An Analogy about Failure

An Analogy about Failure

I was touching base with two of my team members* this morning about one of our customers, and as is so often the case, they brought up a topic which in turn sparked a passionate response that I decided to share with you, too.

The question was roughly along the lines of “how do we deal with this inane process” that some person in the organization “is insisting we must deal with?” In this case, it was a facilities person sending a ‘clean desk policy’ reminder to the entire goddamned company.

“What’s wrong with that,” you ask?

That is exactly when I launched into my little speech.

See, this kind of policy is SO two-thousand and five. Heck, I wrote plenty of security policies that included it myself. Back in the day when people actually had desks in actual friggin offices, it made sense. It was needed.

In today’s world, though, one must consider that a fair number of companies have extremely limited office presence, and many are run entirely using remote work forces. Even if you include this policy clause, you definitely should alter it so that it acknowledges this shift in reality. Perhaps add the leading words “For employees working at physical company locations,” and go from there. And then make extra sure that your emailed notices start with that part.

Why is that important?

Because the gravest danger to security in any company is operational fatigue. I’m not going to mince words here: if you do not understand this, then you do not belong in a security management or leadership position. And by operational fatigue I do not mean security people – you pay them to deal with it – but rather, everybody else. They all despise you by default, it’s kind of built into the job description. You make their lives harder. Because of what you do, you are perceived as arrogant, annoying, and unpleasant. And ultimately security depends on people, not systems.

So stop sending your people irrelevant “awareness” messages, already! You’re not helping anyone.

Anyway, I’ve written plenty on the topic, but it led me to the reason I am writing this column.

And so I introduced an analogy from the world of security in business transactions. Specifically, I highlighted another process happening at the same company right now, where they are undergoing a security evaluation by an enormous prospective enterprise client.

If you’ve ever done this, you know just how dumb the whole thing can be. Large enterprise CISOs often outsource this to third parties, and when they do, the third party – in this context, typically a big-4 consulting firm – ends up assigning very junior personnel to what is essentially a checkboxing exercise with zero security intelligence or value. The whole thing is fundamentally broken, and I urge you to read my analysis of it in the upcoming second edition of Why CISOs Fail.

Here is today’s fresh insight: this entire process exemplifies and highlights, in a way I never previously considered, how CISOs fail their businesses repeatedly by thinking of security through a technology lens.

What? How? Why?

Simple. Typically, the RFP process itself is a one-and-done deal. The CISO or one of their people crafts (or borrows) a lengthy list of questions. Because they see their job as oriented towards cyber controls and frameworks, they think of this as drudgery, but they do it because they see the long-term benefit of getting these annoying business buyers and lawyers out of their faces. So they compile the list, ship it to legal, and go back to the technology world where they feel comfortable.

Here is what happens next.

The questions become immortalized in business transactions. Forever. Every business buyer now has to send this to their vendors, and because it’s all outsourced to a third party who is getting paid for checking boxes rather than evaluating security, even the remote potential for nuance or context is removed.

Time passes.

The process remains the same.

And the questions go stale.

I mean, just look at any typical RFP process for any F500 – at this point in my career, I’ve had to personally address most of them – and you can see evidence of it everywhere. Easiest example to understand is network controls. So many SaaS and PaaS vendors today have no networks or physical IT assets under management; even if they do have an office location, it’s a congregation space, and they usually simply have a public WiFi access point to which everyone connects. It’s often supplied by the building. It’s a sort of coffee shop with free drinks and snacks and some cubicles.

But the questions? They still go very deeply into network controls. “Do you have a user proxy?” “Do you use split tunneling?” “Do you have VPN?” Uhh, no. I understand where you’re coming from, but it don’t work that way no more, champ. No network means no network controls. We do shit in access management; for example, have you noticed how multi-factor auth is on by default for everything and everyone at these vendors? They don’t have a choice. That’s their world, even if it looks different than yours.

Really, you don’t even need to ask.

But the process for getting through this stuff is annoying for all parties involved. It delays the transaction. It frustrates and infuriates both buyer and seller. The third party is happily cashing their checks, even while acknowledging during the review that it makes no sense at all to mark the lack of user proxy in a networkless environment as a “high vulnerability”.

Their job isn’t to question the questions.

You know who isn’t bothered by all this?

You guessed it. The CISO at the enterprise buyer. They or one of their predecessors did their job twenty years ago, and it has served them pretty well so far in terms of getting those annoying lawyers out of their faces. They do have more important things to do than actually supporting the business, after all. All those cyber controls aren’t going to take care of themselves…

But it provides us with a useful sense of hypocrisy. How so?

Well, just ask any of these security leaders what they think about leaving systems unpatched for twenty years (the analogy).

The thing is, the business process around third party risk management is arguably far more important to the business than software versions of OSS libraries. If that makes you queasy, then I hope you can accept it’s at least equally important. If you are going to maintain one, then you must maintain the other.

That means going through the list of questions at least annually and updating them to match the reality of the vendors you are (in theory) trying to assess, and insisting that the third party doing it understands and follows those nuances. Then your business will not have to go through a dumb process that takes a long time for no actual purpose and induces more operational fatigue. Your third party will cash smaller checks and create less delays in bringing key vendors onboard. Ultimately, you will reduce your company’s transaction costs and the actual risk associated with vendors will end up lower, because the remarkable side effect will be less checkboxing, more reality-based review.

And we all know that the less noise there is, the more likely we are to find something that matters. Right?

Right.

(*) So, you know, thank you, Alexis & Prabjit, for asking. It’s all your fault.

 

Related Posts
Leave a Reply

Your email address will not be published.Required fields are marked *