Baking security into the DevOps lifecycle – why and when

DevOps delivers a flexible framework that enables companies to deliver new innovations faster to market.  However, there are lingering questions about its impact on security.  With multiple functional teams collaborating on development, and so many moving parts in the process, security is often not incorporated into the process, rather it’s tacked on at the end – which ultimately negates many of the benefits of DevOps.

Yet the earlier that security is baked into a DevOps process the better and safer – both for the company developing the application, and the application’s users.  A SANS report into application security found that resolving defects in a live, production application is twice as expensive in terms of person-hours as fixing them during customer beta testing, and six times more costly than eliminating them during initial testing.

So let’s take a look at how, when and why security should be introduced and automated into DevOps.

The DevOps lifecycle looks like this. Your developers build new versions of an application. When the new functionality is ready the application is migrated from the development to the test environment. There, it undergoes QA testing. Once those efforts are completed, the application is migrated again to the final lifecycle stage – the production environment.

Now, to make these processes as realistic as well as secure as possible, you would typically have firewalls in each of the three environments, segmenting between the clients, servers and the databases. This segmented structure is replicated in the test and production environments, like this

Of course, each firewall in each environment has rules in place in order to allow the necessary traffic in that environment.  Across the three DevOps environments, the structure of these firewall rules is the same (because each is allowing the same services between the equivalent systems), but the objects in those rules are different (because the IP addresses of the application servers and the databases are different across the three environments). Therefore, these objects need to be adjusted for each environment in the lifecycle.

Let’s consider an example in which new functionality is added to the application that requires connectivity to a second database.  In the development environment, a new rule needs to be added to the firewall protecting the database. This rule will allow traffic between the application development server, and the second database.  So far, so good.

But, when the updated application is migrated from development into the test environment, naturally all the application code needs to be migrated over from the first environment to the second.  But that’s not enough on its own:  to maintain security while allowing approved traffic, the firewall rules also need to be copied over to the test environment.

And here’s the catch – it’s not as simple as merely copying the rules between environments.  As we’ve already mentioned, while the firewall rule structures are the same in all three environments, the objects are not the same.  You have to map the objects in the development environment rules over to their counterpart objects in the test environment. And then repeat the process again when moving into production.

And this is where you need a security policy automation that supports the DevOps methodology. This solution needs to be able to automatically copy the firewall rules – and then make the necessary modifications to map rules to the new objects, when the rules are applied to each new environment in the DevOps lifecycle.  With the right automation solution, security can be baked into the DevOps process providing an easy and cost-effective way to introduce and maintain security right from the start.

See me explain this issue in person in my new whiteboard video: