Innovate. Accelerate. Win.
September 18-19 | Las Vegas and Virtual
#MIMSummit2023 is the frontier for unstoppable innovation. The gathering ground for security leaders looking to redefine what’s possible. The must-see industry event of 2023. Register today and save with special Early Bird rates!
Let’s face it, business has changed quite a lot over the past 10-15 years. 15 years ago, the IT department was quite powerful. By the IT department I mean everyone in the CIO’s department. However, because IT projects tended to be long, drawn-out affairs, they were somewhat slow in delivering the technology that was needed for innovation. As a result, the business units started to take over responsibility for pushing their own IT development projects ahead.
This was the birth of DevOps. And with the success of continuous development, we’ve seen the development teams increase their influence, as well as power and authority, within organizations. The rapid-fire results that they have been able to deliver have become so important to business results that other groups within IT hesitate to do anything that might slow them down. But this hesitation can lead to some problematic trade-offs resulting from conflicting priorities within security and IT departments.
Today, DevOps teams are so powerful that they can actually stop IT teams from deploying technology.
Here’s an example, which came out of a conversation I had with a CIO just the other day. He mentioned that one of his DevOps teams was stopping part of the Venafi deployment that was ultimately going to help DevOps teams! This particular DevOps team was so focused on solving the immediate compromised certificate issue, that they didn’t want to allow testing for a solution that would actually help them speed things up and prevent future occurrences of the same problem. The DevOps team’s commitment to timely results, for their business outcome, rendered the IT team powerless to keep the deployment moving forward in time to help the DevOps team achieve a longer term, positive outcome.
That’s when I started to wonder if the immediate value of DevOps might come at the expense of some longer-term IT and security projects. In the case of machine identity management, this certainly seems to be true. Very few DevOps people actually understand the technology around certificates—how to use them properly and how to ensure that the appropriate security configurations are applied. They just can’t slow down enough to learn about how important certificates are as machine identities for their containers, clusters and microservices.
For DevOps teams, certificates are just something that they have to use. Simply put, developers are generally not security people. To them a certificate is a certificate is a certificate. It’s just a checkmark in the process. Perhaps, they will engage as far as asking, “Is there a certificate in there? Yeah. There’s a certificate in there. We’re good to go then.” But that’s pretty much it.
But that lack of awareness can have far-reaching impacts. If no one is thinking about the bigger security picture, then nobody is thinking about whether the same private key is signing thousands of servers. That’s how you can get virtual servers spun up with the same certificate used and reused and reused over and over. And nobody knows where that certificate is anymore. When the original certificate expires, it is impossible to be sure you have renewed ALL the copies.
It’s easy to speculate why this is happening. Keys and certificates are a relatively old technology that is being used to secure innovative new technological breakthroughs. This attitude is particularly applicable to new DevOps practitioners, who are sourced from GenX and Millennial talent pools. They’re like, “What is this stuff? Why is it still here? Oh. We have to have this but why isn’t there something better?”
But the reality is that the value of a technology often has very little to do with how old or new it is. This is certainly true of PKI and has a real impact on machine identity management. As I wrote in a previous blog, “Instead of becoming less relevant, PKI is becoming more relevant as we increase our adoption of cloud and DevOps infrastructure. Both of these technologies consume large numbers of certificates that are only used for short periods of time.” The reality is that no one has been able to develop an alternative that is as ubiquitous and easily deployed, or one that is as cost effective.
PKI is not going to die. And it’s not likely that there is going to be a replacement anytime in the near future. Given the long-term importance of PKI to the management of machine identities, it’s critical that we equip developers with easier ways to incorporate the safe use of certificates into their DevOps processes. Equipping developers with self-service certificate portals can help speed up the development process and, at the same time, help ensure integrity and compliance of the security attributes of your certificates. And integrating secrets acquisition into DevOps recipes will help foster best practices in applying keys and certificates to development efforts.
As your DevOps teams become more powerful, funded and supported by the business, outcome focused, rarely project or process focused and begin to call more of the shots, make sure that they don’t inadvertently shoot down security.