FSV306_Getting to Yes—Minimal Viable Cloud with Maximum Security

© 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
AWS re:Invent
G etti ng to Yes —Mi ni mal Vi abl e Cl oud wi th
Maxi mum Securi ty
I l y a E p s h t e y n , A W S S o l u t i o n s A r c h i t e c t
M a y a n k J a i n , V a n g u a r d A r c h i t e c t M a n a g e r
F S V 3 0 6
N o v e m b e r 2 7 , 2 0 1 7

What to expect from this session
Getting to yes: common challenges
Vanguard’s journey to running critical workloads in the cloud
Best practices and lessons learned
Leveraging the AWS Cloud Adoption Framework (CAF) security perspective to move
fast and stay secure
Maturing security controls through DevSecOps principles

Getting to yes
We’re Going
to Public
Cloud
Running
Critical
Workloads
in the Cloud

Some common challenges
What security framework are we going to use?
Will our existing controls work in the cloud?
How do we measure success of governance and risk directives?
We have so many applications, each with its own security and compliance requirements
Varying levels of cloud knowledge—not everyone is speaking the same language
Too much tools-focused discussion instead of focusing on controls objectives
Where do we begin?

Vanguard’s journey to yes

Vanguard is one of the world's largest investment
companies, offering a large selection of low-cost
mutual funds, ETFs, advice, and related services
Core purpose—to take a stand for all investors, to
treat them fairly, and to give them the best chance for
investment success
Oldest fund—Wellington Fund (inception 1929)
Began operations—May 1, 1975, in Valley Forge, PA
Funds—over 180 US funds (including variable annuity
portfolios) and 190 additional funds in markets
outside the United States
Vanguard—Background

Our cloud journey—timeline
We’re Going
Public Cloud
Educate/
Experiment
Minimal Viable
Cloud (MVC)
Build/Test
MVC1
Production MVC2 Production
Additional MVCs and
Production Deployments
Dec 2015 Feb 2016 Apr 2016 Oct 2016 Dec 2016 Ongoing

Our team structure
Steering
Committee
CTO, Security,
Operations
Application
Workloads
IT & Security
Security, Legal,
Compliance,
Enterprise Risk

Regulatory controls
Name Description
SOC1 Service Organization Controls Report 1 is a report on internal control over financial reporting
SOC2 Service Organization Controls Report 2 is a report which shows how the system is protected against both
physical and logical unauthorized access
GS007 A report focused on International technology controls to support Australia
International Privacy Privacy Laws and Regulations of the countries we do business in
Domestic Privacy Privacy Laws and Regulations for US to support IIG, RIG, FAS and HR
FFIEC The Federal Financial Institutions Examination Council (FFIEC) is a formal US government interagency
body composed of banking regulators
MIFID II The Markets in Financial Instruments Directive 2004/39/EC (known as "MiFID")
MAS The Monetary Authority of Singapore (Abbreviation: MAS) is Singapore's central bank and financial
regulatory authority
NYDFS Is a new set of regulations from the NY Department of Financial Services (NYDFS)

The primary objective of this risk assessment is to help the business identify the right controls and to evaluate the design
effectiveness of management's controls to ensure an effective control environment exists to help protect Vanguard
resources.
Key assessment steps:
Design Build Monitor
 Review process flow
 Identify risks, controls, and monitors
 Determine control design adequacy and significant residual risks
 Document assessment results
 Identify gaps and action plans
 Communicate the assessment results
Identify
Key Risks
Identify
Controls
Assess and
Document
Control Design
Identify
Remediate
Gaps
Develop Control
Monitoring
Plan
Risk-based controls assessment

IT RC Cloud
Assessment
Ballast Point
Controls Library
(GS007, SOC1,
SOC2 )
CCRA MVC1
Controls
AWS
Compensating
Controls
Key controls
ITRC Cloud Assessment Report:
 Single master (Gold) copy Controls (for MVC 1,2)
 Control gaps (weak or missing controls)
 Remediation plan(s) to address control gaps
