AWS Security Automation for IR Workflows

© 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved.
AWS Security in Your Sleep: Build End-to-End
Automation for IR Workflows
Don “Beetle” Bailey
Senior Principal Security Engineer
AWS Security
S E C 3 2 7
Brian Wagner
FSI Compliance Specialist
AWS Financial Services

Today’s Discussion
• Sleep for security geeks via incident response (IR) workflow automation
• Amazon Web Services (AWS) capabilities that can make that happen
• IR workflow automation examples, idea to code to execution
• References and resources to further assist you in getting some Zs
• And, of course: demos!

AWS CloudTrail OFF IR Runbook
1. Turn CloudTrail back ON
2. Gather event data related to CloudTrail being turned OFF
3. Extract principal, date, time, source IP, etc. from event data
4. Map principal to human
5. Look up human contact info
6. Contact human, provide guidance, and offer support
7. Generate event summary for report
NOTE: We do not need to wake up to do any of the above.

CloudTrail OFF IR Runbook
1. Turn CloudTrail back ON
cloudtrail.start_logging(Name=trail_name)

2. Gather event data related to CloudTrail being turned OFF
{
"account": "483366358098",
"region": "us-west-2",
"detail": {
"eventVersion": "1.06",
"eventID": "85ce2937-6984-4484-8629-13d15ed03071",
"eventTime": "2018-11-20T23:47:08Z",
"requestParameters": {
"name": "sec327-demo-1-rCloudTrailTrail-12XXNQSQJAHC"
},
"eventType": "AwsApiCall",
"responseElements": "",
"awsRegion": "us-west-2",
"eventName": "StopLogging",
"readOnly": "false",
"userIdentity": {
"principalId": "AROAIRT6OZJ4JDSDZ3NTA:botocore-session-1542757567",
"accessKeyId": ”XXXXXXXXXXXXXXXXXXX",
"sessionContext": {
"sessionIssuer": {
...
{
"detail-type": [
"AWS API Call via CloudTrail"
],
"detail": {
"eventSource": [
"cloudtrail.amazonaws.com"
],
"eventName": [
"StopLogging"
]
}
}

3. Extract principal, date, time, source IP, etc. from event data
{ $.eventName = "StopLogging" }

4. Map principal to human
{ $.eventName = "AssumeRole" && $.requestParameters.roleArn = "arn:aws:iam::483366358098:role/NonProdAdmin" }

5. Look up human contact info
(&(objectCategory=person)(objectClass=user)
(cn=Brian*))

6. Contact human, provide guidance, and offer support

7. Generate event summary for report

CloudTrail OFF IR Workflow Automation

Incident Response (IR) at A Glance
Establish
control
Determine
impact
Recover as
needed
Investigate
root cause
Improve

Security Geeks Require “Sleep”
• Where “sleep” = “time not actively engaged in fire-fighting”
• This “downtime” is necessary, for a variety of reasons:
• Non-emergent security engineering stuff
• Inventing and building new security solutions
• Learning
• Educating
• NON-security stuff, too

Why Can’t Security Geeks Sleep?
• The pager keeps going off. Why?
• Mitigation requires a human.
• Investigation requires a human.
• Analysis to correlate event to human activity requires a human.
• Contacting a human requires a human.
• Writing a report for a human requires a human.
• However, a human probably isn’t really required all of the time.

Put AWS to Work for You And Get Some Sleep!
• Inventory your IR activity, find candidates for automation.
• Ask tough questions like:
• Where are the hard boundaries where we can act quickly?
• Do we appropriately assess / assign risk to all events?
• What value does a human bring to this particular workflow?
• Can I nuke root cause instead?
• Security agility, MTTR, etc. requirements vs increasing scale and
velocity mean you will end up investing in security automation, so
giddyup.

This All Sounds Strangely Familiar
• Indeed. This talk is new, but the security automation topic isn’t
• YouTube search for our previous related talks, including:
• “automating security event response aws” 2016
• “force-multiply security team with alexa aws” 2017
• Learn more about event detection, logging, automation triggers,
rollback, you name it
• Check for prerequisites to automating IR workflows
• We will hit the highlights next + some new stuff

Empowering AWS Capabilities
• Many AWS bits empower security geeks to accomplish awesome
• Some are obvious, like Amazon GuardDuty or Amazon Inspector or
Amazon Macie
• Some are not as obvious, but just as groovy, including:
• CloudTrail
• CloudWatch
• AWS Config
• Amazon Virtual Private Cloud (Amazon VPC) Flow Logs
• Lambda

AWS Step Functions

IR Lifecycle in AWS Step Functions
Define in JSON Visualize in the Console Monitor Executions

Eat Your Vegetables!
Audit / IR role
App or Env-specific
CloudWatch logs
Centralized logging/
Alerting
Amazon S3 bucket logging (or S3
object-level events > CloudTrail)
Resource backup/
versioning
Runbooks
Pre-built IR environments
Practice Practice Practice

“There are two ways to get practice in
incident response. You get to choose
one.”
A Couple of Goofy Yet Smart AWS Security Geeks,
re:Invent 2016

AWS-oriented IR at A High Level
Macie GuardDutyCloudTrail CloudWatch
Events
On-Instance
Logs
VPC Flow
Logs
CloudWatch
Logs
CloudWatch
Alarms
Lambda
S3 Access Logs S3 Bucket
State Machine
AWS Config
CloudWatch
Logs
CloudTrail
AWS APIs
Team
collaboration
(Slack etc.)
SIEM

Idea to Code to Execution Redux
• What is my expressed security objective in words?
• Is this configuration or behavior related?
• What data, where, could help inform me?
• Do I have requisite ownership or visibility?
• What are my performance requirements?
• What mechanisms support the above?
• What is my expressed security objective in code?
• Am I done?
• Does a human need to look at this? When?

Automating Until DONE DONE DONE
• Start with ONE workflow. Preferably a SIMPLE one. Binary.
• From the moment of event detection, automate all the things:
• Get back to a known good state
• Get all the logs for the event
• Pluck out the necessary values, who, what, when, from where
• Correlate value to personnel and assets
• Analyze data, assess risk, and assign priority
• Engage owners and escalate
• Report whenever and to whomever appropriate

CloudTrail OFF IR Runbook Rehashed
• Turn CloudTrail back ON
• Gather event data related to CloudTrail being turned OFF
• Extract principal, date, time, source IP, etc. from event data
• Map principal to human
• Look up human contact info
• Contact human, provide guidance, and offer support
• Generate event summary for report

The Robots Aren’t In Command Just Yet
• If you’re just starting, then tag, you’re still it
• Early automation should still be supervised
• Production concerns are probably still page-worthy
• Escalation escape valves in automation are OK
• Create fast feedback loops in report mechanisms
• Your automation will break
• More complex events are your reward for success
• We still have jobs for now

S3:PutBucketPolicy IR Runbook
1. State machine is triggered
2. New S3 bucket policy is evaluated
3. Decision is made
4. Gather the last policy
5. Restore the policy
6. Notify
NOTE: We still do not need to wake up to do any of the above.

S3:PutBucketPolicy High-Level
1. Notify security
2. Evaluate the new policy
3. Decide if it’s okay
**when it isn’t**
4. Gather the last policy
5. Restore the policy
6. Notify user
1
3
4
5
6
2

2
1

def check_policy(policy):
for st in policy['Statement']:
actions = st['Action']
if isinstance(actions, str):
actions = [actions]
if st['Effect'] == 'Allow' and st['Principal'] == '*':
for action in actions:
parts = action.split(':')
service = parts[0]
call = parts[1]
if call.startswith('Get') or call.startswith('Put’):
return {
"acceptable": False,
"reason": "overly permissive statement detected",
"statement": st
}
return { "acceptable": True }
3
4

def lambda_handler(payload, context):
client = boto3.client('config')
response = client.get_resource_config_history(
resourceType='AWS::S3::Bucket',
resourceId=id,
limit=1
)
last_config = response['configurationItems'][0]
policy_obj = json.loads(last_config['supplementaryConfiguration']['BucketPolicy’])
prev_bucket_policy = json.loads(policy_obj['policyText’])
return prev_bucket_policy
"GetPrevBucketPolicy" : {
"Type" : "Task",
"Resource": "arn:aws:lambda:...",
"InputPath": "$.bucket.name",
"ResultPath": "$.bucket.policy.prev",
"OutputPath": "$",
"Next": "RestoreLastPolicy"
}, 5

"RestoreLastPolicy": {
"Type" : "Task",
"Resource" : "arn:aws:lambda:...",
"InputPath": "$.bucket",
"OutputPath": "$",
"Next": "Done"
},
def put_policy(bucket, policy):
client = boto3.client('s3')
response = client.put_bucket_policy(
Bucket=bucket,
Policy=json.dumps(policy)
)
def lambda_handler(bucket, context):
bucket_name = bucket['name']
policy = bucket['policy']['prev']
put_policy(bucket_name, policy)
"RestoreLastPolicy": {
"Type" : "Task",
"Resource" : "arn:aws:lambda:...",
"InputPath": "$.bucket",
"OutputPath": "$",
"Next": "Done"
},
6
"GetPrevBucketPolicy" : {
"Type" : "Task",
"Resource": "arn:aws:lambda:...",
"InputPath": "$.bucket.name",
"ResultPath": "$.bucket.policy.prev",
"OutputPath": "$",
"Next": "RestoreLastPolicy"
},

Amazon Elastic Compute Cloud (Amazon EC2) Login IR Runbook
User Login
1. Get the user
2. Gather relevant data
3. Terminate session
4. Isolate the instance
5. Report the incident
Research
1. Pull instance logs
2. Correlate with other
data sources
3. Report findings
Forensics
1. Take memory dump
2. Create AMI
3. Copy AMI to
forensics account
4. Launch instance
5. Investigate
6. Report findings
…so are we done? …now are we done? …but are we DONE?

{
"detail-type": [
"EC2 forensics needed”
],
"source": [
"ec2.login"
]
}
Know Your Event Sources

Amazon EC2 Login IR Runbook(s)
Start
End
IsEmergencyUser
TermianteSession
IsolateInstance
TagInstance
Notify
Start
End
StartForensicsEC2
ApplySecurityGroup
TakeMemDump
Notify
Start
End
PullInstanceLogs
PullCloudTrailByIp
PullFlowLogByIp
Notify
User Login
Research Forensics
Start
Start

Wrangling

IR-related Partner Solutions

Open Source IR Solutions
• AWS Security Automation
https://github.com/awslabs/aws-security-automation
• Threat Response
https://threatresponse.cloud
https://github.com/ThreatResponse/aws_ir
• Wazuh
https://documentation.wazuh.com/current/amazon/

Open Source IR Solutions, Continued
• Cloud Custodian
https://github.com/capitalone/cloud-custodian
• Fido
https://github.com/Netflix/Fido
• Security Monkey
https://github.com/Netflix/security_monkey
• StreamAlert
https://github.com/airbnb/streamalert

Community / Industry Resources
• FIRST
https://first.org/
• Cloud.gov
https://cloud.gov/docs/ops/security-ir/

Related Breakouts
Tuesday, November 27th
Five New Security Automations Using AWS Security Services & Open Source
11:30 AM – 12:30 PM | Aria West, Level 3, Ironwood 5
Wednesday, November 28th
Using AWS Lambda as A Security Team
1:00 PM – 2:00 PM | Mirage, Grand Ballroom F
Thursday, November 29th
Netflix Cloud Forensics
1:00 PM – 2:00 PM | Mirage, Grand Ballroom F

Takeaways
• Security geeks can be heroes, but shouldn’t have to be all the time
• Automating IR workflows can free resources for non-emergent yet
equally important security engineering tasks
• AWS capabilities empower any customer to create end-to-end
automation for IR workflows
• Start small & simple, iterate, and leverage partner and open-source
resources or Support for success

Thank you!

AWS Security Automation for IR Workflows

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a AWS Security Automation for IR Workflows

Semelhante a AWS Security Automation for IR Workflows (20)

Mais de Amazon Web Services

Mais de Amazon Web Services (20)

AWS Security Automation for IR Workflows