Ian MacMillan - Compliance to the Rescue: Transforming Compliance from Burden to Benefit

All right. Uh, and now we're gonna have Ian speak on compliance. Hello. I'm not sure if you can tell by the way I speak, but I am not from Quebec. [laughter] Uh, my name is Ian and uh, I'm here to give you a talk on compliance this afternoon. So, now that we've all had bread and pasta salad and the temperatures coming up, uh my two objectives are to keep you awake and hopefully to give you some insight here about how compliance can help uh strengthen and improve your security program and how it doesn't have to be something that you dread or dislike um and something you can actually use to your benefit. Uh so, a little bit about

me. My name is Ian McMillan. Um, I'm a senior manager in cyber risk and compliance at M&P Digital. I'm also a co-founder of Berron Security. So for anybody that knows about Boseron, I'm not the person that personally sends you fishing simulations. I built a product that does that. And um, yeah, my background is in software development. So originally started as a developer. I've worked on uh security tools like curar. Uh, if you use the um DSM editor, I did some work on the DSM editor, the log source management app. That's me. Um, you can blame me for that one. Um, originally my my career in uh in uh development was in UIUX and front end

and uh I actually bring a lot of those skills from my UIUX background um into my security career. So I I did do full stack. My preference was UIUX and I I really believe I'm a really strong believer in the common sense approach and usable security controls. um you know implementing security in an organization in a way that does not create friction for end users and the people that are trying to use it on a daily basis. And so I've brought it you know taken it upon myself to try and uh hopefully change your perception about compliance and how that doesn't necessarily have to be something uh that's that's difficult or causes friction for you as practitioners in

industry. Uh my current role I'm a PCI QSA. Um, so a lot of my uh a lot of my role now is consulting to help clients develop a PCI compliance program. So if you're not familiar, a PCI QSA is payment card industry qualified security assessor. So it's credit card security compliance and uh yeah, I help organizations, you know, achieve compliance with PCI. I also assess organizations. So I do things like SAQ validations like self- assessment, questionnaire validations, uh report on compliance assessments as well, you know, from organizations that are small mom and pop shops or local startups right up to household brands like Telos and couriers and municipalities and governments. Um and yeah, you know,

before uh before I was in consulting at MMP with Bon Security, you know, we built a tool that did security awareness. So when I'm not doing, you know, PCI, ISO 27,0001 readiness, risk management, risk assessment, stuff like that. I actually lead our national security awareness practice at MMP as well. Um, and so I help organizations build out security awareness programs and and implement tooling and kind of best practices around that. And uh at Bose Run Security prior to joining MNP that was a big part of my role as well. So you know, real real focus on people and implementation of controls and you know, helping uh improve security posture with uh with awareness. Um just

a little bit about MNP. So um we're founded in 1958. Uh we're a fully born and bred Canadian firm. Got about 8,8200 uh employees. Our core business originally was an accounting. So um Meyers, Norris, and Penny is actually what it stands for. And uh we have a digital subsidiary which is MP Digital. It's about 500 employees that does sort of endtoend IT consulting. So we're all over the country. We do all kinds of stuff. Um you know, a little bit of everything in IT consulting. and uh I belong to the bottom right corner there which is the cyber security and privacy uh team and all the stuff we do related to that. So um what we're going to talk about

today is a little bit about like what information security compliance actually is. I mean we all know it's checklists and controls that um we are assessed against or audited on. Um we're going to talk a little bit about some examples. I'm going to talk about PCIDSS and ISO 2701 and I promise it will be engaging. It won't be boring. Uh we're going to talk about how you can leverage these sorts of standards and frameworks uh these compliance standards to improve your security program. Uh practical ways, tangible examples of how you can take something like PCIDSS or ISO 27,0001 even if it's not something that you're subject to or you're assessed on, you can use it to improve the posture of

