Creating a Cloud Security Standard

I’ve written here in the past about how I’ve created Cloud Security Scorecards to help our account holders fix security issues and to help management hold the account holders accountable for their security posture. Today I’m going to discuss the Cloud Security Standards against which we measure our cloud accounts.

Our first major decision was not to have a single standard for the three public clouds we operate in. The differences between AWS, GCP and Azure are major, and creating a document that addressed configuration in the abstract would create confusion. Therefore we ended up with three documents which all ended up abbreviated as CSS-AWS, CSS-Azure and CSS-GCP.

Cloud Security Standards

The general outline of each document is:

1. Purpose

   This section defines the scope (anything in AWS/Azure/GCP across the entire company) and what is excluded (O365, G-Suite, etc). Most importantly, it defines what is meant by a requirement and a recommendation. Throughout the document, requirements use the term “must”, while recommendations use the term “should”.

   Also defined in this section is the process for requesting and granting exceptions to the standard, along with the process for updating and ratification (which I’ll discuss later).

2. Roles & Responsibilities

   Here we define the key parties in our organization as it pertains to public cloud. They include our Cloud Governance, Security & Finance groups. Also the team or teams who manage the AWS Organization payers, Azure Enrollments and Google Organizations are defined.

   The other two key parties defined in this section are the Executive Sponsor and Technical Owner:

   The Executive Sponsor is the entity to which overall management of the AWS account is delegated. The Executive Sponsor is responsible and accountable for adherence to all Cloud and Information Security Policies and Standards. The Executive Sponsor must be a Company employee with a designated job title of Director of higher. The Technical Owner(s) may be a team or a third-party approved by Security and Legal.

3. Background

   This section discusses the particulars of each public cloud platform. For example, the CSS-GCP discusses the relationship between GCP, G-Suite and the other Google services we use as they pertains to cloud identity for Google. This section is also where the Shared Responsibility Model is discussed and any notion that “I don’t need to worry about patching, the cloud provider does that for me” is explicitly debunked.

   We also make sure to point out that with great power comes great responsibility as we hand out full control of what is essentially a data-center to developers who may have always had a sysadmin team responsible for the triad of Confidentiality, Integrity and Availability:

   In order to foster a more democratic, dynamic and responsive development model, management of AWS accounts can be delegated to respective departmental executives (Executive Sponsors). These executives are then responsible to the [Cloud Governance Function] for adherence to policies around finance, security and risk compliance.

   Finally, I also reference all the other pertinent policies & standards. Our data classification standard is important to reference as those classifications drive many of the security requirements found later in the document. Network Security, Vulnerability Management, Content Protection, etc all apply in public cloud as they do on-prem. One primary goal of each CSS document is to define how the controls provided by that cloud provider can be used to meet our other infosec policy requirements.

4. Standards for the Organization

   This section defines the security requirements for the top-level account. This is less of an issue for AWS, but is key with Azure and GCP. First thing we do is make sure that Security, Legal and Cloud Governance are involved in the creation of any new top-level accounts. Section 4.01 of the CSS-GCP states:

   No Company-owned domain may register with G-Suite, GCP or Google Cloud Identity without permission of the Security, Legal, and Cloud Governance.

   Additionally because identity is managed at the top level in GCP & Azure, and because both clouds allow a mix of enterprise and consumer identities, we define what types of accounts can leverage these clouds and the requirements for authentication (ie MFA).

   Section 4.02 Identity & Authentication

   (a) All Access to GCP for Employees must be via a Google Enterprise Account. This applies to the company.com Organization and any other authorized Organizations. No Personal Google Accounts may be used to access GCP Resources.

   (b) All Authentication to GCP and other Google Resources provided by a Managed Google Account or Organizational G-Suite Account must leverage MFA.

5. Standards for Account Owners

   This section defines the requirements that are specific to the Exec Sponsors & Tech Owners. It contains all the details on how an AWS Account, Azure Subscription or GCP Project must be configured.

   For example, the section of the CSS-AWS on the root user contains language similar to the following:

   Section 5.03 Root User

   Use of the root account beyond initial provisioning of the AWS account is prohibited.

   (a) Upon completion of the AWS account creation multi-factor authentication (MFA) must be enabled.

   (b) [Requirements for how to store root MFA & Passwords].

   (c) In accounts where Content (as defined in the Content Security Policy) or PII data is stored, Segregation of duties should be instituted by which the party with the root password is not the same party with the MFA Token.

   (d) If the root login must be used, an email should be sent to [SOC’s email address] documenting the reason for the root login. Valid reasons to login as root include resetting S3 Bucket Policies, enabling MFA Delete, and other reasons documented by AWS here

   (e) The root email address must not be tied to an individual employee and must be a distribution-list

   (f) All AWS Accounts must set the contact info [in the aws portal] with current information and review it every 6 months.

   (g) All AWS Accounts must have security contact set to [the contact information for our SOC which is defined in the document]

   It is also in this section that the requirements for Security to audit the configuration of the cloud account is defined. For AWS, this means specific CloudFormation templates that need to be deployed. For GCP & Azure, it is the specific role that needs to be applied to specific service account/principals. Any other enterprise security tools that must be deployed in the account are also defined here. While I typically deploy the security tools via automation when I detect a new account was created, defining the requirement help to avoid complaints around cost of these tools.

   Since VPCs/vnets are typically done by account admins and not by devops, the requirements for Network security fall into this section. This is where our rules around “no ssh open to the world”, and “never use 0-65535 as a port range” are defined. We also define the firewalling and network segmentation rules for VPCs to talk to each other and back to our on-prem network.

