Keeping Control during Automation in SOAR

I previously posted “but donโ€™t forget that over-automating can lead to reduced visibility“.  Machines do what we tell them (to a fault), how do we retain some control?

Example – At Demisto, when you ask for access to our help-center, the email is processed by a SOAR playbook to validate the request, manage access, and respond to the user, like self-service. 

However recently it took a wrong turn so I had to open and take control and override our usual logic.  This was easy as each incident (which the automation belongs to) is tracked like case management, so we simply “re-open”, open up the playbook to find the issue, and correct it.

So what best practise can we utilise to keep control over SOAR?

Human Checks – Before any critical steps (e.g. pushing IP to firewall) you might want to ask a human analyst to verify (either using ticket management, email/slack question, or using the Mobile App)

Playbook Design – Many playbooks have forks based upon automated decisions. Consider the chain of events in a ticket if is restarted from a certain point taking a different action. Do any original steps have to be undone? A good design allows users to quickly make changes and walk away.

Human Notifications – If anything is seen slightly odd (too much data in a reply) then continue a human analyst of the observation with a direct link “click here to see the playbook in operation”

Summary Page – All key data and decisions should be in the tickets summary page, so any analyst/team leader having a quick view can see the key points of ticket (e.g. User not found resulting in playbook taking a specific course of action)

Andy

SOAR in Banks

Great article
https://biztechmagazine.com/article/2019/07/how-security-orchestration-and-automation-make-banks-cyber-resilient?utm_source=linkedin.com&utm_medium=referral

“Visibility is critical in all contexts: network, endpoint, DNS, email, web and, most importantly, the hybrid cloud, where monitoring workloads and accessibility presents a big challenge.”

Agreed, in a way SOAR isn’t a security tool, it orchestrates them, so make sure you have visibility. Even a free/open/cheap tool with SOAR can show value if it’s integrated to a complete workflow.

Andy

best-practices-for-the-soc-team

Lots of great points in the article, I’ve taken a few out below.
https://www.infosecurity-magazine.com/opinions/best-practices-for-the-soc-team/

“Organizations are being forced to hire Tier 1 analysts with little or no experience, and spread their Tier 2 analysts too thin”

To help your Tier1 team, either hire anyone in IT and just do data collection, or use Automation:

” …if there is no judgment to be made, you donโ€™t need a human analyst โ€“ you need to automate. “

To help your Tier2 team

“Analysts should be equipped with tools that can help them automatically investigate incident “

Andy

Bruce Schneier Talk

I recently attended a talk by Bruce Schneier talking about Automation and his new book “Click here to kill everybody” (charming)

Though the talk wasn’t specific to SOAR, it’s still relevant to IT Security I think this borders on similar concepts to SOAR, so here are my personal notes from the talk

  • There will always be vulnerabilities as all software is crap…. we want it cheap, fast and now
  • All computers are platforms and therefore extensible by design
  • Bigger means complex, more attack surface, more insecure
  • Putting 2 Systems together which were not designed together, creates a vulnerability, it’s no one’s fault but it’s there
  • Security hasn’t changed in 10 years but computers platforms are changing a lot (IOT etc)
  • Stealing blood type information from a hospital is bad, changing blood type information is worse (integrity vs confidentiality)
  • Computers break at scale, all at once, think contact-less hotel door, once a vulnerability is discovered every door is ‘broken’ in the same moment
  • It’s a style of failure we’re just not experienced in dealing with
  • Best way to patching legacy kit is simply throw it away and rebuild
  • Replace a phone battery yearly, replace a fridge every decade
  • The world will be swamped with non patched devices soon
  • We are moving further away from “thing to person auth” and even more to “thing to thing” auth, we don’t know how to do this on the scale needed
  • Imagine a city of 1,000,00 cars needing “thing to thing” auth to inform and talk to each other
  • Cyber skills gap, so we need to automate more
  • How do you build something secure, on top of unsecure parts?

The talk summarised with the need for regulation from the govt.

  • Regulation is the only answer. You trust a restaurant won’t poison you, and that the building you’re under wont collapse on you as it’s regulated. Regulation isn’t perfect but it works all around us quite well.
  • Regulate in one place, and every territory should benefit. i.e. companies don’t want 2 code bases, it’s simpler and cheaper to to work it out for the area with the highest standards then use this in other locations

Some food for thought?

Andy

Automating responsibly

I recently wrote about adding a personal touch in SOAR:
https://www.socops.rocks/index.php/2019/04/29/adding-a-personal-touch/

One point included an end user who wants to break out of automation and talk direct to a human with a “click here” button, so they don’t feel ignored/shunned.

I noticed recently this is how a lift works. Lots of buttons to trigger certain functions, but also an alarm button to press when something goes wrong… responsible automation.

My own SOAR demo is guilty of not doing this, it intelligently and informatively acknowledges the request and thanks the user, but until my playbook has reached a conclusion the end user is just a stressed and panicking passive bystander.

Here is my new version, you can see the original acknowledgement email which now gives your staff the ability to ‘break out’.

And here is the logic I wanted: increase the severity, assign it to a team member and start the response SLA counter

Results:

  • Responsible automation
  • Automation that still runs in parallel by default
  • A way to track and SLA time things where things go wrong
  • And ultimately, users that don’t feel neglected

Andy

‘Rethinking the SOC for Long-Term Success’

https://www.sans.org/cyber-security-summit/archives/file/summit-archive-1561408460.pdf

Great deck (shame I couldn’t watch it too)! I’ve worked in a SOC and in my role I talk to a different SOC every day and agree massively with all of this. Of course I also love how they mention SOAR ๐Ÿ˜‰

The only thing I would add is that Recommendation 1-4 all require having more time (without being bogged down on alert overload) so Recommendation 5 (SOAR) maybe should be promoted to Recommendation 1?

But I work on SOAR, so of course I would say that ๐Ÿ˜‰

Andy

death-of-the-tier-1-soc-analyst

Link :
https://www.darkreading.com/analytics/death-of-the-tier-1-soc-analyst/d/d-id/1330446

” A combination of emerging technologies, alert overload, and fallout from the cybersecurity talent shortage is starting to gradually squeeze out the entry-level SOC position “

“The Tier 1 SOC analyst will become more like the Tier 2 analyst”

“Gone will be the mostly manual and mechanical process of the Tier 1 SOC”

Yup yup and yup.

Andy

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…

Andy

death-siem-rise-soar

Source Article

https://www.linkedin.com/pulse/ashes-we-all-fall-down-death-siem-rise-soar-alissa-valentina-knight/

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

Andy

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

https://www.domaintools.com/resources/survey-reports/ponemon-survey-2018#

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!

Andy