Relevant and Extended Detection with SecureX, Part Four: Secure Cloud Analytics Detections – Cisco Blogs

In part one of this  Relevant and Extended Detection with SecureX series, we introduced the notion of risk-based extended detection with Cisco 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’ve been diving deeper into how different Cisco Secure detection technologies can be prioritised, promoted to SecureX as incidents and extended to accelerate the Observe, Orient, Decide, Act (OODA) loop of the security operations center. In this post, building upon our understanding of a behaviour-based detection from part three, we will look at detections from Cisco Secure Cloud Analytics; and when/how to promote them to SecureX as incidents and how to leverage and extend the detections in SecureX.

What is a Secure Cloud Analytics Alert?

Much like the on-premises Cisco Secure Network Analytics (discussed extensively in part three), Cisco Secure Cloud Analytics is also a Network Detection and Response product whose detection are predominately network behaviour based – meaning that Secure Cloud Analytics uses telemetry to build analytical models of your environment and will generate alerts when certain behaviour conditions are observed. Unlike Secure Network Analytics, however, Secure Cloud Analytics is a Software as a Service (SaaS) delivered product meaning that all data storage and analytics is happening in a Cisco hosted cloud offer, with the only on-premises footprint being a sensor to collect on-premises network telemetry and forward the data to the cloud.  By virtue of being a cloud offer Secure Cloud Analytics is also able easily to consume telemetry and logs from other cloud services that are difficult for on premises products to access. These additional telemetry sources can facilitate behavioural analytics in additional domains, such as cloud-native application security.

The principles of behaviour detections discussed in part three extend to Secure Cloud Analytics; an algorithm watches for a specific behaviour condition of an entity and will trigger a behavioural observation when that condition is observed. An Alert, in Cisco Secure Cloud Analytics, is active notification of the observation of behavioural conditions. Alerts can be enabled, disabled, prioritised, and tuned according to subnet sensitivity.

The Secure Cloud Analytics alert system also utilises a “helpfulness” rating for the alerts it produces. Illustrated in the screenshot of an alert occurrence below, after clicking “Close Alert” the first question in the workflow is “Was this alert helpful?”  Striving to keep our helpfulness metric above 95%, this helps to address one of the largest challenges of behaviour-based alerts;  namely that they describe that a behaviour was observed and thus by definition all observations are true positives. Relevance and meaning to the business and security operations are not strictly speaking captured in the observation.

One of the features I really like about an alert in Secure Cloud Analytics is that where applicable the alert details contain the Mitre ATT&CK Tactic and Technique that the observed behaviour maps to. Over the last few years Mitre ATT&CK has become a valuable tool for Security Operations centres to understand attackers’ tactics, techniques and procedures (TTP) and has become very helpful in building targeted defenses against specific threats actors and/or their modes of operations. By including the TTP label in the alert details, operators can use that data set to help prioritise alerts from Secure Cloud Analytics.

Creating an Incident from a Secure Cloud Analytics Alert

Once integrated with Cisco SecureX you Alerts in Secure Cloud Analytics can be manually promoted to incidents as part of the Alert workflow inside of Secure Cloud Analytics and/or can be configured to be automatically promoted as part of the alert settings.  An example of posting an alert manually to SecureX can be seen in the above Alert example, just above the “Close Alert” option is a button “Post to SecureX Incident Manager” that, if selected, will post the alert and its details to the SecureX incident Manager.  An example of automatically configuring Secure Cloud Analytics to automatically post an alert to the SecureX Incident Manager is in the below figure of the Alert settings for the “Internal Connection Watchlist Hist” alert. You can observe details about the alert such as the Mitre ATT&CK Tactics and Techniques, the telemetry needed, the alert description and you can adjust the severity of the alert and whether or not to promote the alert to SecureX as an incident. If the “Publish to SecureX” option is enabled, the alert will be automatically published to the SecureX Incident Manager as an incident when it occurs.

A common theme throughout this series has been that not all alerts or incidents are equal. Depending on your organization, your processes and other variables such as your own risk assessments, some alerts and/or alert types are going to be more valuable than others. I’ve been highlighting methodologies inside of each detection product to prioritise Incident creation, however, you may still want methodologies of finding the most valuable incidents in the Incident Manager. A feature that helps significantly with this effort is the search bar to filter incidents based on their attributes.

Suppose your organization has adopted Mitre ATT&CK as a framework for prioritising incidents. For example, you’ve identified specific threat actors and their associated TTPs or valuable assets and ascertained the types of TTPs that would be used against them and you now have a list of TTPs that you would like to prioritise inside of your SOC. Suppose that list contains the Technique T1102: Web Service (Adversaries may use an existing, legitimate external Web service as a means for relaying data to/from a compromised system), you can use the search bar in the Incident Manager to surface all instances of T1102, as seen below.

Using the now familiar workflow of clicking “Investigate Incident” in the above “Incident details” figure results in the below figure that showcases the extended detection, enriching the incident created by Cisco Secure Cloud Analytics with data from other SecureX integrated components such as Cisco Secure Endpoint and Secure Network Analytics.

In the above extended investigation, we can see some of the details about the original Stealthwatch Cloud incident between the internal (10.90.90.206) and external IP Addresses (128.107.78.9) but also, the hostname, hoser-w7, as part of incident allowed the encrichment of the investigation with sightings from Cisco Secure Endpoint including the usage of tor.exe (our high impact incident from part two) and, sightings of other other internal IP addresses from Cisco Secure Network Analytics. When combined with a High Impact detection from Secure Endpoint what might have been overlooked behaviour observations suddenly become much more relevant, allowing the operator to shorten that OODA loop and make decisions and take actions quicker and with greater efficiency.

In this post we’ve expanded on the concepts behind what makes a behaviour detection, how to promote them to SecureX from Secure Cloud Insights, a methodology to filter on Incidents using attributes such as Mitre ATT&CK, and how to leverage Cisco SecureX to automatically extend the incident. In the next post in this series, we will continue this effort of extended detection with the automatic promotion and triaging of detections from Global Threat Alerts into Cisco SecureX.

Interested in seeing Cisco Secure Cloud Analytics and the SecureX Incident Manager in action? Activate your SecureX account now.

We’d love to hear what you think. Ask a Question, Comment Below, and Stay Connected with Cisco Secure on social!

Cisco Secure Social Channels

Instagram
Facebook
Twitter
LinkedIn

Share: