Free Delivery on orders above £75 for our US and Europe customers

How LogMeIn challenged security assumptions in a trusted system

The Challenge

LogMeIn’s security teams observed that certain types of systems benefit less from traditional threat-modelling workshops. Components that appear simple in purpose, are operated by trusted administrators, or are authored by very experienced engineers can naturally attract a high level of confidence early in the discussion. While this confidence is often well founded, LogMeIn’s approach to security emphasises continuous improvement and the deliberate testing of assumptions.

The challenge, therefore, was to introduce a method that would reliably broaden the discussion beyond initial expectations, without undermining trust, slowing teams down, or placing the burden of analysis on a small number of security specialists.

Requirements for an Effective Approach

Any technique adopted needed to align with LogMeIn’s existing engineering culture and delivery practices. In practice, this meant:

Encouraging active participation from all attendees, including those without deep security expertise
Supporting constructive challenge in a way that felt natural and collaborative
Producing outputs that could be prioritised and integrated into normal engineering workflows
Working efficiently within a focused workshop format

The solution also needed to scale as a repeatable practice rather than a one-off exercise.

The case at LogMeIn: Strengthening a File Distribution Component

One example shared during the talk concerned a component designed to distribute files across customer environments. An administrator would provide a file or a URL, and the system would retrieve that file and distribute it to managed machines. From an operational perspective, the design was clear and purposeful, and the fact that the initiating user already held administrative privileges shaped the team’s initial risk framing.

How was the session set up

For this threat-modelling exercise at LogMeIn, a single Elevation of Privilege session was arranged as a focused workshop. Five to six engineers who were familiar with the component took part, alongside a security specialist who facilitated the session and ensured the game mechanics were applied consistently.

The session began with a brief walkthrough of the component’s architecture, using a simple diagram as the shared reference for discussion. This model was kept deliberately lightweight, highlighting the key data flows relevant to file retrieval and distribution.

Participants then played the Elevation of Privilege cards in turn. Each card prompted a specific attacker behaviour or weakness to be considered against the diagram, with the player explaining how it might apply. One participant was assigned to capture all identified threats and observations for follow-up.

Using the game framed the discussion as structured exploration rather than critique, enabling the group to examine assumptions openly and efficiently within the time available.

During the EoP session, the team explored how the system handled validation of administrator-supplied URLs. While recognising the legitimate variability of customer environments, the discussion surfaced an important architectural consideration: the component’s position across firewall boundaries meant that additional constraints were needed. Specifically, the system should prevent URLs that resolve to internal LogMeIn network addresses. Without that safeguard, the component could unintentionally retrieve internal resources and distribute them externally.

The value of the exercise was not simply in identifying a missing check, but in clarifying how trust boundaries, network placement, and retrieval behaviour interacted. The game format enabled the team to reach this understanding through collaborative reasoning rather than challenge or debate.

Outcomes and Integration

The findings from the game were captured, discussed with project stakeholders, and triaged according to business and technical priorities. Items that required action were then entered into the normal tracking system, ensuring that insights translated into concrete improvements.

Mark noted that this was representative rather than exceptional: regular use of the Elevation of Privilege game consistently produced a small number of high-value findings that had not previously been identified, reinforcing its role as a dependable part of LogMeIn’s security practice.

Why the Approach Works

As articulated by Adam Shostack, the effectiveness of the game lies in how it changes the dynamics of the conversation. By framing threat exploration as part of play, the exercise creates permission to question assumptions, explore edge cases, and disagree constructively. It also encourages flow, sustained engagement, and rapid feedback, all of which contribute to better analysis.

Crucially, Elevation of Privilege is not used solely as a training exercise. At LogMeIn, it functioned as a practical tool that produced real threat models and supported an organisational culture focused on shared ownership, learning, and continual improvement.