Jim Gumbley, a cybersecurity focused technology consultant at ThoughtWorks, has recently published an article on MartinFowler.com with a template for facilitating remote and onsite threat modelling sessions for teams. Gumbley makes a case for continuous threat modelling alongside business partners, as teams build new features. He wrote that this produces prioritised stories, acceptance criteria, architectural epics and spikes which address real organisational risks.
Derek Handova, Synopsys Software Integrity Group security advocate, also wrote a recent article on DevOps.com about the DevSecOps perspective on seeking incremental security assurances as part of a Secure SDLC. Handova made the case that automating security testing scenarios can result in "consistent levels of application security testing" every time developers check-in code. He wrote of the need for a security inclusive SDLC in supporting a regular cadance of feature delivery:
Under DevOps, some development organizations now do software releases on a daily, weekly or bi-weekly cadence. But they’re still grappling with older application security models. As a result, development and security testing can be out of sync—you cannot conduct a two-week pen test on software that’s released weekly. These organizations need effective security assurance in their SDLC that’s good, quick, early and—above all else—automated.
Gumbley provides a template for a 15 to 90 minute workshop to help teams identify and respond to risk introduced by new features during design. He recommends opening threat modelling workshops with a "security related brain teaser" to break the ice. Gumbley’s format for the workshop visualises the technical solution and then elicits risks through "evil brainstorming." He breaks the session into three main activities which answer the following questions:
- "What are you building" - This produces a shared technical diagram of the solution.
- "What can go wrong?" - Technical threats are elicited through a brainstorming activity.
- "What are you going to do?"- This yields "prioritised fixes added to backlog".
Gumbley wrote that remote threat modelling sessions should be planned "so everyone can participate virtually." He shared that at ThoughtWorks they’d had success using video conferring tools combined with collaboration tools "including Mural, Miro, Google Jamboard and Google Docs."
Gumbley recommends keeping remote threat modelling sessions short by creating technical "diagrams asynchronously before the exercise." He emphasises the need to remotely facilitate a "common understanding of the concepts" and "explain diagram symbols, data flow arrows and colours of digital stickies." Gumbley wrote that this visualisation should include details about users, system boundaries and network boundaries; for which he provided several examples.
Gumbley recommends encouraging developers on the team to help visualize the proposed solution as they "will be comfortable drawing diagrams to explore software designs." He suggests the facilitator "tap into these established skills" in visualising the "trusted paths" of a system. He wrote:
Attackers often use the same pathways to pivot around systems that legitimate users do. The difference is they abuse them.
Gumbley wrote of the importance for teams to threat model together with "product owners, business analysts and delivery managers". He suggested that this "helps address risk holistically and helps the whole team to learn." Without such collaboration, Gumbley argued that the threats would not be addressed as their "value will not be widely understood." He reminded his reader of the shared stake in security, as when "cyber security losses occur they are business losses."
When brainstorming threats, Gumbley suggested using a framework such as STRIDE. STRIDE directs teams to consider risks associated with factors such as identity spoofing, tainted input, information security and privilege escalation. Gumbley's recommendation was to "follow the data-flow lines" to identify exploitable "technical mechanisms" and flows. Such threats can then be captured using "digital stickies." He also warned of the sensitivity of the resulting learnings, stating:
Threat modelling outputs represent sensitive information for a number of reasons and must be protected.
Gumbley wrote that "remote work is tiring" and promoted creating "smaller groups and then consolidating the output." He suggested that "a couple of small sessions is better and more sustainable than one big session."
To aid in prioritisation of mitigations, Gumbley suggested dot-voting on the threats which have been identified. He suggested that this would "yield good risk decisions for low investment, reflecting the diverse perspectives in the group."
Handova wrote that there is "no one-size-fits-all DevSecOps process" across enterprises and development teams. For every risk, he wrote that teams need to "provide the appropriate level of security assurance and security coverage." Handova wrote that this decision may determine whether any resulting investment in security testing will determine the response. That is, whether it is "automated within the DevOps workflow, performed out of band or some combination of the two."
Handova cautioned the need to minimise "friction for developers," in order to avoid bypassing security in favour of "expediting coding activities." He wrote of the value of catching security issues "earlier and more easily while developers are still thinking about the code." Handova’s focus was on using test automation to mitigate "the risk of developers not remembering the code context at a later date." To identify and prioritise security risks, Gumbley recommends threat modelling within each iteration:
...do threat modelling 'little and often'. When you work this way each threat modelling session is tiny, having little impact. Yet the cumulative effect of doing them has a huge impact. When you know you'll be doing this again every iteration, there's less incentive to try to do everything at once and more incentive to prioritize the most important work right now.
