The Importance of Internal Cloud Security Standards

Why You Need an Internal Standard

Internal standards contain prescriptive statements that provide engineers with a recipe to create repeatable secure processes. These statements declare how infrastructure or processes should be defined and are a baseline for security in a cloud environment.

Standards can also be written into reusable modules. When owned and maintained centrally, these modules provide developers with preconfigured templates that adhere to security standards. Converting the standard into policy as code allows immediate feedback to developers, linting the code as they are writing it. This allows developers to create business value quicker while reducing the amount of security remediation needed after deployment.

How to Write a Standard

Just like the standards themselves, how it is written will depend upon the needs of the organization. There are a few overall commonalities, however.

A standard should:

Be RFC2119 compliant. This means using words like MUST, and SHOULD to indicate requirements.
Be RFC8174 compliant. An add-on to the previous RFC, it specifies the required keywords’ capitalization.
Be precise when prescribing the requirements.
- “S3 buckets MUST use SSE-S3 or SSE-KMS encryption keys.”
Have different requirements for applications with different risk levels and criticality.
- Requiring the use of CloudHSM for a moderate risk workload is not a realistic view of the threats.
Have a key for each requirement that can be referred to by external systems. This is particularly important for organizations that use multiple cloud service providers (CSPs), as it helps to ensure the appropriate control is applied to the correct environment.
- AWS.IAM.1 - Identity and Access Management (IAM) users MUST NOT exist.
- GCP.GCE.1 - Identity Aware Proxy (IAP) MUST be used for all human remote connections to virtual machines.

Choose an accessible location to host the standard. This could be Confluence, a Google doc, or Github. Writing the standard should be a collaborative effort that includes the business owner, engineering, and security to ensure the requirements are realistic and align with the business’s risk appetite.

One size does not fit all in large complex environments. Many of the standards and benchmarks are written so that they can apply to a variety of environments. Take for example the CIS Benchmark for Amazon Web Services (AWS). There is a control for integrating CloudTrail with CloudWatch logs so that metric filters for alerts can be created. This control is irrelevant in an environment that has a security information and event management (SIEM) or other log aggregation and alerting tool.

How to Implement a Standard

Once an internal cloud security standard has been written, the next step is to implement and enforce its requirements. Requiring 30 new standards at once would create a large burden upon development teams to triage and remediate, pulling attention away from building business features. Enablement should be a planned and methodical process.

Create a Roadmap

Create a roadmap for enabling the controls. If there are any low effort, high impact items, prioritize those first. Often these are related to any publicly available resources to reduce and secure the attack surface. Some controls may have hidden complexity that is revealed by talking to the developer of the system.

Find the Baseline

The first step is to create detective capabilities to monitor compliance with the new control. In AWS Config is frequently used in tandem with Security Hub, but there is a large variety of Cloud Security Posture Management (CSPM) tools on the market that operate across multiple CSPs. This will not only provide a mechanism to detect compliance, but also give a general idea of the remediation work that needs to be done.

Facilitate Developer Enablement

The next step is to provide the development teams with the baselines and a target enforcement date. The standard should include documentation on how to implement the controls, and there should be a mechanism to provide feedback to the development teams as they are working on implementing the standards. This could be in the form of linting the code as it is written, developing preconfigured secure modules, or providing training for the engineering teams.

Implement Standards as Code

During the baseline phase, detective capabilities were created to detect compliance to controls. Because we do not want development teams to be in a constant state of remediation, for every detective capability, there should also be a preventative capability.

This preventative capability can be written as code, using policy as code tools such as Snyk, Terrascan, and OPA. Once the rules are written, they can be added to git repos as a pre-merge check. This creates a consistently applied process that is easy to maintain and audit.

Closing

Internal cloud security standards are essential for ensuring secure processes and reducing the amount of security remediation needed after deployment. Standards should be written in a precise and RFC-compliant manner and should be tailored to the risk appetite of the organization. Implementation should be done in a methodical way, with detective and preventative capabilities written as code and shared with development teams.

If you have any questions, or would like to discuss this topic in more detail, feel free to contact us and we would be happy to schedule some time to chat about how Aquia can help you and your organization.