6 tips for your devops security program

DevOps security extends DevOps processes to the software application security team within your organization. Bringing together software development and application security helps ensure that security moves from a bottleneck to an enabler. According to McKinsey & Company, the benefits of being a “DevOps security” or “DevOps-ready IT organization” include:

• An increase of 25-30% in capacity creation (i.e., freeing up people and resources to work on other priorities)
• A 50-75% reduction in time-to-market
• A greater than 50% reduction in failure rates¹

Your peers and co-workers are ready for this transformation: 45% of respondents to the 2016 Puppet Labs State of DevOps survey said they expect DevOps to make their organization more secure. High-performing DevOps security organizations that incorporate security into DevOps report 50% less time spent remediating security issues². 

The implication is clear: Improving DevOps maturity and moving to DevOps security practices is critical to time-to-market and customer confidence.

The DevOps – Security Zero Sum Game

In a zero-sum game, each participant's gain or loss is exactly balanced by the losses or gains of the other participants. Total gains are fixed, so each win takes away from potential wins on the other side. If the total gains of the participants are added up and the total losses are subtracted, they will equal zero.

Operations vs. security has become a zero-sum game: 70% of IT operations teams believe security slows down IT and 77% of security teams agree3. This has really come to a head as firms make investments in agile methodologies and build DevOps capabilities. At those firms, security teams (especially those providing software application security and monitoring) either become a blocker or get left behind and lose their influence and seat at the table. When security teams are a blocker, firms get slower at deploying code, iterating on their product, and subsequently speed to market. When security teams get left behind, firms release products prone to security threats, compliance risks, and the subsequent damage to customer trust that ensues. Both scenarios pose significant risks. However, moving to DevOps processes that integrate development teams and security teams can provide the answer.

Six Pro Tips: How to Build DevOps-Ready Security Program 

Contrast Security has witnessed and assisted in the revolution of information security in an agile & DevOps-first world. Provided below are the most important lessons learned through the years and seen consistently across every successful DevOps shop.

1. Partner with Vendors that are DevOps Shops

Why this is important: This is critical for them to fully understand a customer’s setup, tool chain and priorities. Most importantly it is a strong indicator of how quickly they iterate their product, deliver on features and respond to support tickets.

What to look for: Find security vendors that use DevOps to deliver product. Review the vendor’s GitHub profile and evaluate their speaking presence at DevOps related conferences and local meet up groups. If possible, talk to the vendors’ DevOps and engineering teams and understand their DevOps setup and tool chain. Bring your DevOps and security teams to these calls. They make great partners during this transformation because they can share best practices, understand your environment and know how to build products using DevOps processes.

2. Add Sensors to Eliminate Security Scanning as a
Step in the SDLC 

Why is this important: Scanning adds an additional step to the release cycle and subsequently a slower deployment. In addition, scanning also implies a “point in time” review that does not capture what happens when a scan isn’t occurring. This leads to less accurate results (i.e., more false positives). IAST (Interactive Application Security Testing) and RASP (Runtime Application Self-Protection) products embed sensors into the application and are therefore fundamentally “always on.” IAST and RASP tools eliminates security testing as a separate step in the SDLC and infuses it across the SDLC. In addition, sensors that instrument the application provide a much greater level of accuracy. 

What to look for: Look to embed controls that reside inside the asset you are trying to protect. For applications, many legacy software security solutions are scanning technologies that either scan or review software (Static Analysis or SAST) or the application itself (Dynamic Analysis or DAST). Security tools purpose built for DevOps, such as IAST and RASP, reside close to or inside the application while it runs.

3. Integrate with the (CI / CD) Integration and Delivery Pipeline and DevOps Toolchain 

Why this is important: Including security as part of your continuous integration (CI) / continuous development (CD) pipeline accelerates time-to-market for your software. This eliminates the need for development and operations teams to incorporate a new tool and removes the extra security testing step from the SDLC. 

What to look for: Security controls should integrate with your development and operations environment. This can be done in two ways. First, you can leverage the readily available RESTful APIs that most DevOps tools offer to deliver security data to those tools. Second, find a security solution that was built to integrate with your firm’s DevOps stack out of the box. Ideally, security solutions should integrate directly into the tools you use in each stage of the SDLC (See Figure 1).

Figure 1 : The DevOps era SDLC⁴

4. Move and Scale Security Controls Easily with Your Product

Why is this important: As an application evolves and scales, security measures must evolve and scale with it. Otherwise, security once again becomes a blocker or a risk to the stability and performance of the application. This is especially critical in cloud based environments where applications and infrastructure are deployed, moved and scaled on an hourly basis.

What to look for: The efficacy of your security controls should not vary with the type of application deployment. The solution should work well whether deployed on a physical box, VM or container. It should also work regardless of the underlying infrastructure – whether that is a private data center, public cloud (e.g., AWS, Google Cloud, Azure, Rackspace) or hybrid. On-demand scaling, micro-perimeterization of security controls and per-resource granular security policies can make your security program agnostic to the environment being utilized⁵.

