What constitutes a “critical” security flaw?

Blog Post created by kevinbeaver on Jun 9, 2015

With security, like most areas of life, everything is relative. A security vulnerability uncovered by a security admin or penetration tester working for a company in the financial industry might be a big deal. The same security finding in, say, a manufacturing company might not mean anything at all. More technical people might see the situation as worse than a non-technical executive. Even different security vulnerability scanners rate their findings differently. It can be a frustrating reality in our field but it doesn’t have to derail our efforts.

You see, every situation is different. Each industry has its own needs. Every business has its own risk tolerance. Even the unique compliance regulations say slightly different things regarding what matters and what might not. The benefit we have as humans working in IT and security is our ability to reason. We can see the bigger picture. We can make judgment calls based on additional information and factors. We can simplify things and decide what’s best for the business as a whole, if we choose to do so.

Even though a vulnerability such as cross-site scripting, a missing patch, or (tongue-in-cheek) SNMP enabled with default community strings is deemed “critical” at first doesn’t mean that it really is in the context of your network environment. Ask yourself questions such as:

  • Is the vulnerability directly exploitable by an outside attacker?
  • Is the vulnerability directly exploitable by a trusted insider?
  • What’s the worst thing that can happen if the vulnerability is exploited? What data can be manipulated or breached? What systems can be taken offline? Which business units or people will be impacted?
  • What are the consequences of such an exploitation? Perhaps it’s an all-out breach you have on your hands. Perhaps it’s rebooting and patching systems. Maybe it’s nothing at all – at least that you can quantify using some good, old-fashioned common sense.


In the end, most security vulnerability findings are not "critical" but only you can determine what matters. It’s then up to you to convey what you believe to be of importance to the people who can help: your peers in IT and security, developers, and (especially) management. Certain security findings – whether or not they’re deemed “critical” by someone – may be no-brainers and super easy to resolve. Still others may have to work their way up the food chain whereby someone else has to make the decision regarding fixing it or accepting the risk. Then there’s that other group that are downright laughable and don’t matter at all.

Leaving things be and not addressing the quantifiable risks is an acceptable outcome, just make sure that you and other decision-makers know all the facts. Otherwise, you’re basing your judgments on others' generic opinions – often made by those who don’t understand your specific business needs. When there’s a breakdown in the analysis and communication of the things that matter is precisely when unnecessary effort and/or increased security risks are introduced.