With ever increasing threat vectors both inside and outside the data center, a compromised customer dataset can quickly result in a torrent of lost business data, eroded trust, significant penalties, and potential lawsuits. Potential vulnerabilities exist at every point when scaling out NVMe® storage, which requires data to be secured every time it leaves a server or the storage media, not just when leaving the data center. NVMe over Fabrics is poised to be the one of the most dominant storage transports of the future and securing and validating the vast amounts of data that will traverse this fabric is not just prudent, but paramount. Ensuring the security of that data will be the topic of our SNIA Networking Storage Forum (NSF) webcast “Security of Data on NVMe over Fabrics, the Armored Truck Way” on May 12, 2021. Join the webcast to hear industry experts discuss current and future strategies to secure and protect mission critical data. You will learn:

• Industry trends and regulations around data security
• Potential threats and vulnerabilities
• Existing security mechanisms and best practices
• How to secure NVMe data in flight and at rest
• Ecosystem and market dynamics
• Upcoming standards

For those of you who follow the many educational webcasts that the NSF hosts, you may have noticed that we are discussing the important topic of data security a lot. In fact, there is an entire Storage Networking Security Webcast Series that dives into protecting data at rest, protecting data in flight, encryption, key management, and more. You might find it useful to check out some of the sessions before our May 12^th presentation. Register today! We hope you will join us on May 12^th. And please bring your questions. Our experts will be ready to answer them.

Last month, the SNIA Networking Storage Forum (NSF) took a different perspective on the storage networking technologies we cover by discussing technologies and practices that you may want to reconsider. The webcast was called “Storage Technologies & Practices Ripe for Refresh.”  I encourage you to watch it on-demand.  It was an interesting session where my colleagues Eric Hibbard, John Kim, and Alex McDonald explored security problems, aging network protocols, and NAS protocols. It was quite popular. In fact, we’re planning more in this series, so stay tuned.

The audience asked us some great questions during the live event and as promised, here are our answers: 

Q. How can I tell if my SSH connections are secure?

A. Short of doing a security scan of a server’s SSH port (typically TCP/IP port 22) it can be difficult to know if your connection is secure. In general, the following are recommended: 

1. Use SSH version 2 or later
2. Disable server SSH root logins
3. Authenticate clients to servers by using SSH key pairs (don’t use the same keys on multiple systems)
4. Change the default SSH port
5. Filter connections using TCP wrappers or similar network filtering
6. Set idle timeouts that close SSH connections. If you don’t need SSH on a server, make sure it is disabled.

Q.  How can customers determine if they are using updated security technologies? 

A. Security technologies can be both security features/capabilities as well as elements that address the security posture of a system at any given point in time. From a feature perspective, it is often difficult to change or add them, so it is important to consider requirements for things like encryption, key management, access controls, etc. up front; assume that what you start with is probably all that you will get going forward. Security posture, on the other hand, can be very different. It typically involves configuration changes (e.g., enabling/disabling a security feature), applying patches to operating systems and applications, and updating software to newer versions when security patches are no longer available or are inadequate. Performing regular security scans of systems is also an important element because they will help verify the system is being maintained properly as well as to provide alerts for new problems as the threat landscape changes.

Q. This is not really a question, but rather a comment on NAS protocols, their security is only as good as the authorization on the files. e.g. 777 or everyone type ACLs.    

A. The NFSv4 and SMB3 protocols are as secure as you want to make them. Assigning inappropriate authorization is a user error, not a protocol problem.

Q. Can most modern storage systems and operating systems support NFSv4 and SMBv3?         

A. The majority of NAS systems from most vendors can support NFSv4 and SMB3, and many will allow access to the same files with either protocol. (But see the caveats below.) There’s the open source Samba (see here  for a protocol that’s SMB3 for Linux and Unix), and Microsoft Windows Server supports NFS v2 v3 and v4.1. 

Q. Do obsolete protocols have an impact on multi-protocol (NFS + SMB) access to data? 

