Cyber attacks happen every day, but some are especially chilling. An attack this summer on the US court system should have sent chills down every spine.
On August 7, officials confirmed an attack on the federal judiciary of the United States. In particular, the attackers went after its court filing system, Case Management/Electronic Case Files (CM/ECF), also known by its public-facing interface PACER. The New York Times said that the attack, which occurred between late June and early July 4 this year, was likely linked to Russian state actors.
The ramifications are significant. While many case files on CM/ECF are publicly available via PACER, many others are sealed because they contain sensitive information. The attackers appeared to have been searching for cases involving Russian nationals.
The incident threw the courts into disarray, and courts were forced to revert to paper filing systems. At least one judge even prohibited the uploading of sealed documents to PACER. Sensitive cases had to be migrated to standalone systems.
More worrying still is the suggestion that Mexican drug cartels might have access to some of this sensitive data, potentially exposing witnesses to their crimes. Gang crime linked to the cartels is often processed at the district court level, meaning that sensitive case files are located in CM/ECF.
The worst part of this is that a mixture of decentralised implementation and old, legacy code is to blame.
CM/ECF dates back to the late 1990s, when the Northern District of Ohio built it to manage a flurry of findings in some asbestos cases. Then, other courts began to adopt it in the early 2000s, when a national roll-out saw bankruptcy, district, and appellate courts implement it too. By 2007, adoption was mostly universal, but management was piecemeal; each court handled its own implementation of the software. So when the Administrative Office of the US Courts released a major revision known as NexGen emerged in the 2010s, not everyone updated.
In a 2021 report on the system, Administrative Office staff complained that over 50 courts had not moved to the new system. The report lamented obsolete foundational technology. “Decentralisation and complexity are causing system instability, high maintenance costs and security risks,” it warned. “Current contracts make it difficult to hold contractors accountable to quality standards.”
The problem has been ongoing, and the results have been disastrous. The Department of the Judiciary also reported a breach in 2021, which was later revealed to have involved three foreign actors.
The problem of legacy software
This legacy software problem is rampant. A survey this year from legacy migration software company Saritasa revealed that 62% of its 500 respondents still relied on legacy systems. IT must always vie with other departments for a portion of the budget. When the technologists get it, they must be careful to balance paying down technical debt with making new software and hardware improvements that please the business sponsors. Every dollar spent on fixing old systems must be wrested from the corporate purse.
Decentralized IT management also creates blind spots, especially when linked to legacy software. It leaves many software products bereft of patches. It also makes it more difficult to understand what’s running on the IT infrastructure and tie it back to security policies. Shadow IT is the result, and it introduces yet more risk.
The federal court system isn’t the only one exhibiting some of these issues. In 2019, the Government Accountablity Office (GAO) published a report highlighting a continued lack of attention to legacy systems in the US government. In the UK, the government classifies 28% of its IT infrastructure as legacy, rising to 70% in some areas.
Taming the legacy beast
There are ways to take back control of your IT infrastructure and at least understand the risks from legacy architectures, even if you’re unable to completely eradicate it. This is where an information security management system (ISMS) such as ISO 27001 is useful.
ISO 27001:2022 Annex A Control 5.9 deals with managing information assets, ensuring that the organisation properly documents who is responsible for each asset in the organisation, and outlining the risks associated with it. It mandates an inventory of assets to support this goal, creating a platform for businesses to organise their activities around it. You can document the current patch levels associated with any asset, for example.
This inventory of assets is a great foundation from which to launch a technical debt pay-down program. Prioritising systems to patch, upgrade, or replace based on their risk factor gives resource-constrained teams a clear plan of action. You can also use it to create governance structures around those platforms that aren’t client-facing but which hold high-value, low-profile information. Those poorly protected crown jewels are precisely the assets that attackers will come after.
Then comes the migration discussion, which outlines how to migrate from a legacy system to a new one. That involves careful thought that takes system dependencies into account. Refactoring (renewing some code in the existing system) is one option, as is replacement (completely ripping out the system and starting again). The latter option creates more opportunities to move from problematic architectures such as monolithic systems to more modular, microservices-based code.
Other measures to help cope with legacy risk include running regular threat modelling exercises to explore that invisible legacy infrastructure that no one ever looks at, such as internal portals or contract platforms.
Getting your legacy architecture in shape isn’t something you should put off till tomorrow. It’s a lot like physical health. Every day spent procrastinating can create problems in the future. A little effort now – even a small regular monthly effort to modernise – can stave off disaster in the future. Just ask any district judge.
