The details below come from Brinkley's recollection as The Register reported it. The account does not name the agency, the contractor, the datacenter operator or the system, and it gives no exact date. No other outlet has reported the incident. It should be read as a credible first-person case study from someone who says he owned firewall changes at the time, not as a documented government finding.
How a firewall rule change opened a path to 50 million immigration records
Brinkley says he worked for the contractor as an information system security officer (ISSO). He was responsible for firewall rule changes and for network intrusion detection and prevention. That role matters later, because he was the person best placed to judge whether a new rule crossed a boundary it shouldn't.
The contractor ran two very different environments. Developers tested new code in a low-security commercial datacenter. Production servers and data sat in a classified datacenter that Brinkley described as top secret. According to his account, a "hard firewall" had always separated the two. Code moving from development to production went through a provisioning server, but that server could not freely reach the classified side.
The developers wanted that to change. To make deployments easier, they asked for a firewall rule letting the provisioning server reach all of the production servers in the classified datacenter. Brinkley took the request to the Change Review Board and argued against it. He told the board the rule would let anyone in the low-security datacenter reach, at a minimum, the high-security one, and called the arrangement "a very glaring issue."
The change went through anyway. In a week when Brinkley was on vacation, the developers went straight to a different body, the Change Acceptance Board, and got the rule approved.
The provisioning server became a bridge across the classified boundary
The request sounds routine, which is exactly the problem. Deployment tooling needs to reach its targets, and a provisioning server that can't touch production isn't much use. But a rule that lets a development-side host reach every production server does more than speed up deployments. It turns that host, and every network that host belongs to, into a way into the classified environment.
Brinkley showed this in person once he was back. With a member of his company and a government representative watching, he tethered his laptop to his cellphone and connected over the commercial datacenter's VPN. He logged into the development server and turned it off and on. Then, over the same VPN connection, he got into the production server and showed that he could control it.
According to Brinkley, the production server held about 50 million immigration records: who was entering the country, who they stayed with, and similar details. The account doesn't name the country, but the setting is a US government contractor. It also doesn't list the data fields or say whether that figure was ever audited.
The demonstration settled the argument quickly. Supervisors immediately put the firewall rule back the way it was. The account does not mention any later audit, credential reset or investigation into whether someone else used the path while it was open.
A commercial datacenter VPN turned dozens of authorized users into thousands
The most serious detail isn't the provisioning server. It's who else could reach it. The VPN into the development environment was run by the commercial datacenter, not the government. That same VPN connection also gave access to servers belonging to other, non-governmental tenants of the facility. Brinkley named Microsoft and Oracle as examples. Nothing in the account suggests either company's systems were involved or at fault. They are named only to show how broad and shared that network was.
Brinkley estimates that thousands of people had access to the commercial datacenter's VPN, while only dozens were supposed to have access to the classified datacenter. So the rule change did more than add one host to the list of machines that could talk to production. It effectively extended network reachability to everyone who could get onto a shared, third-party-run VPN. Few of those people had been vetted by the government, and none had been cleared for the classified environment.
This is the core segmentation lesson. A VPN answers one question: is this user or device allowed onto this network? It says nothing about which systems beyond that network the user should reach. When a firewall rule treats "on the dev network" as good enough to reach production, the VPN's user population quietly becomes production's user population. In this case, that meant going from dozens of people to thousands.
Change control failed when the firewall's owner went on vacation
The account has two failures in it, and the second is procedural. The person responsible for firewall changes had formally objected. The developers didn't resolve his objection. They took the request to another board while he was away and got a yes.
The account doesn't explain how the Change Review Board and the Change Acceptance Board divided their authority. It also doesn't say whether written policy required the ISSO to sign off, or whether the change got any other security review. So it can't be said that a specific rule was broken. The practical weakness is clear anyway: the process let a boundary-crossing change go ahead without its security owner, and without anyone formally accepting the risk that owner had flagged.
Brinkley's recovery also relied on luck and persistence. The rule was only reversed because he came back, noticed it, and staged a live demonstration for management and the government customer. Nothing in the account suggests an automated check, a scheduled rule review or a monitoring alert would have caught it otherwise.
Passwords without MFA were the last control left
Once the firewall boundary was gone, the production servers still asked for a username and password. That was the only remaining barrier. The account says there was no multifactor authentication, and password standards were low at the time. As The Register points out, an attacker on that VPN could have tried guessing credentials or run a brute-force attack against the newly reachable servers.
No attack of that kind is reported. The account doesn't describe any login attempts, compromised credentials or data access by anyone except Brinkley during his authorized demonstration. The point is defense in depth. The network boundary was meant to keep thousands of people from ever reaching the login prompt. With that boundary removed, the only thing protecting the data was the weakest authentication in the environment.
MFA alone would not have fixed the design flaw. Stronger authentication would have made the exposed servers harder to break into, but they would still have been reachable by a population that should never have seen them. The two controls do different jobs, and this environment was missing the second one at the very moment the first was removed.
For context on the period: in 2011, the Department of Homeland Security Inspector General's office flagged weak insider-threat controls in USCIS's immigration-processing IT. Its audit listed a large automation program's susceptibility to insider threats as among the "most prevalent, high-impact areas of concern". That audit concerns a separate case, and nothing links it to Brinkley's account. It does show that immigration systems of that era were already under scrutiny over who could reach them.
Checks that would have caught the provisioning-server rule
The decision for readers is simple. If your environment has any firewall rule that lets a development, test or shared-tenant network reach production, review it now. Don't wait for someone to demonstrate the problem the way Brinkley did. Anyone running build and deployment tooling across trust zones should apply this, whether those zones sit on-premises, in colocation or in the cloud. The specific technology in this 2010s story has changed, but the pattern hasn't.
The measures below are general security practice that follows from the failures in the account. They are not steps the contractor is reported to have taken.
- Treat any rule that crosses a security boundary as high-risk. It should need sign-off from whoever owns that boundary, or an explicit, recorded risk acceptance by someone with the authority to accept it.
- Scope deployment access narrowly. Allow a specific source host to reach only the production destinations, ports and services it needs, rather than every production server.
- Map who can reach the source network before approving any rule that trusts it. If a shared or third-party VPN leads to that network, everyone on that VPN is part of the exposure.
- Make sure change-approval workflows can't get around a security objection by going to a different board, especially while the objecting reviewer is away.
- Re-audit firewall rules on a schedule, so a risky change doesn't stay in place until one person happens to notice it.
- Require MFA and strong password policy on production systems holding sensitive data, but still treat network segmentation as a separate control that stronger logins can't replace.
The account ends well. A security officer caught the rule, proved the risk in front of the customer, and got the boundary restored. Nothing in it shows that anything was lost. Still, the path stayed open for as long as it took one person to come back from vacation and notice it. The practical fix is to make sure the next rule that bridges development and production can't get approved without the person responsible for that boundary, and gets caught by a scheduled review if it ever does.