EXECUTIVE BRIEF | THE DEVOPS-READY SECURITY PROGRAM 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. INTEGRATE WITH THE (CI / CD) INTEGRATION AND DELIVERY PIPLELINE AND DEVOPS TOOLCHAIN 3 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. Figure 1. The DevOps Era SDLC4 1 PRODUCT OWNER Business Need / Use Cases 7 Monitoring/ Operations 2 Software Development Team 3 DevOps + Continuous Delivery Cycle Software Check In 6 Automated Deployment 5 4 Automated Test Scripts Automated Software Build 3 WELCOME TO THE ERA OF SELF-PROTECTING SOFTWARE | CONTRASTSECURITY.COM EXECUTIVE BRIEF | THE DEVOPS-READY SECURITY PROGRAM 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). 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. The figure 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. 4