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.
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:
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.
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 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.
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.
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.
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.
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.