TL;DR Summary
- AI and automation are critical to increasing SOC speed, quality, and reducing analyst burnout.
- Job rotation and cross-training enhance team empathy and reduce alert fatigue.
- Continuous Improvement: A modern SOC must operate as an evolving program, not a fixed project.
- Clear metrics and ROI reporting turn the SOC from a cost center into a value generator.
Building strong inter-team relationships accelerates incident response and organizational resilience.
Abe:
Hey everybody, welcome back to another session of Graylog GO! I’m Abe, VP of Customer Enablement at Graylog, and today I’m joined by an awesome guest — Marty McDonald, Senior Domain Advisor at Optiv. I’ll let him introduce himself.
Marty:
Thanks, Abe. It’s great to be here. As Abe said, I’m a Senior Domain Advisor at Optiv. I get to work with clients in the pre-sales process and help solve problems. I spend most of my time around the SIEM and SOC space and have been doing that since about 2005. Looking forward to our session today.
Abe:
Awesome, thanks Marty! Marty brought a fantastic, polished presentation, but I interrupted him to make this more conversational. Marty has tons of experience in the SIEM space, and has seen a lot of SOCs built. Today, we’re digging into lessons learned, modern SOC evolution, and how some older ideas might be getting a little outdated.
Abe:
So Marty, what would you say is driving the move toward a modern SOC?
Marty:
Sure. I think a few key things. AI is everywhere now — it’s helping with speed, insight, and quality in security operations. Threats are evolving rapidly, and dwell times need to shrink more and more. So, investigation and response must happen faster than ever.
We still struggle with alert fatigue — it was an issue 20 years ago, and it’s still not fully solved. We need better, more enriched insights from our tools. Continuous improvement is critical — tuning for false positives, false negatives, and measuring our outcomes.
Abe:
(Accidentally reading an AI instruction prompt) — sorry, wrong tab! Haha, back to our session.
Abe:
So when looking at alert fatigue, what’s working today? What’s your advice?
Marty:
Yeah, a few areas. First, making the job more fun: rotating roles (tier 1 analyst one week, threat hunter the next, content engineer another) gives variety and builds empathy.
Second, better event enrichment: eliminate “swivel chair” operations where analysts have to check multiple consoles.
Third, automation: anything repetitive should be automated to free up analysts for higher-value work.
Abe:
Turning the question back on me, nice! I agree — cross-pollination builds empathy and resilience. We also see the impact of tool rationalization — mapping tools to actual needs and controls.
Marty:
Exactly. And on the topic of people: the best SOCs I’ve seen meet regularly with different log source owners (like Active Directory teams) and business teams (Legal, Communications). It helps build real relationships, so when the worst happens, people know who to call and how to act.
Plus, informal relationship-building (grabbing coffee, casual chats) really helps smooth collaboration when crises happen.
Abe:
Yes — the human side is critical. You can’t solve alert fatigue just technically; you need to address people and processes too.
Marty:
Absolutely. Plus, unclear mission and goals are another source of fatigue. SOC teams need clear, measurable goals, not just “secure harder!”
Abe:
That resonates. SOC roles can be grindy — it’s a great entry point, but can be tough without clear progression or mission.
So, tactically, how do you recommend SOCs structure things?
Marty:
One of my favorite models:
Self-knowledge: Know what you’re protecting.
Threat knowledge: Know what you’re defending against.
Visibility: Ensure complete and enriched visibility.
Detection: Build solid detection content and hunt regularly.
Investigation: Have clear processes, enable automation.
Response: Have fast, documented response procedures.
Measure and Inform: Show value and improvements to leadership.
Marty:
Mapping your technology stack to a security framework (like MITRE ATT&CK) helps spot gaps and overlaps. And looping threat hunting into detection content avoids repeated hunts.
Abe:
Exactly. Having that feedback loop is key. And measuring success — showing reduced Mean Time to Detect (MTTD) and Respond (MTTR) — shows SOC value as ROI, not just cost.
Marty:
Right. Leadership wants to see real metrics, not just blinking dashboards. Reporting meaningful improvements builds support for continued investment.
Abe:
I love seeing how Graylog’s direction aligns with these best practices — building stronger detection, investigation, and response. It’s validating!
Marty:
Yeah, it’s great when product direction and industry need line up so well.
Abe:
You mentioned challenges — let’s dig into where building a SOC is hard.
Marty:
Absolutely.
Too many alerts: No team can humanly handle thousands daily. Prioritization and enrichment are vital.
Manual processes: Still far too common. Clients often struggle with SOAR (Security Orchestration, Automation, and Response) projects — they try to automate massive complex playbooks first, burn out, and give up. Start small.
Analyst burnout: Constant stress and fear of missing true positives drive turnover.
Abe:
Burnout is heartbreaking. We see it too — lots of smart, passionate people end up exhausted because security never “ends.”
Also, using tools for things they’re not designed for — like stretching SIEMs into DDoS detection — leads to frustration.
Marty:
Right. SIEMs are for logs, correlation, and enrichment, not blocking controls. Misusing tools increases fatigue and risk.
Abe:
And without clear response playbooks, even the best alerts don’t help if you can’t act fast enough.
Marty:
Exactly. And if you want to automate later, you must have processes documented first.
Abe:
You touched earlier on architecture — can you walk through that?
Marty:
Sure.
Ingest logs efficiently and normalize them immediately.
Only send critical logs to the SIEM to avoid data swamp.
Store everything else affordably (e.g., S3, Azure Blob Storage) for future replay or forensics.
Modularize everything: make systems pluggable and flexible.
Support both security and broader operational needs.
Abe:
Yeah — managing hot, warm, and cold tiers of data is crucial for scaling affordably.
Marty:
Exactly.
Also:
Threats constantly evolve, so SOCs must be treated as a program, not a project.
Regulatory environments change (e.g., CMMC 2.0), requiring continual adjustment.
Stay flexible and growth-minded.
Abe:
Perfectly said. Continuous improvement is essential.
Marty:
And — as we keep saying — well-measured SOCs are well-managed SOCs. Metrics matter:
Are we hitting risk reduction targets?
Are we closing vulnerabilities faster?
Are response times improving?
Are phishing rates going down?
And, importantly, are we reporting what leadership actually cares about — not just pretty graphs.
Abe:
Exactly.
And remember: Program, not project. Cybersecurity isn’t something you “complete”; it’s a continuous improvement journey.
Marty:
Yep.
And when building a SOC:
Know where you want to be (not everyone needs a world-class SOC).
Budget appropriately for your goals.
Work toward measurable improvements over time.
Abe:
Fantastic closing! Thank you, Marty, for the amazing insights.
And thanks to everyone for attending Graylog GO!
