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.

Threat Modeling Methodology Stages

Stage 1: Know Your Business. Know What Supports Your Organization

1. How does your company make money?
   1. What are the online components that support revenue?
   2. What are the physical components that support revenue?
2. What does downtime mean over a unit of time? Over how many units of time do things get bad?
   1. How is continuity ensured for the components of your business?
3. How important is information/data to the business model?
   1. Is it confidential?
   2. Is it regulated?
   3. How is it protected?
4. Regulatory Risks
   1. What are they and what impacts do they bring in terms of go-to market, customer adoption, avoiding fees/ penalties

Stage 2: People – Process – Product. What, Where, and Who are they in the support of the Organization?

1. People
   1. Which roles are essential?
   2. Who has access to the keys to the kingdom?
   3. What external human resources play a critical role?
2. Process
   1. What operations are core to revenue generation and growth?
      1. What information is leveraged by these operations?
      2. How is this information safeguarded?
      3. Is this information regulated?
   2. What third party operations support the business?
      1. Consider Shared Services, Offshore Development, Business Process Outsourcing, and Foreign Manufacturing as some examples.
3. Product
   1. What proprietary products support current revenue cycles or growth?
   2. What infrastructure (e.g., CoLo, Managed Services, orCloud) supports these products?
   3. What third party vendors contribute to the product success?
   4. What information is managed by these products?
      1. What actions are taken by the organization to manage such information?
      2. What third parties or sub-processors are in play to support the information managed by the product/services of the Organization?

Stage 3: Process Mapping to Business Objectives.

1. Enumerate mission critical processes, products and serves and map these to People, Process and Product that play a role.
2. Consider the following as process to objectives are put together:
   1. Information flow
   2. Information ownership
   3. Regulatory laws (private/public) that are in scope
   4. Business use cases supported by all People, Process and Product components
   5. Inherent security controls that are in place
   6. Technology footprint that is being leveraged (e.g., MS, Linux, Oracle, Apache, Zigbee, iOS, React.js, AS/400, HID, etc.) by critical or high impact business processes

Stage 4: Threat Analysis.

1. Build a threat library for your organization. An immutable mnemonic like STRIDE will not do since threats are dynamic and vary greatly by industry and organization. Threat libraries are living lists so they should be updated on a regular basis. An example threat library for a consumer electronic manufacturing company may look like:
   1. Information Compromise
   2. Account Compromise
   3. Introduce malicious SDK or alter existing SDK
   4. Compromise device via Supply Chain
2. Note that the above are not attack patterns but threats. Stage 6 will begin to create attack libraries from frameworks like ATT&CK or CAPEC to map to what types of attack patterns could realize threats depicted in this stage.
3. Use the information and context from Stages 1-3 to shape how threat intel is meaningful. Context is everything and can more accurately help funnel threat intel in the right way for an organization. This is a many-to-limited mapping. Threat intel and data is plentiful, but custom develop threat libraries and the attack surface defined by Stages 1-3 can help funnel to more meaningful results.

Stage 5: Vulnerability Analysis.

1. What active weaknesses or vulnerabilities (vulns) do we have?
2. How do they help support the threat library that was created in Stage 4?
3. Build your threat patterns based on abuse cases that can alter your product/service use cases.
4. Focus on the vulns that could facilitate threat objectives. Build a vulnerability list and use vulns frameworks like CVEs to better map to exploits in the next stage.
5. Vulns don’t only come from vuln scanners. Consider human and physical weaknesses as well.

Stage 6: Attack Modeling – What attacks are going to realize the goals of the threats depicted in your threat library?

1. Build a customer attack library. A sample of one that correlates to the one above is as follows (these don’t have CAPEC IDs, but they definitely can and are suggested):
   1. Device NFC Man-in-the-Middle (for Information Compromise)
   2. Credential Stuffing Attack for Management Account Page
   3. DNS Spoofing Attack to Fake SDK Site for Users
   4. Hijacked embedded library in mirror sites for package inclusion in device
2. It’ll be important to test attack viabilities as this will factor in threat likelihood for the overall risk analysis.
3. Attack libraries are also fluid lists but should always be supporting the threats and threat objectives that were previously defined. This is a major difference as many security professionals use threats and attacks as interchangeable words, even though their meanings are different.

Stage 7: Residual Risk Analysis – What’s the net-net of where we should be concerned as an organization?

1. With a net of identified vulnerabilities and simulated attack patterns all supported by a customized threat library, an organization is able to successfully see the residual effects in a controlled environment. This allows a security operations team to discover the detective and reactive technologies that are most critical to triage in the event an incident occurred?
2. This stage allows for a more threat supportive and risk-focused alignment that allows threat data and threat intel sources to operate in a more concerted and strategic effort, as compared to simply leveraging tool-based alerts that are devoid of so much context.