Cloud security has become increasingly complex of late. Cloud providers use tens of thousands of APIs, container orchestration systems are growing in number and complexity, and more platforms and services are entering the cloud-native ring. What’s more, each of these components pose a potential security risk to organizations. And it’s you as the customer that’s responsible for the configuration and security of those components. Perhaps it’s no surprise, then, that Gartner predicts, “through 2025, 99 percent of cloud security failures will be the customer’s fault.”¹

To examine this complexity, we were delighted to welcome Dan Hubbard, CEO of cloud security vendor Lacework, to speak at PagerDuty’s first-ever virtual Summit global conference in September. Offering his take on the cloud security conundrum, Dan spoke of the “Shared Irresponsibility Model.”

“Unfortunately, what we see in a lot of companies is DevOps pointing at security and going, ‘Oh, that security. They’re always slowing us down with these big burdensome security processes.’ And the security people are going, ‘Oh, DevOps. They’re moving so fast. They’re just making us insecure,’” Dan explained.

The reality, he shared, is that you can operate in the cloud with both speed and safety. DevOps-security conflict is often futile, and irresponsibility doesn’t have to occur in your cloud security practices. Instead, as customers become responsible for more and more of their cloud environment’s security, it’s imperative that DevOps and security teams find better ways of working together.

The Four Tenets of Cloud Security Conflict

Dan explained how the Shared Irresponsibility Model revolves around four key factors:

1. Architecture and infrastructure

If the security architecture doesn’t align with the cloud infrastructure, DevOps teams can become frustrated with cloud security products that don’t fit their practices. This is why we need organizational responsibility models, Dan explained.

Collaboration and communication between DevOps and security is essential, so that who’s responsible for dealing with a security breach is crystal clear. “Things like finger pointing, misalignment and governance problems happen here,” he said—which can be critical issues.

2. Tooling and tuning

Organizations spend a lot of time on the tooling process, but time and time again there are missteps. “What we see quite often is DevOps and security working from two different data sources and data planes,” Dan explained.

Ideally, there should be a shared tooling across teams. It doesn’t necessarily have to be the exact same tooling, but it should come from the same data plane. That way, development and security can agree on who tunes performance and can also have shared risk models. Both teams can therefore understand the cause and effect across security-DevOps operations.

3. Understanding changes in data

Gone are the days of making changes once a month in a private data center—the cloud is far more dynamic. “Now, everything happens in near real time so security has to keep up with that—and you have to understand the risks associated with change,” Dan said.

The key, then, is for DevOps and security teams to correlate these changes and risks also in near real time. They must work together and avoid finger-pointing to decipher if a change in infrastructure from DevOps increases the risk of a security breach. And if downtime happens, they must work together to understand whether it was caused by a security event or developer mistake.

4. Workflows and automation

Another key factor contributing to the Shared Irresponsibility Model is not just knowing which workflows to build and run, but also which workflows to automate. “The ability to merge and build common workflows through automation is going to be really important,” Dan said. “There are a lot of repeatable things that are actually automate-able.”

For example, this could be automating how multifactor authentication is turned off or automating a response when employees open buckets without the right privileges. And with automation comes the need for DevOps and security teams to agree on the underlying infrastructure and the security posture needed to enable this.

Enabling Collaboration With PagerDuty

To allow developers and security teams to harmonize their incident response, Lacework and PagerDuty recently announced an integration partnership. In a short space of time, Dan said, around 40 percent of Lacework customers are using the PagerDuty integration.

The integration will tell DevOps and security teams how the incident should be remediated. “We give you as much information to allow you to respond,” he said. “The integration is a really great way to take the information we’re collecting, and then deliver that directly to PagerDuty to make sure the right person is getting the right data to close or triage the ticket directly.”

Interested in watching the full session? Register here for free to watch it on demand, along with other partner and customer sessions.

¹Source: Smarter With Gartner, Inc., Is the Cloud Secure?, October 10, 2019, https://www.gartner.com/smarterwithgartner/is-the-cloud-secure/.