NY DFS Strikes Again on Cyber

A vision insurance company based in Ohio has agreed to pay a $4.5 million penalty to regulators in New York, to settle charges that the company’s poor cybersecurity practices led to a data breach in 2020. It’s a small but informative case for all you and privacy compliance enthusiasts out there. 

The company in question is EyeMed Vision Care, which provides employer-based vision insurance plans to some 55 million people across the United States. Because EyeMed sells insurance in New York, that makes the company subject to the New York Department of Financial Services — which is the regulator that enforces the New York Cybersecurity Regulation, formally known as NYCRR Part 500.

So what happened? According to a statement from the New York DFS, EyeMed suffered a breach in June 2020 thanks to a poor risk assessment and a failure to use multi-factor authentication (MFA) at a key point in EyeMed’s IT systems. Those failures allowed an attacker to access a shared EyeMed email mailbox which contained more than six years’ worth of customers’ personal data, including the data of minors.

Yes, EyeMed did discover the breach quickly, and then notified the DFS and harmed customers three months later. DFS also praised EyeMed for “commendable cooperation” and extensive remediation to fix its security shortcomings. 

Still, DFS also said, EyeMed had certified its compliance with NYCRR 500 for four years running in the late 2010s, when in fact the company hadn’t done a thorough risk assessment nor implemented multi-factor authentication where necessary. 

That meant that EyeMed’s compliance certifications were false, and here we are one $4.5 million penalty (plus more money in investigation, remediation, and legal costs) later. EyeMed will also need to complete a rigorous risk assessment by next spring, with an action plan for necessary improvements submitted to DFS 60 days later.

For anyone subject to DFS jurisdiction (which is most businesses that sell financial products in the United States), the case is worth a close read, because clearly DFS takes a strict attitude to cybersecurity failures. So let’s take a look at what happened.

Nine Employees, One Email Address

As described in the DFS consent order, the attacker struck EyeMed on June 24, 2020. Somehow that attacker gained unauthorized access to a shared email account that nine EyeMed employees used. The company isn’t sure exactly how the attacker gained access — but when nine people share one account, it’s a safe bet that the user ID and password for that shared account are fairly easy to remember. 

Once the attacker gained access to the shared account, he could view emails and attachments that contained the personal data of EyeMed customers, going as far back as 2014. The attacker also had the ability to export all that personal data to destinations somewhere out on the interwebs. 

First failure: At the time of the attack in 2020, EyeMed hadn’t fully implemented multi-factor authentication, even though NYCRR Part 500 (1) went into effect in 2018; and (2) expressly requires that any user trying to access a company’s network from off-site should be challenged with a multi-factor authentication request. 

EyeMed had begun migrating its email systems to Microsoft Office365, which does allow a company to configure MFA quickly — but EyeMed had only begun that migration in March 2020, and the nine-person shared email account (ugh, I wince just writing that phrase) hadn’t been covered when the attack struck. Plus, implementing an IT solution in 2020 for a compliance requirement that went into effect in 2018 is still, ya know, a bad look.

Second failure: DFS also skewered EyeMed for inadequate risk assessments. Yes, EyeMed did hire outside consultants to conduct periodic risk assessments as required by Part 500; but no, “none of the assessments performed by EyeMed’s vendors addressed the risks associated with the non-public information” stored in that nine-person shared email account. (Ugh, wincing again.)

The issues here are two. First, storing personal customer data in an email drive is just really, really bad practice. Either secure the data in some sort of restricted database, or implement strong data destruction protocols so the data isn’t just sitting there in your Sent or Trash folders for anyone to see. 

Second, a single email address shared by nine people — it was used to process enrollment requests; and yes I’m still wincing — is an even worse idea. As we mentioned before, you’ll typically need a simple user ID and password that many people can remember. That leaves the email account vulnerable to a brute force attack, plus the usual tactics of phishing or buying stolen access credentials on the dark web.

Cyber Compliance Lessons

The obvious lesson is that a company should strive for the most thorough risk assessment possible, because a poor risk assessment is the trap that saddles you with a legal violation. Whatever mistakes you let linger for years, you’re also certifying compliance during those same years — and that’s the opening that DFS can use to drive an enforcement action.

Another point, however, is that this is where a cybersecurity audit would be mighty useful; it could identify gaps such as failure to implement MFA at proper places, or weak data destruction policies that heighten your privacy risks unnecessarily.

To be clear, NYCRR Part 500 doesn’t expressly require an audit; it only requires that financial firms design systems that create an audit trail, which is not the same thing. But if you’re handling lots of consumer data (as many financial companies do), then you’re probably subject to some other regulation that requires an audit anyway, like the PCI DSS standard for credit card information. So regardless of Part 500’s specifics, regular cybersecurity audits would be a wise preventative measure to keep DFS away.

I’d also stress that this is the second cybersecurity enforcement action we’ve seen from DFS recently where lack of multi-factor authentication played a starring role. The agency fined Carnival Corp. $5 million back in June for security several failures, MFA gone MIA being one of them. 

Moreover, the Consumer Financial Protection Bureau published a cybersecurity bulletin in August, where it named multi-factor authentication and strong password management as two cybersecurity practices the agency expects to see financial firms embrace, if those firms want even the faintest hope of avoiding civil liability for privacy breaches. 

So we have numerous regulators taking a strict stance on cybersecurity, and especially on block-and-tackle basics like MFA and password management. Companies would do well to absorb that message and start blocking and tackling.