Delivering Security and Speed: The 3 Core Principles of DevSecOps

Despite the bevy of high-profile cyber attacks making headlines these days, security approaches in most enterprise IT environments are set up to fail.

For starters, companies are throwing money at protecting the wrong things. According to Verizon's 2018 Data Breach Investigations Report, 40% of system breaches occur at the application layer. Yet only 3% to 4% of annual security budgets are spent on protecting applications.

There's also an inequitable distribution of labor in enterprise IT departments. It's not uncommon for companies to have 100 developers while employing just one security professional. And those lone security wolves are often siloed, stuck trying to deliver security policies and practices in a Waterfall fashion to Development teams working in an Agile world. Delaying an application deployment with a security checklist of items that were not considered when the app was coded is a surefire way to not only hurt productivity but also poison the culture.

The reality is that if you're not baking in security processes throughout the software delivery pipeline, you're either going to see delivery delays or risk releasing an artifact that is vulnerable. That's why DevSecOps —the practice of shifting security left in the software delivery pipeline to minimize vulnerabilities and bring security closer to IT and business objectives-is taking off.

In a recent XebiaLabs webinar, James Wickett, head of research at Signal Sciences, discussed three principles for incorporating security into the complete DevOps lifecycle. He was joined by DevOps thought leader, Gene Kim, and XebiaLabs CPO, Rob Stroud.

You can listen to the complete Webinar here and read on about the core principles of DevSecOps below.

Principle 1: Design for the Worst-Case Scenario

To "left-shift" security, it's important to get buy-in from Development. To accomplish that, organizations need to help them understand the threats to and vulnerabilities of applications and plan and design for them. Wickett suggests four ways of doing this:

• Bulkhead Patterns — Design your code in a way that separates out application dependencies. The idea is to design for failure. You isolate the elements of an application so if one fails, the others continue to function. According to Wickett, a lot of this is being done as part of the microservices movement because you naturally need to put in bulkheads when you're splitting up big services into little ones. This is great for security, although there are scaling limitations with microservices that need to be considered in enterprise environments.
• Evil User Stories — You can express security concerns to Agile development teams by submitting stories to them about how a user might break the system, so that, ultimately, the code is written to limit nefarious user behavior. For example, code might be written that specifies that, if a user goes to a site and tries to inject cross-site scripting, they will be rejected. According to Wickett, high-performing security organizations write user stories using language, patterns, and testing frameworks already in place, so their approach fits into the existing Agile culture, and therefore is better accepted as part of the system.
• Threat modeling — In software development, you can use threat models to illustrate the components that make an application work, identify the potential risks to those components, and determine the best courses of action. Threat modeling is crucial in environments where security professionals are outnumbered. Having specific risks to point to can make it much easier to have a meaningful conversation between Development and Security.
• Risk Assessments — You can apply a risk-based methodology to your environment to determine which of the actions listed above best fits your use cases. This can be integrated in the implementation design stage, with input from Development, and executed throughout the lifecycle.

Principle 2: Test for Security Across the Pipeline

Securing the complete software delivery pipeline means testing for vulnerabilities across all of the components and stages of an application's lifecycle. There are a few methods for testing the security of software delivery pipelines.

• Adversity Testing — You can take real-world attack tooling and inject it into your pipeline to identify vulnerabilities. Wickett suggests downloading tools like Metasploit, Nikto, and Arachni, which can be used by hackers and run into a site to identify weaknesses. These should be tested against your environment to prevent it from being exploited.
• Security-as-Code — Similar to infrastructure-as-code, security-as-code is the process of integrating security patterns as an automated part of the codified system. Security-as-code can be an important part of promoting culture as it brings developers into the security process.
• Vulnerability Testing — There are a few methods for testing vulnerabilities in an application. Static Application Security Testing (SAST) is a set of tools for detecting vulnerabilities in application code. Dynamic Application Security Testing (DAST) is a method of testing an application in its running state by trying to attack it from the outside. Interactive Application Security Testing (IAST) is a method of analyzing application behavior in the testing phase to help developers prioritize vulnerability findings.

Principle 3: Abandon the AppSec Training Fallacy

Last decade, there was an industry-wide emphasis placed on training developers to write secure code. While it's still important to promote security awareness and best practices through AppSec training, doing so can create a few issues. For starters, as long as humans are writing the code, there are going to be vulnerabilities, and organizations should not assume that developing secure code is enough to keep their applications safe.

Another issue that arises from setting up an AppSec training program is that you make your developers more attractive to other employers and may risk losing them to a better offer.

Instead of putting the emphasis on developers to write code that's more secure, organizations should look to automate as many processes as possible on the left side of their software delivery pipelines, while increasing instrumentation and monitoring tools for security on the right. Ensuring good code hygiene should also be an automated process that can be ultimately enforced by a deployment management system.

Where Security and Speed Meet

It's not surprising that the teams charged with accelerating the release rates of applications fail to bring their security counterparts to the table early enough. It's a challenge to bring these teams in, carry out all the necessary steps, and still meet deadlines. But if you ignore the security side of software delivery, you could lose everything from your customers' trust to your intellectual property.