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?
The Gartner Blog Network provides an opportunity for Gartner analysts to test ideas and move research forward. Because the content posted by Gartner analysts on this site does not undergo our standard editorial review, all comments or opinions expressed hereunder are those of the individual contributors and do not represent the views of Gartner, Inc. or its management.