Slide 1

Slide 1 text

A presentation by Akash Mahajan CoFounder Appsecco #c0c0n, #cloudnative, #cloudsecurity, #secops, #devsecops, #SOAR SecOps for the Cloud using Cloud Native

Slide 2

Slide 2 text

SecOps for the Cloud using Cloud Native

Slide 3

Slide 3 text

Akash Mahajan – About Me • Co-Founder of Appsecco (appsecco.com) • Co-Founder of null0x00 - Open Security Community • Author of Security Books • Burp Suite Essentials • Security Automation using Ansible2 • Security Trainer c0c0n, nullcon, BlackHat US

Slide 4

Slide 4 text

1. Demo – Automated Response against public S3 buckets 2. Define SecOps for our use case 3. Case Study – Automated Response to stolen AWS keys 4. Elaborate on what is Cloud Native 5. List advantages of embracing cloud native for SecOps Agenda

Slide 5

Slide 5 text

1. Understand a way to think about security operations 2. Take away answers to 1. What can be part of SecOps 2. What you can do about it now 3. Looking at only AWS services for reasons of time and popularity What this talk and demo is about

Slide 6

Slide 6 text

What this talk and demo is not 1. Thinking that tools and products are security silver bullets 2. Thinking that the approach and tooling mentioned here, is the only way possible 3. Therefore if you are familiar with all of this, please contribute to the discussion and share your insights ☺

Slide 7

Slide 7 text

Breaches due to public S3 buckets

Slide 8

Slide 8 text

• We will enumerate S3 buckets which are public in an AWS account • We will remediate this security misconfiguration using automation • Once remediation is complete, we will verify and see if there are still any public S3 buckets remaining Demo – Finding public S3 buckets and securing them

Slide 9

Slide 9 text

Automating runtime security in your infrastructure in a way that aligns Security and Operations tasks to reduce risk, stabilize infrastructure, and improve operational efficiency According to ThreatStack SecOps is

Slide 10

Slide 10 text

Attribute In the Demo Runtime Security The detection and response was on AWS S3 buckets that were operational Operations Usually the AWS S3 buckets provisioned by DevOps Security Security team understands the severity of risk associated with public AWS S3 buckets Did we do SecOps then?

Slide 11

Slide 11 text

Objective Remarks Reduce Risk Removing public buckets is a win. Reduces risk. Stabilize Infrastructure ?? Operational Efficiency 1. Automation enables efficiency 2. Non-public buckets won’t get hacked by external attackers by default Did we achieve our objectives?

Slide 12

Slide 12 text

• An application is vulnerable to Server-Side Request Forgery (SSRF) • Using this vulnerability an attacker can read arbitrary files etc. including instance meta data • The application requires read access to S3 buckets • An IAM Instance Role is attached to allow this by the Operations team Case Study – AWS Key theft due to vulnerable app

Slide 13

Slide 13 text

• Attacker is able to get the following three credentials by exploiting the SSRF 1. AWS AccessKey 2. AWS Secret Access Key 3. AWS STS Token • Once the attacker has these pieces of information, it is trivial to make API calls Case Study – AWS Key theft due to vulnerable app

Slide 14

Slide 14 text

• AWS logs API requests to bunch of their services and lets us use them using CloudTrail • By periodically monitoring for any rejections for this log group, we can be alerted if someone has tried to misuse • Misuse can be anything which is not related to S3, like • aws iam list-users Case Study – Serverless, automated response

Slide 15

Slide 15 text

1 1 Vulnerable application 2 2 IAM role with S3 access 3 3 Attacker exploits SSRF 4 4 Gains access to AWS Keys 5 5 Tries to elevate access 6 6 Lambda is monitoring for such activity 7 7 IAM role is detached as security response

Slide 16

Slide 16 text

• Misuse of AWS IAM keys was auto detected • Due to the detection, automated remedial steps were taken to prevent misuse • The leaked keys can be disabled • The instance role can detached • Till the developers can fix the SSRF issue Case Study – Outcome achieved

Slide 17

Slide 17 text

Security and Operational outcomes were achieved while at runtime. SO DEFINITELY SECOPS Net net – we did good SecOps

Slide 18

Slide 18 text

• Using managed services of cloud providers • And/or Container based usually running micro services Cloud Native refers to environments that are

Slide 19

Slide 19 text

• Based on automation • CI/CD Integrations • Centralised Logging and usually have dashboards • Secrets Management Distinguishing attributes for Cloud Native

Slide 20

Slide 20 text

Attribute In the Demo Container based No. Running inside a python virtual machine on my laptop Secrets Management No, The keys for the AWS account used are stored in my laptop Using managed services Yes, the custodian application relies on IAM, Lambdas etc. to execute CI/CD or Automation No, manually trigged by typing a command Centralised Logs No, logs are getting stored locally Was our S3 demo cloud native?

Slide 21

Slide 21 text

AWS ECS AWS KMS AWS LAMBDA Jenkins CloudWatch Events AWS CloudWatch Possible stack to make this cloud native

Slide 22

Slide 22 text

Attribute In the Demo Container based Yes. Lambda Secrets Management Yes, The keys were short lived and only meant for that workload, so temp tokens Using managed services Yes, using CloudWatch Events, CloudTrail CI/CD or Automation Yes, once deployed the defence works on its own Centralised Logs Yes, logs are getting stored in the cloud Was our case study cloud native?

Slide 23

Slide 23 text

• Focus on solving issues that matter to business first • One less server to manage is great • Infra as code, configuration managed as code • Automation to some extent is inherent • This frees us to solve bigger and different problems • Scale of what needs to be secured is growing exponentially Why become Cloud Native?

Slide 24

Slide 24 text

• Major reskilling and capability building required • Major capacity building required • Compliance, legal challenges around data, privacy etc. • Already existing security costs in software, hardware and training Why not to become cloud native

Slide 25

Slide 25 text

Imagine a day in life of a SecOps pro Arrive at office Generate reports or create bugs in issue tracking Leave office knowing that day was well spent Fire up services with all the tools, confs and secrets Bring down un- needed services

Slide 26

Slide 26 text

All the time in between can be spent on Arrive at office Generate reports or create bugs in issue tracking Leave office knowing that day was well spent Fire up a cluster with all the tools, confs and secrets Destroy the cluster Watch a new talk on how to bring observability to SecOps Try out a new open source logging tool Learn how to write test cases for infra as code Evaluate a new cool tool to integrate in the cluster

Slide 27

Slide 27 text

• DevOps is changing how software is developed and deployed • The only way to keep up is by leveraging Cloud Native Services such as • Serverless (Cloud functions, Lambda) • Container runtimes (Docker) • Container schedulers (Kubernetes) Why would we want to do this?

Slide 28

Slide 28 text

• Bring in near real time detection and blocking of security attacks • Analyse incidents quickly and with automation • Remediate potential security holes before they become a problem Why would we want to do this?

Slide 29

Slide 29 text

SecOps for the Cloud using Cloud Native Not just a thought, but something concrete we can rely on and build together. YAY!!!

Slide 30

Slide 30 text

No content