User Guide - Threat Intel Model

Synapse represents common threat intelligence components and relationships using a combination of objects (nodes), tags, relationships (light edges), and taxonomies (ways to categorize different objects or activity).

This guide provides an overview of some of those elements (specifically, tags and taxonomies), and detail about individual threat intelligence objects and how those objects should be used in Synapse.

Tip

Use the Synapse Data Model Explorer (located in the Help Tool) to view detailed information on threat intelligence data model elements.

Where possible, Synapse Power-Ups that ingest data from third-party sources will automatically populate various elements in the threat intelligence model. Threat clusters (risk:threat) and tools (risk:tool:software) are the most common objects created. However, Power-Ups may create other elements depending on the data provided by the specific vendor.

In addition, you can optionally use the mitre.attack.translate command (from the synapse-mitre-attack Power-Up) to take an inbound MITRE ATT&CK Group, Software, or Technique node (or set of nodes) and translate them into corresponding threat clusters, tools, and/or techniques.

This guide includes the following sections:

Background

Tags

Tags in Synapse are often used to record assessments. You can add a tag to a node to indicate it is associated with a malware family or a threat group (or both!), or to indicate that the node represents the use of a particular TTP.

In Synapse, some threat intelligence components (such as threat clusters, tools, and techniques) have an associated tag (:tag) property. This allows you to:

  • apply the tag to other nodes to provide context / situational awareness for analysts; and

  • associate the tag (via the :tag property) with a node. The node allows you to record additional information (using the node’s properties) about “what” the tag represents.

For example, you can apply a tag such as rep.microsoft.nobelium to indicators of compromise (such as inet:fqdn nodes) to associate them with the threat group Microsoft calls NOBELIUM. You can use the associated threat cluster (risk:threat) node to record other names Microsoft states also refer to the same threat, or Microsoft’s assessed location / country of origin for the threat.

Similarly, you can apply a tag such as cno.ttp.persist.registry.run to a node (e.g., it:exec:reg:set) that shows malware setting a registry value for the Windows run key to maintain peristence. The tag provides “evidence” of the technique’s use in a specific instance; the associated ou:technique node can record a description of the technique and optionally link the technique to an associated framework (such as a technique from MITRE ATT&CK).

Tip

Many organizations start recording and tracking threat intelligence-related assertions using only tags. This allows a team to initially test out tag trees and decide how to best record their assertions. This is a great approach that allows you to take advantage of the flexibility of tags while you settle on a structure that works best for you. Once your tag structure is more well-defined, you can “link” those tags (via the various :tag properties) to their associated forms.

Organizations that prefer to use the full threat intelligence model from the start can of course do so!

Taxonomies

In Synapse, a taxonomy is a property type that supports the use of dot-separated (.) string elements to form a hierarchical structure (similar to tags).

Many of the threat intelligence model elements described below include a property (usually named :type or similar) that you can optionally use to categorize those objects. For example, risk:attack includes a :type property that can be used to categorize different types of attacks.

Synapse does not have any pre-configured taxonomies, just as there are no pre-configured tags. Organizations can choose whether or not to use taxonomies, and can define taxonomies that best meet their analysis needs. A taxonomy can be a simple “flat” set of categories or can include sub-categories using a dotted notation.

Tip

Some Synapse Power-Ups create threat intelligence objects with taxonomy properties. We want to capture and take advantage of third-party data! But we also recognize that the objects (such as industries) or taxonomies (such as compromise types) provided by an outside source may not match an authoritative set of objects or categories that you define within your organization.

In these cases, the object’s taxonomy property (such as risk:alert:type) may be set to a value that includes the vendor name and a vendor-provided category (if there is one). You can then query or filter on the taxonomy value to distinguish objects from different sources, and modify those objects (if necessary) to map or merge them into your authoritative structure.

Threat Intelligence Model Elements

The components used to represent threat intelligence-related activity primarily reside in the following portions of the Synapse data model:

  • risk:* (“risk” model): threat clusters, malware families, alerts, attacks, vulnerabilities, compromises.

  • ou:* (“organization” model): organizations (threat groups and targets / victims), goals, campaigns.

  • it:* (“information technology” model): software / malware.

Each of these elements is described below, using the broad categories used in the vertex-threat-intel Workflow. Note that while many of these elements are used for threat intelligence modeling and tracking, they are not limited to a threat intelligence use case. “Attack” could represent a physical attack such as a break-in just as it can represent a phishing or privilege elevation attempt.

Note

In the Synapse data model, some objects (nodes) have an extensive set of secondary properties. Recall that in Synapse, secondary properties are optional in most cases (setting a secondary property value is only required if it is directly based on the node’s primary property - and in these cases, Synapse will set the property for you).

