Introduction to DevSecOps

Sep 20, 2019

I initially thought that DevOps could contribute nothing new—after all, I grew up coding using XP and dark launching. But as I dug deeper past the hype, I was able to find truly great ideas and patterns that added value to the way we build robust, secure and risk-free systems. My first “A-ha!” came when I learned that DevOps systems were proven to recover almost 150x faster than normal.

In this article, we will explore some of the important things that we can and need to do to implement DevSecOps (DevOps + Security), which enhances security and enforces compliance at the same time.

Quick Refresher: DevOps and It’s Challenges

Before we get into the need and details of DevSecOps, let’s quickly refresh ourselves on the advantages of DevOps, along with a few corresponding challenges.

1. Speed of Delivery – Most companies adopt DevOps to bring their products to market faster. However, with great speed comes great responsibility. How do we address responsibility for quality and security?
2. Design and principle of YAGNI – DevOps is built on the principles of agile, lean and YAGNI (“You Aren’t Gonna Need It”). This means eliminating large upfront design and constantly cutting down on design and features to meet only the most important goal(s). When and how will the security teams’ threat models stay in sync with such frequent and continuous changes?
3. Microservices & Containers – DevOps introduced the design of small, isolated functions that can be changed, tested, deployed, and managed completely independently. Unfortunately, microservices and containers also come with downsides, including operational complexity, polyglot programming, logging strategy, and attack surface. Containers (especially the famous Docker) used with microservices can actually provide micro-segmentation. Adrian Mouat, author of Using Docker, has expressed serious security concerns, such as Kernel exploit, Denial of Service attacks, Container breakouts, Poisoned images and compromising secrets. How can security cater to all of these concerns?
4. Compliance & Change Control – Adopting DevOps brings in the need to change old compliance and change control processes. There needs to be SoD (Separation of duties), as well as clear handoffs and wait times to ensure that requirements for data confidentiality and integrity are satisfied; the data and configuration cannot be altered by unauthorized individuals. How do we address this while moving fast?

By wiring compliance and security into DevOps, otherwise known as “DevSecOps,” there are ways to tackle the aforementioned challenges. Below are three solutions to help you get started on your DevSecOps Journey.

Shift Security Left

First and foremost in DevSecOps, you must Shift Security Left. In other words, shift the responsibility for security and other quality factors upstream in the pipeline back to the teams building the solution. Currently, most companies test vulnerabilities at the very end of the development cycle, just before release. This is dangerous. To have a truly robust and effective security system, security must be incorporated as early as possible into the planning, designing, and coding of automated test cycles.

Etsy is a great example of a company that has successfully shifted security left. Etsy built their security culture on top of their engineering culture, which has resulted in an overall thriving company culture. Their driving principles are:

1. Trust people to do the right thing, but still verify – Rely on reviews to prevent or catch mistakes. The production mistakes go through a process of blameless postmortems to examine and understand the source of the problem, so they can fix problems at their source.
2. “If it Moves, Graph it” – Make data visible to everyone in the company so that everyone can understand and act on it, including information about security risks, threats and attacks.
3. “Just Ship it” – Every engineer can push code to production at any time, including security engineers. If something is broken, then fix and ship it right away. Send it through the CI/CD pipeline so all the tests are done again to the fixed code.
4. Security cannot be a blocker – The word “No” is a finite resource, so use it only when you must.

Follow OWASP Proactive Controls

To ensure that security is built-in to your development pipeline, it is important to follow OWASP Proactive Controls. These are a set of development practices, guidelines and techniques that should be followed to build secure applications. These practices help shift security left by injecting security into planning, design, coding and testing. When we start following these practices, we are in turn creating “Security as Self-Service.” We want teams to inject security seamlessly into their features, similar to automation or virtualization.

At Twitter, for example, security checks are run automatically every time a developer makes a change. They use tools like Brakeman to check the code for security vulnerabilities and to provide the developer with direct feedback when something is found. Developers also have a “bullshit” button to reject false positive findings.

Infrastructure as Code

Another key to DevSecOps is Infrastructure as Code, or managing infrastructure configuration in code using tools like Ansible, Chef, Puppet, and Salt. This speeds up and simplifies provisioning and configuring systems, especially at scale. It also helps to ensure consistency between systems and test and production, standardizes configurations and minimizes configuration drift, and reduces the chance of an attacker finding and exploiting a one-off mistake.

Security teams can also use Infrastructure as Code to program security policies directly into configuration, to continuously audit and enforce policies at runtime, and to patch vulnerabilities quickly and safely. A good example of this is a service called UpGuard.

The Bottom Line

If you don’t want security or compliance going to a stage gate to stop the flow, then it is important to continuously build security and compliance into the code while building the CI/CD. In the image, you see “Continuous Security” in the center of the development cycle. This image reinforces that security needs to be checked throughout the entire lifecycle—continuously, from inception to completion.

In the organizations I’ve coached, moving to DevSecOps always started with DevOps and continued with small changes made along the journey. New skills, tools, and priorities, as well as open thinking, were required. My advice? Start small, but start soon!

Need help getting started with DevSecOps? ICON offers testing, quality, and strategic DevOps Solutions.

Written by Nishant Sasidharan , IC Agile certified EBA Trainer

 

With 18+ years in the software industry in a variety of roles and a decade’s experience working as a coach, Nishant possesses a unique skill set to find creative and sustainable ways in the midst of traditional transformation methods. He strongly believes that guiding leaders on a path to a coaching mindset is key to unlocking the potential of the individual, the team, and ultimately the organization. Nishant is a recognized Agile change agent and leader, and his experience in traditional/legacy environments and his pragmatic approach to Agile Transformation allows him to help organizations bridge the gap when adopting Agile practices. Most recently, Nishant has been working to incorporate various Enterprise Business Agility techniques along with DevOps and XSCALE principles to his method of training, coaching, and speaking to help his clients in their transformations.

 

More…