Fix Common Cloud Security Risks With the Essential Cloud Security Controls Ruleset | Datadog

Fix common cloud security risks with the Essential Cloud Security Controls Ruleset

Author Darwin Salazar
Detection Engineer II
Author Zack Allen
Director, Security Research
Author Nick Frichette
Senior Security Researcher

Published: November 30, 2022

With the continual increase of attacks, vulnerabilities, and misconfigurations, today’s security organizations face an uphill battle in securing their cloud environments. These risks often materialize into unaddressed alerts, incidents, and findings in their security products. However, part of the issue is that many security teams are often stretched too thin and overburdened by alert fatigue.

Compounding these issues, the increasing complexity of large cloud and multi-cloud environments makes it difficult to know which risks to prioritize. Our State of AWS Security in 2022 report highlights that at least 41 percent of organizations have adopted a multi-account strategy in AWS. We expect this trend to continue as organizations adopt best practices and invest heavily in their cloud infrastructure.

In this increasingly complex picture, misconfigurations are often left unaddressed by security teams. A study conducted by the International Data Corporation (IDC) in 2021 found that companies with 1,500–4,999 employees miss 30 percent of all alerts. Given that missing alerts and findings are seemingly inevitable, it is up to the security teams to identify what must be prioritized versus what can wait.

There are countless best practice configuration guides for cloud environments, but many teams find it difficult to choose which one to use as a baseline. DevOps and security teams want to ensure that security is embedded at every critical juncture of their cloud environment and in their software development lifecycle (SDLC), including post-deployment. However, with so much ground to cover, teams often struggle to identify and prioritize which remediations protect them from the most imminent risks.

Today, we are announcing the Essential Cloud Security Controls Ruleset for Cloud Security Management (CSM). DevOps and security teams can use this ruleset to prioritize the remediation of misconfigurations in their environment. They’ll also be able to leverage Datadog’s cloud security expertise to stay protected against emerging vulnerabilities and threats to cloud environments. By remediating the insecure configurations that pose the most imminent and greatest risk, DevOps and security teams can operate with peace of mind as they scale their operations.

Essential Cloud Security Controls Ruleset demo.

The Essential Cloud Security Controls Ruleset includes 10 key rules each for AWS, Azure, and GCP. We have selected the rules based on industry best practices, the risk of significant impact, and the potential to have prevented a known public breach. For example, in AWS environments, using the default Instance Metadata Service version 1 (IMDSv1) can introduce the risk that attackers could steal IAM credentials via server-side request forgery attacks. Because of this risk, Datadog Cloud Security Management includes a detection rule to identify instances using IMDSv1 and recommends upgrading to the more secure IMDSv2. You can find a full list of the included rules below.

Datadog’s Security Research team is constantly evaluating the threat landscape for new best practice configurations, cloud breaches, and cloud attack toolsets used by security researchers and threat actors. As the cloud threat landscape changes, the team will continuously add, update, and deprecate these misconfiguration detection rules. All customers have to do is keep this ruleset enabled and remediate surfaced findings.

Expand your security visibility

For existing Datadog customers, you will find the Essential Cloud Security Controls Ruleset on the Cloud Security Management homepage, under Compliance Reports. If you’re not a customer, sign up for a today. To learn more about Datadog Cloud Security Management, see our documentation.

The rules

As organizations continue to fend off the latest threats and attacks, Datadog Security Labs is here to ensure you’re always kept up to date and protected from the latest emerging risks. With this ruleset, we not only streamline your security efforts—we also help reduce alert fatigue and minimize the risk of high-criticality misconfigurations slipping through the cracks. Our goal is to make your life simpler and easier, and to help you continue to focus on what’s important.

AWS

Control #TitleDescription
1.1IAM role trust policy does not contain a wildcard principalEach IAM role must have a trust policy which defines the principals who are trusted to assume that role. It is possible to specify a wildcard principal which permits any principal, including those outside your organization, the ability to assume the role. It is strongly discouraged to use the wildcard principal in a trust policy unless there is a Condition element to restrict access.
1.2IAM policies that allow full “:” administrative privileges are not createdIAM policies are how privileges are granted to users, groups, or roles. It is recommended and considered best practice to give only the permissions required to perform a task. Determine what users need to do and then craft policies that let the users perform only those tasks, instead of allowing full administrative privileges.
1.3S3 bucket is not publicly exposed via bucket policyUpdate your bucket policy as your Amazon S3 bucket is currently publicly accessible.
1.4RDS snapshot is not publicly accessibleSecure your Amazon Relational Database Service (RDS) database snapshots by ensuring they are not publicly accessible.
1.5S3 bucket ACLs are configured to block public write actionsModify your access control permissions to remove WRITE_ACP, WRITE, or FULL_CONTROL access for all AWS users or any authenticated AWS user.
1.6Multi-factor authentication is enabled for all IAM users with a console passwordMulti-factor authentication (MFA) adds an extra layer of protection on top of a username and password. With MFA enabled, when a user signs in to an AWS website, they will be prompted for their user name and password, and for an authentication code from their AWS MFA device. It is recommended that MFA be enabled for all accounts that have a console password.
1.7IAM access keys older than 1 year have not been used in the last 30 daysThis rule identifies IAM access keys that are older than one year and have not been used in the past 30 days.
1.8‘Block Public Access’ feature is enabled for S3 bucketAmazon S3 provides Block public access (bucket settings) and Block public access (account settings) to help you restrict unintended public access to Amazon S3 resources. By default, S3 buckets and objects are created without public access. However, someone with sufficient permissions can enable public access at the bucket or object level, often unexpectedly. While enabled, Block public access (bucket settings) prevents an individual bucket, and its contained objects, from becoming publicly accessible. Similarly, Block public access (account settings) prevents all buckets in the account, and contained objects, from becoming publicly accessible.
1.9EC2 instance uses IMDSv2Use the IMDSv2 session-oriented communication method to transport instance metadata.
1.10No root account access key existsThe root account is the most privileged user in an AWS account. AWS Access Keys provide programmatic access to a given AWS account. It is recommended that all access keys associated with the root account be removed.

