Watch to learn how to be prepared when your QSA comes onsite and how to get the most out of your audit.
Having issues accessing the video above? Watch the video here.
When it comes to PCI audits, being prepared is the key, but what should you do before your auditor shows up? If you're organized and prepared before your QSA shows up, your audit experience will be much smoother and quicker.
View this webinar to hear from our featured presenter, Jen Stone (QSA, MCIS, CISSP, CISA) and Brian Gross, Executive Vice President of Pineapple Payments, as they discuss audit preparation best practices, such as:
This webinar was hosted on April 11th, 2019.
0:01 All right, everyone. We are ready to get started. Welcome to our webinar today. This is how to prepare for a PCI DSS Audit. My name is Andrew Garrett. I work in marketing here at SecurityMetrics. And our presenter today is Jen Stone who is a Security Analyst at SecurityMetrics and she holds the credentials of QSA, CISSP, CISA, and MCIS. So we're really looking forward to having Jen on the call with us and then we'll show you her picture here as well so you can know who's who's presenting to you today. So, this is Jen Stone recently returned from India actually last week doing some audit work over there. So she has years of experience with PCI.
1:00 We're really looking forward to hearing from her and also joining her on on our webinar today is Brian Gross.
1:11 Brian is the Executive Vice President at Pineapple Payments who recently partnered with us for a PCI audit and so it's going to be great to have his experience. So he'll be giving us kind of a first-hand testimonial of what it's like to conduct a PCI audit having just gone through one. Brian, if you're able to take about 30 seconds or so and and introduce yourself and maybe tell us a little bit about Pineapple Payments. Yeah. Absolutely. Good morning everybody. My name is Brian Gross and I’m the Executive Vice President over here at Pineapple, we’re both a payment gateway and a merchant acquirer and I'm responsible for overseeing technology and operations here. I'm also a co-founder of the business.
2:05 So I come at this from both sides as a stakeholder, but also as a technolgoist, I’m a self-taught programmer and have been in SAAS and technology for the last 10 years. And ave had a really fantastic experience, excuse me, working with SecurityMetrics so far and we're excited about the future of our partnership. And I'm hoping that today Jen and I who have worked together in the past can share with you some of our experience to hopefully help make your lives a little bit easier when it comes to this stuff. Awesome. Okay. Thanks Brian.
2:41 So with that we're going to go ahead and dive into the presentation here and one question we get asked all the time is if we will be sending out the recording of this presentation on the slide deck. So, just to let you know we will be doing that. We are recording this right now and will be sending out the recording to the email address that you used to register for today's webinar. So keep an eye out for that in the next couple of days. We'll make sure you get that for your review. Well, at this time I'm going to go ahead and pass the mic over to Jen and we will get started with our agenda. Thanks, everyone.
3:19 Good morning. I'm so excited that we get to talk about this today. It's one of my favorite topics because it means usually we're talking to people who are fairly new to this process. And I find that it's a very interesting point in a lot of organizations development. So today, we're going to be talking about how to be prepared and how to scope, which can be really difficult for some organizations and pretty simple for others. And then how to get the most out of your audit. Audits tend to be fairly stressful and they can be time-consuming and expensive. So the more you can do to prepare ahead of time the more you're going to get out of it. I'm super excited that I get to talk to Brian with this.
4:10 We had a really interesting I think audit together and it I think for me it kind of surfaced a lot of things about how we can help people ahead of time, more, and some of the interesting things that happened during an assessment that a lot of organizations may not be aware that they are going to have to deal with. So, starting with the 7 tips to prepare for you for your audit. Number one; assign a compliance leader. So, if you have a lot of people involved in an audit, but nobody's really driving it that can get confusing because then knowing who's gathering the information, who's kind of leading it on the side of the their the other the or your organization. Sometimes we get organizations that think that we as auditors are going to be creating a project plan for them and doing that interaction reach out to the different people involved but that's actually a really inefficient way to work with your audit company. Brian, from your perspective when it came to deciding who is going to drive it on your end, it was kind of a no-brainer, I think, because you're so heavily involved, but can you talk, speak a little bit to that concept of who leads an audit from the side of the organization? Yeah. Absolutely. It's really important that someone owns the process and that's a single individual so that you have continuity with you know, the entire process and that person has to also be known internally that you know, this is the leader of the effort to go through PCI this year and that person should be responsible for bringing in the appropriate stakeholders to help throughout the process, not leaving it up to Jen or whomever else it might be. To herd cats, you know.
6:18 Jen's job was to help us, you know become a better organization from a security standpoint and get through something that you know is we like to think of is not something that we have to do, but we want to do and we should be doing no matter what and so if you take that approach to all of this, it's a much smoother approach and having you know that single person that figurehead lead things is really a key to making that a success. I'm so glad that you pointed that out about security, a lot of times especially with newer organizations or groups that occasionally we'll run into groups that just don't want to do PCI. They find it to be a nuisance and they want to focus on other things internally and don't understand that using this as PCI compliance as a way to ensure their security that it's actually super valuable. It's not just a check the blanks and and meet a certain criteria and then move on, it's how do we evaluate our systems against a known standard and then increase that security sense. I'm glad you kind of pointed that one out. Yeah, absolutely. And that leads, that actually leads really well into your next point. Not to steal your thunder, Jen. No, please do, ya. The way, you know, again, the way to think about this is that if you know PCI is not a cost of doing business or something that you have to do, PCI is just a way to facilitate a security posture and these are things that companies with technology and data that needs to be secured should be approaching things on a daily basis. And so if you know get stakeholders involved in that mindset, then it becomes a lot easier to tackle this and you know, the process of the audit itself is then the time horizon is much shorter, you're much more well prepared and the stakeholders understand that you have to devote a few days a year to making this a smooth process.
8:24 But if you don't do things as well, walk through some of these other tips, you know in the right fashion, then the conversations become challenging of a why are we doing PCI compliance for three months out of the year or why do we have to move our development roadmap over to this direction to solve for these things if you get people prepared and with the right mindset the whole thing is a lot simpler. Absolutely. And whenever I encounter an organization that approaches it from that standpoint everything goes much more quickly and there it tends to be more valuable to the organization. When I encounter an organization that seems to be just the IT department is involved in PCI, or it's it's driven from maybe the wrong level of the company. That's when it gets difficult because who is, not having the right stakeholders can hamper your ability to make those decisions.
9:17 These are often business decisions not IT decisions on how and how much time and effort you're putting towards closing the gaps that you find in the assessment quickly and making sure that things really are secure as possible.
9:37 So that kind of brings me to the next slide which is understanding your risks. So when you have a PCI audit, one of the things that we have to look at is what is your risk assessment and it's kind of glossed over in a lot of places. Well, we know what our risk assessment is because we ran a vulnerability scan or here's my one page three-point risk assessment, which is really not sufficient and does not help you to complete either closing the gaps that you know about ahead of time. So you're going to get a lot longer remediation potentially for not knowing your risks prior to an assessor getting there. So from your standpoint, how does risk assessment fold into the PCI process. Brian?
10:35 Yeah, it's something that we look at on a quarterly basis and often times. It's more frequent than that just because of things that we're building or challenges that we need to overcome with the objectives that we have as a company that tie, you know back into security and PCI ultimately. But the best way to think about risk assessment is, you know, not just identifying the risks but how do you prioritize those and in the right way in order to tackle them. And so that you know, when we speak in, you know on the annual basis, Jen, that it's not we’ll hear all the things that we found and we've done nothing about it. But you know, here's where we were able to take through action to remedy certain things and so doing that more frequently again more iterative taking a more agile approach to all this is the best way to do it. And so I would even recommend doing this quarterly with the right stakeholders.
11:35 Beyond annually, because it just makes things easier down the line.
11:40 I think that's really wise counsel and especially when things change in the environment. So a lot of organizations are growing expanding through mergers and acquisitions, and that's a great opportunity to use the due diligence portion of that activity to do your risk assessment on systems that are going to be evaluated against PCI and and others that need a real solid security stance. So having a regular one, having an understanding of how a risk assessment works is only going to be to your organization's benefit.
12:19 Again that definitely keys in on the next slide here of you know, what we went through together most recently which was, we had purchased a company that had a payment platform and had some real needs of what I would call almost clean up on on both the technology and the PCI side of things and so we used the due diligence process as an opportunity to go in and do a SWOT analysis of both policies and procedures along with the technology itself and that became our roadmap for what we ended up tackling together to get the platform and some things within the business itself to a place that we felt comfortable with and that starts with you know, what we're looking at right here about analyzing your environment in the right way. Absolutely. I think without that SWOT analysis we really would have been in a much more difficult position going into that assessment, but because you knew what was going on in your environment and you were very clear about understanding some of these vulnerabilities. And and how do we address them? It made it so that compliance was much easier to reach and also a solid security stance resulted from it. Yep.
13:37 So what are the things that people ask me is how do I know what my vulnerabilities are and it's going to be different in different organizations depending on the technology that you're dealing with, you know, if you're developing code to use internally in your organization, or if you're developing code that has an external service, you know, people can get to your systems using portals that you have developed. The software for knowing if there's vulnerabilities inherently in that software just by doing some good code scans do some good vulnerability scanning from an ASV provider these things are going to help, you know from a more automated standpoint or from a tool standpoint things that you might not see if you're just too kind of manually looking for vulnerabilities or doing a thought experiment on them. So I think that finding the right tools to analyze your environment helps really solidify the details of your knowledge of the vulnerabilities.
14:54 I would also add, you know, the tools piece is hugely important in some of the things that we've been able to implement together around regular vulnerability scanning and penetration testing and things. Those are hugely important, but you actually have to do them. It's great to talk about them and you know doing them on an interim basis or making sure that you're in the right place with readiness assessments, but you actually have to execute on those and that's ultimately what we're doing now together, which is something that we would I think recommend to everybody sure and then once you know that there are risks knowing how to prioritize them gives you a roadmap for fixing them.
15:39 So when we talk about risk mitigation that prioritization process is key. A lot of times people will say well I'm going to go fix this because I know how to fix it or it to be something quick and easy and there's something to be said for taking care of the low-hanging fruit, but also knowing that you have a high risk security issue in your environment means you're going to want to tackle that first, even if it is more expensive or you have less familiarity with how to approach it.
16:16 Yeah, absolutely. And we had a great experience of that where you know, there was some things at the code level that would have been quick and dirty so to speak to implement but you know, we really needed to look at a higher level at our entire network structure and firewalls to make sure that things were configured appropriately and that was much more intensive but ultimately much much riskier for us and that's something that you know, we wanted to make sure that we prioritize on an ongoing basis to review firewall rules and policies and procedures, you know quarterly as well. It's just tackling the simple code things that you can change frequently and easily. I think that also gets back to your unique position as a technologist in addition to being a business leader you had the ability to understand what was going on and then help with making those business decisions on what was being tackled.
17:16 Not everyone has that in their organization, but everyone has technologists that they can lean on and the business people to make the decisions. So where you have more people involved, it requires more communication and the challenge there is technologists clearly stating what they understand the problem to be in a way that people who are non-technologists can take that information in, and apply it so that interface between technology and business is often a place of conflict, but it deserves attention to create really strong communication between those groups. So that good decisions can be made and risks can be mitigated in a timely fashion.
18:04 Yeah, yeah. So then this was this is always a fun one keep your documentation updated sometimes and I think we ran into this you can go into an organization and they think that things are a certain way and then when you start testing the assumptions things just aren't lining up and aren't lining up and it's because nobody updated the documentation to say no, this is how things are done now, and I mean not to reveal too much about, you know, what went on with your organization, but you know in an acquisition, of course, this is always going to happen but not just an acquisitions. It's going to happen also in in organizations that have been around for a while and had the same people who just don't think about how to update that documentation.
18:52 Yeah, and it's again this is part of you know, if you do this on a regular basis and not just update the documentation but follow suit on the policies and procedures that you put in place and you know, when you say you're going to do a tabletop exercise for you know, an incident response in the documentation, you actually do it and you document it and you keep that up to date and do it on an ongoing basis that's really how you create this more of a security posture and PCI readiness type of environment instead of a reactive sort of approach each year when the audit comes up and we had to go through the exercise of retooling documentation and altering policies and procedures and all sorts of things as we came into a sort of, you know, state of the environment and the policies and procedures as they were, that didn't necessarily meet what expectations we have of ourselves, but also as PCI expects from us and you know, simply showed us that across our entire business. This is something that we need to do on an ongoing basis. It makes things much simpler and you know with this business unit of ours specifically, last year it took probably 60 days to go through all this but because we're keeping things documented enough to date and we're being proactive about it now, we should be able to breeze through this in a matter of a couple of days together. Absolutely and I cannot stress that enough because it's a super heavy lift to do all at once but it's relatively smooth when you, as you said, do it throughout the year.
20:34 So that brings us to one of my favorite topics in PCI, which is scope, because it's hard, it's hard, especially if you have a complex environment or if you are a service provider or if you are kind of new to PCI. Because some of the language that is used is very specific to how PCI looks at environments and some of it is just especially some of the words that are used in it we use in regular daily life in a lot of different ways. Like segmentation. So segmentation to somebody in IT operations can mean, well, I've got a VLAN here and I've got VLAN there and I got a VLAN there. But, in PCI segmentation, if you want to reduce your scope by segmenting your network, it means some very specific things about what communicates with what and so, understanding all of the system components that are included or that are connected to that can be a challenge. Fortunately I have pictures that will help kind of talk us through what that means. So it starts with knowing where the information is going. How does it come into your systems? What does it touch? How does it, where is it stored? And these things don't happen in a vacuum, right? It starts the information card holder data starts somewhere and then is sent to you in some way and if you can figure out what those pathways are, then you can start figuring out what is your environment related to PCI, and then you can figure out how to scope that. What was your experience with scoping your environment? It was, we definitely had some fun with it because we were, you know of course going through the exercise of, we knew where the existing technology so that we had but when we acquired this new platform, it was a really fun process to you know, remap everything we had to look at every database, every server, every IP address that we had and piece the puzzle together and ultimately that helped us to just know better what we needed to do moving forward with with the platform as a whole as we look to integrate it into our broader technology, you know, but ultimately what it comes down to is is making the right technology decisions as you can to reduce scope and so, you know while it's important to be able to execute what you need to do from a business flow, a business process with your technology, anything that you can do to highlight and set the right boundaries of where cardholder data is flowing and make sure that you keep that documentation up-to-date along the way, that those are the things that will drastically benefit you in the process of of all of this because knowing where the data is going is probably the most fundamental piece of all this because if the data is not going there then your efforts are significantly less when it comes to PCI. But if the data is there and it's passing through or its resting there that's where you need to really spend the time and attention and make sure that you know where the boundaries are but also protect them. So yeah, definitely and sometimes it requires having several different people in the room from several different parts of the organization to get a complete picture of how that information is flowing through your systems.
24:18 Sometimes you can do with fewer people, but the critical thing is if the right people are in the room to answer all of the questions for your assessor they can help you better get a really solid understanding of all of that as a single snapshot of your environment. Yeah and using that stakeholder or you know, the person who's kind of leading the PCI effort, that single individual, to help as I said before heard some of the cats of you know, get programmers involved, get sales people, get customer service people involved, understand how business users make use of the technology and where the data is coming from and then the technologists behind the scenes can help fill in the gaps of you know, ultimately where that data lives.
25:19 You know I agree with you completely. Make sure that both technologists and business stakeholders are there to fill in any gaps of understanding how business users make use of a system and how, you know, cardholder data gets into the environment and then, you know, the technologist can fill in behind the scenes on, you know, where that data ultimately goes and what the different touch points are as far as the technology environment is concerned right?
25:48 One of the gotchas that I see occasionally is in working with, especially if it's kind of an IT driven effort, that the understanding of business processes is not there because that's not their job the you know, the technology part. If you have a large complex organization people focus on their areas, so they shouldn't be expected to know how some of the people on the business side interact with cardholder data, but finding the right person to lead that so you can go and talk to all of the people involved. Who in accounting has access to cardholder data and why? Is, for example, one of the places where often that conversation doesn't happen until the question is asked. Yeah, so if we talk about knowing where it goes then we can talk about how do we segment the environment so that we can apply adequate security controls to the places that most need it and make other business decisions on parts of the environment that don't necessarily interact with cardholder data. And here's the picture that I wanted to use to talk about that. So in PCI, we talk about in-scope systems, we talk about CDE systems.
27:11 We talk about connected to systems and those concepts can get kind of confusing unless we start with the very basics and that is if you have cardholder data in your environment, whether it's passing through a web server or whether it's being stored, those are all in-scope systems. Think about if someone were to try and retrieve that information; hey need to go where it is. And so sometimes that means starting off from a vulnerability on a on a e-commerce website. Or sometimes it means reaching a device that's in another part of the network that can communicate with that web server. So if you look at this diagram, the upper left-hand corner says shared services, the upper right-hand corner says critical data and the lower left says corporate LAN.
28:14 So let's take for example the idea that the corporate LAN where the employees work is not supposed to be able to communicate with where your cardholder data is because they don't have a business need. So that's why we have the big old circle with a cross through it that indicates no communication between your corporate LAN and your critical data. Now where you’re going to save time and money on an assessment is if you can prove that the corporate LAN is out of scope by doing a segmentation test, then we don't have to look at all of the security controls on all of the devices in the corporate LAN. So that's what we mean. When we say segmenting your environment can reduce the scope it sets that aside for other considerations for security in other ways, but not for the purposes of, that's critical data that has to be protected. And then if you look at the shared services part, a lot of the times you have systems that the operations team, your IT guys are using to protect or communicate with the critical data systems. They have to be considered in scope for the assessment even though they are not considered CDE or where the cardholder data can be found because they can communicate with it.
29:49 So if you have an admin who can communicate with your critical systems then that's why it's called a connected to system. And that's why connected to systems are considered in-scope for a PCI assessment. Branded, that makes sense, the way I said that like we I think during the introduction it was mentioned that I just got back from India and I'm fighting a lot of things today and I'm not chop. I'm hoping I'm making good sense. Yeah. Absolutely. I think you know, if just to add some color, because we went through this together. We had a system where cardholder data was being stored just due to the nature of the word processing payments and retaining cardholder data on behalf of our customers using us as a security solution, but that data while secured in the right way, they lived in the same place as other systems that we had which pertained not to that cardholder data, and so simply because of the proximity during our PCI process that we went through last year, everything was in scope when it really didn't need to be so what we've done in the first quarter of this year is segment the cardholder data from systems that have no need for it. And you know, when we get to next year's review the scope that we're looking at is going to be significantly smaller and thus will allow us to get through things a lot more quickly. Now, I always feel the need to say that that doesn't mean that you should be ignoring out of scope systems and security around those. You still need to make sure that you have the right posture there, but for the purposes of PCI itself the process of getting through the audit becomes a lot simpler.
31:43 I'm glad you mentioned that because PCI requires very specific types of security controls that are fairly prescriptive, but you might want to make security decisions on other systems that serve different needs and so having segmentation there allows you that flexibility to make business decisions on non PCI systems for your security stance there, but again being a security analyst, I mean, I want everything secure, but I also want it done in a way that suits the businesses need so that you can function. Exactly. So internal communication. This is all about that ongoing compliance that we keep getting back to but I think it's worth re-examining the idea that you have ongoing compliance needs that meet. You have monthly things that you have to do. You have daily things that you have to do quarterly knowing what these things are is going to help you with your internal flow of examining those requirements.
32:56 Yeah, if you spend a half day a month or a couple days a quarter, that saves you from spending weeks at a time when it comes to you know, the on-site review and everything to prepare and you know, if we all have jobs to do on a daily basis to growth business that you know, while PCI is a component of that the exercises are not directly related. And so if we're heads down on PCI for two weeks or three weeks at a time that's taking away from everything else that we should be doing. So if you know, implement it in there on a regular basis with a good cadence, you know monthly or quarterly to address what needs to be for keeping documentation updated or tabletop exercises or reviewing systems, then things are just you know much more of a breeze. And Jen, as you said at the beginning the expectation is not for you know, in our case SecurityMetrics to come in and do all this for us, you should be reviewing what we do on a regular basis and making sure that it meets the standards and the way that it needs to. Absolutely. So one of the ways that we can do this is through vulnerability scans and pen tests. PCI says you should have quarterly internal and external vulnerability scans. I have a lot of customers who do it monthly because they use vulnerability scans as part of their ongoing vulnerability management program and they want to make sure that that information is as fresh as possible.
34:36 Yeah, and you know when you're building, it's one thing if you have systems that are in maintenance mode, so to speak or you know, making small updates to over time, you know, just having those things on quarterly making sure that you know if anything changes that things are looked at. But for us, we’re constantly building new products and a lot of them do touch cardholder data. And so anytime we're implementing something new, we look at it from a holistic security standpoint and make sure that we're you know, we just build a new tokenization solution. For example, if we're doing a very specific review of that system with vulnerability scans and pen tests and even doing some more in-depth readiness review, you know, with you Jen, to make sure that everything is up to par and that we've implemented things and in our plan for the future is in line with where it needs to be with the rest of our technology platform.
35:30 So, these things are definitely critical, especially if you're, you know, making more critical changes or updates to systems on an ongoing basis. Definitely. So, penetration tests, there's sometimes confusion from people over what's the difference between a vulnerability scan and a penetration test. But if you think of it this way, the vulnerability scan is more the automated portion of the test and then penetration testing sees those automated vulnerability scan results and tries to exploit them using manual and additional tool methods. So a vulnerability scan can give you a certain amount of information, but the penetration test will demonstrate to you how that can be exploited in your environment. One of the risks that a lot of companies run into is that don't quite meet their goals for the date, for their compliance that they need to meet every year because they start their penetration testing too close to the time of the on-site assessment. And so if you know that you have penetration tests that are part of your assessment, I advise people to get them done three to six months before the on-site date and that way you have all of the time that you need to remediate any potential issues that surface but also gives you a good knowledge of where you're at going into the assessment.
37:04 Yeah, and we're on the same page there. That's great. And I like what you said earlier about working with your QSA. We did indeed have a conference call. I think it was last month talking about the the new architecture plans that you had for for making some pretty dramatic changes to the way that you approach things are expanding on some of the services that you offer and the approach that you took was we are not going forward with this until we've talked to a security analyst, third-party about this, which I thought was a very mature approach to take since you have a lot of knowledge and skills internally into your organization. But you still felt that it was in your best interest to also get a third party to talk to about what the potential changes, how it would impact your security standards and how it would affect your PCI compliance assessment.
38:01 Yeah, and and I mean Jen, obviously we trust you a lot but I think in a baseline, you know spending a little bit of time and a little bit of money upfront could save a lot of hassle if we built something for, you know, three months with with a whole product team that didn't meet the requirements then we'd have to go back and do it all over again and retool and that's you know, that's a whole lot of wasted time and resources well beyond. So, you know, it's just about being, again, proactive and and we want to do things, you know technology changes so quickly we want to make the best use of the latest available tools and and allow those to help us forward and so getting some insight externally, sometimes you can get really deep in the weeds when you're building these things yourself or architecting them yourself and that's true both on the technology and the business side, you know, you have certain objectives, you know, you want to meet those and that's all you focus on but there are other things that need to be considered too. And I think you helped Jeremy for my team specifically, you know think through all those finer points during that process and it points out having an ongoing relationship with a QSA so that you can reach out and do that when it when it's an annual thing and you only interact with them once a year that can be harder, especially if you make changes and then they're coming into a new environment, going, Well, I did not prepare. I didn't do my research on the specific tools and technologies that you're currently using so they need a little catch-up time. But if you have those interactions during the year, then everybody gets to stay abreast of new developments together.
39:47 Yeah, it's it's just like anything else if you're you know going in to get a mortgage for a house at a bank or you know, anything that you need to provide documentation for in everyday life. It's a lot easier if you have everything organized upfront and can clearly speak to what the body of work is that you're looking at and and you know, it seems a lot of hassle rather than trying to piece things together at the last minute. So definitely.
40:18 Well, I think that we're reaching sort of the end of what we wanted to cover today. Some of the takeaways that we had were that the one that we keep getting back to you regularly; update your documentation. Of course, you're going to validate your scope at least annually, but then make sure that you're on top of things internally that the constant internal validation of your vulnerabilities and your security controls is only going to benefit you and then make sure that you talk to your QSA on a regular basis. So, even though PCI says once a year, I think the message from today's webinar is, make sure that you have an ongoing process for dealing with your security controls.
41:15 Andrew. Oh sorry. Go ahead, Brian. No, I was just going to briefly add. You know when PCI says that occurs once a year, we like to think of that we see you for a couple of days that we have a lot of fun going through this stuff once a year together, but the rest of the year we do this on our own and we're proactive and this has become a course of daily business for us. It's not something that we think of again is something that we have to do once a year that we need to do it or you know, we want to do this. This is the best thing for us because if we were ever breached that would be a huge problem in the business that we're in and we've seen competitors go down because of a lack of readiness or being proactive and only being reactive. So, you know, stay on top of it.
42:00 It makes things a lot easier and you know, not too many people think of this is as being fun, but it's a good way to build a culture around security at a company of getting folks involved in might not always be and try and get them excited about it.
42:16 Right and that's for the organizations that I work with who are proactive like yours. It is a fun process, fun for the assessor to go in and say hey what's going on and really be able to just kind of put the bow on what you've already been doing all year. It's not fun when people are not proactive. It's it becomes a real slog if it's only a once-a-year thing. So, Andrew tells me that we have an audit management tool that we want to talk to you about when doing an assessment. One of the one of the challenges is, how do we ask for and receive information? How do we share that in a way that is organized and supportive of the customer? And so I think that's what we're going over now, right? Yeah. So we wanted to show a quick demo of our Suralink tool and then we'll get into our Q&A. We've had a lot of good questions that have been chatted in already.
43:15 So we'll get to those In just a minute, but just to give you an idea of our Suralink tool we're going to take a brief pause here and just show you this quick three-minute demo of Suralink, today. We're going to be taking a look at Suralink, which is the tool that we use for creating and tracking tasks exchanging files and overall just to help the audit process move along more smoothly. So upon logging in you'll see under active engagements is a list of the projects that are currently in progress. This is nice because if you were a larger company such as a university or a restaurant chain, you can have anywhere from five to fifty engagements going at a time. But it also works great if you're just a single company. You can take a quick high-level glance at the progress of each project from here. And on the bottom left, you'll see a list of what's called my team. This is the personnel from your company that we've added to help work on these.
44:16 One other nice feature of Suralink is, I'm going to hop over real quick to the view of SecurityMetrics to show you this, but if you have, you know, over 20 or 30 people and they don't want to have access to all the engagements at a time. You can restrict who has access to which engagements, I just have to request that through us.
44:39 So that's the company team, over in the bottom right is the SecurityMetrics team. This is the personnel from SecurityMetrics that have been assigned to the project, it gives you their email address so you know who to contact if you have any problems or questions. Now, we'll go ahead and take a look at one of the engagements.
44:58 Once you click on it, you'll see a list of all of the requests clicking on any of those will give you a more descriptive kind of a better description of what we're looking for to close the request and you'll notice on some of these is a link with firm provided files. These are documents or files that we provided to you to help you with completing the request.
45:22 Each request has three statuses. There is outstanding, which is this blank status. Is this how they all start once you attach a file which we're going to do now.
45:37 You'll get a little yellow exclamation point which means it's fulfilled. This will flag it for the QSAs review. If any of them are returned, you'll get this red X here and in that case you'll want to scroll down and check the comments. So I left one for myself here. It says please revise and update your network diagrams. This is just a description of what needs to be done in order to fulfill that requirement. Now if you ever have a request that is outstanding, but you don't have a file to attach you can change the request manually to fulfilled or if a file that it's attached to another request will fulfill this one. You can change it to fulfilled and leave a comment explaining that once the requirement is fulfilled, it'll turn green. One of the things I want to note here is we break up all of the requirements into different sections for each of the requirements for the PCI DSS. So it's easy to navigate between each section here. When it's fulfilled though, you'll get this little green check mark and it will be closed.
46:47 That was just a high-level look at Suralink. If you'd like a more in-depth look or have any questions. Please feel free to reach out to your account manager. Well at this point we're going to go and head into the Q&A.
47:00 So, I'm just going to take a moment here to pull up some of our questions and then while I'm doing this, if you have additional questions, feel free to chat those in. Obviously we're not going to have time to answer everyone's questions on our live webinar here, but we are noting every question that comes in and we will make sure to reach out to you on an individual basis via email to make sure that you get the answers that you need. So, our first question that came in here is a question for Brian.
47:41 We have someone asking how much time it took you to get PCI certified once you started the project. Also, did you already have a PCI zone within the systems that was storing cardholder data? If not, did you create a new one? How much time did that take separately from the PCI audit process? Was there any overlap?
48:06 Yeah, yeah, happy to answer. You know, it was definitely a unique situation for us is you know, we again acquired this platform and they had already been going through PCI for a number of years, but you know, it took us probably a month or so to really get prepared and then it took I would say another month after that to go through all the documentation and get everything squared away with remediating penetration tests and some other security vulnerabilities that we had at the time and in the length of time that it took was purely due to a lack of posture in place prior to our arrival. And so that's why a lot of these things are critically important to do on an ongoing basis. We did already have a DMZ in place.
48:54 We need to make a couple of small tweaks but ultimately that's what led us to make some different decisions about how we approach our technology and our platform moving forward and so as I mentioned we’re learning some new things and you know, it takes time and money but it's all worth doing, it makes us much more secure, much more scalable and we're actually going to be able to monetize some of the things that we're building from a security standpoint in the broader market. So, I think if you look at it as more of a you know, a business opportunity not a technology requirement than you know, you're in a much better position moving forward. Great, thanks, Brian. Our next question here. This one is probably for Jen, but we had a question. Are there any recommendations on how to pitch PCI to stakeholders or other security frameworks tend to be a higher priority? That is a great question.
49:53 One of the first things that I typically ask a new customer is what's driving this assessment what you know, why are you engaged with us and a lot of times it's because the business leaders recognized one or more driver to go ahead and do it. If you're a larger organization and have a lot of credit card transactions your bank will literally start fining you if you don't have PCI in place and so that's a good driver because it’s monetary. So the business leaders are like, oh well, they're going to start fining us and or make it so we can no longer process credit cards. But if you're smaller and PCI is more of a business decision, then understanding what the implications are for your company and being able to present those to the decision makers who are going to put the prioritization against it is pretty critical. So one of the ways that you can do this is to know personally how many, what is our transaction volume?
51:06 What does that make us in the PCI world in terms of whether we can assess or whether we need to get a third-party and so that kind of makes it so you can make some of the decisions on internally and do a self-assessment, self attestation if you're smaller, but the biggest driver is it comes down to is your bank going to start fining you? That's the reason that PCI has some teeth. Is there some real-world consequences to it?
51:41 Great the next question here. If you have no background in PCI compliance, what do you recommend to get up to speed in order to do the risk analysis and mitigation if you are not a tech or developer, is it impossible to really be effective in this role? Brian, what do you think about that? Yeah, so I'll answer the second question first. It's not impossible. It's actually somewhat better coming at it from the business side because you're able to if you have a conversation with a technologist, communication is really important. You need to really focus on aligning what the goals are and they should not just be singular in either business goals or technology tools that they need to come together and it needs to be both so I it's definitely not impossible. I've seen people do it before and you know, it's, this isn't something that should be looked at is hugely overwhelming.
52:40 Just takes a little bit of time and energy to invest in it. I'm definitely one one of the unique folks. I mean when I first got involved in this I thought the best way to do it would just be to read the PCI DSS cover to cover and I did and that was the best thing that I could have done. I mean, you know spending a weekend just diving through everything and really reading all of the requirements and and trying to match them up. So it's what you know our business looked like that was hugely valuable, but I think, find someone who's done it before, whether it's a friend or a peer or a colleague that you can lean on to have a conversation about it and just you know, understand their experience and what some of the pitfalls are but there's lots of resources online as well. As you know, blogs posting articles and companies like SecurityMetrics do a good job of putting out content that is hugely helpful with all this. I agree. And then, so getting up to speed on risk analysis and mitigation. Risk analysis can be an entire seal set all its own and a career path all its own but it doesn't have to be you know, some organizations can take a smaller, you know, skinnier approach to risk analysis and basically start where you're at start with the knowledge that you have no. Go do a search and try it, see what works for you in attempting the risk analysis, but knowing that you have to take it seriously and it has to be a fairly robust document coming out of it will help you understand the kind of time and energy you need to put into researching how to do it and then finding the answers and if you do a risk analysis against the PCI framework that sets you up in better, maybe a better position to do a PCI assessment that follows it. Can you hit on something that we haven't talked about, which is really important, is that PCI is just a conglomerate of different business practices, whether it's having, you know a disaster recovery plan in place or making sure that you have the right password from requirements and policies to you know, how you, again handle, you know firewall rules and all of these things combined come together to meet PCI requirements. But each of these pieces is something that you know does take time to tackle and their various experts and hopefully you have folks within your business that can help aid you in this process so that it doesn't feel overwhelming but it's important to look at the parts not just the whole as well here.
55:12 Right, exactly. Great, and going along that same line. We had a question about, kind of the small business side of things. We're a very small operation, but we do credit card transactions with very large companies. They pay online with their credit card and the funds go into our bank account. We do not retain our store their info. Do we really need to be concerned about this? Doesn't the processor have protocols in place to protect against fraud, etc? That is a good question because it comes back to scoping a lot of times. It's kind of a black box to small organizations, especially if you lean on service providers to do a lot of the work for you.
55:56 So the real question is, is it somebody else's website that is taking in that credit card information, or is it a website that you control some of the security controls on doing a good scoping exercise, is probably the first step that you need to do to know whether you have to be concerned about it or not. If you're entirely using a third-party outsourced organization, then the extent to which you need to be concerned about it is probably limited to what are your policies and procedures regarding choosing a good service provider. But if you have a website that somebody internally controls whether you have antivirus protection on it, whether you have just some of the basic patching vent all of those types of things and then from that website, they go to the payment page, you have an iFrame that takes them but then you have some other security concerns with regards to PCI, but it's really hard to answer the question. If we don't have a good scoping exercise that's done first.
57:16 Great, thanks, Jen. We're running out of time here. But we have time for just just a couple more questions here on the topic of scoping. We're having trouble getting leadership to understand that the systems connected to our payment environment are in scope because no segmentation exists. What have you used to help with this discussion? Yeah. And so that kind of gets back to the previous question is. We’re small. Do we really have to care about all of these things or we don't quite know how to characterize our scope connected to systems versus in- scope systems and scoping it's not easy in a lot of places.
58:02 I understand that it can take some time and some guidance from a third party, but the whole question about, we don't have segmentation in place and the business leaders aren't listening to us about connected to systems, that can be a tough one because you're asking non- technologists to understand some technology. The way that we have approached this is we have a life hack demo that I've done a couple places. I did it at SAINTCON, which is like DEFCON, only in Utah, people are nicer, and at HIMSS where like the healthcare industry. It's a way of showing this is where we start and this is how we get to your information using these connected systems. So, I don't know if we have that Live Hack demo online or if you are technologist who knows how to say, Okay, I'm going to show you a quick walk through because remember most of your C-levels are not going to want to spend a lot of time on this. A lot of your VP levels that just don't have time to sit down and understand technology because that's not their job, right?
59:09 So, how do you as a technologist say these are connected to systems that can speak to these if this system gets popped, they're going to get to the good stuff. And then how do you tie all that together kind of depends on the size of your organization? And whether you have the ability to to demonstrate that, I'm going to ask Andrew to follow up on that after the call because I think a lot of that demo has been very effective in talking to business leaders in the past because it opens their eyes to what does a communication pathway open your systems up to as far as. One more brief thing to add is of course the conversation goes with stakeholders and it's usually best to approach it from a return on investment standpoint.
59:58 So if you think about time and resources, if you spend a little bit of development time to segment things up front, it makes the process of going through your PCI annually a lot shorter and a lot simpler. The other way to approach it would be if you know like Jen said if there is a true security risk with all of this. Those things are unquantifiable, how detrimental they could be in the future. And so again spending a little bit of time and money upfront could save a lot of headache and hassle on a go-forward basis. Absolutely. Well, thanks so much Jen and Brian. This has been a great webinar. We've heard a lot of great insights today on how to prepare for a PCI audit and we really just want to give a big shout-out to Brian. He's been a great help with us today providing some of this firsthand experience.
1:00:50 So, we really appreciate him hopping on so with that we're going to go ahead and wrap up as I mentioned. We were recording this session and we'll make sure to email out the recording to all of you for review. Again, if you chatted in a question that we didn't get to will make sure to reach out and get that question answered as well.
1:01:12 Well, we do these live webinars about once every month. So if you'd like to stay up-to-date on future webinars, you can subscribe to our newsletter on our website. That way you can keep in touch with all of our webinars last month. We did a data breach webinar, and and I think upcoming we have another PCI audit webinar scheduled in a couple of months. So thanks for joining us today, and we hope to see you next time. Thanks, everyone.
.svg)