A. Yes, in several areas; the two biggies are security and locking. On security, NFS and SMB share in common the same terminology (ACLs or access control lists) to describe the security on objects like files and directories; but the underlying security models are different. See this NFS4 ACL overview for more details. Locking is a complex area, and the general rule is; don’t share files between SMB and NFS unless you’re fully aware of how locking works. Obsolete protocols definitely don’t help here, so best avoided. Even with up-to-date protocol stacks there are lots of other gotchas. If you must share between NFS and SMB, involve the vendor of the system that is providing you with this capability, and adhere to their best practices. 

From a security perspective, multi-protocol access to data is fraught with access control problems because the access privilege models can vary significantly. This can lead to a situation where an escalation of privileges can occur, granting someone access to data that they should not be allowed to access. Adding obsolete protocols to this mix can further expose data because of the granularity of the access privilege model or complete lack of one.

Q: Could we use robust log system and real-time analysis and real-time configuration, in the transport layer?

A: The network transport layer is Layer 4 in the 7-layer OSI model, most commonly using the TCP or UDP protocols. Both packet logging and filtering tools can be used to monitor Layer 4 traffic, and real-time analysis can be done by a packet analyzer, firewall, intrusion detection/prevention system (IDS/IPS). These tools typically allow capture or filtering of packets based on a combination of their source and destination IP addresses, source and destination ports, and the protocol type (TCP/UDP). More sophisticated networking equipment might also track connections and use deep packet inspection to identify applications at OSI layers 5-7 in the network traffic. Doing such analysis can identify the use of obsolete protocols or applications or detect malware or suspicious activity. Real-time configuration could be used to turn off obsolete or unneeded protocols on servers that no longer need them or to block their traffic from using the network.

Last month, the SNIA Networking Storage Forum (NSF) took a different perspective on the storage networking technologies we cover by discussing technologies and practices that you may want to reconsider. The webcast was called “Storage Technologies & Practices Ripe for Refresh.”  I encourage you to watch it on-demand.  It was an interesting session where my colleagues Eric Hibbard, John Kim, and Alex McDonald explored security problems, aging network protocols, and NAS protocols. It was quite popular. In fact, we’re planning more in this series, so stay tuned. The audience asked us some great questions during the live event and as promised, here are our answers: Q. How can I tell if my SSH connections are secure? A. Short of doing a security scan of a server’s SSH port (typically TCP/IP port 22) it can be difficult to know if your connection is secure. In general, the following are recommended:

1. Use SSH version 2 or later
2. Disable server SSH root logins
3. Authenticate clients to servers by using SSH key pairs (don’t use the same keys on multiple systems)
4. Change the default SSH port
5. Filter connections using TCP wrappers or similar network filtering
6. Set idle timeouts that close SSH connections. If you don’t need SSH on a server, make sure it is disabled.

Q.  How can customers determine if they are using updated security technologies?  A. Security technologies can be both security features/capabilities as well as elements that address the security posture of a system at any given point in time. From a feature perspective, it is often difficult to change or add them, so it is important to consider requirements for things like encryption, key management, access controls, etc. up front; assume that what you start with is probably all that you will get going forward. Security posture, on the other hand, can be very different. It typically involves configuration changes (e.g., enabling/disabling a security feature), applying patches to operating systems and applications, and updating software to newer versions when security patches are no longer available or are inadequate. Performing regular security scans of systems is also an important element because they will help verify the system is being maintained properly as well as to provide alerts for new problems as the threat landscape changes. Q. This is not really a question, but rather a comment on NAS protocols, their security is only as good as the authorization on the files. e.g. 777 or everyone type ACLs.     A. The NFSv4 and SMB3 protocols are as secure as you want to make them. Assigning inappropriate authorization is a user error, not a protocol problem. Q. Can most modern storage systems and operating systems support NFSv4 and SMBv3? A. The majority of NAS systems from most vendors can support NFSv4 and SMB3, and many will allow access to the same files with either protocol. (But see the caveats below.) There’s the open source Samba (see here  for a protocol that’s SMB3 for Linux and Unix), and Microsoft Windows Server supports NFS v2 v3 and v4.1. Q. Do obsolete protocols have an impact on multi-protocol (NFS + SMB) access to data?  A. Yes, in several areas; the two biggies are security and locking. On security, NFS and SMB share in common the same terminology (ACLs or access control lists) to describe the security on objects like files and directories; but the underlying security models are different. See this NFS4 ACL overview for more details. Locking is a complex area, and the general rule is; don’t share files between SMB and NFS unless you’re fully aware of how locking works. Obsolete protocols definitely don’t help here, so best avoided. Even with up-to-date protocol stacks there are lots of other gotchas. If you must share between NFS and SMB, involve the vendor of the system that is providing you with this capability, and adhere to their best practices. From a security perspective, multi-protocol access to data is fraught with access control problems because the access privilege models can vary significantly. This can lead to a situation where an escalation of privileges can occur, granting someone access to data that they should not be allowed to access. Adding obsolete protocols to this mix can further expose data because of the granularity of the access privilege model or complete lack of one. Q: Could we use robust log system and real-time analysis and real-time configuration, in the transport layer? A: The network transport layer is Layer 4 in the 7-layer OSI model, most commonly using the TCP or UDP protocols. Both packet logging and filtering tools can be used to monitor Layer 4 traffic, and real-time analysis can be done by a packet analyzer, firewall, intrusion detection/prevention system (IDS/IPS). These tools typically allow capture or filtering of packets based on a combination of their source and destination IP addresses, source and destination ports, and the protocol type (TCP/UDP). More sophisticated networking equipment might also track connections and use deep packet inspection to identify applications at OSI layers 5-7 in the network traffic. Doing such analysis can identify the use of obsolete protocols or applications or detect malware or suspicious activity. Real-time configuration could be used to turn off obsolete or unneeded protocols on servers that no longer need them or to block their traffic from using the network.

