Category: Thoughts

I hear this a lot, but it doesn’t matter. If anything, a smaller team has more of a need for SOAR.

Don’t believe me? Listen to Bruce Potter (CISO, Expel) and Mike Johnson (CISO, Fastly) on the CisoSeries blog (fast forward 1m38s)

Serious Hackers Wear TWO Black Hoodies

A listener writes in asking “How do you thrive, and how do you survive as a team of 1?”

The panel discuss many general points, including:

• think about how to amplify yourself
• democratise others to do work on your behalf
• only so many hours in a day for you to get things done
• bring in others to help
• be the architect for security
• think about the bigger picture, of how to apply your knowledge
• find the multipliers

Whilst the panel lean towards distributing responsibilities and finding allies to do work on your behalf (lucky them), I was just hearing:

• Yes, SOAR
• Yes, SOAR
• Yes, SOAR
• Yes, DBot
• Yes, SOAR
• Yes, SOAR

Essentially, automate the hell out of it.  If you have 1 or 2 people, surely automation is the only way to scale.

Example:  User submits a request (priority 3?), which goes to the bottom of the priority queue, which takes 2 days to find, and 30 minutes to fix.  That’s a long wait for something simple.  People see the IT team as blockers, not enablers.

Now imagine SOAR performing all those simple/fast requests with a turnaround of 2 minutes.   2 days wait -> 2 mins wait is a 144,000% increase in service you give without any additional head count or training.

Use Cases every sized organisation has to deal with:

• Whitelisting domains
• Joiners Movers Leavers (JML)
• Blocking IP
• Enriching IOC for teams
• Phishing 

This has a few benefits:

• Smaller ticket queue
• Increased perception of service (your end users feel that your service is always-on)
• More time and less interruptions whilst you are doing more important tasks

That’s just the basics of what SOAR does. Taking that further and using all the functionality of SOAR Case Management here too:

• The remaining 50% of tickets are already prioritised so you wont miss a high priority just because you ‘started at the top of the inbox and worked down’
• Playbooks can interact with non-SOAR users meaning your end users always had the possibility to “click here to escalate this to a security person now” if it can’t wait
• Daily/Hourly reporting to you on the queue size with nice breakdowns on priority, incident type etc.
• Even cooler would be SOAR checking the baseline of tickets. Imagine a security incident happens and many users report a similar issue, if we see this rise we contact you straight away “warning, phishing requests at 205% of normal”

Honestly I could go on lots more on how SOAR in the background supports a smaller team, but I hope this makes the point?

Andy

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…

Andy

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.

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

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

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

(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

A nice easy place to start in SOAR is with an inbound alert (SIEM, email, manual creation/API) that updates a blacklist and maybe informs a user.  It’s something we all do, often, and this can be a nice money and time saver.  But as we look bigger and wider what other technologies can we bring in as we mature alongside SOAR?

So here is my attempt to list all the categories of Security Tools that we as professionals can have at our disposal.  I’m confident this isn’t exhaustive but it opens the eyes to the possibilities, I wonder how many you have and whether they are reaching their potential (I’ll talk more in the future about how we can use them together).

• Firewalls
• Endpoint, EDR, MDM
• Proxy, Reverse proxy, WAF, CASB
• Messaging (Email, SMS, etc)
• NIDS / HIDS / IPS
• DLP and Data Discovery
• Full Packet Capture and Netflow
• Asset Management
• Malware Detonation service
• Vuln Scanning and Management
• Deception and Network Access Control
• SIEM
• Case Management and Ticketing
• User management and Authentication
• Threat Intelligence
• UEBA
• …more?

https://www.ncsc.gov.uk/guidance/20-critical-controls

https://www.sans.edu/cyber-research/security-laboratory/article/security-controls

https://en.wikipedia.org/wiki/Security_controls