Doing SecOps for the Cloud using CloudNative

SecOps or Security Operations is changing enterprise IT the same way how DevOps
transformed enterprise Dev. The complexity of operations is ever increasing and with the advent and extensive usage of Public Cloud the risk is ever greater.

We need to gear up for this world and a workable approach is to tackle this new world with the same enthusiasm as developers have taken up.

By leveraging Cloud Native Services such as Serverless (Cloud functions, Lambda), Container run-times (Docker) and Container schedulers (Kubernetes) we can bring in near real time detection and blocking of security attacks, analyse incidents and even do remediation of potential security holes before they become a problem.

During this talk and demo we will cover two live demonstrations of this approach and use the demonstrations to expand on the following

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

Transcript

1. A presentation by Akash Mahajan CoFounder Appsecco #c0c0n, #cloudnative, #cloudsecurity, #secops, #devsecops, #SOAR SecOps for the Cloud using Cloud Native
2. SecOps for the Cloud using Cloud Native
3. 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
4. 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
5. 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
6. 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 ☺
7. Breaches due to public S3 buckets
8. • 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
9. 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
10. 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?
11. 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?
12. • 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
13. • 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
14. • 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
15. 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
16. • 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
17. Security and Operational outcomes were achieved while at runtime. SO DEFINITELY SECOPS Net net – we did good SecOps
18. • Using managed services of cloud providers • And/or Container based usually running micro services Cloud Native refers to environments that are
19. • Based on automation • CI/CD Integrations • Centralised Logging and usually have dashboards • Secrets Management Distinguishing attributes for Cloud Native
20. 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?
21. AWS ECS AWS KMS AWS LAMBDA Jenkins CloudWatch Events AWS CloudWatch Possible stack to make this cloud native
22. 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?
23. • 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?
24. • 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
25. 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
26. 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
27. • 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?
28. • 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?
29. SecOps for the Cloud using Cloud Native Not just a thought, but something concrete we can rely on and build together. YAY!!!