This piece was originally published by Matt Kelly on Radical Compliance. Hyperproof is re-posting the article with the author’s permission.
I missed this until now, but several weeks ago the New York Department of Financial Services filed charges for the first time under that state’s cybersecurity regulations. We have a cornucopia of lessons to consider here about risk assessment, policy management, and more.
DFS filed charges against First American Title Insurance Co., for poor management of more than 800 million documents in the 2010s. That ultimately led to a data breach disclosed to the world in 2019, and DFS hit First American with charges on July 21 under NYCRR Part 500, the cybersecurity regulations adopted by New York in 2017.
You may already have heard about the breach. (So many breaches happen these days that I didn’t.) As outlined in DFS’ statement of charges, First American maintains a document database called FAST, which title agents and others can access through a custom-made application called EaglePro.
In late 2014, First American was doing an upgrade of EaglePro and introduced a vulnerability. The URL address for each web page shared via EaglePro contained a document ID number at the end, assigned to a specific document in the database. By typing a different ID number in the address bar of your web browser, a user could call up a different document — complete with all the personally identifiable information that a title agent had recorded on that document.
First American’s cybersecurity team discovered that vulnerability in December 2018. From there, the DFS allegations paint a damning picture of risks misunderstood, policies not followed, remediation not done, and leadership not exercised.
Those are corporate missteps any compliance or audit executive would want to avoid. In today’s world where data is the lifeblood of a company and privacy is fiercely regulated, they’re also missteps that any company might make. So let’s take a look.
You have to wonder how First American allowed this vulnerability to happen in the first place. That is, changing the URL of one webpage to pull up another page hasn’t been a novel form of attack for decades; these days even a child can figure out how to pull that stunt.
One could thwart that attack by, for example, adding an “expiration date” to each URL, or randomly generating a new URL every time someone tries to pull up a page. Those security tactics aren’t novel either; and yet, neither of them happened until First American added expiration dates in May 2019.
There were also flaws in tagging personal data. In April 2018, for example, the FAST database had 753 million documents, 65 million of them tagged as containing non-public information (NPI). NY DFS says a random sampling of 1,000 documents that weren’t tagged found that 30 percent of them in fact did contain NPI.
By May 2019, the FAST database had more than 850 million documents. You do the math.
And when First American’s cybersecurity people did discover the vulnerability, remediation wasn’t done in a timely manner because the severity of the problem was misclassified.
First, employees classified the problem as “medium severity,” because they were under the mistaken belief that the EaglePro app couldn’t transmit personal data. Even worse: when the cybersecurity team later entered the vulnerability into their tracking system, an employee accidentally logged it as “low severity” — which left the personal data hanging in the Internet breeze for many more months.
All of these missteps trace back to flawed risk assessment. Nobody evaluated the risks inherent in that flawed URL structure, and nobody understood the full amount of personal data exposed to the Internet. As such, they didn’t understand the true threat of the vulnerability, so it wasn’t escalated to the right level of remediation. Which ultimately took even longer because of a manual process to track weaknesses.
Policies Not Followed
OK, perhaps First American misclassified the vulnerability as low risk. According to company policy, that would give cybersecurity teams 90 days to fix the problem. Instead, the DFS alleges:
Respondent failed to address the vulnerability for more than five months after its discovery… This failure occurred despite discovery of the vulnerability, widespread internal circulation of a detailed report on the vulnerability, and assignment of a 90-day deadline for remediation. Sworn testimony by 11 respondent’s employees responsible for data security revealed internal confusion and an alarming lack of accountability with regard to responsibility for remediation of vulnerabilities.
What’s interesting here is the way that policy failure is wrapped up in poor leadership and escalation procedures.
Compliance officers so often see examples (even within their own companies) of a policy that clearly says, “This thing shall happen” — and then it doesn’t happen. Why not?
Well, the fiasco at First American suggests why. Without clearly assigned roles and responsibilities, people end up debating who is in charge rather than acting on a policy mandate.
A related example: aside from nobody fixing this vulnerability in a timely fashion, DFS also outlined flawed processes to protect personal information in the EaglePro app. The only control First American used to prevent employees from transmitting personal data via EaglePro was an instruction to employees that they shouldn’t do it.
So employees had to be trained on that security procedure — which business units had to design and conduct themselves, rather than the security or compliance teams leading the task. And why wasn’t the CISO involved? Again, the DFS charges speak for themselves:
When the Department asked the CISO why additional controls were not adopted to protect NPI, CISO disavowed ownership of the issue, stating, among other reasons, that such controls were not the responsibility of respondent’s information security department.
Unclear assignment of responsibility, leading to duties ignored and confusion about how to handle a problem. When those conditions exist, of course failure to follow policy happens. You end up with dithering rather than action.
Failures of Remediation
When First American finally did log the vulnerability for remediation, DFS says, it then assigned that task to a newly hired, unqualified employee. Specifically…
- That employee never received a copy of the original penetration test report that discovered the vulnerability.
- Nobody explained the gravity of the risk to the employee, who instead just got a laundry list of application vulnerabilities he had to fix.
- The employee wasn’t provided with the policies and standards First American used to fix security flaws.
- This employee “was offered little support in performing these new responsibilities.”
In other words, the process to remediate security weaknesses was also flawed.
Those four failures above are basic security steps. Heck, you could codify them into a procedure and automate a checklist of some sort in a GRC tool, to assure that the employee had at least the basic information and tools necessary to perform the task at hand.
DFS has scheduled a hearing on the case for October, and the potential penalties for First American are significant: up to $1,000 per individual violation, with millions of violations in play. The company says it will contest the charges.
Meanwhile, CISOs and compliance officers everywhere would do well to ponder the breakdowns in policy, accountability, and risk assessment that the DFS raises. They could happen to any organization, even though none of them have to.
Matt Kelly is the editor of Radical Compliance, a blog that follows corporate compliance and risk issues. He also speaks on compliance, governance, and risk topics frequently. Kelly was named as ‘Rising Star of Corporate Governance’ by Millstein Center for Corporate Governance in inaugural class of 2008; and named to Ethisphere’s ‘Most Influential in Business Ethics’ list in 2011 (no. 91) and 2013 (no. 77). In 2018 he won a Reader’s Choice award from JD Supra as one of the Top 10 authors on corporate compliance.
Banner photo by Colton Duke on Unsplash.com
*** This is a Security Bloggers Network syndicated blog from Hyperproof authored by Matt Kelly. Read the original post at: https://hyperproof.io/resource/parsing-ny-dfs-first-cybersecurity-case/