Data in transit provides a large attack surface for bad actors. Keeping data secure from threats and compromise while it’s being transmitted was the topic at our live SNIA Networking Storage Forum (NSF) webcast, Securing Data in Transit. Our presenters, Claudio DeSanti, Ariel Kit, Cesar Obediente, and Brandon Hoff did an excellent job explaining how to mitigate risks. We had several questions during the live event. Our panel of speakers have been kind enough to answer them here. Q. Could we control the most important point – identity, that is, the permission of every data transportation must have an identity label, so that we can control anomalies and misbehaviors easily? A. That is the purpose of every authentication protocol: verify the identity of entities participating in the authentication protocol on the basis of some secret values or certificates associated with the involved entity. This is similar to verifying the identity of a person on the basis of an identity document associated with the person. Q. What is BGP? A. BGP stands for Border Gateway Protocol, it is a popular routing protocol commonly used across the Internet but also leveraged by many customers in their environments. BGP is used to exchange routing information and next hop reachability between network devices (routers, switches, firewall, etc.). In order to establish this communication among the neighbors, BGP creates a TCP session in port 179 to maintain and exchange BGP updates. Q. What are ‘north-south’ and ‘east west’ channels? A. Traditionally “north-south” is traffic up and down the application or solution “stack” such as from client to/from server, Internet to/from applications, application to/from database, application to/from storage, etc. East-West is between similar nodes–often peers in a distributed application or distributed storage cluster. For example, east-west could include traffic from client to client, between distributed database server nodes, between clustered storage nodes, between hyperconverged infrastructure nodes, etc. Q. If I use encryption for data in transit, do I still need a separate encryption solution for data at rest? A. The encryption of data in transit protects the data as it flows through the network and blocks attack types such as eavesdropping, however, once it arrives to the target the data is decrypted and saved to the storage unencrypted unless data at rest encryption is applied. It is highly recommended to use both for best protection, data at rest protection protects the data in case the storage target is accessed by an attacker. The SNIA NSF did a deep dive on this topic in a separate webcast “Storage Networking Security Series: Protecting Data at Rest.” Q. Will NVMe-oFÔ use 3 different encryption solutions depending upon whether it’s running over Fibre Channel, RDMA, or IP? A. When referring to data in transit, the encryption type depends on the network type, hence, for different networks we will use different data-in-motion encryption protocols, nevertheless, they can all be based on Encapsulating Security Protocol (ESP) with same cipher suite and key exchange methods. Q. Can NVMe-oF over IP already use Transport Layer Security (TLS) for encryption or is this still a work in progress? Is the NVMe-oF spec aware of TLS? A. NVMe-oF over TCP already supports TLS 1.2. The NVM Express Technical Proposal TP 8011 is adding support for TLS 1.3. Q. Are there cases where I would want to use both MACsec and IPSec, or use both IPSec and TLS?  Does CloudSec rely on either MACSec or IPSec? A. Because of the number of cyber-attacks that are currently happening on a daily basis, it is always critical to create a secure environment in order to protect confidentially and integrity of the data. MACsec is enabled in a point-to-point Ethernet link and IPSec could be classified as to be end-to-end (application-to-application or router-to-router). Essentially you could (and should) leverage both technologies to provide the best encryption possible to the application. These technologies can co-exist with each other without any problem. The same can be said if the application is leveraging TLS. To add an extra layer of security you can implement IPSec, for example site-to-site to IPSec VPN. This is true especially if the communication is leveraging the Internet. CloudSec, on the other hand, doesn’t rely on MACsec because MACsec is a point-to-point Ethernet Link technology and CloudSec provides the transport and encryption mechanism to support a multi-site encryption communication. This is useful where more than one data center is required to provide an encryption mechanism to protect the confidentially and integrity of the data. The CloudSec session is a point-to-point encryption over Data Center Interconnect on two or more sites. CloudSec key exchange uses BGP to guarantee the correct information gets the delivered to the participating devices. Q. Does FC-SP-2 require support from both HBAs and switches, or only from the HBAs? A. For data that moves outside the data center, Fibre Channel Security Protocols (FC-SP-2) for Fibre Channel or IPsec for IP would need to be supported by the switches or routers. No support would be required in the HBA. This is most common use case for FC-SP-2.  Theoretically, if you wanted to support FC-SP-2 inside the secure walls of the data center, you can deploy end-to-end or HBA-to-HBA encryption and you won’t need support in the switches.  Unfortunately, this breaks some switch features since information the switch relies on would be hidden. You could also do link encryption from the HBA-to-the switch, and this would require HBA and switch support.  Unfortunately, there are no commercially available HBAs with FC-SP-2 support today, and if they become available, interoperability will need to be proven. This webcast from the Fibre Channel Industry Association (FCIA) goes into more detail on Fibre Channel security. Q. Does FC-SP-2 key management require a centralized key management server or is that optional? A. For switch-to-switch encryption, keys can be managed through a centralized server or manually. Other solutions are available and in production today. For HBAs, in most environments there would be thousands of keys to manage so a centralized key management solution would be required and FC-SP provides 5 different options. Today, there are no supported key management solutions for FC-SP-2 from SUSE, RedHat, VMware, Windows, etc. and there are no commercially available HBAs that support FC-SP-2. This webcast was part of our Storage Networking Security Webcast Series and they are all available on demand. I encourage you to take a look at the other SNIA educational webcasts from this series:

