I want to elaborate more on having a security reviewer and how to structure threats for any given application. Will be going through some theoretical aspects of threat modeling, describing the security reviewer role and demo out Microsoft Threat Modeling 2016 using this blog application as an example.
To reiterate the idea laid out by the code review process in the previous post: to have feedback, in this case security concerns, as close as possible to the code development phase. Some companies have security checkpoints done when the coding has been completed and is ready to be published but I believe that some of these checks should be shifted closer to the development phase.
Threat modeling allows you to apply a structured approach to security and to address the top threats that have the greatest potential impact to your application first. It should not be a one time only process. Because the code base is not rarely static and is always growing to suit changing business needs, this process should be an iterative one done as soon as a change appears.
- Identify assets
- Identify the valuable assets that your systems must protect.
- Create an architecture overview
- Use simple diagrams and tables to document the architecture of your application, including subsystems, trust boundaries, and data flow.
- Decompose the application
- Decompose the architecture of your application, including the underlying network and host infrastructure design, to create a security profile for the application. The aim of the security profile is to uncover vulnerabilities in the design, implementation, or deployment configuration of your application.
- Identify threats
- Keeping the goals of an attacker in mind, and with knowledge of the architecture and potential vulnerabilities of your application, identify the threats that could affect the application.
- Document threats
- Document each threat using a common threat template that defines a core set of attributes to capture for each threat.
- Rate threats
- Rate the threats to prioritize and address the most significant threats first. These threats present the biggest risk. The rating process weighs the probability of the threat against damage that could result should an attack occur. It might turn out that certain threats do not warrant any action when you compare the risk posed by the threat with the resulting mitigation costs.
The output from the threat modeling process is a document for the various members of your project team. It allows them to clearly understand the threats that need to be addressed and how to address them. Threat models consist of a definition of the architecture of your application and a list of threats for your application scenario.
Below is a simplistic threat model done in Microsoft Threat Modeling tool.
The tool works by offering the user a canvas section where you design the system architecture and data flows. Then , by running the threat generation, a new window will display showing all the possible risks.