As an example, an attack (risk:attack) node gives you the option to set properties to record everything from the relative sophistication or severity of an attack to a compromise or campaign that the attack is part of. But of course you can:

  • only use those properties that matter to you (e.g., maybe you have no need to track attack “severity”);

  • only record as much (or as little) information as you have.

You can always return and add information when you obtain it or when it becomes useful to track.

Threats

In Synapse, threats are individuals or groups that carry out malicious activity. Threats are represented as:

  • Threat clusters: preliminary or not yet well-defined sets of indicators and activity.

  • Threat groups: more well-known, well-defined, or positively attributed entities.

Threats typically start out as threat clusters that may eventually “evolve” or “graduate” into more authoritative, high-confidence threat groups.

Threat Clusters

Threat clusters are represented by risk:threat nodes with an associated :tag property. A threat cluster is associated with a reporting organization. This allows you to optionally track threat reporting by other organizations alongside the threats that you track - you can identify overlaps or inconsistencies, while keeping the reporting by different organizations separated.

Threat clusters are used:

  • To link (cluster) new activity, unattributed activity, or lower-confidence activity that may eventually link to a to a known threat with additional data. (Some organizations refer to these as “unknown” (UNC) groups, “temp” groups, or some other naming convention that indicates their “preliminary” status.)

  • To record and compare threat reporting by different organizations.

Threat clusters may start out small - only a handful of associated IOCs. They are meant to be somewhat ephemeral and flexible as they grow, merge, and are eventually either linked to (or “promoted” to) a more well-defined, authoritative threat group. For example:

  • If you are tracking multiple threat clusters that you decide should be merged, one way to “merge” them is to keep the existing cluster, but link them to a single threat group (described below). This method allows for easier “untangling” if you later decide one cluster should not actually be part of the group.

  • You can also “formally” merge clusters by deprecating one cluster and replacing its tags with those of the cluster it is merged into. The cluster’s :merged:isnow and :merged:time properties can record these changes.

  • A threat cluster that becomes sufficiently mature without overlapping with or linking to other clusters may be “graduated” and linked to its own authoritative threat group.

  • If you are using threat clusters to track reporting from different organizations, you can use entity resolution to decide that threat activity reported by different companies is actually “the same group”. These different risk:threat nodes can be linked to a single threat group.

Threat clusters are linked to threat groups via their risk:threat:org property.

Tip

You can optionally:

  • categorize threat clusters using a type taxonomy.

  • assign a relative sophistication score to a threat cluster.

Threat Groups

Threat groups are represented by ou:org nodes (a threat group is an organization just like any other).

A threat group can represent:

  • An identified real-world entity responsible for a set of threat activity (e.g., “Unit 74455 of the Russian Main Intelligence Directorate (GRU)”).

  • A well-defined threat, even if the specific entity behind the threat is unknown (e.g., “APT34”, “Raspberry Robin”, “Void Balaur”).

Threat groups are meant to be more mature, well-scoped, and authoritative compared to threat clusters. One or more threat clusters can be associated with a threat group via each cluster’s risk:threat:org property.

Tip

You can optionally:

  • categorize organizations using a type taxonomy. For organization taxonomies, keep in mind that organizations can be companies, governments, teams, clubs, etc. - not “just” threats.

  • use the :_vertex:threatintel:isthreat extended property (set to true) to explicitly note that the organization has acted maliciously or is associated with threat activity and is considered a threat for threat intel purposes. (Note that any threat groups created through the Workflow will have this property set to true automatically.)

Note

Threat groups (ou:org nodes) do not have an associated tag property. To annotate or track IOCs or other objects associated with a threat group, use the tag associated with the group’s primary threat cluster.

For example, if Vertex created an authoritative threat group (ou:org) for the group Sparkling Unicorn, the threat group would still have an associated threat cluster (risk:threat) to represent Vertex’s original tracking of the cluster before it was “promoted” to a threat group. The threat cluster’s :tag value is still used to tag nodes associated with Sparkling Unicorn. The threat cluster is linked to the threat group via its risk:threat:org property.

TTPs

TTPs - tactics, techniques, and procedures - are the methods used to conduct an activity. The most common TTPs we want to record for threat intelligence purposes are the use of:

  • Tools: malware or software used maliciously.

  • Software: known software or a well-defined malware family.

  • Techniques: a specific process or methodology.

  • Vulnerabilities: weaknesses with the potential to be exploited.

Tools

A tool is represented by a risk:tool:software node with an associated :tag property. A tool is associated with a reporting organization. This allows you to optionally track tools reported by other organizations alongside the tools that you track - you can identify overlaps or inconsistencies, while keeping the reporting by different organizations separated.

In Synapse, a tool is any code used for malicious purposes. Code is not inherently “malicious” or “benign” - those terms indicate how the code is used.

A tool is used:

  • To represent a named / tracked “malware family” (“Sednit”).

  • For legitimate software used for malicious purposes (“Mimikatz”).

  • To record and compare malware or tool reporting by different organizations.

