This is incredibly dumb. SSD firmware exists at entirely the wrong level to protect against threats like ransomware or data theft -- it cannot identify what application is performing disk accesses and what data is being accessed, know whether that access should be authorized, or display prompts to the user to determine whether a given access should be allowed. All of these things are only possible in software.
My money says that their "dynamic data defense engine" is functionally independent of the SSD, and only requires their branded SSD to be installed as a licensing dongle. Describing this as a feature of the SSD is entirely a marketing ploy. And, because hardware companies are generally not very good at making decisions about software, the software they're bundling is probably less effective than a standalone security suite would have been.
It's actually a great place to perform some types of mitigations (I'm not sure if these are done by this specific product though). Here's an example:
A ransomware attack will rewrite large sections of the drive. Initial phases aren't distinguishable from things like updates but as it progresses the intent becomes more clear. An SSD can leave a ring buffer of old blocks around and transparently revert back if an attack is discovered.
You could also do this as part of the filesystem, but the SSD already has to perform wear levelling and so is quite adept at transparently remapping blocks. It also has the benefit of hardware acceleration in the controller. It's not necessarily a bad place to implement the recovery.
"large sections of the drive" are virtual in SSD. Overwriting a file doesnt mean rewriting same sectors, and once system TRIMs a piece of disk it stops existing. For this to work Disk device would have to understand file systems, be able to decode NTFS etc.
To better understand this consider LVM - it does not understand the filesystems on top of it yet it can still restore from a snapshot. Unfortunately LVM snapshots suffer from performance penalties an SSD could avoid.
Modern SSDs have maybe 5-8% overcommit. Where do you presume a 1TB SSD will snapshot 900GB of my documents as they are overwritten with 900GB of encrypted data? 900 + 900 > 1024...
If 5% of a drive was rewritten I think that would be a reasonable time to interrupt the accompanying software driver and determine a reasonable response. It is not necessary for the drive to revert the full size of the drive, merely enough data to reduce the false positive rate from normal activity.
I think the hangup is the assumption the drive has to do 100% of the work. It is only needed to accelerate the snapshots for restoration after an attack is detected. Determining whether the system is under attack and the correct response can be done in software.
On a larger note the remapping engine in an SSD makes for a great primitive. It would be awesome if SSDs exposed this in a more general way.
Sure, but it could be use configurable. For the actual problem of a cryptolocker it's pretty easy to detect the entropy change. You'd really only need to see the diffs a few files to decide something bad was happening.
In any case users don't expect snapshots to be free.
Entropy is a poor way to detect cryptolockers. For example, many OSes encrypt user data in software (ntfs has "encrypt" built in and is it commonly used).
SSD firmware is simply NOT the place to do this. This is the same reason we do not implement HTML parsers in the kernel or javascript runtimes in BIOS. Too high level of a concept in too low level of a place
I see now my original comment was poorly written. I only intended to imply the SSD would be used for reverting encrypted files as part of a rolling snapshot. It would have to work in conjunction with traditional AV software to actually detect an attack. If it were actually used this way its not crazy the AV software would require the specific hardware it was designed for.
I don't think we disagree the remapping hardware could be repurposed for assisting the creation of COW snapshots, though obviously the disk space wouldn't come for free.
> Initial phases aren't distinguishable from things like updates but as it progresses the intent becomes more clear.
I'm not convinced it does at all. Encrypting a bunch of files one by one is going to be indistinguishable at the block layer from other common operations like updating software, transcoding media files, or creating a compressed archive.
Besides, I still haven't heard a convincing argument that the SSD controller could detect and respond to this any better than the OS could. At best, it might be able to do a poor job of it.
The SSD is not there to do the detection but to allow fast reverts of encrypted files once it is detected. Remapping blocks is a core operation for creating COW snapshots and the SSD already has to do it quickly for wear levelling. Software like LVM can already create snapshots at the block level but being software it has a performance penalty the SSD would not have.
Traditional AV software still has to do the detection and its capable of that long before the entire drive is rewritten.
My thoughts exactly. First thing I checked is if I recognized the SSD vendors. "Cigent and Phison" both sound like BS names to me. Maybe they've done some real things but I don't put much credibility in it.
Phison is a less well-known maker of many SSD controller chips. Some top end manufacturers make their own controller chips, but most don’t — they buy them from companies like Phison.
The fact that these SSDs have to “phone home” in order to do some of their tasks is what gives me the really big heebie-jeebies.
Thanks, but no thanks. That’s about as bad as eMailing password reminders because you stored them in plaintext or reversible encryption. There is just no way of fully and properly protecting your data, then.
17 comments
[ 3.3 ms ] story [ 49.7 ms ] threadMy money says that their "dynamic data defense engine" is functionally independent of the SSD, and only requires their branded SSD to be installed as a licensing dongle. Describing this as a feature of the SSD is entirely a marketing ploy. And, because hardware companies are generally not very good at making decisions about software, the software they're bundling is probably less effective than a standalone security suite would have been.
A ransomware attack will rewrite large sections of the drive. Initial phases aren't distinguishable from things like updates but as it progresses the intent becomes more clear. An SSD can leave a ring buffer of old blocks around and transparently revert back if an attack is discovered.
You could also do this as part of the filesystem, but the SSD already has to perform wear levelling and so is quite adept at transparently remapping blocks. It also has the benefit of hardware acceleration in the controller. It's not necessarily a bad place to implement the recovery.
I think the hangup is the assumption the drive has to do 100% of the work. It is only needed to accelerate the snapshots for restoration after an attack is detected. Determining whether the system is under attack and the correct response can be done in software.
On a larger note the remapping engine in an SSD makes for a great primitive. It would be awesome if SSDs exposed this in a more general way.
Source: have written FTLs that shipped in products
In any case users don't expect snapshots to be free.
SSD firmware is simply NOT the place to do this. This is the same reason we do not implement HTML parsers in the kernel or javascript runtimes in BIOS. Too high level of a concept in too low level of a place
I don't think we disagree the remapping hardware could be repurposed for assisting the creation of COW snapshots, though obviously the disk space wouldn't come for free.
I'm not convinced it does at all. Encrypting a bunch of files one by one is going to be indistinguishable at the block layer from other common operations like updating software, transcoding media files, or creating a compressed archive.
Besides, I still haven't heard a convincing argument that the SSD controller could detect and respond to this any better than the OS could. At best, it might be able to do a poor job of it.
Traditional AV software still has to do the detection and its capable of that long before the entire drive is rewritten.
Thanks, but no thanks. That’s about as bad as eMailing password reminders because you stored them in plaintext or reversible encryption. There is just no way of fully and properly protecting your data, then.