InfusionPoints began our advisory work in FedRAMP just when the FedRAMP program was being formed. Our first FedRAMP project was with Dell Services where we helped develop the concept for a NIST accelerator -- a kit of hardware and software with preconfigured NIST controls. The FedRAMP PMO was formed in 2012 while we were working on this concept, and our NIST project ultimately became a FedRAMP Moderate JAB authorized IaaS solution. From our early experience with FedRAMP we understood the value of providing standardized environments with built-in controls to accelerate compliance outcomes.

Continuing our advisory work in the FedRAMP space we worked to push the acceleration concept further along, helping our clients build centralized control environments that would provide controls across multiple products, reducing the burden of achieving ATO as much as possible. With each engagement we became more hands-on in supporting the development of these environments. As we built our reputation in the AWS Partner Network (APN) we continued adding the capabilities that would soon help launch our clients’ cloud environments as a service, with preconfigured controls built-in. The goal was to completely automate the deployment, while allowing customization and flexibility to support client needs. InfusionPoints began searching for the best pattern to follow to meet FedRAMP Moderate and High baselines as well as the DoD CC SRG IL4 and IL5 requirements.

Up until that time, most of our clients were using single AWS accounts for the system boundary. Indeed today, our competitors providing ATO acceleration are also using single AWS accounts for landing zones they create for their clients. At InfusionPoints we began looking at concepts for multi-account landing zones, designed to isolate specific system functions to certain accounts. This is when we took notice of the Compliant Framework for Federal and DoD Workloads in AWS GovCloud (US). Hereafter, I’ll just call this “the DoD compliant framework”.

(Diagram from Compliant Framework for Federal and DoD Workloads in AWS GovCloud (US))

Particularly of interest to us was the use of multiple accounts in a way that specifically met certain control requirements in a granular way, including (but not limited to):

• Information Flow Enforcement (AC-4)
• Separation of Duties (AC-5)
• Least Privilege (AC-6)
• Remote Access (AC-17)
• Protection of Audit Information (AU-9)
• Least Functionality (CM-7)
• SDLC and Developer Controls (SA-*)
• Separation of System and User Functionality (SC-2)
• Boundary Protection (SC-7)

Uniquely, the DoD compliant framework also enabled the FedRAMP requirement of supporting Trusted Internet Connections (TIC) and the DoD CC SRG requirement to accommodate connection to a DoD Cloud Access Point (CAP). This is accomplished through the Transit account which handles all ingress and egress for the VPCs in the other accounts. The environment can be connected to a TIC or CAP via AWS Direct Connect (DX) or VPN.

InfusionPoints had decided to standardize on Hashicorp Terraform for the bulk of our cloud automation work (a blog post for another time) so we leveraged the DoD compliant framework as well as numerous other resources and some of our own creative “special sauce” to build and launch XccelerATOr -- the first partner-developed multi-account landing zone automated deployment capability.

Example XccelerATOr Deployment

XccelerATOr features a multi-account layout much like the DoD compliant framework. XccelerATOr can be deployed in US East/West as well as AWS GovCloud (US) regions. The central account is the organizational root account and contains centralized services. SCPs in AWS Organizations are used to limit usage of accounts for least functionality. Ingress and egress traffic from VPCs are centralized via Transit Gateway to the Transit account where internal and external Route 53 hosted zones provide for DNS SEC. Remote access is accomplished via AWS Workspaces hosted in the Management Account and secured by MFA via DUO Federal. CloudTrail is enabled centrally, and CloudWatch Logs is used for CloudWatch Logs enabled services and EC2 instances. Logs are moved via S3 replication, Kinesis Streams and Kinesis Firehose for hot storage and audit log reduction in Graylog, and long-term storage in S3 buckets in the Logging Account where retention requirements are enforced. AWS WAF, Amazon GuardDuty, AWS Shield, and Squid proxy provide for boundary control. Security groups and ACLs provide for information flow enforcement. Systems Manager provides for flaw remediation and access control for console access via Session Manager. AWS Config enforces security configuration of AWS services and monitors for configuration creep. SDLC and CI/CD pipeline is provided for Infrastructure as Code via the central account, and InfusionPoints can provide client accounts in any configuration needed to support development, staging, and production requirements.

The XccelerATOr deployment example above describes a client who chose to only place the production workload along with a centralized customer portal requiring two accounts. Clients can manage their own Terraform or CloudFormation templates for their accounts, or we can help manage the infrastructure in client accounts as needed. We can also deploy CI/CD pipelines in the clients' development and staging accounts and support customers in building and demonstrating all required SDLC and Change Management requirements. XccelerATOr provides 76% of FedRAMP Moderate controls and control enhancements.

InfusionPoints can launch an XccelerATOr environment to accelerate your path to FedRAMP Authorization or DFARS-CMMC compliance in about a week, and we can be working with you to secure your application and SDLC. Contact us to learn more about XccelerATOr and get started today!