Scenario mapping

For the final section of this chapter, we are going to look at an important part of SOC development: scenario mapping. This process is carried out on a regular basis to ensure that tools and procedures are tuned for effective analysis and have the right data flow and that responses are well defined to ensure appropriate actions are taken upon detection of potential and actual threats. To make this an effective exercise, we recommend involving a range of different people with diverse skill sets and viewpoints, both technical and non-technical. You can also involve external consultants with specific skills and experience in threat hunting, defense, and attack techniques.

The following process is provided as a starting point. We encourage you to define your own approach to scenario mapping and improve it each time the exercise is carried out.

Step 1 – defining the new scenarios

In this first step, we articulate one scenario at a time; you may want to use a spreadsheet 
or other documentation methods to ensure information is gathered, reviewed, and updated as required:

• Impact analysis: This will be the summary of the complete analysis, based on the next components. You may want to provide a scoring system to ensure that the implementation of security controls is handled in priority order, based on the severity of the potential impact.
• Risk versus likelihood: While some scenarios would have a high risk of catastrophe if they were to occur, we must also balance that risk with the potential of them occurring. Risk calculations help to justify the budget and controls required to mitigate the risk but keep in mind that you are unlikely to achieve complete mitigation, and there is always a need to prioritize the resources you have, to implement the controls.
• Cost and value estimate: Estimate the value of the resource to your organization and the cost to protect it. This may be a monetary value or percentage of the IT security budget, or it could be some other definable metric such as time and effort. If the cost outweighs the value, you may need to find a more affordable way to protect the resource.
• Systems impacted: Create a list of the systems that are most likely to be targeted to get to the resources and information in one or many scenarios (primary systems) and a list of the other systems that could be used or impacted when attacking the primary systems (these are secondary systems). By understanding the potential attack vectors, we can make a map of the targets and ensure they are being monitored and protected.
• People impacted: For each scenario, list the relevant business groups, stakeholders, and support personnel that would be involved or impacted by a successful attack. Ensure that all business groups can contribute to this process and articulate their specific scenarios. Work with stakeholders and support personnel to ensure clear documentation for escalation and resolution.
• Customers impacted: For some scenarios, we must also consider the customer impact as regards the loss or compromising of their data or an outage caused to services provided to them. Make notes about the severity of the customer impact, and any mitigations that should be considered.

Step 2 – explaining the purpose

For each scenario, we recommend providing a high-level category to help group similar scenarios together. Some categories that may be used include the following:

• System health: This is the scenario focused on ensuring the operational health of a system or service required to keep the business running.
• Compliance: This is the consideration due to compliance requirements specific to your business, industry, or geographical region.
• Vulnerability: Is this a known system or process vulnerability that needs mitigation to protect systems or processes?
• Threat: This is any scenario that articulates a potential threat but may not have a specific vulnerability associated with it.
• Breach: These are scenarios that explore the impact of a successful breach.

Step 3 – the kill chain stage

The kill chain is a well-known construct that originated in the military and was later developed as a framework by Lockheed Martin (see here for more details: https://en.wikipedia.org/wiki/Kill_chain). Other frameworks are available, or you can develop your own.

Use the following list as headers to articulate the potential ways in which resources can become compromised in each scenario and at each stage of the kill chain:

• Reconnaissance
• Weaponization
• Delivery
• Exploitation
• Installation
• Command and control
• Actions on objectives

Step 4 – which solution will perform detection?

Review the information from earlier in this chapter to map which component of your security solutions architecture will be able to detect the threats for each scenario:

• SIEM
• CASB
• DLP
• IAM
• EDR
• NGFW
• WAF
• CWPP
• CSPM
• Many others

Step 5 – what actions will occur instantly?

As we aim to maximize the automation of detection and response, consider what actions should be carried out immediately, and then focus on enabling the automation of these actions.

Actions may include the following:

• Logging and alerting
• Notifying/warning the end user
• Blocking the action
• Offering alternative options/actions
• Triggering a workflow

Step 6 – severity and output

In this step, you should be able to assign a number to associate with the severity level, based on the impact analysis in the previous steps. For each severity level, define the appropriate output required:

• Level 0 – Logs and reports
• Level 1 – Dashboard notifications
• Level 2 – Generate events in the ticketing system
• Level 3 – Alerts sent to groups/individuals
• Level 4 – Automatic escalation to the senior management team (sirens and flashing lights are optional!)

Step 7 – what action should the analyst take?

Whereas the Step 5 – what actions will occur instantly? section was an automated action, this step is a definition of what the security analysts should do. For each scenario, define what actions should be taken to ensure an appropriate response, remediation, and recovery.

The following diagram is a simple reference chart that can be used during the scenario-mapping exercise:

Figure 1.4 – The scenario-mapping process

By following this seven-step process, your team can better prepare for any eventuality. By following a repeatable process, and improving that process each time, your team can share knowledge with each other, and carry out testing to ensure that protection and detection are efficient and effective as well as identifying new gaps in solutions that must be prioritized.

You should commit to taking time away from the computer and start to develop this type of tabletop exercise on a regular basis. Some organizations only do this once per year, while others will do it on a weekly basis or as needed based on the demands they see in their own systems and company culture.