Adding a personal touch

At RSA2019 I heard about a SOAR customer that had to add delays to their playbook “wait 5 minutes before replying” so end users felt their request was being handled with care and not simply scripted.

It reminded me of a story of an Italian tortellini maker that bought 5 different pasta machines to keep the product looking ‘varied’ so customers would believe the pasta was hand made.

So what can we do to give SOAR that human touch?  (DBot if you’re reading this, no offence my friend, I still think you’re great)

Approach #1 – Make automation more human like

Adding a time delay to responses to simulate an overworked team

Use a pre-written list of slightly varying replies with the occasional spelling mistake

Sometimes just close a ticket for no reason (or just don’t open it)

Approach #2 – Human chaperone

Random 10% chance that a human sends the last communication “I’ve been watching the ticket and it all looks good, did it meet your needs?”

If the submitter hasn’t used automation before, acknowledge this in your initial reply “we can see you are new and we’re assigning a human to watch over as you engage through this process”

Run a weekly report of new end users and give them a call to review

“Click here if you ever want to escape this automation and talk to someone”

Include “this is an automated response – an analyst response will follow”

I’d love to hear from anyone that has faced this problem and which gave the best success…



Source Article

(SOAR is) taking SIEM further by combining data collection, threat and vulnerability management, incident response and case management, workflow, and analytics

Agreed, will SIEM have to adapt? Is it as easy to shoehorn SOAR into SIEM as it is SIEM into SOAR?

FireEye polled C-level security executives at large enterprises worldwide and found that 36% of respondents receive more than 10,000 alerts each month from their SIEM, of those alerts, 52% were false positives and 64% were redundant#

I’d not come across the 64% statistic before, though I believe it completely. Too many tools alert the same alert over and over. The ability to check incoming alert for duplicates is something I’ve written about before

SIEM required daily, round-the-clock tuning by a seasoned staff

So nice to see someone else say this. Almost every time I hear “our SIEM dashboard is amazing and gives us everything” I dig deeper and finally they admit “well yes we have a full time consultant dedicated”. I’m not knocking SIEM but that is a reality.


Ponemon Survey Report: Staffing the IT Security Function in the Age of Automation

Some amazing stats in here (free to download just register your email). I literally want to copy and paste half the report here, but that’s probably bad manners to the authors.

Gartner predicted 15% would use SOAR by 2020 but Ponemon survey finds
that 46% “expect to use it in the next six to 12 months” (I accept not all automation is SOAR, but this is a security conversation, so it maybe it should be).

“[…] Unfortunately improvements in staffing are not happening.”

I’ve written before that SOAR won’t necessarily replace half your team (though it can lead to reduced workload) and that’s mirrored by the audience, though I didn’t expect people to expect an increase:

  • 23% say “Automation will reduce the headcount of our IT security function”
  • Whilst 44% say “Automation will increase the need to hire people with more advanced technical skills”

Two of the main reasons AI (which as we all know is really ML) is needed is to replace human error and improve 24/7 monitoring and response.

There are many fundamental values SOAR can do, which I’m surprised the report didn’t look into, but maybe that’s a different report in the future?

Anyways, great report, lots I didn’t cover, go read it!


But my ‘XYZ’ just added SOAR capability

How many vendors at RSA 2019 magically now do SOAR… I lost count (and I’m reeeally good at counting).

Unfortunately this trickled down into people minds, and I hear “but my endpoint will do SOAR”  (sorry, I’m not picking on endpoint specifically).

So let’s analyse the reality of ‘we added SOAR’

Source Agnostic

SOAR should be agnostic for where an alert/alarm/trigger comes from.

Example – If your Endpoint is also your SOAR platform, is it still as functional when the alert is generated in Amazon GuardDuty alerts, or from Jira tickets?

Integration Count

Ok great your ‘me too’ platform can integrate with MISP, ePO, ActiveDirectory, Cuckoo. But who has those exact technologies? Your toolsets will change and grow over time.

Example – A SOAR platform has hundreds on integrations. Anything less means a gap, and you will still do all the work yourself.


If solution ‘XYZ’ has workflow built in, is it designed around the functionality specific to that product?

Example – Would a Deception technology with SOAR understand and support workflow needed for Vulnerability management?


So if your “me too” SOAR solution…

  • can’t trigger from multiple sources
  • only integrates with 30% if your security stack
  • can’t handle half the workflows

…how can you get any meaningful reporting out of it?


I’ve heard of vendors saying ‘we do SOAR’ when in reality they just have integrations, and maybe you can change the order, but that’s not SOAR.

And I’ve not even covered: customisation, load balancing, RBAC, multi tenancy, threat intelligence tracking, custom IOC definitions, collaborative work spaces, and dozens more.


Next-Gen-Prioritising 2.0