your program and make your organization more secure. Uh and then we've got some practical examples and takeaways. So I did take some excerpts directly from those standards. you know, maybe there's people in here that haven't had the opportunity to look at those or you're not like me and nerd out on reading those kinds of standards in your spare time. Um, so I'll be able to kind of show you what that looks like, give you the QSA's perspective on um, you know, what kind of PCI controls or requirements can do for you and then give you the uh, the ISO perspective as well. So, just before I start here, um, raise of hands, how many people are

involved or are running a compliance program for some kind of assessment in your organization? Okay. A few. Okay. Leave your hands up for a second. Put your hand down if you do not enjoy it. Yeah. Okay. It's all right. You can be honest. It's okay. Yeah. I think that's really the common uh common experience that I have as an assessor as a as a QSA, right? Um the room falls silent when the QSA enters during an audit. I often feel like I should be wearing a cloak and carrying a big scythe or something like that. Um but yeah so compliance often has this sort of negative connotation this audit sort of mindset where somebody external

is going to come into our organization we have to do all this work and prep and buildup to lead to this point this sort of pinnacle this crux where we're under a microscope for a certain amount of time you know when we're just trying to do our our day-to-day jobs so at sort of like the ground level here I want to talk about what information security compliance actually is what's the objective So information security compliance is sort of made up of six key elements. Uh the first one is to protect data right we're trying to protect data in our organizations and the purpose of these standards you know whether it's credit card information with PCI or it's our

information security program and management with ISO or any other number of standards and frameworks that you're subject to compliance on. Um the ultimate goal is to protect the information and the assets of your organization. The second one is to mitigate risks. So similar to the talk earlier today about risk management, ultimately the purpose of implementation and controls and being assessed on those on a regular basis is to cut down on the chances of somebody actually compromising those assets of our organization. meeting regulatory requirements of course. So you know Visa and Mastercard and MX and JCB and Discover they decide that if you're going to transact card holder data on their as part of their brand um you know they want to make sure

that you're protecting that data. Um so you know meeting the requirements set out by those organizations whether it's you know legal uh requirements or legislation around privacy or any other regulatory requirement if you're in critical infrastructure for example with NERK or others um meeting those requirements you know in order to operate your business is part of that of course maintaining trust I think this is a really really important one that we kind of lose sight of a lot of the time um in organizations particularly as practitioners or technologists in our organizations you know our goal tends to be focused on a very small part or very specific part of the operation of that business. And so what we have to try to

remember is that key role that we play however small or whatever component of the operation that that is ultimately is to serve some kind of larger bigger picture right so whether it's supporting um health care with a healthcare application or infrastructure of some kind or it's supporting someone that wants to ride share with Uber or you know whatever that looks like ultimately the business objective we're trying to maintain maintain trust with the regulators that are ensuring that are, you know, delivering those services or achieving those business objectives securely. Then also with our clients and our consumers and the people that we're we're working with. You know, how many of you have heard of a organization that

experiences a credit card breach and you say, "I'm never going back there again." Right? This is the sort of stuff that we want to try and uh and avoid. Improving security posture. So although compliance can often feel like a burden, it's something that we have to force ourselves to do. we have to provide all this evidence and go through this process every year or every every interval. Um ultimately the goal of those standards is to improve the security posture of your organization and make your organization uh more secure. And then finally facilitate business operations. Again a really important one. Uh I'm a big believer that compliance standards and frameworks can actually be a bridge with the

business which is often a void that gets very hard for us to build a bit bridge across between security and business objectives you know to help the business understand why it is what we do. Why do you pay our salaries? Right? It's so that we can help facilitate business operations. So things like compliance programs like PCI for example or ISO 27,0001 um sort of give us some meat on the bone to say we do these things to ensure that we can operate our business in a way that's secure and safe and protects our assets. Um so some challenges and some perceptions. I've been kind of talking about this all the way through my intro here, but um you know oftent times we

