The New York State Department of Financial Services has launched its first enforcement action under its cybersecurity regulations, and it has major flaws.
The Regs
By way of reminder, the NYSDFS launched cybersecurity regulations for financial institutions in 2017. The fundamental requirement is that regulated entities must maintain a cybersecurity program. For the most part, the regs merely provide the broad contours: the program needs to include written policies, be based on risk assessments, designate persons responsible for its implementation, include employee training—pretty standard governance and compliance stuff.
What the regs do is less important than what they don't do. First, the regs generally don't micromanage what technical controls people have to use. Where there are exceptions, they prove the rule. For example, the original proposed regulation required financial institutions to encrypt all non-public data at rest without meaningful exception. But after the NYSDFS received substantial pushback against this uncompromising (and arrogant) requirement, it yielded to reason and gave businesses leeway to select compensating controls where encryption wasn't feasible. Second, the regs don't purport to judge a cybersecurity program's quality. They require, for example, a program "designed to" protect an entity's cybersecurity; they require written policies approved at a senior level, "reflecting" risk assessments, and "addressing" certain issues; they require a testing program "designed to" assess the security program's effectiveness; and so on. In other words, the requirements are largely about process. The regs don't say that any of these elements have to be "good", "adequate", or even "reasonable", and for good reason: the NYSDFS would have to define what "good", "adequate", and "reasonable" mean. And third, the regs don't demand perfection or expect financial institutions to guarantee that security incidents will never occur. There's some prefatory language in the introduction about financial institutions having systems that are "robust" and "sufficient", but that's it.
NYSDFS's Complaint
Now comes the first enforcement action. The NYSDFS alleges that First American, the biggest title insurer in the country, violated various parts of the cybersecurity regulation in relation to a vulnerability that allegedly exposed tens of millions of documents containing non-public information of consumers and other participants in the financial industry.
As a necessary part of its business, First American collects millions of documents involved in the purchase and sale of real estate, and it has to deliver these to title agents and buyers of property. It delivers these documents by sending those persons a link to the documents hosted on First American's website. The first problem was that, to view the documents, you didn't need any sort of credentials—you just needed the link. And the second problem was that the link contained a document identifier number, so even an idiot could change the number and get a different document than the one that First American meant to expose. In general, this process isn't supposed to give access to documents with non-public information, but apparently there were significant errors in the way that documents were classified, so non-public information made its way into this system.
It's unclear whether the documents were actually accessed by any malicious actors; the NYSDFS and First American dispute the extent to which the documents were accessed and by whom. First American discovered the vulnerability after it had existed for several years, and only fixed it after it was brought to light by a prominent cybersecurity researcher and journalist. And so, the NYSDFS claims, First American violated the cybersecurity regulations.
My Complaint
The NYSDFS's administrative complaint paints a grisly picture, but that doesn't mean the complaint's legally sound. I have four main gripes with it:
Quality
To my eye, the NYSDFS's complaint doesn't contain a single factual allegation that First American actually failed to do anything required by the regs. Instead, the complaint alleges that the various elements of First American's cybersecurity program were flawed or inadequate. In effect, the NYSDFS is assuming that the regs contain some kind of quality standard that just isn't there.
Charge I: "Respondent failed to perform risk assessments for data stored or transmitted within its Information Systems, specifically the FAST and EaglePro applications, despite those applications’ transmission and storage of NPI [non-public information]." Maybe there's more here than what we can see in the complaint, but the complaint actually suggests the opposite. It suggests that there were security controls for non-public information and that there were efforts to detect vulnerabilities in these systems. (Penetration testing did ultimately detect the vulnerability.) Maybe the controls turned out to be flawed, but that doesn't mean they were absent.
Charge II: "Respondent failed to maintain and implement data governance and classification policies for NPI suitable to its business model and associated risks." But the regs don't impose a "suitability" standard. As discussed above, the NYSDFS didn't make the effort to define any quality standards.
Charge III: "The Vulnerability existed due to a lack of reasonable access controls." But the regs don't require "reasonable" access controls. Once again, the NYSDFS didn't make the effort to define any quality standards.
Charge IV: "The Risk Assessment was not sufficient to inform the design of the cybersecurity program as required by 23 NYCRR Part 500, as indicated not only by Respondent’s failure to identify where NPI was stored and transmitted through its Information Systems, but also its failure to identify the availability and effectiveness of controls to protect NPI and Information 18 Systems." I feel like a broken record. The regs don't impose a "sufficiency" standard, or any quality standards; the NYSDFS just didn't make the effort.
Charge V: "Respondent did not provide adequate data security training for Respondent’s employees and affiliated title agents responsible for identifying and uploading sensitive documents into the FAST system and in using the EaglePro system." Nope, there's no adequacy standard, either.
Maybe it's not unreasonable to expect financial institutions to meet some kind of quality standard, but as a regulator, you need to define that standard, and at the very least, you need to say that you're imposing a quality standard. The NYSDFS did neither.
Res Ipsa Loquitur
Even if there were a quality element in the regs, the NYSDFS's complaint often fails to demonstrate that First American fell short of it. Instead, the complaint relies on a common shortcut found in cybersecurity complaints: that any sort of data compromise indicates a flaw in the systems meant to prevent it. It's the res ipsa loquitur fallacy.
For example: One of the alleged problems was that First American didn't think that the web-facing application contained documents with non-public information. It relied on real estate agents and others to mark documents that contained non-public information, and then it instructed users not to make those accessible using the web-facing application. But these processes were manual, which meant they were subject to error, and allegedly a lot of errors.
Nonetheless, the NYSDFS makes not one, but two, unfounded leaps. First, it concludes that "Respondent’s classification of EaglePro as an application that did not contain or transmit NPI was incorrect given that EaglePro could and did allow access to documents containing NPI." Well, hold on: almost any application can contain non-public information if there are errors in the way that information is classified. Junk in, junk out. That doesn't mean it's wrong to classify an application as being meant to exclude non-public information. Second, the complaint concludes that the mis-classification of an application reflects a flaw in the classification policy itself. In other words, if someone misapplies a policy, it's the policy's fault.
All in all, the complaint's Charge II is this: People widely screwed up marking documents as private. That means the company failed to classify an application as containing non-public information. And that means that the company violated the requirement to have a written policy or procedure addressing data classification. The logic just doesn't flow.
Encryption
Res ipsa loquitur isn't the only common cybersecurity fallacy in the complaint. There's also the fallacy that encryption is an end in itself. The NYSDFS complaint charges First American with failing to encrypt the images containing non-public information. (Charge VI.) Nevermind that the regs don't categorically demand encryption. The more astounding part of the NYSDFS's claim is that it concedes that encryption wouldn't have mattered here. The problem was not that someone intercepted messages they shouldn't have or that someone hacked a system and stole a file. The problem was that documents were mis-classified and put onto a system that wasn't meant for non-public information. Simple as that.
Penalty
Finally, there's a problem that's not visible in the complaint itself but swirling around nonetheless. In its press release accompanying the charges, the NYSDFS states that: "Any violation of Section 408 with respect to a financial product or service, which includes title insurance, carries penalties of up to $1,000 per violation. DFS alleges that each instance of Nonpublic Information encompassed within the charges constitutes a separate violation carrying up to $1,000 in penalties per violation." (I don't actually see this allegation in the complaint, but whatever.)
Lawmakers and regulators haven't developed a sensible way of measuring or penalizing cybersecurity and privacy violations. The measurements tend to be one-dimensional: it's about the number of people whose data was involved, or maybe the number of data records involved. That's why you always see sensationalist headlines like "biggest data breach ever" or "2.3 zillion people affected" or some such nonsense. But there's a second, usually overlooked dimension: how much data was in each record? Was it just one or two data elements for each person, or a full dossier? And after that, there's a third dimension, which is hard to measure but nonetheless critical: how sensitive is the data? (Even once you have a meaningful measurement of the breach, there are all sort of other factors like culpability that need to be considered.)
The NYSDFS alleges that the exposed data included data elements that most people would regard as sensitive, such as social security numbers. (Although I've often wondered whether social security numbers are really sensitive anymore.) But there's a big dispute about how often the exposed documents contained non-public information, how much there was in those documents, and how sensitive it was. Before those critical dimensions of this exposure are measured, it's premature to jump to conclusions about the size of the violation and it's way too early to get sensationalist about penalties.
