Threat Modeling Recipe for a State-of-the-Art SOC

What is threat modeling:

Threat modeling is the process of identifying potential threats and risks from internal or external actors for an infrastructure, evaluating the existing counter measures and gaps, develop a strategy in action to fill the gaps and respond to the threats.

A Successful Threat Modeling should involve the following steps.

1) Understand the Organization and Line of Business

Each line of business has their own risks and threats. For example, the threats of banking firm is not the same as a healthcare or Government entity. So, understanding the line of business would help well in plotting the threat actors and attack motivation.

2) Physical and Logical Security Architecture Review

This could be the most important step of Threat Modeling. The first step of architecture review is to get a high-level design diagram of the organization. The diagram should cover all the physical, logical assets, networks, and intellectual properties of the organization. Missing to consider any of the components of the physical or logical architecture would make the whole process fruitless.

• Physical assets could be the office building, branch offices, data centers, devices, etc
• Logical assets are any software run within the organization
• Network assets are any logical or physical network connection with in the organization or with any external third parties like vendors or clients
• Intellectual properties include the source code for a software proprietary by the organization or any secret document, exposing which would affect the business of the organization

In this step, the diagram should be divided in to different security domains and each domain should be prioritized according to the severity of threats and risks. The example for security domains could be

• Perimeter
• Third-party connections
• WAN
• Core network
• Branch offices
• User network
• Core application servers
• Database servers
• VMWare ESXI
• Wireless clients
• DMZ

Domains like Database Servers and Application servers, Perimeter should be given high severity with core network could be less critical.

Its paramount to review the architecture diagram carefully as this step could influence rest of the Threat Modeling process.

3) Define Assets

A good security engineer knows all his assets. Next step in threat modeling is to list all the assets owned by the organization. Each asset should be categorized by the type and assigned to a security zone.

4) Identify the Vulnerabilities, Threats, and Risks

A vulnerability is a weakness of a system which can be exploited. Threat is anything which can potentially harm a system by exploiting a vulnerability. Risk is the impact if a vulnerability is exploited by a threat.

This is the most complex step of Threat modeling. Each asset should be analyzed carefully to unearth all the possible threats. A threat can be anything from an unauthorized access to office premises to anyone hacking in to the critical database servers.

So, threat modeling not only involves the cyber security team, but anyone and everyone within the organization like application owners, network, operation team and even the security personal in the reception who can give key inputs in securing the infrastructure. Penetration testing could be the best approach to identify the threats which are hidden behind walls. It can go through many white board sessions to have a plausible list of threats.

Each threat identified should be classified according to a risk score. This will help in choosing the best affordable counter measure for the risk.

5) Review the Countermeasures and Gap Analysis

After the threats and risks are identified, it’s time to review available counter measures and find the gaps. Counter measures could be anything like Mantraps installed to prevent unauthorized physical access firewall to control network access. Each risk defined in the last step should be reviewed and available counter measures should be mapped to it. The risk what is left is the gap.

Ideally, the gap has to be analyzed and new counter measures are to be deployed. For most of the organizations, filling this gap is a time-consuming process as this could mostly involves a cost. It could be buying lot of new security solutions and hiring experts to manage the solution.

6) Integrate your Security state to SOC

With the Threats, Risk, Countermeasures and Gap known, lets design our state of the art SOC (Security Operations center). Not all the risks can be mitigated in an organization and some need to be accepted due to various reasons including limitations or cost. It’s a mistake to believe that we are all set after the counter measures are deployed. The security architecture requires constant monitoring for the new evolving threats. Also, the chance of threats being missed to identify is high. Security infrastructure with Constant monitoring can be forgiving even if you don’t have all the gaps filled. Or rather, a good SOC can fill most of those gaps due to its versatility in identifying upcoming logical threats and stop it before the risk is materialized.

A next generation SIEM (Security Information and Event Management) solution with some good pairs of eyes can be your friend here with sometimes a fraction of cost involved in filling all the gaps. Also, SIEM helps in visualizing the complete security infrastructure at granule level to monitor the traffic and identify anomalies. Various use cases can be created within a SIEM solution to fill the risk gaps and automate responses.

These are the steps involved in designing the SOC:

Integrate all assets to SIEM

All network, security and system assets by the organization should be integrated to the SIEM Solution. Each asset should be carefully configured to send only the required information (Log, netflow, SNMP traps, etc) to enable in-depth view while avoiding noise.

Define Threat Cases

A threat case is a detailed description of the possible mitigation or alert actions in case a threat appears. A good example will be a SIEM solution sending an alert when it sees more than 1000 ICMP packets from a specific IP pointing to your web server in 30 seconds. SIEM can also be configured to block the specific source IP from firewall using an automated response.

Let’s get back to the documents where we have defined all our threats, risks and security domains. Each of those threats need to be reviewed and threat cases need to be defined for each security zone. All possible scenarios should be documented for defining the threat case.

Simulate the Threat

With threat cases being defined, we have a fair idea on how a specific threat should look like. It’s a good idea to simulate it at least in the lab collect the logs and event details which helps us configure the correlation rules in SIEM. It’s not possible to simulate all the threats. We can go with known event details in such cases.

Build a Correlation Rule Plan

Now we know how the system behaves for each threat. With this, we would define a correlation plan to create a rule in the SIEM solution. With the collected event IDs and all supporting data, we can configure the SIEM solution to either send alerts or perform an automated response. This process may vary between different SIEM solutions.

Sample Correlation Rule Plan for Site to Site VPN Security Zone

Configure the Rule in SIEM

Once the rule plan is ready, it’s time to integrate the same to the SIEM. Each rule need to be monitored and tested for false positives and tuned if required.

7) Monitor-Tune-Mature

Any SIEM solution is not so effective without constant monitoring and tuning. It may fill the gaps identified for now with the above steps. But the cyber war is evolving to new levels every day. Someone dedicated to monitor the warfare and mature your SIEM/SOC to defend it is more than necessary. Or all the time and resources you spend on the above tasks can be ineffective within some time.