The document discusses DevSecOps and identifies its four main components as training, communication, integration, and code. It provides examples of tools that can be used to implement DevSecOps, such as backlogs, support ticket tools, linting tools, and automated vulnerability assessment tools. The document emphasizes integrating security into all phases of the development lifecycle from planning through deployment.
My name is Kieran Jacobsen, I am the Head of Information Technology at Readify and a Microsoft MVP for Cloud and Datacenter Management.
This has been a massive year for data breaches, there are four worth discussing.
WannaCry made the press in a big way, primarily due to how it impacted the UK’s National Health Service. Attributed to the North Korean government, WannaCry left a wide range of NHS computer systems down, closing hospitals and diagnostic facilities. Speaking with medical professionals, including doctors, nurses, their response is that this attack likely resulted in people loosing their lives.
Maesk Shipping, they handle one in seven shipping containers world wide, they fell victim to the NotPeta ransomware. NotPetya has been attributed to the Russian government, and severely impacted organisations who had Ukrainian based offices. Maersk has lost over 300 million dollars due to the attack and their global shipping operations were so heavily impacted that products from the likes of Apple were delayed being shipped to customers.
Now of course, these were all overshadowed by the Equifax breach that resulted in the loss of over 143 million records.
Now the last one is equally as interesting, especially for the audience here. Deloitte suffered a breach of a number of systems including their email. What was found in the days following their announcement were a number of obviously bad processes including things like publicly exposed domain controllers and credentials sitting in public GitHub repositories.
So here we can see a development and operations team working prior to DevOps. Development would catapult new builds at operations, and they would return with a volley of bugs and issues. Apps were unstable, devployments a complex mess, and overall our organisations suffered.
Along came DevOps, with a promise that we would get two waring factions to act as one. To unite them against a common enemy, users! DevOps has largely been a success, apps are more stable, releases simplified and faster.
Unfortunately, in the rush, we left security concepts out of the equations. In the race to DevOps, organisations often forgot to include their own security teams. It is my belief that this is why we are now seeing the issues with insecurely deployed apps, databases, even things like load testing and disaster recovery been forgotten.
So how do we move towards a DevSecOps model? Now I see that there are 4 core components, unified communication, quality training, ensuring you consider all of your code, and finally integrating the right tools into the right places.
Excel is clunky, word can be hard to diff, and we should all by now know the risks of documents with macros!
Backlogs and boards encourage collaboration, and ownership of tasks. Security issues and reviews do not produce reports, that produce tasks in a board.
Don’t underestimate the power of support ticket tools. They encourage better working models, ownership of issues and better customer communication. These tools are not just for ops, but also for developers and security teams as well.
Training is super critical, we can’t be experts, but we need to have awareness of the other parts of our team. Training needs to start for all areas of IT from day 0, and not just the basics. Developers need to be aware of your organisations of code quality, and this includes security.
When we think about code, we usually thing about application source, but what about the other parts of your environment?
Are you monitoring and reviewing ARM templates? What about Chef, Puppet and PowerShell DSC configurations?
In this example, taken from the Azure Quick start templates, we see a configuration element relating to a Network Security Group, this one restricts traffic to RDP, port 3389. Unfortunately, they have allowed all the internet as a source address, so I guess someone will start brute forcing this box soon enough.
Do you know if your developers are deploying from examples like this?
Another example, this time we have an azure ARM template that deploys a virtual machine. It takes in a couple of parameters, specifically the local administrator username and password.
To deploy this virtual machine, the developer has created a parameters file and specified the username, password and a dns label prefix.
The dev runs the deployment, their virtual machine was created successfully. There isn’t anything for us to worry about right?
Unfortunately, in their race to get home, the developer commits the changes to both the template and the parameters file into git, and then pushes that to the remote source. What if that was a public GitHub repo? Well then those credentials would be exposed for all the world to see.
How would you go about detecting and monitoring for this?
Exposed domain controllers and credentials on public GitHub repositories are exactly what we saw during the Deloitte breach. Training and monitoring is probably one of the best tools to prevent these types of issues.
So how do we integrate security into DevOps? Where is the right place? The answer is, at every single step.
When we plan, we need to involve security in both our sprint planning and reviews. I recommend considering security stories early due to their complexity; you don’t want to leave them till the end of a release cycle.
Training is crucial to writing secure code, but its also worth considering methodologies like test driven development. Using the right tools is crucial; most IDEs have tools or plugins that will assist developers by highlighting potential security risks. Pull Requests are also crucial, code that contains security issues, doesn’t get merged.
At the build phase, things like linting and static code analysis tools provide a way of automatically scanning our code to determine if there are any obvious vulnerabilities.
Consider automating security focused testing, fuzzing and most importantly, because people like the ABS seem to forget, load testing.
During the release and deployment phases, we have another opportunity to use automated scanning and assessment tools. Application vulnerability assessment tools, or even infrastructure assessment tools.
In the final two steps, operate and monitor, there are quite a number of things we can do. Monitoring log files and looking for unusual behaviour or patterns is a great way of finding and preventing potential attacks. Do you keep an eye on the failed login attempts? What about successful ones? These metrics could be good indicators of attempts at brute forcing access.
Now during the earlier phases, we used automated tools to look for vulnerabilities, and we should rerun these tools once our application has gone into production.
With the breach of Equifax, Struts has become highly visible. Do you know if any of the software your applications or npm packages contain vulnerabilities? What is your process to upgrade these in your production environment?
If you want to know more about Readify, please come and ask one of us here at the stand. I will be placing the slides on my website, PoshSecurity.com.
Thank you all very much for listening to me.
<applause>
Does anyone have any questions.