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?

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:

• Baby ASO: A Minimal Viable Transformation for Your SOC
• Learn Modern SOC and D&R Practices Using Autonomic Security Operations (ASO) Principles
• EP187 Conquering SOC Challenges: Leadership, Burnout, and the SIEM Evolution
• EP180 SOC Crossroads: Optimization vs Transformation — Two Paths for Security Operations Center
• EP73 Your SOC Is Dead? Evolve to Output-driven Detect and Respond!

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.

*** This is a Security Bloggers Network syndicated blog from Stories by Anton Chuvakin on Medium authored by Anton Chuvakin. Read the original post at: https://medium.com/anton-on-security/not-a-soc-faq-this-is-soc-fmd-e9eeee2429e1?source=rss-11065c9e943e------2