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?
Read Complimentary Relevant Research
Top Strategic Predictions for 2019 and Beyond: Practicality Exists Within Instability
Technology-based change is happening continuously, and most organizations struggle to see the change in advance. Continuous change can...
View Relevant Webinars
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.