Threat modeling is a core element of the Microsoft Security Development Lifecycle (SDL). It’s an engineering technique you can use to help you identify threats, attacks, vulnerabilities, and countermeasures that could affect your application. Like said, these models are focused on application development. However this guide will try to enlighten you to use this not only in the application development lifecycle, but for other infrastructure related topics as well.
On Microsoft’s website we can find the following statement:
“You can use threat modeling to shape your application’s design, meet your company’s security objectives, and reduce risk.” However nothing stops you from replacing the word application with infrastructure.
So basically, the first step is generalizing all the steps in secure application development to a more conceptual basis and then translating them into steps that can also be used for infrastructure setup and design.
There are five major threat modeling steps:
- Defining security requirements.
- Creating an application infrastructure diagram design.
- Identifying threats.
- Mitigating threats.
- Validating that threats have been mitigated.
So basically, the only thing I did here was replace the words application and diagram with infrastructure design. Voila, we now have the first step in our threat model for infrastructure related topics.
Now the next thing we should do, is basically very straight forward but can become very complex because allot of stakeholders are involved. The first step is defining the security requirements. To be able to define the security requirements you need to comply to, you will first need a security policy in place. This is something that needs to be setup by the business/Organization. This is not a task only for IT. You would need to have higher management involved, to define the outline of these policies. Not only will they provide an outline on how your organization handles security on an organizational level, but also will contribute to showing that your organization has taken due care measures on a security level.
Some of the policies, that make up the security policy for an organization include:
- Organizational policy
- Issue-specific policies
- System-specific policies
- Regulatory policies
- Advisory policies
- Informational policies
- Acceptable use policies
Once these policies are in place you can continue on the setup of security standard, baselines and guidelines. Basically these are used to act out the policies and can be directly used to setup your security requirements.
Infrastructure Design phase
Next up is the infrastructure design. Based on your requirements you will start designing your security solution. These will map, not only the infrastructure components itself. It should also contain all the interactions between each of these components and include the implementation and interaction procedures as well. If you do this, you can easily identify where and how each interaction with a system takes place.
Next up is the identification phase. Basically this is comparing the design, to the security requirements in the design phase. Next to that you can also include testing to identify gaps within the design. In application design, this would also include executing things like SQL injections. However you could use infrastructure related tests here. Remember that security is much more then hackers gaining access to your environment. Availability for example is also a security factor. So in this case you could include some failover tests as well.
Once you have found the gaps, it makes sense to mitigate the security risks. This can be done in several ways. Now I won’t be going into details about the different mitigation strategies and how they should be executed. Just know that basically you can do the following:
- Accept a certain risk and do nothing
- Mitigate or remove the threat (implement a workaround, mitigation or resolve the threat)
- Accept a certain risk and take some form of assurance
Now these are just some basic mitigation strategies. There are more out there, and each has its ups and downsides and should always be matched to the situation the current organization is operating in.
Basically the following validations should take place:
- Validate that the implemented mitigation actions are in place
- Validate that the implemented mitigation actions are effective and operate like predicted
- Validate that the design now matched the security requirements (needs to be done on a regular basis)
- Validate that no gaps have been missed
Please be mindful that security is a continuous process. Ideally you would plan this process on a regular basis, but I do know that is not practical for allot of organizations out there. So I would suggest every time there is a new design or a design change I would suggest going over the steps in this cycle again. Remember that a small change in one end of the design can have a big impact on security on the other end of the design.