Tools may eventually be associated with a more well-defined, authoritative piece of software / software family. For example:

  • If you are using tools to track reporting from different organizations, you can use entity resolution to decide that malware or software reported by different companies is actually “the same”. These different tool nodes can be linked to a single software node.

  • If you identify the source for a tool, you can link different organizations’ repoprting about the tool to an authoritative software node for the tool.

Tools are linked to software via their risk:tool:software:soft property.

Tip

You can optionally:

  • categorize tools using a type taxonomy.

  • assign a relative sophistication score to a tool.

  • specify an availability taxonomy for a tool.

Software

Software is represented by it:prod:soft nodes (“malware” and tools are both software - executable code. Vertex often uses the term “code families” to describe both “malware families” and known tools or software).

Software can represent:

  • A commercial software application or operating system (iOS, Microsoft Exchange, Adobe Acrobat Reader).

  • A tool or utility (Mimikatz, PuTTY, ADFind).

  • A program or executable that is part of a larger software package (Windows cmd.exe).

  • A malware family (Sedint, Trickbot, Gh0st).

Software nodes are meant to be more mature, well-scoped, and authoritative compared to tools. One or more tools can be associated with a software node via each tool’s risk:tool:software:soft property.

Tip

You can optionally:

  • categorize software using a type taxonomy. For software taxonomies, keep in mind that software can be operating systems, utilities, tools, binaries, scripts, etc. - not “just” malware.

  • use the :_vertex:threatintel:istool extended property (set to true) to explicitly note that the software has been used maliciously and is considered a tool for threat intel purposes. (Note that any software created through the Workflow will have this property set to true automatically.)

Note

Software nodes (it:prod:soft) do not have an associated tag property. To annotate or track IOCs or other objects associated with a software family, use the tag associated with the group’s primary tool.

For example, if Vertex created an authoritative software family (it:prod:soft) for the Redtree malware family, the software would still have an associated (primary) tool (risk:tool:software) to represent Vertex’s original tracking of the tool before it was formalized as software (a code family). The tool’s :tag value is still used to tag nodes associated with Redtree malware. The tool is linked to the software via its risk:tool:software:soft property.

Techniques

Techniques are represented by ou:technique nodes that have an associated :tag property. A technique is a methodology used to perform some activity. Techniques can be defined broadly according to need or use case. The tag is used to annotate nodes that represent or provide evidence of the use of the associated technique.

Techniques in Synapse (ou:technique nodes) are usable across any discipline (not “just” threat intelligence) and are not restricted to any particular framework. They can be defined and used wholly on their own, but can also be “mapped into” or “generated from” existing frameworks, if desired.

Because of the widespread use of MITRE ATT&CK within the threat intelligence and security communities, ou:technique nodes have a :mitre:attack:technique secondary property that allows a technique to be mapped to a specific ATT&CK technique.

This gives you the flexibility to:

  • define and use your own techniques, independent of any framework; or

  • translate the ATT&CK techniques one-for-one into ou:technique nodes, and use the MITRE ATT&CK framework; or

  • use some combination of your own techniques and existing techniques that meets your needs.

Tip

You can optionally:

  • categorize techniques using a type taxonomy.

  • assign a relative sophistication score to a technique.

Vulnerabilities

A vulnerability is represented by a risk:vuln node. A vulnerability is a weakness that may be exploited to achieve a goal (such as a successful attack).

Tip

Vulnerabilities in Synapse are usable across any discipline and are not restricted to any one analytical framework. They can be defined and used wholly on their own, but can also be “mapped into” or “generated from” specific frameworks, if desired.

That said, there are a number of frameworks that attempt to track, rate, or categorize various computer- and technology-related vulnerabilities. (Examples include Common Vulnerabilities and Exposures (CVEs), CISA’s Known Exploited Vulnerabilities (KEV), the Common Vulnerability Scoring System (CVSS), and the Common Weakness Enumeration (CWE) system.)

As such, many of these industy-specific frameworks have associated secondary properties on risk:vuln nodes that can optionally be set, if they apply to the vulnerabilities you are tracking.

Some Synapse Power-Ups (such as synapse-nist-nvd or synapse-us-cisa, as well as some Power-Ups for third-party data sources) support the automated ingest of vulnerability data.

Activity

Activity is the set of events that can represent malicious actions. Activity types vary in scope.

Activity can be attributed to one or more threat clusters and / or to a threat group:

  • To attribute an activity to a threat cluster, apply the threat cluster’s tag to the associated activity node.

  • To attribute an activity to a well-defined or authoritative threat group, set the associated property on the activity node (typically :attacker or :org) to the primary contact for the threat group (i.e., the :hq contact from the threat group’s ou:org node).

Tip

