6 Executive Tips to Bring Security into the DevOps Era
Extending DevOps to your software application security team shifts security from being a bottleneck to an enabler. According to McKinsey & Company, the benefits of being a 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 rates1
Your peers and co-workers are ready for the transformation: 45% of respondents to the 2016 Puppet Labs State of DevOps survey said they expect DevOps to improve security. High-performing DevOps organizations that incorporate security into DevOps report 50% less time spent remediating security issues2.
The implication is clear: Improving the DevOps maturity of your security program is critical to time-to-market and customer confidence.
The DevOps – Security Zero Sum Game
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) 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 their 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.
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 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 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 utilized5.
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.
Establishing a DevOps-ready security program is possible. Leveraging the 6 pro tips outlined above will allow you to do that in a way that gives you quick wins, gets key stakeholders on board and improves total cost of ownership. Tim Chase, Director of Security at Nielsen, recently shared his story of how he successfully built and scaled the DevOps function. 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 >>
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