In the first post of our Cloud Security Center of Excellence series we covered the two critical aspects of being successful at cloud security: accountability and empowerment. Without accepting accountability to secure all of the organization’s cloud assets, and being empowered to make changes to the environment in the name of improved security — it’s hard to enforce a consistent baseline of security practices that can dramatically reduce your organization’s attack surface.

When we think about the organization models that lend itself to cloud security success, it’s sometimes easier to start with the models that don’t work very well. Then we can contrast with our recommended models. So let’s start by listing a few organizational anti-patterns.

  1. Anarchy: Basically the cloud teams (read developers) do whatever they want. This is what we call _Lift and Pray_ because the developers are tasked with making their applications functional – and while well-meaning, security is not their first priority. The result tends to be inconsistent security at best and insecurity at worst. This really shows when we start working with customers, and what they say they want to do is much different than what we find as we implement security guardrails.
  2. Organizational: Marketing is different than HR than Finance, right? Actually, not so much. Clearly each business unit will have slightly different security requirements, but only slightly different. The security practices should be largely consistent across all the cloud environments throughout organization.
  3. Regional: Similar to organizational-driven models, a regional (or geographic) policy isn’t very effective. Clearly, there are difference in monitoring and privacy in EMEA, then in the rest of the world, but that only applies to a select few practices. Most will be similar across all the regions.
  4. Multi-cloud: It’s really hard to get cloud security right for just one cloud provider. If you try to do multiple cloud providers at once, the challenge increases exponentially. When multi-cloud is an initial approach that usually indicates another form of anarchy, which results in the same outcomes — inconsistent security at best and insecurity at worst, across all of your cloud environments.

Why don’t these work? Because the security team doesn’t have accountability or empowerment, or in many cases either. To be clear, each can work up to a point. But once you hit scale in cloud operations, having a sub-optimal org structure really hinders your security capabilities.

So let’s find a middle ground.

Security Driven Policies

In this model, security drives the policies and sets guidelines for the organization and evangelizes those practices across the organization. This model works, but there are some nuances:

  1. Cloud understanding: First, the CISO must really understand cloud. Not what their existing set of vendors tells him/her about cloud, but how cloud really works and what that means for security controls.
  2. Exception Handling: Second, when the DevOps teams want to do something different (and they will), there needs to be a defined risk acceptance process, so the teams clearly understand they are going outside of the guidelines and will accept the consequences.

To pull this off, the CISO needs to be influential in the environment. They accept responsibility for the protection of data residing in the cloud and are empowered to stop deployment of new apps and new features.

Our preferred model shouldn’t be a surprise because we named the series after it. It’s a Cloud Security Center of Excellence model. Here is how we define this:

  1. Have representation from Dev, Ops, and Security: It’s not called the Security CoE. It’s the **Cloud** CoE, so it needs to be cross-functional to ensure the requirements and issues of all constituents are factored into the approach.
  2. Set Guidelines: As mentioned above, the CoE establishes a set of guidelines representing the best practices and expectations that each cloud team must follow to protect their environment.
  3. Enforce Guardrails: Once the guidelines are established, you’ll need to ensure they are followed. This involves implementing guardrails to continuously assess and control your cloud(s) against these best practices.
  4. Total Transparency: This one can be a little controversial, but we favor an approach of publishing a report on “compliance” against the guidelines. Some groups may have legitimate reasons for not adhering to the guidelines, and they get a pass. But others don’t, and putting them in a position to not just answer to the CoE team, but also their executive level peers can be a very powerful motivator.

Is it called a Center of Excellence? Not consistently, but nearly all successful cloud organizations create some sort of cross functional “cloud team” as they mature their operations. As they get more traction with defining the guidelines and having success, the term excellence can be added.

Is the CoE a full time gig? Probably not at first, though as your cloud(s) expand and evolve, you’ll find that these folks will emerge as a powerful consultative force working with many of the cloud and business teams building applications.

In the next post, we’ll tackle the role of automation in helping the CoE enforcing the best practices in a scalable manner. It’s not enough to just point out where some cloud stacks fall outside the guidelines, it’s about making sure the issues can be remediated quickly and efficiently.