Home

Awesome

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.

My motto is: without reaction (response), detection is useless.

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

Table of Content

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

MITRE references:

Prepare for handling incidents by defining incident categories, response steps, and escalation paths, and codifying those into SOPs and playbooks. Determine the priorities of incidents for the organization and allocate the resources to respond. Execute response with precision and care toward constituency mission and business.

Dedicated page

Cf.: SOC/CSIRT Basic and fundamental concepts.

SOC core

MITRE references:

Consolidate and harmonize views into tools and data and integrate them to maximize SOC workflow. Consider how the many SOC tools, including SIEM, UEBA, SOAR, and others fit in with the organization’s technical landscape, to include cloud and OT environments

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

Mission-critical means (tools/sensors)

MITRE references

Choose data by considering relative value of different data types such as sensor and log data collected by network and host systems, cloud resources, applications, and sensors. Consider the trade-offs of too little data and therefore not having the relevant information available and too much data such that tools and analysts become overwhelmed.

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

IT/security Watch

MITRE reference

Tailor the collection and use of cyber threat intelligence by analyzing the intersection of adversary information, organization relevancy, and technical environment to prioritize defenses, monitoring, and other actions.

Recommended sources

SOAR

MITRE references

Consolidate and harmonize views into tools and data and integrate them to maximize SOC workflow. Consider how the many SOC tools, including SIEM, UEBA, SOAR, and others fit in with the organization’s technical landscape, to include cloud and OT environments.

Dedicated page

Cf. SOAR page

Detection engineering

MITRE reference

Develop situational awareness through understanding the mission; legal regulatory environment; technical and data environment; user, user behaviors and service interactions; and the threat. Prioritize gaining insights into critical systems and data and iterate understanding over time.

Choose data by considering relative value of different data types such as sensor and log data collected by network and host systems, cloud resources, applications, and sensors. Consider the trade-offs of too little data and therefore not having the relevant information available and too much data such that tools and analysts become overwhelmed.

Enhance SOC activities to include threat hunting, red teaming, deception, malware analysis, forensics, and/or tabletop exercises, once incident response is mature. Any of these can improve the SOCs operating ability and increase the likelihood of finding more sophisticated adversaries.

Dedicated page

Cf. detection engineering page.

Threat intelligence

MITRE reference

Tailor the collection and use of cyber threat intelligence by analyzing the intersection of adversary information, organization relevancy, and technical environment to prioritize defenses, monitoring, and other actions.

Dedicated page

Cf. threat intelligence page.

Management

MITRE reference

Develop situational awareness through understanding the mission; legal regulatory environment; technical and data environment; user, user behaviors and service interactions; and the threat. Prioritize gaining insights into critical systems and data and iterate understanding over time.

Structure SOCs by considering the constituency, SOC functions and responsibilities, service availability, and any operational efficiencies gained by selecting one construct over another

Engage within the SOC, with stakeholders and constituents, and with the broader cyber community to evolve capabilities and contribute to the overall security of the broader community.

Determine qualitative and quantitative measures to know what is working well, and where to improve. A SOC metrics program includes business objectives, data sources and collection, data synthesis, reporting, and decision-making and action

Enhance SOC activities to include threat hunting, red teaming, deception, malware analysis, forensics, and/or tabletop exercises, once incident response is mature. Any of these can improve the SOCs operating ability and increase the likelihood of finding more sophisticated adversaries.

Dedicated page

Cf. management page.

HR and training

MITRE reference

Create an environment to attract the right people and encourage them to stay through career progression opportunities and great culture and operating environment. Plan for turnover and build a pipeline to hire. Consider how many personnel are needed for the different SOC functions.

Dedicated page

Cf. HR and training page.

IT achitecture of a SOC

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:

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

Harden SOC/CSIRT environment

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