I had an interesting conversation about data integrity attacks recently. Those involve altering records, rather than stealing them. The initial reaction was that they’d just restore from backup (like a disaster recovery plan). When I pointed out that most advanced attacks are in the environment for months before discovery, the light bulb went off: You can’t roll a big enterprise back a couple hundred days. Disaster backups are insufficient as security backups. So what do we do?
I’ve written before about the advent of integrity attacks – changing information, rather than stealing it or denying access to it. Stuxnet was such an attack, where it was used to change values on the control systems that later destroyed the equipment. Other examples are the classic student changing grades that we saw in Wargames, or changing the expiration date on an account to gain free services. Those are simple examples, where a single point in time change achieves the desired results.
On the other hand, more complex attacks, where the changed data is then used for subsequent transactions – or critical business decisions – present a far more difficult challenge. Let’s take a theoretical example: changing financial records to manipulate earnings reports or equity or commodity prices. Both internal and external decisions have been made based on that information, potentially for weeks or months before discovery.
Disaster recovery systems, even with a near-real-time replication capability, don’t help with either of those, as they’re generally designed to return the entire system or organization to a point in time. While we can probably use granular backups to recover from simple changes, for ones with dependencies, RPO (recovery point objective) doesn’t have much meaning– you can’tsimply recover to a previous state in those cases.
So the conversation turned to having robust transaction logging strategies. For simple changes, that are independent in scope (like changing grades), once detected (no mean feat itself), they definitely help with recovery. Simply undo the transaction and Bob’s your uncle. For dependent transactions, it’s far more difficult, and as much a legal and policy issue as technical problem: if someone manipulates a stock price through cyber means, how is that any different from pump and dump or outright earnings fraud? We don’t roll back the stock market in those cases, so we wouldn’t for a cyber attack either. Yet there’s often a knee-jerk assumption that we can ‘always restore from backup if we get hacked.’
And that’s my point here – our current backup and recovery strategies aren’t as broadly applicable as we might assume. BC/DR use cases are very different from integrity recovery (though BC/DR definitely helps with ransomware recovery). I’m not sure we can really plan a response for a dependent attack, as there’s too many variables to account for. In any case, these conversations are just starting to pop up, and no one has a clear answer yet. I’d love to hear any ideas or thoughts you might have in the comments section below.
