For our new research project focused on starting your detection and response effort, we are thinking about an essential bundle of security operations processes needed for such effort. Sort of “security operations processes you must get right in the beginning” inspired by what is done here for all security processes.
So, let’s start, but please keep in mind that this is a very early draft and even the level at which processes are described may well change in the future paper. Also, while reading the below, think of this as “baby’s first security detection and response” and not what a mature SOC will have after 15 years of conscious improvement.
- For sure, security incident response process is king. “No IR – no go” for any detection and response effort, even heavily outsourced. Naturally, we cover IR in our “How to Plan and Execute Modern Security Incident Response”, but there is a lot of IR in that doc. Here we are talking about a plan, some procedures perhaps, a part-time IR coordinator role (no IR FTEs likely) and some ongoing preparation work.
- Alert triage process – for sure. If you detect, you will see alerts. If you have alerts, you will have to process them and decide what to do (automation can help you with this, but will not do it for you). And, yes, the same with MSSP alerts as well; in fact in “How to Work With an MSSP to Improve Security” we talk a lot about such “joint triage” process.
- Lightweight use case management process (likely inclusive of detection content tuning) probably needs to be on the list too. How lightweight? At least to check the relevance of vendor’s OOB content to your risks/threats and perhaps to do some easy tuning (like “do not apply this rule to this server”, “run this baseline over these users”, etc). This should also include some form of validation that you consistently detect what you need to detect and where you need to do it. We [Augusto and myself] present a very well-engineered (but definitely not lightweight) process for this in “How to Develop and Maintain Security Monitoring Use Cases”
- Lightweight threat assessment process focused on gaining awareness of the threats you face (via threat intelligence or not) is probably a must, at least because it helps you answer questions about the detection tools/content you need; we cover a full process in “How to Plan and Execute a Threat Assessment”, but for this we need to shrink it down quite a bit. And then shrunk a bit more.
- Metrics and reporting process is a must at least because at lower maturity levels of your detection and response effort you will need to justify it a lot. And then, over time, you will still need executive motivation to keep going.
Reactions? Thoughts? Major omissions?
P.S. If you want to say THREAT HUNTING, please reread the instructions
Blog posts related to this project:
Read Complimentary Relevant Research
How to Evaluate Cloud Service Provider Security
Security and risk management leaders continue to experience challenges to efficiently and reliably determine whether cloud service providers...
View Relevant Webinars
Securing the Internet of Things: An Architectural and Risk-Driven Approach
Security is a top concern and significant inhibitor to Internet of Things (IoT) adoption. In this Webinar, Erik T. Heidt will identify...
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.