Incident Response: Preparing and Simulating Threat Response

© 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved
Cloud Adoption Framework: Security Perspective
Eric Rose,
Senior AWS Security Consultant
Incident Response: Preparing and Simulating Threat Response

What to expect from this session
• Cornerstones of a robust AWS Incident Response plan
• Tools and techniques for automating incident responses
• Tips for drilling Incident Response scenarios

Indicators of Compromise
• CloudTrail
• Billing
• AWS Service Logs (e.g. S3 Bucket Logs)
• VPC Flow Logs
• Operating System Logs
• Database Logs
• Application Logs

Intrusion Detection within AWS – Common Customer
Questions
“What should we be looking for using AWS CloudTrail?”
• Authorization failures
• Attempts to disable CloudTrail
• Activity in an inactive region
• Console or API activity from an anomalous IP geography.

Example CloudTrail event
"Records": [{
"eventVersion": "1.0",
"userIdentity": {
"type": "IAMUser",
"principalId": "EX_PRINCIPAL_ID",
"arn": "arn:aws:iam::123456789012:user/Alice",
"accountId": "123456789012",
"accessKeyId": "EXAMPLE_KEY_ID",
"userName": "Alice"
},
"eventTime": "2017-03-24T21:11:59Z",
"eventSource": "iam.amazonaws.com",
"eventName": "CreateUser",
"awsRegion": "us-east-1",
"sourceIPAddress": ”55.55.55.55",
"userAgent": "aws-cli/1.3.2 Python/2.7.5 Windows/7",
"requestParameters": {
"userName": "Bob"
},
"responseElements": {
"user": {
"createDate": "Mar 24, 2017 9:11:59 PM",
"userName": "Bob",
"arn": "arn:aws:iam::123456789012:user/Bob",
"path": "/",
"userId": "EXAMPLEUSERID"
}
....

Questions
“What should we look for in our AWS billing?”
• Unexplained billing spikes.
• Unexplained data transfer charges.
• Billing in previously unused AWS Regions.
• Billing for previously unused AWS services.
• Enable Billing Alerts using CloudWatch to help detect
anomalous usage patterns.

Questions
“What logs should I be collecting?”
• All of the logs….

Questions
“Am I missing anything?”
• Use Trusted Advisor to get an overall picture of your security within
AWS.
• Use AWS Inspector to scan your EC2 instances for specific
vulnerabilities and overall security posture.
• CloudWatch Events can alert on specific API calls, use in combination
with Lambda to automate detective and responsive security controls.
– Example: Use CloudWatch Events and AWS Lambda to alert and
prevent CloudTrail from being turned off.

Incident Response in AWS

What are the goals for Incident Response?
• Establish Control
• Determine impact
• Recover as needed
• Investigate the root cause
• Improve
Lets take a look at an example….

Incident Response Example - Your access
key went to exciting destinations
Its Here
And Here
And Here
And Here

The Situation…
We have detected that an access key and secret key was used
to make a “DescribeInstances” API call from an unknown IP
range, location, or after hours…

Typical Response - Remove the key from the Internet!
• Take down the page it was posted on
• DMCA Notice
• Remove it from search engine caches
This approach does not work. Let’s focus on our IR goals…

Incident Response Example– Establish Control
• The blast radius will be limited by following IAM best
practices, operating a “Well-Architected” workload, and
having followed the intrusion detection prerequisites.
• In this example, the attacker has only limited access to a
single access key and secret key (since we followed our
best practices). What are our first steps?
– Revoke access rather than deleting the key; or
– Apply a “No Access” IAM policy to the user

Incident Response Example – Determine Impact
If we believe we have established control, further investigation is needed to
determine the impact of the event. What are our next steps?
• Investigate the API calls made by that key based on CloudTrail Logs.
• Did they create new users? Policies? Roles? If so, return back to the
Establish Control step.
• Use the script from Sec402 to help figure out which user the Access
Key belongs to https://s3.amazonaws.com/reinvent2014-
sec402/SecConfig.py

Incident Response Example – Recover as Needed
Once we have established control and determined the scope
of the impact, we can start to recover as needed. In this case,
it would include the following:
• Provision new credentials for authorized usage;
• Deploy credentials to the impacted system or user; and
• Validate proper operation using new credentials.

Incident Response Example – Investigate the Root Cause
• Ask Why (at least 5 times) to help get you to the root cause.
• Use the logs that you have been collecting in your S3 bucket to aid
the investigation. Those logs should include, but are not limited to:
– CloudTrail Logs
– ELB Logs
– VPC Flow Logs
– Systems Logs
– Console Logs
– Application Logs

Incident Response Example – Improve
• Apply knowledge from investigating the root cause to
improve:
– Internal Communication between your teams.
– Communication to AWS, if needed.
– Update your IR runbooks/playbooks to include any
additional information learned from the experience.

Incident Response – Fun Facts
• Your ability to detect, respond, and recover in the cloud can
be enhanced by using the cloud.
• Automation is key. Attacks happen in microseconds and
your responsive capabilities need to be just as fast.
• It is better to create (and test!) BEFORE you need it.
• Gameday simulations will provide valuable confidence and
lessons learned to improve your Incident Response
process.

Intrusion Detection and Incident Response – AWS services to
help protect the Cloud
• CloudTrail – Web service that records AWS API calls for your account
and delivers log files to you.
• CloudWatch – Monitoring service for AWS cloud resources.
• CloudWatch Events – Near real-time stream of system events that
describe changes in AWS resources.
• Lambda – Runs code without provisioning or managing servers.
• Inspector – Automated security assessment service.
• Trusted Advisor – Resource to help you reduce cost, increase
performance, and improve security by optimizing your AWS
environment.

CloudTrail events
• A record in JSON format that contains information about requests for
resources in your account.
• Describes which service was accessed, what action was performed, and
any parameters for the action.
• Helps you determine who made the request.
• The event data is enclosed in a Records array.
• http://docs.aws.amazon.com/awscloudtrail/latest/userguide/send-cloudtrail-
events-to-cloudwatch-logs.html

Building a “Lambda Responder”
CloudTrail S3 SNS

Demo

Simulating Incidents

When should I contact AWS Security?
If you are planning Security Incident Response Simulation
(SIRS):
• Obtain permission to perform penetration testing/scanning.
• Confirm the SIRS does not violate the Acceptable Use Policy.
https://aws.amazon.com/aup/

Engage support

Customer AWS Support – Escalations
In situations where an escalation is required, customers can
follow a pre-defined escalation path:
• Contact their Technical Account Manager
• Submit a Support Case
– AWS Support has it’s own internal escalation path which
includes a path to AWS Security, if needed.

Engaging human support
Cloud support engineer (CSE)
Technical account manager (TAM)
Subject matter experts (SME)
You
Relationship POC
Available with enterprise support
Available with support

Go here…
https://aws.amazon.com/contact-us/

Incident Response: Preparing and Simulating Threat Response

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (15)

Semelhante a Incident Response: Preparing and Simulating Threat Response

Semelhante a Incident Response: Preparing and Simulating Threat Response (20)

Mais de Amazon Web Services

Mais de Amazon Web Services (20)

Incident Response: Preparing and Simulating Threat Response