One of the unique innovations in the Stamus Security Platform is the feature known as Declaration of Compromise™ (DoC). We often write about DoCs on our website and in our blog posts, but we have not yet gone in depth to explain what a DoC is, what information it includes, and how it can improve the day-to-day work of an analyst using the Stamus Security Platform (SSP).

Without further delay, let’s get into it.

What is a Declaration of Compromise™?

In the simplest terms possible, a Declaration of Compromise (often referred to as a DoC) is a high-confidence and high-priority security event generated by Stamus Security Platform, signaling a “serious and imminent” threat on an asset. When SSP generates a DoC, it creates a data record that contains a substantial amount of meta data and associated artifacts that help the analyst understand exactly why it triggered and provide evidence for any investigation that may follow.

To fully understand what a DoC is, we have to go deeper into how one is triggered.

On any given day, the network traffic it inspects can cause a Stamus Network Probe to produce many millions of atomic detections, we generically call “events”. These events are not necessarily good or bad, they are simply a record of the many protocol transactions and other detected indicators that transpired on the network. Within that vast pool of events, there is a subset  of activity-related or security-related “alerts” triggered by IDS signatures. As with the events, not all alerts are inherently malicious. 

An example of this data can be seen in the screenshot below:

The Stamus Labs research team works around the clock to identify new threats and optimize their detection. Part of that work involves curating atomic detection methods that, when triggered, represent a high-confidence, serious, and imminent threat. These curated atomic detections form the basis for a Declaration of Compromise.

This research and curation has resulted in the taxonomy which Stamus Labs uses to identify hundreds of named threats that currently fall into one of 22 threat families supported by various detection methods in the Stamus Security Platform. 

SSP creates a “Stamus threat” event when one or more curated “methods” associated with the threat triggers a detection. These methods are individual indicators such as an IDS alert, or machine learning-based anomaly, or suspicious activity detection algorithm.  

SSP updates threat coverage from the Stamus Labs feed daily, and a summary of these updates are shared with customers in a weekly Threat Detection Update email. SSP users can see a list and descriptions of the currently covered threats and threat families on  the “Stamus Threat Research” screen, accessed from the “Coverage” link on the SSP left hand menu. See screenshot below.

A Declaration of Compromise is made the first time one of the  curated attack methods triggers against a single asset (host, user, or email account). At that point, SSP considers the asset “under attack,” and after capturing this “first seen” threat, it then begins to associate subsequent activities (e.g. other threats) and evidentiary artifacts (e.g. files, packet capture, transaction logs, alerts, etc) with that asset to create a complete picture of the attack.

In other words, a DoC signals an impacted asset is under attack and provides all the needed information on the threat(s) that are attacking it. For example, as seen below, there may be 6 different named threats attached to one or two assets, but this will produce 7 separate Declarations of Compromise. Each instance of  a threat on an asset is its own DoC, regardless of whether or not that asset is being impacted by multiple threats or if one threat is impacting more than one asset. SSP displays this information in a simple visualization.

What information does SSP capture with a DoC?

SSP users may investigate a Declaration of Compromise from three different perspectives.

The first is by viewing the attack method. To do this, a user just has to click on the threat from the DoC map within the operational center or navigate through the threat’s corresponding family from the “coverage” menu. Once the user is on the threat’s page, they can see a description of the threat, links to outside resources that could provide additional context — an incredibly useful feature for more junior analysts — and other basic top-level information on that threat.

Analysts are also able to see an overview of relevant information on the asset that the threat is impacting, the related metadata, and a timeline of that threat's activity on the network and progression through the cyber kill chain. By selecting the asset, the user is taken to the “host insights” page within the SSP threat hunting interface.

By maintaining the first seen and last seen state of any threat as well as the asset’s current kill chain phase, SSP is able to create detailed timeline of an attack, including lateral movements. This allows an analyst to quickly identify the progression of an attack and ultimately to visually trace back an attack to the “patient zero”. 

The second way an SSP user can investigate a Declaration of Compromise is by selecting the asset from the DoC map. This will bypass the threat coverage page and go directly to “host insights”. From this page, users will see all impacted assets and the relevant metadata needed to investigate the compromise. For a more detailed look at “Host Insights”, read our blog “Host Insight Transformation with IDS Alert Metadata”.

Finally, Declarations of Compromise can be viewed by selecting the relevant menu from the left-hand side navigation bar in SSP. This page will display a straightforward list of impacted assets and the threat(s) attached to it.

How do DoCs make work easier?

Declarations of Compromise help take the guesswork out of threat detection. Traditionally, an analyst would need to scour through mass amounts of alerts in order to find actionable information, and then there is still the task of aggregating those alerts with other actionable insights. DoCs do this automatically, enabling a significantly faster response.

SSP users are also able to configure their DoCs to trigger a notification or response to nearly any outside system using webhooks. This means that SSP can be configured to automatically send notifications to messaging platforms like Slack or Mattermost, create tickets in other systems, or trigger SOAR playbooks whenever a Declaration of Compromise is made. This can accelerate incident response and help ensure that threats are not lost in the noise of an alert stream.

The webhooks may also be used to integrate with an EDR, firewall or other system to trigger an automated response in those systems. For example an EDR may be instructed – via SSP webhook – to quarantine a compromised host when a DoC triggers against that host.

Importantly, users can also use threat hunting filters to create custom DoCs based on their organization’s specific needs. By filtering for specific types of alerts or leveraging network definitions, users can escalate what they uniquely consider to be “high-priority” in their organization. In this way, they can extend the capabilities  beyond the covered threats pre-identified by Stamus Labs researchers.

Conclusion

Declarations of Compromise are extremely useful to help enterprise security teams cut through the noise and focus on those truly serious and imminent threats. 

In addition, DoCs are great for providing additional context and structure to an analyst’s daily tasks. Ideally, the goal is to set up a fortified protection infrastructure so that attacks never make it to the DoC stage. They should, in theory, be rare occurrences most of the time. So, when a DoC does appear it makes it very easy for the analyst to quickly spot a serious and imminent threat, understand where it came from and what it is doing, and then respond accordingly. 

Finally, because DoCs are extremely high-confidence security events, the enterprise security team can use them to trigger a third party system - such as an EDR, firewall, or SOAR to respond automatically.

To stay updated with new blog posts from Stamus Networks, make sure to subscribe to the Stamus Networks blog, follow us on Twitter, LinkedIn, and Facebook, or join our Discord.