This document provides an overview of responding to incidents in AWS environments. It discusses AWS authentication and authorization, control and data planes, the shared responsibility model, and building an incident response flow. It emphasizes having a services inventory, assessing knowledge gaps, implementing guardrails, threat modeling, structuring response actions, and validating preparations through simulation. The goal is to continuously research, improve detections, train teams, and develop resources to respond to issues across AWS services.

2. Resposta a incidentes
em ambientes AWS

3. $ aws --profile Rodrigo Montoro sts get-caller-identity
● Head of Threat & Detection Research at Clavis Security
● Living in Florianópolis (Silicon Island)
● Author of 2 patented technologies (US Patent Office)
● Speaker in different conferences (Brazil,USA,Canada)
● Proud Dad and Husband
● Full Ironman triathlon (2x)
● Crossfit and Powerlifting

4. Motivation

5. Agenda
Introduction to AWS ecosystem
1
Control Plane & Data Plane
The deFAULT truth of AWS shared responsibility model
Building an incident response flow
Conclusions

6. Introduction to
AWS Ecosystem

7. AWS In Numbers
● Around 12k actions
● 973 Managed policies
● 5 actions access level
● Around 300 Services
Fonte: https://aws.permissions.cloud/

8. How authentication and authorization works

9. AWS IAM policy flow analysis

10. Control Plane &
Data Plane

11. Control Plane

12. Data Plane
● S3 buckets data events
● RDS Audit logs
● EKS (Kubernetes)

13. The deFAULT Truth of AWS
shared responsibility model

14. AWS Shared Responsibility Model

15. ● CSPM Detections (cloudsploit)
○ 460 findings (AWS)
○ 87 services covered (~29% of services)
● Services with Passrole
○ 330 actions
○ 92 services (~30.7% of services)
● Detections from Elastic rules
○ 59 detections
○ ~22 services covered (~7.3% of services)
● Detections from Sigma
○ 31 detections
○ ~20 services covered (~6.7% of services)
Some numbers in secure ‘IN’ the cloud (AWS)

16. Small piece (but important) of a full talking on the way …

17. How many problems an AWS account start (with an Admin user) ?

18. Next let’s add an ec2 instance

19. Just to finish a s3 bucket …

20. Simple scenario (only 3 services) the deFAULT “problems”

21. Do not forget!
● Data Events
● Cross Account
● Uncommon services

22. Building an incident
response flow

23. Building a flow
● Services inventory
● Inventory knowledge self assessment
● Guardrails / Security Architecture
● Threat Modeling / Researches
● Structure response actions
● Validate / Simulate

24. Services Inventory

25. Inventory knowledge self assessment
Service Service Context Level (low to
critical)
Knowledge (1 to 5) Existing Detections /
Researches (1 to 5)
iam critical 3 4
ec2 high 4 4
appstream medium 3 2
sagemaker medium 1 1
rds high 2 3
redshift medium 1 1
* researching/developing idea for a threat score
*

26. Guardrails & Security Architecture
● Deny services you don’t need
● Use conditions in your privilege policies
● Be ready to use AWSCompromisedQuarentinev2
● Use different accounts
● Least privilege

27. Threat Modeling / Researches
source: https://securitylabs.datadoghq.com/articles/threatest-end-to-end-testing-threat-detection/
Map the path
from attacker to
my assets and
possible attack
techniques
Research how
attack techniques
mapped works
and data source
events need to
detect
Create detections
based on
requirements. Try
to analyze events
from real world.
Analyze
False Positives
and False
Negatives.
Deploy in “testing
mode” and keep
improving until
production.
Monitor metrics.

28. Structure a response action

29. Validate / Simulate
source: https://www.netspi.com/blog/technical/adversary-simulation/painting-a-threat-detection-landscape/

30. Future &
Conclusions

31. Future and Conclusions
● Don’t trust default configurations
● Good architecture helps monitoring
● Know what you are running
● Find your knowledge gaps
● Keep researching and improving detections
● Make sure you train your team
● Build an Uncommon services Incident Response Cheatsheet

32. Obrigado
Rodrigo Montoro
@spookerlabs
rodrigo.montoro@clavis.com.br