Greetings from San Francisco and the RSA conference! It's been a great week of sessions, meetings, and vendor presentations. While listening to all these great talks, one thing came to inspire me about what I believe we're all seeing in the industry; misconfiguration and mismanagement.

Defense in depth, the process of adding layers of protection to secure an area. It's not a new concept at all. In fact, it has been the mantra of the security industry for at least a decade if not longer and well before that was a widely used military tactic. Usually, this strategy is used to prevent an attacker from exploiting one of your security tools, like a firewall or IPS, and bypassing what would be a single layer of protection. Now I agree that adding layers of well thought out protection makes a ton of sense when those layers are all managed properly, updated regularly, and the threat you're trying to solve is preventing an attacker from bypassing your security device through its own vulnerabilities. The problem though is that nearly every day, and every breach we've heard about in the news, that is not the case. More often than not, the attacker used a valid communication pathway to access a publicly available service, like a web server, and then used an exploit in the code of that application or un-patched service to gain access into the infrastructure. On top of that, the attacker is usually very likely to gain access to other systems in the corporation by simply pivoting from the system they just compromised.

So, why is this possible? Well, it seems that administrators are spending the majority of their time just "keeping the lights on". Meaning our security and operations teams are stretched far too thin. What suffers when administrators don't have enough time? Almost every single time, the existing product/server is going to suffer so that the schedule is kept for the new project(s) being worked on. What that means is that instead of an administrator keeping existing servers patched and up to date in a timely manner, or keeping your security tools functioning properly to begin with, they are actually working on new stuff for the corporation. It also means you need to protect your security teams from becoming the "Jack of all trades, master of none."

This is a horrible conundrum for an IT organization. So back to my title question, the answer is "it depends". I would argue it makes more sense to have 1 layer of really well implemented security and process before going to add other layers. If you can't make that one layer work properly 100% of the time, then you need to go back to what you were doing and make it work. This may not be the answer the business owners want to hear, but it's the answer they MUST hear.

Far too often I see companies move to technologies like DLP, Anomaly Detection, GRC, etc before they've even mastered how to deploy and use an IDS or IPS. That's like learning to jump hurdles in the Olympics before you've mastered walking. The other thing I can tell you is that with Cloud/ITaaS/'X'aaS coming to a datacenter near you soon, the world of security is getting both more complicated and simpler all at the same time. We're seeing customers collapse network domains in the favor of reducing VLANs, but at the same time they are implementing tools like vShield App that allow for network segmentation at layers 2-4 networking level. These new tools make designing networks a more complicated thought process up front, but in the long run simplify the management of those networks.

We face a series of similar paradoxical situations in the future of virtualized security and compliance technologies. It's incumbent upon us all to learn these tools quickly, act on their proper implementation, and by all means make sure to test our designs before we move on to that next layer of our Defense in Depth strategy. I know the temptation and push is strong to add the latest and greatest, but it'll do you no good if it's implemented incorrectly.





Rob Babb is a Senior Systems Engineer on the Security and Compliance Specialist team at VMware.