Modern SOC Trends 2020
•
0 likes•779 views
Modern SOC Trends by Anton Chuvakin, presented in Netherlands October 2020
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Modern SOC Trends 2020
Similar to Modern SOC Trends 2020 (20)
More from Anton Chuvakin
More from Anton Chuvakin (20)
Recently uploaded
Recently uploaded (20)
Modern SOC Trends 2020
- 1. Modern SOC Trends Dr. Anton Chuvakin Google Cloud Security / Chronicle; ex-Gartner
- 2. Outline ● SOC refresher for 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 operations center 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? Force 1: 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 ● Teams is 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 Modern SOC: People
- 8. Highlights of Modern SOC: 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 Modern SOC: Processes
- 10. Highlights of Modern SOC: 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 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
- 12. Recommendations ● Sure, handle alerts, 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
- “SOCless SOC” and “Fusion center”
- https://www2.deloitte.com/content/dam/Deloitte/us/Documents/about-deloitte/us-deloitte-google-cloud-alliance-future-of-the-SOC-whitepaper.pdf
- “SOCless SOC” and “Fusion center”
- “SOCless SOC” and “Fusion center”
- 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
- 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.