Code Monkey home page Code Monkey logo

awesome-soc's Introduction

Awesome SOC

A collection of sources of documentation, and field best practices, to build/run a SOC.

Those are my view, based on my own experience as SOC/CERT analyst and team manager, as well as well-known papers. Focus is more on SOC than on CERT.

NB: Generally speaking, SOC here refers to detection activity, and CERT/CSIRT to incident response activity.

TOC

Must read

For a SOC:

For a CERT:

Globally (SOC and CERT):

Fundamental concepts:

Concepts, tools, missions, attack lifecycle, red/blue/purple teams:

See: SOC/CSIRT Basic and fundamental concepts.

SOC and CISRT core: architecture of detection:

As per CYRAIL's paper here is an example of architecture of detection (SIEM, SIRP, TIP ): image

Critical means (tools/sensors)

Critical tools for a SOC/CERT:

Critical sensors for a SOC:

Critical tools for CERT:

Other critical tools for a SOC and a CERT:

SOAR

What is SOAR?

As per Gartner definition:

image

Hence 3 critical tools (see below): SIRP, TIP, SOA, on top of SIEM.

And in my view, SOAR is more an approach, a vision, based on technology and processes, than a technology or tool per say.

Simple and commonly needed automation tools:

  • Online automated Hash checker:

  • Online automated sample analyzer:

  • (pure) Windows tasks automation:

  • SaaS-based (and partly free, for basic stuff) SOA:

Common automations:

My recommendations for detection (alerts handling)

Try to implement at least the following automations, leveraging the SOA/SIRP/TIP/SIEM capabilities:

  • Make sure all the context from any alert is being automatically transfered to the SIRP ticket, with a link to the SIEM alert(s) in case of.
    • Leverage API (through SOA) if needed to retrieve the missing context info, when using built-in integrations.
  • Automatically query the TIP for any artefacts or even IOC that is associated to a SIRP ticket.
  • Automatically retrieve the history of antimalware detections for an user and/or endpoint, that is associated to a SIRP ticket.
  • Automatically retrieve the history of SIEM detections for an user and/or endpoint, that is associated to a SIRP ticket.
  • Automatically retrieve the history of SIRP tickets for an user and/or endpoint, that is associated to a new SIRP ticket.
  • Automatically query AD or the assets management solution, for artefact anrichment (user, endpoint, IP, application, etc.).

My recommendations for reaction (incident response, containment/eradication steps)

  • Block an IP on all firewalls (including VPN), and SWG.
  • Block an URL on SWG.
  • Block an email address (sender) on SEG.
  • Block an exe file (by hash) on endpoints (leveraging EDR, Sysmon, or AppLocker).
  • Reset an AD account password.
  • Disable an AD account (both user and computer, since computer account disabling will block authentication with any AD account on the endpoint, thus preventing from lateral movement or priv escalation).
  • Report a (undetected) sample to security vendors, via email.

IT/security Watch

Management

SOC organization:

  • No real need for tiering (L1/L2/L3)

    • this is an old model for service provider, not necesseraly for a SOC!
    • as per MITRE paper (p65):

    In this book, the constructs of “tier 1” and “tier 2+” are sometimes used to describe analysts who are primarily responsible for front-line alert triage and in-depth investigation/analysis/ response, respectively. However, not all SOCs are arranged in this manner. In fact, some readers of this book are probably very turned off by the idea of tiering at all [38]. Some industry experts have outright called tier 1 as “dead” [39]. Once again, every SOC is different, and practitioners can sometimes be divided on the best way to structure operations. SOCs which do not organize in tiers may opt for an organizational structure more based on function. Many SOCs that have more than a dozen analysts find it necessary and appropriate to tier analysis in response to these goals and operational demands. Others do not and yet still succeed, both in terms of tradecraft maturity and repeatability in operations. Either arrangement can succeed if by observing the following tips that foreshadow a longer conversation about finding and nurturing staff in “Strategy 4: Hire AND Grow Quality Staff.”

    Highly effective SOCs enable their staff to reach outside their assigned duties on a routine basis, regardless of whether they use “tier” to describe their structure.

  • 3 different teams should be needed:

    • security monitoring team (which does actually the "job" of detecting security incident being fully autonomous)
    • security monitoring engineering team (which fixes/improves security monitoring like SIEM rules and SOA playbooks, generates reportings)
    • build / project management team (which does tools integration, SIEM data ingestion, specific DevOps tasks, project management).

