![Improving DevSecOps with a Hacker Mindset [Sean Davis Interview, Part 2] - cover graphic](/_next/image/?url=https%3A%2F%2Fcdn.venafi.com%2F994513b8-133f-0003-9fb3-9cbe4b61ffeb%2F38a4df59-4f8e-4381-b609-927314a1750b%2Faid_field_img__837a72feba832199b1911b404455de94.png%3Fw%3D864%26h%3D370%26fm%3Dwebp%26q%3D75%26fit%3Dcrop&w=3840&q=75&dpl=dpl_5K6GokFJa7HkezrHnpB6iq5ZMUKu){kind=small}
In part 1 of this interview with Sean Davis, we discussed the steps organizations can take to improve their DevSecOps climate. As Chief Raconteur for Sean As A Service, Sean is focused on being a human highlighter and cultural flywheel for businesses looking to transform their cultures. In part 2 of this interview we’ll debate whether all companies should view themselves as technology companies and how a hacker mindset can improve the DevSecOps.
Is every company a technology company and if they aren’t, should they be? And if they should, what needs to change to make it so?
Sean: Short answer, no and no. Let’s start with the Securities and Exchange Commission defining the North American Industry Classification System (NAICS). Diving deeper, NAICS actually drives The Global Industry Classification Standard (GICS), which is used to classify stocks. So if the question was true, the entire stock market would be tech stocks, let that sink in for a minute. In order for every company to be a tech company, it means every company would have to offer some sort of technology software, hardware, or service which changes the very nature of the business.
The intent and reality are two very different things. The danger of this statement is that it presents itself as a panacea solution and that it’s the only way forward and you better jump onboard, which has resulted in many failed attempts for non-tech businesses to try to “transform” into technology companies. I’m very passionate about this one as I’ve seen it happen time and time again over the years. I rate this right up there with the statement: ‘agile is a mindset’—if that’s all it was, then there wouldn’t be agile frameworks. Same for failing fast, if you don’t give any additional context it’s difficult for people to understand it or produce the desired outcome. Now, every company should consider if and how to leverage technology to provide a better customer experience. Being agile is a mindset, and you have to fail fast, learn fast, and recover fast. I can get behind those, and they have much clearer messages.
So let’s try a quick exercise, Every Agricultural co-op should be a technology company. Should they be? Probably not. Should they leverage technology responsibly where it makes sense to deliver a better customer experience? Absolutely! Leveraging technology doesn’t make you a technology company. By setting the bar at “every company should be” is a pretty bold assumption. It’s easy to confuse ‘being’ and ‘using’. I can see the positive implications of technology for any business, but the road to hell is paved with good intentions. Being a technology company doesn’t magically fix everything or doesn’t always make you more competitive, nor does it leave you in the dust of your competitors because you aren’t a tech company.
I perceive the point people are trying to get across with that statement is: we live in a society that is rapidly creating greater competitive markets based on technology and there is a clear sign that technology is a critical part of our future. Which honestly doesn’t have anything to do with being a technology company, rather using technology to provide better customer experiences. An Agricultural co-op is still just an Agricultural co-op, no matter how much tech it uses.
What does putting the customer front and center really mean?
Sean: The customer must be intimately involved in not only the communication and voice of the product and services you provide to them but, in my humble opinion, it also means they are part of your narrative. I put it simply as your value delivery doesn’t end at the delivery of value to your customers but rather when your customers have delivered value to their customers. This can be achieved by listening and partnering with your customers in the business, technology and security arenas and connecting with each audience and building meaningful relationships and a mutual understanding of each other’s goals. Companies I’ve worked with have done this in various ways from simple things such as having private ChatOps rooms and touchpoint meetings where both parties can interact directly with liaisons of the product, architecture, and security teams to more advanced concepts of customer feedback being leveraged to refine internal standards documents that are used by the company to govern how products and services are built and delivered. When the customer is truly front and center, it will operate like a bilateral partnership rather than a business/consumer relationship.
How can we work with individuals to develop their hacker mindset? What is the model behavior we want to see?
Sean: There’s a few things we can do to encourage and develop our “hacker” mindsets.It’s important to remember to have fun and experiment, but it’s also important to draw clear lines around ethical boundaries. A great approach consists of what I call a win / win / win. When development occurs, it’s clear to the employee how it provides value to the customer, the company and themselves. If you rally around that when creating programs around development, you will find a greater degree of success.
First, adopt a learning mindset and make your experiences and learning canon in your organization. A great way to do this is through codifying those learnings and experiences into a lean repo, document, or even a set of stickers. However you do it, be creative, inner source and it should be driven from the contributor level. The people closest to the problem are better suited to solve it. Sidney Dekker has a really great explanation, called Safety Differently. This will help people align, remember and practice those principles in their everyday life in an impactful way. Having this will allow you to identify the gaps quicker and provide greater value for when looking for innovation and training opportunities.
Another great way is through education, but watch out for the trap of canvas training, for example, where companies will only do OWASP Top 10 training for all developers and security. The problem here is that maybe a developer is great at preventing Broken Access but has a high propensity for writing code that has XSS exploits. Now, if you take that opportunity to monitor commits and then correlate these commits to security scanning and draw the conclusion: “Hey Sean, I see over the last 6 months, you have had 117 commits and 21% of those have failed muster due to our security tools finding XSS vulnerabilities.” With that information we could take some of their vulnerable code, put them in a sandbox and show them how to exploit their own code, this will land much stronger and we put the focus on improving their biggest areas for improvement vs. generic training. A fairly simple dashboard could allow developers in real time to see their biggest areas for growth.
Finally, Hackathons, premortems, and security chaos engineering exercises can be amazing areas to develop a hacker mindset. Hackathons will allow us to solve big problems for the business or even just implement that lunch ordering app so we can skip the lines (I hope it’s not tied to corporate auth). It’s also a great way to network, grow your areas of expertise and even see how others think about solving problems. Also, in the vein of solving problems, pre-mortems are another great way to develop a hacker mindset because before you start developing anything you assume failure and work backwards to figure out what could lead to the entire project failing. You will be shocked at both the things you come up with as well as the things that get missed when you don’t do pre-mortems. Which leads up to security chaos engineering practices. Contrary to popular belief, security chaos engineering isn’t a set of tools that breaks production.
A colleague of mine, Aaron Rinehart defines it as identification of security control failures through proactive experimentation to build confidence in the system's ability to defend against malicious conditions in production. Security chaos engineering in its most pure form, is testing known truths. Have a web server you think only talks on port 80 and 443? Do you actively test if it can talk on other ports or do you rely on firewalls and distributed network configurations to just be right, everywhere? See how that changes the narrative? Because at the end of the day that’s what developing the “hacker mindset” is about, building confidence in our systems to endure malicious conditions.
What are the typical stages an organization will move through as it metamorphoses into a place where security posture is strongest?
Sean: Organizations are going to vary greatly with the stages they go through, but the important takeaway is that they never stop “transforming.” That is to say they continue to evolve over time. An evolutionary approach is a much better way to tackle strengthening security. The typical formula goes a little something like this.
- First there’s a catalyst, it could be a breach, a major change in leadership, or just a decision that times are changing and they need to strengthen their security posture.
- Next, there is a call to action in the form of new programs, educational training and overall awareness. This could be something as simple as signage or complex as a full-blown portfolio based KPI / OKR’s, but it must result in more active involvement of the business in security both internal and externally.
- The next step really sets an organization up for success. The CTO and CISO should be in lock step with each other and their destinies intertwined. The success of one depends on the other and if they aren’t in agreement and constantly working towards a better state, things will begin to fall apart quickly.
- Once this is done, you want to see the narrative involve the customers / consumers sharing their concerns around security and the company forming bilateral communication I discussed earlier. Solving for those concerns and looking to the future will elicit everything from clearer security commitments to their customers to revamped security and engineering policies and platforms. From there, some of the machine cogs will be upgraded, replaced or eliminated to solve for those challenges.
- Finally, you will see the business begin to develop feedback loops that will drive measurements used to ensure the security posture is continually evaluated and improved proactively. Clear alignment of customers, technology, security, and business organizations that create feedback loops to ensure their counterparts are informed and work is visible to all involved is paramount in continuing the evolution from reactive to proactive security posture.
As a parting thought, there is also a strong correlation between companies who contribute to the industry and open source and their brand confidence and market dominance. Don’t confuse this with a Corporate Responsibility Program, but rather company programs to give back to the industry and customers that it serves in the form of a gift of lessons it’s learned. Contribution begets inspiration begets participation begets investment begets recognition.
Will DevSecOps live forever?
Sean: Forever is a long time. Let’s just say it’s not going anywhere any time soon. While DevSecOps will morph on over time, one undeniable fact remains, security has to be built in. A peer of mine Rajan Gupta said it best, “If you look at every other engineering practice in the world, they all have security built in, so why would it be acceptable that software engineering wouldn’t?” That’s the problem that DevSecOps, SecDevOps, or whatever you call it solves for. Like I always say, it’s not what you call it, it’s what you do with it that matters.
Machine Identity Security Architecture
Related posts
- 3 Steps to Better Understand DevOps Security Challenges [Sean Davis Interview]
- DevSecOps: Minimizing New Attack Surfaces for DevOps [Interview with Mitchell Ashley]
- What Is Your DevSecOps Manifesto? [Interview with Larry Maccherone]
- US DoD Reference Design for DevSecOps [Interview with Nicolas Chaillan]