Guess what happens when ransomware fiends find 'insurance' 'policy' in your files Ransomware operators jack up their ransom demands by a factor of 2.8x if they detect a victim has cyber-insurance, a study highlighted by the Netherlands government has confirmed. For his PhD thesis [PDF], defended in January, Dutch cop Tom Meurs looked at 453 ransomware attacks between 2019 and 2021. He found one of the first …
... doing backups.
It's the ultimate test to study the value of procrastinating.*
For the first time in history, economists can now put an exact value, and price, on procrastinating.
What is often forgotten is to test the backups regularly. I suspect that is something with an even higher procrastinating value.
* It hit me too, I have to admit.
Backups are fine. They (usually) aren't that hard to do. Although they can be hard to test without a spare machine to test them on. You really don't want to load them back onto your system if they turn out to be corrupt or unreadable. They'd work well for me and many businesses.
However, they aren't going to work so well for online businesses because all the transactions between the last backup and its time of reload will have vanished into cyberspace.
Furthermore, it's probably only a matter of time before the malware folks start poisoning backups and delaying the encryption and ransomware demands for a week or two. What then Kemosabe?
So what's the answer? I don't have one. I don't think anyone else does either. Except maybe a complete, thorough, and no doubt incredibly painful rethinking of what it is safe and reasonable to allow over a worldwide communication system where every scumbag on the planet is your next door neighbor.
Furthermore, it's probably only a matter of time before the malware folks start poisoning backups and delaying the encryption and ransomware demands for a week or two. What then Kemosabe?
That's been SOP since ransomware existed, I'm pretty sure. The only way backups help you is if you've been frequently testing them by restoring onto a system that isn't also infected with the ransomware, and verifying that the content of the files can still be read by whatever applications consume them. A fairly tall order.
"Although they can be hard to test without a spare machine to test them on."
If you have a DR contract this should include provision for testing. You can test a full recovery that way. I found this to be ... instructional. The first test led to changes in the order on which the files were put onto tape. Moving some closer to the start of the tape meant that it was quicker to get some functionality in place so that database restoration could proceed from another tape drive before the file system had been fully backed up.
Testing tells you much more than the simple fact of whether you can restore your system.
"However, they aren't going to work so well for online businesses because all the transactions between the last backup and its time of reload will have vanished into cyberspace."
What sort of online business runs on an RDBMS that doesn't use transaction backups?
Unfortunately I suppose the answer is an ordinary one.
Let's think of what seems an overly old-fashioned concept. A physical server that runs nothing but a basic OS and the RDBMS service. it has a network connection on which only the RDBMS service port is open. It is controlled solely by the console - either a directly connected monitor and keyboard or a serial terminal plugged into tty0 and located next to it. It has its own directly attached media drives for backup and for installing upgrades over trusted media. It's not somebody else's computer.
Before the mutterings of Stuxnet let's remember that we're wanting to proof the system against ransomware, not a nation-state attacker.
But aren't those transaction backups going to be encrypted along with everything else the ransomware can get to? Not being argumentative, just curious. I suppose one can try to make the transaction backups read only. Probably could be done? But likely not as easy as it sounds?
We're dealing here at a level of INSERTs, DELETEs, UPDATEs and COMMITs or ROLLBACKs on the actual data of the commercial transaction as it's being processed. If the order for 3 pairs of socks get s encrypted to 287 in the course of the transaction the user might notice and if key fields get encrypted to different values in the tables that they joins there's liable to be an error thrown PDQ as the indexes become corrupted. OTOH there might be an argument that some product names at Ikea and vendors names on Amazon have already been.
The objective, really would be to keep the database sufficiently isolated from anywhere where a marketroid might click on a phishing email, a dodgy but of javascript downloaded onto a server on the fly or whatever. I get the impression that we have businesses set up with networks of machines with storage shared at file system level so that malware introduced through one is readily written to another if there's an escalation of privilege. That becomes a lot harder if the only traffic to some node is through a single protocol that doesn't deal with file systems. On reflection I suppose it would be possible, given an escalation of privilege to introduce a malware stored procedure but even then change control would help - something like the DBA granting and then dropping the required privilege required to upload SPs. Basically you connect the server to the outside world through a very narrow (in functionality) terms.
I suppose as a sometime DBA I take a paranoid approach but the data which represents the real business needs to be separated from all the wielders of spreadsheets and powerpoint presenters.
Right now I'm chasing a UK financial institution as to why I've been sent a click to confirm email to an address that should be part of my customer ID when the email wasn't intended for me and, of course, only a small number of customers were affected. Clearly that information hasn't been kept where it should as it should.
I think you'd have to put a lot of thought into making sure the attackers found them. If they did find them and believe them, it probably would help, but they're looking for the insurance documents because that's directly related to how much money they could get. They'll probably also be looking for the real financials to determine how much more than the insurance amount they could squeeze out, and the real financials can't include these fictional debts. You need to make arrangements to try to ensure that any attacker with drive access finds the fake finances before they find the real ones, even when they can watch user activity and determine which set of data, the real one unless you're running a professional fraud empire, is being edited most frequently. It probably would work, but if you're putting in that much effort to make it happen, you're probably better served by putting that effort toward security, incident response, or more backups.
I would be curious why there aren't laws that ban paying ransoms for cyber attacks yet. To the point of it being a criminal offence if someone does authorise the payment, not merely a civil penalty, it should be misconduct in corporate office or whatever the equivalent is. And it should go up the chain, none of this forcing the low level IT guy to take the rap, this goes up to the top if it happens.
I can totally get that it might be seen as the only way out, but if you do pay ransoms you create an immediate financial reason to go after the next target. If you make it so that it is literally illegal to do so, it doesn't matter how many companies ransomware gangs hit, they won't get paid.
It would probably result in some pain at first where the gangs try to see if anyone breaks, but in the longer term make the sector safer for all.
It's been suggested many times. Politics moves slowly, and it hasn't been passed. There are some regulations that do prohibit governments who signed on from paying ransoms themselves, but to make it criminal for a private company to pay, you have to pass that law, and none of the major countries involved have bothered to do it.
If they tried, I expect that companies that provide cyber insurance would try to prevent it. Insurance likes to pay the ransom often because it isn't an open-ended charge. They cover a single, known payment rather than getting into a fight over how much of the unknown recovery costs and losses from interruption their policy covers. Since that is more complicated, they'd probably not cover much at all, which means fewer customers for their product. So they stand to lose if that law is ever passed. However, from my knowledge, the lack of the law isn't down to the machinations of big insurance since nobody's tried very hard to start the process and the companies would respond to that.
I think banning ransom payments would be the best possible thing to reduce ransomware. It won't eliminate it, but it will deal it a major disadvantage that no other proposed policy is likely to accomplish. Now all I have to do is get several politicians to agree with that and enact it, then shepherd it through the process where it's very easy to just forget something and leave it unfinished.
I think it's the good chaps rule in operation. If, for instance, some good chaps running a bank have a bit of a misfortune and have to pay out a few million $CURRENCY to get it sorted out that's no reason why a good chap in government would want to see them having to go to prison, not when it's been sorted so easily.
What's more a good chap in government has to look at the bigger picture. For instance in 5 years' time he might be in banking himself and it would be a rum do if he had a bit of misfortune and couldn't get it sorted without his old legislation sending him to prison. A good chap wouldn't want to see that sort of thing happening, would he?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
