3 ms·

Indeed - I think Windows Defender dabbled in offering this as a feature. I at least recall seeing programs prevented from creating files in the Desktop or Docum

by g_p 5y ago

Indeed - I think Windows Defender dabbled in offering this as a feature. I at least recall seeing programs prevented from creating files in the Desktop or Documents folders. 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!

csydas 5y ago
My business involves working a lot with such situations, and frankly speaking, none of the above would help in the least bit. 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.

by g_p 5y ago

csydas 5y ago

My business involves working a lot with such situations, and frankly speaking, none of the above would help in the least bit. 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.