Ian Hillis
Hi everyone and welcome to PayFAQ: The Embedded Payments podcast brought to you by Payrix and Worldpay. I’m your host, Ian Hillis, and today I’m talking with Adam “Sully” Perella, Technical Director at Schellman, about where platforms can start with a PCI attestation of compliance, commonly known as an AoC. Welcome to the show, Sully.
Sully Perella
Hello and thank you for having me.
Ian Hillis
We’re thrilled to have you here today. So, audience, let’s give you a little bit of background about Sully, so you know you can trust where he’s coming from as an expert in the field. Adam “Sully” Perella is the master trainer for internal and external training at Schellman Compliance LLC. As Technical Director, he supports PCI, P2P, EP PEN, 3DS, secure software framework, zero trust, crypto and digital trust services in the IT security field, as has been for over two decades. Sully’s experience started in the Air Force and included data analysis, application testing, penetration testing, incident response, digital forensics, cryptographic operations, and most of the PCI assessment or validation programs. Sully maintains multiple certifications within information security and is active within the cybersecurity community. He helps draft new standards and speaks globally on cybersecurity. This is the expert we need here.
Sully, let’s kick it off and get everyone on the same page here with some terminology. What is a PCI attestation of compliance or AoC? And as a platform, why would I want or need one?
Sully Perella
An attestation of compliance is the final document. It’s the certification that accompanies a report on compliance or RoC that demonstrates anything a merchant or service provider is doing to meet the applicable PCI controls. That’s the short answer. I think that attestation of compliance is more commonly used when a merchant or other service provider says, “hey, how do you meet PCI? Or what services are you going to offer for me? And how does your attestation of compliance reflect what your organization is doing to meet those controls?” The value of an AoC is that it explains every service covered by that assessment. So, if we think about something like a hosting provider, Azure, Amazon, or Google, their attestation of compliance for cloud functions will say we do hosting services. Maybe they also include software development. All of these functions that have been assessed are included within the scope section of the attestation of compliance. As I said earlier, the attestation of compliance or AoC is accompanied by a report on compliance, which is pretty much never shared. And that report on compliance not only includes the exact same language within the AoC to say what services or functions are covered but also includes all of the details necessary for how those controls are met. It’s a report hundreds of pages long which includes all of the nitty gritty details, the policies, the procedures, who was spoken to, what evidence was observed, which systems were sampled, and the results of those testing. It’s kind of like the: you can go to your mechanic and get the bill of health saying your car functions, but on their side, they have a really detailed report of all of the things they tested and the result of those individual tests.
Ian Hillis
So, I think there’s a lot of nuances and expertise associated with this. If I’m a software company and thinking about the initial pieces of this, do I need to hire someone? Who could I start to talk to about getting a PCI attestation?
Sully Perella
That is the question. A Qualified Security Assessor (or QSA), that’s what the individuals who are certified under the Payment Card Industry Security Standards Council (or PCI SSC). There’s a lot of acronyms here. So, if anybody struggles with any of this, reach out and we can go through them individually. But a QSA is going to be the person you want to speak to. They’re going to understand the applicable requirements and then what your organization must do to demonstrate that they’re met. And for a software creator or software provider, this can be something as simple as: What are your software development processes and how do you do this? Or it can be something more inclusive that in addition to providing software functions, you also provide hosting services, in which case you have a lot more of a compliance burden to demonstrate. It is a lot of work. And by talking with the QSA you can say: well, this is what I’m doing, or here are the services we’re offering. What must be reviewed in order to demonstrate that we meet these controls so that any of our customers, prospective or current, can say we trust what this offering is? And on that message, I want to make a point to highlight that the Software Security Framework (and there’s a whole other series of acronyms here) provides the ability for a company to say this is what we do to meet our compliance burden for making secure software; from inception through development and maintenance. The Secure Software Framework has a function called the Secure Software Lifecycle where a secure software vendor can have their company listed as such. And then you don’t have to go through an AoC every year, literally an attestation program every year. You can do these every three years to the same end. This is how we manage software; this is how we do threat modeling; this is how we test our code. And all of these things are going to be both demonstrable and repeatable so that your customers can say the software product that you are developing is maintained and secure.
Ian Hillis
That’s really helpful context on what is a very complex topic there, Sully. If you think about a software company and obtaining that AoC and breaking that into steps, what might those steps look like? What could a software platform expect to go through over the course of that process?
Sully Perella
So, let’s start with the PCI and then I’ll make a carve out for the Secure Software Framework because there’s an incredible amount of overlap between them. When you speak to a QSA, utmost importance is that you’re honest. Honest about what you want covered and what you’re trying to accomplish. Your QSA is then going to be able to walk you through what is included in that environment. So, for this sample, let’s assume that your software company is just that “we develop bespoke software for our customers. Needs? You need ‘X’. We’re going to build ‘X’ and we have a baseline template that handles payments because that’s how PCI applies here.” In that model, the QSA is going to say, “okay, you are going to use ‘X’ platforms. These are the languages that you use. This is how you are delivering it. How are you managing that versioning? So maybe you have one or two versioning systems you want to discuss. Where are your employees? Are any of them outsourced? How is this maintained? How are you tracking the changes to this environment? So, you’ve got some version control system in place, and you have ticketing software. Usually these are related. Think about things like ServiceNow or Jira would probably be the most common. GitHub has its own. But regardless of the platform you are using, there are ways to track tickets, the changes, and the changes to software throughout. All of this is going to be included.” Primarily looking at requirement 6 within the PCI DSS, the Secure Software Lifecycle dovetails heavily here to not only include all of the elements of requirement 6, but expound and to elaborate on all of those details for how requests to changes are made for, for software, what story that you need to address, how this is communicated to developers. How do you say okay to these changes? What does that impact? How does this impact the security of the software? Who needs to know about it? And then you have a more detailed review within the Secure Software Lifecycle than you would in just the DSS. But the difference here, if you go with the DSS, you need to say to your QSA, this is how we substantiate our environment. This is a smaller level of networking controls and system management. Under requirement 2, you’ve got a lot more requirements and a lot more nuance, broad in scope to demonstrate where the Secure Software Lifecycle limits that but goes in greater depth. So, it’s, you’re trading one issue for another in terms of the lift. But we have found that a lot more of our customers, where they are secure, where they are software vendors prefer the Secure Software Lifecycle because they only have to go through the assessment once every three years and it can include the specific platforms that they’ve tested. All right, so that’s just the beginning. And so now let’s talk about the assessment. Looks like during the assessment, and this is not the same for every QSA company, but there’s a large amount of overlap and similarities between us at the outset of an assessment scope is confirmed. Here are all of the assumptions that we’ve made about what must be reviewed. And here are all of the milestones or checkpoints that we need to have along this journey so that you can substantiate the things you’re doing are done. Because a report on compliance or a Secure Software lifecycle assessment, regardless, is a moment in time and we need to see that all of those controls are actively being met. Not we’re going to meet it, not that we have plans to meet it, but this is what we’re actually doing. It’s, it’s the tying together. This is what we say we do, this is how we do that. This is who is doing it and this is how you can see it being done in the past, going through that process of demonstrating compliance in all of these areas. We record all of those. It’s a giant report. It’s a lot of fun to read. It’s riveting and enjoyable for all parties involved. And if anybody did not hear the sarcasm, I can say it again. But it’s a lot to read, it’s a lot to write, but it definitely demonstrates what a company is doing. Ultimately here you’ve heard me say the word demonstrating compliance about a dozen times each. These records of observations along the way show what a company does to create and maintain that secure software must be accomplished. There are no skipping areas, there’s no way that you can avoid some of these requirements. And in meeting all of those that’s recorded in your report on compliance, then you say, “okay, these are the services offered, these are how we observed these in place.” And as a result of that, you’re good, you meet all these checks. Here’s your attestation of compliance for this software platform and that way your customers know that when they’re working with you that you hit all of the checks they need for the software that’s going to reside in their environment.
Ian Hillis
So, you’ve done an exceptional job at demystifying that entire process. I think the audience is going to be very grateful for that. To wrap things up a little bit, you’ve been in payments compliance for some time now. What advice do you have for platforms out there specifically as it relates to this area?
Sully Perella
I think the first big point is to see your QSA as an ally. Both your organization and your assessor want to see you succeed. Your assessor has a lot of experience. I mean the prerequisites to be a QSA are high. Your QSA is going to be able to call upon a variety of different, well, let’s take journeys that other companies, your competitors likely have had to meet this. And while your QSA is not going to divulge any specifics about that, they are going to be able to say, we’ve seen in Azure that people do this. We see that when people are using this framework, they test using this model, or we see that this struggle in Agile is often addressed by doing these things right. All of these are ambiguous in my answer here, but that experience is invaluable. When a company engages a QSA and they see that QSA as an ally, then they can actively communicate their worries, their concerns. Maybe we want to test this new platform, but we’re not testing consistently. Or we’re testing consistently but we don’t test every single change because doing so would prevent us from maintaining an active development life cycle which meets our customers’ needs. And when we think about the CICD pipeline for most software development companies, they can’t do a full system test. So, we look at: “all right, if you’re only making changes to ‘X’, maybe a portion of the code that you’re working with, what unit tests have you done? And then how do you perform integration testing, regression testing, or similar to confirm that these changes didn’t impact the security of the whole?” In that way, these threat modeling efforts to identify attack vectors and the actions taken in testing can, as appropriately as possible, demonstrate that a company is meeting the intent of the requirements to routinely test. This is just one example of where these relationships are valuable. So, you can actively have this dialogue outside of just the assessment window. And then in that assessment window, you’re not trying to provide some polished experience, but really saying: “this is really what we’re doing, this is really how we’re accomplishing this.” And then your QSA can say: “here are the tools that you have, here are the paths you’re taking, here’s how this can be more simple, or here’s how your organization can make these smaller adjustments to meet these controls now and moving forward, because this has to be an ongoing.” And second, we far too often see companies that have a GRC manager or somebody in that role whose responsibility is to maintain these many programs, not just within PCI, but ISO, SOC, or others. And that’s a lot. And it’s needed, right? You need to have the people who can speak the language of compliance and align that with the policies and procedures of a company. But not often enough, let’s say not often enough are companies looking at or talking to the people who are doing this and saying: “okay, the intent of this requirement is to make sure that we include patching for all the dependencies. How are we doing that?” And making it a question for someone to explain what they do, where instead of by involving these people, you’re saying you’re seeing the actions in place. And this is where what somebody says and what you can demonstrate is already aligned. Which is beautiful. Where a GRC manager can come in and say: “we want you to accomplish ‘X’, we are going to tell you to do that, you’re going to do ‘Y’.” This is where you get that butting of heads, where you’re telling somebody to follow a prescribed path that doesn’t align with the actual operations of an organization, in which case things are usually not done to spec. And then you have this mismatch between the policies and procedures versus what somebody says they do and what can be shown in place. So, we like to recommend that people kind of flip that on its head. And say: “What do you do? How does this meet the requirement?” And if it doesn’t, you know, then you can shore it up directly with the people who are going to have to do that now and on repeat in the future. And then you say: “okay, can you document that process? Can you explain how this is going to be done now and in the future?” Then that’s written into procedure. That procedure is reflected with policy. And now you tie all that together where you have this repeating motion of the people who are doing the work can follow the processes they created to demonstrate that security controls are met and that meets compliance requirements. It’s a whole lot to digest there. So, did you want to tease any of that apart further?
Ian Hillis
No, that’s really helpful. So, I think the recap I have from that is one from advice perspective, QSA is more of a partner instead of a hurdle, and some great reasoning around that, and then certainly involve the people doing the work if they’re going to be a critical part ongoing across all that. I think that makes fantastic sense.
Sully Perella
And to elaborate on the value of communication, your third-party service providers, be it Worldpay, be it Payrix, be it Amazon, whoever, these organizations, you know they’re going to have their own hurdles and issues. But if you have needs to include what you are expecting from a software provider, this needs to be communicated, there’s no reason to hide it. There’s no unicorns or special sauce behind a lot of this. And your QSA, on the flip side of that, is going to say: “this is what you need to do to demonstrate compliance.” These candid conversations about the need, about the capabilities, are what simplify a lot of the communications between third parties and the people who want to purchase them. And then having straight answers also make these efforts a lot easier. Where if I’m talking with a software provider and I say: “what software are you trying to sell?” They describe it to me. I’m going to ask them at the end when we’re drafting up their attestation of compliance where it says the services included within the scope of this assessment, I’m going to say: “This is what we observed. Does this align accurately with what your marketing says?” And hopefully the answer is yes. And if not, we want them to have that discussion so that they can actively sell what has been assessed as compliant. And all of this kind of comes together which makes marketings lives easier, or rather all of this comes together which makes the lives of those in marketing easier. And it also meets the needs of the customer because we’re talking in the language of both compliance and security.
Ian Hillis
So, you have been a wealth of information on an especially complex topic. I can’t thank you enough for joining us and the audience here on the show today.
Sully Perella
Thank you. I really appreciate being here. Anytime that we are able to share knowledge with people, it should be done. Now, it shouldn’t be proprietary, right? We need to be able to share how these things are done. And if any of your customers have any questions, we always welcome you to reach out to us directly.
Ian Hillis
Fantastic. Ladies and gentlemen, we want to be a trusted resource for software providers who are out there trying to make sense of Embedded Payments and finance to help them get the education they need to make the business decisions their customers and investors will thank them for. Thank you to everyone joining us today and I look forward to continuing the conversation in our next episode.
