Let’s talk modern SOC tools. The analogy I’d like to use is that of a “Nuclear Triad” – a key cold war concept. The triad consisted of strategic bombers, ICBMs and missile submarines (strictly speaking, submarine missiles – SLBMs) and sought to “significantly reduce the possibility that an enemy could destroy all of a nation’s nuclear forces in a first-strike attack.”
 |
 |
 |
Your SOC should have its own nuclear triad of visibility:
- SIEM – if I need to explains this, please read something else instead 🙂
- Network Forensics (NFT) – tools that can capture all network traffic (full packet capture), extract metadata (including application layer, L7 metadata such as HTTP user-agent, DNS query response, FTP username, email subject, etc) and payloads, retain some raw traffic and metadata, enable searching and analysis. There are several commercial tools, and then there are moloch and OpenSOC; Bro sort of fits in as well. [See more details here and in this GTP document]
- Endpoint Detection and Response (EDR, formerly ETDR) – typically agent-based tools to capture execution, local connections, system changes, memory activities, etc. There are a lot (A LOT!) of commercial tools, and then there are GRR, MIG (update: not really MozDef, as I mentioned in the previous version) as osquery, sort of. [See more details here and in this GTP document]
Similar to the above, your “SOC triad” seeks to significantly reduce the chance that the attacker will operate on your network long enough to accomplish their goals.
Of course, your SOC will make use of other tools and capabilities, such as threat intelligence (TI) data, malware sandboxes and reversing tools [to push the above analogy a tad too far, maybe this is like a suitcase nuke? Very much an auxiliary weapon, but also very cool? :-)] as well as some workflow system to organize all your work [strategic forces undeground command center?]. However, I always think of SIEM + NFT + EDR as “SOC nuclear triad” of visibility!
There you have it! Enjoy!
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.
Comments are closed
11 Comments
Fully agree! In addition these (SIEM/logs, network traffic, endpoint data) should be considered data sources into an integrated system which enables both behavior-based detective analytics, analyst anomaly hunting, as well as forensic investigations.
Thanks for the comment, Matt. Indeed, this seems to match the needs of both detection (monitoring) and response use cases.
Thanks for a good analogy.
But Analysts are still prescribing SIEM as a one stop shop for customers. Do you think SOC as a framework and what you explained above deserves to be a defined category rather than individual tools assessment which is creating a confusion in prospective buyers minds.
Thanks for the comment.
>But Analysts are still prescribing SIEM
>as a one stop shop for customers.
Indeed, I still see “SIEM is the only SOC tool you will ever need” narrative.
HOwever, I don’t think that “SOC tools” is a category. Some people may get all 3 capabilities from 1 tool, while others will choose 2 or 3 tools from the categories mentioned in the post. I don’t think we are talking one unified category here
These are definitely useful tools for the SOC, however another one that occurs to me is the “meta” tool that collates, correlates and prioritises alerts for the SOC team’s response.
A proper SOC will have a workflow component. This component can be implemented within a SIEM (think ArcSight’s case customization) or in an outside tool (any kind of ticket/helpesk-type tracking software.) Alternatively I’ve seen people use Wiki software.
An issue or anomaly will be detected by the SIEM or via manual analysis (reporting, hunting for bug-du-jour, etc.) Then the workflow will be started. The workflow itself should be defined by an incident management or handling plan and the two components should compliment one another.
Depending upon corporate culture or how well IT is ingrained within an enterprise, the incident handling/management plan is “bigger” than the SOC (strategic) while the workflow for managing the incident at the lowest layer is a function of the SOC (tactical.)
Ah, but the debate that the tool you mention is NOT a SIEM needs to happen first…
Still, there is definitely a need for a workflow tool (mentioned in my post), even though some people will successfully use SIEM workflow features for this.
Anton, this is the second time you’ve mentioned MozDef in an EDR context. I figure MozDef is more like a SIEM or a helper automation tool, it doesn’t have endpoint capabilities. Why keep mentioning it in this context?
Well, sure, MozDef has SIEM features too, from what I can figure. I suspect I am basing my possibly inaccurate judgement on the usage of that tool I’ve seen….now that I am thinking about it, in the install I’ve seen MIG was the EDR, and MozDef was sort of the layer above that. SO, yes, I should probably stop calling it EDR.
Anton, very interesting post. On the other hand, i strongly beleve there is a need for an orchestrator, able to coordinate workflows and further actions. Still Gartner defines this category as SIRP. Security Incident Response Platform, with the purpose of supprting both CSIRT and SOC.
Dario, thanks lot for the comment. Indeed, the workflow/orchestration layer is also VERY important (whether SIRP or not). In this post, I wanted to touch on the sensors/visibility, but I am always keeping the workflows in mind!