Existing systems that aggregate network security alerts and metadata do not properly detect and expose today's multi-stage attacks and the assets that are under attack. These systems produce too many alerts and not enough insight. A bold new approach is needed to shift from a classic network threat detection model to a more valuable solution providing truly actionable indicators.
The systems that manage events coming from network threat detection tools typically aggregate events based on the source, destination, or other common factors present in each event. This results in a more condensed display of information that allows for a more straightforward analysis.
The problem with this method is that it fails to address the current attack mechanisms, which are multi-stage. Attacks can begin by exploiting a system vulnerability, then installing on the system, perhaps moving laterally within the network, and communicating with the command and control server to collect and perform desired actions on the target.
The cyber kill chain
This step-by-step approach has been modeled in the cyber kill chain (https://en.wikipedia.org/wiki/Kill_chain). The model has several advantages for defenders who need to know when an immediate response is needed. For example, if an attack has moved to one of the final stages in the kill chain such as “command and control”, the reaction must be immediate and comprehensive.
Unfortunately, simple event aggregation by metadata doesn’t allow us to model the cyber kill chain and assets-under-attack. For example, the initial target in an attack may be the packet’s destination IP when a remote command execution takes place. But the next step will involve the download of a malicious payload from the target. In this case, the source IP of the connection will be responsible for the download. But the download server in most cases is on a different IP than the attacking one, so simply aggregating threats by IP address will not help - even if we accurately map source and target IP. This is further complicated by the fact that the victim IP addresses often change due to user mobility and VPN usage.
As the above example illustrates, an additional abstraction is needed or we won’t see the exploitation initiated from one server and the command and control beacon as being part of the same process.
Because of this limitation, we at Stamus Networks adopted a threat-based and asset-based approach to model the progression of attacks in the cyber kill chain and thereby help clarify the severity of a given threat. And earlier this year, we brought this approach to market when we introduced Scirius Threat Radar (note: this is now referred to as the Stamus Security Platform - NDR license tier).
Alert noise reduction
One of the primary benefits of this approach is significant noise reduction.
For example, when detecting a communication between malicious software and a control server, conventional systems will generate repeated alerts that pollute the console used by the SOC for analyzing events. But in fact, the communication is a single event spanning over time.
In this situation, our Stamus Security Platform (SSP) logs a single threat event - we call it a Declaration of Compromise™ (DoC) and the users sees only that the malware appeared on the server in the Command and Control phase of the kill chain. The analyst also sees the specific time that the communication was detected and when it was last seen. Note that while all those repeated noisy alerts are suppressed, they remain available in the system logs as important corroborating evidence for the incident investigation.
This approach completely changes how security teams view individual events drawn directly from network traffic, by moving to a whole new way of identifying incidents. It is now possible to be warned about critical events such as a new threat detected on an asset or a change in the progression along the kill chain. The great news - it will warn analysts only when something meaningful happens on the network.
High-fidelity threat event notifications to trigger response
In the old model, you would not dare to sign up to receive a notification each time one of these noisy alerts is triggered. But when you reduce the number of events to only a handful of very high-fidelity threat events - Declarations of Compromise - you can begin to consider signing on to notifications again.
Recently we developed a webhook notification system to communicate these very serious threat events identified by the Stamus Security Platform to other platforms used by security professionals.
For example, one might choose to send a notification to a Slack channel that Emotet has moved to the “reconnaissance” phase. And because SSP does not send messages for every single network event that does not align with changes in the kill chain, the system will not generate a noisy stream of alerts.
Thanks to the powerful template system used in Stamus Security Platform for webhooks, we can also send notifications of these high confidence threat events (DoCs) to trigger an automated response or an incident investigation in a security orchestration, automation and response (SOAR) solution.
See screenshot below of a notification in The Hive.
And in ServiceNow
Our customers have found the high-fidelity threat events (DoCs) created by Stamus Security Platform to be an extremely powerful solution that allows them to focus only on the real events that matter.
And because webhook notifications can be delivered directly to the automated response and collaboration platforms security professionals use for their daily operations, they are able to easily integrate the solution into their existing workflow.
With the DoC detection and webhook integrations in Stamus Security Platform, organizations can more quickly identify the critical active threats targeting their assets and accelerate incident response.
Learn More
If you are interested in learning more about optimizing your network security with a network detection and response from Stamus Networks, please contact us today.
