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.

Workflow

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?

Reporting

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?

Summary

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.

Andy

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.  **

Summary

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.

Andy

** 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!

Andy

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.

Andy

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.

Andy

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 https://www.k3r3n3.com/ )

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 https://github.com/NullArray/AutoSploit

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. (https://www.crowdstrike.com/blog/2019-global-threat-report-shows-it-takes-innovation-and-speed-to-win-against-adversaries/)

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

Andy

socless-detection-team-netflix

(sorry for a link to an old article, I only just came across it)

“Every triggered rule should fire automation before it fires an alert to a human. When a human gets an alert they should be the right person, and be provided the right context and the right set of options. In our culture the person with the best understanding of the system is the system owner / oncall, whether a security team or application team. This is what I mean by SOCless; decentralizing alert triage to system experts. Within security that means you respond to the alerts you write.”

https://www.linkedin.com/pulse/socless-detection-team-netflix-alex-maestretti/

I love it!  One of my SOC roles included 3-4 hours a day of copy-paste IOC enriching, occasionally leading me to an alert for a system/process which I didn’t even know about and couldn’t find documentation for *

However, in my experience system owners typically care about availability/development not security/confidentiality/integrity.  This extra responsibility might only work when devsecops mindset matures.

Personally I’d explore a middle ground.  Have each alert is assigned a system specialist who takes ownership of an alert but also has a member of the CIRT/SOC who acts as a concierge (or Military Police if you prefer lol).

Andy

* I can’t RTFM until you WTFM

Too busy

https://www.linkedin.com/pulse/please-stop-im-too-busy-kristin-tucker/

The other say I essentially heard:

We’re too busy doing the stupid tasks to work out how to automate the stupid tasks so that we don’t have to do them any more

 Andy