Storage Developer Conference - #200: An Introduction to the IEEE Security in Storage Working Group

Episode Date: February 5, 2024

Hello, this is Bill Martin, 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 Developers Conference. The link to the slides is available in the show notes at snea.org slash podcasts. You are listening to SDC Podcast Episode 200. Hello, everyone. My name is Paul Suler. I'm the chair of the IEEE Security and Storage Working Group. I work for Kioxia Corporation.

If you're wondering why you're seeing a Zoom recording instead of an actual presentation being given live at the Storage Developers Conference, it's because we had some technical problems and also because we had a lot of audience participation that was not recorded. So we're going to run this with myself, and playing the part of the very helpful audience will be the vice chair of the IEEE SISWG, Eric Hibbert. Anyway, what this talk is about is to introduce you to the IEEE's Security and Storage Working Group because it's something you need to know about. You need to know about the standards that come out of it, and you may want to participate. So what is SISWG, as we call it? It's a working group

that produces standards that many storage developers, storage vendors, and storage system operators care about a great deal, including we're doing a family of standards on sanitization, the IEEE 2883 family. We have a family of standards on encryption methods or storage components. Those are the IEEE 1619 family. And there's another standard on discovery, authentication, and authentication in the host attachments of storage devices, which is designated IEEE 1667. So, Paul, before you move on, a little bit of history. You know, the CISWG has actually been fairly active going all the way back to about the 2003-2004 timeframe. And you mentioned the 1667.

That was in a separate working group until maybe a year and a half or two years ago. So it's possible that people may have been aware of its existence elsewhere. So its new home is here in Sisway. Okay, thanks, Eric. So how are we organized? Well, we come under what you may have heard of, the IEEE Computer Society. Underneath that, one of the groups is called the Cybersecurity and Privacy Standards Committee, CPSC. Eric is the chair of that committee. And we are one of the working groups that fall under CPSC. So what do we do? Our charter is pretty broad. It's to address any aspect of security as it relates to storage.

We develop international standards rather than domestic standards. For example, standards that come out of the National Institute of Science and Technology, NIST, which some of you are no doubt aware of, are considered domestic standards. SISWG is also an individual membership working group. There are other types in which the members of the group represent particular companies, but that's not the case with SysWig. We do not formally represent companies or other entities, although, of course, we'd like to have input from a variety of different aspects of the industry, storage vendors, storage customers, et cetera. We have our meetings. Yes, go vendors, storage customers, et cetera. We have our meetings. Yes, go ahead, Eric. Sorry, Paul.

So I was going to also comment that IEEE Computer Society has a Category A liaison relationship with the ISO committee that deals with information security, cybersecurity, and privacy protections, known as Subcommittee 27, and that's under the JTC1. And that's particularly important because CPSC and the work groups in CPSC do not duplicate the work that's being done in ISO. It's frequently complementary. And we also have the ability to do collaborative work.

So we can actually do ISO, IEC, IEEE work as a part of the arrangement. So really to sort of complement what you said about the international standards, the work done here really can be injected into, for example, triple branding, which is a very unique arrangement. Could you explain that a little bit more, Eric, triple branding? So that means it's possible to create standards that are ISO slash IEC slash IEEE, which in the international arena carries a fairly significant weight in certain countries. Some ISO standards in some countries almost have the weight of law, you know, depending on how they've adopted that. Okay. Thanks very much. And we will be talking about how we get input into and take input from some of

these other groups, but that will be later in the presentation. The last point I wanted to make about the group is we have meetings every other week, Friday afternoons, and we are currently typically getting about 15 to 18 individuals in the biweekly meetings. So here's some of the historical work we've done, and Eric may want to comment on this, but let me do a first quick pass through it. We already mentioned IEEE Standard 1667, last updated in 2018. That's the one I mentioned that is discovery authentication and authorization in host attachments of storage devices. I also mentioned the 1619 family. The base standard is 1619 from 2018, and that is titled Cryptographic Protection of Data on Block-Oriented Storage Devices. It's a formalization of the Advanced Encryption Standard, AES-XTS, which is used on

