Security Breaks DevOps – Here’s How to Fix It

By Amrit Williams

The concepts of communication, collaboration, abstraction, automation and orchestration are cornerstones of the rapidly growing DevOps movement. At the same time reliance on virtualized infrastructure and Infrastructure-as-a-Service has exploded, making manual provisioning and management simply not feasible anymore; it takes too long and locks up too many resources. Modern DevOps methods and tools have emerged, allowing IT organizations to move faster and with higher quality, thus giving them the ability to respond to the business with more agility.

Now security teams have an opportunity to learn from the DevOps experience. Manual policy provisioning and security operations in highly dynamic IaaS environments simply doesn’t work, for the same reason it doesn’t work for DevOps teams – the pace of change is simply too to fast to handle manually.

Applying security policies based on static parameters and making manual rule changes just before production leaves little time for provisioning the policies. This impacts release quality, increases risk of errors and slows down the DevOps cycle.

Trying to use DevOps orchestration tools to provision security can leave companies exposed since these tools lack critical controls and don’t integrate with the rest of the security infrastructure.

To solve these challenges, IT and security teams need to adopt platforms and processes that match the speed and agility of their DevOps brethren.

Here are the key ingredients you should look for in security solutions that can move at the speed of DevOps:

  • Built-in Automation – Security automation means that any control (e.g. firewall policies, configuration vulnerability scans, intrusion detection, multi-factor authentication) can be deployed and managed without human intervention. Most desirable is full-lifecycle automation, in which policies are set once and tied to some context, after which underlying controls are 100% automated at each stage of the control’s lifecycle, from deployment to de-provisioning. Automated collection of audit and operational data is also critical, especially in environments where infrastructure components are only operational for short periods of time. Even though short-lived, these ephemeral resources are still in scope for auditor inspection, even if not running at audit time. Well-implemented automation enables security organizations to keep up with the scale and rate of change associated with dynamic infrastructure models. Security accuracy and effectiveness are both improved by automation, and potential for human error is removed—especially if API instrumentation enables cooperation of otherwise disparate technologies.
  • Security Orchestration – Platforms that enable security orchestration centrally manage the composition, deployment, and management of individual control components into more complex, service-oriented security systems. By composing many individual controls into a larger system, security orchestration is considered to be a higher order function than simple control automation. In many implementations, orchestration also addresses licensing, metering, chargeback, and other security resource consumption issues that are important in service-oriented cloud computing and software-defined infrastructure environments. 
  • Instant Visibility & Continuous Enforcement at the Workload – Public clouds have no natural perimeter and network segmentation, which leaves individual servers exposed. In private clouds, malicious East-West traffic inside the network is undetected by perimeter tools and can become a serious threat. So choose a security platform that extends your investments in network security directly to the workload itself. The solution should be on-demand and easy to deploy. Many of these platforms have an agent-based model, so make sure the agent is ultra lightweight to eliminate drag on the virtual server, is non-intrusive to the workload and is easy to integrate into DevOps continuous deployment model. The agents should be deployable through orchestration tools, with scripts or manually, even on live systems without reboot, to speed up the process even further.
  • Flexible Policy Definition – A modern security platform should allow security policies to be defined by logical application groupings instead of static network parameters, which protects new workloads automatically and overcomes natural limitations of traditional network security tools.
  • Security at Every Stage – The DevOps model has multiple stages, many of which are conducted on various cloud services and on other virtualized architectures. This leaves assets vulnerable to attackers, so baking in security at each stage prevents this issue. Just as importantly, development teams need to know how security will impact the application being developed, so incorporating security early in the process makes a ton of sense.
  • Layered Approach – Having a platform that provides layered security (not just a firewall) in the DevOps model, is key. Integrating multiple functions from different vendors would prove enormously daunting from an orchestration perspective. So make sure layered security functions like file integrity monitoring, security configuration monitoring, strong access control and vulnerability management are baked into a single platform and included on every system throughout the lifecycle.
  • Seamless Integration with Orchestration Tools – Make sure your security platform integrates seamlessly with the orchestration tools you’re already using. Jumping back and forth between tools can slow things down, introduce errors and lower your overall security posture.

By implementing a security solution that incorporates all of these attributes, IT can bring security into the high speed, high quality DevOps model that is now required to provision and manage modern infrastructure.

What Is DevOps?

By Daniel Greene

