From Zero to Process to XSOAR Playbook

[JStephan]

XSOAR is a Security Orchestration, Automation and Response platform. Generally speaking, this means that we perform the right response, orchestrated from a central platform, while automating the annoying and repeatable tasks which slow us down.

Using the commonly known language and used Incident Response Cycle, XSOAR strives in the area of analysis, containment and remediation. As a great feature, our Playbook design tool also follows the standard flow diagram model from Process and Use Case design.

Many companies struggle when working with XSOAR, as our out-of-the-box playbooks have been curated and improved over the years and seem to be complex for many companies whose current processes are smaller or for those who haven’t started building out their processes.

Take a Step Back and Start From Zero

Like in Process design, the whole approach is rather small and contains three components: Input, Processing and Output.

• Input, is the data you get from a 3rd party. Keep in mind that XSOAR is indeed an Incident Response Platform, so this should be a (conformed) incident. The more certain you are that the data received belongs to a real incident, the easier and smaller your processing can be.
• Processing, includes all the steps you need to take to make a decision on the severity of the incident as well as the best response. Of course, part of this processing are the steps you need to add in order to make your work valuable or at least reportable, so every timer you need for SLA and KPI’s will be reflected in the steps of the processing.
• Output, are the set of actions you want to take based on the processing you have done before. This can fall fully in the orchestration part, where you use our integrations to, for example, block IPs on a firewall or block users, but can also be something simple like reporting and escalating.

XSOAR adds benefits for you, such as:

• Mapping, normally dismantling of data out of the complex incident data is a common step of the analytics. With the Mapping in XSOAR we lift this to an earlier step. This is meant to ensure that the data is already available from the start of the processing and XSOAR, for example, understands the difference between a source and destination IP as well as sender and a receiver.
• Classification is very useful, as now you don’t need to analyze an event in order to understand the type of the incident. Especially sources like a SIEM or data lake can have multiple types of incidents. Classification can be performed to ensure that the right processing is used for a certain type of incident.

A new Playbook should be minimalistic in the approach to take a certain input and come to a certain output. Trust me when I say that a Playbook will grow once you get the hang of XSOAR and you add more tools and integrations to your processing steps.

What Would a Simple ALL PURPOSE Playbook Look Like?

The basic processing of Incidents should contain of the standard steps like:

• Start a timer, either for tracking your internal SLA or simple identifying the steps of the playbook where you could improve your automation capabilities. For example, you can of course start multiple timers so you can really track the time on individual steps.
• Dismantling of indicators and information. Remember when we said before that Mapping solves the dismantling of data, while this is still true for metadata. This dismantle step is in order to prepare the enrichment of indicators mainly.

Using the “extractIndicators” on certain parts of the incident data will give you a list of all indicators within the incident. This list can be fed into the “enrichIndicators” task in order to query 3rd party enrichment like VirusTotal, Alienvault OTX, IPinfo. These and so much more are available on our Marketplace.

Now with all the data in place we can estimate the overall severity of an incident. The “DbotAverageScore” is a great starting point, until you find a way that is most comfortable to you to handle. It will simply compute a score based on all the different indicator scores.

Next Steps

Once you get used to XSOAR and all the possibilities, you may add different tasks and steps to these playbooks and start to specialize them based on the remediation steps.

Some sub-playbooks you may want to consider are:

• VIP/VVIP detection - An incident can have a different severity if a VIP (Chief Finance Officer, CEO, etc) is involved. It makes sense to have a list of VIPs (executive managers) and VVIPs (C-level) and check if they are involved in an incident. A phishing email to a VIP/VVIP can potentially cause more harm than emails to other recipients. Same goes for malware on devices.
• Crown Jewel detection - Following this same approach, having a sub-playbook which queries a CMDB or similar to identify high risk systems can be a plus.

As a site note, you can of course also create an “Crown Jewel” indicator type and save all the IP addresses in the standard indicator library with a high severity, so it will impact the average verdict of an incident.

We should also discuss the idea of remediation at this point. Remediation describes all the steps you want to take as part of the containment of an incident or the recovery from it. This can also be a ticket you open somewhere or an email you send. If this is the case, the whole remediation part becomes a single task at best.

Depending on the incident type, we also offer some remediation playbooks you can easily add to your current playbook. For this, simply open the Task Library and select the Playbook which suits your situation best. Keep in mind that many of the Marketplace Content Packs will expand these remediation tasks based on the specific integration you are using. Many firewall integrations will provide the specific steps you need to take in order to block an IP, for example.

As always, be excellent to each other and read you soon!