Security and DevOps for the first time

- [Instructor] Security and DevOps working together has a lot of names, DevSecOps, DevOpsSec, Rugged DevOps. The important part is not the name. Feel free to call it whatever you need in order to achieve the desired results, but the important part is adopting some new approaches to security. I recommend three main approaches to security in the area of DevOps. The first approach is to embrace the role of an enabler. In your mind, juxtapose this with security being a blocker. Instead of being the department or a team that blocks the release, be the department that helps everyone go faster and assert security quality at the same time. In the end, the security team needs to understand this core principle. If you're a blocker, you'll be routed around. If you're an enabler then you add value. Now that sounds good on paper, but it isn't as easy in practice. One of the things I've seen work is to bring the security team together and ask, how can we help the overall software development pipeline go faster and be safer? Once you have a list, find the lowest hanging fruit and use small projects to test out your ideas. The next approach is to think about the software supply chain as a whole and look for places to add in security. With the rise of a lot of the compliance frameworks, for many people security became more active. You add in a certain control because compliance says you have to. The new approach I'm recommending is to look from start to finish at your software supply chain and pinpoint areas where security can add value. Shannon Lietz who is a good friend coined the term DevSecOps. She has an excellent process for looking across your supply chain and asking questions to help identify areas to improve. I have a slightly modified approach and think of a software supply chain as these six areas. First design, what do you intend your software to do? Can you make sensitive flows more secure? The next is inherit, what software have you inherited such as libraries and dependencies? What other layers of software are you inheriting from your OS or your service provider? Can you create a software a bill of materials so when a new vulnerability comes out for a certain library, can you know whether you have that or not? The next is develop, as you develop, are you writing tests for security? Ask if you're writing tests for auth for handling tokens and for the OAuth top 10. Okay next is build, as you build your software, do you have security acceptance tests? For the deploy stage, what happens to get software into production? Are you securing config and secrets for the application and infrastructure? Lastly operate, are you under active attack at this very moment? Do you even know what is getting attacked? This course is going to hone in on some of the middle sections of the pipeline in order to add automation to do security testing in a devops context. However, I want to stress that it is important to think from design to operation when evaluating the software supply chain. Okay, this leads us to our last approach. Create feedback loops to automate your security improvement. There are three main places I like to add feedback loops when getting started. First is the Continuous Integration or Continuous Delivery system, CI or CD. Sometimes it's referred to as the build system. Popular CICD systems include Jenkins or Bamboo or SAS tools like Travis or CircleCI. If you're unfamiliar with these, there is a class I recorded with Ernest Mueller here in the library under the title DevOps Foundations: Continuous Delivery/Continuous Integration where we cover CICID in depth. Adding security testing to CI finds flaws in development and this is most often the best place to start with security automation. We will cover this in detail throughout the course and at the end of the course, we will put it all together with an example of adding security testing to a CI system. Next I look for where deployment happens. Generally there is a pre-prod or staging tier where changes get pushed before going to customers in a production capacity. Sometimes deployment is handled by the CICD system itself, sometimes not. The goal is to test against something that looks and acts exactly like production does. This is a good place to run security attack tooling and anything that attempts to exercise several attack vectors in conjunction. I also like to put longer running attacks here so as to not slow down the build, but more on that in future videos. Lastly I look to production and try to monitor sensitive data flows against common attacks. Most of my experience is in running large-scale web apps, but the idea is the same no matter the system. Look for areas to instrument that allows you to have feedback to answer, am I under attack right now? Using defensive tools like WAFTs or RASP for common web application security is a good start. Adding instrumentation around authentication events like password resets and failed logins gives insight into account takeover attempts. Really we can sum it up with our overall approach. Our whole approach here could be summarized as first change culture by adopting the identity of an enabler. Second, understand current state as you look across your software supply chain in order to remove blockers. And lastly, create positive change through exposing feedback loops throughout your system.