LinkedInGitHubYouTube

Declarative Policies

Centrally declare and enforce your desired configuration for a given AWS service at scale across an organization

Overview

Released a year ago, AWS Declarative Policies enforce attributes for a handful of services. While this was (and still is) possible using AWS Service Control Policies (SCP), those have limitations such as the number of SCPs attached to an OU, policy size, and more. Declarative Policies provide a way to offload our SCPs, freeing them up for other security considerations.

Let's dive into what we can do with Declarative Policies!

AWS Organizations must be enabled before Declarative Policies can be enabled and used.

Check out my tutorial on enabling AWS Organizations if needed.

Supported Services

Right now, AWS supports 6 services, but will hopefully provide more in the future.

  • AWS provides a nice table with example policies, so rather than duplicate this, I'll describe the benefits of these policies below.

An important consideration before deploying these to your environment -

  • If you follow best practices for designing an AWS Organization, you likely have, e.g., all Production accounts under a "Prod" OU (Organizational Unit)

  • Declarative Policies do not support account-level exceptions, so if one account needs an exception, you can't deploy the policy to the whole OU, and we'll need to get creative

VPC — Block Public Access

This type of policy is great when your organization wants to lock down networking and/or have a centralized ingress/egress network architecture.

If enabled, this can help thwart techniques used by threat actors like Crimson Collective, who have been known to exfiltrate data through EC2 instances.

This policy supports three configurations:

  1. Off — Policy is not enabled

  2. Block Ingress — All traffic to/from VPC is blocked at the Internet Gateway (IGW). NAT Gateways and Egress-only Internet Gateways still work.

  3. Block Bidirectional — All traffic to/from VPC is blocked, no matter which gateway is used

EC2 — Block Serial Console Access

EC2 Serial Console provides access to an EC2's serial port and is used for troubleshooting and configuration. Only certain instance types, like Nitro and bare metal, are supported.

If enabled, this can help thwart techniques used by threat actors like Scattered Spider (LUCR-3), who have been known to leverage this capability - avoiding network detection monitoring since these connections are hardware-based.

This policy supports two configurations:

  • On or Off

EC2 — Block Public AMIs

AMIs can contain sensitive data, such as secrets, code artifacts, and other sensitive information. If these AMIs are shared intentionally (or maliciously), it could be a bad day!

It's important to note that any existing publicly exposed AMIs will remain public. Make sure you inventory your AWS data regularly to identify these.

This policy supports two configurations:

  1. Unblocked — effectively "off" i.e., policy doesn't block any AMIs from being public

  2. Block new sharing — AMIs cannot be publicly shared after the policy is enabled

EC2 — Allowlist AMIs

This policy restricts which AMIs are authorized to be used and protects against the whoAMI attack, i.e., essentially malicious AMIs posing as legitimate offerings from known vendors. I also have a blog post describing how to implement these policies to protect against this attack.

The configuration options for this policy have increased since the release — nice!

So, first, you choose the policy state:

  1. Enabled — policy is enforced

  2. Disabled — policy is disabled

  3. Audit Mode — policy only audits violations — man, I wish this were an option for other AWS security policies!!

Then you choose some Image Critera to narrow down what to allow vs not.

EC2 — Configure IMDS Settings

This policy enables you to enforce IMDSv2 for EC2 instances, which better protects against Server-Side Request Forgery (SSRF) attacks. This attack led to a data breach of over 106 million Capital One customers in 2019, and it's still an issue even today!

We have a few configuration options for this policy:

  1. http_tokens

    • No Preference — defaults to the AMI's configuration

    • Required — enforces IMDSv2

    • Optional — allows both IMDSv1 and v2

  2. HTTP Put Response Hop Limit — Setting depends on environment

  3. HTTP Endpoint

    • No Preference — defaults to the AMI's configuration

    • Enabled — enables the IMDS service

    • Disabled — disables the IMDS service

  4. Instance Metadata Tags

    • No Preference — defaults to the AMI's configuration

    • Enabled — any tags on the EC2 are available in IMDS

    • Disabled — EC2 tags are not available in IMDS

EBS — Block Public Snapshots

Public EBS Snapshots, much like public AMIs or public RDS snapshots, can contain sensitive data as they're backups of EC2 instances in the AWS account.

This policy supports three configurations:

  1. Unblocked — effectively "off" i.e., policy doesn't block any EBS snapshots from being public

  2. Block all sharing — any current public EBS snapshot (or attempts in the future) are blocked, and private

  3. Block new sharing — only new attempts to make an EBS snapshot public are blocked, any existing public snapshots remain public

PreviousAWS OrganizationsNextAWS Incident Response

Last updated

Was this helpful?