Here at Automation Theory, we advocate for keeping Automate’s MySQL database patched for typical security/performance/stability reasons. However, we’ve recently seen clients purchase our MySQL maintenance packages for cyber insurance reasons — a trend we hadn’t seen before. One client explained that his insurance carrier added a clause that claims wouldn’t be covered if the software wasn’t patched in the event of an incident. Curious about this, we contacted insurance broker Joseph Brunsman, aka Joe_cyber, for more information on MSP insurance and software patching.
Important note: We are neither insurance brokers nor legal advisors. The content below is for informational purposes only; we advise consulting with a qualified insurance broker for advice about your particular situation (such as our friends at Burnsman Advisory Group).
Background: Connectwise Automate DB Patching woes
Our conversation was specifically around the Automate database, although this principle would apply to other software and systems used by an MSP. Automate uses a MySQL database, and it’s rarely updated after implementation. There’s no current vendor guidance for patching it, and Oracle releases security patches for MySQL quarterly. The average instance of Automate runs on a version of MySQL that’s several years behind and has hundreds of known vulnerabilities. Against this backdrop, we examine the implications of software versions and technology E&O insurance.
Tricky insurance clauses
In our conversation, Joe mentioned three policy exclusion types that could be problematic for MSPs in the event of an insurance claim. Below, we’ll review the clauses and then explain how they might be used to avoid paying an insurance claim that involves the RMM (a ransomware attack would be a typical scenario).
Failure to Put Right
As explained by CyberInsureOne:
Failure to put right describes negligence on the part of an IT manager or business owner to correct known vulnerabilities that could lead to a cyberattack. Most cyber insurance policies will have a clause explaining that “failure to put right” is not covered. This assumes that you knew there was a problem in your infrastructure and failed to fix it. If a cyberattack or data breach occurs, it will not be paid for by your insurance company.
In a nutshell, knowing that a system needs updates but not installing them is a failure to put right — and it’s not covered by insurance in the event of a claim. While we hate to be the bearers of bad news, since MySQL releases are updated quarterly, there are likely vulnerabilities in most Automate stacks (and now you’re aware of it).
Legacy hardware/software
This line item is often in a “failure to meet standards” or “failure to maintain security” clause, but legacy hardware and software are typically not covered — and the language in these clauses is rather vague. While the legacy exclusion is expected, there’s an unfortunate knowledge gap among MSPs regarding MySQL versions. There’s no official vendor guidance for clients on MySQL version/security best practices — and Automate supported MySQL 5.5 for 3 years past its end-of-life date.
MySQL 5.7 reaches its end-of-life date on October 31, 2023 — so this will become a concern for many Automate partners again.
Gross negligence
IRMI defines gross negligence as: “the willful or reckless disregard to the duty of care and complete disregard for the safety and well-being of others.” This clause is important because of how it interacts with other standard contract terms (since it’s often an exclusion to a limitation of liability), and it can also be a coverage exclusion.
Gross negligence must be proved, and an expert witness would often be called in to do this. Joe mentioned that the witness would likely be similar to the most cynical and abrasive people on /r/msp (not to mention someone with unparalleled credentials). Such a witness would make a fool of any MSP trying to defend themselves for running an unpatched Automate environment.
Adding it all up: how insurance companies could skirt claim payment
Insurance companies are losing a lot of money in the MSP space, so scrutiny on claims is increasing. The worst-case scenario for an MSP would play out like this:
- The first step is for the insurance company to establish a nexus between the claim on the RMM and the unpatched database. This likely would take the form of “the RMM contained vulnerabilities” — the argument being that the MySQL database is part of the RMM.
- The next step would be spelling out that the vulnerability isn’t covered — either because the MSP knew about it and failed to put right, or because the unpatched/legacy software was excluded from the policy as a failure to meet standards or maintain security, or due to gross negligence.
- The insurance claim would be declined (or only partially declined), and the MSP would have a tough road ahead to recover from the incident.
- If the insurance company declined coverage due to gross negligence, it’s possible the MSP clients would consider litigating to recoup losses on the same grounds.
The particulars of this scenario depend on the exact nature of the terms in each insurance contract, so it’s critical for each MSP to review their insurance and determine if any vague language could pose an issue before a claim event occurs.
An ounce of prevention
The good news is that, for Automate, there’s an easy solution: keep your database patched. While it’s easy in theory, several nuances can complicate the process.
Here at Automation Theory, our MySQL Maintenance Packages make the process easy for MSPs. We monitor Oracle’s repositories and automatically get notified of new versions. We perform validation testing of the latest version of MySQL (and the connector software) and then automatically inform our clients that a new version is available and that it’s time to self-schedule an upgrade appointment (which we perform after hours). This removes the administrative burden from MSPs and provides the MSP with access to a certified MySQL DBA familiar with the Automate platform.
We hope this information has been helpful to you — please don’t hesitate to contact us with any MySQL patching-related questions!
