Gartner Blog Network


Back to Basics: Indispensable Security Processes for Detection and Response

by Anton Chuvakin  |  February 8, 2018  |  4 Comments

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.

  1. 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.
  2. 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.
  3. 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
  4. 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.
  5. 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:

Category: incident-response  monitoring  security  

Anton Chuvakin
Research VP and Distinguished Analyst
5+ years with Gartner
17 years IT industry

Anton Chuvakin is a Research VP and Distinguished Analyst at Gartner's GTP Security and Risk Management group. Before Mr. Chuvakin joined Gartner, his job responsibilities included security product management, evangelist… Read Full Bio


Thoughts on Back to Basics: Indispensable Security Processes for Detection and Response


  1. Tyler says:

    I would add developong response policies and plans based on general and specific types of threats and an overarching policy based upon liability and risk to the organization.

    I would enjoy talking with you further if you are interested.

    Oh and in the early 2000s we called it real time threat response based on intrusion detection 😉

  2. […] talked about starter detection and response processes, now what about the tools? Namely, tools that help you start your detection and response […]



Comments are closed

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.