Free Trial

DevSecOps: Merging Security and DevOps

Best Practices for DevSecOps and Security as Code

Subscribe to RSS

Topic Filter

Done

So What Is DevSecOps Anyway?

DevSecOps. It’s hard to keep track of all of the names, acronyms, and buzzwords floating around in the software industry, isn’t it? Whether the term is new to you or you’ve heard it before, you may be asking yourself, “What is DevSecOps, and why would I need it?”

It’s a reasonable question—one that we will do our best to answer in this article.

No Substitute for Security

devsecops-it-securityLet’s start with system security. Right now, it’s more important than ever. If you’re in IT, or in any position that involves IT, security should be (and probably is) near the top of your list of concerns. Data security can be crucial to the fate of your enterprise—and all too often, there is no margin for error.

Whatever your approach to IT is, whatever methodology or philosophy guides you in developing, deploying, and maintaining software, data security must be central. Treating security as an afterthought is a classic (and extremely costly) mistake.

Dangerous Assumptions in IT Security

It is easy, after all, to assume that adequate security is built into applications, that default settings are sufficient, or that well-established technologies will naturally include a full, up-to-date set of security features.

But all too often, such assumptions are not accurate. In fact, the developers who produce those established technologies may be assuming that their users will take full responsibility for security. And if everyone involved thinks that somebody else will handle security, it won’t get handled at all.

New IT Methodologies, Old Security Problems

The security situation can become even more uncertain when new IT methodologies replace old practices. If the new methodologies do not specifically incorporate security, it can become even more of an afterthought, and may in fact be left behind entirely. After all, if you’re heading into a new and wonderful world where the sun shines every day, do you really need to take your umbrella with you?

(The answer to that question, in case you’re wondering, is “Yes, you do.” Utopias are generally oversold, and chances are that even the best of them will still have a few rainy days.)

A DevOps World

DevOps has rapidly become the dominant methodology in development and IT, particularly for network- and Internet-based applications. DevOps practices, such as the integration of development and IT, continuous delivery of software updates, automation, virtualization, and treating infrastructure as code are a near-perfect fit for cloud-based deployment.

A development cycle that once took months under older methodologies might take no more than a few days, with not only applications but entire infrastructures and software ecosystems being deployed almost instantly. DevOps promises (and delivers) lightning speed, and the companies that use DevOps require that speed in order to remain competitive.

Integrating Security with DevOps

But speed requires a lean and often streamlined delivery chain, and it does not naturally lend itself to slow and painstaking processes, or to the addition of features that are not necessary for rapid delivery. If security is going to be a part of DevOps, it needs to be explicitly included. That’s where DevSecOps comes in.

The purpose of DevSecOps as a distinct methodology is to integrate security smoothly into the DevOps framework, and to do so fully in the spirit of DevOps. This means that security is integrated throughout the DevOps process, and not just as an add-on at one or two specific points. Security is a fundamental part of architecture and design, programming, testing, deployment, and monitoring and maintenance.

It also means that this integrated application of security must keep pace with the DevOps continuous delivery chain as a whole, which is itself an additional reason for full integration. If you stop the continuous delivery chain to apply generic security features, or to run standard security tests, you’ve broken the delivery chain, and it’s no longer fully DevOps. Security must be part of the stream, rather than an interruption.

If Infrastructure is Code…

One of the fundamental insights of DevOps is that infrastructure is code. Even in the days when deployment on bare metal was the rule, the actual interface between the application and the underlying server was code. Hardware was always abstracted to one degree or another. With cloud-based/virtualized deployment, abstraction has reached the point where “infrastructure is code” is simply a description of everyday reality, rather than being a goal, or a statement of an ideal. When you provision infrastructure in the cloud, you write or configure code. And that’s it.

… So is Security

For DevSecOps, the equivalent statement is that security is code. This was also largely true in the traditional IT world, so its applicability to the DevOps world is hardly surprising.

 

This doesn’t mean that physical security measures no longer matter. They are important, and will continue to be so. In many cases, site and hardware security are crucial to the security of the system as a whole. But for cloud-based deployment, most aspects of physical security are necessarily in the hands of the cloud service provider, and physical security is generally not a direct part of the continuous delivery chain.

devsecops-security-as-codeCode-based security, however, is crucial. It must be built into the application, into the development and test infrastructure, into the deployment scripts, into monitoring, and of course, into the virtual machines and containers that make up your deployment. (How does it handle a malformed request, or even a simple overflow?) And in DevOps, all of these things are code.

