# Declarative Policies ## 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! {% hint style="warning" %} AWS Organizations must be enabled before Declarative Policies can be enabled and used. Check out my tutorial on [enabling AWS Organizations](https://www.techwithtyler.dev/academy/aws-security-cookbook-by-tyler/aws-organizations) if needed. {% endhint %} *** ## Supported Services Right now, AWS supports 6 services, but will hopefully provide more in the future. * AWS provides a [nice table](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_declarative_syntax.html#declarative-policy-examples) with example policies, so rather than duplicate this, I'll describe the benefits of these policies below. {% hint style="warning" %} 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 {% endhint %} ### 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](https://aws.amazon.com/blogs/networking-and-content-delivery/deploy-centralized-traffic-filtering-using-aws-network-firewall/). If enabled, this can help thwart techniques used by threat actors like [Crimson Collective](https://www.rapid7.com/blog/post/tr-crimson-collective-a-new-threat-group-observed-operating-in-the-cloud/), 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](https://permiso.io/blog/lucr-3-scattered-spider-getting-saas-y-in-the-cloud) (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! {% hint style="warning" %} 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. {% endhint %} 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](https://securitylabs.datadoghq.com/articles/whoami-a-cloud-image-name-confusion-attack/), i.e., essentially malicious AMIs posing as legitimate offerings from known vendors. I also have a [blog post](https://blog.pwnedlabs.io/defending-against-the-whoami-attack-with-aws-declarative-policies) 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](https://krebsonsecurity.com/2019/08/what-we-can-learn-from-the-capital-one-hack/) of over 106 million Capital One customers in 2019, and it's [still an issue](https://www.f5.com/labs/articles/campaign-targets-amazon-ec2-instance-metadata-via-ssrf) 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](https://www.darkreading.com/cloud-security/thousands-amazon-rds-snapshots-leaking-corporate-pii), 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 --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://www.techwithtyler.dev/cloud-security/aws/aws-defensive-security/aws-organizations/declarative-policies.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.