Whether you're building a new system or updating an existing one, you'll want to consider how an intruder might go about attacking it and then build in appropriate defenses at the design and implementation stages of the system. The design of secure systems through a technique called threat modeling—the methodical review of a system design or architecture to discover and correct design-level security problems. Threat modeling is an integral part of the Security Development Lifecycle.
One of the most valuable and important SDL practices is threat modeling which is a systematic way to find design-level security and privacy weaknesses in a system. It also helps guide a designer or architect to determine the correct mitigation(s) to use to reduce the overall risk to a system and the data.
The threat risk modeling process has five steps, enumerated below and shown graphically in Figure:
- Application Overview
Once the security objectives have been defined, analyze the application design to identify the components, data flows, and trust boundaries.Do this by surveying the application’s architecture and design documentation. In particular, look for UML component diagrams. Such high level component diagrams are generally sufficient to understand how and why data flows to various places. For example, data movement across a trust boundary (such as from the Internet to the web tier, or from the business logic to the database server), needs to be carefully analyzed, whereas data that flows within the same trust level does not need as much scrutiny.
- Decompose Application
Once the application architecture is understood then decompose it further, to identify the features and modules with a security impact that need to be evaluated. For example, when investigating the authentication module, it is necessary to understand how data enters the module, how the module validates and processes the data, where the data flows, how the data is stored, and what fundamental decisions and assumptions are made by the module.
- Identify Threats
It is impossible to write down unknown threats, but it is likewise unlikely that new malware will be created to exploit new vulnerabilities within custom systems. Therefore, concentrate on known risks, which can be easily demonstrated using tools or techniques from Bugtraq.
6.2.1. Threat Modeling and STRIDE
Secure properties:
- Confidentiality
Data is only available to the people intended to access it.
- Integrity
Data and system resources are only changed in appropriate ways by appropriate people.
- Availability
Systems are ready when needed and perform acceptably.
- Authentication
The identity of users is established (or you’re willing to accept anonymous users).
- Authorization
Users are explicitly allowed or denied access to resources.
- Nonrepudiation
Users can’t perform an action and later deny performing it.
One way to ensure your applications have these properties is to employ threat modeling using STRIDE, an acronym for Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege.
To follow STRIDE, you decompose your system into relevant components, analyze each component for susceptibility to the threats, and mitigate the threats. Then you repeat the process until you are comfortable with any remaining threats. If you do this—break your system down into components and mitigate all the threats to each component—you can argue that the system is secure.
