Storage Developer Conference - #172: Emerging Storage Security Landscape

Episode Date: July 19, 2022

Hello, everybody. Mark Carlson here, SNEA Technical Council Co-Chair. Welcome to the SDC Podcast. Every week, the SDC Podcast presents important technical topics to the storage developer community. Each episode is hand-selected by the SNEA Technical Council from the presentations at our annual Storage Developer Conference. The link to the slides is available in the show notes at snea.org slash podcasts. You are listening to SDC Podcast, episode number 172. Hello, and welcome to the session on Emerging Storage Security Landscape. My name is Eric Kibbert, and I am with Samsung Technologies. I'm the Director of Product Planning, in particular dealing with storage networks and security.

I'm a practicing security and privacy professional. I've been involved with SNEO security activities for quite some time as well as a wide range of security and privacy oriented standards bodies and industry associations. And relative to this talk, I'm currently the ISO editor for the 27040 Storage Security Standard. And as such, I tend to keep an eye out on emerging storage security specifications and Really, the goal here from a storage security perspective is to try and have storage be the last line of defense, which is almost a sort of a natural kind of thing, given that the data typically live there and reside there.

And we're going to highlight some of what I see as new and emerging storage security elements that may be able to play into this and make some comments about how I think that will come into play. So as a bit of background, let's take a quick look at the common threat actors and common motivations. In general, these have not changed much. They're pretty much the same as 10 years ago. However, the techniques they use, their approaches, the tools they use have gotten extremely sophisticated. Many of these actually apply to the storage world as well. We do see right now an increased presence of things like ransomware. So there's a lot of sort of financial gain that's coming out of that space.

But in general, it's important to keep in mind that security is basically a people problem. It's not a technology issue. We don't have systems waking up and attacking each other, at least not unless somebody's pushed a button somewhere and said, you know, go do that. And so that means that as defenses evolve, so do the attacks. And I'd like to say it's a cat and mouse game, but it's really not a game. And in this case, it's the cat that, you know, the attackers basically assume. And we as defenders are more like a mouse. We're constantly chasing a problem bit in terms of what's the biggest plague at the moment, so to speak. The highlighted ones are the kinds of

threats that we see as being directly relevant to the storage and storage technology. And as I mentioned, ransomware is up towards the top. So these are, you know, in basically a priority order of what we're seeing right now. They do change a little bit,

but, you know, not significant from year to year. When we talk about security, especially if you're not a practitioner or if you're sitting in the privacy space and talking about security, you can have sort of a wide range of views. And this is an attempt to basically show you why that's the case. So you see on the left-hand side, the privacy and data protection.

And here, the focus is really dealing with lots of laws and regulations. There are a bunch of them. It seems like almost every country these days has some sort of privacy and data protection requirements in the regulatory space. Indirectly, those will drive security, but it's usually characterized in the form of some sort of risk mitigation kind of language. On the right-hand side, we have information security, and the focus is actually on information. So that could include things like paper. Really, this is where you hear confidentiality, integrity, and availability. You have the CIA triad that, again, has been around for quite some time.

Cybersecurity is basically a subset of that, and it's really focused on the cyber aspect of this, whereas information security is going to be worried about things like supply chain. Cybersecurity, maybe not so much, but it's definitely worried about how you protect data and applications and people in the general cyberspace. And of course, somewhat related to this is there's an issue of ethics, and that will often drive what people do or not do. And so this is sort of an overall sort of landscape of those of us that are looking at this problem set having to basically operate in some or all of these arenas. All right, so I'd like to move forward and talk a little bit about some of the current standards that are relevant to the storage and storage security. So within ISO, there is a subcommittee 27,

which deals with information security, cybersecurity, and privacy protection. This is the standards body that produces the 27,000 series security standards, if you're familiar with those. Lots of organizations base their security checklists on those standards. And so within that body, there's also some activities that are more directly related to storage technology. So first up is the 27040 Storage Security Standard, which was published in January 2015. It's all guidance, so you can't claim conformance with it.

Well, you can, but that doesn't necessarily mean anything. There are about 330 recommendations or controls, as we call them. It covers the full range of storage technologies, storage networking, storage management, various flavors, fiber channel, NFS. If you can think of it, if it's mainstream, it's probably got some coverage of things that you should be worrying about. It even includes materials on sanitization, both storage and media-based. It is the only international standard that deals with storage sanitization, so it's worth sort of noting that. 27050 is focused on electronic discovery, in particular part four which is called technology

readiness uh addresses things like retention and preservation um and and it it um has some requirements and guidance on on what you should do about for example standardization its focus is on the legal community and records management, but it is one of those documents that addresses this aspect that, again, we in the storage industry care about. The 27031 deals with business continuity. And again, it's a guidance standard, puts out concepts and principles, and basically how to improve the overall business continuity. Both 27040 and 27031

