One of the most important aspects of security is how to protect the data that is just “sitting there” called data-at-rest. There are many requirements for securing data-at-rest and they were discussed in detail at our SNIA Networking Storage Forum (NSF) webcast Storage Networking Security: Protecting Data-at-Rest. If you missed the live event, you can watch it on-demand and access the presentation slides here. As we promised during the webcast, here are our experts’ answers to the questions from this presentation:
Q. If data is encrypted at rest, is it still vulnerable to ransomware attacks?
A. Yes, encrypted data is still vulnerable to ransomware attacks as the attack would simply re-encrypt the encrypted data with a key known only to the attacker.
Q. The data at rest is best implemented at the storage device. The Media Encryption Key (MEK) is located in the devices per the Trusted Computing Group (TCG) spec. NIST requires the MEK to be sanitized before decommissioning the devices. But devices do fail, because of a 3-5 year life span. Would it be better to manage the MEK in the Key Management System (KMS) or Hardware Security Module (HSM) in cloud/enterprise storage?
A. For a higher level of protection including against physical attacks, a dedicated hardware security module (HSM) at the controller head would be preferable. It’s unlikely to find the same level of security in an individual storage device like a hard drive or SSD.
Q. What is your take on the TCG’s “Key per I/O” work that is ongoing in the storage workgroup?
A. It’s for virtual systems where many different users need to share common resources like storage. This design only covers one aspect of that security. We’re interested in the opinions of those who see a bigger picture of security.
Q. Most “Opal” drives have encryption circuits based on AES-256. How secure is that method?
A. Anything using 256-bit encryption is going to offer a high degree of security, regardless of Opal. Opal provides additional benefits to Self-Encrypting Drives (SEDs) by offering features such as “Locking Ranges” where a different Media Encryption Key can be used for a contiguous (Logical Block Address) LBAs, and each range can be unlocked independently of the others. These LBAs can then also be independently cryptographically erased.
Q. What is your opinion on SEDCLI?
A. As a definition, ‘sedcli’ is an Open Source utility for managing NVMe SEDs that are TCG Opal complaint.It is a new proposal to manage keys in datacenter usage. It enables auto provisioning, hot insert, and multiple key management. So, the use of sedcli will be critical for the management of Opal-compliant drives.
Q. What is the standard on Secured Erase?
A. NIST-SP 800-88 has guidelines for media sanitization.