When I was a SOC team lead prioritising alerts was very simple, each alert came with it hard coded….

alert tcp any any -> any 80 (msg:"WEB-MISC phf attempt"; flags:A+; \
        content:"/cgi-bin/phf"; priority:10;)

…..10.  So it goes to the top of the alert pile.  As the meerkat says, simples.


But by continuously re-evaluating through the lifecycle of the incident/ticket, can we do better using SOAR?

Enrich against devices

You see malicious activity targeting an internal IP address, what is that device?  Enrich with CMDB

Is the device a payment gateway?  priority +1

Is attack against the correct Operating System?  priority +1

Enrich against the user

If we have an end user request on phishing, let us enrich with Active Directory

Attack against any user?  Priority +1

Attack against CxO ?  Priority +2

Phishing query from a reliable user?  Priority +1

Phishing query from an unreliable user?  Priority -2

Baseline of similar alerts

A simple test, but if a particular alert type is running at 205% of normal for a Tuesday afternoon maybe we need to increase the priority to understand what has changed.  Here I would enrich using SOAR/CaseManagement 

Confirm if Malicious

If I have two similar alerts, enrich with Threat Intelligence.

Alert includes known bad IOC?  Priority +1

Alert has IOC from 2001/Eicar/RickRolling?  Priority -1

Confirmed on your Estate

A trusted security person shares 2 IOC with you, each becomes an independent ticket in SOAR and automation kicks in to validate and search.  Enriching with SIEM

IOC not on your network?  Close ticket with 0 prioirty.

IOC observed on your network?  Priority +1 and escalate

Per Incident type

Typically I would prioritise a Phishing enquiry before removing a user from a OrganisationalUnit in AD.

But if SOAR can automatically tell me that the Phishing enquiry contained no known IOC, and was from a high FalsePos user….. vs the OU request was from the CxO and involved a user that was currently logged on to the systems I think I would probably swap their priorities around.  **


So there you have some ideas on how to prioritise at the beginning of the ticket and how to prioritise all the way through the ticket so make sure you’re looking in the right place first.


** that’s a trick question, I wouldn’t do either of them, I have SOAR, but you get the point.

Chat with a SOC Leader

At a recent conference we had a Q&A with SOC team lead, <REDACTED> from <REDACTED>. The team is newish and growing so they are embedding SOAR into the team from day 1, aka SoarNativeSOC

I’ve not worked in a SOC for over 6 years so it was a great chance to see how the world has changed (though amusingly it hasn’t, same incidents, same challenges).

I thought I would share my favourite takeaway:

  • The company is going through hyper growth, with tough expectations that the SOC scales at the same pace. SOAR helps reduce the immediate need for security head count and lets them grow at a lower controlled rate.
  • First use case for SOAR was phishing simply due to the quickest return of the biggest amount of time
  • As well as simply handling real phishing enquiries, SOAR was used to track phishing tests and auto training and enablement for those who fail
  • They have identified a use case for travellers planning on a trip to <scary_country>. The playbook informs the user, limit their access in the org, put them in a high risk group, etc
  • Also a use case to monitor for users activity in new countries. SOAR sends a quick “is this login you?” over Slack/HipChat/Email. “no” results in password resets etc. The advantage to the business is 1 less solution to buy in the future, and one less technology to train/enable with.
  • SOAR has helped increase the team’s reputation in the company due to the speed of their service (which underpins AppSec, not just security)
  • Playbooks know how to add team members automatically. So if a incident/playbook finds malware it automatically adds a Malware researcher to the ticket
  • SOAR is good for IOC searching, which we should remember is NOT the same as threat hunting. The former is simple and quick, the second requires a lot more effort, time, expertise, context, etc.

Thanks <REDACTED> it was a great session!


SOAR in 5 sentences

Listening to ‘CISO Security Vendor Relationship‘ (a great resources!) I heard the following aimed at vendors:

Don’t market as simply ‘saving time or money’, it’s lazy, and not everyone needs to save money.

Which is tough because these are literally the concept of SOAR.

So I challenged myself to write a pitch for SOAR, in 5 sentences, without these lazy sentences, aimed at someone who is new to the SOAR concept.

Note – This is just my little game, it’s not an approved or sanctioned pitch from any vendor

Security teams typically spend too much resource (money, time and brain cycles) on the simple tedious tier 1 soul destroying work.

When busy, humans can be unresponsive (minutes/hours/days), expensive (time/money/brain cycles), forgetful (deviating from process) and easily distractible.

So when Analysts should be deep investigating, concentrating and self learning, they are infact trying to keep up with 1000 smaller things a day (alerts, processes, actions etc).

SOAR aims to automate these tasks in seconds and minutes (either completely or just the heavy lifting/preparation) allowing analysts to use their brains and not the control+c key.

