![Highlights of Modern SOC: “Help”
“Every modern SOC is a hybrid SOC” -- Anton Chuvakin [source]
THIS OUTSOURCES WELL
- Deeper malware analysis
- Threat intelligence
- SIEM, EDR and other tool
management and tuning
- SOC tool tuning and use case
analysis
- Managed threat hunting
THIS OUTSOURCES BADLY
- Remediation of threats
- Full cycle of incident response
- Insider threat detection
- Business- and application-specific
threat detection
THIS DOES NOT OUTSOURCES AT ALL
- Accountability for security success
- Governance of security program](https://image.slidesharecdn.com/modernsoctrends-201028184734/85/Modern-SOC-Trends-2020-11-320.jpg)
Uploaded byAnton Chuvakin
Modern SOC Trends 2020
Modern SOCs face expanding attack surfaces, security talent shortages, and too many alerts from numerous tools. A modern SOC organizes teams by skills rather than levels, structures processes around threats instead of alerts, performs threat hunting, uses multiple visibility tools including logs and network data, and automates tasks through SOAR. It consumes and creates threat intelligence, elegantly uses third-party services, and does not treat incidents as rare or center itself around a single tool like a SIEM. A modern SOC recommends handling alerts but recognizing that is not the entire role, making analysts and engineers collaborate, hiring skills over levels, automating routines, and keeping fuzzy tasks for humans while using third parties for some tasks.
More Related Content
Similar to Modern SOC Trends 2020
More from Anton Chuvakin
Modern SOC Trends 2020
- 1. Modern SOC Trends Dr.Anton Chuvakin Google Cloud Security / Chronicle; ex-Gartner
- 2. Outline ● SOC refresherfor 2020 ● WHY | WHAT | HOW ○ Why MODERN SOC? ○ What modern SOC is? ○ What modern SOC isn’t? ○ How to evolve your SOC to this? ● What to expect next?
- 3. “A security operationscenter provides centralized and consolidated cybersecurity incident prevention, detection and response capabilities.” -- Gartner SOC is first a TEAM. Next a PROCESS. And it uses TECHNOLOGY too. What is a SOC?
- 4. Why Modern SOC? Force1: Expanding attack surface More things to secure... Force 2: Security talent shortage More things to secure than people... Force 3: Too many alerts from too many tools More things to secure that all scream for attention...
- 5. Modern SOC ● Teamsis organized by skill, not rigid level ● Process structures around threats, not alerts ● Threat hunting covers for cases where alerts never appear ● Multiple visibility tools, not just logs ● Automation via SOAR works as a force multiplier ● Threat intelligence is consumed and created ● Elegantly uses third party services
- 6. NOT Modern SOC ●Inspired by IT helpdesk philosophy ● Treats incidents as rare and abnormal ● Focuses on alert pipeline, and pairs alerts to analysts ● Centered on a SIEM (SOC = SIEM analyst team) ● Has walls between alert handlers and alert tuners ● Threat intelligence is sometimes consumed
- 7. Highlights of ModernSOC: People
- 8. Highlights of ModernSOC: Tools Logs (such as via SIEM) Network data (such as via NDR) Endpoint data (such as via EDR) Other data (deception, RASP, etc)
- 9. Highlights of ModernSOC: Processes
- 10. Highlights of ModernSOC: Detection Engineering ● Detection content versioning ● Proper “QA” for detection content” ● Content (code) reuse and modularity ● Cross-vendor and cross-tool content ● Metrics and improvement
- 11. Highlights of ModernSOC: “Help” “Every modern SOC is a hybrid SOC” -- Anton Chuvakin [source] THIS OUTSOURCES WELL - Deeper malware analysis - Threat intelligence - SIEM, EDR and other tool management and tuning - SOC tool tuning and use case analysis - Managed threat hunting THIS OUTSOURCES BADLY - Remediation of threats - Full cycle of incident response - Insider threat detection - Business- and application-specific threat detection THIS DOES NOT OUTSOURCES AT ALL - Accountability for security success - Governance of security program
- 12. Recommendations ● Sure, handlealerts, but be aware that this is not your entire world ● Make analysts and engineers friends; no walls in SOC ● Hire skills, not levels ● Automate routines, and keep fuzzy tasks for people (hunt) ● Prepare to trust 3rd parties with some tasks ● Keep your SIEM, but be aware that SOC visibility is broader than logs
Editor's Notes
- #4 “SOCless SOC” and “Fusion center”
- #5 https://www2.deloitte.com/content/dam/Deloitte/us/Documents/about-deloitte/us-deloitte-google-cloud-alliance-future-of-the-SOC-whitepaper.pdf
- #6 “SOCless SOC” and “Fusion center”
- #7 “SOCless SOC” and “Fusion center”
- #9 https://medium.com/anton-on-security/back-in-2015-while-working-on-a-gartner-soc-paper-i-coined-the-concept-of-soc-nuclear-triad-8961004c734
- #11 https://medium.com/anton-on-security/can-we-have-detection-as-code-96f869cfdc79 Detection content versioning so that you can truly understand what specific rule or model triggered an alert — even if this alert was last July. This is even more important if you use a mix of real-time and historical detections. Proper “QA” for detection content that covers both testing for broken alerts (such as those that never fire or those that won’t fire when the intended threat materializes, and of course those that fire where there is no threat) and testing for gaps in detection overall. “False positives” handling, naturally, get thrown into this chute as well. Content (code) reuse and modularity of detection content, as well as community sharing of content, just as it happens for real programming languages (I suspect this is what my esteemed colleague describes here). As a reminder, detection content does not equal rules; but covers rules, signatures, analytics, algorithms, etc. Cross-vendor content would be nice, after all we don’t really program in “vendor X python” or “big company C” (even though we used to), we just write in C or Python. In the detection realm, we have Sigma and YARA (and YARA-L too). We have ATT&CK too, but this is more about organizing content, not cross-vendor writing of the content today. I also think that getting to cross-tool detection content would be great, wherever possible. For example, you can look for a hash in EDR data and also in NDR; and in logs as well. SIEM alone won’t do. Metrics and improvement are also key; the above items will give you plenty of metrics (from coverage to failure rates), but it is up to you to structure this process so that you get better. While you may not be looking at building a full CI/CD pipeline for detections to continuously build, refine, deploy and run detection logic in whatever product(s), I’ve met people who did just that. To me, these people really practice detection as code.