This article was originally written by Robert Reichel for the GitHub blog. To see the original article in its entirety, click HERE.
One of the most effective tools for DevOps teams looking to increase the security of their applications is threat modeling. Threat modeling involves bringing security and engineering teams together to discuss systems and generate action items that improve the security of the system.
Here at GitHub, threat modeling has helped us improve communication between our security and engineering teams, has made the security review process more proactive, and has led to more reliable and more secure system designs.
The creation of a threat model is a collaborative security exercise where we evaluate and validate the design and task planning for a new or existing service. This exercise involves structured thinking about potential security vulnerabilities that could adversely affect a service.
Every threat modeling conversation should have at least the following goals:
- Ensuring everyone understands how the system works.
- Evaluating the surface area and developing the most likely points of compromise.
- Developing mitigation strategies to be implemented for each point of compromise.
The simple act of sitting down and discussing the system holistically provides a great opportunity for everyone to discuss the underlying system. Knowledge sharing between the teams helps everyone grow in their knowledge of the systems in the environment. This also contributed to the development of vulnerability mitigation strategies for issues discovered during the threat model review, which improved the security posture of the entire organization.
Government agencies looking to embrace threat modeling within their own organizations may not know where to start. So, here the process that we follow at GitHub, which has delivered system-wide security improvements, proactive design guidance, and improved communication between security and engineering teams:
Decide when to threat model
At GitHub, we typically do threat modeling on a set cadence with each of the feature teams, and before the release of any new features that make major changes to the architecture. Depending on the amount of engineering taking place on a feature, you may need a faster cadence (every couple of months) or a slower one (once per year).
If you have an existing cadence of software review, we’ve found that integrating it with those existing processes helps everyone to adapt to adding a new security process. Regardless of your timing, set guidelines, and be flexible.
Build the threat model
Threat modeling is usually a collaborative exercise, so the engineering team for the product and the security team will get together to talk through the architecture and potential security concerns. Ahead of time, our security team will provide documentation and examples to the engineering teams on effective threat modeling.
We typically ask each engineering team to generate a model in advance, covering a significant part of a system to review as part of a single threat modeling conversation. Setting these expectations early (and doing the homework) helps to ensure that the meeting is effective.
Though the process and discussions are what matter more than the specific output, at GitHub, we ask the engineering team to bring a threat model developed either in Microsoft’s Threat Modeling Tool or OWASP’s Threat Dragon (both are entirely free). These tools enable the teams to clearly present important information for the threat model such as APIs, trust boundaries, dependencies, datastores, authentication mechanisms, etc. In addition to providing some consistency between teams, these files will also act as important collateral to share with any auditors if you need to meet various security compliance requirements.
Review the threat model
When it’s time to review the threat model, we typically schedule a one-hour session, broken into two parts. The first five to 10 minutes of every session is spent with the engineering team understanding the design of the system that is being reviewed. This time ensures that everyone is on the same page and helps clarify any ambiguities from the previously prepared threat mode—including which technologies are being used and any design quirks. After everyone is aligned, we can jump right into the security discussion.
At this point in the security discussion, we’ve found it helpful to use a framework to methodically address different vulnerability classes. One of the methodologies we frequently use is Microsoft’s STRIDE model—Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Escalation of Privilege—a mnemonic covering common attack vectors which may be found in an application. Stepping through these classes while looking at the overarching system enables the security teams to holistically look at a system being analyzed and ensure that they cover the most likely threats. Following STRIDE fills the remainder of the hour as conversation expands and more parts of the system get unpacked.
As potential security vulnerabilities or design flaws are found, the security team takes note of them as well as potential remediations. This is so we can generate a list of potential changes for the engineering team to consider making after the session.
We found that as threat modeling became more common across GitHub, teams learned to engage the security team while developing the system—which is better, as it fostered getting ahead of potential issues and addressing major architectural changes before hands hit keyboards. This in turn helped the security teams deploy better defense in depth through secure design principles.
As the session draws to an end, we recount the key findings and improvements that the teams should make and generate tracking items for those. A summary is distributed to the participants where anyone is free to ask follow up questions to better flesh out the action items.
Threat modeling is an incredible way for government DevOps teams to identify vulnerabilities in their applications and make them more secure. GitHub’s methodology for threat modeling has had generated incredible results for the company – enabling the development of vulnerability mitigation strategies, guiding engineering teams from system designs that might present future vulnerabilities and building connections between the engineering and security teams that make it easier to reach out— in both directions.
