Cloud Governance

Stopping data breaches in the cloud more effectively

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

⚙️ Part of my series on Automating Cybersecurity Metrics. The Code.

🔒 Related Stories: Multicloud Security | Data Breaches | Cloud Governance

💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I cover cloud governance in my existing cloud security class but even with 5 days, there wasn’t enough time to go as deep into it as I would have liked. Cloud governance is a broad topic and varies across cloud providers. You can discuss it generally or more specifically — how do you actually implement cloud governance? I discuss it at a high level in my cybersecurity book that introduces cybersecurity fundamentals and risk management.

Cloud security governance is the key to stopping data breaches. It starts with understanding what causes data breaches, followed by how to stop them. It ends with creating rules that minimize both the risk of a data breach and the extent of the damage, should one occur. Then you need to effectively manage the people, technology, and processes within your organization to ensure people and systems follow the rules you created.

Putting your rules on a piece of paper, as was the case in old-school security efforts, is not going to save you. I speak from experience. People don’t even know those documents and rules exist. You need to inject security into people’s everyday workflow. To prevent data breaches, you need to disallow the things that cause them before they get into your environment. The architecture needs to facilitate identifying attacks and minimizing the damage.

Some classes also tell you what but not how. They don’t provide the nuts and bolts to go back and build what they are telling you to do. You want a plan and a way to make it happen. That plan involves a combination of security, software, and process management skills. Many people would ask me for a reference architecture in the past. I would say that there is no reference architecture because each organization is different and may have individual requirements. Additionally, the architecture is only part of the equation to get to a secure cloud environment.

Now more sample cloud architectures exist, but they are sometimes general and non-specific. They also may not work in your particular organization. We can start with a basic introduction to a foundational architecture and customize it from there to make it work for any organization. But if a company cannot implement fundamental guardrails and governance due to organizational politics, there’s only so much we can do. I address that in my paper, book, and classes.

Although I speak and write a lot about governance and risk management, I wanted to dive deeper into the hands-on aspects, so I’m expanding the cloud governance modules in my class. Hopefully, I can make it accessible to smaller companies as well. 2nd Sight Lab is leveraging some of these improvements in our own accounts and the way we teach classes and perform cloud penetration testing and cloud security assessments to test out some new ideas.

It helps to come from a place where you’ve been the one to implement cloud governance at a company from the ground up. I was on the original Capital One cloud team. My vision of how we could protect assets in the cloud wasn’t exactly how security was rolled out there, but it was the first major US bank to move to AWS. We had 11,000 developers at the time. No real guidance existed. A lot of the governance-related tools offered by AWS and other cloud providers came later.

Based on that experience, I wrote about my vision of cloud governance in a paper after that experience: Balancing Security and Innovation on Through Event-Driven Automation. A lot of the concepts in that paper and my book are now finally coming to fruition. The tools exist. The mindsets to implement them exist that were lacking in the past. We’ve had enough data breaches for people to stop saying, “That’s not possible in our organization.” People are now asking, “How do we do it?”

I went to another smaller company and as a cloud architect, later Director of SAAS Engineering, I was able to architect a fully automated cloud deployment pipeline with security baked in. I oversaw a DevOps team that successfully implemented it, and our cloud engineers used it for secure and testable deployments. This same pipeline uncovered people making mistakes thanks to a design that reigned in unwanted actions while providing flexibility to enable developers to customize applications and containers as needed. For people who say it can’t be done, it is possible. I’ve done it.

The question is, does the executive team have the will to implement it? Do they understand why it matters? (That is also covered in my book and one of the key reasons to read it along with learning cybersecurity basics.) And will they keep it running the way it was initially designed to stop cloud threats? There are many reasons why cloud governance efforts fall flat, as I wrote in a blog post on why cybersecurity is a team sport and the sequel, Security Teams are Not Enforcers.

Bringing a whole team together to learn cloud security will help most, but the initial design of your cloud accounts can lend itself to security or make it nearly impossible. I started writing a framework from the ground up to show how someone might go about initially implementing governance in a cloud account. You can follow along here.

Automating Cybersecurity Metrics (ACM)

A series of blog posts on cybersecurity metrics and security automation

medium.com

One paraticular post you may be interested in:

Stop Writing Paper Policies

ACM.112 A look at how effective your PDF and Word policy documents are in a cloud environment — and how to fix it