Security programs tend to rank systems by how often they are used. The Arizona court system’s cyberattack points at the system an attacker may want most: the one holding the most history, which is often the backup tier.
What the court reported
The Arizona Judicial Branch says criminal hackers accessed and copied backup court files in an attack that began on September 24. The court says the data came from a backup server and included protective order records, Foster Care Review Board reports, and case numbers, names and Social Security numbers for approximately 1.3 million people referred to its debt-collection program, with debts dating back 30 years. In its words, “Evidence so far suggests the cyberattack began with a common phishing attack, where a court employee received an email and clicked a malicious link.”
The court also describes the controls around it: statewide judicial branch cybersecurity policies, scans and remediation twice a year, annual training for every employee, full-time security staff and 24×7 monitoring. I take that description at face value. It makes the point of this column sharper, because a court with those controls still had a backup server whose copied files held a large body of sensitive records.
My argument
A backup is a second copy of production data, and in many organizations it is the longer copy. Production systems archive, purge and minimize. Backups keep what existed on the night they ran. That makes the backup tier a store of everything the business has decided it no longer needs on the front line, with the access controls, monitoring and patch cadence of a system nobody opens on a normal day.
I would put three controls on that tier before any new product. First, limit which accounts and networks can reach backup storage, and make that list shorter than the one for production. Second, encrypt backup data with keys that the backup system itself cannot read, so a stolen file is a locked file. Third, set a retention period that someone has to defend in writing, because every extra year of retained records is a year of data an attacker can copy in one pass.
The strongest counter-argument
The best objection comes from the court itself. It says the copied files are highly compressed, that it is unclear whether most of the data can be easily read, and that it has no evidence any of it has been accessed or shared. A reasonable security leader could conclude that backup formats are a form of protection, and that spending to harden them returns less than spending on phishing defenses.
I disagree for two reasons. Obscurity from a file format is a property of today’s tooling, and the court’s own wording is that it is unclear, not that the data is unreadable. A control that depends on nobody at the other end having the right parser is an assumption, not a safeguard. And the entry point the court describes was a click by one employee. Better phishing training helps, as the court’s annual training requirement shows, but the court quotes the National Institute of Standards and Technology as saying “the hackers only have to be right one time.” A layer that is built on the assumption that no click ever lands gives a defender nothing to fall back on. The backup tier is the one place where hardening limits the damage after the click.
What I would do this quarter
List every backup system and snapshot store, the oldest record each one holds, and every identity that can read it. Compare that to the retention schedule your legal and privacy teams actually approved. Where the backup holds records production has purged, either shorten the retention or encrypt the older data under separate keys. Then run a restore drill that uses the same least-privilege accounts you intend an attacker to be limited to, so you learn whether the controls survive a bad day. For related thinking on knowing what you expose before an advisory lands, see CyberTech’s opinion on exposure inventories, and on the human side of the same entry point, the help desk as the door nobody locked.
The court has said it will conduct a full review of the incident. Whatever it finds, the lesson I would take is already on the page: protect the oldest copy of your data as carefully as the newest one.
