Risk-Centric Threat Models as Blueprints to Operationalizing Cybersecurity

Understanding The Context of a Risk-Based Threat Model

Introduction: SOC Processes are Flawed

Desensitization, as defined within the psychological definition, is a process that diminishes responsiveness to adverse events after repeated exposure.

As I write this near midnight, I can’t help but think of the hundreds of security analysts that work within the confines of security operations centers (SOCs) worldwide, perhaps on a second or third shift, eyeing alerts from log aggregators, security incident event monitoring (SIEM) solutions, or even event correlation engines.

That was me in 2005. Even now I remember the stamina needed to stay focused and engaged to the alerts that came into what seemed like a never-ending queue, much of them even labeled as false positives by fellow associates from prior shift notes or the event tracker itself. I wonder if the analysts today feel desensitized over their 8, 10, or even 12-hour shifts, as they receive security alerts from multiple infrastructures that they’ll never even know contextually what purposes they serve.

Of course, those analysts will become desensitized. Hackers count on it every day and have for years.

I make this point facetiously to draw some much-needed light to the status quo methods of running and subscribing to SOC services in 2020. As many continue to search for the silver bullet of products to correctly identify an indication of compromise based upon 20, 30, or even 50 distinct events for in-scope infrastructures, systems, and applications, I would like to point out many key observations that indicate today’s SOC processes are fundamentally flawed.

The Observations are as Follows:

• The SIEM Alone SOC. Most of us in the field know of countless failed or incomplete SIEM implementations. If a SIEM alone is the primary tool shaping the security analysis of your SOC personnel, you may be missing a lot of valuable information. Regardless of the number of flows going into your SIEM, poor implementations and configurations may undermine the expected results of a solution that is traversing all log events as advertised.
• Denial of Threat Information. Tools are ingesting massive amounts of information and often, the quality of how the information is ingested, parsed and then reflected back to analysts is not effective for triaging.
• Many SOCs Use the Wrong Metrics. Many MSSPs are driven by metrics that make them appear that they are focused on service. Events mitigated, closed incidents, total alerts processed, and high risks addressed are just some of the examples of “wrong” metrics that fuel SOC today. These metrics are focused on demonstrating numbers in work that may not be useful or relevant for threat mitigation. Many of the events or incidents reflected as “closed” may not have been true positives and (most importantly) may not really pertain to an organization’s threat model.

 Introducing Organizational Threat Models

Threat models serve as a pattern that allow organizations to more easily identify a list of threats against a target. In an organizational threat model, the organizations serve as that target.

The model itself is intended to mesh together a custom threat library [against a target], along with associated threat motives, probable attack patterns, vulnerabilities that facilitate threat objectives, associated targets, and a list of countermeasures that help resist the effectiveness of attack patterns that support threats and their objectives. Notice that the items in bold represent factors that contribute in the calculation of risk.

This is an important distinction because the messaging of what is attacking a target is important to understand, particularly for those that are on the front lines of monitoring adverse alerts on a target’s infrastructure.

The organizational threat model essentially provides a way for context to find its way into the role of security operations. Beyond simply relying on tools to govern decisions, an organizational threat model provides the context that security analysts need to think about what is important based upon the likelihood, severity, and accuracy of both threat data and threat intel.

Organizational Threat Models as a Blueprint for Threat Intelligence

At this point, organizational threat models are not something that snap on as a plugin to a SIEM or threat intel subscription feed, but something that can be instead used to train SOC analysts on how to think in the trenches when triaging security events and incidents.

The organizational model will allow a team of SOC analysts to ask the following important questions:

1. Who is my enemy?