Unless you have both high-confidence in your threat groups and your attribution assessment, most attribution will be done with threat clusters and tags. As always, tags give you greater flexibility to update your assessments (in contrast with updating secondary properties).

In addition:

  • Activities can have associated TTPs (tools / techniques / vulnerbilities) that were used in the activity, if applicable.

  • Attacks, compromises, and campaigns can have an assessed goal or goals.

  • More acute activities can be optionally linked to broader activities with which they are associated:

    • An alert can be linked to an attack.

    • An attack can be linked to a compromise or campaign.

    • A compromise can be linked to a campaign.

Alerts

Alerts are represented by risk:alert nodes. An alert is a notification about an event or condition. Alerts are typically generated by a sensor or application. However, actions such as a third-party contacting you to inform you of a breach can also be considered alerts.

Tip

You can optionally categorize alerts using a type taxonomy.

Attacks

Attacks are represented by risk:attack nodes. An attack is an attempt to conduct malicious activity. Broadly speaking, an attack can be thought of as an action taken against a target (host, person, organization) without the target’s consent.

Attacks represent specific (often highly tactical) actions. All of the following can be considered attacks:

  • A phishing email sent to a user. (Note that a phishing email sent to ten recipients represents ten different attacks, each with its own chance of success, depending on whether a particular recipient opens the email / attachment / link.)

  • Exploit code run against a particular host or application.

  • An attempt to log in to a system with stolen credentials.

The level of detail you wish to capture as attacks will vary based on your analytical needs, visibility, etc.

  • Some organizations may only model attacks to represent “initial attacks” (initial compromise attempts) to identify metrics such as how many attempted attacks were actually successful (e.g., the effectiveness of an organization’s defenses).

  • Other organizations may choose to model threat actor activity (particularly within a victim environment) as a detailed sequence of attacks in order to accurately represent threat actor behavior. This detailed representation can be used for purposes such as evaluating the effectiveness of detection / mitigation strategies, or identifying patterns of threat actor behavior.

Tip

You can optionally:

  • categorize attacks using a type taxonomy.

  • assign a relative sophistication score to an attack.

  • specify whether an attack was successful, if known.

  • specify whether an attack is assessed to be targeted.

  • “chain” individual attacks to represent a series of actions executed in a particular order.

Compromises

Compromises are represented by risk:compromise nodes. A compromise represents a successful (by definition) attack against a target. A compromise records summary information about an incident, including time, duration, or information about loss or impact from the compromise.

Detailed information about a compromise can optionally be recorded in a set of attack nodes associated with the compromise.

Tip

You can optionally categorize compromises using a type taxonomy.

Campaigns

Campaigns are represented by ou:campaign nodes. A campaign is a broad set of activity carried out by a threat in pursuit of one or more goals.

Campaigns (and associated goals) often represent a threat actor’s strategic objectives; these objectives can be defined at varying levels of granularity according to needs.

Both attacks and compromises can be associated with a broader campaign.

Tip

You can optionally:

  • categorize campaigns using a type taxonomy. For campaign taxonomies, keep in mind that campaigns represent a broad set of actions in pursuit of any organizational goal - not “just” threat activity. Marketing campaigns, political campaigns, business strategies, military operations, etc. can all be considered campaigns.

  • record certain metrics, such as cost or budget (if known), as well as metrics for goals that have a numeric target (such as population or revenue).

Targeting

Targeting refers to criteria commonly used to categorize the interests or motivations of threats.

Industries

An industry (ou:industry) represents a type of activity that an organization engages in or operates within. An organization (ou:org) can be associated with one or more industries.

Tip

You can optionally:

  • categorize industries using a type taxonomy. This allows you to create industries and sub-industries based on the taxonomy you choose.

  • use an industry’s :name and :names properties for entity resolution to cross-reference similar names that different reporting organizations use for what you consider to be “the same” industry.

  • create industries based on common industry classification systems. Industry nodes include secondary properties that allow you to map directly to systems such as the North American Industry Classification System (NAICS), the International Standard Industrical Classification of all Economic Activities (ISIC), or the Standard Industrial Classification (SIC).

Goals

A goal (ou:goal) represents a particular objective to be achieved. Both threats (threat clusters, threat groups) and activities (attacks, compromises, campaigns) can have goals.

You can define goals according to your needs and at varying levels of granularity - for example, the specific goal of an individual attack will likely be very different from the goal of a broad campaign; which may differ from the general goals of a particular threat.

Tip

You can optionally categorize goals using a type taxonomy.

Organizations

An organization (as represented by the ORGANIZATIONS primary tab in the Selection Panel) represents an entity (ou:org) that is targeted or compromised by one or more threats.

It is possible for an organization to be both a threat group and a targeted organization. The ORGANIZATIONS tab focuses on the victim or target aspect, while the THREATS > THREAT GROUPS tab focuses on the attacker aspect.