block storage devices. Eric, a little later, will fill in further details on this. 1619.1, also last published in 2018, brings in various other AES modes, CCM, GCM, CBC with HMAC, and XTS with HMAC. And finally, the last member of the family was 1619.2, which was published two years ago. That is wide-block encryption for shared storage media. And that uses yet some other variations of AES. So, Eric, would you care to comment on any of these? Sure. A couple of things. So in the case of, for example, 1619, you know, it was originally published in 2007, and I mention that because the audience may be aware of the NIST Special Publication 800-38E, which is one of the documents that identifies approved modes of encryption for symmetric key encryption, that document, if you look at it, simply has some wrapper text and some NIST clarification, some limitations, if you will, and then it points to the 1619 standard. Now, it's actually pointing at the 2007 version,

and some of the issues that were identified in the 838E document have actually been addressed in the newer version of the standard, so that, you know, if there's an update to 838E, they would even need some of this would not need to include some of the language that's there. But I pointed out is that this is an example where the IEEE standards in SISWG do get consumed in other fashions. Likewise, 1619.1 and.2 were published much earlier. IEEE has basically a 10-year shelf life of standards, and then they have to basically be revisited. This is a little different than, for example, ISO, which has about a five-year cycle for its standards. And of course, sometimes we find there are enough changes that we want to update things more frequently,

and we'll be talking about that too. Okay. So what's some of the recent work from SysWig? Well, mostly we have been working on sanitization of storage devices. Last year we published 2883-2022, which is the IEEE standard for sanitizing storage. Why do we do this? Well, a number of members of the group, especially Eric, had noticed that in other standards that bear on sanitization, there were no actual requirements. Sometimes there were guidelines. Sometimes there were suggestions. Sometimes there were wordings such as,

you should do the following. Well, that's a problem because if you have a lack of mandatory requirements, then someone could simply point to one of those standards and say, we comply with this. And that claim is absolutely meaningless because there's no need to do anything. It's only if there are statements that you shall do such and such in order to comply with this standard that it becomes meaningful. So what did we do? We began work by providing definitions of some of the concepts that originally came from ISO IEC standard 27040. Some of the parts of the work that we did, we defined methods for sanitizing storage. Generally, what do we mean by sanitizing? We mean eradicating all of the user data. This is a part of security to make sure that your customer's data does not leak out.

We call these methods clear, purge, and destroy. I'll give you more details in the follow-on talk from SDC, which is in much more detail about sanitize. So I'll just summarize this here. For each of those three methods, we described different techniques. If you want to do a clear and a purge, we defined override, block arrays, crypto arrays, and then destruction, actually called destruct, of a storage device. This has techniques disintegrate, incinerate, melt, and you can imagine how those all work. We also described how to verify, assuming you didn't destroy the device, how to verify that

sanitization actually worked. And part of what 2883 has are a number of sequences of operations to go through, including invoking a sanitized command on the device and then later confirming, verifying that none of the user data is still there. And we also made a lot of updates because some of the sanitization methods applied to extremely old types of media that no one produces or sells and has not done so for years. The bottom line is these are actual requirements that certain things shall be done, some things may be done, and now all the other standards can be rewritten to point to 2883 for their actual requirements. And 2883 has just become a common place for multiple standards to

point to, and the only one that needs to be modified when you, when some of these technologies change. Eric, would you care to add some color to that? Yes, I would. So, and sort of picking up on the comments you're making here, the NIST Special Publication 800-88, which deals with media sanitization, and you mentioned the ISO 27040 standard, which deals with storage security. Those two documents were published about two weeks apart, and that was basically December of 2014 for the NIST document, January of 2015 for the first edition of 27040. There was a significant amount of work put in to make sure that the sanitization language in 27040 was synchronized with the NIST document. In the 27040 standard, there was an annex that basically had the same kind of materials. But as Paul pointed out, this was like first-generation iPhones, floppies, I mean, just very, very ancient technologies,

