Venafi Interview – DevSecOps Challenges
Helen: When a breach causes reputational damage at an organization, what is a typical response and does this vary from what the response really should be?
Sean: That’s a multifaceted question. Every company handles things very differently. The typical response from the inside is to fix the breach and make sure it never happens again and the typical response from the outside for the company usually is: “We’re sorry, and we’ve addressed the problem and will make sure it doesn’t happen again.” Then the consumer generally must decide to trust the company again based on their current behaviors or to do business elsewhere. However, if you look closely though, there are subtle markers that indicate what the future will look like. Where is the blame being placed? Does the apology come with action? Because the interesting part actually comes after the apology. Do they take responsibility for the breach? What do they do to learn from the experience and do they create and continually improve their security posture around those learnings? What actions are they taking to not only prevent something from happening again but to help others from suffering the same fate? It’s what happens after the apology that tells us the most.
Helen: How is culture related to cybersecurity risk?
Sean: Culture is essential and will make or break your organization’s security posture. Culture is where it all begins and will be the foundation of everything that comes next. DevSecOps is a great place to start, culturally, because without the right thought patterns and approach, you’re just throwing tools against the wall until something sticks. I’ve said, and I’ve heard a lot of others say, the basis of DevSecOps is that everyone is responsible for security, but the more accurate statement may be everyone has a SHARED responsibility for security. It’s not an ‘us versus them’ conversation; it’s a WE conversation. It’s important to make the delineation because everyone being responsible for security will culturally start a war and everyone quickly gets burned out thinking they have to be security engineers as well as handling their current roles. The truth is that we all have security responsibilities, but the expectation is not for everyone to be a security engineer but rather apply the proper security principles for our given areas and collaborate with security to grow from what we learn by applying those principles.
It’s a lot like Sisyphus. I’m always thinking about how to get everyone to be more like Sisyphus and focus on the rock (security) he pushes. Each of us have a boulder to push (read as security), and it’s a heavy one, but Sisyphus was a force to be reckoned with; pushing the rock was his purpose. Just because inevitably the rock would just roll back down the hill against him, he never stopped, he always kept making the climb. A great culture defines whether you see Sisyphus as someone who was just being eternally punished or if you see him as an unstoppable security driver. Do you continually raise the security bar or are you crushed by the weight of risk?
Helen: How do automation and cloud platforms help organizations improve their security posture?
Sean: This is something I get asked often, but it is not always fully understood. Which is (ironically) understandable; you don’t know what you don’t know. I’ll start with how cloud platforms show how economies of scale can improve security postures quickly. A cloud provider has a larger experience base to learn from, so improved security for a platform equates to better security experience for every consumer of the platform. Cloud providers can also leverage their scale and experience to rapidly provide improved security at several levels of sophistication that can’t be rivaled by any one company. For example, one large cloud provider actually leverages customized hardware that is purpose-built to reduce attack surface down to even the physical hardware level that can’t be purchased through commercial channels. Access security is another great example: cloud providers have much more centralized and resilient identity and access management controls with more granular level controls than a ‘roll-your-own’ solution may have. Then as you start moving up the stack from IaaS into PaaS and SaaS solutions, it works even better as a bulk of the operational burden, such as patching, logging and configuration management is handled automatically and the attack surface is reduced even further.
Combined with solutions like recommendation engines, granular access control, and service isolation, you’ve got a very comprehensive security posture at your fingertips, allowing you to move faster, provide more consistency in services and configurations and a better overall operational experience which equates to more time for innovation. Finally, the power of the cloud lies in the people behind the scenes; the talent pool is usually much greater than most companies have at their disposal and in some cases such as SRE, they spawn entire movements resulting in industry shifts in how we operate.
From an automation perspective, I’m going to try to oversimplify this one. What do you call doing the same thing over and over again expecting a different result? Insanity. Automation essentially helps reduce the insanity in the value delivery process by ensuring when you do something over and over again you get the SAME result. Automation removes human error, provides easier auditing, and allows security techniques and processes to be injected incrementally into the pipeline for improved security posture for your team and your customers, once again freeing your teams up to reinvest that saved time in other innovation or security activities.
Helen: What tactical interventions have you found really work to improve a DevSecOps climate?
Sean: Nothing works better than shared responsibility and understanding. Don’t let the collaboration approach fool you, while on the face of it, it may sound more like strategy, there’s a great degree of tactical execution required to deliver value here. I’ve created a simple three step approach that yields a lot of visibility into security challenges and can spark conversations on how they can be addressed.
- Step 1: Security Listens. Leverage the same approach as paired programming and embed a security engineer into development teams TO LISTEN. The goal is for security to understand from the developers perspective where security can be involved earlier in the process as well as where the sticking points are for teams. Then, and this is critical, have your security engineer come back and create a working session with their security team on a value stream map and work the map. If you don’t do this step, you’re wasting your time and if your security teams don’t have the discipline to do this, chances are they are chasing after the wrong problems and not providing much business value. Understanding cross-functional challenges and how to provide value in the context of those challenges is what we are aiming for with this step.
- Step 2: Developers Listen. Now it’s time for the developers TO LISTEN to security by embedding them into a security team to understand the processes, challenges and pain points they experience. The goal is for developers to take an understanding of the security processes and areas they can improve through collaboration back to their teams. Even more important is that developers log and pay this process off as cultural debt in the same way they pay off technical debt. Cultural debt is much more expensive as it can spread beyond a product, team or tool into the entire organization. By paying off cultural debt, you’re modeling the behavior that drives the culture that everyone should be able to understand and embrace. I have found setting up tools like ChatOps between the liaisons and teams helps keep the process visible and helps capture challenges that can be discussed and considered.
- Step 3: Education, Education, Education. Now that we’ve identified the challenges and both sides have a better perspective and understanding of the issues, it’s time to educate. There’s something very powerful about seeing how the other half lives. It helps dispel rumors, it helps build relationships and most importantly it yields understanding and opens up opportunities to improve. Maybe the teams found that no one understands or knows how to use a tool, that’s a great opportunity for a ‘lunch and learn’. Perhaps security didn’t realize how many open source packages were being used, that’s a great chance to introduce development teams to your open source security management tools and teach them how to integrate them into the pipeline. You’ll be surprised how many people in your company have the same issues and how much time is spent trying to figure out how to address them. This step helps reduce toil and focus learning on the most critical challenges. Each education opportunity you create comes with collateral that can be leveraged by the entire company, so the return on investment is high and far greater than any individual trying to figure it out on their own.
Execute these three steps well and you’ve paved the road for deeper tactical work such as tool injections into the development pipeline, open source / centralized source control management, and chaos engineering that will yield exponential returns for your teams. Best of all the approach works with any number of teams from development, security, architecture, and even product.