get this perception that oh no uh brace yourselves compliance is coming right our PCI audits coming up our ISO audits coming up we got to get ready we got to collect our evidence we got to ensure that everything is in good shape um and what this means is you know some of the challenges around these programs is that controls are often not maintained or baked into the security program. It's something we do leading up to the audit. it's something we stop doing once the audit is complete. Um, in some cases, you know, we only do it for the sake of that audit. We don't actually look at how could this possibly improve our program or what are some of the benefits

or the objective of that control that's in the compliance framework. Uh, the objective like I just mentioned of the control is not really considered. So, what we're going to do today actually when I get into some of the specifics will be, you know, why does PCI ask you to have a 12 character password as an example? um or why does ISO say that there has to be leadership engagement? Just talking about some of the actual objectives and outcomes from those controls, compliance really becomes a checklist activity. Um I can't tell you how many times I get into an interview with a system I'm in and I'm like, "Hey, what's the OS on that device?" And

they'll like literally just say OS number, patch version, patch revision, etc. Is this patch within 30 days? Yes. And it's a very trained and limited response. And all they're trying to do is make sure that for the sake of that audit or that assessment, they're just achieving those check marks so that this can be over and I can go back to my cave and not have to talk to an auditor ever again. And then finally, maintaining compliance is resource intensive. So um I'm not sure what your experience has been but in any of the cases where I've been consulting so more on the internal security assessor ISA side of the PCI stuff when I'm supporting an

organization preparing for an audit you know they're pulling in everybody from all these different teams and you know operational stuff sort of gets put to the wayside to focus on the audit or the assessment. And so that's kind of the perception is that now we have to buckle down and focus on getting this stuff done right now so that we're ready for the audit when it comes around the corner. Just like nods or shakes of your head. Does this resonate? Does this sound about right for anybody that's gone through this pro pro this process before? Yeah. Lots of nods, no shakes. Okay, cool. Great. Okay. Um, so I love this picture on the left because a lot

of my QSA experiences or my experiences as a QSA have been something like this, right? um we look at the version, you know, we when I do my my PCI audits, we're very thorough. So, we'll do a screen share, we'll get onto a VM or an EC2 instance or a, you know, a VM in the cloud and we'll say, you know, let's pull up the version of the OS on this device and let's pull up the patch history and it was patched the day before I got there, right? Um, so these are the kinds of things that we run into. And of course, for anybody here that's not subject to any kind of compliance, you know, the one on the on

the right there is probably a bit more relevant, right? Um, we can't be non-compliant if we've never been assessed, right? That's kind of the kind of the idea. Yeah. In terms of benefits of compliance programs, there's actually a ton of stuff uh that can help you out. So, compliance is often all-encompassing. Um, we're gonna Oh, it's a GIF. It's going to loop, isn't it? Oh, man. Okay. Hopefully that's not too distracting for you. Um, compliance can often be all-encompassing. So, just show of hands. Has anybody here ever actually looked at the PCI data security standard before? A few. Yeah. Okay. So, we just had PCI version 4 that dropped in April on April 1 of this year. Uh it's

something to the tune of about 400 different requirements and it covers 12 functional areas around networking uh operating systems, password access management, identity and access management, logging, NTP protocol, like you name it, there is stuff in there that can help uh help with that. So sometimes in some cases, you know, these compliance frameworks can really touch on all the different things in your environment, maybe even things that you've overlooked. um when maintained proactively, organizations that are more compliance forward demonstrate a higher level of security maturity and that's actually my experience speaking. So organizations that adopt PCI in our PCI audits as sort of the the minimum viable standard for their security practices when we go in

there, they're not pulling people from teams to try and get this stuff together ahead of my visit. They just do it. It's just part of their culture. It's part of their their existence as a security team. And so what ends up happening is we go in and they're like, "Yep, here's John. John, tell tell us what you do." He's like, "Apache systems. We do it every 30 days. Here's the log." And that's it. It's like a 10-minute interview. And we're in and out and it's very simple. So, you know, that compliance forward mentality is very important. Um, compliance often has defined security objective. So whether it's security governance or protecting card holder data. So ISO actually is a

