Strategic threat intel before patching? Malware reversing before firewalls? Honeypots before NIPS? Are you freaking insane?!
Well, are you? Why are you doing this? What good do you think it will do? Well, it gets your boss’s boss points for “being innovative” and “using cutting edge tech”… I will give you that. Also, it lets you play with new tech to prepare for your next job…maybe. However, apart from these dubious points, you probably mostly get FAIL – at least in regards to security the environment and reducing risk.
Many of my readers know me as an unrelenting fan of approaching hard security problems with the security maturity lens in mind. For example, here are some posts related to security maturity – SIEM maturity, IR maturity [BTW, also see this fun overview of some security maturity discussions]. When we give advice to Gartner GTP clients, we want to “tint” it based on their security maturity – we want them to grow (if they want/need to), but grow in a realistic, achievable manner, in order to make our advice not just “right”, but also feasible.
One common pattern that emerged in my work – an anti-pattern, rather – is a concept of “jumping maturity” or “stand/crawl/RUN/walk” pattern. For example:
- You can barely patch windows … but are deploying a honeypot and want internal threat intel!
- Log collection is limited and analysis non-existent … but you now want full-packet capture and network forensics
- The organization can barely review alerts … but is determined to hunt and profile threat actors.
- Not enough personnel is available to use basic security technologies, yet more advanced technologies with more tuning requirements are being purchased.
- The organization can barely manage the basic, noisy threats, yet they want to go after the advanced ones.
All the above items smell like FAIL! While there is clearly no ONE right sequence to implement security safeguards, as it depend on your business, risks, threats, regulations, etc – there are some examples of sequences that are very likely to be wrong since the layers of solid security architecture can only be built on …well.. other solid layers and not on wishful thinking.
As all good rules, this better have exceptions! What are some of those?
- Good monitoring at a badly secured network MAY make sense (trade control for visibility model); mind you, it is not a happy model and it can get stressful as hell, but likely better than poorly secured network with poor monitoring
- If your environment is very non-traditional (like, say all SaaS and clouds), some of the security basics are either useless, wasteful or – rarely – harmful. In this case, some more advanced stuff (CASB? UEBA?) may in fact be the recipe to WIN
There you have it! Keep this in mind when planning your security process improvement and tech acquisition.
Select blog posts tagged “philosophical”:
- Security: Automate And/Or Die?
- On Tanks vs Tractors
- Enable the Business? Sometimes Security Must Say “NO”…
- Defeat The Casual Attacker First!!
- Critical Vulnerability Kills Again!!!
- Security Essentials? Basics? Fundamentals? Bare Minimum?
- On “Defender’s Advantage”
- Security And/Or/Vs/Not Compliance?
- Bye-bye, Compliance Thinking. Welcome, Military Thinking!
- Security Chasm Illustrated
Read Complimentary Relevant Research
Five Golden Rules for Creating Effective Security Policy
Policy writing is a risk communication exercise that is frequently performed by people who lack the skills needed to create good security...
View Relevant Webinars
Office 365 and Google Apps for Work: Security Comparison
Google Apps for Work is increasingly a viable option for many businesses as a replacement for Microsoft Office. As CISOs consider their...
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.