The Regulator Did Not Fine Them for the Bug

In May 2019, Brian Krebs reported that the website of First American Financial - the second-largest title insurance company in the United States, roughly 18,000 employees and $6.2 billion in revenue that year - was exposing approximately 885 million documents relating to mortgage transactions.

The records went back to 2003. Sixteen years of them.

They contained bank account numbers and statements, mortgage and tax records, Social Security numbers, wire transfer receipts and images of driver's licences. Reaching them required no credentials, no exploit and no tooling. A link to one document could be edited - change a digit in the URL - and you had somebody else's.

That is an Insecure Direct Object Reference, and it sat in a proprietary document-sharing application called EaglePro.

What the regulator actually said

Here is where this incident becomes more instructive than the headline number.

In July 2020, the New York State Department of Financial Services brought its first-ever cybersecurity enforcement action under 23 NYCRR Part 500 against First American. It settled in November 2023 for $1 million. Read the consent order and notice what it faults. Not the IDOR. Not a coding error.

NYDFS concluded the company had failed to maintain and implement effective governance and data classification, access controls and identity management, and risk assessment policies and procedures - and that those failures resulted in unauthorised access to consumers' non-public information. The regulator did not need to prove a clever attack. It examined whether the environment had the controls it was required to have, and whether those controls operated compliantly. It found that they did not.

The record shows how that played out. NYDFS's statement of charges alleged that First American's own internal penetration test found the flaw in December 2018, about five months before Krebs reported it. The flaw was rated medium severity, then accidentally logged as low, which gave the team 90 days to fix it. The team reviewed only 10 of the hundreds of millions of exposed documents, and its recommendation to investigate further was not followed. Detection worked. Remediation did not happen.

Separately, the SEC settled with First American for $487,616 over deficient disclosure controls. Its order found that senior executives were never told that the company's security personnel had identified the vulnerability months earlier and had not remediated it as company policy required. It was one of the earliest occasions a regulator treated a cyber incident as a corporate governance failure rather than a security event.

Two regulators, two theories, one finding: the control environment was the deficiency. The bug was just how it surfaced.

The question every examination comes back to

Strip away the incident and both orders ask the same thing: is this a control environment that can be secured? That has a specific meaning. There is a standard, a defined statement of what is expected. The standard is applied consistently across the estate. And the company can show both. Two of the areas NYDFS named map straight onto that: governance and data classification define what is expected of which data, and access controls and identity management show whether it was applied. The third, risk assessment, works at the edges of the standard. It decides what the standard should require in the first place, and it decides how seriously to treat something that breaks it.

The standard matters more than it looks, and it does not have to be technical. It can simply be guidelines on how things should operate. Without a definition of expected, a risky access or a public resource is only a fact. Nobody can say whether it is a deviation or normal. An analyst cannot triage it, an examiner cannot assess it, and nobody can be held to it.

This is also why the question is not how quickly you put out the fire. It is whether you had the controls and procedures to avoid it. The best fire detector in the world does not help much if there is a fire every hour. First American’s detector worked: its own team found the flaw in December 2018. What failed was the managed environment around the finding. The flaw was classified as low severity, and it was not properly investigated, escalated or fixed.

A managed environment does not mean no exceptions. There will always be a legitimate reason to deviate. It means exceptions are known, bounded and approved, so they stay exceptions instead of becoming the environment. The question is not how quickly you put out the fire. It is whether you had the controls to avoid it.

Why this lands hardest in insurance

Every industry accumulates data. Insurance accumulates it by obligation.

Title insurance is the extreme case - a policy on a property may need to be defended decades after it is written, so the underlying documents are retained accordingly. But the pattern holds across the sector. Claims files, underwriting records, medical evidence for life and disability, actuarial datasets. Retention is measured in years or decades, mandated by regulation and by the nature of the contract.

Which produces a structural condition unique to this industry: the data estate only grows, and its oldest, largest portions live in the systems with the oldest controls.

Add the sector's other characteristics. Distributed agent and broker networks with delegated access. Managing general agents aggregating policyholder records across many retail producers. Third-party administrators, claims adjusters, reinsurers. Each relationship is a route by which data enters an estate the carrier is answerable for. In an estate built from agents, MGAs and administrators, a standard that does not travel with the data is not a standard.