Putting DevSecOps to Work

At this point, you may be asking, “How do I put DevSecOps to work? What are its basic practices? And what kind of real-world problems does it face?”

DevSecOps Automation

As is the case throughout DevOps, automation is fundamental.

This includes automated security testing—integration of security tests into automated test suites. Parallel testing (made possible by large-scale, cloud-based virtualization) allows broader and more thorough automated testing, including security-related tests.

Parallelization cuts the time per test run to a fraction of what it would be in a sequential testing regime. This allows you to run not only more tests of a given type, but more types of tests. This in turn makes room for tests which would have been previously given a low priority, or simply set aside as too time-consuming.

Automation also means implementation of automated security processes throughout the continuous delivery chain, including management of privileges, configuration, and patches, as well as monitoring of logs and other indicators of security-related anomalies. At every point where security measures are appropriate, include scripts or other code to put those measures into practice.

Tailoring Security Policies

Automated security should include tailored security policies, applied at the level of individual applications, and even processes.

Why? The combination of virtualization, plus the decomposition of monolithic applications (typical of container deployment), mean that applications and processes often have their own interactions with underlying system resources, and with each other, rather than being part of a single large program. They must be dealt with individually when it comes to applying security measures and policies, and very often, their individual security requirements may vary.

By tailoring security, you can maintain a high level of security for the majority of processes, allowing specific kinds of access only for those processes that need it. Tailored security is also a necessity for multi-tenant environments, where individual users may have access to the same virtualized services, but must be restricted from accessing each other’s data.

Monitoring and DevSecOps

Monitoring is always a key element of security, and this is even more true of DevOps, since most or all of the basic control processes are automated. For DevSecOps, by far the most appropriate choice is a comprehensive, integrated monitoring system with a full API and dashboard capabilities.

Such a system is a key element for automation and for real-time alerting and staff intervention where necessary. A monitoring-system API allows you to include a wide range of automated responses to security-related events, including such things as switching suspicious activity to a server that is isolated from sensitive data and processes, along with a variety of logging and alert options.

Tools for DevSecOps

Which DevOps tools are necessary or important for full integration of security? While there are many security tools which can be integrated into DevOps, and may serve as key elements of your individual DevSecOps strategy, from the DevOps side, it is not so much a matter of specific tools as it is a matter of integrating security with those tools.

Key DevOps tools such as Chef or Docker, for example, can be integrated with both security and monitoring applications and services, and automated testing suites can be configured to include a full set of security-related tests. In addition, security tools themselves can be integrated with comprehensive monitoring services, as is the case with Sumo Logic’s App for Trend Micro Deep Security, which allows deep monitoring and integrated analysis of security and other monitored data. DevSecOps is as much a matter of bringing security to DevOps tools as it is a matter of bringing security tools to DevOps.

Steps for Implementing DevSecOps

How do you implement DevSecOps in your continuous delivery chain? The following basic steps can serve as a framework for a full DevSecOps implementation strategy:

  1. Start with a comprehensive survey of your security needs. It should include those which are common to most IT operations, those which are specific to your industry, platform, or niche, and those which are specific to your individual applications and operating environment.
  2. Determine the best ways to meet those needs on a general level. The goal of this step is to lay out a basic plan, including such things as architecture, policies, practices, etc.
  3. Implement those solutions in code – at the application code level, in testing scripts, in deployment scripts, in monitoring—automating all tasks that can be automated without loss of security or responsiveness.
  4. Include alerts, monitoring dashboards, and other methods of notification at points where human intervention may be required.

The basic idea is to automate what can be automated, automatically alert IT staff when intervention is appropriate, and apply all of the features which support these processes by means of code (scripts, API calls, etc).

The result will be security that is seamlessly integrated into your delivery chain—so seamlessly that if and when you shift to whatever methodologies eventually replace DevOps, security will naturally be a part of that shift.

Back to top
“Sumo Logic brings everything together into one interface 
where we Hudl can quickly scan across 1,000 servers across and gigabytes of logs and quickly identify problems. It’s awesome software 
and awesome support.”

Jon Dokuli,
VP of Engineering

Sign up for your 30 day free trial!*
Sign up for Sumo Logic Free
  • No credit card required to sign-up
  • Create your account in minutes
  • No expiration date*
  • *After 30 day trial period, reverts to Sumo Logic Free
    View All Pricing Options
    Already have an account? Login