CERT organization:

  • Designate among team analysts:
    • triage officer;
    • incident handler;
    • incident manager;
    • deputy CERT manager.
  • Generally speaking, follow best practices as described in ENISA's paper ("Good practice for incident management", see "Must read")

TTP (attack methods) knowledge base reference:

  • Use MITRE ATT&CK
  • Document all detections (SIEM Rules, etc.) using MITRE ATT&CK ID, whenever possible.

Data quality and management:

  • Implement an information model, like the Splunk CIM one:
    • do not hesitate to extend it, depending on your needs
    • make sure this datamodel is being implemented in the SIEM, SIRP, SOA and even TIP.

Key documents for a SOC:

  • Document an audit policy, that is tailored of the detection needs/expectations of the SOC:
  • Document a detection strategy, tailored to the needs and expectations regarding the SOC capabilities.
    • The document will aim to list the detection rules (SIEM searches, for instance), with key examples of results, and an overview of handling procedures.

Detection quality controls:

Detection capabilities representation standard:

  • Use Security Stack Mappings to picture detection capabilities for a given security solution/environment (like AWS, Azure, NDR, etc.):

SOC detection capabilities simplified representation:

SOC Self-assessment:

CERT/CSIRT self-assessment:

Reporting:

  • Generate metrics, leveraging the SIRP capabilities to do so:
    • top security incident types
    • top applications associated to alerts (detections)
    • top detection rules triggering most false positives
    • top detection rules taking the longest to be handled
    • number of false positives
    • top 10 SIEM searches (detection rules) triggering false positives
    • number of new detection use-cases being put in production.
    • number of detection rules which detection capability and handling process have been confirmed with purpleteaming session, so far
    • most seen TTP in detection
    • most common incident types
    • mean time to triage (assign) the alerts
    • mean time to handle (verify and be ready for incident response) the alerts
    • top 10 longest tickets before closure
    • percentage of SIEM data that is not associated to SIEM searches (detection rules)

Recommended timeframes to compute those KPI: 1 week, 1 month, and 6 months.

HR and training

Recommended SOC trainings:

Regular trainings:

Certifications:

Recommended CERT/CSIRT trainings:

Regular trainings:

Certifications:

IT achitecture

Disconnect SOC from monitored environment

  • Implement SOC enclave (with network isolation), as per MITRE paper drawing: image

To go further

Must read:

Nice to read:

SOC sensors, nice to have:

Management:

  • Define SOC priorities, with feared events and offensive scenarios (TTP) to be monitored, as per risk analysis results.

    • My recommendation: leverage EBIOS RM methodology (see above).
  • Leverage machine learning, wherever it can be relevant in terms of good ratio false positives / real positives.

    • My recommendation: be careful, try not to saturate SOC consoles with FP.
  • Make sure to follow the 11 strategies for a (world class) SOC, as per MITRE paper (see Must Read).

  • Publish your RFC2350, declaring what your CERT is (see "Nice to read" above)

Harden SOC environment

  • Implement hardening measures on SOC workstations, servers, and IT services that are used (if possible).
  • Put the SOC assets in a separate AD forest, as forest is the AD security boundary, for isolation purposes, in case of a global enterprise's IT compromise
  • Create/provide a disaster recovery plan for the SOC assets and resources.

Appendix

License:

CC-BY-SA

Special thanks:

Yann F., Wojtek S., Nicolas R., Clément G., Alexandre C., Jean B., Frédérique B., Pierre d'H., Julien C., Hamdi C., Fabien L., Michel de C., Gilles B., Olivier R., Jean-François L., Fabrice M., Pascal R., Florian S., Maxime P., Pascal L., Jérémy d'A., Olivier C. x2, David G., Guillaume D., Patrick C., Lesley K., Gérald G., Jean-Baptiste V., Antoine C. ...

awesome-soc's People

Contributors

cyb3rxp avatar

Watchers

James Cloos avatar

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.