5. Emphasize “Security as Code, Vulnerabilities and Attacks as Defects”

Why is this important: Delivering results into existing tools removes the friction of making developers learn a new tool and perceiving security as a blocker. Developers should be alerted of security results the same way they are alerted of testing, defect and crash results. Knowing how the application is being attacked allows developers to prioritize fixing vulnerabilities in their next sprint, while it’s still fresh in their minds. Doing this repeatedly embeds secure coding practices within development teams without adding additional steps or tools.

What to look for: DevOps-ready security programs infuse security into the daily work of developers and DevOps. This implies testing security requirements as part of automated testing. It also implies delivering vulnerability and attack results directly into existing developer tools (e.g., Slack, HipChat).

Figure 2 : How Contrast Security Works in DevOps Environments

6. Cover the Full SDLC Consistently — Secure Dev, QA and Production with a Single Platform

Why is this important: This implies that the security of the software being built is contingent on the vulnerabilities being fixed. This means, one of two things – either the build slows down until the vulnerability is fixed or the vulnerable code is deployed. Vendors offering both IAST and RASP can extend the protection to production. This allows customers to deploy code with full protection even if the vulnerability is not fixed in code. However, this implies the purchase, implementation and management of two disparate solutions. Vendors offering IAST and RASP through the same agent introduces full lifecycle protection and the implementation & management of a single solution. This approach also offers the ability to respond rapidly to exploits and provide closed loop feedback on the exploit to developers in parallel. Figure 2 below outlines how Contrast Security covers the SDLC with a single solution.

What to look for: As mentioned above, not every vulnerability can be fixed before deployment. Hence, the same level of control should exist in production environments once code is deployed. While there are several security solutions purpose-built for the DevOps era, most are incomplete. While some solutions (such as IAST, SAST, DAST) provide coverage early in the SDLC (Dev, Build, QA), they do not extend their protection into production on their own. Vendors offering both IAST and RASP solutions can cover the full SDLC.

SIX PRO TIPS: HOW TO BUILD AN INTEGRATED DEVOPS SECURITY PROGRAM 

Contrast Security has witnessed and assisted in the revolution of information security in an agile and DevOps-first world. Provided below are the most important lessons learned through the years and seen consistently across every successful DevOps organization. 

1. PARTNER WITH VENDORS THAT ARE DEVOPS SHOPS

Why this is important: It is critical that security vendors fully understand their customers’ setup, tool chain, and priorities. Most importantly, it is a strong indicator of how quickly they iterate their product, deliver on features, and respond to support tickets.

What to look for: Find security vendors that use DevOps to deliver product. Review the vendor’s GitHub profile and evaluate their speaking presence at DevOps-related conferences and local meet up groups. If possible, talk to the vendors’ DevOps security and engineering teams and understand their DevOps setup and tool chain. Bring your DevOps and security teams to these calls. They will make great partners during your transformation because they can share best practices, understand your environment, and know how to build products using DevOps processes. 

2. ADD SENSORS TO ELIMINATE SECURITY SCANNING AS A STEP IN THE SDLC 

Why is this important: Scanning adds an additional step to the development process and subsequently a slower deployment. In addition, scanning also implies a “point in time” review that does not capture what happens when a scan isn’t occurring. This leads to less accurate results (i.e., more false positives). IAST (Interactive Application Security Testing) and RASP (Runtime Application Self-Protection) products embed monitoring sensors into the application and are therefore fundamentally “always on.” IAST and RASP tools eliminate security testing as a separate step, infusing it across the Software Development Lifecycle (SDLC). In addition, sensors that instrument the application provide a much greater level of analysis and accuracy. 

What to look for: Look to an integrated process that embeds controls that reside inside the asset you are trying to protect. For applications, many legacy software security solutions are scanning technologies that either scan or review software (Static Analysis or SAST) or the application itself (Dynamic Analysis or DAST). Security tools purpose-built for DevOps, such as IAST and RASP, reside close to or inside the application while it runs.  

3. INTEGRATE SECURITY WITH THE (CI/CD) PIPELINE AND DELIVERY PIPELINE AND DEVOPS TOOLCHAIN 

Why this is important: Including security as part of your continuous integration (CI)/continuous development (CD) pipeline accelerates time-to-market for your software. This eliminates the need for development and operations teams to incorporate a new tool and removes the extra security testing step from the SDLC. 

What to look for: Security controls should integrate with your development process and operations environment. This can be done in two ways. First, you can leverage the readily available RESTful APIs that most DevOps tools offer to deliver security data to those tools. Second, find a security solution that was built to integrate with your firm’s DevOps stack out of the box. Ideally, security solutions should integrate directly into the tools you use in each stage of the Software Development Lifecycle (See Figure 1). 

Figure 1: The DevOps era SDLC4 

