Your Chance to Get It Right Five Keys to Building AppSec into DevOps Chris Wysopal Redev Boston – August 8th, 2017

Applications are riskier than ever

Majority of internally developed applications fail OWASP

DevOps enables competitiveness DevOps enables competitiveness due to: Speed (thanks to automation) Communication (thanks to collaboration) Reliability

Why Security is Essential Don’t trade off security for competitiveness

5 steps to achieving secure DevOps (TIME FILL) Re #2 and #3, somebody made this point during a DevOps talk at O’Reilly: “Security tests in CI/CD need to be binary. It succeeds or it doesn't.” This led to some discussion where some felt there should be a manual step because different apps have different risks, attack surfaces, and threats. Came to realization we were conflating CI/CD with just CI. (TIME FILL) Re #4, talk about our Security Champions program. (TIME FILL) Re #5, talk about security telemetry, piggybacking on tools that DevOps teams are already using, except to trigger on security-related events. Some of the stuff Etsy did under NickG and Zane, as an example.

Automate Security In Automated testing Static Analysis Software Composition Analysis Interactive Dynamic Analysis Invoke via APIs from your build and release pipeline Still do penetration testing, but don’t gate the release on it! Instead of penetration testing, why not dynamic? Instead of dynamic, why not static and SCA? Don’t not do the slower methods, just don’t gate your release on them Technology: SAST, guided DAST, APIs

2. Fail Quickly Fail quickly: Just like with QA, have as few security tests that run late in the cycle as possible. You want to automate security testing relatively early in the pipeline. Even better, look at doing it before the code hits the pipeline. Development tools that do security testing as you type have gotten a bad rap in the past for being noisy and inaccurate, but there’s a new generation of those coming that address those issues. Mature Technology: SAST in the pipeline (runtime concerns) Emerging technology: “instant SAST” or security unit testing – “as you type” (historical concerns about noise)

Pre-submit verification A pipeline example Release candidate Submit verification Full verification mainline Pass; commit to master Lots of places to integrate security in here. I’d argue that it depends a little on the codebase and a lot on your development teams. But the places I’d think about is the “full verification” stage, the “submit verification,” and before the developer even commits code. But we’re not done, because putting security on the pipeline is scary. Pre-check in review Pre-submit verification Fail Code commit Code commit Code commit Code commit

No false alarms: The problem with any automated testing is getting the noise level down. Starting with a static analysis tool that is low noise to begin with helps, but you also need to look at what you will allow to stop your pipeline, vs. that which just becomes backlog. Technology: Static analysis with low FP Emerging technology: Interactive Application Security Testing (coverage concerns) Process: Security mitigation review 3. No false alarms

4. Build security champions Build Security Champions: Part of what you want to think about is how you can reduce the input of flaws into the process in the first place. Look for opportunities to drive learning from findings whether through formal education or on the spot reinforcement. Ultimately security champions aren’t enough by themselves, but you can’t get better over time without them. Mature technology: eLearning and contextual tutorials. Process and humans: remediation coaching, instructor led training, embedding security into development teams, security in the “definition of done”

Keep operational visibility Not enough to think about appsec only before you ship: New vulnerability categories may emerge Your org may have applications in production that aren’t deployed through the common pipeline If you’re attacked, you want to feed that information back into development so you can address the issues quickly. Emerging technology: RASP (Runtime Application Self Protection) provides monitoring as well as the ability to block common kinds of attacks, and runs in the application or the container so it avoids some of the failings of WAFs. Mature technologies: WAFs (have to be tuned, not generally in the control of the DevOps team); web application discovery; software composition analysis.

Where should you secure DevOps? If you’re doing appsec today, you’re probably doing it in the Test stage. DevOps and other methodologies with automated build give us the opportunity to integrate into the pipeline (the Build stage). But you should also think about it before any code gets committed, by embedding security into your process and investigating arming your developers with “as you type” security tools. And you shouldn’t stop thinking about it after you ship either – at a minimum keep a bill of software components so you can quickly react when new vulns are found, and consider web application discovery/rapid baselining and RASP to ensure that you understand your perimeter and that you can be alerted to attacks and buy yourself some time to remediate the underlying vulnerabilities. Or maybe you do a blue green deployment and don’t turn everyone on until the code has passed a scan in production. There are lots of options.

Conversation starters (1) Which of your applications will pass through a CI/CD pipeline? What tolerance do you have for “false alarms” (FPs) that is integrated into your DevOps practice? Are you using Microservices?

Conversation starters (2) How do you plan to monitor your operational applications for security attacks? How do you plan to bring security expertise into the DevOps team?

Get smart on DevOps Train beyond your walls Train beyond your walls, i.e. become more educated on DevOps practices in general and CI/CD. Encourage non-security teams to participate in training on security testing and secure coding. Image: copyrighted, not for distribution Train beyond your walls