Recently, Stamus Networks introduced outgoing webhook capabilities to its Stamus Security Platform. As we explained in an earlier blog post, this feature is more than simply a new mechanism to send network security alert logs to a third party system.

Stamus Security Platform (SSP) identifies, enriches, and logs numerous individual threat indicators using its broad spectrum of detection mechanisms, including signatures and behavioral anomalies. These detailed logs form the foundation for proactive threat hunting and incident investigation within the system. And while we refer to them as ‘alerts”, they are not - on their own - intended to trigger an immediate response.

With the launch of Scirius Threat Radar (now referred to as the Stamus NDR license tier of Stamus Security Platform), we introduced the concept of “Declarations of Compromise” which represent a new level of automated detection. These high-confidence threat events are associated with specific assets in the network and are tracked along the stages of the cyber kill chain. Declarations of Compromise include various forms of botnets, policy violations, phishing, remote access trojans (RAT), data theft, CnC, ransomware, lateral movement, advanced persistent threats (APT), exploit kits, and custom defined events. By definition, Declarations of Compromise have an ultra-low rate of false positives and can therefore be used to trigger an immediate response.

The webhook interface is designed to send notifications when these high-confidence Declarations of Compromise (DoCs) are detected or when they change stages in the cyber kill chain.

This powerful feature has two primary use cases:

Send notifications to a channel-based chat system such as Slack or Mattermost to alert security personnel when Stamus Security Platform has detected an attack milestone associated with a critical asset.
Trigger an action with an incident response (IR) or security orchestration, automation and response (SOAR) system such IBM Resilience, ServiceNow or TheHive when Stamus Security Platform has detected an attack milestone associated with a critical asset.

In this article, we focus on the second use case through an integration with a popular open source incident response system -- TheHive. As a result of this integration, security teams are able to automate the initial stages of their incident response and ensure that relevant data associated with the incident is available to help with the investigation.

Background on TheHive

According to the organization's website, TheHive is “a scalable, open source and free Security Incident Response Platform, tightly integrated with MISP (Malware Information Sharing Platform), designed to make life easier for SOCs, CSIRTs, CERTs and any information security practitioner dealing with security incidents that need to be investigated and acted upon swiftly.”

Development on TheHive Project began in 2014, and it has since become widely adopted throughout the world, particularly in Europe where a number of our customers are using it.

One of the key concepts embraced by the project is that of “observables.” Observables are artifacts associated with an incident that aid in an investigation. An IP address, a file hash, a URL, a domain are all examples of observables. TheHive collects these artifacts and enriches them using the Cortex analysis and response engine.

For example, Cortex may trigger Whois and Onyphe queries on an FQDN observable and use the results to create an entirely new set of observables. Thus providing the incident response team even more enrichment and context on a given case.

TheHive Observables and Stamus Security Platform

We know that observables are a key component of incident response within TheHive. Therefore when considering an integration with Stamus Security Platform, it is crucial that SSP delivers meaningful observables with any webhook notification for a Declaration of Compromise. Doing so is key to ensuring a timely incident response.

Before we explore that concept further, we must first decide what type of objects Stamus Security Platform should create in TheHive through the REST API. It turns out that the “Alert” object in TheHive is the ideal endpoint with which to connect the two systems. Alerts are presented to the user as notifications, the user can readily view the complete alert list, and any meaningful alert may be converted into an incident or added to an existing incident.

Conveniently, alerts may embed any number of related artifacts and it is therefore perfectly suited to receive all the context associated with a Stamus Threat.

The screenshot below shows the resulting observables for a single DoC event created using the template provided in the Stamus Security Platform documentation:

We can see the alert message and a series of attached artifacts containing all the information from the original DoC event. Specifically for this case, we have:

IP addresses (offenders and target)
FQDN (based on HTTP hostname used in the request triggering the alert)
Hashes
…

Webhook Message Template Definitions

The Stamus Security Platform webhook integration uses a powerful Jinja2-based template system which allows for logical construction using Python-like constructs to create complex variables. Stamus Networks has developed a number of ready-to-use templates for integrating with popular third-party systems including Slack, Mattermost, ServiceNow and TheHive.

Using the template, you may embed custom logic to extract the specific data elements (observables) you wish to include in the notification.

In the example below, you can see that we are configuring Stamus NDR to extract all the relevant fields and assign them a precise type when it encounters an SSL DoC containing a TLS sub-object:

Screenshot from 2021-01-13 14-20-19

By doing this in the template for all supported protocols, we are able to extract all available artifacts and provide them to TheHive for a more complete insight and more efficient incident response.

The screenshot below shows how this configuration -- including the template set up -- may be performed in the SSP management interface:

Looking further at the above example, when Stamus Security Platform detects a Trickbot-related DoC event containing a TLS protocol transaction, the following observables are included in the result.

Note: in the above screenshot, the eye icon in the left indicates that the observable has been observed in an existing case.

Stamus Security Platform allows you to choose whether to create a webhook to notify TheHive when a new DoC is first detected on an asset or when an already known DoC has advanced stages along the kill chain. And because events may arrive asynchronously, Stamus Security Platform also provides a webhook for any changes in the kill chain phase of a known DoC - so you won’t miss an event that would come late.

As we’ve seen in this example, integrating Stamus Security Platform with an IR or SOAR system via webhooks, can bring many benefits beyond a simple notification, including powerful automation and enrichment of the incident records. And the powerful template system provided by Stamus Security Platform enables substantial artifacts (observables) to be conveyed with each notification.