Controls library:
 GS007, SOC1, SOC2, etc.
Cloud key controls:
 Cloud Cyber Security Reference
Architecture (CCRA based on MVC1)
 AWS Compensating Controls
Internal
Controls
Ballast Point
Controls
Library
(GS007, SOC1,
SOC2 )
AWS
Compensating
Controls
Arriving at Vanguard cloud controls

CCRA volumes

Cloud control framework
Started with existing on-premise controls
Categorized controls into common services and workloads
Updated existing control procedures to align with cloud capabilities
Added/removed controls as needed based on CCRA
Assigned ownership of controls based on modification/add/remove
Baselined MVC1 controls and used them in cumulative manner on subsequent workloads
Validated controls in design and implementation phases

The Cloud Business Office (CBO) will leverage a repeatable framework involving app teams to deliver a consistent cloud on-boarding ramp
and minimize risks during and post cloud migration.
Process
Cloud Readiness
Due Diligence
Engagement kickoff
Gate 1 Gate 2 Gate 3 Gate 4
Technical
Readiness
Financial
Viability
Security, Risk, &
Controls Review
App Ecosystem
Readiness
For new workloads,
teams complete and
gather key artifacts
Engagement Manager
review and provide
guidance
Review by central
Cloud team
Finance team
creates ROI
Security, risk, and
compliance review
Operational &
Organizational
readiness
Final
Evaluation
and
Decisioning by
SI Sub-
Division Leads
Engagement
Managers
Portfolio Architects/
SI Team
Gate 1—Technical Readiness
Gate 2—Financial Viability
Gate 3—Security Risk & Controls Review
Gate 4—App Ecosystem Readiness
New app onboarding governance framework

AWS Professional Services validated security capabilities in addition to Vanguard Risk & Control
DevSecOps enables addition of preventive controls to responsive, detective, and directive controls
Commit
(Code Repo)
Infrastructure and
Applications
 Static code
analysis
Build
(Pipeline)
Infrastructure
 Static code
analysis
Applications
 Static code
analysis
 Dynamic testing
 Automated test
cases
Deploy
(Engineering/Test)
Infrastructure
 Dynamic analysis
 Continuous
monitoring
Applications
 Interactive
application
security testing
(IAST)
Production
Infrastructure and
Applications
 Continuous
monitoring
Maturing our controls

Lessons learned
Cloud skills set across the different teams was diverse
Invest in training and AWS expertise at all levels
Design of the controls was iterated with implementation
Plan for co-location of different teams to break down barriers,
especially in the design phases
Ongoing compliance of AWS services. Keep tabs on AWS compliance page
Work with AWS for a roadmap for compliance
Uncertainty of new regulations
Actively maintain the control mapping as regulations and risk profile change

Patterns for success

Patterns for success
We’re
Going
Public
Cloud
Educate/
Experiment
Establish
Cloud
Team/
Select
Partner
Minimal
Viable
Cloud (MVC)
Build/Test
Security
Controls and
Assessment
(Ongoing)
MVC
Production
Additional MVCs
and Production
Deployments
Running
Critical
Workloads in
the Cloud

No science experiments! Do not fear backlogs! Baseline security
MVC: The ingredients
Landing Zone
H

MVC: Prove capabilities in six areas
A W S C l o u d A d o p t i o n F r a m e w o r k

AWS CAF security perspective

Directive component
Account governance
Account ownership
Control framework
Control ownership
Data classification
Change and asset management
Data locality
Least privilege access
Security operations run books

