To help prevent unexpected access to your AWS resources, it is critical to maintain strong identity and access policies. It is equally important to track and alert on changes to your AWS resources. In this tech talk, you will learn how to use AWS Identity and Access Management (IAM) to control access to your AWS resources and integrate your existing authentication system with AWS IAM. We will cover how you can deploy and control your AWS infrastructure using code templates, including change management policies with AWS CloudFormation. In addition, we will explore different options for managing both your AWS access logs and your Amazon Elastic Compute Cloud (EC2) system logs using Amazon CloudWatch Logs. We also will cover how to use these logs to implement an audit and compliance validation process using services such as AWS Config, AWS CloudTrail, and Amazon Inspector.
Learning Objectives:
• Understand the AWS Shared Responsibility Model.
• Understand AWS account and identity management options and configuration.
• Learn the concept of infrastructure as code and change management using AWS CloudFormation.
• Learn how to audit and log your AWS service usage.
• Learn about AWS services to add automatic compliance checks to your AWS infrastructure.
2. A practical approach to help achieve SecOps excellence
+
How to leverage AWS services to implement.
+
Take home toolkit i.e. try it by yourself.
Control Monitor Fix
What to expect from the session
3. In detail
1. Introduction
2. CMF: Control/Monitor/Fix
- Control: Creating the guardrails.
- IAM, Code*, AWS Config
- Monitor: Provide visibility
- Cloudtrail, Flowlogs, Syslog, Cloudwatch
- Fix: Dealing with Exceptions
- Lambda
3. In Practice (aka demo)
4. Your take home kit and actions
MSB – Minimum Security
Baseline
Pro Level – What to aim for.
4. Cloud Adoption Framework
The Security Perspective
Directive
Preventive Detective
Responsive
Control Monitor
?
Fix
Driving the right behavior Maintain and assure over time.
Get back to known good.
7. Phase 1: Control
Goal:
• Drive towards secure outcomes i.e. Build guardrails
Possible options:
• IAM
• Cloudformation
• Code*
Best practice:
• MSB: Individual users + Least privilege + use of groups.
• Pro level: Centralized deployment of controls across N accounts.
8. AWS Identity and Access Management (IAM)
Enables you to control who can do what in your AWS account
Splits into users, groups, roles, and permissions
Control
Centralized
Fine-grained - APIs, resources, and AWS Management Console
Security
Secure (deny) by default
Final decision =“deny”
(explicit deny)
Ye
s
Final decision =“allow”
Ye
s
No
Is there an
Allow?
4
Decision
starts at Deny
1
Evaluate all
applicable
policies
2
Is there an
explicit
deny?
3
No
Final decision =“deny”
(default deny)
5
AWS retrieves all policies associated with
the user and resource.
Only policies that match the action and
conditions are evaluated.
If a policy statement has
a deny, it trumps all other
policy statements.
Access is granted if
there is an explicit
allow and no deny.
• By default, an
implicit (default)
deny is returned.
9. Top 11 IAM best practices
1. Users – Create individual users.
2. Permissions – Grant least privilege.
3. Groups – Manage permissions with groups.
4. Conditions – Restrict privileged access further with conditions.
5. Auditing – Enable AWS CloudTrail to get logs of API calls.
6. Password – Configure a strong password policy.
7. Rotate – Rotate security credentials regularly.
8. MFA – Enable MFA for privileged users.
9. Sharing – Use IAM roles to share access.
10.Roles – Use IAM roles for Amazon EC2 instances.
11.Root – Reduce or remove use of root.
10. One AWS account vs. multiple AWS accounts?
Use a single AWS account when you:
Want simpler control of who does what in your AWS environment.
Have no need to isolate projects/products/teams.
Have no need for breaking up the cost.
Use multiple AWS accounts when you:
Need full isolation between projects/teams/environments.
Want to isolate recovery data and/or auditing data (e.g., writing your
CloudTrail logs to a different account).
Need a single bill, but want to break out the cost and usage.
11. Segmented AWS Account Structure
Procurement and
Finance
SOC/Auditors
Billing account
Production
accounts
User management
account
Security / Audit
account
Application Owners
Security/auditUtilityFinancial
Consolidated Billing,
Billing Alerts
Read-only access
for all accounts
Dev / Test
accounts
Operational
Logging
account
Backup / DR
account
Key management
account
Shared services
account
Domain Specific Admins
Event and State
Logging
Read-only access
to logging data
12. Introducing AWS Organizations
Control AWS service
use across accounts
Policy-based management for multiple AWS accounts.
Consolidate billingAutomate AWS
account creation
13. Typical Use Cases
Control the use of AWS services to help comply with corporate
security and compliance policies.
Automate the creation of AWS accounts for different resources.
• API response to trigger additional automation. (e.g. deploy
CloudFormation template)
14. What is AWS CloudFormation?
• AWS CloudFormation allows you to model,
provision, and update the full breadth of AWS
resources.
• Manage anything from a single Amazon EC2
instance to a multi-tier application.
• Integrates with other development and
management tools.
16. Elements of a Continuous Delivery Pipeline
Commit Phase: Source Control changes
• Static code analysis: Analyze the CFN templates against a set of security rules
Acceptance Phase: Dev Environment
• Dynamic analysis: Run template in sandbox / acceptance test environment.
Capacity/Integration/Staging Phases: Pre-Prod Environment
• Load, performance, Penetration and failover testing.
Production Phase: Prod Environment
• Deploy controls.
19. Phase 2: Monitor
Goals:
- Ensure effective operation over time.
- Detect anomalies/change.
Options:
• Cloudtrail, Cloudwatch*, VPC Flowlogs, Config…
Best Practice:
• MSB: Aggregate log data.
• Pro level: Analyze and act on log data as it arrives.
20. What is AWS CloudTrail?
A fully managed service that records API calls made on your AWS account.
Customers are
making API calls...
On a growing set
of services around
the world…
CloudTrail is continuously
recording API calls…
And delivering
log files to
customers
21. Alert indexer
Triage/Classification
rules
Cloudtrail
Cloudtrail
Cloudtrail
... ...
Security accountAccount 1
Account 2
Account N
Cloudtrail
aggregation
bucket
Automated configuration to enable
logging and aggregation
destination.
Log files deposited in S3 bucket
under Security Account.
SNS notifies lambda of
new events available for
processing.
Each lambda evaluates a
specific compliance item
or misuse case.
Rules engines help defin
action to take based on
asset and environment.
If dictated by rules engine,
event results in notification
via email i.e. critical
events.
Alerts preserved in
Dynamodb for reporting and
indexing of raw data.
All processing in Security
Account i.e. no external
dependencies to add new
logic, log processing, etc.
28. Goal:
• Return to ‘known good’
• ‘Don’t throw the baby out with the bathwater’…
Options:
• Lambda shines but whole AWS platform plays a role.
Best Practices:
• MSB: automate alerting and integrate with ticketing systems.
• Pro Level: Closed loop.
Fix – Correcting anomalies
30. Fix using AWS services
Trusted
Advisor
AWS Config
Managed
Rules
AWS Config
Custom
Rules with
remediation
CloudWatch
Events with
Lambda
rules
Lambda
code with
various
triggers
Ease of getting started vs. customization and control
31. Security Incident Response Simulations
Test and benchmark your security response to security events.
Experts from the Security, Risk and Compliance (SRC) practice can
help you assess your current state of incident response readiness,
then prepare and execute an exercise to practice that response.
Objectives:
• Assess current incident response processes and procedures
• Provide recommendations for using AWS services of incident
response
• Test the cloud incident response process via a simulated exercise
Typical effort: 15 Man Days
33. Demo – event flow
1 – Standard
2 – Enhanced
3 – Active
Auto Scaling group
security group
security group
EC2 instance
Web
server
security group
EC2 instance
App
server
Auto Scaling group
CloudWatch
Syslog
Flowlogs
CloudTrail
In standard operation, we are
observant.
Control:
- Security agent loaded in
instance.
- Logons tracked.
Monitoring:
- We gather data covering API
activity (cloudtrail), network
(Flowlogs) and also in-
instance activity (Syslog).
Fix:
- We are good
Logon ok?
Logon is OK!
SSH
Login!
(CWECustom)
34. Demo – event flow
1 – Standard
2 – Enhanced
3 – Active
Auto Scaling group
security group
security group
EC2 instance
Web
server
security group
EC2 instance
App
server
Auto Scaling group
CloudWatch
Syslog
Flowlogs
CloudTrail
SSH
Login!
(CWECustom)
A logon event occurs. We go to
Enhanced surveillance mode.
Control:
- Dynamically add lambda
subscriptions to log feeds.
Monitor:
- In instance activity (privilege
escalation)
- Initiation of forbidden flows.
Fix:
- Alert only. Watchful but
passive.
Enhance
OS data
analysis
Network data
analysis
Subscribe to Syslog
Enable Instance level flowlogs
Subscribe to instance flowlogs
Flowlogs
Logon ok?
Logon NOT ok.
35. Demo – event flow
Auto Scaling group
security group
EC2 instance
web app
server
Elastic Load
Balancing
security group
EC2 instance
web app
server
security group
EC2 instance
web app
server
security group
App
server
1 – Standard
2 – Enhanced
3 – Active
OS data
analysis
Isolate Preserve Deregister
Syslog data
Root Access
CloudWatch
36. Demo – event flow
Auto Scaling group
security group
EC2 instance
web app
server
Elastic Load
Balancing
security group
EC2 instance
web app
server
security group
EC2 instance
Anomaly
security group
App
server
1 – Standard
2 – Enhanced
3 – Active
OS data
analysis
Isolate Preserve Deregister
Syslog data
CloudWatch
37. Demo – event flow
Auto Scaling group
security group
EC2 instance
web app
server
Elastic Load
Balancing
security group
EC2 instance
web app
server
security group
EC2 instance
Anomaly
security group
App
server
1 – Standard
2 – Enhanced
3 – Active
OS data
analysis
Isolate Preserve Deregister
Syslog data
CloudWatch
Block all
38. Demo – event flow
Auto Scaling group
security group
EC2 instance
web app
server
Elastic Load
Balancing
security group
EC2 instance
web app
server
security group
EC2 instance
Anomaly
security group
App
server
1 – Standard
2 – Enhanced
3 – Active
OS data
analysis
Isolate Deregister Preserve
Syslog data
CloudWatch
Block all Dereg
ASG/ELB
39. Demo – event flow
Auto Scaling group
security group
EC2 instance
web app
server
Elastic Load
Balancing
security group
EC2 instance
web app
server
security group
EC2 instance
Anomaly
security group
App
server
1 – Standard
2 – Enhanced
3 – Active
OS data
analysis
Isolate Deregister Preserve
Syslog data
CloudWatch
Logs
Block all Dereg
ASG/ELB
Amazon EBS
snapshots
40. Demo – event flow
Auto Scaling group
security group
EC2 instance
web app
server
Elastic Load
Balancing
security group
EC2 instance
web app
server
security group
EC2 instance
web app
server
security group
App
server
1 – Standard
2 – Enhanced
3 – Active
security group
EC2 instance
Anomaly
An escalation occurred and we
switched to Active i.e.
intervene and get it fixed.
Control:
- SG to isolate anomalous
instance.
- Preserve instance for both
live and offline analysis.
- Deregister application from
live use.
Monitoring:
- We continue to monitor all
activity as per previous
steps.
Fix:
- The control actions cause
ASG to be 1 instance short and
will recover to original fleet size
from ‘last known good’.
41. Demo – event flow
1 – Standard
2 – Enhanced
3 – Active
Auto Scaling group
security group
security group
EC2 instance
Web
server
security group
EC2 instance
App
server
Auto Scaling group
CloudWatch
Syslog
Flowlogs
CloudTrail
In standard operation, we are
observant.
Control:
- Security agent loaded in
instance.
- Logons tracked to TT.
Monitoring:
- We gather data covering API
activity (cloudtrail), network
(Flowlogs) and also in-
instance activity (Syslog).
Fix:
- We are BACK TO good
42. Summary
Control:
• IAM is the foundation for everything else.
• Service catalogue as an option to standardize product distribution.
• Code*: Embed security throughout (‘Fail early’).
Monitor:
• Cloudtrail, Config, Flowlogs,…:To get visibility, you need to see – enable
logging.
• Data is good. Better if you use it. Great if used to drive automation.
Fix:
• Reduce ‘Detect-Report-Remediate’ cycles.
• Automate to gain speed + free human intellect to more added value tasks.
43. Take home kit – your turn!
#1 Demo code is published
• https://github.com/awslabs/automating-governance-sample
#2 Implementing DevSecOps using AWS Codepipeline
• https://aws.amazon.com/blogs/devops/implementing-devsecops-using-aws-codepipeline
#3 “what should I Control/Monitor/Fix next?”
• https://aws.amazon.com/whitepapers/aws-security-best-practices/
#4 (Optional) Come Jam with us!
44. San Francisco Summit 2017 – April 18 (am) and April 19 (pm)
Washington DC, Public Sector Summit - June 12 (pm)
More to come…
Your company?