We all know that XSOAR is sort of a platform for automation. It can literally run variety automation use cases, from security (as it is known for) to other IT processes, even HR on-boarding or any other serialized/conditioning processes that you can think of.
But let's put those use cases aside, we, as SOAR engineers, focus on the way we can run automation scripts on the platform. So when we get requests from the stakeholders, we know how to translate the requests and make it real.
Now, do you know where you can run automation scripts on XSOAR? Yes? Playbook tasks seem to be an easy answer, but there's somewhere else that you can work with scripts. Here they are:
Automation tasks
There's a dedicated menu for Automation tasks, so obviously, this is the most consumed feature for automation scripts.
+ You can run automation tasks manually in the War room/Playground
+ Run it as a task of a bigger Playbook.
Normally, each task is sort of a single script (written in Python/JavaScript). The XSOAR platform came with many built in scripts but new custom scripts are here as well.
The script can do small things like calculating a math equation to bigger stuffs like fetching and processing external data via API, presenting data for the analysts to use, enforcing Firewall rules with a list of bad IP addresses...
Dashboard & report widget
I found this is a cool and useful feature as many of my customers require customized widget. Widget is a box that displays data on XSOAR dashboard/report. Normally, it gets data from the database by lucene queries and presents to a table/different statistical charts.
What if the query is not enough or the presentation types are not customizable in the way you like?
Creating a script-based widget is the answer. I will write about how to make it in the next blog, but so far, a script can fetch data you want, modify it as much as possible, present the relevant field to the widget.
+ One example of the script that I've done before is that customer want a table with an ticket number column. This column contains offense ID from QRadar with a hyperlink to that particular offense in QRadar, so they click that offense ID to drill down for more data easily. So I created a script to present data in markdown format, with a column contains field in this format: [Offense ID](https://LinkToTheOffenseID).
+ Another example is you will present the data conditionally. If condition A is met, you present in the A way. If condition B is met, you present in the B way. Else, present in the C way. Script based widget is the way to go!
And there will be a lot of more complicated requests out there waiting for you to practice and deploy.
Incident field:
Sounds fun? Yes, it does. An incident field also has scripts attached to it. As you can see in the below figure, there are 2 types of script to run:
+ Script when field value changes: it is the most used feature because along the incident life cycle, a SOC analyst can change/update a lot of information including data in the field. For example, a Stage field can change frequently (e.g from queued --> investigating --> escalating --> closed). Each time it changes, interestingly, a script can run to fetch more information, involve more people, change timer, enforce rules...
+ Field display script: normally, you can put field into Layout to display data to the users. This script is designed for you to control whether a field can be displayed or hided. Sometime, the field must wait for some specific stage/condition to be usable. In that case, a script will help.
A layout button:
This is a straight forward and very useful feature of XSOAR. A Button is a component on the incident layout. You can imagine this one like a button on a website. When you click the button, it will do something in the backend.
So a scripted button is the easiest and most visualized way for an user to interact with an incident in XSOAR. A script will be triggered to change the incident status, assign to another one, stop the timer, confirm a firewall rule... If you are working with your customers to design a layout for them, buttons with script must be one of the most utilized features, I believe.
Pre-Processing rule:
Pre-Processing rule is designed for you to take some actions based on a match condition. For example, if an incoming incident contains "phishing" keyword, the pre-processing rule will fire up and take action. However, the built-in actions are just drop, link, close incident.
So, you can run a script to modify incident fields, or fetch more information for the incident, or assign it to a specific queue... Or we can do some more conditioning instead of relying on static condition that XSOAR gave us.
In conclusion, XSOAR is a free platform for you to play, design and run different use cases. And remember that use cases are not limited to just playbook tasks. An use case will involve pre-processing rules, layout buttons, incident fields, dashboard and report widgets to be comprehensive.
So, as an engineer, it's your capability to utilize everywhere you can run scripts to build a robust use case for your organization.
Comments