XSOAR is a Security Orchestration, Automation and Response Platform, hence the name. 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 language of the commonly known 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 standards flow diagram model you well know 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 since years and seem to be complex for many companies whose current processes are way smaller or for those who haven’t even started building out their processes.
So let’s 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 a Incident Response Platform, so this should be a (conformed) incident. The more certain you are that the received data 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 is 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.
One thing XSOAR adds as a benefit for you is the
- 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 nand 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.
Keep it stupid and simple. 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 a hang of XSOAR and you add more tools and integrations to your processing steps.
So how 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. Yes, I remember I said before that Mapping solves he dismantling of data, while this is still true for meta data, 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 feed into
- The “enrichIndicators” task in order to query 3rd party enrichment like VirusTotal, Alienvault OTX, IPinfo and so much more are available on our Marketplace.
- Now with all these data in place we can estimate the overall severity of an incident. Until you find your own way of dealing with this, the “DbotAverageScore” is a great starting point. It will simply compute a score based on all the different indicator scores.
Next Steps
Like I said before, once you get used to XSOAR and all the possibilities you will 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 VIP (executive managers) and VVIP (C-level) and check if they are involved in an incident. A phishing email to a VIP/VVIP can potentially cause more harm then 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.
Of course we also should 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.
to again keep it simple, this can also be a ticket you open somehwere 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 quite some remediation playbooks you can easily add to your current playbook. For this simply open the Task Library and select the Playbook wich suits you 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.
Thats it again, be excellent to each other and read you soon