• Understanding Storage Security and Threats
• Protecting Data at Rest
• Encryption 101
• Key Management 101
• Security & Privacy Regulations
• Applied Cryptography

---

It's well known that data is often considered less secure while in motion, particularly across public networks, and attackers are finding increasingly innovative ways to snoop on and compromise data in flight. But risks can be mitigated with foresight and planning. So how do you adequately protect data in transit? It’s the next topic the SNIA Networking Storage Forum (NSF) will tackle as part of our Storage Networking Security Webcast Series.  Join us October 28, 2020 for our live webcast Securing Data in Transit.

In this webcast, we'll cover what the threats are to your data as it's transmitted, how attackers can interfere with data along its journey, and methods of putting effective protection measures in place for data in transit. We’ll discuss: 

• The large attack surface that data in motion provides, and an overview of the current threat landscape
• What transport layer security protocols (SSL, TLS, etc.) are best for protecting data in transit?
• Different encryption technologies and their role in protecting data in transit
• A look at Fibre Channel security
• Current best practice deployments; what do they look like?

Register today and join us on a journey to provide safe passage for your data.

It’s well known that data is often considered less secure while in motion, particularly across public networks, and attackers are finding increasingly innovative ways to snoop on and compromise data in flight. But risks can be mitigated with foresight and planning. So how do you adequately protect data in transit? It’s the next topic the SNIA Networking Storage Forum (NSF) will tackle as part of our Storage Networking Security Webcast Series.  Join us October 28, 2020 for our live webcast Securing Data in Transit. In this webcast, we’ll cover what the threats are to your data as it’s transmitted, how attackers can interfere with data along its journey, and methods of putting effective protection measures in place for data in transit. We’ll discuss:

