Bryan Sullivan, a Security Program Manager at Microsoft, called threat modeling a “cornerstone of the SDL” during a Black Hat Conference presentation. He calls it a ‘cornerstone’ because a properly executed threat model:
- Finds architectural and design flaws that are difficult or impossible to detect through other methods.
- Identifies the most ‘at-risk’ components.
- Helps stakeholders prioritize security remediation.
- Gets people thinking about the application attack surface.
- Drives fuzz testing.
- Provides the basis for abuse cases as it encourages people to think like an attacker.
In this post, I’ll discuss some common pushback when it comes to conducting threat modeling in the continuous integration / continuous deployment (CI/CD) environment. I’ll then provide advice for integrating threat modeling properly into the CI/CD pipeline, also known as the DevSecOps pipeline.
If you’re not familiar with threat modeling, here's a YouTube presentation on the Synopsys threat modeling method.
Threat modeling documentation
Yes, threat modeling requires documentation, but that’s not a bad thing.
When teaching threat modeling, a surprisingly common question I hear is “threat modeling requires documentation?” That question is often followed by an explanation that since moving to SAFe and CI/CD processes, firms have disposed of documentation.
This persistent ‘zero documentation in Agile’ myth is based on a misunderstanding of the Agile Manifesto. It is true that the Agile methodology does prioritize working software over written documentation. However, there are a number of design, architecture, and user story artifacts needed to properly communicate commitments and other project parameters to stakeholders.
If the application is mission critical and/or it handles sensitive data, then the project or application threat model is one of the most important artifacts. Architecture diagrams involving the inputs to the threat model are also highly valuable artifacts. The process of creating and maintaining these artifacts—usually a team exercise—is never automatable. This is known as an out-of-band activity.
Performing threat modeling as an out-of-band activity
There are a number of security activities, including tool-driven static application security testing (SAST) and software composition analysis (SCA). These testing approaches are amenable to automation and fit nicely within an always-deployable paradigm. Threat modeling doesn’t fit into this approach.
Think of threat modeling as you would any other manual process or activity such as sprint planning or bug wash sessions. Threat modeling is a team exercise. Conduct it as an out-of-band activity either before the first development sprint, or as part of ‘sprint 0.’
Maintaining threat modeling artifacts
As with any critical documentation, update the threat model as facts that form its basis change or are clarified during a development activity. The artifact you'll need to maintain largely depends on the threat model method in use.
Keep threat modeling artifact(s) in a repository available for team editing (e.g., a wiki or SharePoint site). Ensure that changes are tracked.
Finding issues during threat modeling
Prioritize issues found during threat modeling within the backlog.
Remember, in a continuous development model (Agile or CI/CD), you’re going to be threat modeling as an out-of-band process. Thus, issues found may show up at any time during the threat modeling process. This may mean after development sprints are underway. Write up these issues as user stories and prioritize them on the backlog during a bug wash or sprint planning session—just as any other user story or defect.
It may be necessary to ‘pull the chain and stop the train’ to fix a serious issue found in a threat model.
I was once involved in a threat modeling exercise where we identified that the authentication module in a system handling protected health information (PHI) was seriously broken. The development team was in the middle of one of the last sprints in a release commitment. The current sprint was cancelled and priorities were rearranged.
Since threat modeling involves at least some of the Principals on the development team, it shouldn’t be a surprise to the team if there’s a disruption to resolve a serious security flaw identified through threat modeling.
The bottom line
Threat modeling needs to be a part of CI/CD and Agile processes. There are too many benefits to threat modeling not to conduct this activity on mission critical applications—regardless of the methodology in use for development.
Continue Reading
