5 Horror stories about cybersecurity consultants (and how to avoid them)

I seldom get mad at work. When I lose it, it always seems to involve consultants. I remember one time. Have you ever had one of these "summit" meetings between managers of 3-4 departments? One of the tensest ones I've attended involved "the consultant question": from contracts to HR procedures to IT access management, to security compliance checks...

By a certain point, I got so fed up with everyone trying to avoid taking responsibility for consultants' management that I went full snark: "fuck it, the security guy's gonna take care of it all."

Do you know how the summit ended? No, I didn't take over consultant management. The parties agreed that we should look into a third party to manage administrative tasks related to consultants.

I kid you not. Consultants managing consultants.

The point is, while consultancy brings unquestionable business benefits, the practice also carries severe security risks, which people couldn't care less about.

This is why this week, I've chosen to tell you about some of my worst experiences with consulting services as a security analyst.

The superstar on the scoping call, then the clueless junior to deliver

I once heard that a consultant's job is to "win" contracts, not to deliver the work. This is cynical, but sometimes it does feel so. For example, this could mean that the most senior employees get assigned to the pre-sales cycle, while delivery is dispatched based on the account's overall value.

What I've seen in the security world was even scarier. Sometimes, the person assigned to the work will not even be an employee of the firm; call it subcontracting. You can therefore end up with a security consultant who did not even receive the knowledge transfer! This is how consultants end up fired...

What was the issue: it's one of the rare ones where I would lay most of the blame on consultants. Selling something and then underdelivering is what gives the profession a bad name.

How to fix it: make sure during scoping to know who will deliver the contract if it's not the main person you spoke to.

Consultants as key decision-makers

I remember this badass conference a senior security architect gave about the company's annual security plan in front of the whole company. The only problem? He was a consultant. Looking back, I don't even know how a security team can end up in such an awkward position. Consultants work best as trusted advisors and partners. They should not drive the show!

This becomes problematic on many levels. I've seen consultants agree on major deals for software purchasing. I used to have coffee with a brilliant consultant. In the end, when we were bickering about projects going awry, he always chuckled: "Anyway, I'll be out of here when the thing comes crashing down." He said it as a joke, but we both knew there was a sense of truth behind it.

Security is uniquely placed to suffer from a company that misuses consulting services. Remember, we are the department that gets fired if a threat actor gains access to our systems. Their favourite backdoor? Bad security systems!

What was the issue: Someone was put in a decision-making place despite having no skin in the game.

How to fix it: Seriously, don't do this. Internal employees must keep the spotlight.

Consultants as sole developers

If the thing stopped at bad security systems, it could remain tolerable. But sometimes departments will hire third parties to build whole systems. The issue? The project triangle. Time, money, and scope: you need all three to get quality.

Do you know where the projects with a collapsed triangle end up?

The bug bounty.

Imagine having a low-quality system delivered by consultants who have long left, maybe on bad terms (catastrophes tend to happen together). How do you fix vulnerabilities you find in there?

What was the issue: Thinking you knew what you wanted, asking for a firm out of their depth to deliver on an unrealistic timeline.

How to fix it: Make one of your internal team's individuals the owner of the solution. Gain a precise understanding of the business need, what your team cannot do, and scope precisely the work.

The consultant is always right

This is an anecdote I've heard from multiple sources. If you feel your risk assessments' message isn't getting through senior management, hire a consultant to tell the exact same thing.

When I was younger, the idea of spending tens of thousands of dollars on such an endeavour enraged me. Now, I understand why it works. Leadership assumes consultants have been around the block, seen the competition, and therefore bring better industry knowledge to put risks into perspective... which can (or should) be true!

I used to receive this as a knock on my competence. Now? It's just another tool.

What was the issue: Not explaining to internal employees that consultants are being used as a political measure.

How to fix it: Be transparent with your internal teams that consultants are a means to an end that involves them.

Consultants as labour

I'd call them permanent consultants. To me, consultants work best with a clear statement of work, in a time-constrained context: you need special expertise for something special.

The ordinary? That's for us, permanents. We're the ones playing the infinite game. We maintain things. We own it.

So what happens when an independent contractor just sits there like the rest? I understand how this allows a business to save on employee benefits and reduces labour law complexity. Yet, I can't help but feel a clash with the essence of security.

Some mundane security tasks require a degree of caring that, to me, is incompatible with what an independent worker brings to the table.

What was the issue: Hiring consultants without a clear understanding of their tasks

How to fix it: Define clearly the expectations, timeline, and work order.