Unending ransomware attacks are a symptom, not the sickness
- Reference: 1747038612
- News link: https://www.theregister.co.uk/2025/05/12/opinion_column_ransomware/
- Source link:
Imagine an inverse Black Hat conference, an Alcoholics Anonymous for CISOs, where everyone commits to frank disclosure and debate on the underlying structural causes of persistently failing cybersecurity syndrome
If the goods these people sold were one-tenth as shoddy as their corporate cybersecurity, they'd have been out of business years ago. It's a wake-up call, says the UK's [1]National Center for Stating the Obvious . And what will happen? The industry will just press the snooze button again, as we hear reports that other retailers are "patching like crazy."
The bare fact that entire sectors remain exquisitely vulnerable to what is, by now, a very familiar form of attack is a diagnostic of systematic failure in the way such sectors are run. There are few details of what exactly happened, but it's not the details that matter, it's the fact that so little was made public.
We see only silence, deflection, and grudging admission as the undeniable effects multiply - which is a very familiar pattern. The only surprise is that there is no surprise. This isn't part of the problem, it is the problem. Like alcoholics, organizations cannot get better until they admit, confront, and work with others to mitigate the compulsions that bring them low. The raw facts are not in doubt; it's the barriers to admitting and drawing out their sting that perpetuate the problem.
We know this because there is so much evidence of corporate IT's fundamental flaws. If you have been in the business for a few years, you'll already know what they are – just as surely as you'll have despaired of progress. If you are joyfully innocent newbie, then [2]look at the British Library's report into its own 2023 ransomware catastrophe. It took many core systems down, some of them forever, while leaking huge amounts of data that belonged to staff and customers. As a major public institution established by law, and one devoted to knowledge as a social good, the British Library wasn't just free to be frank about what happened, it had a moral obligation to do so.
[3]
The entry point for the attack could have been a host of other things. It really doesn't matter. What does matter is that legacy components of a very complex whole couldn't be secured to modern standards, and in many cases they couldn't be restored once they were disrupted. The Library said in its report that this and the complexity was due to underspending on lifecycle management, and the underspending was due to new projects being preferentially funded from a fixed budget. The complexity was due to the amalgamation of very different departmental systems over time, again without the resources needed. And IT, with its lack of budget, was being asked to do too much in a fiscal environment in competition with other, higher status parts of the organization.
British govt agents step in as Harrods becomes third mega retailer under cyberattack [4]READ MORE
Does this sound familiar? You may not be a national library with multiple collections and legal obligations vying for oxygen, but you may be a large retailer with IT systems bearing the scars of corporate mergers and amalgamations, of integration of old logistics systems with new online customer-facing portals, with migrations and data flows built out of more string and sealing wax than any PowerPoint executive summary dare show. Once something works, however ungainly it is, the attention moves elsewhere. Security is a business expense that, if it works, has no visible effect whatsoever. Ongoing security looks like a bucket with a hole in it to those for whom visible effects are vital
This is basic human psychology that operates at every scale. Getting the boiler serviced or buying a sparkling new gaming rig - there's a right decision and one you'll actually make. Promising to run a state well while [5]starving it of funds , is again hardly unknown. Such an act is basic, but toxic, and it admits of its toxicity by being something that polite people are loath to discuss in public.
[6]
[7]
Where there's insufficient discipline to Do The Right Thing in private, though, making it public is a powerful corrective. Self-help groups for alcohol abuse work for many. Religions are big on public confession for a reason. Democracy forces periodic public review of promises kept or truths disowned. What might work for the toxic psychology of organizations that keeps them addicted to terrible cybersecurity?
It's unlikely that entrenched corporate culture will reform itself. You are welcome to look for historic examples, they're filed alongside tobacco companies moving into tomato farming and the Kalashnikov Ploughshare Company.
[8]
There is one way of publicly accepting shortcomings with consequences, one that is frequently and not inaccurately seen as advanced ass-covering. It's a variant of the It's Everyone's Fault So It's Nobody's Fault. Often an excuse for inaction, it does at the least get problems out in the open, where there is opportunity for innovation in fixing them. Imagine an inverse Black Hat conference, an Alcoholics Anonymous for CISOs, where everyone commits to frank disclosure and debate on the underlying structural causes of persistently failing cybersecurity syndrome, or PFCS. The British Library report could serve as a starting point, with hundreds of other major incidents used to create a properly abstracted, generalized description of PFCS. Diagnosis is a prerequisite of a cure, it's like getting an owner's manual for what ails you.
[9]PowerSchool paid thieves to delete stolen student, teacher data. Looks like crooks lied
[10]From Russia with doubt: Go library's Kremlin ties stoke fear
[11]RSA Conf wrap: AI and China on everything, everywhere, all at once
[12]Healthcare group Ascension discloses second cyberattack on patients' data
What then? A protocol for ensuring, or at least encouraging, the security lifecycle of a project or component. How long will it live, how much will it cost to watch and maintain it, what mechanisms are there to reassess it regularly as the threat environment evolves, what dependencies need safeguarding, and, lastly, what is the threat surface of third party elements? In short, we must agree to accept that there is no such thing as "legacy IT," no level of technical debt that can be quietly shoved off the books. If all that isn't signed off at the start of a system's life, it doesn't happen.
No silver bullet, nor proof against toxic psychology. It would be a tool for everyone who knows what the right decision is, but who can't see how to make it happen. There are plenty of accepted methodologies for characterizing the shape of a project at its inception and development, and all came about to fix previous problems.
One that takes on board the nature of PFCS would be the start of fixing an unacceptably embarrassing and highly dangerous toxic reality that has been in plain sight for decades. ®
Get our [13]Tech Resources
[1] https://www.theregister.com/2025/05/02/ncsc_steps_in_as_harrods/
[2] https://www.theregister.com/2024/03/11/british_library_slaps_the_cloud/
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/cybercrime&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2aCHGvsSfJO5OfN3j-xWSmwAAAII&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[4] https://www.theregister.com/2025/05/02/ncsc_steps_in_as_harrods/
[5] https://www.theregister.com/2025/04/14/opinion_secret_state_security/
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/cybercrime&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aCHGvsSfJO5OfN3j-xWSmwAAAII&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/cybercrime&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33aCHGvsSfJO5OfN3j-xWSmwAAAII&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[8] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/cybercrime&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aCHGvsSfJO5OfN3j-xWSmwAAAII&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[9] https://www.theregister.com/2025/05/08/powerschool_data_extortionist/
[10] https://www.theregister.com/2025/05/06/from_russia_with_doubt_go/
[11] https://www.theregister.com/2025/05/04/rsac_wrap_ai_china/
[12] https://www.theregister.com/2025/05/01/ascension_cyberattack/
[13] https://whitepapers.theregister.com/
What "massive disruption" did Harrods experience?
A few hours where they halted in-store wireless and card payments in staff canteens - I know this from chatting to staff last week.
As a customer, impact was negligible: rewards points didn't credit for a few days, the website wasn't updated with new items for a few days.
If El Reg has details of "massive disruption", spill the beans.
Make the management legally liable
The whole industry is a genuine fuck up.
CEOs thinking in 3 month chunks & even IT guys who aren't interested in sitting down, going through the legacy issues to fix them but want the latest shiny on their CV.
Patch it. Carry on.
Not enough staff. Staff spread across the world. Agile, DevOps, STICK IT ALL IN THE CLOUD!!
Everything is a checkbox exercise. Wages are collapsing. You have morons who say "well ALL software has bugs & you can't guarantee a library isn't buggy ".....well simple write better software & don't use external libraries!
The whole industry from top to bottom is full of lazy arses & those that have been mentally broken from trying to do a good job.
CEOs are untouchable & those of us who actually TRY to do things the right way are the first one out the door.
Lloyds shipping their IT to India even though they had to previously bring it back due to security issues.
Users who have been molly coddled for decades. I don't care if you're "not technical". A man who uses a chain saw KNOWS how to use that chain saw & HE isn't going to cost a firm £100 million from clicking an incorrect email.
Purchasing & finance able to override the IT SME about what to buy. IT guys implementing the incorrect solution because, either they want it on the CV or they refuse to learn anything new.
How many projects have gone tits up because a PM was allowed to make fundamental technical decisions?!
Unless the CSuite is made legally liable & can't blame the IT department. Nothing will change.
I REALLY care about doing a good job but these days, even in public sector if I spotted files being encrypted at 445 on a Friday afternoon, I would quietly close my laptop & go home. Becsuse I know that wherever I'd be working, the stuff I wanted to buy to be able to recover would have been turned down & the overtime would be unpaid.
Re: Make the management legally liable
Your last paragraph is shockingly unprofessional and a hallmark for why technology needs to become a regulated industry like medicine and law.
No company can fix all of the flaws, all of the risks. The only secure system is one that's powered down and guarded by wolves.
Instead of blaming management, look at your own final paragraph. You are the problem. Sorry, but you need to see this.
I quote
I REALLY care about doing a good job but these days, even in public sector if I spotted files being encrypted at 445 on a Friday afternoon, I would quietly close my laptop & go home
"If all that isn't signed off at the start of a system's life, it doesn't happen."
That still doesn't solve the issue with *existing* technical debt. I fully agree with you, but i think software lifecycles are extremely complex, especially when you're working with massive technical debts. So you create an inventory of software, assign priority and risk levels, make plans for their lifecycles... and then what?
You need to get budget to even execute the plans, this can take a lot of time. You're also not going to get this budget all at once, it needs to be gradual. But what do you do in the meantime? While you're building a new system, the old system may need maintenance or hardening, how do you approach this? How do you approach dependencies and interfaces, especially when the programs it interfaces with are due a replacement as well?
That is assuming you can get company-wide support for such an undertaking.
Again, i fully agree with the sentiment, but frameworks for software lifecylcle management didn't exist (or at least weren't widely used) when the most problematic of today's software was deployed. The massive complexity and cost of relieving this technical debt is a serious undertaking, and i feel like this article doesn't sufficiently address the complexities of it.
I also think there is is an easier way to address the most problematic part of this: improve your security posture. Review and test your DR protocols, assess your risks, and reduce your attack surface. Focusing on this first will allow you to partly mitigate the most direct threats, and reduce the impact associated with them. This will also serve you well into the future, it's an investment that is guaranteed to pay off.
Do the DR assessment and attack surface reduction on all software changes, use the risk assessment to prioritize your software lifecycle decisions. This is a continuous process, but you need to start in the right place.
Conferences not needed
It does not need conferences or other bullsh*tting events to sort these problems. What it does need is for shareholders to accept lower dividends provided that the money is spent on doing the computing properly.
lose-lose
We're stuck between a rock and a hard place.
Legacy systems suffer from being built at a time when code dev and testing tools were not as sophisticated, and the perceived (if any) external threats were not given much thought, plus systems were not connected to external environments in such accessible ways. Simpler times.
Now, systems are abstracted into so many layers, both from technology stack and business responsibility levels; dev tools come from multiple sources, on local and cloud environments divided into layers of services, containers, orchestration and physical or software edge devices, spread across different commercial organisations that don't and can't have an intimate, holistic approach to development and testing, except to share, often iffy, API specs... and we're surprised when the whole lot leaks like a sieve.
Who'd be a CISO?
The fundamental role of the person in charge of business information security is there to develop a robust plan for business continuity and recovery that kicks in WHEN a system is breached. Anyone taking on the role on the basis that their skills and leadership will make their organisation's systems impervious to infiltration is very misguided.
We've worked so hard to be 'clever' with dev pipelines, frameworks and bolt-it-together architectures that we've lost the ability to understand, own and test the creations we make.
The solution? Get systems and services back to minimum viable stack so that the end-end design can be understood and owned by the development team. What shape this takes is a big discussion..maybe start by considering on-prem or co-located physical hardware and then work outwards, software and hardware-wise, as much as you believe is possible, necessary and safe, so that you can own and audit the beast you are creating. And then write your recovery plan from the start point of your secured data repository (backups) and the business needs, not the technology that's just let you down.
Of course, you could always commission a solution from an established market practitioner on the basis that you haven't, and don't, need a clue about what's going on under there hood provided you're as happy as can be with the functional spec you are served, safe in the knowledge that when things go tits up it's someone else's job to sort it out, and you escape the front of the incoming storm when your business grinds to a halt. With a bit ofuck, the company you engage to provide your solution developed it as described above so they have an easier time getting you going again.
Slate and chalks all around then!?
Open Door
At the turn of the century I worked for a company that was going through the List-X process. In the run up to the preliminary audit, IT were working flat out on their processes, procedures, training, etc. One of the major findings of the audit was that there were too many doors into the building.