many of which you would have a hard and it is very close to being completed. In other words, we're anticipating publication of the second edition in probably the December 2023 timeframe, maybe a little later than that, but not much, that version of the standard actually had all of the media-specific sanitization materials removed so that that standard wouldn't go obsolete almost immediately. That was one of the big concerns is, you know, storage technology changes on a fairly rapid basis. So 27040 now basically points at either 2883 or to leave a little bit of wiggle room,

an organization approved standard. Well, I don't know of any other standards that you could basically point at, maybe the NIST document, but, you know, it's so obsolete at this point. In general, it's probably not going to be too practical. So, you know, here's another example where in the ISO world, there's literally pointing at 2883, and it's been done carefully so that as 2883 is being updated, it doesn't lock you into what might become an ancient version of 2883 that allows whatever the latest version is to basically be used. Right. That's very important. You don't want to be stuck being required to adhere to a document that is obsolete.

So that's excellent that these changes are being made in 27040. All right. So I mentioned that there are other, the 2883 is a family. Now, we have a current project, P2883.1, which is titled the Recommended Practice for Use of Storage Sanitization Methods. By way of explaining the terminology, IEEE refers to standards that are under development as projects, and we append a capital P to the number that the standard will eventually have when it's published. So whenever you see a document, if it says P whatever, you'll know that that is not the published final version of the standard. Anyway, what is 2883.1 about? Well, essentially it's about how do you use sanitization to meet your organization's needs? This is for people who are trying to understand what they should do to protect their data.

What this lays out is you have to analyze the value of the data. What is the risk to your company from data breaches? For example, the penalties you may suffer, and not to mention bad publicity and possible loss of customers, the risk is a lot worse if you disclose personal information of some of your customers than, for example, if you let out a device that only has the company's cafeteria menus. So part of what this standard is about is laying out a process for evaluating who are the people attacking you, what is the value of your data, et cetera, et cetera. Also, it allows or it enables the organization to develop clear procedures for sanitization of devices. It's easy, sort of easy, to put in your command standard for your storage device, a sanitize command.

But there's an awful lot more that has to happen around that. Like we've said, you have to analyze what your organization needs, but you have to establish a clear process for what to do with a storage device that you are going to send out of the company, that you're going to reuse within the company, or that might be reused in place for just different customers' data. All of this requires careful documentation. Paul, can you comment on this? Yeah, just to add one more sort of secret decoder ring. In terms of IEEE documents, you'll see designations of a standard or recommended practice or a guide. So 2883 is a standard. And what that means is you're going to see shall statements. So,

you know, conformity, you know, is something that was actually considered. In this case, it's a recommended practice. That tends to be guidance. So you'll see lots of should statements. You might see an occasional shall, but in general, when you see recommended practice, they're more guidance-oriented documents. Okay, thanks. The next one in the family, it hasn't yet received as much work as 2883.1, but this is a recommended practice, again, this time for virtualized and cloud storage sanitization.

The purpose is to tell people how to implement sanitization for virtualized and cloud storage systems. What's different about this? Well, these are storage systems at very large scale, and it's the intent of this document to address the particular issues that occur for very large data storage systems. Eric, would you care to add to that? Yeah, this is definitely an interesting area. When 27040 was being developed, there are materials in that document that talk about virtual or logical

sanitization, essentially dealing with some of these topics. And there are definitely some limits in terms of what you can do. For example, disrupt is typically not an option in these environments. So your choices basically come down to clear or purge. And even within that suite, it may be as limited as being able to do something like cryptographic erase, which, you know, if you don't talk about SysWeek comes up with with guidance in here, because 27040 essentially identifies the difference between media aligned and this virtual sanitization kinds of scenarios. But it doesn't really go into a whole lot of detail about what other than maybe using something like cryptographic arrays, you know, this is an opportunity to go into more detail where potentially looking, you know, if you choose cloud as a topic, you know, what could you do in certain, with certain cloud service providers, whether, you know, that's Google or Amazon or Microsoft

or any other, you know other major player, there's a possibility including specific guidance in terms of how do you make data go away in those kind of environments where 27040 doesn't even begin to just basically identifies you've got to handle this a little differently and you may or may not have any options. So I'm hopeful that this new standard will help deal with some of that situation. Very good. Thanks. There's another project that has just been approved. It's P3406.

