Sean Davis is currently Chief Raconteur for Sean As A Service and is focused on being a human highlighter and cultural flywheel for businesses looking to transform their cultures. Sean currently sits on Technology Association of Georgia and DevOps Society boards, an Ambassador for Humans of DevOps and a flagship instructor for DevOps Institute And ITSM Academy for Agile, ITSM, DevOps and DevSecOps. Prior to Sean As A Service, Sean was the Chief Transformation Evangelist for Equifax with a focus on creating opportunity between the market, customers, consumers and technology teams to deliver exceptional experiences and best-in-industry data and analytics services. His industry experience with 3 of the Big 4 accounting firms allows him to lead business and digital transformations while creating competitive FinTech platforms and products.
As a DevSecOps ambassador and advocate, Sean spends a great deal of his time dedicated to the industry’s community and collaborating with its leaders to solve the problem of tomorrow, today.
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.
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?
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.
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.
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.
In part 2 of this interview, we’ll discuss ways that you might use a hacker mindset to improve DevOps security practices.