Do you think ransomware is scary? It will be.

Ransomware attacks have been in the news a lot recently; M&S, Co-op, Jaguar Land Rover, Heathrow Airport & other airports.

But compared with what I’m expecting to come these are all relatively harmless.

Don’t misunderstand me; they all cause harm, and real harm to real people, but this is caused indirectly. My fear is that before long the damage will be much more direct.

What if a „kill switch” were to become quite literally that? Implanted medical appliances are getting smarter; insulin pumps that dynamically deliver the insulin doses required to maintain safe blood sugar levels; pacemakers that adapt to the physical demands placed upon their host; defibrillators that monitor for anomalous heart rhythms and leap into action when required to resolve problems. All these, and others current or future, can be monitored, and in many cases adjusted & controlled, from outside of the host body. This is a game-changer; innovation in products is accelerated. But it’s also a game-changer in terms of risk; connectivity opens the door to attack.

What happens when technology which has typically not been connected to hostile networks becomes so connected? Well, we have some examples.

SCADA as a weapon

Supervisory Control And Data Acquisition (SCADA) industrial control systems evolved in a simple world where, whilst networked, the network was simple and local. No need for complex authentication or encryption. No need to patch software or firmware for security flaws, only to add functionality. These now end up on the same network as everything else, and their vulnerabilities are legion. Remember the Iranian centrefuges which were destroyed by hostile software abuse causing burnout in 2009? You will almost certainly recognise the name of the cyberweapon: Stuxnet.

Fragile Equipment

Voice switches were developed to operate on their own local non-hostile networks with PSTN connections. VoIP was local-only when it first arrived. I worked for two years at Nortel. Their CS2000 Enterprise Level Voice Switch was, from a security design point of view, an utter joke. [Full disclosure: Nortel went bankrupt in 2009 and I am STILL a creditor 14 years later as the most expensive Administration process in history costing over $2bn so far trundles along with an end allegedly finally in sight, so I don’t have fond memories of the organisation!] The CS2000 was basically a rack of 20-odd separate devices. Within the overall CS2000 “appliance” there were plaintext administrative control protocols – yes, we are talking telnet I kid you not – and an utter lack of security design. In fact, you could basically “see” the 1950s telecoms thinking and the 1960s design elements still present, with just point technological upgrades to the devices within the overall appliance. Close your eyes, and you could smell the valves of the original kit. I once ran a nessus against one of these switches, having been tasked to perform a penetration test at a call-centre site. With great trepidation, knowing the fragililty of the design and suspecting the quality of the implementation, I dialled back the nessus settings removing everything aggressive or dangerous, to make the testing as low-stress and low-risk as possible. I was still extremely nervous because we had been asked to test the live site not an inactive fall-back site.

You know where this is heading, right? Seconds after initiating the scanning, before we even got to any real vulnerability testing, there was some commotion in the building. Lots of people in a state of near-panic, and within minutes a DR event was declared. The mere act of scanning for open TCP ports had taken the whole “Enterprise Grade” voice switch down and killed the entire call centre. There’s nothing like a system failing gracefully. And this was certainly nothing like it,

This is what happens when devices designed and built without hostile activity in mind get connected to untrusted and untrustable networks. It isn’t pretty.

Ransomware With A Vengence

Now consider ransomware, and two slightly different scenarios;

Scenario 1 – Happens Now

Your systems are down, your data is encrypted. You receive a ransom demand. Pay up and (maybe) get your data back, and if you’re really lucky then once you’ve paid there won’t be a follow-up extortion demand with the threat of publishing all your data because obviously they kept a copy. But you won’t be that lucky, sorry.

Pay up for that too, and you’ll most likely get another extortion demand from someone else… reductio ad bankruptatem.

Or, don’t pay up at all from the start. You had better have rock-solid reliable backups-of-last-resort from which to rebuild. You have tested this process in advance, right? Right?

You also need a very good idea of what sensitive data is likely to end up being published.

And of course you’ll need to manage both of these disasters at once. You practiced that though? Right?

Scenario 2 – Bleak Expectations

Several people across a wide geographical area all drop dead in agony within a few minutes of each other. The common factor is that they all have surgically embedded devices manufactured and/or managed by your organisation.

You receive a ransom demand: pay up NOW or thousands of people will die. Maybe they’ll be killed off in random batched to rachet up the publicity and the pressure.

Pop Quiz, hotshot: thousands of people could die any minute without warning. What do you do? WHAT DO YOU DO?

Á la Speed, 1994

Choosing not to pay up is no longer a realistic option. You can’t “tough it out” as your end-users get, literally, terminated, and there’s no way this does’t hit the news big time.

The organised crime groups (OCG) are wanting one thing: money. They don’t want one other thing: getting caught. It’s that simple.

They are amoral, and will use whatever leverage they can to force payment. They probably think that they are untraceable – maybe they are, maybe they are not – but because they believe that they are, they will act without restraint, without consideration of what getting caught would mean. That’s a dangerous combination.

Prevention Is Key

Preventing this class of outcome is critical. And prevention must be through proper Secure By Design approaches, rigorous assurance processes, brutal penetration testing at all stages of development, and a genuine understanding and appreciation that Cybersecurity issues cannot be ignored, overlooked, or rationalised as small risks Because Reasons™️.

You need the best security designers, the best security testers, and the most tenacious, pedantic and bloodyminded assurance personnel too.

In addition, consuming organisations & end users need to ask awkward questions too. Watch some Columbo and master the “Oh, just one more thing….” technique at least!

I desperately do not ever want to be reading about a scenario like the second one above. But I fear that it is almost inevitable unless security design and implementation is properly assessed to differentiate the products that are likely vulnerable from the ones with robust controls and non-fragile designs.

This reason, and many more, contribute to why I’m attending BCC2025.