It's titled a Standard for Purge and Destruct Standardization Framework. At the time I had to submit these slides, it had not yet been approved. In fact, voting was probably taking place as this original talk was delivered. But this has now been approved by IEEE's New Standards Committee. So we are moving forward with this. So it is kind of part of the 2883 family, but we decided that we needed to, that it was more fundamental. It's something that 2883 itself, the standard that's already been published, would depend upon. So we mentioned the methods of purge and destruct. I need to make a distinction right now. You heard Eric mention clear.

When you sanitize by clearing a device, that means that the original user data can no longer be accessed through the interface. On the other hand, if you perform a purge, then even if you were to take the device into a laboratory, disassemble it, and do raw accesses to the data, you would not be able to recover any of the user's data, or at least not to a very high probability not be able to do that. So that's the distinction between clear and purge. Clear was not interesting enough, so we are not including any guidance on that in this, or not including any requirements on that in this standard. Okay, so what is it going to do?

So it will provide requirements for standards organizations, which may include industry groups that define command sets to define purge and also destruct techniques. Now, this is going to be important because we have some new storage technologies that are coming along. We don't have – well, there are ideas and prototypes for interfaces, such as DNA storage, which you've probably heard a lot of over the last few years. There were talks on this SDC, and there were also some on crystal storage, using silicon crystals for storing data. So these are going to – we don't know if we would have any, probably nothing in the first edition of 3406 that would address these directly. But as those come into the market, we can update 3406 to describe how to purge a storage device using these technologies.

And by the way, purge leaves it, of course, operative. Or what do you have to do to destroy them? So I've already mentioned the requirement for purge, making data recovery, the term we use is infeasible using state-of-the-art laboratory techniques. Interestingly, destruct can also be subject to aging out of certain methods. I spent a long time in the tape world, and for the longest time, people would say if you degauch your tape, you have destructed it, especially with some technologies, you lose the servo track and it can no longer be read.

The problem is, though, that as tapes get denser and denser, it takes higher and higher magnetic field intensities to erase them. So a device that could degauss an early generation tape may no longer be able to do so to device it to tapes that are coming out, say, 12 years later. So that's a sort of example of how 3406 would have to be updated, or we have to use careful wording to incorporate changes in the technology that make later generations more difficult to destruct. Also, some techniques will simply have to be deprecated. As an example, I'm not saying this has happened. If the advanced encryption standard were somehow to be broken,

and no, quantum cryptography has not figured out how to do that yet, then all of the crypto erase implementations that used encrypted data on the device and sanitized by simply erasing the key, all those implementations that relied on AES would be ineffective and an updated version of 3406 would have to take that into account. Eric, anything to add to this? Yeah, you know, just sort of following on with your comment about deprecated, when we were looking at destruct, and this is one of the differences between the NIST 888 and 2883, we deprecated shredding and pulverizing, you know, as an example, because the density of the media is such that even if you were to sort of cut things up into, you know, say that you had, like, for example, a Blu-ray disc, if you cut that up into two millimeter square chunks as part of your shredding operation, you could actually recover significant amounts of

data off of just one of those little pieces. So even in the case of 2883, you know, we made that decision. And that was a bit of a catalyst for trying to get our arms around what do we mean by, you know, state-of-the-art laboratory techniques and try and, you know, potentially establish some sort of boundary conditions of when do you deprecate some of these things? When, you know, so, you know, another area, and Paul, you mentioned this about degaussing. We had some very spirited discussions about the use of degaussing. You might not work in terms of making data go away on, for example, a particular drive, but in the process of using it, you might actually destroy or make interoperative the mechanical mechanisms of the drive.

And so the conversation was, so did DGALS move from being a purge operation? Because if you look at how it's described in the NIST document, that's where it shows up to becoming destruct. And the answer was, well, no, because if you actually took the media out of the device, you might still be able to recover the data. So how you deal with that is really part of the domain of P3406 is, you know, how to understand, you know, for example, in 2883 in the future when things need to be, you know, potentially deprecated or not, as well as, as Paul mentioned, you know, other industry activities, when they're looking at, well, we think this is a destruct,