are undergoing revisions, and so we're likely to see some changes. In the case of 27040, I'll probably talk more about that. But 27031 is expected to actually be enhanced as well. NIST actually has multiple documents out. 888, Special Publication 888 deals with media standardization. It's a guidelines document, but it's focused exclusively on media. The 800-209 is dealing with the guidance for storage infrastructure, a little broader scope. Some of what it addresses are also covered in the 27040 standard, but NIST documents are developed by the U.S. government, are developed by the U.S. government,

definitely apply to the U.S. government, but because of their sort of the general availability at no cost, they do get quite a bit of visibility. There are some interesting concepts that are floated in the 800-209. For example, they've introduced the concept of cyber recovery systems. And this is separate from your traditional disaster recovery business continuity. And so how do you basically prepare

for something like a ransomware attack? How do you recover from that? So, you know, interesting document in that space. Also worth noting, there's the 800-111, which is Guide to Storage Encryption Technology for End-User Devices. Definitely something worth, if you're interested in encryption technology, worth taking a look at. All right, so let's move to the emerging side. This is probably the more

interesting piece. As I mentioned, 27040 is undergoing changes. The big change here is it's including shell statements requirements. So in the future, if you claim conformance, there'll be a set of things that that means. And they're sort of peppered throughout the document at this point. So there have been a fairly large number of changes from you should do this to you shall do this. And some of them with caveats, for example, dealing with whether the data is sensitive or not. The target audience is consumers of storage technology.

And so if you're a vendor, this means you've got to sort of figure out what the indirect impacts are. So, for example, if there's a requirement to use encryption to protect confidentiality, for that to actually be usable, a vendor has to implement encryption and key management functionality. And that's what I mean by sort of indirect. The update basically had been some removal of what we would consider to be some niche technology. So Fibre Channel over Ethernet and PNFS were basically removed, as well as some obsolete technologies like floppies and zip drives and renewables and things of that nature.

There's definitely new material on securing NVMe over fabrics and IPMI, which have been some areas that needed some attention. Lots of consolidation of the controls in this document, a little easier to process. Big changes around sanitization. All of the content that dealt with technology-specific has basically been removed and is now being handled by an IEEE standard 2883. And there were some prioritization tables that kind of helped you figure out what to do. Most of all, that's basically gone because now you've got requirements and those represent sort of baseline controls. There's a new version of the

2702 standard coming out. And this is part of that information security management. How does an organization deal with that? And there's a little tighter relationship between the 27001 and 2 and 27040. And we're anticipating that this new document will come out in mid to late 2022. I mentioned the 2883 standard. This is focused on storage sanitization. The nut of it is we think this is going to be the go-to standard for how do you get rid of data on storage devices and storage media.

So it basically identifies applicable sanitization methods, what techniques you can use for specific technologies, and sort of the minimum requirements of what you need to deal with. It also talks about things like cryptographic erase and degaussing and how all this sort of fits in and provides some guidance on verification of sanitization. There's another talk here at SDC. So if this is a topic you're interested in, you may actually want to review that one as well. All right, so the PCI-SIG and the DMTF are working on some specifications that are

very interesting looking at this point. So what we're seeing are the introduction of some specifications that are dealing with authentication and measurements and attestation and roots of trust. And really, at sort of a high level, the idea is that components of a system can actually determine whether they've been changed or not. So, for example, if the firmware has been changed and it shouldn't have been, there's likely to be the ability to detect that and then be able to respond to what exactly you need to be doing. Do you trust this storage device, for example, because its firmware changed and there's no record that it should have been changed? So some of this could actually be very useful sort of countermeasures

to things like ransomware and certain malware that can get installed on systems. Maybe useful from a standpoint of detecting counterfeit technology. So if there are supply chain problems, there may be ways to detect, you know, is this device actually from the vendor that it purports to be from? So we're anticipating that when all of these specifications are in place, that it's going to offer some very, very interesting and potentially powerful technologies. And companies that are operating in the cloud space, for example, these are kinds of technologies that they're going to be very interested in seeing in the future. A little more about the component authentication. So it's dealing with things like manufacturing and integration and how you deal with initialization and power cycle events, what to do during runtime, whether you need to basically re-authenticate during runtime kinds of things, and what happens when you're adding things or replacing things?

Now, you know, in many cases, our systems are designed to be plug and play and, you know, that's convenient, but from a security perspective, plug and play could be a source of serious problems where you've introduced, you know, some technology that, that essentially can be used to harvest data or cause corruption, a whole variety of problems. The PCI technology dealing with integrity and data encryption is something looking very interesting. And basically this is, think of it as link encryption. And it could be between for maybe a host or server and a switch,

or it could all the way be down end toend, you know, from basically the host or whatever the computer is down to, for example, a storage device and passing through, you know, switch infrastructure and things of that nature. So why would we be worrying about this? Well, when you're dealing with, you know, short cables or, you know, a bus inside of a server, it's not a problem. But when you start dealing with some of these storage networks, and for example, when you look at what you may be able to do with NVMe over Fabric, you know, some of these technologies may prove to be very, very useful to help secure connections that are, you know, not sitting next to each other,

