In part one of this series we introduced the notion of risk-based extended detection with SecureX – the idea that a user can prioritise detections into incidents based on their idea of what constitutes risk in their environments and then extend those detections with enrichments from other products. In subsequent posts we are diving deeper into different Cisco Secure detection technologies and how their respective detections can be prioritised, promoted to SecureX as incidents and extended. In this post we will look at detections from Cisco Secure Endpoint: what makes them relevant and important, the new automatic promotion feature and the triaging of endpoint events in SecureX.
What Makes an Endpoint Detection?
We’re digging into Endpoint Detections first for a Reason: Endpoint Detection and Response (EDR) solutions, like Cisco Secure Endpoint, have been central to Security Operations and Incident Response teams for years. In fact, when performing research with many of our security operations customers earlier this year we found that a majority of customers treat detections from their EDRs as their highest fidelity level and automatically put endpoint derived detections at the front of their incident response queues.
There are multiple reasons for why Endpoint Detections are so valuable to SecOps:
◉ Endpoint Detections are high fidelity:
◉ The nature of residing on an endpoint allows the detection system to be accurate in describing what is being seen. The observables and Indicators of Compromise (IOCs) in an endpoint detection (ex. Filename, file hash, hostname, URL) are typically accurate in what they are observing and explaining
◉ Endpoint Detections are explainable:
◉ Many of the detections generated by endpoint solutions link back to a file hash and threat intelligence with an explanation of what that file is and does, what the risk is to the asset that it is on, and the level of risk to the organization as a whole.
◉ Existence of Endpoint data itself provides insight:
◉ This intuitively obvious statement derives from the fact that the reason there is an endpoint detection in the first place is that it came from an agent that was installed on an owned asset. You don’t tend to go to the effort of installing and managing agents on unowned or non-valuable assets and on top of that in the very nature of installing the agent the asset became more valuable.
Just because an EDR can detect something, doesn’t mean that all detections are equal: understanding what the threat is, its risk to the device it’s on, the risk to the data on the device and the risk to the rest of the organization all are factors in determining how important the detection is. One of the most common, yet most overlooked components of what makes an endpoint detection important is security policy, for example forbidden applications. Applications can be forbidden for numerous reasons, from internal policy to government regulations, but those custom detections can be the most informing and actionable to a security operations team. In the example Simple Custom Detection from Cisco Secure Endpoint below we can see adding the SHA-256 of tor.exe to a simple custom detection on the left and the occurrence of that detection on the right.
Figure 1 – Configuration of Simple Custom Detection to detect tor.exe
Figure 2 – Occurrence of detection of tor.exe
In the detection occurrence figure above, at the top right, you might notice the label “Medium” indicating the severity of the threat detected. The notion of Severity was introduced to Cisco Secure Endpoint in the fall of 2018, providing a new setting for an analyst to leverage in prioritising events.
In Cisco Secure Endpoint there are four severity tags that can be applied to a given event; these severity tags are assigned by Cisco threat research team based on the global threat landscape knowledge and are continuously tuned to maintain a high level of accuracy. Since their introduction, we have found the below security events to be very useful in allowing Cisco Secure Endpoint customers to prioritise events and sort their inboxes using the severity tag and what it indicates:
◉ Critical – involving known malware families identified with very high precision
◉ High – generic malicious behaviors and generic malware, not attributed to a particular family
◉ Medium and Low – possibly malicious or risky detections, that could indicate about a potential compromise or degraded security posture
A new feature of both Cisco Secure Endpoint and Cisco
SecureX is the ability to have Critical and High Cisco Secure Endpoint events automatically promoted as Incidents in Cisco SecureX Threat Response, allowing for the extension and prioritisation of Cisco Secure Endpoint detections.
Extending an Endpoint Detection:
In addition to the ability to automatically promote Critical and High Secure Endpoint events into Threat Response as Incidents is the creation of the notion of a High Impact Incident in Threat Response. The High Impact Incident List, an example seen below, are Incidents that are perceived to be of the highest criticality and importance to a security operations center. You will note in the screenshot below that there are two Incidents that appear in the High Impact Incident List and an additional 6,063 as Other Incidents: this is the process of identifying those incidents that are deemed to be the most critical, highest risk to the organization. In its first iteration the incidents that make their way onto the High Impact Incident list are those that are promoted from Cisco Secure Endpoint. As previously mentioned, we’ve found that Security Operations Centers tend to prioritise endpoint detections for numerous reasons.
In the above figure you might notice that labels “Enriched” and “Enriching” next to the two Incidents in the High Impact Incident list. Another recent enhancement is the automatic enrichment (or extension) of the incidents that are in the High Impact Incident List. What is happening behind the scenes is Cisco Threat Response is searching all integrated products for additional details about the attributes in the incident.
As we explored in the first part of this series, in the Orient stage of the OODA loop you are enriching or extending a detection. Potentially more important than the details about the file involved in the endpoint detection are the external factors such as:
◉ What role does this device have in my organization?
◉ Who is the user on the device?
◉ What other devices might be involved in the incident?
◉ What external knowledge is there of the threat?
◉ How often is this threat seen?
And, any other detail that might be used to assess the business risk of the detection.
By automatically enriching these High Impact Incidents with data from other integrated products we are shortening the Orient step portion of the OODA loop considerably, speeding up that mean-time-to-respond.
Once it has finished enriching, if we click on the top Incident in the High Impact Incident list and then on Linked References, we can see the Snapshot that was created during the enrichment process and that there were nine different observables investigated across multiple data sources integrated with SecureX Threat Response.
Opening the automatically created Snapshot takes us to an investigation in Cisco SecureX Threat Response. We can quickly see that not only the original device – w7-hoser – is involved but also another device on the network – w7-darrin – and that both have communicated to the same known malicious external IP addresses. If you look closely at the SHA-256 in the centre of the image you might notice that it is the same SHA-256, for tor.exe, that we used earlier to create a Simple Custom Detection.
From here we have a wealth of information for a given High Impact Incident:
◉ We know the hosts involved
◉ We know they are using banned applications
◉ We know some external threat intelligence
And, we can use that information to quickly make a decision that would frame our response action, quickly tightening our OODA loop.
In this post we’ve reviewed some concepts behind what makes an endpoint detection, why they’re valuable, and how to leverage Cisco SecureX to automatically extend the detection and create a High Impact Incident in SecureX Threat Response. Future posts in this series will explore the different integrated products in SecureX and how their detections can be promoted, enriched, and extended in SecureX. In the next post in this series, we will begin with the automatic promotion and triaging of behaviour detections from Cisco Secure Network Analytics into Cisco SecureX.
Source: cisco.com
Posts