How we do that (automation, case management, threat intelligence platforms, machine learning etc), how we differentiate, and our typical use cases would be great things to have a follow up chat about.


Removing insider threat from processes

Here is another interesting chat at RSA Conference this year. A gentleman approached me asking if we could help with their problem of moving data and insider threat.

His organisation policy makers were happy to use Cloud for standard business services, but not storing their sensitive data (he wouldn’t tell me the specifics). Anytime they wanted to move data from that ‘area’ of the network to the cloud they were refused by policy in case there was data leakage… you know… just to be safe.

His first problem I couldn’t help with, apparently encrypted VPN isn’t safe enough for transmission. Maybe they will end up with sneakernet and a suitcase + handcuffs.

The second problem though was a great use case for SOAR, and not one I’ve come across yet. The data source and data destination were from different vendors with no existing integration together. This means the process is very manual and potentially exposes sensitive data to the insider threat / operators.

So I demonstrated our playbook execution and how we communicate with end users. The final pseudo design we agreed on was:

  • A playbook that can be initiated by a schedule or by an inbound request
  • The playbook automatically restricts permissions of the ticket. Access is only granted with 2 pairs of eyes.
  • The playbook fetched the data from vendorA
  • The playbook then did some basic pattern matching against the data, file type checking, maybe push it through a DLP, and many more.
  • If the data was sensitive we can stop the process, flag the ticket, etc.
  • If the data was good we push it to the remote system and close the ticket.
  • However If the data was neither definitely good or definitely bad we can use CommunicationTasks to email a manager and the original ticket requester asking what to do? Proceed or stop?
  • Using our ComTask we can interactively engage the end user without exposing the data in question (see above)

To summarise, they can still do the process (quicker than before and with fewer mistakes), they’ve removed visibility to the data, but their workers still have the control to initiate and control the workflow. Pretty cool.

Thought not predominantly a SOC incident type, it shows that automation is automation, be as creative as you like.


Thoughts from #Symphony2019

A great day for SOAR at #Symphony2019 in SanFrancisco yesterday. For those that couldn’t attend, here are *my* top 10 comments/thoughts from today. I’ll no doubt follow some of these up with better write-ups in the future.

“There will be 12.3 billion mobile-connected devices by 2022” (Cisco Visual Networking Index whitepaper) reinforcing our problem that human analysts can’t keep up with the tech explosion. Especially as our brains and team sizes grow in a linear way, and this device explosion is growing more like exponential. Is automation the only to retain some control? (Thanks Keren )

I’ve already joked on this blog how attackers automate, and so should defenders. Keren also pointed the audience in the direction of AutoSploit which really backs this up

SOAR and automation are great, but don’t forget that over-automating can lead to reduced visibility which is a slippery slope to not seeing everything. Yes automate the boring, but don’t forget to track it, review it, etc. So don’t forget case management, automated reporting etc.

‘SOC Analyst hours saved per month’ might not be a KPI for some business units. Consider other approaches that relate to business goals, for example ‘response time for access requests’ which uses a playbook that onboards people into Distribute Lists, 2FA systems, etc. For many your employer is your customer and KPI that relate to the business might fare better.

Previously I briefly touched on how even simple playbooks can still add value, and a great example was covered today by a guest speaker. Chasing end users for input/updates on tickets is not only time consuming but very distracting. Imagine SOAR as an end user prompter which will ask for more information “every 4 hours” for a total of 24 hours and then automatically closing the ticket with “lack of information”. Any system can kick off this playbook and we sync all updates back to ticketing/email/slack taking the burden of responsibility away from your team.

Over the years Privacy and Security have been merging into one another and it’s causing fresh problems SOC teams (e.g. scale, focus)

During a Q&A it was asked “is SOAR not becoming one complicated place with lots of code in?”. The guest presenter made a fantastic point reminding us that SysAdmins are naturally lazy and mini tactical home-brew scale automations have existed for 20+ years. However without SOAR their network would have small snippets of code running on 100 different servers by 100 different authors and without real documentation meaning that when a developer leaves the knowledge of what/why/how goes with them. A SOAR platform helps bring that together and formalise that with a standardised environment.

Guest speaker – “In a P1 critical incident the last thing I want to focus on is remembering how to do the silly little processes”

All board members understand risk, but they might not quantifiably understand how much better stopping attack X in 15 minutes is compared to stopping it in 2 hours, is that good or bad? Crowdstrike recently released a report focussing on the breakout time breaking this down by threat actor. This can serve as a fantastic baseline that explains to the board “this attack typically takes 1 hour from exploit to exfiltration” and we can now us that to serve the baseline to compare a “manual only” method vs how a SOAR playbook can compete. (

It was a great event and I’m looking forward to next year’s guest speakers, thanks everyone!!