really good example where the purpose of ISO 27,01 is to create a scenario where your organization is required to have a consistent cyclical process for reviewing information security in the organization. So rather than a here's all our policies, we produce them and we'll go back and look at them again later. Um it becomes this cyclical event that's sort of always evolving, evolves with the needs of the business, involves leadership, um has a review process, has a process for identifying nonconformities and addressing them, all these things. And so uh the objectives of that are ultimately to make your organization more secure and more diligent in the way that you handle information security governance. And then finally, compliance standards are

measurable. Uh, one of my favorite things about PCI is there's no subjectivity really. It's either you're compliant to this very prescriptive requirement or you're not. It's a zero or a one. Um, so it makes it a lot easier to to measure that to say here's, you know, the things we do right and here's the things we do wrong. Okay. Hopefully you guys aren't dizzy from that looping gif there because I didn't realize I say GIF. Sorry. I know some a lot of you guys probably say GIF but um so ultimately how can compliance uh improve your program or strengthen your program? So you can adopt a compliance framework as a security baseline. As a matter of fact, I

encourage you to layer compliance frameworks to build your security baseline. So a lot of the controls that you'll have in place will overlap across these different frameworks and these standards. Um and you can sort of pick and choose and you know pick your flavor, right? what things are we lacking in, what areas of our program are we less mature in or that we think we're less mature in. Uh, and we can say, hey, if it's good enough for credit card data, it's probably good enough for our stuff. Or [snorts] if it's good enough for to develop an information security management system under ISO, you know, maybe that's how we should be approaching our governance. So, these

are the sorts of things that you can pick and choose. Uh, you can utilize the controls and requirements to strengthen areas uh in your program that lack maturity. I just mentioned that. So you know maybe you are looking for a better way to do pen testing. Now we do pen testing like once every 3 years. Is that enough? We can have a look at PCI. We can have a look at you know various other compliance standards that are prescriptive about that to give you guidance and sort of be a north star for you. And then you can use defined requirements to measure the maturity of your programming controls if you have a compliance program as sort of like your

reference. Um so the idea is um and I'm going to show you this like PCI I'm a QSA so a lot of my references are going to be PCI sorry um in PCI for example new this year with the version 4 was the customized approach objective so you know there's the prescribed approach which is Valve shall do XY Z uh and then the customized approach objective allows the organization to say well based on how we operate or based on the architecture of our environment that doesn't really work for us so what are we really trying to do with this requirement. And I'm going to give you some examples of that in a little bit here.

So PCIDSS and ISO 27,0001. I asked about PCI. Has anybody here ever looked at ISO 27,01 or? Yeah. Okay. A few people. All right. A lot less than what I expected to be honest, but okay. Um, so what is PCIDSS? Uh, it's the data security standard set out by the payment card industry. So for those of you who don't know, I rhymed them off earlier. Visa, Mastercard, MX, Discover, JCB got together, formed a council, created a data security standard that says if you're going to use our cards to process transactions, here are the things you need to do uh to be secure. And so it's an annual assessment typically um depending on the number of transactions

you do. You can do a self assessment and have it validated by a QSA like me. Uh and then once you surpass a certain number of transactions, depending on the nature of your environment, you do a full report on compliance where someone like me comes in and goes through uh all of your stuff. Uh and essentially it's for organizations that process, store, transmit credit card data. I tell my clients there's three things in life that are guaranteed death, taxes, and PCI compliance. If you interact with card holder data, you are subject to uh PCI compliance. And for those of you in here that might be doing that are going, "Yeah, we've never done anything like

