Building a Security Operations Centre (SOC)

The first step, when threat modelling, is identifying where:

• users interact with your system
• data flows into or out of your system

This is often referred to as the attack surface of your system.

Identifying the users, data flows and attack surfaces, will allow you to start identifying potential risks and attacks on the system.

As a very simple example, a web server has users that authenticate and submit information. It stores sensitive data and is public facing. Therefore, this server would be considered to be attractive to attackers as a target for their attacks. Meaning that this server would be considered a potential attack vector.

To put it simply, the next step is to figure out what could go wrong. What could happen that would impact the security of your system?

The Confidentiality, Integrity & Availability (CIA) model can be useful here, giving you a neat way to enumerate the potential risks. Equally, you could also apply other approaches for categorising threats or types of attack e.g. the STRIDE model, for greater depth.

Applying the CIA model to our previous Web Server example is instructive. We see that, because the web server handles customer data, there is a risk to the confidentiality of that data if the server were compromised.

If the authentication controls fail, then in addition to gaining unauthorised access and compromising the confidentiality of stored data an attacker could use that access to make unauthorised changes to data, compromising its integrity or delete stored data making it unavailable to authorised users.

This risk analysis is vital, as it rationalises the monitoring of specific components within your organisation. The highlighted risks can also help to guide the development of detection use-cases. (See Detection for more on this).

Attack Map V1
 

Note: You can also expand your risk analysis to encompass the potential impacts to your business if the risk is realised. This can help stakeholders understand potential outcomes and help prioritise on-boarding actions.

Next, you should seek to understand the users or actors that might try to attack or maliciously affect your system.

Each class of actor will interact with the system differently. For example, an expert attacker would have the ability to launch attacks that are far more sophisticated in comparison to a novice. Equally, a typical user would have a different level of access, compared to a privileged administrator.

Attack Map V2
 

This section of the attack map also maintains that the level of protective monitoring should be proportionate to the threat profile of your organisation (as discussed in the Operating Model section). If you determine that your system wouldn’t be subject to attack from the most sophisticated actors, you should not focus on trying to detect them. Instead concentrate on the attacks that your system is more likely to see.

At this point you can objectively explore each abstract risk. This is where the “how” of the attack is detailed. This can then be used to link a risk to a log source.

For example, if the risk was a breach of user data, you simply need to detail how this might happen within your system. It does not have to be extremely detailed and can still be quite abstract as the goal is to identify a log source. At this point it can also be extremely useful to use the MITRE ATT&CK framework as it can help identify specific techniques that an adversary can use and will help you find the most appropriate log source.

Attack Map V3
 

The penultimate part of your threat analysis, and its main output, is the identification of log sources. Here, you identify and list any available log sources that could be used to indicate any of the attacks you have determined might take place within your system.

Attack Map V4
 

Once you have gone through the threat modelling process, you should have a model, detailing several log sources, risks to your system, and various attacks. This model can then be used to develop detection use-cases or ensure you have appropriate coverage in place already. (See Detection for more information on use-cases)