How Secure is Secure Enough?

This post was guest authored by Neil Bahadur.

Deciding how much security is “enough” is more practical and much less academic than it seems on the surface. It’s not about the technology or the environment's vulnerabilities, the latest, most obscure hacks, the ratings from tools, or even normalized vulnerability scores.

Qualys recently cited this staggering statistic “25,228 KNOWN vulnerabilities, how many were actually exploited? Less than 1%”

While it is fun and exciting to think in terms of attack and defense as we do during threat models and adversarial emulation, we also have to weigh a broader set of factors:

• What must be done by mandate? What happens if it isn’t? Are all consequences equal?
• What is the real impact of something being exploited on the business overall?
• What is the impact of the control/fix /etc. to the business overall?

While detailed, thoughtful technical evaluations play a part in robust threat models, penetration tests, and other security assessments, many decision-makers outside of security seldom are looking for more than a green light for their project.

And sometimes, they aren’t even looking for a green light. Sometimes that's because they're nervous to ask, or they don't trust that security is going to be a good partner.

For example, if fixing the issue is $5M, and the fine for not fixing it is $1M, and an exploit would cost $100M but is 0.001% likely, then a lot of risk and app owners may just decide to pay the fine if and when it comes.

Of course, this is somewhat oversimplified, but security is an important thing and often not the most important thing. There are plenty of caveats here for places where security is the most important thing (or significantly important to the mission), but this is generally also reflected in the business goals. That decision is more likely to be made by a CEO than a CISO.

The CISO informs the business owner of the risk.

The business owner ultimately decides what to do.

So what is an effective CISO? It's when you make it easy for your business owners to understand the risk in their terms and context rather than yours.

The CISO could always hand over a list of 20 findings, with write-ups like: “A user could gain access to XYZ resource by exploiting ABC app finding with High likelihood based on the public availability of exploit 52” And sure, these include all sorts of wonderful “executive summaries” that recap methodology, high-level findings, maybe some caveats…

And then layer that on with a report with some threat intelligence information from another team. Then some technical information around some monitoring results from another team.

Sure, with the right technical details and enough time, the biz owner (with some SMEs) could get to the bottom of what to do and ultimately make a choice.

But, you may find that speaking the audience’s language gets better results for them in quality of decision and in speed. You can be the translator to make it easier for the business to make the right choice vs. giving them triaged, high quality data but still expecting them to understand the context the way you do and really make the best choice.

Demonstrating you understand:

• Business owner risk threshold
• Prioritization of business drivers
• How to put the risk into context

This process can help you turn technical findings into a defensible position on how much security is enough for your unique context. You may or may not want a business to even go through the trouble of fixing everything just to be “hardened” (even if policy mandates this). Adjust your approach to keep the emphasis on how to let the business do its job effectively while you do your job effectively.

Said another way, do you think it’s easier for you to learn a bit about how the business functions and what it cares about, or for a business owner with goals to quickly get up to speed on security data, technical details, risk context, etc. and make a qualified choice?

You may not always get it right on the first try, but negotiating in business terms is a lot easier than dealing with a line of angry developers yelling at your tools, reports, alerts, etc., out of context.

Be a good translator.

Speak security like a human.

CHATGPT treated version:


Title: Deciding on "Enough" Security: Balancing Technical and Business Drivers

In the world of cybersecurity, the question of how much security is "enough" can be a difficult one to answer. It's not just a matter of identifying vulnerabilities or the latest hacks, nor is it about relying solely on tools or normalized vulnerability scores. Good practitioners understand that there are a multitude of factors to consider, including technical and business drivers.

While detailed technical evaluations certainly play a role in threat models, penetration tests, and other security assessments, decision-makers outside of security are often looking for a simple "green light." This means that effective communication is key to ensuring that security risks are conveyed in terms that are meaningful to business owners.

To strike a balance between technical and business drivers, practitioners must consider a variety of factors. These include:

• What must be done by mandate? What happens if it isn't? Are all consequences equal?
• What is the real impact of a security breach to the business overall?
• What is the impact of implementing a control/fix to the business overall?

Ultimately, it is the business owner who decides what level of risk they are willing to accept. The role of the CISO is to inform the business owner of the risks and help them make informed decisions.

To be an effective CISO, it is important to make it easy for the business owner to understand the risks in their terms rather than in technical jargon. This means being a good translator and speaking security like a human. One approach could be to present a handful of actionable findings and recommend specific actions, while also demonstrating an understanding of the business owner's risk threshold and the prioritization of business drivers.

For example, instead of presenting a long list of technical findings, a CISO could say, "There are a handful of things here that I think are not worth fixing before release. It’s worth investing $2k for a temporary fix to allow us to avoid a $200k delay for a major release. We would need a policy exception, and you’d need to delay one feature sprint for the next minor release."

By taking technical findings and turning them into a defensible position on how much security is "enough" in a way that emphasizes how to let the business do its job effectively, practitioners can help prevent misunderstandings and promote effective collaboration. While it may take some negotiation and compromise, speaking the audience's language and prioritizing business drivers can lead to better results in the long run.