Azure

Control #TitleDescription
2.1Web app redirects all HTTP traffic to HTTPS in Azure App ServiceAzure Web Apps allow sites to use both HTTP and HTTPS by default. Web apps can be accessed by anyone using non-secure HTTP links by default. Non-secure HTTP requests can be restricted and all HTTP requests redirected to the secure HTTPS port. It is recommended to enforce HTTPS-only traffic.
2.2Azure Key Vault is recoverableThe key vault contains object keys, secrets, and certificates. Accidental unavailability of a key vault can cause immediate data loss or loss of security functions (authentication, validation, verification, non-repudiation, etc.) supported by the key vault objects. Datadog recommends the key vault be made recoverable by enabling the “Do Not Purge” and “Soft Delete” functions. This is to prevent loss of encrypted data including storage accounts, SQL databases, and dependent services provided by key vault objects (Keys, Secrets, Certificates) etc., as may happen in the case of accidental deletion by a user or from disruptive activity by a malicious user.
2.3User has ‘Delete Key Vault’ activity log alert configuredCreate an activity log alert for the Delete Key Vault event.
2.4SQL Databases do not allow ingress 0.0.0.0/0 (ANY IP)Ensure that no SQL Databases allow ingress from 0.0.0.0/0 (ANY IP).
2.5PostgreSQL Databases do not allow ingress 0.0.0.0/0 (ANY IP)Ensure that no PostgreSQL Databases allow ingress from 0.0.0.0/0 (ANY IP).
2.6‘Secure transfer required’ is set to ‘Enabled’Enable data encryption in transit.
2.7All keys in Azure Key Vault have an expiration time setEnsure that all keys in your Azure Key Vault have an expiration time set.
2.8Blob Containers do not allow anonymous accessAnonymous read access is disabled for Azure Storage Blobs.
2.9Default network access rule for Storage Accounts is set to denyRestricting default network access provides a layer of security, because storage accounts accept connections from clients on any network. To limit access to selected networks, change the default action.
2.10All secrets in the Azure Key Vault have an expiration time setEnsure that all Secrets in the Azure Key Vault have an expiration time set.

GCP

Control #TitleDescription
3.1RDP access is restricted from the internetGCP Firewall Rules are specific to a VPC Network. Each rule either allows or denies traffic when its conditions are met. Its conditions allow users to specify the type of traffic, such as ports and protocols, and the source or destination of the traffic, including IP addresses, subnets, and instances. Firewall rules are defined at the VPC network level and are specific to the network in which they are defined. The rules themselves cannot be shared among networks. Firewall rules only support IPv4 traffic. When specifying a source for an ingress rule or a destination for an egress rule by address, an IPv4 address or IPv4 block in CIDR notation can be used. Generic (0.0.0.0/0) incoming traffic from the Internet to a VPC or VM instance using RDP on Port 3389 can be avoided.
3.2SSH access is restricted from the internetGCP Firewall Rules are specific to a VPC Network. Each rule either allows or denies traffic when its conditions are met. Its conditions allow the user to specify the type of traffic, such as ports and protocols, and the source or destination of the traffic, including IP addresses, subnets, and instances. Firewall rules are defined at the VPC network level and are specific to the network in which they are defined. The rules themselves cannot be shared among networks. Firewall rules only support IPv4 traffic. When specifying a source for an ingress rule or a destination for an egress rule by address, only an IPv4 address or IPv4 block in CIDR notation can be used. Generic (0.0.0.0/0) incoming traffic from the internet to VPC or VM instance using SSH on Port 22 can be avoided.
3.3Cloud storage buckets have uniform bucket-level access enabledUniform bucket-level access is enabled on Cloud Storage buckets.
3.4The default network does not exist in a projectTo prevent use of the default network, a project should not have a default network.
3.5Cloud storage bucket is not anonymously or publicly accessibleIt is recommended that IAM policies on Cloud Storage buckets do not allow anonymous or public access.
3.6Compute instances do not have public IP addressesCompute instances should not be configured to have external IP addresses.
3.7Instances are not configured to use the default service accountConfigure your instance to use an account other than the default Compute Engine service account, because it has the Editor role on the project.
3.8OS Login is enabled for the projectEnabling OS Login binds SSH certificates to IAM users and facilitates effective SSH certificate management.
3.9SQL database instances do not have public IPsDatadog recommends configuring the second generation SQL instance to use private IPs instead of public IPs.
3.10Only GCP-managed service account keys are used for service accountUser managed service accounts should not have user-managed keys.