Threat Modeling
J. D. began the presentation by describing some of the purposes of a threat model. Some approaches use a visual representation, but all simplify system requirements to help identify potential threats. The resulting threat model is a list of threats to the system being analyzed. It is also used to hightlight blind spots on the part of the developers. Done correctly, a threat model helps to focus thinking on security in design, and communicates the team's understanding. It should provide an actionable list of tasks to use to reduce threats to a system.
The normal approach would be to create a Data Flow Diagram of the system. Next, the modeller identifies threat boundaries. Boundaries determine the interfaces between different security assumptions in a system. This could be inside/outside the firewall, a system requiring admin privileges, or system that handles billing. When crossing one of these boundaries, different rules apply. The parts of the system on either side of a threat boundard determine what threats apply.
- Vulnerability
- A vulnerability refers to a known weakness of an asset (resource) that can be exploited by one or more attackers.
- Exploit
- An exploit is a process or software designed to take advantge of a vulnerability.
- Threat
- A risk in the design that might lead to a vulnerability.
- Mitigation
- Functionality to address risks
Classifying Threats
Several groups have developed systems or frameworks for defining and classifying threats. Some of the well-known ones include:
- STRIDE used by Microsoft
- DREAD used by OpenStack
- CWE used by MITRE
- Top 10/100 lists published by OWASP
STRIDE
The STRIDE risk assessment divides threats into 6 different kinds:
- Spoofing Identity
- Tampering with data
- Repudiation
- Information Disclosure
- Denial of Service
- Elevation of Privilege
Although fairly effective, STRIDE does have a few problems. It does not take into account privacy concerns. Some threats can also fit into multiple buckets, making over counting or missing threats possible.
The goal of a risk assessment is to find actionable threats. You might want to think of them as Abuse Cases instead of the Use Cases we normally consider. A good list of threats can help to guide further work.
- Guide development of mitigations
- Guide review of design
- Guide QA testing
- Guide security review/testing
Enumerating all of the threats to a system requires going through STRIDE exhaustively for each item in a system. You should mostly ignore externalities without stifling discussion that might lead to important threats. A good approach is to document everything as you go, and throw out duplicates at the end.
Many groups perform threat modeling iteratively. They do an initial threat model when the project is first planned. At each cycle through the development, the threat model should be refined given the better understanding of the system. This simplifies the application of security gates in the development process.
Tools
J. D. tried using OWASP's Threat Dragon tool and Microsoft's Threat Modeling Tool. He found the Microsoft tool to be more useable.
Card Game
Microsoft has provided a card game based on the STRIDE model called Elevation of Privilege. It's available for sale or as a free PDF.
At the end of the talk, J. D. introduced the game and we broke into groups to play and learn more about potential threats. The group appeared to enjoy the exercise and learned quite a bit in the process.
We had 10 people attending this month. As always, we'd like to thank cPanel, Inc. for providing the meeting space and food for the group.
