How to think about cloud security governance
Creating the right governance model for your organization
When customers first move to the cloud, their instinct might be to build a cloud security governance model based on one or more regulatory frameworks that are relevant to their industry. Although this can be a helpful first step, it’s organisations should also understand what the control objectives for their workloads should be.
Moving to the cloud provides you with an opportunity to deliver features faster, react to the changing world in a more agile way and return some decision-making power to the hands of the people closest to the business. In this fast-paced environment, it’s important to have a way to maintain consistency, scaleability, and security. This is where a strong governance model helps.
Choosing the right framework
Many customers use a standard framework that’s relevant to their industry to inform their decision-making process. Some frameworks that are commonly used to develop a security governance model can include NIST Cybersecurity Framework (CSF), Information Security Registered Assessors Program (IRAP), or BS 10012, and ISO 27701. Some of these standards provide requirements that are specific to a particular regulator or region while others are more widely applicable. You should choose one that fits the needs of your organization.
But while frameworks are useful to set the context for a security program and give guidance on governance models, you shouldn’t build a framework just to check boxes on a particular standard. Instead, you should build for security first and then use the compliance standards as a way to demonstrate that you’re doing the right things.
This is when controls should come into consideration. A control is a technical or process-based implementation designed to make sure that an identified risk is reduced to an acceptable level for the organisation. Examples of controls include firewalls, logging mechanisms and access management tools.
Controls will evolve over time and sometimes they evolve very quickly in the early stages of cloud adoption. During this rapid evolution, it’s easy to focus purely on the implementation of a control rather than the objective. However, if you want to build a robust and useful governance model, you can’t lose sight of your control objectives.
Choosing your cloud platform: making the most of AWS
The cloud platform you use is the foundation of many of the security controls. These guard rails of federation, logging, service control polices and automated response apply to workloads of all types. At Amazon Web Services (AWS), the security pillar in the AWS Well-Architected Framework builds on other risk management and compliance frameworks. It provides you with best practices and helps you to evaluate your architectures. These best practices are a great place to look for what you should do when building in the cloud. The categories—identity and access management, detection, infrastructure protection, data protection, and incident response—align with the most important areas to focus on when you build in AWS.
When you think about cloud security, we find it useful to use a layered cake as a good mental model. The base of the cake is the understanding of the below-the-line capability that AWS provides. This includes self-serving the compliance documentation from AWS Artifact and understanding the AWS shared responsibility model.
The middle of the cake is the foundational controls. This is the most important layer, because it’s where the most controls are and therefore where the most value is for the security team. You could describe it as the “solve it once, consume it many times” layer.
The top of the cake is the application-specific layer. This layer includes things that are more context dependent, such as the correct control objectives for a certain type of application or data classification. The work in the middle layer helps support this layer, because the middle layer provides the mechanisms that make it easier to automatically deliver the top layer capability.
The middle and top layers are not just technology layers. They also include the people and process parts of the equation. The technology is just there to support the processes.
Why governance matters
At the end of the day, it doesn’t matter what security frameworks or standards you use to inform your business, and you might not even align with a particular industry standard. What does matter is building a governance model that empowers the people in your organisation to consistently make good security decisions (and enabled your security team to make this happen).
To get started or continue to evolve your governance model with AWS, follow the AWS Well-Architected security best practices. Then, make sure that the platform you implement helps you deliver the foundational security control objectives so that your business can spend more of its time on the business logic and security configuration that is specific to its workloads.
The technology and governance choices you make are the first step in building a positive security culture. Security is everyone’s job, and it’s key to make sure that your platform, automation and metrics support makes that job easy.