6. Standards for Developers & Application Owners

   This section mostly consisted of tagging standards and issues pertaining to data-classification. I intended for some DevSecOps principals to be applied here, but gaining the consensus necessary to enforce this threatened the overall roll out of the standards.

   Right now, Section 6 defines requirements around encryption of material based on data-classification in additional to logging standards for applications.

7. Standards for Specific Cloud Services

   This section is typically the most interesting. Here is where we define how to use each of the IaaS or PaaS services for each cloud provider. For AWS, this section covers:

   • Section 7.01 S3 & Glacier
   • Section 7.02 AWS Managed Databases
   • Section 7.03 EC2
   • Section 7.04 Lambda & API Gateway
   • Section 7.05 Containers, ECS & Fargate
   • Section 7.06 Route53 & SES
   • Section 7.07 CloudFront
   • Section 7.08 ElasticSearch Service
   • Section 7.09 Amazon WorkLink

   The obvious is covered (no public-write S3 buckets), in addition to some specific considerations for other departments. The use of Route53 Domains states:

   7.06 (a) Any domain registered by an Account or Application Owner in AWS’s Route53 Domains registrar service will be reviewed by Legal. Legal may instruct the Account Owner to modify registration information or transfer the domain into the possession of the [legal].

   As AWS releases new services, this is typically where they are first mentioned in security documentation. We rarely forbid the use of a service (ClientVPN being the one exception to that rule), but we do want to make sure everyone understands the implications. This section was very recently updated based on all the AWS re:Invent announcements.

   Here is the section on Lambda. I include this section as Lambda is a major AWS service that is still not addressed by the CIS Benchmarks for AWS.

   Section 1.01 Lambda & API Gateway

   • (a) API Gateway should implement individualized authentication at the API Gateway layer. AWS Provides API Gateway Custom Authorizers to meet this requirement.

   • (b) Lambda Functions must only be invoked by authorized AWS Accounts. The use of “Effect: Allow” with “Principal: *” in Lambda Invocation Policies is forbidden.

   • (c) Lambda Functions must execute with the minimal IAM permissions necessary to accomplish their function. Using the default “lambda_basic_execution” role is not allowed

   • (d) Lambda Function IAM Policies must enable logging to CloudWatch Logs

   • (e) Lambda Function Code must not be stored in a S3 Bucket that is either world-readable or world-writable.

   • (f) Password or other sensitive parameters must be passed into Lambda functions via encrypted environment variables, leverage SSM Parameter Store or AWS Secrets Manager. These must be encrypted with Customer Managed KMS Keys

   • (g) For internally focused applications, API Gateway should be deployed inside the VPC

   • (h) Lambda Functions must be tagged to establish contact and ownership.

   • (i) Lambda functions must use the most recent (or next most recent) language run-time

   • (j) Lambda functions that are fronted by an external ALB must leverage an approved AWS WAF on the ALB. This is to protect against web attacks against the Lambda functions. If the ALB is fronted by a CDN that provides a WAF that meets this requirement.

   • (k) Lambda Layers must never be shared publicly. They may only be shared with authorized company accounts.

   • (l) API Gateways should be protected by AWS WAF

   Just because a cloud service is or isn’t mentioned doesn’t mean it is or is not approved or in use. This section covers what I’ve been able to identity threats from misconfiguration, and then to promote the awareness of those potential threats.

Updating & Ratification

These standards are written to be achievable with our current level of cloud maturity. We don’t assume everyone is capable of running immutable infrastructure. Nor do we want a rigid Service Catalog of architectural patterns built by an ivory tower of architects. Every draft change is circulated for comment to all the account owners. I typically get comments back that help me refine my language to be more explicit. Some examples are when I’m considering the micro-perimeterization of a publicly exposed service, and I forget to consider that there is a large class of services that are only accessible via a private connection (ExpressRoute/DirectConnect) from on-prem. Language then needs to reflect the existence of a public ip address or some other exposed attack surface.

Ratification is done by the Cloud Governance committee. This helps the business understand and agree to the cost implications for any security services tooling that will appear on the Executive Sponsor’s bill. Our model is that security costs billed by the cloud provider are costs of doing business in the cloud and are borne by the account owners. Security tools bought from third parties are paid for out of the security budget.