As we return to our Cloud Security Center of Excellence series, we talked about the need for a CoE structure as well as our preferred organizational model. Now let’s dig in a bit more and discuss a bit more specifically into setting up your CoE to be able to define and enforce the best practices that should guide cloud activities in your organization.

To rehash a little bit, we believe that the security function looks quite a bit different as the cloud-native mentality proliferates and cloud becomes the primary delivery vehicle for technology. Today, security is a separate group that has both architectural, design, and operational responsibilities. That worked fine when all technology was under the auspices of the Central IT group and took direction from the CTO and CIO.

But all technology is not going to remain within the central IT group, especially cloud computing, given the ease to spin up resources and move fast. Thus, security teams must evolve to become more of an advisor to the DevOps and cloud teams (increasingly within the business units). In this world, the security job becomes one of influence not of mandates. Of selling the benefits of building security into the cloud stacks, not bolting security onto the infrastructure underneath whatever has been developed. Security is customized for the application/tech stack, not deployed as a set of generic security controls.

A natural offshoot of this model is that over time security operations becomes entirely subsumed into the DevOps functions. And that means the security team’s primary purpose evolves to governance, defining and enforcing the security practices to protect the organization’s data. The defining part is straight forward enough, but how do you enforce these policies? It’s a process, so let’s unpack the aspects of the process.

Visibility

It all starts with visibility over what’s happening in the cloud. There is good news and bad news here. The good news is that anything you do in the cloud can be tracked and assessed. Via APIs (and automated discovery of new resources) you can get a sense of all of your cloud assets pretty much at any time. The bad news is that you need to know about the cloud accounts and have access to those accounts, which is not always so easy given that anyone with a credit card can stand up a cloud account and build things.

Over the past few years, we’ve seen organizations focus on centralizing some aspects of the cloud, especially the financials. Typically this happens by employing a structure like AWS Organizations or Azure Management Groups, which provides the highest level of organizational structure to a cloud environment. Without a centralized structure for standing up new accounts, there is a low likelihood that you’ll be able to enforce best practices.

Shared Services

Once you have visibility over all of the cloud accounts in your environment, you can ensure each account leverages CoE defined and offered shared services, which provide consistency for the activity in your cloud. There are many different kinds of shared services, but we’ll highlight three to focus on initially:

  1. IAM: Identity and Access Management is best done at the highest level of the organization. So the CoE will define the general structure of the IAM groups and roles, and define how each project team can and should provide entitlements to the resources needed within the cloud environment. Federation can be used to ensure consistency with on-prem and multi-cloud environments.
  2. Logging and Monitoring: In an environment like the cloud that can quickly devolve into chaos, it’s critical to ensure logging/monitoring happens consistently. Now you don’t need to aggregate all of the telemetry from every project in every cloud. But you do need to aggregate security data, again for compliance and governance purposes.
  3. Incident Response: Although you can architect cloud applications that are far more secure than what can be built on-prem, you cannot assume that you’ll never have assets or applications compromised. So the CoE also needs to establish a cloud-native (and provider-specific) incident response motion that leverages the cloud’s ability to move tech assets out of production and spin up new ones (leveraging technology like auto-scaling).

There is a ton of detail under each of these shared services (in fact, our friends at Securosis have multi-day training courses to dig into the specifics of cloud security architecture and operations), we’ll highlight these for now and dig into each in subsequent posts.

The Guardrails Service

So let’s dig back into the challenge that eventually every Cloud CoE faces. That’s how to enforce the best practices across hundreds of applications in multiple regions, potentially across multiple cloud providers. It’s definitely not by having a bunch of people in the backroom, continually checking and tuning the environment. You have to embrace Cloud Security Automation as the means to automatically assess and then take action in the event of a policy violation.

The cloud industry is quickly adopting the term Guardrails to describe the ability to define and enforce these security and operational policies. Thus, another critical shared service under the auspices of the Cloud CoE is the Guardrails service.

This service involves being able to connect to each account, assess what’s happening in that account, identify potential violations of best practices, notify the responsible parties of the issue, and make the fixes in the account to ensure the issue does result in data loss or another adverse outcome.

Cloud security automation drives the Guardrails Service, and we’ll wrap up the series next with a discussion of how specifically to set this service up, defining the guardrails, triggering action, and building credibility to take on responsibility for enforcement.