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"
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.
DevSecOps is a new way of working as described in my blog "What is DevSecOps? And Why is it needed?" As I was developing the training course DevSecOps Hands-on I realised I needed a DevSecOps framework encompassing the elements making up DevSecOps, which I then used to define the topic areas of the course at a high level:
The DevSecOps Framework shows the various aspects which together encompass effective DevSecOps within an organisation, spanning application security, infrastructure security and security operations.
to see more on culture, organisation, tools and training as applied to DevSecOps, click on the "Read More" link .......
DevSecOps has been described as "security as code", "a marriage of DevOps and Security" and "shifting security to the left".
Traditional security approaches are inefficient and largely ineffective for organisations using Agile, DevOps and Cloud - as illustrated by the massive amount of recent data breaches.
DevSecOps is a new approach which embeds security to each DevOps team, with automated security testing at all stages of the software development lifecycle.
Security infrastructure, policies, controls, compliance, audit and even secure operations are all coded and automated, with almost no manual processes.
This is the basis of a new course I've developed, DevSecOps Hands-on which I'll be delivering at QA's International House in London early October.