And insurers licensed in New York are covered entities under Part 500, so the standard applied to First American is the standard applied to them.

Being precise about what prevention would and would not have done

This matters, because an insurance security team will spot an overclaim immediately.

Deployment-time policy enforcement would not have prevented an Insecure Direct Object Reference. That is an application-layer authorisation flaw in code, and it needs secure development practice, code review and application security testing. Any vendor telling you otherwise is selling.

A standard can still reduce the risk. An architecture built on defence in depth puts controls around an application that may have flaws: a web application firewall in front of externally facing requests, rate limiting, and other layers. None of them removes an authorisation bug. They make it harder to exploit. For a flaw that let anyone move from one document to the next by changing a digit, rate limiting and request filtering are the kind of control that makes working through 885 million of them hard. Prevention does not stop the vulnerability from existing. It can make it much less exploitable.

What enforcement most directly addresses is the finding the regulator actually made. NYDFS faulted governance, classification, access control and risk assessment which are the basics for a control environment - whether policy was consistently applied across the estate and whether the company could demonstrate it. That is a different question from whether a particular application had a bug, and it is the question every Part 500 examination asks.

A control environment is only as consistent as the weakest thing anyone deployed into it. Every storage account created reachable from the internet, every database provisioned without encryption, every role granted access beyond its function - each one is a small, quiet argument that the environment is not under consistent control. Individually they are findings. Collectively, to an examiner, they are the answer to the question about your cloud security governance.

Where the leverage is

The realistic path to a defensible control environment is not to catch every deviation after the fact. It is to reduce how many exist - which makes cloud misconfiguration prevention a cloud security compliance strategy, not only a security one.

If a data-bearing resource cannot be created reachable from the internet, that is not a policy somebody follows. It is a property of the environment. The same applies to encryption, to permitted regions for data residency, and to access scope.

The difference at examination time is the difference between two answers:

We detect non-compliant resources and remediate them within our SLA. An examiner will then ask about the ones you did not detect, the SLA you missed, and the backlog. First American is what that backlog looks like when a finding sits unremediated for five months.

Resources that violate policy are not created in this environment, and here is the continuous record of what policy applied. There is considerably less to ask about. Insurance has been living with continuous supervision longer than most sectors. The second answer is the one built for it.

How Aryon helps

Aryon is a cloud security enforcement platform. We apply your policies when cloud resources are created or changed across AWS, Azure and Google Cloud, so a configuration that violates policy is never deployed.

For a carrier or broker operating under Part 500 and its equivalents:

The standard lives in one place and applies everywhere. You define what expected looks like - for example, that a resource holding non-public information must be encrypted, must not be reachable from the internet, and must stay in approved regions. Aryon applies that definition as a condition of creating the resource, in every account, instead of leaving it in a document teams read once.

• The standard lives in one place and applies everywhere. You define what expected looks like - for example, that a resource holding non-public information must be encrypted, must not be reachable from the internet, and must stay in approved regions. Aryon applies that definition as a condition of creating the resource, in every account, instead of leaving it in a document teams read once.
• Exceptions stay managed. Where a team has a legitimate reason to deviate, the deviation is a known, bounded decision, not drift. The environment stays managed over time.
• Defence in depth is a requirement, not a hope. Policy can require that externally reachable workloads sit behind the controls your standard calls for, such as a web application firewall and rate limiting, before they go live. It will not remove an application flaw. It makes one far harder to exploit.
• Agents, MGAs and administrators get your policy. A third party provisioning resources inside your cloud estate passes through the same enforcement as your own engineers, without adopting your tooling or completing an onboarding programme.
• Evidence accumulates instead of being assembled. A continuous record of which policy applied and what was prevented is closer to what a Part 500 examination expects than a point-in-time gap analysis compiled in the weeks before it.
• Nothing running is disturbed. Enforcement applies to new deployments, and we do not perform auto-remediation on live infrastructure - which matters when the systems in question are processing claims.

The question for a carrier

Not "could we have an IDOR?" You could. Everyone could, and application security is the discipline for it.

Ask the question the examiner will actually ask: can we demonstrate that our standard was consistently applied across the whole estate, continuously, for the period under review?

And the question underneath it: do we have a written definition of "expected," specific enough that a deviation is obvious when it appears?

If answering either requires a project, the answer is already visible.