Confessions of a Former CISO: Shaming People for Bad Security

My name is Scott King, and I am the Senior Director of Advisory Services at Rapid7. Before that, I was a CISO and have held many different roles in the infosec profession.

Today marks the second episode of “Confessions of a Former CISO,” a video series that highlights some of the mistakes, challenges, and successes I have learned throughout my career, with the hope that others can learn from them as well.

In our second episode, I will share some lessons I learned the hard way about shaming others who do not take security seriously enough. Please watch the video below, or read on for a recap of what was covered.

On being the instigator of shaming

I’m not proud of it, but earlier in my career, I was the instigator of shaming someone who, in my view, wasn’t taking security seriously enough. What I realized, though, was their goals were simply different than mine, driven in part by management who wasn’t on the same page in terms of setting the right tone for the organization but I also realized that my lack of understanding and empathy for their role and their responsibilities played a part in my actions.

What I learned from this was that as security professionals, it’s our responsibility to bring people together to inform risk-based decision-making. People often view security as the naysayers who come in and embed unnecessary rigidity, but what I’ve learned is that security is really about bringing everyone together to enable good business. In other words, security isn’t all about doing security.

This was one of the biggest realizations for me in my career and reshaped how I approach cybersecurity risk for the organizations I’ve worked for.

Using technology to end separateness

In one of my prior roles, I had this idea that we as a security organization had to maintain a level of separation from the rest of the IT stack because I thought the IT organization didn’t practice good security hygiene. In one scenario, my team and I were looking to consolidate technology into a common footprint. What we ended up doing was creating an architecture that made the other team feel completely inadequate and unable to meet our needs.

After using this architecture for some time, we started to realize that in order to adhere to our own security policy, we either needed to make an investment in IT administration tasks or revert back to the level of support and standards our IT team could provide. We chose the former and ended up spending far more money than we should have without much of any gain.

The lesson here was that when making an important decision, don’t let internal politics, like whether we believe IT is security savvy enough, be the main driver and blindly shame them for perceived shortcomings without doing our own due diligence.

My foot-in-mouth moment

In another situation, I had just started working for a company and was involved in a project that was already underway before I came on board. The project was to implement an organization-wide identity and access management solution. Early on in the project, I stated that a decision that had been made prior to my arrival was one of the stupidest things I had ever heard, not knowing that the project manager I was speaking to was the person who made the decision (insert foot in mouth).

The project proceeded with a very awkward ambiance and ultimately, we were left with a less-than-ideal operating model because of an uninformed comment I made that put shame on prior decision-making that I didn’t yet understand.

My lesson here was that instead of jumping to a conclusion, it’s important to understand the thought process and build bridges to work productively with the team instead of coming in and tearing them down.

Putting myself in their shoes

Throughout my career, it’s been my goal to improve the security posture of the companies I’ve worked for. However, as I reflect on my tenure in each of my previous roles, the common theme is I did not consistently put myself in my counterparts’ shoes. Instead, I was focused on finding the best solution from a security standpoint rather than incorporating other parts of decision-making, such as business objectives, costs, or IT.

In this way, I wasn’t truly improving each company’s security posture since not every team’s viewpoint and needs were factored in. This has been a lesson that’s carried with me ever since.

Key takeaways

While sometimes security risks should outweigh other factors in a business decision, in my experience, that’s the exception and not the rule. More often than not, my approach ended up only driving wedges between myself and other parts of the organization, when instead the goal should have been to work together to accomplish the greater business goals. To do this effectively, I’ve found it best to lead the discussion by empowering the stakeholders and reach a consensus on risk tolerance. At the end of the day, the business drives risk management based on factors from many different viewpoints, not just security, and all need to be considered equally.

Thanks for reading! We release new videos once a month, so keep an eye out for our next one!