that." have a look at your contract with your acquiring bank because they indicate that you are required to do that um maintain that PCI compliance. Um yeah, so that's kind of in a nutshell that's kind of PCIDSS. It's set out over 12 sort of functional areas here um that are grouped together. So building and maintaining networks uh secure networks and systems, protecting account data, maintaining vulnerability management programs, implementing strong access control measures, regularly monitoring and testing, and then also maintaining an information security policy. This kind of sounds like everything you'd want to have in your security program. No. Yeah. Yeah. Um so there's specific uh requirement areas within each of these categories that are much

more specific. I'm not going to get into all of them right now because like I said, there's 400 and some odd of them. we'd be here all day. Um, but yeah, this sort of gives you an idea of of what's included in there. Uh, like I mentioned, there's compliance levels, too. So, what's great about some of these compliance uh, frameworks and standards is when you start to dig into them, they actually have different flavors. So, for example, PCIDSS talks about all these different things that you can do. If you're a retail environment that has pin pads, what we call POI devices, point of interaction devices, you know, where you put in your card to pay, obviously you

don't have servers that are hosting payment applications. And so, as a QSA, we're not going to look at, you know, the operating system version or the patch history or how you're doing vulnerability management because that doesn't apply to those smaller devices as an example. So, I encourage you, you know, it's not like ah compliance hs, right? have a look at these standards and see maybe if there's flavors of these standards that align more to the nature of your business and the things that you're doing or maybe the areas of your program that you're trying to improve. Um the strengths of PCI DSS include it's very technically focused. So if you're a practitioner, if you're assistant, a

network admin, a security practitioner that's very operational. Um a lot of the requirements are very prescriptive and specific to you know what you're trying to achieve technically. Um there it's like I said it's broad. It covers a lot of different areas. I kind of just showed you all the different things. Um the requirement that I I shared here was around audit logging. So as you can see it's very specific um about what it wants you to capture uh in your audit logs, right? User ID, type of event, date and time, success or failure or origination and identity or name of the affected area, system, component, resource or service. Um, so you know, hey, if this is good enough for credit

card data, maybe it's good enough for us, right? Um, the PCIDSS remains current and is updated regularly. Any of those of you that are subject to PCI probably hate that because, uh, when a new standard comes out, it gets challenging to meet some of the requirements. Um, but like I said, if you're using this as a Northstar or a guideline, it means that you're not looking at something that's a million years old, right? Uh, I love looking at some of the NIST SP800 standards um because some of them are like 2012 2015, right? And they they don't actually um they're not actually kept up to kept up to snuff in some cases. Um, but yeah,

PCIDSS always tries to stay a breast of the latest technologies. Um, there's a lot of supporting documentation for PCI uh in open source documentation from the perspective of the community. You know, everybody has the same headaches with the requirements. So, uh, the PCI compliance Reddit thread is a ton of fun to read. I love going in there and reading it in my spare time. And, uh, yeah, the council actually releases a whole bunch of stuff. So, not only do they give you this 600page document with the data security standard, they also release FAQs, information supplements, all this kind of stuff. So the way I look at it is from an perspective of an organization that doesn't handle card

holder data but wants to have a more secure organization and a better security program. Here's a guide on what looks good for credit cards and here's a bunch of supporting information on how to get there. Um you know being able to cherrypick and pick and choose from that what makes sense is a great way to kind of navigate um navigate some of those challenges around you know technical controls and improving that security. Okay, ISO 27,0001. So it's a security standard with a set of requirements that helps you establish, implement, maintain and continually improve uh improve excuse me an information security management system for your organization. So the idea behind ISO 27,01 is less control focused and more governance

focused. Now there is an accompanying standard which is 27,02 which is much more control focused. You know you could pick from that one if you want to. I chose PCI for the sake of my um presentation here. um and it's very well recognized. Um it's very rigorous. So I improved I I included the u table of contents here that kind of talks about all the things leadership planning support operation performance evaluation improvement. So again all of these different areas from a governance perspective that help you build and maintain an information security program in your organization that is kept healthy and continually improved. Some of the strengths uh for ISO 27,0001 is it's strategically focused as I

