Please don’t laugh, but alongside our “Testing Security” research project (that will likely skew towards the high-maturity security audiences) we are also doing a new research project for mainstream organizations in Q1 2018. It will focus on starting your detection and response effort.
Now, a security skeptic may say “why teach an organization to focus on THREAT DETECTION and RESPONSE in 2018, if they have not figured it out by now, they are hopeless …”
We disagree! We do in fact see plenty of organizations actually wanting to improve their security and to evolve away from their sole [and failing] focus on prevention. However, many simply do not know how to do it in their circumstances [e.g. you cannot start with hiring a team of 10 for your 24/7 SOC or blowing your budget on a big fat UEBA with nothing left for the personnel to run it or buying threat intel and then going “whaaaat is all that data?”].
So, while there is plenty of good advice on many particular aspects of threat detection and response, what we think we need here is a usable guidance on how to embark on this journey, written for the mainstream, not for the elites with their high maturity security ops teams, security data lakes and threat hunters.
BTW, and I cringe that I need to say it, but “focus on detection and response!” does NOT mean “better prevention is not needed” – of course it is needed. But – and my analogy risk is high here – just as in the physical realm “if you just use better door locks, you can avoid funding the police” sounds thoroughly idiotic, so it is in the realm of cyber…
A contrarian may further opine thus: “why tell the low-maturity organizations to ‘start the effort’, shouldn’t they use an MSSP or an MDR?” Well, guess what, if you do use an MSSP, you will need your own response capabilities anyway [to respond to what an MSSP or an MDR sends you … duh!]. Hence, you need to know how to start a detection and response effort. Furthermore, to separate “a clown-class” MSSP from genuine excellence you need some basic understanding of what they do – hence detection and response again.
Now, those of my readers who were involved with threat detection (back then, it was called intrusion detection… how quaint and 1990s :-)) and response since 1995 may still laugh. OK, laugh away then … but please share what would have helped YOU to start with detection and response … EVEN IF it was in 1995…
Finally, as some of you recall my poll, this research aligns perfect with these findings, skewed though they may be.
What are some of our plans for this?
- Baby’s first threat detection: how to start if all you have is “firewalls + AV” (or: firewalls and SSL)?
- So you hired your first security analyst, what should he/she do for maximum impact (“one person detection and response capability”)?
- We got a log management tool, so where do we go next? To SIEM? To network monitoring? To endpoint monitoring?
No real call to action to vendors here, but if you have any creative tips for starting the detection and response effort, we are all ears…
Read Complimentary Relevant Research
2019 Planning Guide Overview: Architecting Your Digital Ecosystem
Technical professionals are confronting increasingly complex technology ecosystems. They must overcome this complexity to create solutions...
View Relevant Webinars
Gartner Top 10 Strategic Predictions for 2018 and Beyond
The future is filled with technology-based innovation and disruption. Yet, the pending disruptions are taking on new forms and increasing...
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.