1. Understanding motives and likely threat actors is important because the majority of cybercrime is a copy, or rehash, of prior successful attacks. The current gap today is that most analysts do not actually know or understand who their attacker is and are forced to play detective on purely aggregated log information/threat intel, which doesn’t bring a lot of context. It’s important that a threat actor profile be developed so that, with an understanding of a company’s exposure, analysts can correlate to see if abuse patterns to company infrastructure, assets, and applications match threat motives that pertain to a threat actor profile.
2. The answer to this question is determined largely from threat intelligence feeds, advisories, industries CERT/ ISAC reports, and more. It allows for the analyst to match a developed threat actor profile to threat events worldwide that may be targeting the industry of a specific target(s).

2. What are they after?

1. Profiling an enemy naturally leads to answering the question of what this enemy wants. Many inexperienced security analysts may just be focused on data-based attack patterns, meaning attack patterns that are simply looking to exploit and pilfer data sources. Not all threat actors are looking for data; some may be looking for persistence and others may simply be looking to burn the whole place down.
2. Understanding what targets are in-scope based on trends, prior incidents, other threat advisories and intel is how these types of information can go from simply mass consumption of threat information that looks like noise to more selective filtering that leads to improved analysis. Knowing what to protect is a fundamental part of defense and it’s not fulfilled with simply a point-in-time discovery. Discovery of what is in-scope for monitoring and defense is an ongoing process that can be automated for virtual, physical, data, and application assets.

3. What trends have developed or are forming?

1. Trends have lifecycles. Many companies react to trends at different stages and today, there are virtually no SOC analysts that are thinking about trends. In the “trenches”, trend discussion is important because it makes the discussion more fluid in the minds of the analysts. Some companies may argue that trends are looked at via feeds or at higher management levels. Unfortunately, at this level conversations don’t become operationalized, which is why it’s important to allow for analysts to not only have news run within their operational centers but to allow them to converse on what trends may be forming in real-time or may already have formed and to discuss how this affects their fluid threat model.
2. It’s also important to note where trends come from, as there are many different types of trends. In threat analysis, you have economic trends as you do have trends in social engineering attack vectors. Often, the latter serve as obvious trends and are presented to analysts after the point that they are able to take a proactive stance. Security trends are largely based upon inquiries with analysts, surveys, annual reports, or other sources that assess market conditions. This means the activities that shape these trends have been occurring or are currently occurring, thereby forcing company operations centers to react versus foresee possible threats. The improvements of correlation engines to collate similar events on a corporate network does allow companies to start thinking more proactively, and this should be greatly encouraged within the trenches.

Building and Operationalizing a Threat Model for Defense

Organizational threat models can leverage a framework like the Process for Attack Simulation and Threat Analysis, or PASTA, to think about building a threat model in both an offensive and risk-based perspective. The idea of a risk-centric approach like PASTA is that it compels a threat modeling security champion to focus on the things that matter, where what “matters” are things that support the business in a way that is of critical or high importance. It leverages elements of a business impact analysis in order to help qualify the criticality of components that support an organization.

The simple steps to building a threat model using PASTA is to leverage the activities that are depicted in every stage of the threat modeling methodology. These stages are simplified below with a lite version of some exemplary artifacts, questions to ask and objectives to achieve. It is by no means comprehensive, but they do help to convey the idea of each stage number. It also correlates with sample tech genres to help depict how this can all come together for a threat-focused Security Operations team.

Conclusion

Over the years, VerSprite has found threat models to provide an excellent lens through which our threat intelligence group supports various clients. With a unique client profile and threat model in place, alerts can become a lot more contextualized, which allows us to truly be analysts versus simply looking at their roles as tool administrators or ticket managers for security tickets in a queue. I hope this write-up encourages others to consider threat models in their own respective SOCs for improved analysis and response by their blue teams.

PASTA Threat Modeling: The Process for Attack Simulation and Threat Analysis

VerSprite leverages our PASTA (Process for Attack Simulation and Threat Analysis) methodology to apply a risk-based approach to threat modeling. This methodology integrates business impact, inherent application risk, trust boundaries among application components, correlated threats, and attack patterns that exploit identified weaknesses from the threat modeling exercises.

Download the eBook