Security is changing and is rapidly uptaking the DevOps movement. In this video, explore the major implications.
- In this course we've looked at how DevOps affects our IT culture. As we look to the future of DevOps, we see the integration of other sections of the parts of the IT organization, from QA to DBAs to the security team. Let's see how security is ready to jump into the DevOps movement, but maybe in a little bit different way than you would expect. Security has a real similar history to operations and organizations. In fact, security finds itself in the same spot that operations found itself in 10 years ago. Security is undervalued in many organizations and has different priorities than many other teams which leads to natural friction. To make a generalization, we normally see ratios in organizations of 100 developers to 10 operations to one security person. This is in order of magnitude problem. Security feels the burden of living downstream and is the recipient of the throw it over the wall practices. All right, why is this? Well, in many organizations, security is just seen as a checkbox to gain compliance and that's about it. In 2010, a group of security practitioners met and they were trying to discuss this problem. From that discussion arose the Rugged Manifesto. The Rugged Manifesto gives aspirational values that everyone in the organization can be excited about. We can all relate from one of the lines from the Rugged Manifesto, "I recognize the my code will be used in ways that I cannot anticipate, in ways it was not designed, and for longer than it was ever intended." Rugged changes our language from a point in time security approach to doing better defense. Let's take the idea of Rugged and look at across all the areas of DevOps. Alright, first, let's talk culture. Self realization is often the first step. The security team needs to realize that if they're going to be a blocker, they're just going to get routed around. Every team in organization is judged on how well it provides value and how much wasted producers along the way. Many security teams today are set up in a way that adds little product value and inserts waste into many of the processes. The second step is realizing when you're outgunned. We don't have enough people to overcome the hundred developers to one security staffing problem. The best way I've seen to overcome this is by deputizing a security champion in each group. By having these security deputies across the teams, Rugged becomes part of the discussion. Alright, next let's see how security relates to infrastructures code. One of the core goals of compliance auditors is to understand exactly how the systems work, how data backups are handled and so on. With an infrastructure as code shop, the auditors can just look at, you know, for example, like the chef recipes and see how they're defined automation and understand your system much more quickly than a discovery based approach. If you're instantiating systems of a model, then you can focus the discussion on just validating that model. Okay, let's take a look at continuous delivery in security. With a continuous delivery pipeline, you're allowing developers to push code straight to production. Now, some security professionals they cringe when they hear this, because of their interpretation of compliance standards like PCI6.4.2 and they say that this is not allowed. Lucky for us, they're wrong. Now, I won't get into this too deeply. It's not like PCI is the most exciting topic in the world. However, if you're dealing with separation of duties, and that's an objection that you face, I highly recommend reading the DevOps Audit Defense Toolkit, which is geared to helping implement DevOps in highly regulated environments. In see CICD, we move security testing from the end of the cycle to the left. Are there four key areas, software supply chain security, regression testing, environment validation and attack testing. I recommend instrumenting your CICD system with a way to validate your build of materials. This is all of the software that is going into your system. And using either commercial or open source tool chain to validate them for known bugs. Often we run these tools after development is over or during audit time. However, the most optimal thing to do, is run them earlier in your build system. Regression testing is a core feature of CICD pipelines, and it helps you not repeat the past. Taking security vulnerabilities and creating them as tests in your pipeline is highly recommended. Maybe you find yourself without security staff or expertise. One piece of advice I like to give everybody in this situation is to specify functional tests in the CI system as requirement for your next security engagement or penetration testing. So don't give me a PDF, give me a functional test at the end. Environment validation can mean a lot of different things but here's some ideas on what you can do to regularly validate. Chef an open source config tool has an audit mode that you can just check to see if you're in compliance. Additionally, environment validation happens at the cloud layer. There are some great companies like Threat Stack, which makes sure your cloud provider is locked down and new vulnerabilities haven't been introduced. Alright, the last thing I want to talk about is attack testing. Can you answer, am I being attacked right now? Or can you answer, what is being attacked? You know, here's a lot of companies out there without insight into what is actually happening in the runtime environment. Lots of security dollars are spent to meet compliance objectives, but they're often done without putting any telemetry in place to answer these kind of fundamental questions. The days are over for security experts that just drop off a PDF with thousands of vulnerabilities to you. Now we see security teams focus on repeatable, discrete tests. These are tests that can be embedded in your continuous delivery pipeline and get the security team speaking the lingua franca of the team. I'm a core contributor to a tool made for this very thing. It's called the Gauntlt and it helps you be mean to your code. Finally, a word about security in your operational environment. My advice is to instrument your runtime at the application layer with the defense product like Signal Sciences, or at the host layer with a solution like AlienVault. Full disclosure at the time of this recording both Ernest and I work for these two companies. But we work there for a reason. We believe that these spaces need innovation, and it's one of the big challenges security faces because we need to answer these two fundamental questions. All right, in this section, we've discussed how security changes in a DevOps World and we recommend taking a valued centered approach and adopting principles from Rugged as a path toward bringing security to DevOps.
In this course, well-known DevOps practitioners Ernest Mueller and James Wickett provide an overview of the DevOps movement, focusing on the core value of CAMS (culture, automation, measurement, and sharing). They cover the various methodologies and tools an organization can adopt to transition into DevOps, looking at both agile and lean project management principles and how old-school principles like ITIL, ITSM, and SDLC fit within DevOps.
The course concludes with a discussion of the three main tenants of DevOps—infrastructure automation, continuous delivery, and reliability engineering—as well as some additional resources and a brief look into what the future holds as organizations transition from the cloud to serverless architectures.
- What is DevOps?
- Understanding DevOps core values and principles
- Choosing DevOps tools
- Creating a positive DevOps culture
- Understanding agile and lean
- Building a continuous delivery pipeline
- Building reliable systems
- Looking into the future of DevOps