• The large attack surface that data in motion provides, and an overview of the current threat landscape
• What transport layer security protocols (SSL, TLS, etc.) are best for protecting data in transit?
• Different encryption technologies and their role in protecting data in transit
• A look at Fibre Channel security
• Current best practice deployments; what do they look like?

Register today and join us on a journey to provide safe passage for your data.

Last month the SNIA Networking Storage Forum continued its Storage Networking Security Webcast series with a presentation on Security & Privacy Regulations. We were fortunate to have security experts, Thomas Rivera and Eric Hibbard, explain the current state of regulations related to data protection and data privacy. If you missed it, it’s available on-demand. Q. Do you see the US working towards a national policy around privacy or is it going to stay state-specified? A.  This probably will not happen anytime soon due to political reasons. Having a national policy on privacy is not necessarily a good thing, depending on your state. Such a policy would likely have a preemption clause and could be used to diminish requirements from states like CA and MA. Q. Can you quickly summarize the IoT law? Does it force IoT manufactures to continually support IoT devices (ie. security patches) through its lifetime? A. The California IoT law is vague, in that it states that devices are to be equipped with “reasonable” security feature(s) that are all of the following:

• Appropriate to the nature and function of the device
• Appropriate to the information it may collect, contain, or transmit
• Designed to protect the device and any information contained therein from unauthorized access, destruction, use, modification, or disclosure

This is sufficiently vague that it may be left to lawyers to determine whether requirements have been met. It is also important to remember IoT is a nickname because the law applies to all “Connected devices” (i.e., any device, or other physical object that is capable of connecting to the Internet, directly or indirectly, and that is assigned an Internet Protocol address or Bluetooth address). It also states that if a connected device is equipped with a means for authentication outside a LAN, either a preprogrammed password that is unique to each device manufactured or a security feature that requires a user to generate a new means of authentication before access is granted to the device for the first time is required. Q. You didn’t mention Brexit – to date the plan is to follow GDPR but it may change, any thoughts? A. British and European Union courts recognize a fundamental right to data privacy under Article 8 of the binding November 1950, European Convention on Human Rights (ECHR). In addition, Britain had to implement GDPR as a member nation. Post-Brexit, the UK will not have to continue implementing GDPR as the other member countries in the EU. However, Britain will be subject to EU data transfer approval as a “third country” like the US. Speculation has been that Britain would attempt a “Privacy Shield” agreement modeled after the arrangement between the United States and the European Union. With the recent Court of Justice of the European Union issuance of a judgment declaring as “invalid” the European Commission’s Decision (EU) 2016/1250 of 12 July 2016 on the adequacy of the protection provided by the EU-U.S. Privacy Shield (i.e., the EU-U.S. Privacy Shield Framework is no longer a valid mechanism to comply with EU data protection requirements when transferring personal data from the European Union to the United States), such an approach is now unlikely. It is not clear what Britain will do at this point and, as with many elements of Brexit, Britain could find itself digitally isolated from the EU if data privacy is not handled as part of the separation agreement. Q. In thinking of privacy – what are your thoughts on encryption being challenged? By EARN IT act/LAED act, etc. It seems like that is going against a nation-wide privacy movement, if there is one. A. The US Government (and many others) have a love/hate relationship with encryption. They want everyone to use it to protect sensitive assets, unless you are a criminal and then they want you to do everything in the clear so they don’t have to work too hard to catch and prosecute you…or simply persecute you. The back-door argument is amusing because most governments don’t have the ability to prevent something like this from being exploited by attackers (non-Government types). If the US Government can’t secure its own personnel records, which potentially exposes every civil servant along with his/her families and colleagues to attacks, how could they protect something as important as a back-door? If you want to learn more about encryption, watch the Encryption 101 webcast we did as part of this series.

