TL;DR

The second-day opening keynote was about security. Pati Gallardo’s talk was DevSecOps for Developers. Let’s learn what role DevSecOps is.

In the previous keynote, we learned that the world thinks in roles. I have never heard before term DevSecOps. It is about DevOps security.

Pati started at Opera (browser) and was responsible for the security of that product. Her programming language was C++, with all security challenges that C++ brings to the developer. Application security is a broad spectrum of knowledge, Pati context was binary security of Opera browser.

We got first Book Alert, Accelerate:

The book punchline is How can we apply technology to drive business value.

My A-HA moment was that security vulnerability is simply a bug in your product. The problem with vulnerabilities is that they usually represent complex user stories for your product. A regular user would never trigger that story, but a hacker would. Hacker reward is access to your application.

A user story for a vulnerability bug is called an exploit. What exploit do:

• read – is a data leak
• write – is setting up unwanted code
• execute – is trigger execution of that code

The target of every hacker is your application state machine. The goal is to put it in a weird state. Exploit puts applications from that weird state to hacker new code.

One example of an exploit that managed to write was to put a short integer into a long integer location. The difference in the size of long and short integer hackers used for putting an application in a weird state.

As Pati loves to solve hard problems, she joined customer service. There was one anecdote where a customer reported that it could not receive a call. She investigated server logs and could not conclude to root cause. She tried Occam’s Razor approach, she phoned that customer, and to her surprise, the customer answered it. The customer explained that it could receive a call when the phone is on, but not when it was off :).

In the investigation of vulnerability reports, Pati also uses the Cynefin framework:

 

When they receive a vulnerability report, they are in the chaotic quadrant that needs to be STABILIZED. After that, the DISCOVER in complex space. The engineering approach solves complicated quadrant, and in the obvious quadrant, they automate vulnerability discovery.

Which skills we map to the Cynefin quadrant? In a chaotic quadrant, Devops is using critical thinking skills; in the complex, you need to be creative. The complicated quadrant is about skill development and an obvious one we deploy automation. Here is Devops techniques mapping. In Chaos, we explore, debug is used in the complex quadrant. The exploit is developed in the complicated quadrant, and the Metasploit framework is used in the obvious quadrant.

How to map testing in the Cynefin framework? Chaos monkey is used in Chaos. Chaos Monkey is responsible for randomly terminating instances in production to ensure that engineers implement their services to be resilient to instance failures. Testers use A/B testing in the Complex quadrant. TDD and automation is a candidate for Complicated quadrant, and code static analysis for Obvious quadrant.

Pati provides statistics on why security testing is not usually done. We have 1 security expert on 10 develop engineers and on 100 developers.

To avoid vulnerability reports that could be a company killer, Pati suggests a premortem analysis that should be a team activity.

Data Flow Diagram is a useful technique, especially in mob sessions. In the Data Flow Diagram, you show how data flows from user to storage through the system subsystems. It is ideal for mitigating the risk of data security.

To try to prevent company killer event, Pati listed six HACKS:

1. Use available tooling on your platform for monitoring (observability).
2. Manpower is enabled using quick communication
3. Version control. I found out interesting git commit statistics: Commit message size is inversely proportional to a number of files in that commit. To be able to do effective security code reviews, keep message size broad and the number of files small.
4. A/B testing could be used to quickly turn off feature with vulnerability to B feature with similar functionality but without vulnerability.
5. Have a hotline. Not only phone one, but on the product home page, you must have a security page with information on how to securely report a vulnerability using email.
6. Do not panic. Do a triage on reported vulnerability using the Security, QA, and Marketing team. Prepared a simple procedure checklist.

It is good practice to have infrastructure as code, so infrastructure could be set up automatically. Automate source code analysis scanners, but be prepared to filter out false positives. For the end we got Book Alert:

Incidents Handling by SANS.