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.
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:
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
or similar) that you can optionally use to categorize those objects. For example,
: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.
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.
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.
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 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:timeproperties 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:threatnodes can be linked to a single threat group.
Threat clusters are linked to threat groups via their
You can optionally:
categorize threat clusters using a type taxonomy.
assign a relative sophistication score to a threat cluster.
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
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.
:_vertex:threatintel:isthreatextended 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.)
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
value is still used to tag nodes associated with Sparkling Unicorn. The threat cluster is linked to the
threat group via its
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.
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
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 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 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
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.
:_vertex:threatintel:istoolextended 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.)
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
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:techniquenodes, and use the MITRE ATT&CK framework; or
use some combination of your own techniques and existing techniques that meets your needs.
You can optionally:
categorize techniques using a type taxonomy.
assign a relative sophistication score to a technique.
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).
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
nodes that can optionally be set, if they apply to the vulnerabilities you are tracking.
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
:org) to the primary contact for the threat group (i.e., the
:hqcontact from the threat group’s
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).
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 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.
You can optionally categorize alerts using a type taxonomy.
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.
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 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.
You can optionally categorize compromises using a type taxonomy.
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.
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 refers to criteria commonly used to categorize the interests or motivations of threats.
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.
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
:namesproperties 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).
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.
You can optionally categorize goals using a type taxonomy.
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.