Start with user stories
User Story AWS Specific Backlog Story Acceptance Criteria
As a Product Owner, I would like to apply
patches as early as possible, to reduce the
window of opportunity of an attack
As a Product Owner, I would like patches
applied in Staging Account/VPC, tested,
rescanned, and then deployed into production
With AMI Bakery process in place, I am able
to follow a Blue/Green pattern to immediately
address patching and remediation
As a Security Engineer, I would like to enforce
the use of only approved OS versions and
patch levels
As a Security Engineer, I would like to enforce
that all instances are built from pre-approved
Golden AMIs
With IAM polices, I am able to limit use to
approved AMIs
As a Security Engineer, I would like to verify
the OS patch level on the identified host so I
know there has not been a drift from approved
AMIs and patch baselines
As a Security Engineer, I would like to
determine whether the host OS is built from
pre-approved AMIs
With EC2 Systems Manager, I can ensure that
there has not been a drift from the pre-
approved AMI and baseline patch levels
As an Incident Responder, I need to be able to
cut off network traffic to/from a server during a
security incident
As an Incident Responder, I need the ability to
block ingress and egress traffic to an instance
during a security incident
With Incident Response and Forensics
runbook, I can easily cut off traffic to a
compromised instance

Preventive component
Identity and access
Infrastructure protection
Data protection

Preventive controls: Identity and access
Resource-based policies
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": [
"arn:aws:ec2:region::image/ami-9e1670f7",
"arn:aws:ec2:region::image/ami-45cf5c3c"]
}
]
}
Tag-based policies
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:region::image/ami-*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/Flag": "Golden"
}
}
}

Detective component
Logging and monitoring
Security testing
Asset inventory
Change detection

Detective controls: Logging and monitoring
Amazon
EC2
CloudWatch
Event
AWS
Lambda
Target
DynamoDB
(Pre-approved AMI IDs)
Approved AMI

Detective controls: Change detection
• Control configuration details such as
anti-virus settings, iptables, etc.
• Compare actual deployments
against specified configuration
policy
• Automatically re-apply policies if
state drift is detected
o OS changes
o Local users and permissions
EC2 Systems Manager
State Manager
EC2 Instances

Responsive component
Incident response
Security incident response
Simulations
Forensics

Auto Scaling group
security group
root volume
data volume Amazon EBS
snapshots
EC2 instance
web app
server
Elastic Load
Balancing
security group
EC2 instance
web app
server
EC2 instance
web app
server
Internet
Gateway
Anomaly
forensic group
forensic
instance
Amazon S3
create copy volumes
Responsive controls: Forensics on AWS

Maturing controls though DevSecOps

Automated and autonomous security
Implement controls as part of the CI/CD process
Achieve the desired control objective by implementing the control at the
optimal CI/CD phase
Commit
(Code Repo)
Build
(Pipeline)
Deploy
(Engineering/Test)
Production
Preventive
Only proceed to build
phase if pre-approved
AMI was used in code
Preventive
Detective
Verify the host OS is
built from pre-
approved AMI
Preventive
Detective
Test compliance of
instance against well-
known standards/
benchmarks
Detective
Responsive
Automatically re-
apply policies if state
drift is detected
Maturing controls through DevSecOps

Implementing security as code
Create Stack
CloudFormation
AWS
CodePipeline
DevOps
Code Push
Code Pull
Static code analysis
(check AMI in the code)
Dynamic
security check
(Check instance AMI)
Create ChangeSet
CloudFormation Approve
ChangeSet
Delete
Stack
CloudFormation
Execute ChangeSet
CloudFormation
AWS
CodeCommit
Commit Build Deploy

Confidence that our code is validated against security policies
Assures unified security configurations across all environments
Increases agility of your security team
Automated audit and alert
Security at scale
DevSecOps benefits
Security
OperationsDevelopment

In summary
Key patterns to success: experiment, build a cloud team, engage with partners,
iterate through MVCs
Apply an agile process to developing cloud security controls
Leverage AWS CAF security perspective for directive, preventive, detective, and
responsive controls
Mature your controls over time through DevSecOps

Thank you!

FSV306_Getting to Yes—Minimal Viable Cloud with Maximum Security

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to FSV306_Getting to Yes—Minimal Viable Cloud with Maximum Security

Similar to FSV306_Getting to Yes—Minimal Viable Cloud with Maximum Security (20)

More from Amazon Web Services

More from Amazon Web Services (20)

FSV306_Getting to Yes—Minimal Viable Cloud with Maximum Security