Automated Responder Knowledge (ARK) in Action

We released our Machine Learning Engine PRISM in our most recent 4.2 release. The first capability that we developed from PRISM is our Automated Responder Knowledge (ARK). This capability will change the way incident responders and SOC analysts respond to incidents, and how they share and transfer their entire knowledge to the rest of the team. The key to this capability is that it learns from your own analyst’s responses to historical incidents to guide the response to new ones.

We are not re-inventing the wheel with this feature. SOC and Incident Response teams have been doing this the old-fashioned way for a long time – through 6-12 months training. What we’re doing is providing a GPS and Satellite Navigation, guiding the wheel and giving you different paths to choose from according to the terrain you are in.

We do this by analyzing incidents and their associated attributes and observables, to work out how closely they are related. Then we can suggest actions and playbooks based on your organizations’ historical responses to similar threats and incidents.

Automated Responder Knowledge (ARK)

Using Automated Responder Knowledge (ARK) in IncMan

Step 1: Not really a step – as it’s done automatically by Automated Responder Knowledge (ARK), but this occurs in the background for every incoming incident. Every Incident possesses a feature space1 that contains all the information related to it, composed of every attribute, associated observable and attached evidence. ARK analyses the feature spaces associated with every incident ever resolved. When a new incident is opened, it is scored and ranked and then compared by ARK to the historical model to identify related incidents or actions based on similar and shared attributes. The weighting of the ranking can be customized by analysts.

 

Automated Responder Knowledge (ARK)

 

Step 2: Open the incident, selecting the applicable incident type. To save time, you can create an incident template to prepopulate some of the contexts automatically in future.

 

Automated Responder Knowledge (ARK)

 

Step 3: Select Playbooks, and PRISM.

In the next screen, you will see a variety of suggested related actions and related incidents based on the feature space that your incident type is matched with. The slider at the top is used to determine the weighting in ranking for actions that are suggested. For example, if I move the slider to the left, the entire feature space actions appear, then if I move the slider to the far-right only a few actions appear from highly ranked incidents.

 

Automated Responder Knowledge (ARK)

 

 

Automated Responder Knowledge (ARK)

 

Step 4: Determine which automation and actions you want to use from the suggestions. After saving, you will be presented with options such as Auto-Commit, Auto-Run, Skip Enrichment, Containment, Notification or Custom Actions. You have the ability to select only the actions you want to automate. If you are concerned about running containment automatically, for example, you just deselect those options.

 

Automated Responder Knowledge (ARK)

 

Step 5: The automated actions are executed, resolving the incident, based on prior machine-learning generated automated responder knowledge.

ARK is designed to facilitate knowledge transfer from senior to junior analysts and to speed up incident response by applying machine learning to automate the knowledge gathering and analysis.

How Trading Platforms Are not the Same as Incident Response Platforms?

What’s wonderful about all our security industry and specifically the products, is that we constantly see similar fancy dashboard reporting. These views focus on an abundance of information being displayed to aid users trying to correlate and make historical data relevant. It’s vital data but I don’t think this information is best placed in this scenario. I am going to focus on the perspective that is most relevant to myself, and that’s incident response. For incident response, historical data is relevant when you have a purpose to use it. Our main focus, within incident response, is to respond to incidents that are relevant right now.

We often focus on thinking outside the box and use examples from other business models in order to facilitate our own growth. I think this concept is common and serves its purpose for planning, but we must understand the purpose for which we’re trying to use this concept. I always laugh when I see a show of the morning which displays stock/indices information. I ask myself, who is next to implement that view in their security product? Considering this, I think it’s something we need to seriously think about. Is this information relevant for this purpose at this point of a cyber investigators journey?

Over-complicating and over-stimulating users with too much data can have the opposite effect of the desired consequence. You’ll lose value and purpose for this information and ultimately it can become another piece of background clutter that is easily ignored. Time is essential when dealing with any cyber security event, not only from a response standpoint but also an evidentiary gathering perspective. Orchestrating information at the correct time is just as important as responding to the incident itself. Evasion techniques, obfuscation, and piggybacking are just some of the thought processes cyber intruders will use. It’s extremely difficult to know when the right time will be for each individual case, however having an incident response platform to gather and display incident information is essential and following this information in a visual manner will prove effective to the war rooms.

An incident responder’s dashboard should be clear and concise. The investigator, analyst or stake holder should see information that can drive them to an action on a granular level. While this information may be different from organization to organization, the concept should remain the same. I do enjoy a good list, so here are some of the thoughts I have when planning a dashboard view:

Active Cyber Incidents per business units and their priority, some people mention this as a health status. Either way the concept is the same. Which business units have incidents registered against them? What’s the priority of the incident? This should simply generate a % number and a color coding. Use RED, if major, Green is low priority and non-invasive tasks identified. The number should represent the inverse of incidents * by the priority raised
Events identified by source, knowing which products are producing the most events is quite key in identifying if this source is doing its job or if the source could be configured differently
Playbook stage number, time to close organized by priority.

Incident data is critical, and the general rule of thumb is more is preferable to not enough. However, given that the purpose is to understand the relevant data as it relates to current and future incidents, this simple technique ensures that your incident data feeds not only remain timely, but provide maximum value as well.