When you are hired for a security leadership at a company you are being hired because the company has a need for your experience. The company may need help with reducing risk to a new business area, successfully passing a new compliance audit, implementing a new security capability or simply growing the team to match the growth of the company. All of these are possibilities, but I often find one of the most important underlying reasons a company hires a new security leader is to effect behavioral and cultural change. Changing behavior, and ultimately the culture, of a company is an exceptionally difficult challenge for a security leader and the following are some examples of what doesn’t work when trying to effect change. In Part 2 I’ll cover what does work.
What Doesn’t Work?
First, let’s talk about what doesn’t work. In some cases I have learned these lessons the hard way. In other cases, I’ve learned these lessons through observation or listening to my peers.
Don’t Be The Mafia (Or What I Like To Call “The NO Factory”)
First up, avoid creating an adversarial relationship between your team and the rest of the company. If the security team constantly tells the rest of the company NO, then eventually the rest of the company will start ignoring your team and this will become a problem in terms of risk management, security enforcement, support during incidents, etc.
I find a much better approach is to figure out how to enable the business with security. What does this mean? It means working with the non-security teams to put processes, people or technology in the right places so they are minimally invasive, while achieving the security objectives.
Example – Architectural Review Process:
Several years ago my team was responsible for reviewing new architectures for security issues before they went into production. This was a very lightweight process with two phases – a conceptual review (does this make sense) and then a more detailed post production review (did you do what you said you were going to do). In order to achieve the results of managing or reducing risk appropriately my team ended up acting in a consulting role to work alongside the other teams to help improve their security as part of the Architectural Review Process. We even eventually automated several of the compliance checks and scans to shorten the feedback loop and allow teams to self service as they were building their new thing. The end result was the security team built trust with the rest of the business and we ultimately reduced risk. If, instead, my team told the non-security teams NO every time they submitted something that wasn’t up to security standards, they probably would have just deployed to production anyway without meeting our security requirements and this would have put the company at significant risk.
Don’t Confuse Accountability With Ownership
If you have ever read Extreme Ownership by Jocko Willink then you are familiar with the concept that good leaders should take ownership for everything in their world. In the case of security this would mean the security function should be responsible for patching, hardening, scanning, etc. of everything in the company. Yet, I argue this is not only impossible, but the wrong approach.
Why is this impossible?
The team building the product or service needs to be responsible for the security of that service. If you aren’t the team building the product or service then you may not have the right permissions, you may not understand the code and you may not even know it exists.
Why is it the wrong approach?
Asking another team, other than the one who produced the product, to be responsible for patching, hardening, scanning, etc. of a product or service, passes the responsibility and accountability for security away from the team that actually owns the product or service, which means the original team will have zero incentive to develop a product or service that meets the appropriate security requirements.
As a CSO/CISO you are accountable for the security posture of the company, yet the security function doesn’t actually own the products or services that the company sells to customers. The teams who build the products or services are responsible for patching them, scanning them and fixing the security issues that are discovered in them. The non-security leaders over these teams need to hold their teams accountable for meeting the appropriate security requirements and the CSO/CISO needs to hold these leaders accountable (with things like dashboards, scan results, etc.).
Don’t Underestimate The Human Factor
When beginning a new security leadership position it is usually easy to identify the technological solution to a problem. Need more visibility? Improve logging and alerting. Need to know who owns something? Improve asset inventory. Need to shorten the vulnerability window? Improve patching. However, it is often extremely difficult to diagnose and understand the behavior of the humans who are behind the security problem you are dealing with.
Technology is easy, humans are complex
I often say this to my team to remind them that people are the most valuable asset for a company, but are also the most challenging. It also reminds them to not jump to a technological solution. Spend time talking to people to understand how and why they the things they do so you and your team can develop ways for them to achieve your security goals as quickly and easily as possible.
Changing patterns or behavior within a company or group takes time and is difficult. Humans will do what is easy, what is habit or both, often at the expense of security. Make small changes to processes or technology to gradually nudge teams into compliance.
I hope this helps you avoid these pitfalls so you and your team can be successful in achieving your security objectives via cultural change. Up next – Cultural Change Agent – Part 2 What Does Work?.
370 Security Blog 