by Anton Chuvakin | October 28, 2016 | Comments Off on SOC Webinar Questions Answered
As promised, here my Gartner SOC webinar Q&A (webinar recording) – admittedly I am keeping some answers short since there were so many of them [some questions are edited for clarity; those that refer to specific vendors are excluded]:
- How do you see the role of BRO IDS when it comes to hunting?
- We see Bro as a key source for layer 7 network traffic data (traffic metadata), definitely useful for hunting activities. Bro to ELK or Bro to commercial search and/or analytics tool are common scenarios for usage.
- Businesses wide across industries are moving toward autonomous processes. How SOC will be able to survive the autonomous wave? Will we see autonomous SOC?
- Right after we see autonomous police robots, me thinks. In other words, never. Security will never be fully automated, please lay this idea to rest.
- Can Osquery or OSSEC be considered EDR tools?
- Our original thinking on EDR (back then: ETDR) capabilities makes osquery an almost-EDR. OSSEC (IMHO) is not.
- How a MSSP can act to be as valuable as an in-house SOC for the customers? How to make it less out-sourced and more like an integrated component?
- Short answer: it can’t A longer, but less pithy answer lies somewhere here, with some hints also here.
- Understand SOC is an entity of people process and technology. What are the implications of having a SOC offshore?
- Not sure I can give a short answer to this one, we do see some legitimate reasons for an offshore SOC (such as for follow-the-sun model), and I think you can make it work. But then again, if this is seen as “can we hire people who are 20% as good as ours, but at 30% of the cost?” then you can guess the result…
- How are orchestration tools different from SIEM tools?
- Eh… they are just different, OK? SIEM collects and analyzes logs and orchestration tools provide security operations and incident response workflow and [some] automation. However, some SIEM tools had decent workflow components, and more are building them. So, for now they are different, but may collide later…
- Where do you organizationally locate the SOC in order to be independent? Who does the SOC report to?
- A common scenario is SOC –> Head of Security Operations –> CSO or CISO. How independent is that? – Well, it depends :–) We discuss some of this in our recent SOC paper.
- How critical is including your SOC operations with an enterprise GRC program?
- It feels like an obvious one: since GRC covers all security and risk activities, it sure will cover SOC as well. Not sure what else to add here…
- Our client doesn’t like being asked too many questions about their infrastructure, being an MSSP how do we tackle such a situation?
- That’s a very tough one! We insist in our MSSP guidance that the client should provide that information, otherwise MSSP will fail to protect them. If client refuses, you have a choice a/ admit that you are being “a checkbox MSSP” and will probably be sued by a client if they are hacked, or b/ insist that this information is a must for service deliver.
- I’ve got an incident management tool, does that fit into your spectrum of “workflow” tools?
- It fits, most likely. As we discuss in our IR guidance, security incident response and security operations workflow tools are converging. However, many IT [NOT security] incident management make a poor SOC workflow tool, while some (yes, I mean ServiceNow, really!) enable excellent SOC/CIRT workflow capabilities.
- Of the 20 FTEs required to comfortably implement 24/7 SOC, what would be the typical allocation of duties? I.e. alert triage, threat hunting, management, etc?
- We discuss this in our SOC paper. I can’t think of a short answer, but the long one is in the paper. Also, if you cannot get to our paper, feel free to fish for this information in MITRE SOC book [PDF], it is there somewhere too…
- Does/should a modern SOC also monitor physical access (e.g. Data Center) access?
- Frankly, it varies. We see it occasionally in different models; this seems to be more of an exception than the rule. It is probably more common to see some physical security data feeds flow into a SOC than to have SOC be truly responsible for physical security monitoring.
- Would you also consider “identity context” (i.e. who is a user or who does a account belong to, the user’s role etc.) to be a pre-requisite [for SOC monitoring]?
- I’d say that it is very important, but not truly essential. If you cannot find the asset, you cannot monitor it. If you don’t have the user context, the monitoring for some things becomes very hard. For example, a lot of people run decent SIEM implementation without identity integration. We will touch more on this in our upcoming UEBA / UBA papers. Please don’t take this as “identity is not important”, but as “asset is HUGELY important.”
- For companies that don’t have the maturity or resources necessary to build a modern SOC, what steps should they take or what options are available to them?
- Can’t think of a short way to answer this one. Sorry, please read our SOC paper. It is very likely that the steps will involved working with third party providers such as MSSPs.
- How would you rate the priority of a [secure physical] facility for a monitoring-focused SOC?
- While a lot of people see the rise of a virtual SOC as a sign of our times, many large enterprise SOCs are very much tied to a secure facility. You can do a lot in chat and via phone, but sometimes you want that huddle over coffee and a couple of big screens….
Enjoy the webinar recording here.
Related posts about webinars:
- Upcoming Webinar: Design a Modern Security Operation Center (SOC)
- SIEM Webinar Questions – Answered
- Upcoming Webinar: SIEM Architecture and Operational Processes
- Upcoming Gartner Webinar: DLP Architecture and Operational Processes
- DLP Webinar Questions – Answered!
- Upcoming Gartner Webinar: The Future of Security Monitoring and SIEM
- Webinar on Security Monitoring of Public Cloud Assets
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.