Complying with DHS Emergency Directive 19-01 on AWS

On January 22, 2019, the Department of Homeland Security (DHS) posted Emergency Directive 19-01, “Mitigate DNS Infrastructure Tampering.” The directive states that the DHS Cybersecurity and Infrastructure Security Agency (CISA) is aware of multiple executive branch agency domains that were impacted by a DNS tampering campaign. The directive requires that by February 5th agencies must take four specific actions. For each action, we suggest the guidance below for AWS customers.

Action One – Audit DNS Records

“Within 10 business days, for all .gov or other agency-managed domains, audit public DNS records on all authoritative and secondary DNS servers to verify they resolve to the intended location. If any do not, report them to CISA.”

For customers using Amazon Route 53, you can manually check the Route 53 console and inspect each hosted zone and associated record set to determine if each record points to its intended location.

For customers that have many hosted zones, the following AWS Command Line Interface (CLI) snippet lists your Route 53 public hosted zones:

Note: the examples below use the AWS CLI on a Linux-based host using the bash shell in US-East-1.

aws route53 list-hosted-zones --query 'HostedZones[?Config.PrivateZone==`false`][Name,Config.Comment]'

Each hosted zone may have multiple records. The following snippet loops through each hosted zone and prints all the record set data for review. We use a modification of the the prior command to loop through each hosted zone:

for i in $(aws route53 list-hosted-zones --query 'HostedZones[?Config.PrivateZone==`false`][Id]' --output text |awk -F '/' '{print $3}'); do aws route53 list-resource-record-sets --hosted-zone-id $i;done

Note: The CLI returns one hundred Route 53 records at a time. Customers with more than one hundred hosted zones must paginate the results.

Action Two: Change DNS Account Passwords

“Within 10 business days, update the passwords for all accounts on systems that can make changes to your agency’s DNS records.”

AWS recommends that enterprise customers leverage identity federation instead of AWS Identity and Access Management (IAM) user principals. Federated users with access to relevant IAM role principals can change their passwords within existing enterprise identity stores (e.g., Microsoft Active Directory).

Customers can review IAM user principals that have Route 53 permissions using the following CLI snippet. This script loops through all IAM user principals and checks for Route 53 access policies.

for i in $(aws iam list-users --query Users[*].Arn --output text); do echo $i; aws iam list-policies-granting-service-access --arn $i --service-namespaces route53 --query 'PoliciesGrantingServiceAccess[?not_null(Policies)]'; done

For customers that use identity federation, you can also scan for role principals that contain Route 53 access policies. The script snippet below provides this capability.

for i in $(aws iam list-roles --query Roles[*].Arn --output text); do echo $i; aws iam list-policies-granting-service-access --arn $i --service-namespaces route53 --query 'PoliciesGrantingServiceAccess[?not_null(Policies)]'; done

Action Three: Add Multi-Factor Authentication (MFA) to DNS Accounts

“Within 10 business days, implement multi-factor authentication (MFA) for all accounts on systems that can make changes to your agency’s DNS records. If MFA cannot be enabled, provide CISA with the names of systems, why it cannot be enabled within the required timeline, and when it could be enabled.”

Customers using identify federation, accessing AWS through role principals, must configure MFA on their existing enterprise identity provider. Note, as per NIST 800-63b, Short Message Service (SMS)-based MFA is not recommended.

For customers that are using IAM user principals, AWS IAM documentation provides step-by-step instructions for enabling MFA on user principals. Per AWS security best practices, you should also enabled MFA on your AWS account root user. The documentation walks you through this process, as well.

The following snippet identifies IAM user principals that have Route 53 access but do not have MFA enabled.

for i in $(aws iam list-users --query Users[*].Arn --output text); do echo $i;  j=$(aws iam list-policies-granting-service-access --arn $i --service-namespaces route53 --query 'PoliciesGrantingServiceAccess[?not_null(Policies)]'); if [[ -z "$J" ]];then echo "MFA Device"; u=$(echo $i|awk -F '/' '{print $2}'); aws iam list-mfa-devices --user-name $u; fi; done

Action Four: Monitor Certificate Transparency Logs

“Within 10 business days, CISA will begin regular delivery of newly added certificates to Certificate Transparency (CT) logs for agency domains, via the Cyber Hygiene service. Upon receipt, agencies shall immediately begin monitoring CT log data for certificates issued that they did not request. If an agency confirms that a certificate was unauthorized, it must report the certificate to the issuing certificate authority and to CISA.”

Customers using AWS Certificate Manager (ACM) should configure a CloudWatch event for new ACM certificate requests.

The following snippet will create an SNS topic for email notification and CloudWatch event rule for ACM certificate creations, deletions, or changes.

s=$(aws sns create-topic --name dhs1901-alert --output text); 
aws sns subscribe --topic-arn $s --protocol email --notification-endpoint my-email@example.com
echo $s

Note, the ARN output from the last command (e.g., arn:aws:sns:us-east-1:0123456789012:dhs1901-alert) will be used in the commands below.

You will need to validate your email address. AWS will send a message to the specified address. You may either click on the link in the email or use the following code snippet with the token in the email to authorize the subscription.

aws sns confirm-subscription --topic-arn arn:aws:sns:us-east-1:0123456789012:dhs1901-alert --token 01234567890123456789

We can now create the CloudWatch event rule to alert when ACM changes occur using the following snippet.

aws events put-rule --name "DHS1901StateChanges" --event-pattern "{\"source\": [ \"aws.acm\" ], \"detail-type\": [ \"AWS API Call via CloudTrail\" ], \"detail\": { \"eventSource\": [ \"acm.amazonaws.com\" ], \"eventName\": [ \"RequestCertificate\", \"DeleteCertificate\", \"ImportCertificate\" ] }}"

Now we will set the SNS topic as the target for the CloudWatch event rule.

aws events put-targets --rule DHS1901StateChanges --targets "Id"="1","Arn"="arn:aws:sns:us-east-1:0123456789012:dhs1901-alert"

Customers can also create custom CloudWatch event alerts for changes to Route 53 as part of their environment surveillance regime. Similarly, CloudWatch events can alert on the removal of MFA devices from relevant account principals.

In this blog, we provided suggested guidance to address the four actions required by DHS Emergency Directive 19-01. Customers with additional questions regarding how to leverage AWS services and features to address the Emergency Directive by the February 5th deadline should reach out to their AWS account team or AWS support for further guidance.