The SNIA Networking Storage Forum’s Storage Networking Security Webcast Series continues to examine the many different aspects of storage security. At our most recent webcast on applied cryptography, our experts dove into user authentication, data encryption, hashing, blockchain and more. If you missed the live event, you can watch it on-demand. Attendees of the live event had some very interesting questions on this topic and here are answer to them all: Q. Can hashes be used for storage deduplication?  If so, do the hashes need to be 100% collision-proof to be used for deduplication? A. Yes, hashes are often used for storage deduplication. It’s preferred that they be collision-proof but it’s not required if the deduplication software does a bit-by-bit comparison of any files that produce the same hash in order to verify if they really are identical or not. If the hash is 100% collision-proof then there is no need to run bit-by-bit comparisons of files that produce the same hash value. Q. Do cloud or backup service vendors use blockchain proof of space to prove to customers how much storage space is available or has been reserved?    A. There are some vendors who are using proof of space to map or plot the device. Once the device is plotted you can have a report which provides the summary of storage space available. Some vendors use it today. Since mining is the most popular application today, mining users use this information to report available space for mining pool applications. Can you use it for enterprise cloud to monitor the available disk space – absolutely. Q. If a vendor provides a guarantee of space to a customer using blockchain, does something prevent them from filling up the space before the customer uses that space? A. Once the disk is plotted there is no way for any other application to use it. It will be flagged as an error. In fact, it’s a really great way to ensure that no attacks are occurring on the disk itself. Each block of space is mapped and indexed. Q. I lost track during the explanation about proofs in blockchain, what are those algorithms used for? A. There are two concepts which are normally discussed and create the confusion. One is that Blockchain can use different cryptographic hash algorithms such as SHA-256 (one of the most popular), Whirpool, RIPEMD (RACE Integrity Primitives Evaluation Message Digest), Dagger-Hashimoto and others). Mercle tree is a blockchain construct which allows one to build a chain by using hashes and data blocks. Consensus protocols is protocol for decision making such as Proof of Work, Proof of Space, Proof of Stake and etc. Each consensus protocol is using the distributed ledger to make a record for the block of data transferred. Use of cryptography hashes allows us to create trustless concept with encrypting data which is being transferred from point A to point B. The consensus protocol allows us to keep the record of the data blocks in distributed ledgers. This is a brief answer to the question and if you would like to get additional information please contract olga@myactionspot.com I will be happy to deliver the detailed session to address this topic. Q. How does encryption work in Storage Replication? Please advise whether this exists? A. Yes it exists. Encryption can be applied to data at rest and that encrypted data can be replicated, and/or the replication process can encrypt the data temporarily while it’s in transit. Q. Regarding blockchain: assuming a new transaction (nobody has information yet), is it possible that when sending the broadcast someone modifies part of the data (0.1% for example) and this data continues to travel over the network without being considered corrupted? A. The first block of data which is building the first blockchain creates the authenticity. If the block and hash just created are originals they will be accepted as originals, recorded in distributed ledger and moved across the chain. BUT if you are attempting to send a block on a blockchain which is already authenticated this block will be not authenticated and discarded once it’s on the chain. Remember we said this was part of a series? We’ve already had a lot of great experts cover a wide range of storage security topics. You can access all of them at the SNIA Educational Library.

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.

The rapid growth in infrastructure to support real time and continuous collection and sharing of data to make better business decisions has led to an age of unprecedented information storage and easy access. While collection of large amounts of data has increased knowledge and allowed improved efficiencies for business, it has also made attacks upon that information—theft, modification, or holding it for ransom — more profitable for criminals and easier to accomplish. As a result, strong cryptography is often used to protect valuable data. The SNIA Networking Storage Forum (NSF) has recently covered several specific security topics as part of our Storage Networking Security Webcast Series, including Encryption101, Protecting Data at Rest, and Key Management 101. Now, on August 5, 2020, we are going to present Applied Cryptography. In this webcast, our SNIA experts will present an overview of cryptography techniques for the most popular and pressing use cases. We’ll discuss ways of securing data, the factors and trade-off that must be considered, as well as some of the general risks that need to be mitigated. We’ll be looking at:

• Encryption techniques for authenticating users
• Encrypting data—either at rest or in motion
• Using hashes to authenticate information coding and data transfer methodologies
• Cryptography for Blockchain

As the process for storing and transmitting data securely has evolved, this Storage Networking Security Series provides ongoing education for placing these very important parts into the much larger whole. We hope you can join us as we spend some time on this very important piece of the data security landscape. Register here to save your spot.