Are you as tired as I am of movie and television series plots that revolve around super-hackers and super-counter-hackers?
It was bad enough when a bad guy sat down, cracked his (or, less commonly, her) knuckles, started typing, and five seconds later told the uber-bad-guy (no, not a tailgating ride-share-driver), “I’m in!” (Fair’s fair: In the first Die Hard movie the hacker needed a more reasonable hour or so.)
If you’re working on a hacking-related script, please: Have the bad-guy-hacker open a desk drawer, pull out a Post-It®, and type in the password written there. While in the real world this isn’t a reliable method … in a typical office the hacker would have to visit at least five desks … it would at least be plausible.
Accuracy would depict the hacker sending out a spear phishing attack, but I’ll make a concession, given that, unlike your average caper movie, in a hacker plot the process isn’t the point.
Which (in admittedly slow motion) gets us closer to the point of this week’s epistle. But to get there … my wife and I were catching up on a couple of television shows we enjoy. Both of their plots, back to back, were based on ransomware attacks. And no, I’m not going to identify the shows. My guilty pleasures are none of your business.
What is your business is protecting your organizations from ransomware attacks. On a pain scale of one to ten, where one is your level of discomfort following a vaccination and ten is what you experience during an anesthetic-free amputation, these rate about twelve.
What’s most shocking about the ransomware epidemic, both on television and in the real virtual world (now, now, don’t be like that!) is that they are, so far as I can tell, both more preventable and remediable than your typical write-up on the subject would suggest.
But only if you’ve prepared.
What follows are a few basics to get you started. Most are steps you should have taken even before ransomware became prevalent. Next week we’ll dig deeper.
Data can’t be infected. Data can be encrypted, making it inaccessible, which is what ransomware does. But except for macro viruses, data can’t be infected, because … it’s data, not executable. So make sure all of your data resides on different physical servers than your executables. That’s physical, not just virtual.
More important, make sure all of your data backups are read-only, managed by different, air-gapped physical servers.
More important yet, take frequent snapshots and preserve all journal files and change logs for an excessive period of time.
Ransomware discontinues business operations. So include recovery from a ransomware attack in your business continuity plan. Additional thoughts about this:
- If you have two overlapping recovery plans to keep synchronized, they won’t stay synchronized.
- Know how you’ll continue business operations during a ransomware attack. Improvisation after you’ve been attacked is considered industry worst practice.
- As with the rest of your business continuity plan, an untested ransomware recovery plan isn’t a plan, just wishful thinking.
- Hope wasn’t a plan before ransomware became a threat. It’s even more not a plan now.
Reinstall. Make sure you can reinstall, not only applications, but also the platforms they run on. Document every procedure required to rebuild every piece of your production environment, starting with the original installation files. That’s the only way you can be confident you aren’t recovering ransomware executables in your attempts to restore an uncompromised production environment.
Cloud due diligence. Review your cloud vendors’ ransomware recovery plans and make sure they’re up to your standards, especially with respect to data protection. Consider adding on-site, read-only, snapshotted, air-gapped data backups to your cloud architecture.
Bob’s last word: In addition to making sure you have a professional-grade ransomware response plan, rationalize your application and platform portfolios. If you do have to recover from a ransomware attack, recreating the production environment is polynomially simpler in organizations that have consolidated redundant applications and platforms, and whose platforms are sufficiently current that reinstallation will work.
Bob’s sales pitch: I don’t claim to be an expert on this subject (thanks to Mike Benz, who is, for reviewing it).
This isn’t intended to be either gospel or complete. Consider it a nudge, and guidance on where to start digging. If you haven’t been taking this threat seriously … take this threat seriously. It’s shocking how many IT organizations have succumbed to ransomware attacks with little or no preparation. The pandemic-level growth of these attacks is even more shocking, and we’re still at the pre-vaccine stage of dealing with it.
Safe behavior is the best defense. Make sure you’re practicing it.
Security stinks. At least the crapola we have that is called security.
Even NSA and DoD are not immune from getting hacked.
Passwords are useless – all they do is make it hard (or worse) to get to MY data.
Yet the hackers have stolen all of my data from at least 3 major companies and a major university. And thosewere where I did not have an online account NOR a password.
When I worked at the House of Representatives passwords were on yellow stickies put on the displays being used. Users know they are worthless so they avoid the hassle.
At IBM the code to the door to our lab was 1234. Security came through and made them change it. Yep!, the new one was 4321.
People know they will be hacked because the stuff we use is so terrible bad, so they don’t want to be hassled with useless passwords.
Now it is possible to ARCHITECT , DESIGN, and then build a TOTALLY secure system.
I did it in the 70s. Met someone at a conference and they had done the exact same approach on a government contract. It never got used. I suspect NSA killed it because they prefer to able to hack into things more than to keep us from being hacked. No one wanted to buy ours.
A salesman was selling our company something back then and my boss asked him about security. The salesman said nobody would pay for having it.
So we got insecure devices built on insecure operating systems which built an industry that will now fight tooth and nail to stop anyone who would try to design a completely secure system and put them out of business.
I could still ARCHITECT, DESIGN, and have built a totally secure system, but at my age now I have no interest in even trying. I suspect there are a few others who could do it to. And possibly some good management somewhere that could put a team together to do it if they wanted to, and the government let them.
One thing is for sure that you can NOT agile your way to a secure system. And if you doubt that fact try to explain how and also why they have not done it already. Do we just need a few million more patches to get there? Or what?
You lost me on your last point. Your logic: If Agile could produce a secure system it would have already. The rest of your arguments are about how systems designed and developed through some other, unspecified methods (presumably Waterfall) also failed to be secure.
Is it possible to design, build, and deploy a completely secure, bulletproof system? Maybe, if you think biometrics or some other identification validation token can’t be compromised.
But of course, whatever the system it probably exchanges data with other systems, which might or might not be fully secured. And even if these are fully secured, employees at the organization that receives this data could steal it.
Oh, one more thing: Just because you tell us the system you designed and built a totally secure system doesn’t mean you did design and build one. Speaking only for myself, I’m skeptical that you’re any more capable than any other programmer at writing perfectly bug-free code.
That was the point. Nobody has done a brand new total from scratch ARCHITECTURE first. You can agile all you want but windoze is still full of holes no matter how many agile patches are applied.
Stop being hung up on waterfall. There are better methods out there.
No method is perfect but unless you architect first you will never succeed on something big like security.
There are many approaches not just tokens and biometrics.
Of course you would have to use two identical systems or the other one may be full of hackable holes like windoze is.
Fixing people problems is beyond what systems approaches can do. But even those could be reduced a lot if companies would spend the money.
I designed but did not build it. A company in Colorado built it on a government contract. But it got killed so NSA could keep breaking into things instead of being kept out of them even if they were ours.
All code has bugs but there are ways to ensure that code will be safe but only if you ARCHITECT first and then enforce the IT weenies to follow the design and not start ad libbing and certainly not trying to ‘improve’ it.
It will take longer and cost more but the trade off is security and risk if we keep doing things the same way.
A large number of years ago I won a bet (dinner) with a client: that I could hack into a majority of his servers. UNIX machines in a major corporation. All I had to do was log into the root user on each server with the factory setting for the password.
I would like to believe that things have got better since then. What I actually believe is a lot less optimistic.
@Michael D. Langfield
unix and now liinux were not designed to be totally secure. considering how many antivirus companies are making a good living fixing problems it is clear that nothing has gotten better since way back when.
Bob made a point we need to consider. What we are running is not secure, and there is no hope it will be. Bad guys can and will get into it. So we better be in a position to recover it. And to do that we have to plan ahead. It is not easy to rebuild hundreds of servers that have been built over many years/decades. It is very difficult without a plan.
The alternative is to have a business that is losing money and therefore not attractive to anyone. Customers or ransomware hackers.
Thanks, Scott, especially for the innovative solution you suggest at the end of your Comment. Why didn’t I think of it?