Category: Uncategorised

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

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

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

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

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

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

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

https://www.cyberdefensemagazine.com/seven-myths-about-security-orchestration/

7 great points that come up often. A couple of these I’ve already touched on in this blog (e.g. automation doesn’t replace head count), but the above link does a much better job exploring in detail than I can.

Go read it!

Andy

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

SOC world problems

Andy