mentioned. So for any of you that are managing an information security program or any of you that are trying to or tasked with sort of building out this governance, how do we maintain our information security program once it's in place? This is a really good way to do that. It emphasizes rigor, diligence, governance, uh repetition, cyclical events in terms of the analysis and assessment of that uh information security management system. Um it requires a lot of strong leadership commitment and buyin when it's implemented effectively. So, you know, this is a great way to bridge the gap as I mentioned with leaders and the business about information security and how it's a business driver and not a

business inhibitor. And then finally, oh yeah, sorry that's the last point. I kind of jumped ahead of myself there. Yeah. Um couple of examples here of this. So I included the improvement section on the lefth hand side. So in continual improvement. Um so it talks about um the organization continually improving the suitability, adequacy and effectiveness of the information security management system. And then also how to deal with non-conformities like what are things we can do to find and remediate nonconformities in our information security management system. And so if you're in the kind of environment where you've built a security program, you have a million tools like all of us have and you're just essentially putting out fires as

they come up, this might be a really great way for you to set a baseline and you know have a mechanism to remediate those risks and and deal with them. And then on the right hand side, speaking of risks, I included the information security risk assessment section which talks about establishing a risk acceptance criteria. you know, developing a risk appetite, um, identifying information security risks and and dealing with them. So, the level of risk, how do we qualify or quantify these risks and then how do we track them and and continue to improve on them? Okay, so that's enough standard stuff and screenshots from uh those standards for now. So, how do you leverage like

this is all great, Ian, you've talked about PCI, you're a PCI nerd, we get it. You've talked about ISO, you like security governance, we get it. What does this actually mean for me? How do I what do I take away from this? and what do I apply this? How do I apply this to my program? So, if I can give you one thing today to take away from this uh that I think is really important is the concept of scope. Just put your hands up if you have an idea of what I mean when I say scope. Yeah. Okay. Good. All right. Good. Good. Okay. So, scope is defined by the boundary of what's being assessed or

audited. And so what we get into in the case of PCI when we're talking about scope is an organization has deployed assets, you know, in the way that they deploy everything. Yeah. Yeah. Our server that hosts the web page for processing payments is right there in the same subnet as our, you know, our app that we have or it's in the same uh VLAN as our DC. I don't know. I'm just kind of throwing stuff out there. But the idea is you know not really thinking about um the segmentation controls or the division of those assets um you know technically what's important is that this also applies at the business process or business function level too.

So what I mean by that is you know in this case in the diagram I kind of drew a little green square around two servers and said yeah there's your scope but also considering what are the business processes that we want to include in the scope of this as well and that's more relevant to ISO 2701. So the handling of customer data, you know, maybe we have an application where we have customer information, but maybe we also have a ticketing system over here where we're interacting with customers and we want to make sure that we're maintaining the confidentiality, integrity and availability of that as well. So sort of defining that scope depending on you know if you're looking

at the technical level, the technical control or the governance level is like really the most important first part. The example I can give you with PCI would be, you know, how do we reduce that down so that the stuff we have to protect for PCI is only the stuff that pertains to our credit card information, right? If we have this app deployed on the same network as our internal corporate network and now all of our workstations are essentially adjacent to our payment card application. um you know that's a bad thing that that could give us a lot of uh a lot of uh vectors for for compromise laterally right and so how do we reduce that down so that

this little piece of paradise that is our our card holder data environment is separate from everything else and that's the only view and so applying this in the concept of your security program and applying compliance to improve that would be okay what things can we separate out that are the crown jewels and we can assess or internally assess just that piece and make sure that that piece is the most important and the priority number one and what I put here and this is a bit of a challenging question can we keep everything secure all the time and that's kind of the goal for sure but at what point do you start eating an elephant bit by bit one bite