what's the benchmark that they've got to sort of meet, you know, achieve, you know, to really consider it to be, you know, a purge or a destruct mechanism? So we think that this is going to be an important standard. You know, if my hunch is correct, we're likely to see certain governments around the world take a particular interest in this once, you know, the draft starts, you know, coming together because they're going to want to make sure that, you know, their opinions on some of this stuff are, you know, being sort of factored in. So I anticipate this is going to be a fun project to sort of develop. And we are kind of diving deep into some of the details of sanitization, but I think it's important because it gives you an idea of what motivates us to start different projects and how we choose the things that we write standards about.

There's some other work. We're updating 1667, so there is now a P1667 project again. The last version, as we said before, was from 2018. We found it needed a few editorial corrections. There were a couple of details of PCIe. Now there are more multi-port PCIe devices and so it's going to be necessary to clarify what happens with resets because it's different to some degree in a multi-port device than a single port device. This is not going to be something that consumes a lot of energy, but it is something that is worth dating to make sure that the standard stays abreast of developments in the industry.

So we've talked a little bit about other standards organizations. And the point I had mentioned kind of in passing earlier is that individual members of SISWG work with the editors of documents developed in a lot of other organizations. Sometimes we are the editors of those documents. For example, Eric mentioned Subcommittee 27 of ISO IEC JTC1. They're the ones who developed 27040, and Eric is the editor. And as he said, we're aligning that to make use of 2883. The SNEA security twig is actually where some of that work is going on, but they're also working on the media sanitization white paper,

encryption key management white paper, and they have various other things. Eric, are there any of the projects from the security twig that people need to know about? Are those the main ones right now? So those are sort of educational materials. One document that the security twig is involved with is dealing with basically a TLS profile for storage systems. So how do you protect, for example, management? And that's something that SNEA has published as one of their standards, and it's also known as ISO 20648. So that doesn't necessarily come to play here with the media sanitization, but given the broad scope that SysWeek has,

it's conceivable that we could end up doing some work where, you know, the storage management, you know, becomes sort of the focal point, and then that work, you know, could definitely be of value or important. Okay, thanks. Another group is the trusted computing group. The storage working group within TCG, in particular, has been working on a standard called the key per I.O., how to provision a storage device with encryption keys that can be used, that can be selected on the fly when data is written to that or read from that storage device. Along with that will be an educational application note and possibly some other guidance. The big 800-pound gorilla is, of course,

NIST, the National Institute of Science and Technology. We work with them, and one of the important standards that Eric has already mentioned is 800-88 media sanitization guidelines, which has not been updated in about nine years. Eric, you're much more involved with them. Would you care to comment on our interactions with NIST and any other useful standards? Sure. So there have been multiple interactions with NIST about basically the need to do an update on this document.

The Biden administration has them a little distracted with things like IoT, consumer IoT labeling. There's a bunch of stuff going on with artificial intelligence. So this hasn't been a major priority. In some ways, with the new 27040 and 2883 out, there's a way to cover it. But we have had some conversations about the need to do and that the NIST could potentially use the same technique they did for the 830 AD, which is some wrapper text and then defer the details to the IEEE 2883 standard. We haven't gotten far enough to know whether that's going to basically happen or not. And frankly, we're waiting to see if this management, you know,

this is the right time to undertake a revision. We're hopeful that they'll do that. So that's one facet of it. There's also been some conversations with the ISO SE27, where, you know, strategically, it may be worth taking 2883 into that arena. It may make it easier for adoption in Europe and whatnot. So now that the standard is done, we have the ability to sort of look at, you know, what would be the most effective way to engage some of these other jurisdictions like NIST. NIST is, you know, not the only organization in the world that has this kind of problem that, frankly, 2883 solved. It's not really straightforward. I mean, in the spirit of transparency, if NIST were going to do something like this, they might need to actually say, okay, where it says shall in 2883, you know, from a U.S. government perspective, interpret that as a should.

