Enough Security - Part 3

Using Capital & FUD Raising

Time to finish up the code walk-through. In our last post, we ended with the concept of “best use of capital”.

What I am describing is the concept that the company should be investing its resources (capital) in the places where they reduce the likelihood that the # 1 risk will occur. If we go back to the minimum statement in the pseudo-code: Loop minimum ([Rate of Change Acceptance] or [Cash to execute]), this is saying that the company should spend the least amount possible to reduce the gap between what the customer expects and where the company is at today. This could be in the form of changes to processes (rate of change) and cash outlay. Choose the lesser because if you don’t, you are diverting capital from other initiatives that could be reducing the #1 risk (for example: launching a new product or expanding into a new geography and ensuring a ton of new sales). Security folks tend to be narrowly focused in their viewpoint and forget about the bigger picture. My advice to CISOs would be to understand your company’s strategic initiatives for the year, where it spends its money, and adjust your change versus cash decision to align to these.

So, what happens if you are spending more than your customers expect (after the ‘else’)? There are really two options here:

One: Convincing your customers (and the company) that more security is better. I will say – in my experience – this is a tough sell. Most customers don’t care (back to post 1 in the series) and the company is trying to optimize use of capital to ensure that risk #1 doesn’t occur (post 2 in the series). Can it be done? Sure. How? You can attempt to convince customers they need more security to feel safer. I call this “FUD raising” your budget. It works sometimes but, in my experience, has no staying power. At some point, it will self-correct, and you as the CISO might be part of that self-correction.

Two: Now if you can’t “FUD raise”, you are now faced with the stark reality of the code – Decrease [your security] = [customer expected security] . Danger: harsh words coming. You are part of the problem. If you have more security than is required to reduce the #1 risk to an acceptable level, you are performing a disservice to the organization as you are misusing capital, and therefore should reduce your spend. The reality of this situation is the same as above. It will correct itself at some point. Better you control this, rather than it be dictated to you.

Let me tell you a story that ties this all together:

I have a friend of mine who had a functioning security program that generally met customer expectations. They had [Customer Expectation] = [Security Delivery]. They were making good use of capital, and in my opinion spending “enough” on security. The company then had a pretty high-profile breach. Customer security expectations increased dramatically (note that customer expectations are not static). A gap now existed between expectation and delivery. The company attempted to correct, and during the incident, the CISO got a blank check. She spent a tremendous amount of cash on gear (as this was seen as the minimum versus corporate change). Fast-forward 3 years. Customer demand for security dropped during that period. She was unable to “FUD raise” and convince the customers that the increased security was worth the cost – so, as expected, her budget got reduced to reflect new customer expectations. She and the bulk of her team quit.

This is just one example of what I have seen in my travels across the globe. If you are a security executive, think about how this simple bit of code can help you set your strategy.

Thanks for tuning in. Oh wait, I nearly forgot something:

What is the proper response to the CTO group’s question – “How much security is enough?”

My original soundbite is a pretty good answer –

“The #1 risk to our business is not being in business. Enough security ensures that we stay in business.”

Stay safe

Marc