Blog post

Is Your SOC your CSIRT?

By Augusto Barros | June 27, 2018 | 3 Comments

threat detectioninsights and philosophicalincident response

As we move forward on updating our SOC research, Anton and I are back to the discussion about the existence of two separate entities in organizations, the SOC and CSIRT. This has been the “standard model” we’ve based some of our research on. It looks more or less like this:

Security Operations Center: Runs security monitoring, owning the “detect” step. When do the initial triage of generated alerts and submit the confirmed incidents to the…

Computer Security Incident Response Team: Receives the confirmed incidents from the SOC and proceed with the “response” step, going further into investigation steps (what’s the real extension and impact of the breach, etc) and proceed through the traditional IR model: Containment, remediation, return to normal, lessons learned, etc).

Our impression was that smaller and medium, as well as low/medium maturity organizations would normally operate with a SOC doing all the activities above. Big enterprises, as well as those evolving to a high maturity state, would eventually have the model of two separate entities. But after some time collecting data from client calls and reviewing some other sources of data, my impression is that most organizations, regardless of size or maturity, have both “detect” and “respond” roles as part of the same group, the SOC. So, what is the “best” model?

At this point I believe that a single entity, the SOC, is preferable. Why? Because the line between detection and response is becoming blurry, maybe even ceased to exist. Hunting activities, for example, are primarily a way to detect threats, but operating in “response” style. The use of SOAR tools by both functions would also point to the need of having those groups together, as it would be hard to define exactly who “owns” the tool and is responsible for its evolution. Threat intelligence related activities are another reason to keep them together. A single TI consumption role can provide insights for detection and response practices.

Another reason to keep those groups together is workforce management related. One of the main issues with SOCs is staff attrition. It’s very hard to keep “level 1” analysts motivated, especially if those working on night shifts, weekends, etc. Having the IR and hunting activities as part of the same group expands the opportunities for job rotation, an efficient way to provide more interesting jobs and even more perspective on career evolution.

However, there are also reasons to keep those groups separate. Some people believe that keeping those functions separate would allow them to focus on their main objectives (detection vs response). There are also cases where there are needs for multiple SOCs (due to multiple subsidiaries or regional offices), but some ability (or desire, due to higher sensitivity of the outcomes) to keep IR centralized. Finally, strategic plans for outsourcing (mostly for the detection activities) may require the functions to be separate. I don’t think this is a requirement, as most SOCs today are operating in a hybrid fashion in terms of outsourcing, but it may be a way for an organization to keep the responsibilities for an eventual partner more clearly defined.

What do you think? Is everything part of THE SOC or is there still room for the SOC/CSIRT model?


Leave a Comment


  • Le Toux says:

    You make the assumption that CSIRT=technical incident response
    If I quote one of gartner research is that if an organization should afford only one FTE it should be a coordination person

    If I rephrase to « should the incident coordination should be in the SOC » my answer will be a NO.
    Indeed having a CSIRT (most of the time a CERT) at corporate level can leverage more easily management support legal etc
    A soc in the IT subsidiary will have difficulties not doing technical job

  • I’m on the all-SOC side of this discussion. A LOT of the activity isn’t clearly a threat. It can be reporting on activity that poses no threat, compliance concerns, and then there are the many anomalies to investigate. If you separate teams, you don’t develop the skills and knowledge in IR unless you pass lots of events to them. If you pass too much, the SOC loses knowledge of the network behavior that informs analysis. Keep it all in the SOC and create an integrated IR process. Then you don’t have to worry about the gray between incident and event.

  • Glenn says:

    At one time I followed the SOC does it all, however in today’s market it has become easier to split the teams into 2. The reason is not all triggered event requires IR, however the event still needs to be looked at with initial triage. Yes, always a concern of attrition however internally if you have it planned out there is not a great deal of attrition as you build a career path where some members start within the SOC by following established procedures/processes and can move them over to IR as they become more qualified.