On the other hand, they could actually say, no, we're going to step the bar up and acknowledge that, you know, that's a transition and that, yes, you need to pay attention to that and whatnot. And so that's part of the complexity in terms of how to go about doing an update. Frankly, you know, if NIST were to decide to, you know, actually do an update and they wanted to pursue this, you know, leveraging 2883, I think that would probably serve as a catalyst to sort of start a revision of 2883 to ensure we have the window to basically capture any of their needs, you know, that we might not have taken care of up front and any other kind of issues that come into play. So I'm hopeful that something like that will happen, but, you know, time will tell. And, you know, wishful thinking is always, you know, we're looking at this in a positive way where maybe take some of the load off of NIST because they definitely have their hands full

in a bunch of other areas right now. Yes, they do. The last group I wanted to mention is called the Open Compute Project, or OCP for short, which was started by some of the groups that we refer to as hyperscalers, but it has membership from device vendors and others. So like many groups that produce industry specifications and industry standards, it's got both the vendors and the customers for storage devices. Now, at this point, we don't have any active work directly with them, but some of the OCP documents, they do have their own

security working group. Eventually, some of those documents may be candidates for actual standardization. And because members of SISWG are right there helping to work on those, we'll know when we have a document that would be of use to the industry as a formal standard. There's another whole aspect of something that SISWG is probably going to push into fruition. We've been talking about standards. Well, if you buy a storage device, how do you know that it really does sanitize itself, for example, correctly? Well, you need an entire program to do that. I'm sure a lot of the people are aware of Federal Information Processing Standard 140-3. It's part of NIST's cryptographic module validation program. So what they do is if someone wishes to have a certification that they adhere to 140-3,

they work with NIST by way of a test lab who tests their products, and if they pass, then they are issued an official certification. So IEEE has what's called the Conformity Assessment Program that has the ability to establish and perform certifications. Generally, it works rather the same way. You have to set up test labs, certify that they know what they're doing, and then vendors of devices can bring their devices in to be certified that they actually are sanitized correctly. So right now, we are trying to, our efforts are underway. We're going to establish a cybersecurity certification scheme, as it's called. So SysWig may be involved with ICAP as a part of this, as part of certifying, like I said, the data is eradicated, providing proof that it is eradicated correctly. Eric, you work with them closer than I do.

Is there anything you would like to add? Yeah, a few things. So the ICAP is a separate part of IEEE. It's separate from the societies. So, for example, CPSC and SysWig, in turn, are all underneath the, you know, computer society. We're developing standards, which are basically managed by IEEE Standards Association. So, you know, the, so IEEE SA, as it's known, is, you know, sort of a separate body. ICAP is also a separate, you know, entity. And the conversations that we've had so far are, and we went from initially looking at,

could we set up some sort of a certification program underneath ICAP just to do sanitization. While that was possible, it was unlikely to be practical because the number of players to do that would not necessarily be large. I mean, think about basically your drive vendors, maybe a handful of laboratories that are doing it, and then maybe some other set of players. That's probably not enough to set up a full-blown scheme. The schemes have lots of complexity in terms of setting them up, and then you've got to maintain them and whatnot.

And ICAP is kind of the umbrella under which you can set the structure up. So that takes, you know, part of it, part of the problem set. So current conversations have been looking at a broader cybersecurity. And again, you know, from a CPSC perspective, that's actually kind of ideal because then any, potentially any of the standards in CPSC or for that matter, there are other groups in IEEE that deal with security. You know, for example, medical devices and whatnot could slide underneath, you know, a cybersecurity certification scheme. They would just be individual projects. The beauty of that approach is from a scheme perspective,

you could have a wide array of vendors, a wide array of basically consumers of the technology, associated laboratories and whatnot, and then spread the pain, if you will, in terms of costs and things of that nature. So that's the good news. And that's the good news is it's a much broader entity that basically has to be brought online. So there's a lot more discussions, negotiations, and foundational work that has to basically be done. Sort of coming back to, you know, assuming this is successful, no guarantee that that's the case, but assuming it's successful,

