/awesome-soc

A collection of sources of documentation, as well as field best practices, to build/run a SOC

Awesome SOC

A collection of sources of documentation, and field best practices, to build and run a SOC (including CSIRT).

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

NB: Generally speaking, SOC here refers to detection activity, and CERT/CSIRT to incident response activity. CERT is a well-known (formerly) US trademark, run by CERT-CC, but I prefer the term CSIRT.

ToC

Must read

For a SOC

For a CERT/CSIRT

Globally (SOC and CERT/CSIRT)

Fundamental concepts

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

See: SOC/CSIRT Basic and fundamental concepts.

SOC and CSIRT core

From logs to alerts: global generic workflow

Quoted from this article:

image

Following the arrows, we go from log data sources to data management layer, to then data enrichment layer (where detection happens), to end-up in behavior analytics or at user interaction layer (alerts, threat hunting...). All of that being enabled and supported by automation.

SOC/CSIRT architecture of detection

Based on CYRAIL's paper drawing, that I've slightly modified, here is an example of architecture of detection (SIEM, SIRP, TIP interconnections) and workflow: image

  • Sensors log sources are likely to be: audit logs, security sensors (antimalware, FW, NIDS, proxies, EDR, NDR, CASB, identity threat detection, honeypot...).

Mission-critical means (tools/sensors)

Critical tools for a SOC/CSIRT

Critical sensors for a SOC

Critical tools for CSIRT

Other critical tools for a SOC and a CERT/CSIRT

  • Internal ticketing system (NB: not SIRP, not for incident response!):
  • Knowledge sharing and management tool:

SOAR

What is SOAR?

As per Gartner definition:

image

Hence 3 critical tools (see above): 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 (script):

  • Online URL automated analysis:

  • 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 response (incident response, containment/eradication steps):

IT/security Watch (recommended sources)

Detection engineering

Cf. detection engineering page.

Threat intelligence

Cf. threat intelligence page.

Management

Cf. management page.

HR and training

Cf. HR and training page.

IT achitecture

Have a single and centralized platform ('single console')

As per NCSC website:

Indications of an attack will rarely be isolated events on a single system component or system. So, where possible, having a single platform where analysts have the ability to see and query log data from all of your onboarded systems is invaluable. Having access to the log data from multiple (or all) components, will enable analysts to look for evidence of attack across an estate and create detection use-cases that utilise a multitude of sources. By creating temporal (actions over a period of time) and spatial (actions across the estate) use-cases, an organisation is better prepared to address cyber security attacks that occur system wide.

Disconnect (as much as possible) SOC from monitored environment

The goal is to prevent an attacker from achieving lateral movement from a compromised monitored zone, to the SOC/CSIRT work zone.

Enclave:

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

  • Only log collectors and WEF should be authorized to send data to the SOC/CSIRT enclave. Whenever possible, the SOC tools pull the data from the monitored environment, and not the contrary.

SOC’s assets should be part of a separate restricted AD forest, to allow AD isolation with the rest of the monitored AD domains.

Endpoints hardening:

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/CSIRT 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.
  • Implement admin bastions and silo to administrate the SOC env (equipments, servers, endpoints):
    • My advice: consider the SOC environment as to be administrated by Tier 1, if possible with a dedicated admin bastion. Here is a generic drawing from Wavestone's article (see Must read references): image
    • Recommended technology choices: Wallix PAM

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. ...