Time, resources, and money - three things that most IT and security teams never seem to have enough of, in the never ending fight to keep your organization secured. With so many risks and vulnerabilities to track and remediate, how can a team focus their efforts for maximum impact and implement the most relevant threat controls first?
In this blog post, I describe the tangible effect security controls should yield - practices enabling risk reduction; I introduce some Threat Modeling frameworks that you can draw upon; I provide a simplified version of the process these frameworks yield - more appropriate for SMBs in terms of time, resources and money available, that covers assessment, analysis, and mitigation phases of a Threat Modeling undertaking. And finally, I provide a concrete, visual example that you can use to help protect your organization.
Controls: Driving Security Practices
First off, what do we mean when we talk about controls? Security controls are, essentially, mitigations put in place by an organization to help avoid such as policies, procedures or technology, reduce or eliminate risks to the classic confidentiality, integrity and availability (CIA) of computer systems and data. There are many examples of frameworks that outline security controls that should be implemented in an organization. Some that we refer to often here at ActZero are CIS 8.0(link) and CMMC (link).
When we talk about threats NIST has compiled a number of different definitions from frameworks and sources (here). The first one they list from FIPS-200 should suit the purposes of this article and that is:
“Any circumstance or event with the potential to adversely impact organizational operations (including mission, functions, image, or reputation), organizational assets, or individuals through an information system via unauthorized access, destruction, disclosure, modification of information, and/or denial of service. Also, the potential for a threat-source to successfully exploit a particular information system vulnerability.”
Not “one size fits all”
Every organization has a unique environment, facing different threats and may need to implement different controls at higher priority than other organizations. One method to help prioritise controls against external security threats is to use Threat Modelling. Originally used to model threats in a military context to evaluate defensive preparations, this technique is used today to:
- help identify the threats that are the greatest risk;
- highlight gaps in safeguards, and
- to prioritise the mitigations and controls to protect against the identified threats.
Not every control will be the same and an organization with the exact same infrastructure, controls or processes may not have the same model. It all depends on the priorities specific to a given organization - for example, environments that have a lot of in-person interaction with hardware might prioritize controls for removable hardware.
Threat Modelling Frameworks
There are a number of frameworks that are used for modelling threats to software, or reducing organizational risk while others focus more on actors or personas. Some popular examples of Threat Modelling Frameworks are STRIDE, PASTA and OCTAVE. While these can be useful, many small and medium-sized enterprises will not have the resources to go deep into Threat Modelling. Again, the time, resources and money issue... So what can we do instead? Well, we can take the most important concepts from these frameworks, use them to solve problems, and iterate over time to improve them.
Simplifying the Frameworks
An organization is going to want to start simple and the simplified process really boils down to three basic steps, repeated over time: Assess→ Analyze → Mitigate.
Assess Your Environment
Step back and take a good look at your data and infrastructure. Smaller organizations needn’t get too far into the weeds; the deeper you go, the more detailed it will be, the longer it will take and the harder it will be to start remediating the vulnerabilities you uncover. Don’t try to boil the ocean here. Start by identifying and understanding what your “Crown Jewels” are. They may include important database servers, and will almost certainly include your network directory infrastructure (such as Active Directory). Identify the most important systems, services, or data that if lost or otherwise interrupted, could lead to extreme business disruption, high costs to recover, or even going out of business. Things that couldn’t wait a few days to fix or reinstall, or that are proprietary in nature (the “secret sauce recipe,” for example)...
You also want to understand overall what assets you have as well as what security defenses are in place already. There is no sense starting an exercise to model threats against old AS400s if you don’t have any in use!
Assess Threats & Vectors
Next come the threat-related questions. Look at the most immediate and severe threats to your organization. What are the attacker’s motivations; what would they be after? What would their target be? What does that scenario’s attack pattern look like? And lastly, how ready is your organization to defend against those types of threats? See my colleagues’ webinar on perspectives of attackers and defenders to see this line of questioning in action.
To give you a broader picture, look at global threat trends and threat intelligence, data from internal incidents and events/IOCs (pull your SOC data, dust off those RCA minutes), and Red Team exercise or penetration test reports. Working with stakeholders like finance, leadership, R&D and others can provide valuable insight about your organization’s “Crown Jewels”. There may be things not obvious to you as an IT or Security professional that are critical to the business.
Take the information you gathered in the previous phase and dig deeper. Examine in more detail your incidents and control breakdowns. You want to understand what went wrong in the context of where a specific control broke down, or was absent. Focus on a single specific threat in this phase. You probably have (at least) a few that came up in the Assess phase - but save those for the next iteration of the process. Focus here on the most likely, important, or potentially damaging threat.
Draw the attack pattern
Take the high level steps in the attack pattern and map them into boxes in the process (click here for a visual representation of what I mean). Be as generic as possible here, keeping the steps broad, so that your model can cover other related scenarios. If you get too specific your model will cover too narrow a scope and you may miss opportunities to map controls that would help protect against related attacks. For example, if you only mapped a threat specifically to one operating system or brand of endpoint, you may leave gaps for all the other OSs or endpoints in your environment.
Now that you know what the threat is, the stages that it can take, and you have a rough model represented visually - map your controls to each of those stages, and look at the diagram to see where your gaps are. These are the areas you will want to propose new controls, in order to mitigate the risk of such gaps being exploited. Here at ActZero we use our own maturity model to help customers understand what controls they have or are missing in their environments. You can use this kind of information to help with this part of the process.
Once you have mapped your controls and mitigations to the model, you should have a picture of steps along the way that are missing (effective) ones. You then identify what additional controls or mitigations you may need at the various attack stages to help reduce exposure. The closer to the start of the attack that you can add mitigations and controls the better chance of reducing the exposure and impact of the potential threat.
This exercise doesn’t yield a reduction in risk unless you take the practical steps. Having controls in place is meaningless if they don’t represent a practice that your team, or those of your partners, can use frequently.
Make sure that you validate and test those controls to ensure that they work as expected. (We talked about the importance of Validating and Testing in our white paper).
Document and Communicate
Share the final output of your model with leadership, risk and vulnerability management teams for visibility and communication to broader audiences. Share it with Red Teams or partners who can use the information to help your validation, testing and improvement. You now have your first Threat Modeling exercise completed - but this is just one of many.
Next up, iterate on the process to explore additional high importance scenarios. Models can change or be stale due to factors such as aging technology, new attacks, or implementation of controls elsewhere that could have an impact on other scenarios. There is no one cadence that will be right for everybody; evaluate your models frequently to see whether they still apply.
I hope you learned a thing or two about threat modeling! Now that you have specific frameworks to draw on, and a boiled-down version to expedite the progress, you stand to gain the benefits of reduced risk of cyber attack (by implementing controls specific to the threats that are most important for your organization) and reduced impact when they do land (by implementing new controls, and using them to practice scenarios to prepare for attacks). The only thing missing? A visual representation of the threat modeling exercise - which you can download in this example, for free, right here.