SISWG, as on the standard side of the house, think of it as developing the standards that would serve as some of the base criteria for the certification. But ultimately, a set of test plans would need to be developed. My guess is that the project on the ICAP side would have ownership for those test plans, but it would need input from SISWG to make sure that the content of those test plans, but it would need input from SysWig to make sure that the content of those test plans, you know, passes, I call it the giggle test, the security giggle test, because if it's not really putting the right mechanisms under the microscope, so to speak, you know, it's not going to solve

the problem of, you know, has the data, you know, been eradicated, you know, it's not going to solve the problem of, you know, is and has the data been eradicated, you know, when the appropriate, you know, maybe purge mechanism has been invoked. And so I believe that, you know, anything under ICAP in this space would definitely be collaborating with CPSC and CISWG to make sure that, you know, that the test plans are set up correctly. And of course, then the laboratories, you know, would need to do their part. So they've got to understand how do we execute this test plan. And again, there may be some additional, you know, guidance that's got to basically be

set up. So that's basically being explored, studied at the moment. In general, I would characterize it as this seems to be the right thing to do. Lots of opportunities here. It's a matter of getting all the work that needs to be done, done, and getting the right players to the table and agreeing on time. And we're just starting that piece of the activity. And, you know, it sounded like a lot of hula dancing.

It is a bit of it because we're kind of at that stage of, you know, trying to sort of understand how ICAP works and what all the moving parts are and what we need to make this successful. Okay, thanks. And just to recap, the cybersecurity certification scheme is a very, very broad thing. And sanitization or proof of data eradication is just one piece of that. So, yes. So, like Eric says, we hope that establishment of the scheme will be successful and then we'll be able to bring in our contributions. Yeah, and maybe I guess one additional comment, Paul, is that because we have identified this particular issue, so it's a known, you know, it's a desire to have a project, it's serving as sort

of the, you know, the initial anchor point, and it's not necessarily a massive problem set to solve. It's just an example of many things. So I'm anticipating – well, I can tell you the conversation I've had is this is one of the examples of we need this, and here's why, and here's the set of players, which would be maybe a subset of sort of the grander scheme of things for a cybersecurity scheme. Okay, thanks. Other future work? Well, 2883 is only a year old,

but we already know some things that will eventually need to be added to it. NVM Express is in the process of finalizing a definition of a method of performing media verification after sanitization is complete. In other words, you've got to be able to read the device and check to make sure that the user data is not there. And we're forming an NVMe. We are working on a proposal for that that is almost ready. Something a little bit farther in the future is namespace purge. You may know that a NVM Express device can have multiple what are called namespaces.

How do you want to – can you purge just one of those instead of the entire device? Well, not yet, but after this new proposal is worked out, then there will be a method for that. And those will need to be mentioned in 2883. Also, there are changes underway for eMMC devices. We want to add to 2883 more meat on how to purge SD cards and purge for other existing technologies. For example, NVDIMS, storage class memory, et cetera, are candidates for being added to 2883. Eric, are there any other things that you can think of we might want to put into the next revision? And, of course, anything our friends at NIST, if they come play, might potentially want to add. But I think you've got to – I mean, this is a list that's getting dangerously close to needing to kick it off.

That's right. Okay. There are other IEEE Standards Association groups, and the ones that are closest to our heart, there are a couple. There's a group focusing on post-quantum cryptography. They have a project P3172, and this is going to probably turn out to be an entire family of standards. They recommend a new method, a family of methods that recommend new quantum encryption for various storage types, block devices, stream devices,

for example, tape, but not only tape. Those all may be appropriate to add to IEEE 1619, the encryption mechanisms that are being defined under Project 3172. Also, there's another group working on what is called Zero Trust Security, abbreviated ZTS, and that project is P2887. So things that they come up with may be within the purview of IEEE SISWG. You know, anything that touches on security. So these may be places we can make contributions or we need to bring some of their ideas into the standards developed by SysWig. Eric, I've got two more slides with a variety of other groups, but would you care to comment on

