Security Automation = Good Security Practice

As I shoveled even more snow, I was starting to think about automation, as in how could I get something to shovel the snow for me, which lead to thinking about automation within the cloud. I see lots of discussion about automation in the cloud. Many of my friends and colleagues are developing code using Puppet, Chef, vCenter Orchestrator, etc. This development is about producing the software defined datacenter (SDDC). However, I see very little in the way of security automation associated with SDDC.
Take for example, the process in Figure 1. Currently, there are most likely many, if not 1000s, of attacks against your environment. There may be some form of detection (IDS, Anti-virus, Anti-malware), and eventually a response to the attack if it was egregious enough.

The problem we have is that “Detection” today is often by happenstance. People are looking at the right set of data either long after the attack occurred or at the right time. For example, I get emails from my systems listing odd happenings. Some of those odd happenings are malformed web transactions. Many of those malformed web transactions are related to attacks to get critical files off the system. Unfortunately, while the email is automated, it is automated once a day, I have to read it and then act upon it.
It would be far simpler if the detection system was tied into the response system so that such attacks would automatically be blocked immediately after detection. And there are tools that will do this for you, but they tend to be rather heavy handed. Permanently or even temporarily blocking an IP address could impact your business, as with attack traffic there is also legitimate traffic.

New Ways of Doing Things

There are newer tools that implement somewhat older concepts to aid in this. Instead of detecting the attack, they surround the attack so that it does very little damage. This looks like Figure 2. If the tool is intelligent enough, it would then allow the attack to be detected as tries to go outside the allowed paths for a given application, process, or user.

Bromium, Symantec CSP, and SElinux (native to all Linux implementations) implement the ‘surround the attack’ methodology. Does this mean the attack was successful? It could be, but access to critical system pathways would not be allowed. The concept is very old and is referred to as mandatory access controls. However, these mandatory access control mechanisms need to also feed into detection and eventually a response. The immediate response was met (with the surround the attack mechanism) but the attack could still live on a system, and it should eventually be cleared away.

DevOps and Security Automation

However, if we were to fix the code, then perhaps attacks would be limited. This implies there is more process necessary. Figure 3 shows some of that process. I am sure there is more we can add, but it builds upon the need for feedback. While it is fairly easy to add static code analysis into your code repository (products from Core Impact, Fortify, etc.), the feedback loops for new attacks is the key part of this automation that still needs to be developed.  This is the key to security automation as there are new attacks happening every day, new ways to exploit the system.

Figure 3 shows there there are at least 5 feed back loops necessary. Any newly detected attack needs to feed back into the surround technology in use so that it can improve its whitelisting and sandbox mechanisms, feed back into your detection stage to improve the time to detection, but most importantly feed back to the developers to let them know to change their coding practices. In addition, we need to add more static code tests to enforce best practices for coding and feed back into our automated pen-test tools to add more tests as necessary.
This level of automation and feedback is where we need to go with security automation. Firewalls and such are just not enough; we need to fix many of these issues further back, in the code and perhaps the architectures of systems. This needs to be the bedrock of any SDDC not just for security, but to fix any problem. Software can only do what we tell it to do and has limited intelligence today. The SDDC needs to include feedback loops for security automation, but also automation to fix other problems that may arise.
Given this is foundational, is SDDC doing it today? For security? Not at all but we may be on the cusp. I Have great hopes given VMware’s new Investment In Puppet Labs.