As is evident from the increase in conferences, books and software tools, there is a growing emphasis on improving DevOps within all sizes of software development organizations. The question that follows is typically, “What is DevOps?” This is an absolutely understandable question. Not only is it a relatively recent movement within the software community, but the commercial marketing machine has taken over ownership of the term, bending it to their needs.

This is nothing new. SOA, ESB, and cloud computing have received similar treatments. Four to five years ago, a massive amount of integration products were quickly renamed ESBs, and SOA was infamously declared dead due to the level of marketing hype. Don’t even get me started on the Microsoft “To the Cloud!” ad campaign for its picture-editing software.

Yeah, But Really, What Is DevOps? 

Historically, product managers, business analysts and software engineers would work together to organize a release plan, with user stories sequenced into iterations that could be re-­prioritized at each iteration boundary. While every iteration is supposed to end with a “production ready” version of the system, it has not been common to actually release to production regularly.

More often, the output of an iteration makes it only as far as a “test” or “staging” environment, because actually pushing to production requires many more steps: bundling the code, packaging the product, provisioning the environment, and coordinating with the operations staff.

People began to realize that a “throw it over the wall” mentality from development to operations was just as much of a challenge as we used to have with throwing requirements over the wall and waiting for code to come back. People began to blur the lines between the development tasks, such as coding and operational deployment tasks such as server provisioning, hence the name “DevOps.”

I still don’t see a clear definition in there… 

As mentioned above, the term DevOps has been used for many areas: automated infrastructure provisioning tools (e.g. Chef and Puppet) and automation tools (e.g. continuous integration like Jenkins), as well as for establishing developer work environments to mirror production (e.g. Vagrant).

I use the term “DevOps” to define a set of practices, tools and policies that lead to improved quality and Automated Delivery (AD). In many ways, rapid and frequent deployment to production reduces risk, as any release contains fewer changes. And fixes for any issues that are found are easier to fix or, alternatively, the smaller changes are typically easier to roll back.

So, DevOps is the same as Automated or Continuous Deployment then?

Almost. DevOps, in a way, is all the things that go into making AD/CD possible. In many ways, DevOps is about ensuring quality at all stages​.

You can visualize DevOps as a conveyor belt, where many checks and balances are in place, at all stages, to ensure any bundle coming down the belt is removed if it’s not good enough, and delivered to the end of the belt (e.g. production) safely and reliably if it is.

Why should I care? What will DevOps do for me?

DevOps practices and procedures lead to smoothing out the typically ‘bumpiest’ aspects of software development and deployment. By pulling infrastructure setup and awareness earlier in the development cycle, surprises from environmental differences are significantly reduced.

By establishing consistent, reliable and repeatable automated deployments, human error and the need for ‘rockstar firefighters’ are reduced. The Phoenix Project (Kim, Behr, Spafford) is a great read on the subject and chronicles an organization’s change to embracing these practices in an incremental and prioritized manner. One of the key takeaways from the book is that making the first step is difficult, but allows for the next step to be easier.

Defining DevOps and integrating it into your processes at all levels

Most of the talk, tools and processes around DevOps can be intimidating. The Herculean task of transitioning to fully automated, multiple production releases per day can be daunting. The truth is that level of automation is simply not needed for all products or companies.

How deeply clients incorporate DevOps into their practices varies wildly; some still want a formal ‘hand off’ process, which DevOps purists will rage against. For these clients, a fully automated end­to­-end system may convey far too much risk.  Do what alleviates the greatest pain for your organization in the development to release cycle. Like agile programming ­ taking incremental steps toward the end goal is the most effective and reliable way of reaching the goal.

Software product businesses commonly aim to be ahead of their competition by launching new products and features quickly to market. Agile product development teams are expected to adapt to business changes and challenges while maintaining high quality standards.

More clients are recognizing the need for, and asking for help with, developing effective strategies to continuously deploy new/updated software; keeping systems up around the clock; and quickly and seamlessly resolving operational issues quickly.

If you leverage DevOps practices to assist in smoothing the worst point in your cycle, you may discover that your pain level has been lowered to the point where your releases are in sync with the velocity of customer feedback, and you can hold and/or hone your existing processes.

Like traditional software development, introducing capabilities that are not needed or of high value is a waste of development resources. You know by now that many business demands can be managed with DevOps practices and processes. That’s why I’m excited by DevOps initiatives.