either of these two right now? Yeah, in particular, you know, I think you covered the post-quantum crypto. Well, the zero trust security is an interesting one. And, you know, my gut tells me that sanitization has got to play a role in zero trust. But, you know, I haven't really seen where it's being singled out and how it would be integrated. So I think this is going to be one of those scenarios where there's going to be some cross-pollination, cross-discussions between the two working groups to explore some of this. And like SISWG, the Zero Trust Security Working Group just had another project authorization request approved, so they're starting a new project, and it's P3409. And it's looking at a zero trust security framework. So this is trying to identify what are the components or the elements of zero trust security that you need to worry about.

The existing document that Paul mentioned is intended to be a guidance standard. What should you be doing? But you kind of need to know the space that you're operating in. So I think that clearly storage and how you secure storage is one of the things that Zero Trust Security has got to deal with. And so I envision there's definitely going to be some collaboration. Could even be, you know, a joint project, you know, down the road when we get, you know, a little more insight. Okay, thanks. So as we reach the end of this talk, I'll mention some other IEEE and CPSC in particular working groups. There's a project P2989, authentication in a multi-serve environment work group, is the group that's working on this.

There's a data leakage tracing work group, and their project is P3361. And they're going to call that a standard for evaluation method of robustness of digital watermarking implementation in digital contents. In other words, if you find a document that was leaked, can you figure out where it came from? Is there anything that can be done to the document watermarking? Sounds very interesting. There is another work group called the Interworking Framework for Privacy Preserving Computation. They have a project 3117, which we call the Standard for Interworking Framework for Privacy Preserving Computation.

And finally, there's the Quantum Security work group that we just talked about, 3172 is their project. I've got another slide of these, Eric. Are there any here you want to add any color on? Yeah, just a real quick comment is the first three of these are entity-based working groups. So they have a more restrictive participation. And all three of these were basically initiated coming out of China. So China's got quite a bit of activity going on, you know, in the various standards development organizations. So these three are being worked primarily in China, and the entities, for the most part, are Chinese-based.

Okay, thanks. Some other CPSC working groups are the Space System Cybersecurity Workgroup. They have a Project 3349, Standard for Space System Cybersecurity. There are interesting challenges with devices that have to work in space. Zero gravity, temperature extremes, and networking, I'm sure, come into this. There is the System and Software Runtime Security Working Group doing Project 3389, a standard for a technical framework, again, of runtime application and self-protection. Software Supply Chain Security, which you've heard a lot about in the news over the last couple of years. 3390 will be a standard for security management capability framework

of open source software. And the title goes on and on, supply chain for software providers. And we've already talked about the Zero Trust Security Workgroup. Eric, any more details about any of these? Yeah, a couple of these. The P3389 and the 3390, again, are a couple more that are being worked out of China. The 3349, it's having

worked for NASA for many years, it's kind of a pet project from my perspective, although I'm watching what they're doing. This has got pretty significant participation from space agencies and companies that are operating in this space, producing true space-based, commercial space-based technologies. And we believe that 3349 is very likely to end up as one of those triple branded standards when it's all said and done. There have been some early coordination work to go about doing it.

And likewise, zero trust security is definitely being targeted towards SC27. So, you know, I believe may do the heavy lifting, but then bring the documents to ISO for triple branding. Right. And recall that SC27 is part of ISO. Okay. So we have come to the end of our talk. Eric, any final thoughts before we wrap up? Yeah, I would say, you know, SysWig is definitely the home for a lot of storage security activities, especially informal standardization. It's got a solid set of experts who are very, very strong expertise in the storage technology. But we've also got a pretty good selection of experts that understand the security side. So storage security is an area that there's a rare breed, if you will, of experts. And this is one area where it's got some of the dominant, you know, players, you know, actively engaged.

So if this is a topic of interest for, you know, your organization, then I would encourage you to get involved. It's pretty straightforward to do that as an individual member organization. Okay, thanks. And I guess that doesn't leave me very much to say except thank you for listening to this session. Give us feedback if you can. And definitely get involved if you think that you want to know more about the work we're doing or especially that you want to know more about the work we're doing, or especially if you want to contribute to it.

So thank you very much. Thanks for listening. For additional information on the material presented in this podcast, be sure to check out our educational library at snea.org slash library. To learn more about the Storage Developer Conference, visit storagedeveloper.org.