at a time right and so if we apply this concept of scope and we say okay here's the crown jewels here's the stuff that we want to focus on first uh and we shrink that down and we create an environment where you know this is the stuff that we're going to assess internally and then we gradually add stuff to that scope. Um what you'll find is over time you've developed an environment that's much more secure setting baselines. Um so taking elements from compliance frameworks that fit your organizational needs. So this is an example. Um this is one of my favorites because I always get funny looks when I talk about this one. This is the PCI

requirement for NTP um for time synchronization. One or more designated time servers uh only only the designated central time servers receives time from external sources. uh received from external sources based on international atomic time or coordinated universal time. So, you know, all very very prescriptive stuff. But maybe you're like, well, we don't even do any time synchronization. We don't we've never even looked at time synchronization in our environment. Well, PCI, I talked about the customized approach is really great that way because they say just as long as the time on all systems is accurate and consistent. That's ultimately the goal of that requirement, right? And so now you have a baseline. You can say, "Yeah, we've never looked

at time, but maybe at a minimum, we'll do that. We'll just make sure that everything is consistent from a time perspective." Align your program to the framework in these areas. Like I said, whether it's pentesting, whether it's audit, whether it's governance, uh, excuse me, audit logging, whether it's governance, uh, whether it's patching, whether it's identity access management, you know, all of these things um can all come together to create your security program. And so the areas that you're lacking, you know, cherrypick that, grab your favorite uh compliance framework and pull that out as a as an northstar and then what can we do that will be better than where we are now ultimately. That's sort of the that's sort of the

theme. What are the things that we can take away from this to improve our program? It's also useful in identifying gaps. So hey, we've never really we've done risk assessments that give us an idea of where our risk lies and our, you know, maturity in certain areas. Um, but looking at these frameworks as sort of a template to say, yeah, like I mentioned, if it's good enough for credit card data, maybe it's good enough for us. And so mapping your security program to that compliance framework, seeing where the gaps are. Hey, we never really thought about this sort of control. Um, you know, maybe we should start to look into that would be a really good way for you

to get an idea of, you know, where your strengths are and where there may be gaps. Um, and uh, yeah, I already mentioned this, but you know, are there things that you've completely overlooked or areas that you're less mature or areas where um, you could uh, you could use some improvement. Okay. And the last piece, the last part here, just concept of the time. Um, we're going to have a look at a couple of the specifics. So, I did I lied earlier when I said I didn't have any more screenshots. I do have screenshots from the PCIDSS and from ISO here. Um, you know, this is a really basic one that we run into as a problem most of

the time in our PCI assessments. An accurate network diagram is maintained that shows all connections between the card holder data environment and other networks including wireless networks seems like a very small thing. Network diagram um but having that as sort of a baseline um to say yeah we need to make sure that we have a network diagram that's maintained um is a good idea. And what's great about the PCIDSS is on the right hand side there's actually some guidance, some good practices. What's the purpose of this requirement? What's the good practice look like? So all locations, clear labeling, uh all security controls providing segmentation, all in scope systems, all of these things included on that

diagram. And so if someone tasks you with, yeah, we need you to create a network diagram, and you're kind of making it up just based on what you know best, uh, this is a really great way to kind of start you and give you that foundation. Uh, this is the another one I wanted to share. 1283, an established process is implemented for engaging thirdparty service providers, including proper due diligence prior to engagement. So um anybody here have a TPRM program a third-party risk management program in their organization? Yeah, not very many. So this would be a great way for you to start, right? Like what's at the very viable minimum that we should do to

ensure that we're engaging third parties effectively and securely. There's even information on the purpose and the good practice, right? Uh and the customized approach objective again which is sort of the broader objective of this the capability intent and resources of a prospective thirdparty service provider to adequately protect insert your data here assessed before the third party service provider is engaged. Great. This is one uh from the uh uh ISO 2701 standard. So information security objectives and planning to achieve them. Uh and so this just talks about um the information security objectives of the program overall are consistent, are measurable, they take into account applicable information security requirements, they're monitored, communicated, updated, and available as documented information. So again, when

