Future-Proof Security into DevOps

If you don’t think about security when you start going down the DevOps path you’re going to get caught by surprise when someone tells you that what you’re doing is insecure. At that point you’ll have to retrofit security into the process – and that’s painful.

DevOps is meant to be flexible so you certainly don’t want to go through any kind of security review every time you roll out a new version of your application. But the DevOps process can only be flexible and automated if no-one has to think about changes introduced by a new version and determine if these changes require changes to security infrastructure ….if that happens everything grinds to a halt.

The only way to do this right is to insert security into the DevOps process from the beginning. Which means that you have to organize things in a way that allows you to release new versions without going through a security review at the end. A security review is sometimes necessary, and can be streamlined, of course, but you still need a human to review the security change and decide if it’s a yes or a no –which takes you from a cycle time of minutes to a cycle time of days.

Inserting security into the DevOps process requires discipline and needs some prep work. One way to do this is by blueprinting the IP addresses and the ports in advance. Then, when you need to make changes to your firewall rules be disciplined and restrict yourself to predefined pools of IP addresses that are already whitelisted in the firewall policy. Now, when DevOps rolls out a new version of the application, adds front-end capacity, or switches between servers, there is no need to touch the firewall rules, and no need for a security review or a human in the loop, because you have all the future server’s connectivity needs pre-approved!

For example, suppose your applications have front-end servers and you anticipate that their number could fluctuate depending on demand. Place all the front-end servers in one block of pre-defined IP addresses but keep some addresses in the block unassigned. Now for the discipline part: don’t use those unassigned IP addresses for anything other than front-end servers. If you follow this tip you will be able to write firewall rules that refer to the whole block of front-end servers’ addresses as a single object. This provides the necessary connectivity for the existing servers, and also for any future servers you may need to spin up (as long as you give them addresses from in the designated block).

On the flip side, you need to make sure you’re developing versions of applications that do not require additional connectivity that was not foreseen when you wrote the security policy. So make sure your developers don’t decide to use a new protocol or port “just because it’s cool”.

There are technologies that help in future-proofing the process. If you use cloud-based environments (such VMware NSX or Amazon Web Services) you can define your security policies using various types of dynamic objects or Security Groups. This way when a new server gets powered up it automatically belongs to the correct grouping and the desired security policies are applied to it.  Be aware, however, that things will get complicated when traffic to or from the new server needs to cross the cloud boundary and traverse other security devices which are unaware of the dynamic grouping inside the cloud.

While discipline and future proofing are key to a successful and secure DevOps process, it’s also important to be careful not to stifle creativity or be dogmatic. Occasionally applications will require new types of data and new types of connections in their future versions. When that happens, you’ll need to go through a security review because you’ll need to change the firewall policy. So it’s a balancing act: on the one hand, you should future-proof the firewall rules so they are broad enough to support future flexibility, and on the other hand you need to have the discipline within the development teams to be aware that some types of connectivity are sanctioned and to the extent possible they should favor re-using them in future application versions.