At LogMeIn, threat modelling had become a regular part of the development process. But some systems could still be difficult to challenge effectively.
The problem was not necessarily a lack of security awareness. In some cases, the opposite was true. A component might have a relatively simple purpose, be used only by trusted administrators and have been designed by some of the company’s most experienced engineers. When all of those factors were present, it was easy for a team to begin a threat-modelling discussion with a high degree of confidence that the important risks had already been considered.
There was also a human challenge.
As Mark Vinkovits explained, some of the engineers involved had been with the company for close to 20 years. They were principal or fellow-level engineers, long-standing security champions and people who had previously worked on some of the company’s most security-sensitive systems.
For someone newer to the organisation, challenging their assumptions could be difficult.
The question was therefore not simply how to find more threats. It was how to create an environment in which any engineer, regardless of seniority or security experience, could question the assumptions behind a system that highly experienced colleagues already believed to be secure.
Requirements for an effective approach
Any technique adopted needed to fit naturally into LogMeIn’s engineering culture and development process. In particular, it needed to:
- encourage active participation from engineers with different levels of experience;
- give junior and less security-specialised engineers a legitimate way to question the assumptions of more senior colleagues;
- make challenge feel constructive rather than personal;
- provide prompts that moved the discussion beyond the threats the team had already considered;
- produce findings that could be prioritised and incorporated into normal engineering workflows; and
- work efficiently enough to become a repeatable part of regular threat modelling.
LogMeIn used the Elevation of Privilege (EoP) card game to provide that structure.
The Case at LogMeIn: A File Distribution Component
One example Mark shared concerned a component developed several years earlier to distribute files and patches across customer environments.
Its purpose appeared straightforward. An administrator supplied a file location or URL, the LogMeIn component retrieved the file and then distributed it to machines within the customer’s environment.
There were several reasons for the development team to feel confident about the design.
- Firstly, the person initiating the operation was already an administrator. They already had extensive privileges over the machines receiving the file, so there appeared to be relatively little additional power for an attacker to gain.
- Secondly, the component had been developed by some of LogMeIn’s most experienced engineers. As Mark described them, they were almost the “demigods” of the company: people with decades of experience, strong security awareness and extensive knowledge of the systems involved.
For a newer engineer, that created an understandable question: If engineers at that level had designed the system and already considered its security, what was I realistically going to discover that they had missed?
That assumption turned out to be exactly what the threat-modelling session was able to challenge.
How the session was set up
The team ran a focused Elevation of Privilege session involving around five or six engineers familiar with the component, with a security specialist facilitating the exercise.
They began with a lightweight architecture diagram showing the important components, trust boundaries and data flows. The intention was not to produce a detailed architectural model, but to give everyone a common representation of the system against which threats could be discussed.
Participants then played EoP cards in turn. Each card presented a particular attacker behaviour or class of threat. The person playing the card had to consider how that threat might apply to the system shown on the diagram and explain their reasoning to the group.
One person recorded the threats and observations that emerged. This changed the nature of the conversation in an important way. A junior engineer no longer had to say, “I think the design created by these senior engineers is wrong.” Instead, the game gave them a reason to ask, “This card requires us to consider this type of attack. How would the system behave if somebody tried it here?”
The challenge came from the game rather than from the individual. That helped flatten the normal hierarchy of an engineering discussion. Ideas could be explored on their merits, regardless of whether they came from a principal engineer, a security specialist or someone relatively new to the company.
Challenging the assumption
During the session, the team began examining how the component validated the URL supplied by the administrator.
Initially, there appeared to be relatively little that could sensibly be validated. Customers might legitimately provide an internal IP address accessible only from their environment. They might use an Amazon S3 bucket, their own domain or another type of file location. Placing tight restrictions on the format or destination of the URL could therefore interfere with legitimate customer configurations.
But the EoP discussion pushed the team to examine the behaviour from a different perspective. The important question was not simply: “Is this a valid URL for the customer?” It was also: “What can the system itself reach when it processes that URL?”
That distinction exposed an important missing control. Because of the network segment in which the component operated, it could access resources inside LogMeIn’s own network. If a customer supplied a URL resolving to an internal LogMeIn IP address, the component could retrieve that internal resource and then distribute the resulting file back into the customer's environment.
In effect, functionality intended to retrieve customer files could potentially be used to exfiltrate data from LogMeIn’s internal network. The system therefore needed an additional validation rule: administrator-supplied URLs must not resolve to internal LogMeIn network addresses.
Why this finding mattered
For Mark, the significance of the example went beyond the individual vulnerability.
The component had been developed by highly experienced, security-conscious engineers, including long-standing security champions. The EoP session added a fresh perspective, helping the team uncover an important interaction between URL handling, network placement and trust boundaries.
The cards provided an external prompt, allowing junior and senior engineers alike to explore assumptions constructively without making the discussion feel personal. That is one of the important organisational benefits of the game: it gives everyone in the room permission to challenge the system.
From finding to action
Mark also stressed that finding threats during the game was only part of the process.
After each session, the findings were triaged with the relevant project managers and stakeholders. Their technical severity was considered alongside their business importance, and items requiring action were entered into the normal ticketing system.
This ensured that threat modelling did not end as a collection of interesting observations from a workshop. Findings became part of the engineering workflow and could be prioritised, assigned and resolved in the same way as other development work.
A repeatable practice
Mark acknowledged a reasonable scepticism about using a card game for something as serious as threat modelling.
Security analysis is often viewed as a specialist discipline practised by highly experienced security engineers. A game can therefore initially seem too lightweight: participants might concentrate on winning, focus on high-value cards or fail to explore threats with sufficient depth.
LogMeIn’s experience was different. After more than two years of regularly using Elevation of Privilege as part of its threat-modelling practice, Mark reported that sessions would consistently uncover two or three significant findings that had not previously been identified.
The file distribution issue was one particularly memorable example, but it was not presented as an isolated success. The game had become a dependable method for helping teams discover things they had not already thought about.
Why the approach works
The value of Elevation of Privilege is not that the cards somehow replace security expertise. They change the conditions under which that expertise is applied.
The game introduces prompts that force the team to approach the system from perspectives they might otherwise overlook. It distributes participation across the group rather than allowing the discussion to be dominated by the most senior or security-experienced people. And it makes questioning an expected part of the activity.
That is particularly valuable when confidence in a system is already high.
A junior developer can challenge an assumption made by a principal engineer without the conversation becoming a contest between the two people. An experienced engineer can reconsider an old design decision without having to defend it. A security specialist can facilitate the discussion rather than having to personally identify every threat.
The result is not simply a more engaging workshop. It is a practical threat-modelling technique that helps teams challenge trusted assumptions, reduce the effect of hierarchy on security discussions and identify real vulnerabilities in systems that experienced engineers already believed were secure.
