Blog post

Back to Basics: Indispensable Security Processes for Detection and Response

By Anton Chuvakin | February 08, 2018 | 3 Comments

securitymonitoringincident response

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:

Comments are closed


  • 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 😉