Cybersecurity is all about relationships
As of writing this, a colleague I hold dear announced that she was leaving the company for personal reasons. The news saddened me. I don’t believe in company loyalty. I believe we are loyal to the people around us.
Such sadness remains inevitable. Everybody switches jobs fast these days. So why bother building these ephemeral relationships, and allow myself to let them evolve into friendships?
I believe that a successful information security analyst needs to be wired with such openness. Establishing rapport with your collaborators is the only way to achieve organizational progress.
No, that doesn’t mean to be friends with everybody. Sometimes, things click, and you discover you share similar hobbies, thought patterns, or world views, and the relationships transcend into friendships; often, they don’t. But that does mean most of your day-to-day work is about understanding people, their goals, and their motivations.
What does this “need for relationships” mean in real life? And how are they necessary for success? Read on.
You can't do it all
"Just give me the Domain Admin creds and I'll take care of the problem!" This rant is my most common frustration during my one-on-one with my manager.
Of course, this is me being emotional and stupid. From the outside, it's easy to ignore all the details that make other teams seem slower. Truth is, I'm no smarter than any of the administrators out there.
Another way to look at the problem is that no single person can take care of all IT systems. I'll go farther. No security team can maintain all the information systems in an organization.
The only solution is to ensure that the teams that operate these systems consider security.
Yes, security should be a default part of anyone's duties. I often say I shouldn't exist. The nature of software makes security too easy to overlook. Too many unpredictable inputs, too easy to build fast, too much chaos...
There are not enough carrots and sticks anyways
For the past few years, I have been leading the community of security champions at work. I adopted a "carrot" approach: praising the good behaviours and hyping the small successes that often go unnoticed. Despite my enthusiasm, engagement metrics stagnate.
The stick approach is worse. Ask any security analyst who has ever tried slowing down a development team's sprint to address vulnerabilities SLAs. In most industries, such a hard line is untenable.
What remains is the risk-based approach and a great deal of opportunism.
Many changes I have been able to push for have been due to being involved at the right moment by the right person in a project. That individual could have woken up one day and thought to involve security due to some obscure process... But our odds are much higher if we have visibility and relationships.
It's easy to be avoidable
One of the best comments I've had was a random ticket we've received about a Java Development Kit version. I wasn't sure what was asked of me, and the engineer replied: "You guys always seem to have good ideas, so I figured we'd ask about recommendations."
Relationships in a security setting are all about understanding people's problems, identifying the tradeoffs, and pointing to the "secure path".
This also applies to more focused roles such as pentesting or security operations. Do you want these vulnerabilities fixed? Do you want to stop the bad alarms at the source? Are the people behind the systems aware of your existence?
And when I mean "your existence", I am talking about you, as an individual; not about this intangible thing called "security". Humans work better when they can put a face on things.
This is where I bring back my consultant horror story. This man needed to implement a cross-departmental process. His interventions were so irrelevant that the topic between managers was: "How to make sure he never speaks to me again". He got the process signed by every party. But the paper was worthless.
Relevance matters. I'll give you an example. When a new director gets hired, did you ever think about reaching out to explain access management procedures and discuss the profiles you could build for their team? I did that once for a BI architect and he wound up calling me "the guy that opens doors" in front of about 30 people. I hated the moniker but was grateful he consulted me when he was investigating cloud solutions for his data needs.
So how about you, how do you build relationships?
If you like my content, subscribe to the newsletter with the form below.
Cheers,
Pierre-Paul