I’ve noticed in my career that we, security experts, often lose sight of what our organisations’ are trying to accomplish. Compliance heads will get entirely absorbed in controls, frameworks and audits, sending out proof requests faster than any team could handle. Tech heads would get tied up in knots whenever they saw an 8.2 CVSS vulnerability or 0.5%of their SIEM logs being dropped.
What are they doing? Why aren’t they helping me fix this?
They, meaning the other teams in your org, do not care (read this to learn more about why).
If these patterns are left unchecked, you’ll end up with fractures in your organisation, with an isolated security team working entirely by themselves, sporadically complaining to management that the other teams don’t cooperate.
Your security team walked themselves into the Ivory tower trap. That’s not a good thing.
# How to avoid the Ivory tower
# Don’t be dogmatic
At the beginning of my career, I fell victim to the Ivory tower mentality. Thankfully for me, my boss at the time set me straight.
Don’t be dogmatic.
He said that every time I would get frustrated that something wasn’t to my liking. At first, it was a tough pill to swallow, but it got me to work everyday on understanding my organisation.
As I started working closely with other teams, I came to appreciate that my coworkers were brilliant engineers, who were managing complex unwieldy systems. Bending these systems to my requests wasn’t easy, and often wasn’t a priority for them. They just did not have the incentive, or their management’s explicit instructions to handle the security team’s requests. In that organisation, I indeed had to drop my dogmatism, be more flexible and gain my coworkers trust to advance my goals.
# Have empathy
Empathy is necessary to defeating dogmatism.
You might aim to improve your organisation’s security posture. Other people in your organisation are trying to make it successful at its main objective, whatever that may be. It’s highly unlikely they’re sabotaging the org’s security on purpose.
So why are they doing it? I can’t tell you. You will need to figure it out on your own. You will need to go and have a chat with your coworkers, ask them about their day, about the difficulties they’re facing. Build rapport. Have empathy.
Doing so has 2 benefits: as you begin to understand people’s goals and struggles, you’ll be able to better formulate and time your requests; and since people now see you as a friend, they’ll be more likely to happily help out!
# Share your partners’ pain
Some people are more inclined to naturally have stronger empathy. Others not so much. Process Communication Model’s 6 personality types highlights that very well. Regardless of the dominant personality traits within your security team, the team as a unit must build that empathy, the understanding of others’ pain points. After all, you can’t secure what you don’t understand.
The best way to achieve that is to actually deal with the same problems as your partner teams. Go ahead and deploy a service to production, don’t pawn it all off on another team. Contribute to the code base. Write a design doc. Help out in product research. Actually do the things that make your organisation tick.
Security folks tend to forget that they are in the same boat as everyone else. When that happens, their recommendations instantly become inapplicable and thus useless.
Dealing with the mundane blockers other teams are navigating everyday will vaccinate you against the Ivory tower syndrome. And just like the COVID19 vaccine, you’ll need regular booster shots.
# Hire non-security people
You can’t secure what you don’t understand. You understand security, but do you understand your organisations’ systems? Yes, you’ve had a one hour architecture overview at some point in your onboarding, but that’s not enough. To steer clear of the Ivory tower, your team needs to really, properly understand the system.
So get an engineer on your team! No, not a security engineer, a regular engineer. It’s alright if they don’t know what a CVSS is; and if they don’t remember by heart every word of ISO/IEC 27001:2022 Annex A. Get an engineer who knows how the system works, how to fix it if it breaks, and who’s willing to learn more about security.
Their presence in your team will keep you grounded. At first, you will need to adapt your language and requests, so they can understand; that will make you more approachable to other people in the organisation. Their presence in the security team will also give your team more credibility to other engineering teams. You’re one of them now!
# Security is an enabling team
What you really want is a security team that enables others; A team that supports others in their work, guiding them onto the right path; A team that acts as the organisation’s therapists 😅.
Matthew Skelton and Manual Pais put it very well in Team Topologies. The security team is first and foremost an enabling team.
But it won’t be enabling much if it’s stuck up there, in the Ivory tower.