In Part 1 of this post I discussed how security teams are often challenged to change behavior and ultimately culture. This is an exceptionally difficult problem and I covered a few things that don’t work when trying to effect change. In this post I’ll discuss my observations for what does work when trying to change behavior to a security first mindset.
What Does Work?
Assume Good Intent And Be A Patient Teacher
This one speaks to mindset. When coaching my team I often find they are frustrated with another group unnecessarily. When diving into the problem there is usually a lot of blaming and an us vs. them attitude. There is also an underlying assumption that the team is not doing something because they don’t want to.
Instead, I coach my team to adjust their perspective and lead with empathy. It is exceptionally rare that a team flat out refuses to do something security related. Instead, I find a team wants to do the thing, but just doesn’t know how. Changing your mindset from a negative one (they aren’t doing it) to a positive one (they want to do it, but don’t know how) changes the entire dynamic of the conversation with the other team. Practicing empathy, and ultimately patience, with other teams by coaching them to the outcome you want is far more effective than blaming them for failing to comply.
Make Security Easy (Without Compromising Effectiveness)
I touched on this briefly in Part 1, but I’ll say it again here because it is worth repeating. Humans will take the easy path, follow habit or both. Security teams need to find solutions that make security easy, without compromising effectiveness.
A good example is patching. Make it easy for teams by publishing hardened, up to date images, containers, etc. that they can pull and use for their products / services. Take the burden off of them to have to patch an OS by providing them with a patched version up front. (Yes there is a lot of nuance to this. I’ll discuss this more in a later post).
Enlist Allies
Enlisting allies on other teams can really help accelerate your security goals. Teams within IT, the CTO group and even senior engineers can help get momentum behind key initiatives and act as an extension of the security team.
- Early Adopters – New processes and technologies always have issues. Having a team of early adopters outside the security function helps iron out the bugs before trying to get the entire organization to adopt it.
- Security Champions – In my current function we use our security allies to help champion initiatives or act as an extension of the security team. This is invaluable because it helps explain things in a way that is understood natively by the receiving team and it is delivered by someone within their own group. This can be particularly effective when one team is behind on something (like patching) and needs a little extra encouragement.
- Extended Vulnerability Response Team – During Log4j we found the security allies to be invaluable in responding to the vulnerability. They were able to take the new patches / fixes and translate that to their products or services. They were also able to come back with suggestions and improvements to processes to speed up remediation. By having key allies represent the engineering groups we were able to keep our War Room relatively small and relied on them to deliver marching orders to their teams so we could tackle the issue at scale.
Set The Example (Lead From The Front)
Sometimes teams need to see what good is before doing it themselves. The CSO / CISO and ultimately the security team should set the example for the type of behavior they want to see from the rest of the organization. This shouldn’t create an us vs. them or sense or superiority, but instead should act as an eat your own dog food type of exercise. If you are asking teams to patch things, then your team should follow the same processes. By participating in the very same processes you are asking the rest of the org to follow it creates accountability for your team to make sure those processes work appropriately.
Trust But Verify
Simple, but effective. Early in my current role I often had teams tell me one thing and I took their word for it. I did this because I simply didn’t have the staff to chase down every little thing and I assumed good intent. As my team matured and we developed better processes for collecting data, we found what people told us didn’t match up to reality. This wasn’t a case of malicious intent, but instead the reality of working in a large organization. Things change, people leave, nothing is static. One of my history professors used to say “the palest ink is better than the fondest memory.” This is true with security data. Talk to people, get their perspective and then go check it out to see if that is true. If it isn’t, then that is an area to focus on.
Like any skill, practice makes perfect. I often find when I am getting frustrated it is because I am slipping back into bad habits like failing to assume good intent or leading with empathy. A simple mindset shift usually snaps me out of it and I spend a large amount of my time reinforcing these principles across my team. I hope you find these skills useful and are able to put them to use in your organization to achieve cultural change.
370 Security Blog 