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 (and keep in mind that this is a very early draft and even the level at which processes are described may well change). Also, while reading the below this 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, with an 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 detect what you need to detect and where you need to do so. We [Augusto and myself] present a very well-engineered (but definitely not lightweight) process for that 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:
This is a Security Bloggers Network syndicated blog post authored by Anton Chuvakin. Read the original post at: Anton Chuvakin