AWS SecOps: Using AWS Services to Protect, Adapt and Respond

© 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
AWS re:Invent
SecOps 2021 Today: Using AWS
Services to Deliver SecOps
A l e x M a e s t r e t t i – N e t f l i x - E n g i n e e r i n g M a n a g e r - S e c u r i t y
I n t e l l i g e n c e a n d R e s p o n s e T e a m
A r m a n d o L e i t e – A W S – S n r M a n a g e r – R a p i d P r o t o t y p i n g & S o l u t i o n
B u i l d e r G l o b a l s T e a m
S I D 3 0 4
N o v e m b e r 2 9 , 2 0 1 7

2021?

1. Protect
2. Adapt
3. Respond

A first use case
EC2:RunInstances
security group
security group
EC2 instance
Web
server
security group
EC2 instance
App
server
1. Use of approved
AMIs with the
right placement

RunInstances
(AMI-xxxx, VPC + Subnet…)
Amazon
EC2
{ "source": [ "aws.ec2" ],
"detail": { "state": [
"pending" ] } }
- What
- Where
- Is it ok?
{
"detail-type":
[ "activeResponse" ],
"detail":
{
"actionsRequested":["instanceTermination" ]
}
}
Terminate
Evaluate
No

Our message router
Route events:
Platform native filters/events
Custom custom filters
Our message handlers
Context was hardcoded… 

Signal
Noise
Gather Remediate
Collate
Correct
Alert
Enrich
Stop
Measure
Spectrum of options
Context:
1. Static (ex: add metadata)
2. Situational

Static context: Account Metadata
R e q u e s t

Static context: Account Metadata
R e t r i e v e

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 define
action to take based on
asset and environment
If dictated by rules engine,
event results in notification
via email (ex: critical
events)
Alerts preserved in
DynamoDB for reporting and
indexing of raw data
All processing in Security
Account (ex: no external
dependencies to add new
logic, log processing...)

Use Case: Adaptive security controls
1. Situational awareness
2. Adjust security posture
3. Stealth
Auto Scaling group
security group
EC2 instance
Web
server
Auto Scaling group
SSH

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)

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

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

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
Syslog data
CloudWatch

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
Syslog data
CloudWatch
Block all

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

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

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 (ex:
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’

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 
All code at:
https://github.com/awslabs/automating-
governance-sample

1. Protect
2. Adapt
3.Respond

Detection Analysis Containment Eradication Recovery
Alex Maestretti - Engineering Manager, Netflix SIRT
Netflix - Security Intelligence and Response Team

To enable forensic capture and response, it
is helpful to have dedicated roles and
accounts established ahead of time
● A dedicated forensics account
● An ‘IR_S3’ role in the forensics
account that allows read to a trusted/
prefix and write to an evidence/
prefix of buckets in the forensics
account
● A managed policy on all accounts that
allows instance profiles to assume
into the IR_S3 role
● A role in all accounts that can be
assumed into from the forensics
account and allows snapshots
Roles and Accounts

The best way to acquire forensic data is
NOT to touch the target instance. In AWS
we rely on APIs to achieve this:
● A snapshot Lambda in the forensic
account
● Assumes into the target account
IR_role
● Snapshots each of the target’s root
volumes
● Shares the snapshots with the
forensics account
● Assumes back into the forensics
account role
● Creates volumes from the snapshots
in the forensics account
Stealthy Acquisition

At this stage we have snapshots saved to
our forensics account
1. Turn snapshots into volumes
2. Spin up collection instances from an
AMI
3. Attach volumes to the collection
instances
4. Instances detect new volumes and
process them
5. We run a hashdeep recursion and
compare to known good file hashes,
copying interesting new files
6. We copy artifact files based on
Forensic Artifact YAML
Processing—Snapshots

If we are not worried about stealth, we can
get more information more quickly
through live response. For this we leverage
Simple Server Manager (SSM):
1. Task target instances via SSM
2. Target assumes into IR_S3 role
3. Pulls safe binaries and tasking from
the trusted/ bucket
4. Executes
5. Writes results to Amazon S3—files,
command output, etc.
Fast Acquisition

Whether via live response or through the
snapshot process, we now have forensic artifacts
stored in Amazon S3. The processing stage
makes use of Amazon Simple Queue Service
(Amazon SQS) queues which trigger on new
keys/files in the evidence/ bucket.
1. New files are en-queued
2. The ‘dispatch’ Lambda function takes a file
key from the queue and looks up metadata
3. Metadata defines a parser
4. Dispatch looks to see if it has a matching
Lambda function, and if so, sends the key
to that Lambda
5. Parser Lambdas write results to Amazon
Elasticsearch Service (Amazon ES) and/or
back to Amazon S3
Processing—Artifacts in Amazon S3

Thank you!
Jam Lounge
Wed and Thu from 8 a.m.
Drop by at any time
Alex Maetretti@Netflix
Armando Leite@AWS
Come Jam with us! 

AWS SecOps: Using AWS Services to Protect, Adapt and Respond

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a AWS SecOps: Using AWS Services to Protect, Adapt and Respond

Semelhante a AWS SecOps: Using AWS Services to Protect, Adapt and Respond (20)

Mais de Amazon Web Services

Mais de Amazon Web Services (20)

AWS SecOps: Using AWS Services to Protect, Adapt and Respond