but maybe a little more distant. And you want to essentially secure the data path with some solid encryption. And what we're seeing is, in this case, using AES-GCM, which is a very fast encryption mechanism and typically used in things like TLS and IPsec to secure communications. So lots of work on this right now. Specifications are firming up, and in the not-too-distant future, you're likely to see various players who will have to deal with IDE offering support. My guess is that this is probably going to be in the 2024 or later timeframe because there is a need for essentially heterogeneous support for those. Next one that's an interesting beast is some work that both the NVM Express and the Trusted Competing Group are collaborating on.

It's known as Keeper IO or KPIO. The simplified version of what this is, is think about a scenario where for every read and write that is executed, it includes key tag information that allows that write to identify an encryption key that then gets used by a drive to encrypt the data. But the drive itself doesn't have to do the complex key management. It has a cache of keys, some number to be specified. Let's say, hypoth it's 2000 keys. And the host that's using that drive, or it could be multiple hosts,

preload this cache with these keys. And then it uses the key tags to identify which key to use, which each IO operation. It's an intriguing idea in that, for one, you can use the drive's encryption capability as kind of an offload engine and not worry about the drive having to basically deal with the key management piece.

Basically, when the drive is restarted or systems restarted, those keys that are cast all go away. You basically have to load up the keys before you can start using them. So why would you do something like this? Well, from my perspective, when I kind of look out on the landscape, if you're dealing with containers and VMs, and you don't necessarily want the underlying system to know anything about, you know, the encryption keys, you could actually manage those keys, you know, within the container in the VM. And, you know, you're passing that information down into the drive as part of your reads and your writes.

So even though you may be abstracted away from it because of the way you're doing the I.O., it may actually not be that abstracted. You could take this to another level and look at it from a cloud perspective. And theoretically, if the specifications are done right, you as an end user of a cloud service that's using encrypted drives, you could be pumping in the keys that the cloud service provider knows nothing about all the way down to the drives that they own, but you're providing the keys that are used for your particular data.

It's an intriguing approach. There's a lot of work that needs to be done. The trusted computing group is right in the midst of specifying how all this does. And the NVMe folks have basically said, yeah, this is part of the NVMe folks have basically said, yeah, this is part of the NVMe functionality. And, you know, you're likely to see these specifications come out

in probably the next six to seven months, you know, to actually see how this stuff is all going to work out. But it is definitely an intriguing, you know, technology. And it'll be interesting to see where it goes. All right. So some other miscellaneous noteworthy activities. So the U.S. government is making quite a bit of emphasis on zero trust architectures and the concept of trustworthiness. And both of these, they're different, but they're potentially changing the game for the security community.

Because essentially you start from a position of I trust nothing. And you have to basically establish that trust relationship. You're not talking about things like perimeters. So, you know, the trust boundary might be within a particular system, might even be at the device level. And so we anticipate that some of the zero trust activity is definitely going to have some impacts. I mentioned earlier the 27001 standard. You know, so there's a sequence of events that are queued up right now. 27002 is about to be published as a new version. The expectation is that 27001 will then undergo a limited revision, basically updating an annex that essentially is the outline of what's in 27002.

And that will be done as an amendment. However, once that amendment's done, the expectation is that a new version of 27001 will then be published by sort of taking the amendment, applying it, and there's some other changes that would need to go in. When that new version of 27001 comes out, it will cause of that period, whatever their previous certifications were, they're invalid. Now, this is going to cause a lot of interesting perturbations to the security community because it means they're going to be looking at everything. Because a lot of the supporting documents of 27001-2 have also been undergoing revision. And so this is going to be, you know, I think where the storage ecosystems are going to get a lot of scrutiny. This 27040 is going to be in that part of that mix. Another thing to keep an eye on is TLS.

1.3 has been out for a while, and we're seeing behind the scenes adoption, at least from the toolkits and whatnot. We think that there's probably going to be some sort of black swan event that will serve as a trigger. And when that happens, previous versions of TLS prior to TLS 1.3 are essentially going to be abandoned, and there's going to be a mass stampede to TLS 1.3. So this is one of those areas where if you're looking at TLS as part of your products and whatnot, you absolutely want to make sure you're positioned to deal with TLS 1.3.

So with that, I'd like to thank you for your time. It's a bit of a whirlwind tour of some of the things that we see on the event horizon. And hopefully this is helpful. Watch out for the specifications when they come out for public review. Many of them are not out at the moment. And thanks again for your time today. Thanks for listening. If you have questions about the material presented in this podcast, be sure and join our developers mailing list by sending an email to developers-subscribe

at sneha.org. Here you can ask questions and discuss this topic further with your peers in the storage developer community. For additional information about the Storage Developer Conference, visit www.storagedeveloper.org.