The cause is definitely technical, it is a huge gaping hole in the design of modern operating systems that you could sail the Ever Given through sideways without incident.
Your operating system does not confer to the user the ability to delegate only X resources to the opening of a file, email, etc. They (the users) have no ability to limit side effects. Blaming them for your bad system isn't ever going to help fix things.
The missing system of limiting side effects is known as Capability Based Security. We all have a practical example of it in our wallet or purse. We can remove a unit of currency, hand it to someone else for a purchase, and that is the maximum we can lose, unless something extraordinary happens.
We all have outlets, which limit the amount of power they will supply, and some even check to make sure it isn't supplied through us, or into a system that has arcing issues. We never have to worry that turning on a lamp will take down the power grid.
Imagine if there were no circuit breakers or fuses, would blaming people for not being careful enough help make the system safer? No, of course not. Neither does blaming the user for your defective Operating System.
Not that you don't have a point, but outlet safety measures only address accidental failures. A malicous device is perfectly capable of storing power in a battery or capacitor to exceed instantaneous power limits, or running at 12 amps (out of 15A fuses) 24/7 to pull much more power than you expect over time, or electrocuting you taser-style even if it doesn't have a high-current ground path. So while the safety features are useful, they're not particularly relevant to security.
The wallet example is pretty good, though, as is your actual point.
Wondering how we're going to remember the times before proper capability based security systems go mainstream...
You can prevent ransomware fairly simply by following best practice, and taking some steps that most companies will feel are excessive (but effective), such as whitelisting binaries, preventing running of any binaries not on that whitelist, and keeping that whitelist up to date on a regular real-time basis. Nobody wants to spend the time doing this, so they leave it a "free-for-all".
Exploiting user-level access is just the natural escalation now that getting good exploits is more costly and difficult. Now attackers will "make do" wiht what they have. IT can win the battle, but with inconvenience, friction, and increased costs in IT.
There's important businesses that are "critical infrastructure" still using Windows 7 on their corporate day-to-day let-me-check-my-emails-and-browse-the-web laptops, without extended support. Organisational inertia and a lack of recognition that they need to pay for the technology that enablers their business leads them to this position.
As weird as it sounds, this is both correct and incorrect at the same time.
It is correct, because ransomware is not particularly sophisticated by today's standards. Couple of decades of R&D has made the building blocks robust and uninteresting.
It is also correct in the sense that the attacks used to breach systems are unsophisticated. A vulnerability is published for an internet-facing system, and in just couple of days the underground toolkits are already (ab)using it.
It is incorrect in the sense that the crews who breached the systems are not the crews who deploy ransomware. Computer crime has evolved to a fully functioning economy, with high specialisation among its participants. Crew A reverse-engineers patches, updates their vulnerability exploitation engines and goes on to breach systems. (In a race against time, because there are other crews doing the same.) They then sell access to crews B, C and D.
Crew B are after financial information and will exfiltrate anything that can be sold to morally ambivalent hedge funds. They may also grab R&D material, because corporate espionage is a thing. Crew C will grab all the personally identifiable data and have intimate knowledge how to best monetise it for various types of fraud.
Crew D will deploy the ransomware, because they have all the sophistication you need to run their extortion operations at scale. These days this includes the ability to handle massive volumes of off-site backups, because why not. "Pay up or we leak it" is a perfectly valid extension to their business model.
The gangs I referred to as "Crew A" are known in the industry as Access Brokers. There are of course other operators too who work in a more asynchronous fashion, such as money launderers.
The economy powering the criminal enterprise markets is certainly sophisticated. And while most of the technology in use doesn't qualify for using that word, the internal operations these gangs run certainly do.
If it gets in through an access broker, you're definitely looking at a sophisticated outfit of attackers.
I guess I'm approaching this as the defender - if the malicious code isn't exploiting anything needing patched (other than decades-outdated assumptions of a threat model where any binary has the ability to act inseparably "as" the user), the actual ransomware is harder to prevent for most organisations, as all the friendly hand-holding type advice they receive from police and governments doesn't save them (patching desktop systems won't prevent the file encryptor payload from running on the first host, after a user runs the bogus docx.exe file and ignores warnings through alert fatigue).
It would be interesting if companies were more willing to (or required to) share details of ingress vectors, to understand the extent to which they're being breached through really advanced attacks involving reversing of recent patches, versus someone popping a pulsesecure VPN that's been warned about for years. Or on-prem Exchange that they've continued to ignore all the warnings about as nothing is on fire. Or just a user clicking a link to a shared file mistakenly emailed to them, called CONFIDENTIAL - PAY SCALE 2022, which phishes their SSO credentials for 365...
Eg. an application is only allowed to touch 100 files per second or 1000 files per hour.
When it reaches those limits, it gets paused and a popup asks the user if this application really should be doing X.
Then at least ransomware can't run through stuff too quickly.
A rate limit, with group-policy controllable "automatic response" would perhaps help - you need the GPO integration though so that an IT admin can say "never allow file system rate limit to be exceeded".
If you enforce a rate limit locally, and on the network, and move to copy-on-write filesystems, it would be a whole lot harder to cause straightforward harm (at least while migrating to a newer, safer OS architecture paradigm, where code doesn't run as the user).
In the post-Covid world, I think MS and others have a whole host of these kinds of issues to think about - Windows in an AD environment is still (as far as I know) not something really geared for working off-prem. It still relies heavily on LDAP and CIFS etc. A re-write to get a desktop OS ready for the "web first" world (where everything is sent to the AD domain TCP/443, using HTTPS, with client certificates rather than passwords, stored locally via hardware-backed secure storage, and trusted CAs used by the DC) would be a big first step towards this. Yes, I know you could use Direct Access or whatever MS has butchered into the system, but in a world moving to zero trust, MS needs to move to zero trust.
Rate limits would be a great starting point, as would some proper platform-level protections around preserving shadow copies, using copy-on-write, and locally preserving versioned user files as a priority. As soon as a ransomware attack touches the network, IT should be able to handle it, as their backup regime should take effect. At that point, if you don't have backups sufficiently separate from user-writable files (or you never validate them, and thus don't realise you're backing up transparently encrypted ransomware'd files for months), you're on your own!
Cost cutting is probably the biggest threat to most businesses. The mythos of the hyper-converged infrastructure, with the datastores and repositories for backups being hosted on the same physical device, are some sort of infection that just cannot be wrenched from people's heads.
IT Professionals (not managers, not hapless non-techies, actual persons with a cornucopia of certs and accolades on their linkedin) are in denial as to how to design a proper infrastructure to respond to ransomware. At this stage and for the foreseeable future, Ransomware is an inevitability; not "if" you get attacked, "when". But the countless number of conversations I've had where basically a group of people from the IT department theorycrafted a perfect defense only to get attacked because one of them clicked on a random excel document from a spoofed email is too high.
When clients ask me "what do we need to do to protect against ransomware" and I explain what airgapping means (tape, removable drive arrays), we're either ignored, or they say they accept and the clients just don't have the discipline to follow the required practices.
Modern IT prefers cargo-cult security, and IT professionals love their checklists from some organization, regardless of the fact that most of the checkboxes are useless to protect against ransomware. But the professional can eschew responsibility because "hey, I checked all the boxes."
Until technical professionals as a whole start to take security seriously and exhibit the discipline that is required for such security right now, Ransomware is going to continue to be prevalent. No amount of rate limiting from vendors will help, because users will simply just not use such versions, will disable such limits, will work around such limits, or any of dozens of workarounds to avoid it because such limits would be inconvenient (neverminding such limiting tooling probably will just be exploited)
We need discipline first, not tooling to try to correct for lack of discipline.
“The thing” would not work as an unprivileged user account and would only work as a right click run as administrator situation :-)
> IT departments will never have enough money/time/staff to keep systems up to date with the latest OS (look at the number of people still running critical systems on Windows XP).
Why is it that even slightly old systems are so buggy that they are trivially hackable for a moderately well funded group?
Modern security is based primarily on security through obscurity. As long as you stay up to date, all of the bugs you have are sufficiently obscure that knowledge about them is probably too expensive for the type of hacker that would target you.
> Users will always open attachments from people they don't know, click links, or even pick up random USB sticks.
Why is any of that a problem? A user should not be able to threaten an organization's IT system even if they were outright hostile (unless they were put in a specific position of trust within IT; but even then the amount of damage they should be able to do from their personal work computer should be limited).
Because there's not enough money in making things bug-free from the start. It is possible (see seL4 and They Write the Right Stuff), but the incentives aren't there.
Some kind of liability or minimum standard (similar to building code) would help, but I'm not sure just how it would be best implemented.
You're not wrong about why it doesn't exist, but I'm not convinced the market conditions exist to rectify that.
because software is tremendously complex with a large surface area to attack. And many OS features were designed when wide-scale hacking was not a problem.
You can better believe software running an aircraft carrier has been hardened 12 ways til sunday. Prosumer operating systems - not so much.
Slightly old here means 13 years after the latest release in case of Windows XP.
That's a very long time for anyone to upgrade.
"My puppy just got hit by a car! Can I come in and use your phone to call for help?"
I'm not saying it'd be easy to do, but rather that it'd be a nice thing for the world if they did.
These are facts of life and need to be expected. Not saying that security training is wasted money, but it is in no way a solution to for example phishing. Accept that you will have compromised clients and internet facing servers and start making a strategy with that scenario in mind.
In fact, there were systems built this way in the 70's.
It's not like Microsoft has an explicit EOL date announced for every OS release...
IT is a cost to their business, not a revenue source. They don't consider the counter-factual of "well, what if we didn't use IT and computers and the internet" when valuing what IT is bringing to their business. If they did, they'd perhaps be willing to spend more.
MBAs don't like spending money on something that doesn't yield them more sales though...
Since there's no visible problem (nothing catches fire) the day, week or month after cutting spend on IT, it's an unnecessary expense in the eyes of beancounters.
One bank I interned at sent people an email about the weather or something to that extent and each link had a unique identifier. Shaming each individual user is the best way for them to learn.
It's the best way for them to stop trusting the security team and never come in with any issue, even if it could be used as an early signal preventing bigger attack. Many people's jobs rely on them receiving emails from unknown sources and receiving files from them. Shaming them for "you should've known this specific link is bad" is counterproductive. That's even before we get to whether they would actually put in any credentials.
Phishing tests have value. Running them to shame people into compliance is a waste of time.
For better takes, there's a good thread https://twitter.com/hacks4pancakes/status/133487573995560550...
IT departments will never have enough money/time/staff to keep systems up to date with the latest OS (look at the number of people still running critical systems on Windows XP).
Users will always open attachments from people they don't know, click links, or even pick up random USB sticks.
The perpetrators know this. They don't need to be more sophisticated than the InfoSec people at a given organisation, they just need to trick one user in that organisation in to letting them on to the network.