Jumping Security Maturity FAIL!

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