I’ve been asked to review DoD AWS Ref Arch document. I don’t think there was enough abbreviations there. That would have been really long to type out there. So many words. Not like I’m writing words about writing words now. On to the meat and potatoes.

The document was completed in middle of 2015, not bad. I think I’ll try a cliff notes format for this.

Caveat Emptor

These are just my notes. If you are doing this for business purposes you should probably get a professional to look over your specific cases.

Be responsible for your own systems.


They assume you have a basic compentency in security, administration, and are aotherwise not going to have your eyes glaze over when reading technical information. I wonder if that mens I’m out :laughing:.

Also, running in AWS alone doesn’t make your system secure. Duh. I’m glad someone said it.


Establishing the autthority under which AWS has been authorized, effecitvely you may only achieve level 2 authorization without using the US Government Cloud region in AWS. The hails from guides in 2012. In 2015 the DoD published a new set of requirements called teh CC (Cloud Computing) SRG (Secruity Requirements Guide) which AWS at the time of writing has not been deemed incompliance with at the time of writing. Compliance information. The guide is for level 2 reference architectures for the general regions and level 4-5 of government regions.

Getting Started

Know your system and resolve issues within the context of your system. We’ve all seen that person who says “but this is the reference architecture we must follow it at all costs” BS.

Shared Responsibility and Governance

You are building atop AWS’s infrastructure, don’t fight it and work with it. Amazon will take care of physical security through hypervisor security. You are responsible for patching guest OS through your applications. Your responsibilities are based on the services used.

Mission Owner Responsibility

You are responsible for:

  • Storage Buckets and Objects (S3)
  • Compute Instacnces (EC2)
  • Virtual Private Clouds (VPC)
  • Firewalls
  • Application Management


  • Patch Management
  • Application Maintenance
  • Vulnerability Scanning

General recommendation to create AMIs with updated patch levels to improve out of the box expierence.

Operational Ioslation

You should have a set of security groups which match the role of the nodes within the graph of your system and restrict the abilities of those node ot only the minimum required functionality.

VPCs should be designed to protect each role within the graph from all other nodes. This should restrict the information to expected traffic only.

A backup system needs to be designed and implemented. Recommended the data is backed up to S3 regularly. Set the permissions on EBS and S3 backups.

Hosts should use intrusion detection and so sort of explotiation scanning.

The system as a whole should have vulnerability scanning and penetration testing performed regularly. They note you should coordinate with AWS Security Teams.

Users should be restricted to least privilege nessecary, including root accounts and IAM policies.

The identity federation is a stupid call out to integrate with ActiveDirectory. For my purposes I wonder if it would integrate with Google and be able to map roles from there.

All privleged accounts should activate MFA, especially the AWS root account.

All logs should be forwarded to a management subsystem which follows the rules of all other nodes (IE: not publically accessible, etc). It is recommended that LogTrail is enabled for all hosts to audit the AWS calls made from hosts.

Use Availability Zones to allow for timely recovery fo the application in case of downtime.

Data at rest for the operating system must use at least AES256. Specically calls out DoD guidelines, including FIPS 140-2. AWS takes care of destroying the physical media however I’ve seen attacks which have sucessfully recovered unencrypted data so take that seriously.

Your system must be scanned for intrusion detect in compliance with CNDSP. I’m not sure what this means right now so I’ll have to return back to it.

The Compliance Governance setion is fairly striaght forward and outlines decent practices you should probably be using anyway.


AWS has acheived the compliance nessecary to operate the cloud infastructure within what they refere to as the CONUS regions. Specifically they call out GovCloud, US East, and US West. I’m sure you’ll violate something by hosting outside of the US.

Cloud Computing SRG

AWS has obtained the standards nessecary for an operator using AWS to asses compliance with the DoD CC SRG. Intersting that SRG level 6 is not permissible on cloud hosted systems. CUI stands for Controlled Unclassified Information. Depending upon your specific system you will need to target a specific level of compliance.

AWS Global Infrastructure

They’ve achieved compliance for the following services within US East, US West, and USGov:

  • EC2
  • EBS
  • S3
  • VPC
AWS Services

This reads like a brochure for AWS’s serice that they list. Elastic IPs aren’t applicable for impact levels greater than 2. I’ll probably only make notes about level 2 for now. Elastic Load Balancing reads like it’s aloud but they don’t explicitly mention it anywhere…so probably ins’t.

For networking the AWS VPC maps to the Virtual Private Enclave. Using the VPC is the primary mechanism to control access to a particulare role of hosts and they encourage you to design your own network within the system. With each AZ needing it’s own subnet design I would imagine there isn’t a good reason not to use the 10/8 space and do something like 10.{region}.{subnet}.{host} or the like. Where region will probably be subneted with the lowest being the home office.

The network ACLs have some fun times due to the way they number rules for application. This should be fun figuring out how to decompose the ruleset into something actionable.

The S3 option for encrypting at REST should be used, it doesn’t look like it will o it by default.


We don’t get at rest encryption out of the box with EBS. They recommend looking at third party modules to support at rest encryption of images root disk.

S3 may use either client side (before submitting objects to S3), or server side encryption which is entirely AWS managed.

There is the AWS CloudHSM which is a hardware module that costs $5K up front + ~$1.8K/month there after you could use to manage keys yourself.


The users of your organization should be under a single account with IAM access restricted to what they work on.