Designing SOAR (and Winning)
Feel the power of the dark side.
SOAR Projects are the kind of projects that can make your SOC Level up in 200 Levels or can push you back to Ancient ages if it is not well defined.
In this blog post — I will write how I designed a few projects, what is necessary and what you need to point out to the Integrator (or if your doing it on your own — these should be your working notes)

Start with designing the Scope of Work for Automation
Design the Scope of work you would like to cover, moreover — what kind of Alerts you would want to include, the faster you cover the Alerts with high false positive count (SOC Fatigue FTW) — your SOC could start doing more meaningful things.
Be as precise as you can regarding the Use Cases — don’t say “I WANT TO COVER EVERYTHING” — as this is not feasible promptly, Again — this kind of projects should be covered on a yearly basis (Milestones).
A Good start Proposition is :
- Covering IOC Based detection’s (User surfed to a C2 — yay).
- Covering Malware based detection (Playbook can be rather easily defined and handled — at least on collection level).
- Covering Use Cases that require manual interaction — and tons of it (i.e. Miss from Proxy, Phishing alerts).
- Covering Double Assurance (as mentioned in the rules for a successful SIEM implementation blog post).
Define your Doctrine & Goals
Here is the part where I start sweet talking.
Doctrine
- Automate and Orchestrate — High-level well-defined incidents, strive that any case will be handled automatically.
- Provide a playbook driven incident management process for security incidents. This will result in a wholly transparent and smooth operation for incident management and deliver metrics like trending incident types, most effective security analysts in the SOC, mean time to resolve incidents.
- Show collaboration across security analysts and eof other analysts to perform a security analysis of incidents.
- Give Automation Services (To a certain extent) to Enable Fast Reaction to Security Incidents.
- Prioritization should be derived from Base events alongside other parameters as agreed in SIEM doctrine.
Goals
- Reduce mean time to Response.
- Reduce Human Case error handling.
- Remove the need for Tier 1 Analyst.
- Allow a clear Mission on Incident Response task.
- 24x7 Incident handling by Automation.
- Provide Fully Automatic Response to specific events.
Define your Classifications and how an event is classified
Now, That’s kinda tricky.
Most SOAR’s require you to classify an Event to be able to assign a Playbook — so if a Malware event occurs — you want to run the Generic Malware playbook and then maybe a more precise one.
Now — here is what I did on my last project — it requires some work on the SIEM Side, but once you do it — you’ll be able to be more precise on Playbook picking. I’m not saying this can’t be done on the SOAR side — I’m just saying that for Management reasons — I have done it on the SIEM side.
So — I went over all of our correlations — and started Classifying them since we were using ArcSight & Demisto — we did on the “Meta event” level — but you can do it on all if not most SIEM’s similarly.
- Take your Correlation Lists.
- Export them and define 2/3 Categorizations — On an excel file or similar.
- Set Fields that Populate these Events when they trigger, so instead of Running a Playbook by Classification that is derived from a Rule name — it will now derive from a Real Classification Field.
So — for example, you will have the following classifications :
Malware;PUA
Malware;Ransomware
Malware;Persistence
Malware;Filess - Feel free to contact me for a bigger list of classifications.
Yes, I know this is some work — but once you get the bigger picture, you’ll understand why you listened to me in the first place.
Define your action repositories,Employ threat intelligence
This one is pretty simple, just see what supports what (i.e. you have some EDR — make sure it is supported both ways on your SOAR).
See what actions are supported — and make sure to understand how they fit in your playbooks.
Build once , use many times
Perhaps the most essential building blocks — are the ones you are going to use on each Playbook.
For example, in the SOC we did an automation Project for — we decided each alert should have the following automation — no matter what.
- Enrichment: All data was enriched from Threat lists (it’s,URL’s, etc.).
- Timeline : All data was timelined via search query to the SIEM which returned events around the time of the occurrence.
- Bigger picture: See if any events are related, or if this is a part of a campaign (if so — merge the cases).
Before even implementing the Playbook — we designed the interaction between the playbooks — here is an example :
A Master Playbook for Classification, Then Unique Playbook for Malware, Then 2 Other Enrichments which are building blocks (Created once, used many times)


Define Playbooks to a level so deep, your grandmother could understand it (create no space for mistakes)
We parted this as two things, 1 — Implement the verbal response (what needs to be done) 2 — Implement the Automation in Playbook level.

Create a Pre-work decision making Master Playbook — you will thank me later
This is bread & butter, this is one of the more critical Playbooks, your analysts will thank me.
The Prework Playbook gathers data from other data sources (in our case it was Logger — but it can be Splunk or any different Log Repository) — this will save the time cutting the data you need.
Desigining your screens is NOT LESS important then Playbooks
Since not every Case/Alert looks the same — design your screens, they will save the analyst time Analyzing the Case and give the relevant information heads on
Work with the Vendor for Playbooks
The vendor has Tons of Samples and Community-based Playbooks (At least our Vendor did) — Use their past knowledge to see (as before) what others did and implemented.
Get help from the community
Most vendors (not all) — have excellent Slack channels, make sure you check em out.
Define your automation level (or how Skynet takes over)
A good friend of mine pointed out — when we last discussed, its hard to design (Kudos IK — You know who you are) a use case or automation for EVERY thing that happens (and I did mention it before) — and he is right.
I quote
“You can’t drain the bath every time without making sure you don’t drain the baby while at it as well” (man that’s tough).
this is why you should leave some space (&faith) for your Analysts, they are there so Skynet won’t take over just yet.
Be one with the Dark side
Let the Hate flow young Sith!
So to Summarize, before you go head on to this big project — Design it well — “dummy proof” (another quote from a friend of mine — MA — You know who you are).
Make sure you spend time and thought about :
- Event Classification.
- Playbooks (Building blocks).
- Moreover — where to automate and what, don’t try to solve the unsolvable.
- Playbooks in depth — who does what when.
- KPI’s.

Contact me if you need help on your next Automation Project :)
