You’re patched, but are you insured? Check your cyber insurance policy

Have you checked your cyber insurance policy lately? I’m talking here to those of you readers who administer Windows client and server systems. And I’m talking especially to those of you who are responsible for ensuring your company’s systems are up to date with all of the critical updates, security updates, cumulative updates, optional updates, hotfixes, and other updates that stream out of Redmond these days like water from a firehose.

I’m asking this in particular because I heard recently that a Windows admin dusted off a copy of his organization’s cyber insurance policy recently. And he was worried about what he found concerning what their policy said about patch management.

Besides the usual boilerplate language of “document this” and “document that” regarding their company’s internal IT processes, the policy also contained a few unambiguous statements similar to the following:

“All servers and workstations owned by [org] must have up-to-date patches installed in order to safeguard them against known vulnerabilities.”

“All servers and workstations must have Automatic Updates enabled so that patches are applied once they have been approved by administrators.”

“All patches must be tested prior to deployment on the production environment. A fully isolated separate test environment must be used for this purpose.”

“Installation of all patches must be documented so systems can be rebuilt in an emergency by reinstalling patches in their proper order.”

There were a number of other stated requirements regarding patch management in the company’s cyber insurance policy, but let’s focus on some possible issues concerning the ones listed above.

Cyber insurance problem #1: Must have up-to-date patches installed

Here we have a simple language problem, namely, what exactly does the insurer (policy provider) mean by the phrase “up-to-date patches”? Does the language here mean that the insured (your company or organization) is required by the policy to install patches on the date they are released? Probably not, since a different statement in the policy says you’re also required to test all patches before you apply them, and testing can obviously take some time to perform properly, depending upon the scale and complexity of your infrastructure.

Still, there remains the issue of what the ambiguous term “up to date” means in this context. If you delay applying a cumulative update (CU) two weeks, does this mean the Windows system isn’t up to date with patches? Or three weeks? A month? When does a Windows system qualify as being not “up to date” with patches?

And what about a standalone Windows PC running an industrial or medical tool. Such systems are often not connected to the Internet, and if they’re working properly then you’re probably not going to want to patch it in case the patch breaks something and you can’t use your tool. That’s certainly an exception case that must be handled, and even if you don’t currently have a system like this in your environment, your policy should include a statement concerning such exceptions.

Problem #2: Must have Automatic Updates enabled

Must have? What if I have a small portion of my network where I patch certain machines manually? Like business-critical servers for example. Some admins like to follow this approach to avoid the (unfortunately increasingly common) situation where a patch causes more problems than it is designed to fix. The last half of 2018, for example, saw a number of cases where software updates released by Microsoft caused numerous problems for those of us who are responsible for patching Windows server and client systems. So clearly there needs to be something included about possible exceptions to this policy statement, or a change in how the statement is worded.

Problem #3: Must be tested…in a fully isolated separate test environment

OK, let’s get serious here: Who really has time to maintain a proper test environment — for example one that mirrors the key elements of your production environment and is always up and running — and perform a full and comprehensive range of tests concerning the potential effects of applying a patch? Who has the resources to do that kind of thing? Small businesses certainly don’t, and mid-sized ones also probably can’t handle it. Only large enterprises that have money to burn can take this kind of absolute stance with regard to patch testing, and those are few and far between nowadays.

Sure, you can use a virtual test environment and employ checkpoints and snapshots and so on to keep things simple and cheap. But practically speaking most businesses and organizations can’t afford to carefully test any but those patches that are going to be installed on their mission-critical servers.

For testing patches on client systems, you might want to follow a different approach like the one that was suggested to me by a colleague who administers 300 seats for a midsized business. Her approach is to assemble a small group of enthusiastic and somewhat technically-savvy users and make them a “pilot group” for patching Windows PCs. New software updates from Microsoft are deployed first on the PCs of these pilot users, and if anything goes wrong they notify the admin who rolls the patches back and investigates the issue further. If no problems arise however with this group in say, seven days, then the patches are rolled out to all the PCs on the network. I find this a good approach to follow for small- and midsized businesses, but just make sure your insurance provider understands what you’re doing and the rationale behind it — and that the language of your cyber insurance policy confirms that they understand it and accept it for your environment.

Problem #4: Must be documented…in their proper order

Here once again appearances run straight into reality. Because of how Microsoft now releases most monthly patches in the form of cumulative updates (CUs), when you rebuild a system from scratch you don’t need to apply all of the patches you previously installed on the failed system, all in the same order as before. Then there’s the matter of patches that are pulled by Microsoft because of problems with them. These may later be released under the same KB designation or under a different KB. Really, this idea of documenting every patch installed on every system is just a time-waster, and when you’re negotiating (or renegotiating) your cyber insurance you should strive to remove such language and requirements from your policy.

Check your cyber insurance policy — now!

Based on our discussion of possible problems that could arise from non-compliance — either intended or unintended — either real or apparent — by your organization with the stated requirements for patch management found in your company’s cyber insurance policy, it’s probably a good idea to review what your policy says concerning patch management. Look for any language you may feel is ambiguous or requirements that need clearly defined exceptions articulated. Then contact the insurance company that covers your cybersecurity needs and ask them to clarify — in writing — patching issues you feel should be defined and expressed more clearly. Because remember, when something unexpected and bad happens and you need to file a claim with an insurance company, their granting or refusal of the claim will ultimately depend on only one thing: the exact wording of your policy.

Featured image: Shutterstock