Security people are trained to find problems. It is, after all, their raison d'être.
Good security leaders also need to know when not to fix them.
That may sound counter-intuitive.
If there is a security risk, surely the obvious response is to remove it?
Sometimes.
But businesses do not exist to minimise risk. They exist to deliver products, serve customers, grow, make money and, occasionally, try something new.
All of those things involve risk.
The role of security is not to make that risk disappear.
It is to help the business understand it, make sensible choices and achieve the outcome it is trying to achieve without taking risks it cannot tolerate.
And occasionally, the most pragmatic recommendation is:
Accept it.
Start with the business objective
Security discussions can go wrong surprisingly early.
A vulnerability is found.
A control is missing.
An assessment produces a red box.
And the conversation immediately becomes:
“How do we fix it?”
I would normally start somewhere else.
What are we actually trying to achieve?
Perhaps the business needs to launch a product before a competitor.
Perhaps an important client needs a new capability.
Perhaps we are integrating an acquisition.
Perhaps a legacy system only has another six months to live.
Perhaps the objective is simply to reduce cost or remove an operational bottleneck.
The context matters.
A security recommendation that ignores the business objective may be technically correct and still be the wrong recommendation.
If I don't understand what the business is trying to achieve, I am unlikely to give particularly useful advice about how much risk it should take getting there.
Safest is not always best
There is nearly always a safer option.
We can add another control.
Another approval.
Another authentication step.
Another review.
Another product (more tools!).
Another process.
Keep going for long enough and eventually nobody can get any work done.
Clearly that isn't the objective either.
Take customer authentication.
We can generally make authentication stronger by adding more friction.
At some point, however, customers abandon transactions, support calls increase and the commercial benefit starts disappearing.
Or imagine that security identifies an issue three weeks before a major product launch.
Engineering can fix it properly.
The problem is that doing so moves the launch by two months.
That does not automatically mean:
“Delay the launch.”
The useful questions are more practical.
How exploitable is the issue?
What would actually happen if somebody exploited it?
What other protection is already in place?
Can we reduce the exposure another way?
How long would we carry the risk?
And what does delaying the launch cost the business?
Sometimes the answer will still be:
“Don't launch.”
There are risks where the likely consequence simply isn't acceptable.
But that conclusion should come from understanding the exposure and the business outcome, not because somebody's dashboard turned red.
The cost of fixing something matters too
Security people are usually quite good at explaining the cost of not fixing something.
We are sometimes rather less enthusiastic about discussing the cost of fixing it.
And I don't just mean the invoice.
A remediation might consume six engineers who would otherwise be improving the product.
It might delay entry into a new market.
It might make the architecture considerably more complicated.
It might introduce additional operational dependencies.
It might make the customer experience worse.
Or it might consume budget and management attention that could have addressed a considerably larger problem somewhere else.
Resources are finite.
Management attention is finite.
Engineering capacity is definitely finite.
So every security decision has an opportunity cost.
Imagine one issue requires £500,000 and six months of engineering effort to reduce an already modest exposure.
Another could materially disrupt a critical customer service and can be substantially reduced with two weeks of engineering work.
If we insist on treating both in the same way because they have both been labelled High, we have stopped managing risk.
We are managing labels.
Pragmatism means putting effort where it produces the greatest useful outcome.
Give the business choices
I have never particularly liked security being positioned as the department that says no.
Sometimes no is absolutely the correct answer.
But it shouldn't be the only tool available.
A much more useful conversation is:
“There is a risk here. This is what could happen. These are the realistic options, this is what each one costs, and this is what I recommend.”
That changes the relationship.
Security stops being an obstacle which the business needs to navigate around.
It becomes part of the decision.
Perhaps the ideal solution costs £200,000.
Perhaps an £18,000 compensating measure removes most of the practical exposure.
Perhaps we can restrict functionality for three months while the permanent fix is developed.
Perhaps we can alter the architecture.
Perhaps the customer can accept a slightly different process.
Perhaps the planned system replacement makes a major remediation programme rather pointless.
Or perhaps the remaining exposure is simply not significant enough to justify doing anything more.
There is rarely only one way of solving a security problem.
And occasionally the best answer is not to solve all of it.
Accepting risk is not ignoring risk
There is an important distinction.
“We haven't got around to fixing it” is not pragmatic risk acceptance.
Neither is:
“Nobody has exploited it yet.”
And leaving something on a backlog for three years in the hope that it quietly becomes somebody else's problem certainly isn't.
Accepting risk means understanding enough about it to make a conscious decision.
What could happen?
How serious would it be?
How plausible is it?
What alternatives do we have?
What are we giving up if we choose those alternatives?
Then somebody has to exercise judgement.
Sometimes that judgement will change later.
A relatively unimportant internal system becomes customer-facing.
A small product becomes commercially critical.
The threat changes.
A temporary solution becomes surprisingly permanent.
That happens rather more often than most of us would probably like.
Pragmatism therefore does not mean being casual about security.
It means being proportionate.
“Security is a business enabler”
It is one of those phrases our industry uses rather a lot.
I happen to agree with it.
Saying it is the easy bit.
Actually behaving like one is harder.
It means understanding revenue, customers, delivery deadlines and operational constraints.
It means recognising that commercial organisations deliberately take risk.
It means accepting that an imperfect solution can sometimes produce a better overall outcome.
And it means having sufficient credibility to say no when the consequence genuinely justifies it.
The objective is not the minimum possible level of security risk.
A company genuinely optimised for minimum risk probably wouldn't launch many products, enter many markets or innovate very much.
The objective is to help the organisation achieve what it is trying to achieve without taking risks it doesn't understand or cannot tolerate.
That is a rather different proposition.
Judgement matters
Tools help.
Frameworks help.
Metrics help.
None of them can make the business decision for you.
Eventually, somebody has to exercise judgement.
A good security leader should be able to distinguish between:
something that must be fixed;
something where reducing the exposure is enough;
something where there is a pragmatic workaround;
and something the business can reasonably live with.
If everything is critical, eventually nothing is.
And if every recommendation from security is “fix it regardless of cost”, the business will quite reasonably begin questioning the value of the advice.
Security leadership is not about winning every security argument.
It is about helping the business make better decisions.
Sometimes that means fixing the problem.
Sometimes it means reducing the exposure.
Sometimes it means finding another way to achieve the objective.
And occasionally it means saying:
“We understand the risk. The business benefit justifies it. I recommend we accept it.”
That is not security stepping away from the business decision.
It is security doing its job.
Personal commentary. Views are the author’s own.