Welcome to our podcast series, Coffee with the Council. I'm Alicia Malone, Director of Communications and Public Relations for the PCI Security Standards Council. Well, happy new year and welcome to the fifth season of our podcast series. The Council is off and running with its first major piece of news, and that is the publication of Secure Software Standard version 2.0. This is the first major revision to the Standard since it was introduced in 2019. Joining me today to talk about all that's new in the Standard and also what it means for the 3DS SDK Standard is Mike Thompson, Director of Solutions. Welcome, Mike.
Mike Thompson: Thank you. It's great to be here today.
Alicia Malone: So, let's get into it. So, first for those who may not be familiar, tell us a little about the two standards that make up the Council's Software Security Framework and what those standards are all about.
Mike Thompson: Sure, so we have two standards, as you mentioned, as part of the Software Security Framework. We have our Secure Software Standard, and that's the standard we're talking about today that we just published last week, which we're very excited about. But we also have a Secure Software Lifecycle Standard as well. So, the Secure Software Standard is really about the assessment of the software product itself, whereas the Secure Software Lifecycle Standard is about the vendors’ development and management processes over their software products.
And a good question would be, why is it two standards? Why isn't it just one standard? And the reason it's two standards is because it has a lot of benefits being separated. So, you don't have to be a Secure Software Lifecycle - what we call “qualified vendor” - to do a Secure Software product assessment, but it is advantageous because it avoids the reassessment of that vendor's development and management processes every time they want to assess a new software product, and it also affords them programmatic benefits, most especially in the way of what we call delta changes - so change management - to their existing products. So, by having them separate, it affords a greater degree of flexibility and programmatic benefits to the software vendors that over time, since we've published them, has proven to be quite successful and quite advantageous for those vendors involved in the program.
Alicia Malone: Interesting. Okay, that makes a lot of sense. So, over the last 18 months or so, your team has been diligently working on a major revision to both standards, with Secure Software Standard version 2.0 coming out first. Let's talk about that process and how this current version came to be.
Mike Thompson: Absolutely. So, there’s no question about it. One of the most valuable mechanisms that we have here at the Council is stakeholder engagement and the input that we get from our stakeholder community. So, one of the most prominent mechanisms we have is a Request for Comments process, or RFCs, as people know them to be, where all of our Participating Organizations and our assessor community can provide feedback on that standard. And we factor all of that in as we go through the revision process. But we also have Principal Participating Organizations as well. And those have unique channels where we can have discussions and get great input there. As most folks hopefully know, we have our annual Community Meetings and there's a lot of good engagement. Those are near the end of the year. And then we also have separate opportunities just for the assessor community where we have engagement calls, and we can get feedback that way.
So, we really, really leverage our stakeholder community and all of that valuable input as part of our revision process. And then we take all of that, we aggregate it, that's something that I do, and in our working group, most especially in this case, our software working group, we get to process all of that and then see how that will help direct the next evolution of our standards.
Alicia Malone: So, it sounds like it's really a collaborative process.
Mike Thompson: Absolutely, we couldn't do it alone, and we really do value our stakeholder community and all of the engagement that they provide.
Alicia Malone: Well, that's great. I know there are many changes in version 2.0 of the Secure Software Standard. Tell us about some of the most important ones that stakeholders need to be aware of.
Mike Thompson: Oh, there's so much good stuff. I don't know where to start, but if you're just getting used to it, the Secure Software Standard, maybe you haven't participated prior, or even if you participate in the 1.x, a great resource is our Document Library. And as part of the new publication, we have a Summary of Changes. So that'll document the significant changes between v1.2.1, that's what's out there now, and what we just published, version 2.0.
But I would have to say one of the most prominent changes is around what we refer to as sensitive assets. This is really the core of the new Secure Software v2.0 Standard. So that folks that were familiar with the 1.x version were probably familiar with the term “payment software”. And that had a very particular definition to it. And it was kind of a defining criteria for the standard. Folks will not see that term “payment software” in v2.0. Instead, what we've done is we've designed it again around this context of sensitive assets, and it has some underlying context, sensitive data, sensitive resources, and sensitive functionality. And this is really the center of what the Secure Software Standard is about for v2.0, so much so that we created a new companion document to the standard referred to as the Sensitive Asset Identification document. And that has great information. It's a document that's used with the Standard and that will really help with both the vendors understanding the context of the Standard and how to design their Secure Software product, but also for those assessors doing the assessment as well.
Along with that, for those folks interested in cryptography, we've aligned the baseline for allowable cryptography in v2.0 to the term “strong cryptography”, which is directly taken from PCI DSS. It's a long-established term, and it sets a baseline set of expectations for cryptography. And we have aligned the Secure Software Standard v2.0 to leverage that baseline of strong cryptography.
But also, it's not just about the Standard. We have the Program as well. We introduced wild cards. So, these are variables that can be used in the versioning schema by the vendor, and they can account for non-security impacting changes. So, this is highly advantageous. It allows the flexibility for those software vendors to make non-security impacting changes, and they don't need to make an update to their listing or submit something to the Council. But if there is a security impacting change, we've even revised that process as well. We refer to that generally as our delta change process.
Folks might be familiar with low and high impact changes from 1.x. We have redone all of that change process and we hope folks find that much more streamlined, much more straightforward in being able to manage their Secure Software products and their associated listings. And again, just as a reminder, we do have these documents in the Doc Library. I know we'll say that a couple of times, but we do have that Summary of Changes out there as well. Please do refer to that. It's got a great overview of the changes we've made in v2.0.
Alicia Malone: That is a lot of great stuff in this new version of the Standard. So, one of the things I wanted to also talk about is that there's been some groundwork done to start to consolidate the 3DS SDK Standard into the Secure Software Standard. What does this mean for both Secure Software and for 3DS SDK moving forward? And how will it affect assessors and other stakeholders who work with 3DS SDK?
Mike Thompson: Yeah, that's a great question. So, we have our PCI 3DS SDK Standard, 3DS being the EMV® 3-D Secure, and EMVCo maintains those 3DS specific specifications. So, we've had that standard and program out for a while, but the major revision to Secure Software really afforded the opportunity, especially given that we've broadened that scope as I just spoke about, to also assess SDKs or Software Development Kits generically. And this opened up the opportunity to also be able to assess EMVCo 3DS-specific SDKs as well. So, we do intend to have the new Secure Software Standard v2.0 and forward being the eventual replacement for the PCI 3DS SDK Standard. And hopefully folks will find that quite advantageous because of the more objective nature of the Secure Software Standard, it really does afford that flexibility that should be advantageous to all Secure Software Vendors, but that also includes 3DS SDK Software Vendors.
Alicia Malone: That does sound like some big news, so more to come there. And while it's not available just yet, what can you tell us about the upcoming Secure Software Lifecycle or Secure SLC Standard revision?
Mike Thompson: So, we are diligently working on that; it is also going through a major revision. So, that will also be a v2.0, first major revision that it has ever had. So, we're excited about that. So, there'll be more news in the future. But that will be out as soon as we can get it all finished up. And again, we're hoping just for the same improvements, all based on that stakeholder engagement I spoke about, so we can really provide that value to our stakeholder community.
Alicia Malone: That’s great. So, you did mention some of the documents that are now available for Secure Software Standard v2.0. Could you run through that list again and where stakeholders can find them?
Mike Thompson: Absolutely. So, as I mentioned, the Document Library. If you're ever looking for a Council resource, the Document Library on the PCI SSC website is a great place to go. We have five documents that were just published and I will run through them. So, we have the actual standard itself, v2.0, the PCI Secure Software Standard. We have that new document I talked about, the Sensitive Asset Identification document, and that's used for v2.0 going forward. We have the Summary of Changes I've mentioned that describes those changes from v1.2.1 to v2.0. We also have the Secure Software Program Guide v2.0 that came out as well. And as I mentioned, with that now being able to accommodate 3DS SDKs, we've updated the PCI 3DS Data Matrix. It is now on v1.2. So, that's a document that's used both for our PCI 3DS Core Standard and Program, but we've added 3DS SDK context to it so that it can also complement the assessment of those 3DS SDKs with the Secure Software Standard.
I'll also mention that coming soon, so not out just yet, but coming soon, will be the Attestation of Validation (AOV) template, the Report on Validation (ROV) template, as well as a brand-new Change Impact template. So, where folks used to use the little three-page template at the end of the Program Guide to submit changes, we will now have a brand-new Change Impact template that will have numerous improvements for that change management process.
Alicia Malone: That's fantastic. This is all such great information. And I'm so glad, Mike, that you could join us today on our podcast and share this with us. There is a blog post out there that folks can reference and check out, which lists those documents that you mentioned, and also just links to that Document Library directly. I wanted to thank you so much for joining us on Coffee with the Council, Mike, and for sharing all of your insights into the changes in Secure Software and what's coming up ahead.
Mike Thompson: Thank you. Glad to be here and I hope folks are genuinely as excited about this new revision as we are.
Alicia Malone: Once again, as Mike mentioned, Secure Software Standard v2.0 is now available in the PCI SSC Document Library, which we've also linked to in the blog transcription of this episode.
Like what you’ve heard? Subscribe to PCI SSC’s “Coffee with the Council” podcast by visiting any of the following platforms: Apple Podcasts, Spotify, Amazon Music, Anchor, Castbox, Google Podcasts, iHeartRadio, Pocket Casts, RadioPublic, Stitcher, Audible, Overcast, or Pandora.