4. MOVE AND SCALE SECURITY CONTROLS EASILY WITH YOUR PRODUCT

Why is this important: As an application evolves and scales, security measures must evolve and scale with it. Otherwise, security once again becomes a blocker or a risk to the stability and performance of the application. This is especially critical in cloud-based environments where applications and infrastructure are deployed, moved, and scaled on an hourly basis.

What to look for: The efficacy of your security practices should not vary with the type of application deployment. The solution should work well whether deployed on a physical box, VM, or container. It should also work regardless of the underlying infrastructure – whether that is a private data center, public cloud (e.g., AWS, Google Cloud, Azure, Rackspace), or hybrid. On-demand scaling, micro-parameterization of security controls, and per-resource granular security policies can make your security program agnostic to the environment being utilized to ensure flexibility5.

5. EMPHASIZE “SECURITY AS CODE, VULNERABILITIES AND ATTACKS AS DEFECTS”

Why is this important: Delivering results into existing tools removes the friction of making developers learn a new tool/process and perceive security as a blocker. Developers should be alerted to security results the same way they are alerted to testing, defect, and crash results. Knowing how the application is being attacked allows developers to prioritize fixing vulnerabilities in their next sprint, while it’s still fresh in their minds. Doing this repeatedly embeds secure coding practices within development teams without adding additional steps or tools.

What to look for: DevOps-ready security programs infuse security into the daily work of developers and the DevOps process. This implies testing security requirements as part of automated testing. It also implies delivering vulnerability and attack results directly into existing developer tools (e.g., Slack, HipChat).

Figure 2: How Contrast Security Works in DevOps Environments

6. COVER THE FULL SDLC CONSISTENTLY – SECURE DEV, QA, AND PRODUCTION WITH A SINGLE PLATFORM

Why is this important: This implies that the security of the software being built is contingent on the vulnerabilities being fixed. This means one of two things – either the build slows down until the vulnerability is fixed or the vulnerable code is deployed. Vendors offering both IAST and RASP can extend the protection to production. This allows customers to deploy code with full protection even if the vulnerability is not fixed in code. However, this implies the purchase, implementation, and management of two disparate solutions. Vendors offering IAST and RASP through the same agent introduce full lifecycle protection and the implementation and management of a single solution. This approach also offers the ability to respond rapidly to exploits and provide closed-loop feedback on the exploit to developers in parallel. Figure 2 below outlines how Contrast Security covers the SDLC with a single solution.

What to look for: As mentioned above, not every vulnerability can be fixed before deployment. Hence, the same level of control should exist in production environments once code is deployed. While there are several security solutions purpose-built for the DevOps era, most are incomplete. While some solutions (such as IAST, SAST, DAST) provide coverage early in the SDLC (development, build, QA), they do not extend their protection into production on their own. Vendors offering both IAST and RASP solutions can cover the full SDLC.

CONCLUSION

Establishing a DevOps security program is possible, and leveraging the 6 pro tips outlined above will give you quick wins, ensuring that key stakeholders are on board and improving total cost of ownership. By using DevOps to unify highly specialized IT functions, teams come together to work in concert. Results are elevated to a new level. The top priority becomes providing end-to-end value to the customer and at the same time keeping the organization secure. This is a shared goal across the DevOps infrastructure, and it shifts security from being a bottleneck to being an enabler, driven by a continuous, automated, and shared system.

 Tim Chase, Director of Security at Nielsen, recently shared his story of how he successfully built and scaled the DevOps function at is organization. Tim says that an instrumentation-based approach that enables applications to be assessed and protected simultaneously and continuously has transformed his DevOps program. 

Hear how Tim built a successful DevOps program in this ON DEMAND VIDEO >> 

SOURCES:
1. McKinsey & Company:  DevOps: The key to IT infrastructure agility 
2. Gartner DevSecOps: How to seamlessly integrate Security in to DevOps (Sept, 2016)
3. Puppet Labs: 2016 State of DevOps Report 
4. DevOps Cycle Gallery
5. Tripwire: Marriage of Security and DevOps

Most companies build or buy software applications to run their business. Unfortunately, application code exposes critical vulnerabilities to hackers. Contrast solves this complex problem with a bold new secure technology platform that transforms application security by making software self-protecting. Intelligent Contrast agents are injected into the code, instrumenting applications with thousands of smart, agile sensors that detect and correct vulnerabilities before deployment, and protect the software applications in operation. No legacy security tool can protect every application, but a tenacious army of intelligent Contrast sensors can. Because Contrast technology works hand-in-glove with agile and DevOps teams, it transforms every software application in a company’s portfolio from a weak spot into a strong point to decisively repel attacks.

 To learn more about Contrast portfolio of products:  

• Interactive Application Security Testing - Used for infusing software with vulnerability assessment capabilities

• Runtime Application Self-Protection - Used for monitoring and protecting cloud applications

• Open Source Security Software and Compliance - Used for managing open source software risk in DevOps solutions