Great, does this mean we can bring back VMS's semicolon operator?

MYFILE.TXT;1

MYFILE.TXT;2

It would never overwrite a file, instead, it gave you a new version ;2 ;3 etc.

The PURGE command would then kill off the plethora of old versions.

You misread the article. Thats exactly the command as it exists in the SSD firmware ;)

That's the feature of VMS which I miss more than any other. I'd pay good money to have it available on Linux.

I get something like it by using the [1]NILFS2 filesystem . It has some downsides (no ACLs, for example), but I have been using it for years. Convert checkpoint to snapshot, mount snapshot read-only, recover previous version of file going back as far as the circular buffer allows. Of course, it might not be suitable for your particular use case, but I landed on it after looking for VMS-like behaviour with file versioning.

It is a pity that btrfs and bcachefs apparently can't do the same. I would love to be shown to be wrong.

NN

[1] https://en.wikipedia.org/wiki/NILFS

This is a neat idea conceptually. However if widely taken up, technologies such as this could also lead to rapid escalation of the threat, as perpetrators often have access to significant expertise and can counter relatively narrowly specified mechanisms quite soon after they are implemented.

I suspect that the strongest protection is still not allowing ransomware (or any other malware) to enter the organisation in the first place (or at least catching at or near the boundary before it gets a hold). It's interesting that the Jericho project didn't persist, or lead to widespread changes in the way we protect our infrastructures. De-perimeterisation never really took off.

It's not a panacea but as part of a multi-layered defense I think it may have more value that you are crediting.

rapid escalation of the threat

That was my initial take, too. It's unlikely you'd put all the functionality in the firmware - there'd presumably have to be some external interface through which suspected corruption could be reported and recovery attempted. And as soon as you have an external interface that allows the reassignment of data blocks between files, you have another potential exploit path.

Having said that, one of the big hazards of ransomware is not noticing until your entire backup cycle has also been corrupted. If you can come up with an early alert, that would be incredibly valuable. And presumably you could apply the same principles of detection to any storage medium that avoids rewriting blocks in place - either at the device level (like shingled magnetic recording) or at the filesystem level (journalling file systems).

That an SSD can detect infection is already a surprise to me, but what really takes the cake is the "unexpected encryption" part of that declaration.

Please explain to me how an SSD can tell if an encryption is expected or not.

How can an SSD make the difference between the used deciding to encrypt files on the SSD and malware residing in RAM doing it ?

I would really like to know, and then explain to me how a malware author is not going to be able to replicate that.

The vast majority of files have a header that does not change, if suddenly a lot of files are having their headers muddled up then it's a high probability something wrong is happening.

That's the easiest approach, I assume they've got some other detection modes running.

As for miscreants fooling the detection, well inevitably after a while - not encrypting the first (and maybe last) few K of each file might be enough.

As with all white hat/black hat battles it's an ongoing effort of attack and counter-attack - as long as the firmware can be (safely and securely) updated, but that introduces a new attack vector so it can all rapidly get quite complicated.

How does the firmware know what constitutes a file? At that level they're just blocks; they don't become files until they're processed by the filesystem and the filesystem driver is in the kernel* (ie software)

That's a rhetorical question, by the way.

(* or at least hooked into it)

Valid points, this would be far better implemented at the file system level and probably easier too which makes me wonder why the file system writers haven't come up with something along these lines.

Going further, how can a SSD tell if a file is encrypted or not? What is to prevent the ransomware creators triggering a TRIM command after a few encryptions? How does the system detect between ransomware encrypting files and a safe, bulk file operation?

It is an interesting concept. But they aren't thinking like the baddies. To thwart this system, all the ransomware has to do is encrypt a few files, run a TRIM operation, and then repeat until all the files are encrypted. The ransomware could even stagger the operation -- do 4 in the morning, another 4 in the afternoon, another 4 in the evening. It would, at least, stop the older ransomware infections. But I can already see how the blackhats can get around it.

Duh. Its you thats not thinking it through. If the solution is in firmware the Trim command is also subject to interception and nulling/modification by this solution. Trim becomes "Trim everything except 1 known good copy".

Going further, how can a SSD tell if a file is encrypted or not? What is to prevent the ransomware creators triggering a TRIM command after a few encryptions?

TRIM is an irrelevance here. For a start is doesn't actually delete any data, it simply marks logical blocks as not containing needed data so they can be overwritten without the data needing to be preserved first - the data itself gets overwritten at a later point on an as-needed basis.

Secondly it refers to logical blocks only. In this case where data is (logically) overwritten in place the physical blocks are replaced by spares. The logical blocks are still valid so there isn't anything to trim. The blocks containing the old data are marked as available for reuse but as before, that occurs on an as-needed basis rather than straight away.

"Please explain to me how an SSD can tell if an encryption is expected or not."

That's what the mentioned software is for. Up pops the anti ransomware software notification "We have detected an unusual amount of files being encrypted. Is this you or ransomware?"

The threshold for the pop up will determine if the feature is nagging or not, but seeing as up to 10s of gigabytes of encrypted files could be reversed in minutes, that threshold can be very high.

You'd better have that software running all the time. If it's not there while, say, encrypting a drive for the first time it's likely the whole drive will be corrupted. Of course, anyone doing that would take a backup first.

Having worked through a ransomware attack the flaw in his argument a backup strategy isn't a great mitigator for a ransomware attack.

Firstly it requires extensive use of hot incremental backups to avoid significant data loss. The majority of firms still don't (and won't) do this.

Secondly the ransomware process is generally incremental itself which means you need a file by file analysis during the restore to figure out the most recent hot copy that's not encrypted.

Assuming this solution isn't snake oil it has the massive advantage it doesn't require proactive action by the users. You just specify these disks at purchase time and you are mostly protected.

Also whilst not underestimating the ransomware baddies - understanding actually how this protection works and circumventing it would not be a trivial task imo, as its operating several layers down the stack from where they operate at the OS level. They are good at finding OS exploits to get privileged access. I've seen no evidence as yet they can move deeper into the stack.

Again assuming it really works - as part of a layered anti-ransomware strategy I think this has promise. The latency is probably amenable to additional design or embedding some of the solution in hardware .

If the SSD manufacturers won't do it, why not build a box with a SATA plug and socket on it, that proxies all requests to the SSD, performing the ransomware detection and file versioning. Yes the performance will be worse, but for normal desktops it might be worth it.

I would like to see some independent testing to see if it lives up to the claims. Do they see this as something like anti-virus where it can update the firmware should new threats/circumventions come along?

Seems to me a limit on the number of files that can be modified/deleted/written per day would be a fairly effective protection for a home user. I rarely work on more than 15 or 20 separate documents in a day, so just warn me if I'm working too hard.

Also - code in pub opening hours. If I am editing a document > 1 hour after opening time it probably isn't me, and if it is me, its probably a bad idea.

Pubs around here open by mid-day.

Hmm... nice thought.

Icon——-> by 4 in the afternoon.

They illustrate a range of approaches to "solving" the ransomware problems and extend ransomware too. I think this describes is a good precaution, it's not a solution but it could be very helpful. The solution is more likely to build a new operating system that prevents the entire malware attack methods - but I can't see that happening because it would have to limit many of today's commercial data theft "features".