Here are the slides for my talk "Real-life Cloud Security Issues" which I presented recently at the Photobox meetup "An evening of AWS Security". Many thanks to all at Photobox for a great evening, and to Tash Norris and Toni de la Fuente for their excellent talks - I've already incorporated Toni's open source Prowler tool to the AWS compliance lab in my cloud security course at 44CON.
The Cloud Security and DevSecOps training course I’m delivering for 44CON in June includes AWS, Azure and GitHub accounts which the students use so they don’t need to create their own.
Wouldn’t it be great if students could turn up with any laptop, or even an iPad, and do the course. And the time spent on the labs would be used to learn about cloud security and DevSecOps, not debugging software installation issues.
So I started looking at building a training platform which students can use – and as this is a cloud security course, what better place to do this than in the cloud?
Click on the "Read More" link below to see the proof of concept and design.
Yesterday I took the new 2019 version of the AWS Certified Solutions Architect Professional exam – roughly 2 weeks after it was launched in February.
….click on the "Read More" link to see my journey
I'm looking forward to demonstrating real-life cloud security issues next week at "An evening of AWS Security" at Photobox's new offices in London
My recent talk at DevSecCon London 2018 "a journey to continuous cloud compliance" is now on YouTube:
To see the presentation slides, click on "Read More"
AWS Lambda is a widely used cloud service which allows customers to create event driven serverless functions of short duration. To find out whether a bad lambda function could lead to AWS account takeover, I created some code to deploy one and uploaded to GitHub.
The code returns the environment variables of the container in which the lambda function is being executed - this simulates what could happen if the Lambda function was vulnerable to an injection attack or a malicious dependency was included in the code.
An attacker can simply take these credentials and use the AWS command line to perform any actions within the AWS account which are allowed by the Identity and Access Management (IAM) role assigned to the Lambda function. In my example code, this is access to AWS Secrets Manager. In the worst case, it could be access to IAM allowing an attacker to set up their own administrator account.
So the answer is YES - if the AWS Lambda function is vulnerable, and the assigned role has excessive permissions, a bad Lambda function can lead to AWS account takeover.
To protect an AWS account from takeover due to bad Lambda functions, see my blog 10 Steps to Lambda security. Click on the read more link below for screenshots and technical details.
AWS Lambda, launched in 2015, is a service which allows customers to create event driven serverless functions of short duration.
Since then Lambda has become amazingly popular, Lambda functions are widely used for many different purposes ranging from low latency web applications and IoT, to AWS account operational and maintenance tasks.
Just like any other application in the cloud, a vulnerable or poorly configured Lambda function can lead to data loss, privilege escalation and even AWS account takeover, see for example this blog post.
I’ve created “10 steps to Lambda security” based on my experience of working with customers using AWS Lambda:
© 2018 Paul Schwarzenberger www.celidor.co.uk May be used with acknowledgement
Continuous cloud compliance is essential to maintain the security of applications and systems in the cloud. At DevSecCon London next week I'll be talking about my experiences in this area, and how an effective solution needs to include prevention, detection and remediation elements.
In my talk "A journey to continuous cloud compliance", I'll give a live demonstration of techniques and approaches with a system I've built in AWS using Capital One's open source Cloud Custodian project, combined with Lambda functions and other AWS services to provide customised notifications via email and Slack.
Click on the read more link to see other examples of alerts and automated remediation.
As I was developing the course DevSecOps Hands-On I realised the need for a DevSecOps Framework - covered in my earlier blog post - and a DevSecOps Toolkit.
The DevSecOps Toolkit illustrates the spectrum of tools which can be used for various purposes (columns) across the primary system components (rows). The named open source projects and vendors are examples - it's not possible to be completely comprehensive in a single diagram.
An organisation can use the toolkit to help assess their DevSecOps maturity - ideally there should be at least one tool in each area.
This is a very fast moving field – for example “SOAR” – Security Orchestration, Automation and Response – is a new category created in late 2017.
Keys and secrets in code repositories have led to major data breaches and significant financial loss. An AWS secret key accidentally pushed to GitHub on a Friday reportedly led to a loss of $64,000 by Monday morning, as 244 virtual machines were spun up. The attacker who stole 57 million user and driver records from Uber appears to have made use of an AWS credential within a private GitHub repository with permissions to the S3 bucket used as a database backup.
Why do developers put keys and secrets in code repositories?
Developers and DevOps engineers want to automate application and infrastructure deployment and the most straightforward way to do this can be to include the necessary keys and secrets in code. Sometimes this starts off as an initial proof of concept, but then ends up in production.
It's also easy to accidentally push a credential to a repository. I've done this myself with an Azure service principal credential. Fortunately it was a repository on a private network with limited access.
How can I discover keys and secrets in code repositories?
I've created a Github repository and deliberately included some keys and secrets. As it's a small repository, you can probably find them all manually. You can also scan using a tool such as GitRob. Click on the Read More link to find out more.