This document discusses how to automate compliance and security on AWS through infrastructure as code. It recommends architecting for compliance upfront by mapping controls to AWS services, creating standardized baselines, and taking advantage of automation tools. It also emphasizes continuous monitoring and validation to maintain compliance.
2. Compliance & Accreditation
How do I architect for compliance in AWS?
How can I make architecting for compliance repeatable?
How can I validate that my architecture is compliant before
deployment?
How can I ensure continuous compliance in production?
How can I simplify my accreditation process and get to ATO faster?
4. Shared Responsibility Model
Customers are responsible for how they use AWS components in AWS
Customer Data
Platform, Applications,
Identity & Access Management
Operating System, Network &
Firewall Configuration
Client-side Data
Encryption & Data
Integrity
Authentication
Server-side Encryption
(File System and/or
Data)
Network Traffic
Protection (Encryption/
Integrity/Identity)
DatabaseStorageCompute Networking
Edge
Locations
Regions
Avail. Zones
AWS Global
Infrastructure
Customer
Responsible for
security in’the Cloud
Responsible for
security of the Cloud
AWS
5. Customer Challenges
Meeting compliance requirements (NIST, PCI, HIPAA, CJIS, etc.)
Taking advantage of new services and features when designing for the
Cloud
Making many critical decisions to ensure a secure application when
using the AWS Shared Responsibility Model
Mapping security controls to numerous AWS services
− Example: 400 NIST 800-53 Security Controls to 42 AWS services
Common Challenges in Compliance
6. Shared Responsibility Model
Compliance in the Cloud: Examples
Framework Control Description Implementation in AWS Architecture (Example)
NIST 800-53 AU-9 The information system protects
audit information and audit tools from
unauthorized access, modification,
and deletion
AWS CloudTrail and/or log files in S3 buckets which have
S3 bucket policies to prevent modification or deletion (write
once read many)
PCI DSS Requirement 4 Encrypt transmission of cardholder
data
Elastic load balancers must enforce HTTPS encryption
using strong security policies enforcing TLS
HIPAA - Tenancy requirement Requirement to use “dedicated” tenancy for EC2 instances
storing or processing PHI data
CJIS Policy Area 7 Configuration management Enforce use of hardened EC2 instance operating systems
and/or pre-approved Amazon Machine Images (AMIs)
DoD CSM Levels 4-5 No direct access from VPC to the
Internet
Amazon VPCs for Impact Levels 4-5 data require VPN
connection, no Internet gateway (IGW)
7. Simplifying Compliance: Key Concepts
Know your compliance framework(s)
− Translate compliance controls to technical implementation
− Create and manage a pre-approved common security controls mapping (SCTM,
CRM, etc.) to use when architecting for security and compliance
Distinguish between inherited controls vs. customer controls
− Establish (in advance) which controls are inherited by the global infrastructure
Take advantage of capabilities the Cloud provides
− Infrastructure as Code
− AWS services (CloudTrail, AWS Config, Amazon Inspector, etc.)
− Partner solutions
Automate standard implementations
8. Automation
Why automate compliance?
− Reduced time to ATO
− Lower cost
− Fewer resources required
− Less human error
− Consistency
− Reproducible
9. Automating Compliance in AWS
Infrastructure As Code
− Managed and controlled like software
− Validate pre-deployment
− Test-driven development (TDD) for security and compliance
Standardization
− Predefined guidelines, mapped to security controls
− Consistent, reusable architecture and configuration
Compliance at scale
− Enforce policies across accounts, workloads, systems
− Shared services for security, logging, monitoring, access control
Transparency
− Everything is an API call!
− Auditability, logging
− Continuous monitoring (CM) for both applications and infrastructure
11. Pre-Development
Development
Testing
Production
Architect for
Compliance
Architect for
Compliance
Provide
Baselines
Enterprise
Accelerator for
Compliance
IATT ATO
Develop
Applications
Enterprise
Accelerator for
Compliance
AWS Service
Catalog
Submit SSP
Validate
Architecture for
Compliance
Continuous
Monitoring
Manage Security-
Relevant
Changes
Integration
Testing for
Compliance
Submit for ATO
Accelerating the Journey to ATO
Vulnerability
Scanning
AWS Code
Pipeline
Compliance Control
Mapped to
Implementation Method
Developing with a
predefined baseline
implementing control
Validation & Testing
for Requirement
Continuous
Monitoring for Control
Implementation
Amazon InspectorAWS Config
AWS Config
AWS
OpsWorks
AWS Elastic
Beanstalk
12. Pre-Development
Understand your compliance requirements
− Compliance type(s): NIST 800-53, ICD 503, DoD CSM,
PCI, HIPAA, etc.
− Workload-specific: DoD CSM Levels 1-2, FedRAMP High,
etc.
Architect for compliance
− Map security controls to technical implementation
Predefine baselines
− Examples: VPC configuration, connectivity, AWS Identity
and Access Management (IAM) configuration,
logging/monitoring
− Baselines align with governance model
Pre-Development
Architect for
Compliance
Provide
Baselines
Enterprise
Accelerator for
Compliance
AWS Service
Catalog
Compliance Control
Mapped to
Implementation Method
13. Development
Deploy predefined baseline environment
− Service Catalog
Manage all AWS components as code
− Version Control (AWS CodeCommit, Git, SVN)
Take advantage of AWS services
− AWS CodeDeploy/AWS CodePipeline
− Elastic Beanstalk
− OpsWorks
Submit for IATT (prepare for ATO)
− Simplify the process of security controls
mapping
Development
Architect for
Compliance
Develop
Applications
Enterprise
Accelerator for
Compliance
Submit SSP
Developing with a
predefined baseline
implementing control
AWS
OpsWorks
AWS Elastic
Beanstalk
14. Testing
Unit testing
− Validate before deployment
− Check AWS CloudFormation templates for
non-compliant configurations
Integration testing
− Deploy infrastructure code into AWS account
− Run tests for validation (Config, Inspector,
HBSS, partner products, etc.)
Prepare for ATO
− Submit predefined security controls mapping
for simplified ISSO/ISSM approval
Testing
Validate
Architecture for
Compliance
Integration
Testing for
Compliance
Submit for ATO
Validation & Testing
for Requirement
15. Testing Infrastructure Code
Identify resource configurations in
code that violate compliance
− Example tools:
https://github.com/stelligent/cfn_nag
Common points of compliance
validation
− Security group rules
− Network Access Control List (network ACL)
rules
− IAM policies
− S3 bucket policies
− Elastic Load Balancing security policies
"sg": {
"Type":
"AWS::EC2::SecurityGroup",
"Properties": {
"SecurityGroupIngress": {
"CidrIp": “0.0.0.0/0",
"FromPort": 22,
"ToPort": 22,
"IpProtocol": "tcp"
},
"VpcId": "vpc-12345678"
}
}
}
}
Example: AWS CloudFormation template
contains security group allowing
unrestricted access to SSH
16. Production
Authority to Operate (ATO)
− …but compliance doesn’t end with ATO
Continuous monitoring
− Security-relevant changes to configuration
Non-compliance
− Continuously monitor for changes that violate
compliance
− Immediate notifications
− Event-driven, automated remediation
Production
Continuous
Monitoring
Manage
Security-
Relevant
Changes
Vulnerability
Scanning
Continuous
Monitoring for Control
Implementation
Amazon InspectorAWS Config
18. Lifecycle of a Compliance Control: Example
Control Pre-Development Development Testing Production
SC-7(5)
Boundary Protection - DENY BY
DEFAULT/ALLOW BY
EXCEPTION: The information
system at managed interfaces
denies network communications
traffic by default and allows network
communications traffic by exception
(that is, deny all, permit by
exception).
Enterprise Accelerator
defines required NIST
800-53 compliance
control and maps
predefined to
implementation in
CloudFormation
template
Enterprise Accelerator
as starting point for
CloudFormation
template development
Automated unit testing
with cfn-nag tool
validates that control is
not being violated in a
template
Integration testing with
Config verifies
Config rule
continuously monitors
for violations of this
control and takes
corrective action if a
violation is detected
Requirement: Rules with
“ALL TRAFFIC” not
permitted in security groups
Base templates by default
deny all ports except those
required to be open
Starting point in
development with templates
which
Testing for security groups
where all ports are open
If security group changes,
Config rule immediately
evaluates and determines if
rule changes violate control
20. AWS Compliance Enterprise Accelerator
AWS Compliance Enterprise Accelerator
Address security/compliance requirements and AWS best practices
Knowledge transfer on AWS security model
Standardized for specific use cases
Ready to be pre-approved by customer assessment organizations
Ready to deploy “out of the box”
Customizable
AWS Compliance Packages Include:
Managed Automation –CloudFormation templates, automation scripts
Detailed Documentation – User Guide, setup, customization
Security Controls Matrix – Mapping of controls to implementation
21. AWS Enterprise Accelerator for Compliance
Currently Available Quick Starts
NIST High baseline
(Featuring Trend Micro Deep Security)
NIST SP 800-53 (version 2.0)
DoD SRG (GovCloud)
Trusted Internet Connection
800-171
PCI DSS
Secure Commercial Cloud Architecture (SCCA)
Late July preview
http://aws.amazon.com/quickstart
Title: “Fast track your ATO with Compliance Automation”
Compliance automation made easy! Who says Compliance and security can’t be cool! Customers in regulated verticals such as Financial Services (PCI DSS), Public Sector (FedRAMP/NIST) must prove that their IT systems are secure and dependable. However, traditional security and compliance processes are slow, tedious, labor intensive, and not interesting. Come learn about how to employ “Push Button” or Alexa powered AWS security/compliance tools that drive down costs, increase your speed to the cloud and make your auditors and developers happy.
INTRODUCTION
- Introduce self & session
*Intro key points:
Customers in the public sector are taking advantage of all the benefits of moving workloads to AWS including agility, efficiency, cost savings, scalability…
…but same customers must still adhere to the existing compliance frameworks
Discuss strategies and tools to help accelerate compliance (more specifically, getting an authorization to operate faster)
How compliance can be parallel to cloud adoption and not a hurdle to it
How we can actually implement better compliance in the cloud through automation and taking advantage of available of tools and services
Also in turn ensuring adherence to compliance well beyond just ATO
Common questions from customers…
How do I architect for compliance?
In other words, design and develop a compliant configuration in AWS (from VPC networking, to access control, to continuous monitoring requirements, etc)
How do we take existing compliance controls and turn them into technical implementations
How can I make architecting repeatable?
How can we make it so we are not reinventing the wheel every time we want to deploy a new workload
How can I validate before deployment?
How can I validate for compliance along the way, avoiding common pitfalls when submitting for my AT
How can I ensure continuous compliance?
Compliance doesn’t have to end at ATO obviously, how do I implement solutions including continuous monitoring and automation tools to ensure my deployments are continuously compliance
How can I simplify the accreditation process…?
How can I take the same agility and efficiency of the cloud and apply that to my accreditation process
Most organizations follow some type of existing industry or government standard compliance framework. These are just a few common frameworks I’m sure most of us have encountered…
Brief recap of shared responsibility model. AWS is responsible for the core infrastructure provided on which our services are built, while the customer is responsible for using the services and features provided by AWS in order to properly meet their security and compliance needs.
In architecting for compliance in AWS, we want to primarily ensure 2 things:
We know what compliance controls are being met by the AWS global infrastructure (commonly inherited)
We understand what controls are considered a customer responsibility, and know how to best implement them in our architecture
The challenge many organizations encounter with compliance is how to translate compliance requirements into a technical implementation. In other words, how to configure their systems and design the technical controls of security in a way that properly meets the frameworks the organization must adhere. This can be a time consuming and error prone process if not done correctly.
The cloud offers many options through services and features to better implement security, but within that context we must ensure we are using the correct tools in our toolbox in the correct way to be able to ensure our compliance, whether NIST or PCI or any other requirement, is being met.
Meeting compliance requirements
The challenge many organizations encounter with compliance is how to translate compliance requirements into a technical implementation.
What does it mean to technically implement the controls in NIST 800-53 or in PCI or any other compliance framework?
Taking advantage of new services
Now have more than 50 services and we are continuously adding more, how can we use new services to take care of some of the heavy lifting in security and compliance?
How do we use all the tools in our toolbox the best possible way in terms of our compliance frameworks
Making critical decisions for security
May often look at compliance as something we just have to follow, but it plays a valuable purpose in security
NIST is intended to provide standards to protect federal government information
PCI is intended to protect payment cardholder data
HIPAA is meant to ensure protection of personal health information
Mapping to numerous services
We can always say we are compliance, but if we want to be authorized by our security organization to operate an application, we typically have to document that (in the form of security controls matrix, system security plan, or other means)
To effectively implement compliance controls IN the cloud (in terms of the shared responsibility model) we need to know from a technical perspective how to implement them.
Some common examples of how typical compliance requirements are implemented are listed here
While many methods of implementation can often cover requirements across multiple frameworks, as you can see there are differences that must be considered when working with a specific framework.
Why automate compliance in AWS?
Why automate? Why automate anything?
We’ve heard of automation in terms of software deployment and configuration….but what does it mean to automate compliance in AWS?
*we manage compliance as CODE
- We manage and control our compliance implementation much like software. Version control, testing, QA, applying corrective action (fixes).
Optionally we take it to the level of Test Driven Development: concept in which you can first design tests based on requirements before even writing your application (same concept can apply when automating compliance)
*provide STANDARDIZATION
Can write something once which can be reused across many deployments many times
Have consistent and reusability in our architecture
*deliver COMPLIANCE AT SCALE
Through standardization and infrastructure as code, we can apply and enforce policies across many workloads
Shared services for security such as vulnerability scanning and intrusion detection can be scaled to support many workloads across our organization
Scalability of the cloud also allows us to aggregate and analyze vast amounts of data and logs
*in automating compliance we have greater TRANSPARENCY
Remember everything is an API call in terms of monitoring our configuration in AWS
Continuously monitor both applications and the infrastructure in parallel
Demo placeholder
My definition of unit testing here….not sure how that fits in with common terminology but wanted to differentiate between just testing code and testing a fully deployed infrastructure
My definition of unit testing here….not sure how that fits in with common terminology but wanted to differentiate between just testing code and testing a fully deployed infrastructure
Putting this entire workflow together in terms of a DevOps approach, we can have a complete CI/CD pipeline where we start with pre-defined architectures built for compliance, we validate them using automation and continuous integration tools, and finally deliver them for workload owners who can then use these as service catalog products to launch their applications into.