Cybersecurity Secrets Unveiled for the Insurance World: Not All Vulnerabilities are Created Equally

By Stephen M. Soble

Note:  This is the first in a series of regular columns on topical issues relating to cybersecurity for the insurance industry, from Stephen M. Soble, a cybersecurity thought leader. His article, “Cyber Risk Beyond Compliance” was the cover story of our June 15 issue, and it has received wide acclaim. We hope you enjoy and benefit from Steve’s contributions.–SA


Whether it is the buzz over the WannaCry, Petya or NotPetya ransomware, Russian hackers, North Korean hackers or whatever today’s news headline about cybersecurity might hold, we constantly hear the word “vulnerability.” But, what is a cybersecurity vulnerability? And why should you even care?

Just when you think you know the meaning of this common English word, the digital world shifts the sands of perception and understanding. Let’s explore.

Not all Vulnerabilities are Created Equal

 In common usage, a vulnerability is a weakness, a corner of our emotional life susceptible to a minor hurt. People don’t die from vulnerabilities, save for the “death from a broken heart” predicament of a Jane Austen protagonist. Dying is reserved for disease, virus, and unforeseen calamity. But everyone suffers some hurt of the heart because of their personal vulnerabilities. And sometimes we even say that vulnerabilities—which can lead to injury—strengthens our character, improves our heart and is a necessary growing pain.

The kind of vulnerability which lives in the hardcore engineering cyber world, appears in many flavors:

  • Poor software development or coding practices
  • Defective or weak system design
  • Dangerous gaps in network connections
  • Ineffective or unsecured interaction of hardware and/or software on the network
  • Gaping holes in deployed software that can be readily exploited—some so wide open that a Mack truck without power steering can slip through the hole.

In software development, “vulnerabilities” typically mean a defect in the code that can be exploited by a hacker. There are many scanning tools that can detect these poor code defects. Some are very reliable. When we look at the network system and operations, the interaction of various devices on the network with one another, we might see vulnerabilities, too. But here the vulnerabilities are often characterized as gaps that create a pathway by which a network may be penetrated; a gap that may be so difficult to locate or so buried beneath other security devices that risk of loss is not measurably increased by the presence of such a gap. Apart from your security provider, who wants to spend more money to fill every gap? The mortar in brick houses gives rise to air gaps, and unless energy efficiency or another overriding concern arises, we don’t rush out to seal the mortar in order to feel good about eliminating the gaps.

The Real Problem is Holes

Vulnerabilities in software already deployed on your enterprise are an animal of a different color. Think of vulnerabilities in deployed software as holes in the bottom of a boat. You have three choices—repair and seal the hole, turn on the pumps to remove the water, or sink.

Vulnerabilities in deployed software are the genuine Achilles heel of our digital systems today—networks, computers, mobile devices, biometrics, even the Internet of Things (IoT). Why? Some 80% of the successful cyber-attacks (including WannaCry, Petya, NotPetya, the Russian hack on the DNC, and the North Korean hack against the Central Bank of Bangladesh) exploited known vulnerabilities in deployed software. Once the bad guys can look for the hole in the software operating on your system, find it, and exploit it, you are most likely in for a serious data breach, a ransomware attack or other malicious attack.[i]

The WannaCry and Petya attacks have demonstrated that systems which haven’t been patched (repaired and sealed) to close the hole (the vulnerability in the deployed software) are susceptible to rapid and devastating breaches by these attacks. Some companies do not have a solid program of patch management. Many software providers do not push their remediation patches out to their clients, but rather rely on their clients to take the initiative to download the patch from a repository and then take the responsibility to make sure the patch was properly deployed.

Defining liability for a data breach between the network operator (the insured, most likely under a cyber risk policy) and the software developer (another insurer, probably for E&O insurance) has been a donnybrook in the courts. Insurance policies and the stakeholders may talk past each other, each using the word, “vulnerability,” but each meaning something different from the other. In some of these cases, insurance companies have forced settlements, rather than create precedent which may result in a poorer result in the future.

Most cybersecurity companies like to sell pumps to pump out the water flooding through the hole in the bottom of a network’s boat. That way they have long-term clients who become dependent on them. Dependency and crisis management increase costs. Over time, larger and more powerful pumps are deployed because the network (ship) is taking on more water (exploited known vulnerabilities in the software deployed on their networks). It is a never-ending cycle.

Consider this:  several hundred new vulnerabilities are documented each week around the world. Keeping up is a problem.

 So, What Does This Mean for the Insurance Industry?

We have yet to see an insurance policy which clearly differentiates or properly defines—from a cybersecurity engineering perspective—which vulnerabilities are eligible for coverage and which are excluded. As we have seen, vulnerabilities exist on a spectrum ranging from weaknesses to defects in the structure (design or architecture of a system) to gaps, which may augur the need for monitoring, repair or even salutary neglect, to holes in the software which may need to be repaired and sealed to ward off the next global attack. Other milestones (definitional points) along the spectrum from weakness to holes probably exist.

Those responsible for claims, compliance, litigation and drafting of policies at the insurers/re-insurers level need to be cognizant of the variety of meanings and ramifications arising from the type of vulnerability referred to in the documentation. The insured may want to know what is and what is not covered with clarity. Brokers and agents may want to work with their best clients to reduce the client’s cyber risk, while providing the greatest coverage in a policy. Actuaries and analytics professionals need statistically correlative points of comparison in order to make proper judgments. Yet, if the insurance industry persists in the vague, imprecise use of the term vulnerabilities in the cyber world, the industry may lose control over its destiny with the most active new genre of insurance on the market—cyber risk insurance. Instead of controlling its destiny, the insurance industry may discover one day that a judge in some jurisdiction has resolved matters by defining vulnerabilities according to their own biases and criteria. Let’s hope the judge does not have a heartbroken teen at home. Court roulette is not a comforting game, especially when the stakes are so high.


[i]  The solution is deep software scanning, which is only available through one source.


About the Author:
Stephen M. Soble is Chairman and CEO of Assured Enterprises, Inc. 

More Information:
Cyber Risk Beyond Compliance
AssuredScanDKV® Deep Software Scanner