In part one of the Relevant and Extended Detection with SecureX series , we introduced the idea of risk-based extended detection with Cisco SecureX – the theory a user can prioritise detections into incidents predicated on their notion of what constitutes risk within their environments and extend those detections with enrichments from other products. In subsequent posts we have been diving deeper into different Cisco Secure detection technologies and how their respective detections could be prioritised, promoted to SecureX as incidents and extended. In this article we shall look at detections from Cisco Secure Network Analytics to discover just what a network behaviour-based detection is, why is them important and relevant, when/how to market them to SecureX as incidents, and how exactly to leverage and extend the detections in SecureX.

WHY IS a Network Behaviour Detection?

If you’ve attended BRKSEC-3014 at any Cisco Live before, you’ll know that is among my favourite topics: behavioural observations describe a specific behaviour was observed and therefore certainly are a statement of fact – ex. “This host has been observed to possess High Traffic.” The most common language in security operations – True Positive, False Positive, True Negative, False Negative – can’t be utilized to accurately classify a behavioural observation (by definition, everything is really a true positive) and we should approach them with a slightly different mindset than we’d a content derived detection.

A behaviour analytic product, like Cisco Secure Network Analytics, collects data, analyses it so when the conditions for confirmed algorithm, or behavioural model are met, generate a detection. I have a tendency to separate the detections generated into two buckets:

1. Observation of a known behavioural condition

An algorithm watches for a known behaviour alarms and pattern once the conditions are met. A simple example is communication to a known control and command server, a far more complex example is really a host is downloading a great deal of data.

2. An anomaly observation

A definition of normal is set up so when the conditions for a deviation from that normal is met an alarm generates. This event is harder to classify, oftentimes the style of normal is built predicated on a number of the similar behaviour conditions above and alarm on a deviation, for instance “a bunch is downloading an abnormal quantity of data.”

The matter that makes operationalising behaviour observations tricky is that the detections themselves usually do not capture intent: you often must overlay intent utilizing the language of the business enterprise and its own relevance to the behavioural observation. For instance “the PCI server just uploaded plenty of data to an external server” is quite unique of “10.10.10.10 uploaded a lot of data to 128 just.107.78.10.” Just identifying a behaviour doesn’t indicate it was a negative behaviour and just identifying an anomaly doesn’t indicate that it’s an insidious threat. There’s a whole lot of weird on the market, and some of this means nothing.

.

The procedure of choosing which observations and alarms are a few of the most valuable and actionable is beyond the scope of the blog series, however, several tools and techniques have already been documented over time and various methodologies developed showing how exactly to best operationalise behavioural observations from Cisco Secure Network Analytics. In the event that you haven’t already, and you’re thinking about understanding the analytics engine, I will suggest viewing past recordings of BRKSEC-3014 and the Phased Method of Tuning is definitely worth a read.

Creating an Incident from the Secure Networks Analytics Observation

One approach that takes the context of the business enterprise in to the generation of alarms may be the Tiered Alarm approach ; which also lends itself to the promotion of incidents into SecureX threat response&nbsp perfectly;.  In the tiered alarm method of tuning alarms, active alarms in Secure Network Analytics are configured to three tiers:

• • Severity Critical – Well-tuned, well-understood, typically low volume and actionable

• • Severity Major – of interest and so are tuned, observed, and documented

• • Severity Minor – informational Mostly; not actionable independently necessarily, but ideal for context

With all the Tiered Alarm approach, after deciding which are the most significant alarms to your security operations center, you set their severity to critical – and they are the ones that a reply is made by you playbook around. In addition, it happens that Cisco Secure Network Analytics uses the severe nature setting as criteria for promotion of alarms to Cisco SecureX threat response as incidents. To be able to automatically promote an alarm to SecureX threat response simply set its criteria to critical and in the Response Management configuration for the built-in rule Priority A: Severity Critical enable the built-in Create Threat Response Incident action. In the event that you wished to promote the High Severity detections as incidents also, you can certainly do exactly the same with the built-in Priority B: Severity High rule.

Once promoted into SecureX threat response being an incident you can start to increase the incident  utilizing the top features of threat response and the incident manager as discussed in Part one.  For instance, in the below figure, we are able to start to see the occurrence of the alarm CSE: Employees to Bottling Line , and the observables are increasingly being examined by us in the incident .

Clicking Investigate Incident will launch a study, extending the incident with relevant information regarding those observables by querying the APIs of integrated products to get what those products find out about the observables. The investigation of the aforementioned incident results in the below figure where we are able to see additional context. Of interest here’s that we now have multiple different incidents from Secure Network Analytics from the IP involved (bottom left of the figure). We have been also able to take notice of the target endpoint involved gets the hostname w7-darrin (top left of the graph).

You may spot the groupings of 8 IPs, 4 IPs and 27 IPs – with regards to data from Secure Network Analytics every edge in the graph is really a behaviour observation (Security Event in Secure Network Analytics nomenclature – they are observations which are being made however, not necessarily alarms).

Leveraging this understanding of how SecureX threat response displays data from Secure Network Analytics, we’re likely to go back to the incident from Part Two; the created and enriched automatically, high severity incident relating to the host w7-darrin . Opening the snapshot of the incident and adding the IP 10.90.90.201 results in the view below.

At this time we’ve significantly extended the incident to add data not merely from the initial incident but more completely earned data from Secure Network Analytics. What started as a higher Impact incident, largely driven by endpoint severity settings (in cases like this the usage of tor.exe) resulted in an image with greater context of a bunch that’s using banned software (tor.exe), actively cryptomining and for a few unknown reason violating network security policy by connecting over RDP to the production bottling line. The quantity of infractions shown in a single screen is incriminating quite.

Among the great benefits of Secure Network Analytics may be the wealth of network data it holds – an archive of each conversation on the network – even though that can be plenty of data and you also don’t always know very well what you’re searching for, the Security Events (or behaviour observations) generated by Secure Network Analytics help tell you where you can look. When coupled with a higher Impact detection from Secure Endpoint what may have been overlooked behaviour observations suddenly become a lot more relevant, allowing the operator to shorten that OODA loop and make decisions and take actions quicker sufficient reason for greater efficiency.

In this article we’ve reviewed some concepts behind why is a behaviour detection, why they’re valuable, how exactly to leverage Cisco SecureX to increase the detection, and how to utilize the behaviour observations to enrich and extend incidents from other detection products. Within the next post in this series, we shall keep on with this effort of extended detection with the automatic promotion and triaging of behaviour detections from Cisco Secure Cloud Analytics into Cisco SecureX.

Thinking about seeing Cisco Secure Network Analytics and the SecureX Incident Manager doing his thing? Activate your SecureX account now.

We’d want to hear everything you think. Ask a relevant question, Comment Below, and Stay Linked to Cisco Secure on social!

Cisco Secure Social Channels

Instagram
Facebook
Twitter
LinkedIn