DevOps is one of the hottest trends in software development. It's all about helping businesses achieve agile service delivery – that is, moving applications from development to test to deployment as quickly as possible.
Fast application deployment may seem at odds with robust security practices, which often take a go-slow approach to new or changed applications in order to verify that the applications are safe before letting them touch live data or business networks — or be exposed to the Internet or customers.
Fortunately, there's nothing inherently risky or dangerous about DevOps and agile service delivery, as long as the right security policies are created and followed, and if automation eliminates unnecessary delay in ensuring compliance.
What's this "DevOps" thing?
DevOps, or Developer Operations, is a mashup of two trends, that of applying agile software development methodologies to administrative IT operations, and of improving the historically poor collaboration between developers and IT staff. The DevOps movement recognizes that we're past the era where developers work in one silo to write software and throw it over the wall to another silo where administrators manage the application. In the DevOps model, everyone works together for the complete software lifecycle, from conception to design, from coding to testing, from implementation to management, from enhancement to migration, and finally from replacement to decommissioning.
In practice, DevOps is frequently used to specifically refer to the operations side of applications management – in other words, everyone except the software architects, designers, programmers, and testers. That's how we'll use DevOps here, to refer to the non-developer functions of the application lifecycle, including security management.
DevOps is often associated with the cloud, but it applies to non-cloud activities as well. Certainly, the rise of DevOps coincided with the popularity of cloud-based PaaS (platform as a service) and IaaS (infrastructure as a service), because traditional IT teams were not required to manage development and deployment services on, say, Amazon Web Services or Microsoft Azure. However, there is nothing inherent in DevOps that can't apply to applications developed, tested, and deployed in a traditional data center.
While it may seem that security policies must slow down DevOps, the truth is that security doesn't need to have a negative impact, especially if developers and DevOps avoid unnecessary changes to connectivity requirements so as to avoid trigger unnecessary security reviews – and if DevOps puts in the right test infrastructure and network rules to automate security testing and policy changes for those situations where connectivity changes are required.
Set up the environments
In the old days, everything was slow. Traditional app deployment processes were lengthy and process-driven. A human-driven security review before every release fit into those processes. By contrast, DevOps is an agile process with the goal of iterating software feature enhancements and builds quickly. Part of that agility comes from automating the deployment of those apps by development operations staff.
So what about that all-important security review? With some pre-work, you can integrate security right into DevOps without sacrificing flexibility or agility.
Start by using firewalls and VLANs (virtual local area networks) to create secure development, test, and production environments that have the same configurations. That applies whether it's in the cloud or in the data center, developers working in an environment that matches their production environment, in terms of traffic permissions for data leaving the application server, going to the application server, reaching databases, access to internal and external APIs, being driven by load balancers and content filters, and so-on.
Do the security review during the dev process
Make sure that those environments are locked down tight – and that developers don't have the keys, even to their dev environment. If they want to give applications and servers access to resources, like those on-premises databases or cloud-based APIs, they need to document those requests and submit them for a security review. That means working with the enterprise data security team to document and validate APIs and URIs, local IP address and ports, and so-on.
Once the security review is complete, the enterprise data security folks open up the ports, enable the virtual tunnels, and reprogram the firewall rules as appropriate. And here's the key: Make the same modifications simultaneously on the development, test, and production environments. That way, if the new security rules don't work, everyone knows it during the development process — and there's good assurance that if the security specifications work in dev, they'll work in test and production.
Application deployment now doesn't need a security review
By definition, if the security review of network resources and pathways takes place during the development process, then it should be good for the deployment. This requires the IT security team to take the security review seriously, looking at everything: hacks coming in, data leakage coming out, compliance with HIPAA and PCI, and so on. Sure, that's not strictly necessary during dev, but if the security review is performed thoroughly the first time, it shouldn't need to be done a second time.
A key part of DevOps is agile development and deployment: Applications are never finished, but continuously evolve, such as in two-week sprints under the Scrum development methodology. Generally speaking, connectivity requirements for the application shouldn't change from week to week. But when they do — such as when adding new features — the developers can bring the security review team in during that feature's development sprint.
Let's say, for example, the application stakeholders have requested that the application does real-time mapping of retail store locations. That might mean that developers will begin to use Google Maps API. By default, the locked-down application servers in the dev, test, and production environments won't have access to that API; attempts to talk to it will fail because the firewall or VLAN doesn't permit the communication. That's good security.
Once the developers have notified the IT security staff that the application requires access to the Google Maps API, the security team can validate the API's safety, determine the best way to direct traffic to/from Google's server, and make the correct changes to the network security settings. Voilà! Developers can write and test their code, and DevOps can automatically deploy the code knowing that it's safe, won't violate security policies, and won't crash due to a connectivity failure. (The security review also provides an opportunity to review license conditions with legal — something developers often forget to do.)
Four key steps to enabling secure DevOps
Developers want to code at the speed of light, and DevOps wants to support the rapid creation, testing, and deployment of code. It doesn't matter whether the dev, test, and deployment environments are in the cloud. The secret to securing agile service delivery with DevOps is to:
- Configure the dev, test, and deployment environments identically.
- Perform all vital connectivity security reviews during the development process.
- Make proactive changes to all three environments as needed.
- Make sure that only the IT security team can adjust network connectivity, VLAN and firewall.
Follow all those steps, and DevOps is fast, safe, and secure.
This article is published as part of the IDG Contributor Network. Want to Join?