Aggregator

Not a SOC FAQ! This is SOC FMD!

Security Boulevard
2 months 2 weeks ago

Somebody asked me this profound question that (a) I feel needs an answer and that (b) I’ve never answered in the past:

If you run a SOC (or an equivalent D&R team), what things should you require (demand, request, ask, beg … depending on the balance of corporate power) of other teams? Dall-E via Copilot image gen, steampunk

Think of this not as SOC FAQs, but SOC FMDs — Frequently Made Demands…

To frame this a but, this is not about executive sponsorship (you should always “request” executive support, otherwise some efforts are not even worth starting, frankly), or other SOC success “pre-requisites.” This is about the key ongoing “asks” SOC makes of other teams and departments so that it has a chance of being successful with its mission over time.

So when asked this question, my ex-analyst mind went and produced a 3 pillar framework:

  1. Assets information
  2. Useful signals delivery
  3. Triage partnership

Let’s review these three.

Assets Information

If a SOC is tasked with detection and response, they better know the lay of the land that they are defending. “Defender’s Advantage” and all that. If you don’t know the terrain better than the attacker, you already lost.

There is of course a lot of nuance to it, but at some basic level, there should be a way for a team deploying anything to report this to SOC for coverage, and for a SOC to ask a team for their list of assets to be monitored for threats. Assets here may mean servers (hey, the 1990s are NOT reality over, joking aside), cloud assets, SaaS services, applications, etc (it would also be handy for ZT efforts).

Summary: if your mission is to protect assets, ask for the list of assets (sorry, this came out very Capt Obvious, but this is in fact missed in some cases)

Useful Signals Delivery

You should ask for logs! Duh, is that you, Captain Obvious, again? Well, you should ask for specific logs relevant to your mission, you should ask for compliance with a sensible logging policy, and to cover custom applications, you should ask for compliance with a sensible (this means: short!) log standard.

Don’t just ask for “logs”, ask for logs and other telemetry you can use given the tools, process and people you have. Ask for relevant context data too. If you need EDR deployed, ask. If you need to sniff traffic because EDR cannot go there, ask for NDR.

If you need logging enabled, ask for types you need (logging policy, short and sweet). If you need them delivered, ask for access to supported log pipelines or mechanisms. If they need to develop logs for custom applications, offer a log standard, then ask for compliance with it (log standard must be short and thus implementable by unmotivated developers…)

Don’t fall victim to “application is deployed, app owner never provides logs, app owner assumes that SOC will detect any threat” syndrome (this is real, please don’t laugh!). If you cannot get the logs, ask for Plan B (you do have a Plan B?).

Basic Plan B examples may include: I really want EDR here, but I can’t have it; I can then ask for logs + NDR to mitigate the visibility gap. Another: I really want logs from this application, but can’t have it. I can get OS logs, would it help? Yes, but only if I get these events, and also get logs from another system that this one connects to.

Triage Partnership

You have assets, you have signals … what do you do with all this? Well, to be very fair to many solid SOC teams, sometimes the answer is “not a whole lot” or “who the hell knows.” Unless… unless the team that runs the system (IT, DevOps, etc) and/or the team that owns the system (business, etc) helps figure out what the thing is saying via those logs.

This means you do need to ask for alert triage help. Yes, I know, I know: many SOCs are not used to this, and prefer to ad hoc it for those “rare” cases where they need help. My favorite example where ad hoc does NOT work well is DLP alerts. Back in my analyst days, there was a lively debate among the analysts covering DLP about who should own DLP, security or business (!). In that vision, even if security owns DLP, business has to play an equal role otherwise “X emailed Y about Z” and “X uploaded Y to Z” alerts destroy the SOC due to its lack of capability to understand whether this is apocalyptic, merely bad, or perfectly normal, just rare.

Distributed alert response is a thing at some elite D&R teams (famous example, more current example). But even if SOC owns triage, it needs to ask for help. This is needed even more for data related alerts (What is this data and how valuable is it? Can it go out that way?) and application security alerts (What is the app threat model? Can the app do that? Should it?). As a side note, there is probably another blog here about how to plan appsec to D&R collaboration…

Anything BIG I missed? Anything else you as a SOC leader demanded from other units and departments?

Related blogs:

Not a SOC FAQ! This is SOC FMD! was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

The post Not a SOC FAQ! This is SOC FMD! appeared first on Security Boulevard.

Anton Chuvakin

Cribl Gets $319M on $3.5B Valuation to Boost Data Management

DataBreachToday.com
2 months 2 weeks ago
Google Ventures Leads Round as Sales of Cribl's Vendor-Agnostic Data Tools Grow
Cribl has completed a $319 million Series E funding round led by Google Ventures. The financing pushes the company’s valuation to $3.5 billion, with backing from prominent investors as Cribl's data engine technology continues to be rapid adoped by enterprises globally.

McLaren Health: IT Operations Fully Back Online Post-Attack

DataBreachToday.com
2 months 2 weeks ago
Restoration Completed Days Ahead of Schedule But Still a Lot of Catch-Up Work to Do
McLaren Health says its IT systems are fully restored a few days earlier than expected, following an Aug. 6 ransomware attack that disrupted clinical and administrative operations at its 13 hospitals and other facilities. The Michigan-based entity had expected the recovery to last through August.

Managed ad