we talk about what does the governance of a program include and what does good look like, ISO defines it in this way. And so you can go to the ISO standard and pull this out and say, "Yeah, here's how we want to try and structure the governance of our information security program." And uh there's lots of takeaways from that that you can uh you can pull out of there. I'm starting to see some nods, so I'm going to speed up a little bit. Um leadership and commitment. I I I always go back to this. I always go back to this because I know what it's like to try and bridge that gap. You know, I talk to execs all

the time about, so what's the fine if we're not PCI compliant? Is it cheaper than paying to be PCI compliant? Um, and helping them understand like why you have to keep card holder data secure. Um, this is an example from ISO that talks about top management's involvement. So, demonst demonstrating leadership and commitment with respect to the information security management system by and you know here's items A through H that sort of say what the role is of uh of leadership of top management. And so as an information security leader or um you know someone that interfaces with the business, you can go here's A through H that I would like you to do to help us be more

secure. And again use that as an northstar as a guiding principle to help you uh be more secure. All right. Uh pretty close to time. Um any Oh no. Any questions? There we go. Questions? Yep.

Hold on. Wait for the microphone for PCI standards and compliance. Yep. Who actually gives you the fine? Yeah, great question. So for PCI who gives you the fine. So it's the card brands. The card brands will determine the fine and actually it's the card brands that do the investigation. So if you have an incident um involving card holder data, you know, it's Visa or Mastercard that comes and uh and wants to do that and then they impose stricter um stricter assessment requirements on you if you do experience an incident involving card holder data. Yeah. Yep. Good question. PCI specific questions are good, too. I'm QSA. I know I know we're like, you know, the sickly, but this is an

opportunity for you to ask me if you have a PCI question. That's no problem. Um so I have two questions. Uh the first part is uh as a startup or uh high velocity um like uh product company. Uh so a lot of times the these standards get overlooked and what is sort of like a baseline that uh I am a devops engineer so I can convince my leadership that hey this is the things that you absolutely need to do. So if we want to uh get um like certified in future and uh the second part is if we uh use uh a third party um uh card uh like a payment integrator like for example stripe.

So we are not u um storing the card holders data at all. So what are the like u from PCI perspective what are the things that we need to do? Great. Okay good question. So I would say in the first part as far as being a startup and the cart and horse effect of when do we achieve a compliance standard versus focusing on our development and things like I've been there you know I built Beron I was literally quit my full-time job and I was employed number two to do that and um that is a challenge what I would say you know maybe without a hard and fast rule what I would say is at some point that

critical customer that can make or break your business will come to you and want to buy your product and they're going to ask you for that. Um whether it's a CAIQ or you know something else from the CA CSA star or uh CCM for example or whether it's a PCI compliance or something along those lines, you're going to have to do that. So um do it at some point. Um all the variables involved with startup landia, you know, there's not really a hard and fast rule, but uh you ha you do have to do it. Yeah, it's it will it's pay me now or pay me later. You either do it in the beginning or you do it when

that big customer comes along. And then the second question, I outsource my payment. What's my responsibility from PCI perspective? Um PCI compliance and credit card data are mutually exclusive. You can't have one without the other. So even if you're using a thirdparty service provider like Stripe, um like Moner's Checkout, uh or any one of these other payment gateways, you you're still you're still subject to PCI compliance. Your scope is the web server that serves up the page with the iframe. You know, that web server is your scope. And then you would want to make sure that that has adequate segmentation controls to keep it away from everything else. Additionally, in requirement 12, the governance aspects of PCI. So, we have a

list of thirdparty service providers. We get their AOCC's every year. Uh we have an information security policy. You know, these sorts of things. um the merchant, the person that's uh you know capturing, excuse me, receiving the money for the card transaction is still subject to some of those PCI requirements. And depending on the number of transactions, that's typically an SAQ type A if you wanted to reference that to see what those requirements were. Great. Any other questions about compliance or PCI or ISO? Okay.