Why Does Security Matter For DevOps?

If you had $10,000, would you rather build a deck for your home or a fence?

For instance, when someone chooses a fence over a deck, there is probably something in their home they want to protect - something physically valuable, or emotionally valuable, such as privacy from a nosy neighbor. If they choose the deck, chances are they prioritize improving their product (their home) because they don’t have a pressing need to protect it.

Caroline is a Chief Security Strategist at Cobalt.io. She got her start in security with eBay and Zenga (you know, the company that created Farmville). At a previous All Day DevOps conference, she presented on why security matters for DevOps.

What Drives the Need for Security?

She likes to ask people what drives the need for security at their organizations. It seems like a straightforward question, but the answers aren’t always straightforward. Sometimes an answer can be found by looking at the organization’s first security hire and what they were brought in to do.

For example, when she joined eBay, security was brought in for compliance. Then their new CISSO noticed they were focused on compliance, but they had a more important driver - application security. After all, they were enabling strangers to transact over the Internet, opening up their application to bad actors.

At Zenga, there were security incidents as they were getting ready for an IPO. Farmville grew to 80 million active users, and they used AWS for elastic capacity. They had to trust their vendor, AWS, to be secure.

Before digging into why security matters to DevOps, Caroline touched on why DevOps matters to organizations. Quoting research from the DevOps Research and Assessment Group, organizations that have DevOps are 2X more likely to succeed than peers.

At the same time as organizations are adopting DevOps in increasing numbers, the role of security is changing. Web apps are increasingly more complex and the attack surface has changed. Previously, security was about protecting the perimeter. Caroline said organizations were like M&Ms - hard on the outside, soft on the inside. This was reflected in performance goals for security professionals, such as, if we didn’t have any breaches, you get your bonus. The assumption was you could keep them out, and you worked hard to keep gates up, do reviews, and give approvals.

DevOps Supports Trust

Now, everything is so interdependent, we have to work together and trust each other. We can’t assume that we can always keep bad actors out. Apps and APIs are the norm, employees bring and use their own devices, and vendor risk goes both ways. We don’t write all of our own software, and organizations are selling their software to other organizations.

Trust is so critical that security is now a business driver, not a cost center. Security is part of the sales process. Sales is touting its security, and buyers are evaluating security compliance and trust.

In the end, Caroline contends that sales and acquisition is the one reason security matters in DevOps. She points to three reasons: sales/acquisition, press, and, compliance. Press and compliance both come back to sales. You don’t want bad press about a breach because it will erode trust, and therefore sales. Similarly, you can’t sell software that requires compliance, say a healthcare application that needs to comply with HIPPA, if you are not compliant.

To underscore this point, Caroline quotes Bill Gates from 2002, “Trustworthy computing is more than any other part of work. If we don’t do this, people simply won’t be willing - or able - to take advantage of all the other great work we do.”

What are the next steps for an DevOps organization to improve their security?
Caroline is a certified consultant in BSIMM and, while she sees tremendous value and “loves it,” she contends the trouble with it is that it is really long and complicated. It has 116 security controls! Other methods that focus on the cloud, such as ISO 27017 and Cloud Controls Matrix have similar complexity. The latter has 133 things to do and ISO has 121.

Caroline says, “Your brain explodes when there are more than 100 things to go through to figure out what you need to do first.” It doesn’t matter how great it is if you don’t even get started because it seems insurmountable.

Modern AppSec Framework

Caroline introduced the Modern AppSec Framework. It is straightforward with 4 categories and 12 things to do. The 4 categories are:

• Govern. What is important?
• Find. What’s wrong?
• Fix. What are you going to do about it?
• Prevent. How do you scale our efforts?