PCI DSS Masterclass - From Foundations to Mastery

1. Introduction: Hello, hi everyone. My name is femoris and I'm the creator of this course, welcome discourse which is called PCI DSS foundations to mastery. Now the PCI DSS, it's one of the hottest topics around and it has been for the past, I think 15 years or so. And it will remain to be hot honestly, as long as payment transactions keep happening. So if you're interested in learning about the PCI DSS standard from scratch, this course is definitely for you if you're already an expert, I mean, you have a few as experience in implementing PCI DSS, then it is still for this course, I would still recommend it as it will be a great recap for you to just go over some of the core concepts and get some practical advice. And also, I will be covering the new updates to the standard which is in PCI DSS version 4. And honestly, no matter how much technology progresses, cardholder data is still one of the most important types of data around and it will always need to be protected. So whether you're a small startup, whether you're a Fortune 500, honestly, the standard is usually applicable to you. This course. I have specifically designed it to help people gain mastery over the PCI DSS standard from scratch, okay? You don't need to be an expert in credit card transactions or the payment industry or even an IT expert. Okay. It's based on my own like a nine or ten years experience and implementing PCI DSS. I've implemented it in multiple standards across multiple geographies. I know the standard inside out the course. It will make you understand and master the PCI, DSS standard. And it gives you all the knowledge that you need to implement it in any environment honestly. And I try to make sure to give you practical advice. I don't want to bore you and make it like a death by PowerPoint. But I'm just reading a slide and you're just like, I'm going to try and give you a, make this as practical as possible. What are the key things you need to know? What are the some of the mistakes which people make so awesome, Let's get started. Just a brief background about me guys don't know who is teaching you this course. My name is Dan Voltage Law. Okay. I've been in various leadership positions for the past 20 years, mostly in the Middle East. Okay. So I will total around 20 years and technology risk. I was responsible for overseeing PCI DSS implementation in their own three or four locations for over nine years. So I have a very diverse experience and PCI, DSS. Okay. So currently I'm based out of London. I'm an author. I have, I'm also like to blog and I'm also a teacher and instructor, which you can see here. I'm also cybersecurity career coach. I usually try to help people if they want to succeed. And really what he called, Go ahead in there and will improve upon their cybersecurity careers. I have a YouTube channel called the Cloud is cloud security guy, which you can take a look at. And I usually talk about stuff pertaining to cloud security, artificial intelligence, and gender cybersecurity advice. So apart from cybersecurity, my journey has been ups and downs. I won multiple awards in the industry, and I've established myself in the Middle East for many years. I've written a book also about artificial intelligence governance in cybersecurity. And I have two more books plan this year. I felt this was a topic that has not getting enough coverage. So I thought I'll do my bit to create as much awareness as possible for my buck to the industry. I was awarded like a UK global talent visa. And I also help people who are applying for UK technician endorsement. I tried to help them out in their applications as much as I can. So this is just a recap on who I am. What I do is to understand who's teaching in this course. While and PCI, DSS guys. So what's the reason? Why should you, if you're attending this course, obviously, you must have a reason. It might be part of your job. Or maybe your company has decided to implement it as a regulatory requirements when you don't have a choice, All you might get fined if you don't implement it all. Or maybe a company is just saying it's a good standard to implement, it's good practice. So let's go ahead and implemented one of the, some of the reasons, okay. My pod guys, VR, what he called the Moving to a cashless society, right? The card-based transactions are becoming more and more common. It might be point-of-sale terminals, CashRegister, smartphones, everything is being powered by cashless transactions. And protecting those transactions is very important guys. If you want to feel, if you feel that, if the customers feel they cannot protect their data, then they will transact with you, which will destroy your business. I mean, if you're a merchant or service provider, right? And people don't want to have transactions with you, this has become a big problem. So this is where PCI DSS comes in and it enforces like a common standard across the world for the protection of cardholder data. This standard, it will remain applicable as long as what do you call people doing transactions, Okay? And it will be very important for the foreseeable future. It's a great thing to have on your CV is a great experience to have. Also, depending on the industry, might not have a choice. You have to be compliant if you are storing, transmitting, or like processing cardholder data, which we'll see. But they are, like I said, they are always good reasons for knowing how to implement a PCI DSS standard, which is one of the reasons I made this course. So what will this course cover? And I hope you understand now why you should note PCI, DSS, okay? What about this course? Or what is it going to teach you? It is going to teach you, first of all, PCI DSS from scratch. I'm not going to read the standard from page one until the end. Okay. Nobody wants that. I honestly, if you want me to read bullet by bullet, this is not the course for you. I'm going to make you understand the intent of the, all the requirements. What are the practical steps in doing that? You do not need to memorize the standard. Lot of people started making that mistake. Okay. What I'm going to do is I'm going to explain how the standard works and what are the best ways to go about implementing. I am going to deep dive into this 12 requirements, the standards, and we will go over each in detail. Okay? I'm gonna give you practical advice, okay? Actually advice based on real-world implementations which I've done. And lastly, the standard is being revised, okay? The latest updates for PCI, DSS for points, what are the key changes you should be aware of? What are the things you should be ready for, whatever you think you should start doing now. Because the two thousand and twenty four twenty five is very close. It looks far away but is going to come. And you might need to do certain things, so I want to make sure that you are ready for this. Okay. Who is this course for? Whether you're a new employee with limited present knowledge or maybe experienced system administrator. This course is going to help you, your organization to become compliant with PCI, DSS or comments. I've made this, I've designed this course like a reference guide, address the most challenging aspects of PCI, DSS compliance. So depending on your background, job role, the organization leaves some sections may be more relevant than others, okay. So you can be an IT auditor who's going to audit their environment against PCI DSS. You can be like, I don't know, a QSEN ISAF, people who are preparing for the exams for PCI, DSS, you might be preparing for this. And this example gives you some great inputs on that. There's some good test questions, practical advices, they are okay. You might be a risk professional. And who wants to understand the standard, how it, what are the risks? What are the things which we have to implement, okay? Or you might be a business professional. Your business might be underscore for PCI, DSS, and you want to understand how to implement it. So these are all the things which were the people who or whom the standard might be applicable to. As a class project guides information which you don't apply, you're going to forget it. Okay? That has been my experience throughout my life. If you don't implement what you're learning, you're going to forget it. So by the end of this course, I want you to fill out in a city or we're gonna go into detail about SAQ is for a physical or an e-commerce merchant. So just think about a hypothetical merchant. They are accepting card-based transactions. Are they doing e-commerce? And I want you to fill out and SEQ for that doesn't really help you to lock it down and really make you understand how to the PCI DSS standard works. So I hope I made you excited for this course and what are the things I'm going to be teaching you? And how are you going to be learning about the PCI DSS. Let's get started, guys. Thank you so much for taking this course. And I will see you in the next section. 2. Overview of PCI DSS: Okay guys, Welcome, Welcome to the first module of this course, which is PCI, DSS, and overview of the standard. But first of all, I want to teach you what PCI DSS is likely or don't want to jump into implementing the PCI DSS standards and requirements, right? You don't understand what we hear ideas, this is how it works. What's the point of this standard, right? We've already have so many standards. By one more. Let's learn about PCI DSS. From the ground-up, I would recommend taking this model even if you have experience of implementing PCI DSS before, because you'll get a good overview and a history of the standard. And I'm going to teach you how the standard is structured and some of the common mistakes I've seen people make in around like ten years of implementing PCI DSS, okay? Okay. First of all, the PCI DSS standard, okay. It was established in 2006 or eight by the major card brands, Visa, MasterCard, American Express, Discovery, JCB, all of them. Why did they do it? Simply put, historically, what used to happen with all of these color schemes? They had their own standards, they had their own programs, so compliance. So let's say you are a merchant, right? We want to employ you want to accept Visa cards, okay? Visa had their own standard you have to comply with before you could do it, then Mastercard it there only if you want to accept MasterCard. And simply with Amazon, again with American Express, I'm making a gesture be. So you can understand, this became a big issue for merchants and service providers. The amount of time and money implemented different standards. Okay? So what happened was all of the standards that came together and they're going to establish a common standard. And this standard is going to be applicable for people who are involved in the payment industry. It eliminated the need for complying with each one separately promise, okay? So this is how, if you are like storing, processing, transmitting this data, you are required to implement the standard to protect it. Based on thousands and thousands of investigations of merchants who had been breached. What was confirmed, what that if they had implemented distended properly. Okay. What do you call they have implemented centered properly. It would greatly reduce the risk of them getting attacked or like compromised. Ok, so the standard is very useful. Does it make you a 100% secure? No, absolutely not. But it is a very good starting step. Okay? So who is it applicable to? Basically remember this storing, processing or transmitting any business that stores, processes or transmits payment card data, you are required to implement the standard to prevent cardholder data, okay? You can be a merchant, it can be a service provider, you can be a bank, you can be a call center. We can be a technology company. Doesn't matter if you're doing these three things. Either of the three things we will come into scope. How much you have to implement, that is where the difference happens. But rest assured you will come into the scope. Okay. So why? You might ask why, okay. I'm already secure. I have implemented controls and all that, etc. Why do I need to do the standard? Okay. What's the need for the standard? Simply put, like based on the old thing that criminals go where the money is okay? The same. In a digital age, merchants have become much in service providers, there becomes a new target for fraudulent activity. Okay? So you might, it might be your cash register, it might be your primary point of sale. It might be a shopping cart, it might be a Wi-Fi network. It might be the PCs or the workstations that you have. Okay? It's become a serious problem because attackers know that even one of these things I can compromise. I might get access to this data. I might be able to commit fraud with this. That's why it's so critical to understand these vulnerabilities. They can happen anywhere in the card processing ecosystem. Like I said, it might happen in mobile devices, point-of-sales, wireless hotspots where shopping applications, it might be transmitted and it might go, it might not be in dry Miami, it might be in a service provider. It might be in your Cloud environment. Okay, So that's why the PCI DSS comes in and really helps you to secure this environment, really makes you understand what I have to do. What don't I have to do? One other due diligence activities I have to implement. Okay? So definitely there is absolutely 0 when he called disadvantage in implementing this standard. Okay. That's why any technology, any company who was, who is processing and involvement payment transactions, I always recommend to implement a PCI DSS standard. Okay. So the timeline from the standard has come a long, long way, honestly. And why it has been revised so much because it is a living document. It has evolved to keep up with the state of e-commerce and most sophisticated cyber threats. And honestly how technologies evolve in 1015 years ago, the Cloud wasn't that important. Smartphone transactions weren't happening that much they were happening but not that much. Okay. Attacks for different who didn't have like containers in Cloud and Sowell as all of these things have come up, that's why the standard keeps changing. We don't need to like it. You don't need to memorize the history and this is just for your reference. But just know that it has gone through various iterations to keep up-to-date with technologies. In 2022, the version 4 was released. Okay? And just to make you understand, in 2022, it has come up, right. And it has expanded upon MFA, multi-factor authentication or their roles and responsibilities. And a lot of new requirements have come up till March to 2024. By that time, the PCA, the old version, which is 3.20.1, it'll be retired and it will be completely replaced by 4. So you do have a little bit of time. And by March 2025, the new requirements will officially become effective. Some optional comments, okay. These are based on projections by the PCA Security Standards Council, the body who maintains the standard. They may be subject to change, but the timeline. So that's why I keep recommending that guys. If you are in scope for PCI, then start looking at the 4 requirements today. Don't put it off. Okay, so this was a basic overview of the standard. In the next module, I'm going to go over the vesicular architecture, how the standard is structured, how it works, and how it's structured. So thank you guys, and I will see you in the next module. 3. Standard structure : Okay guys, so welcome to this module which is about the PCI DSS structure, how the standard works. So simply put, it's very simple. It has six schools and 12 requirements. People usually to focus more on the 12 or comments from one to k, we have to implement it to become PCI DSS compliant. You might be in scope for some I notice for fathers. But this is basically how the standard has been structured is pretty simple. It's not that complicated. So the goals, these are common step requirements, honestly, some of these you might look at and say, Hey, okay, all a lot of these things I'm already doing. But that's the whole point. Because what might seem common sense to you might not be common sense to other environments like other merchant service providers, they might say, Okay, I don't need to implement a firewall, I don't need to do this. That's my mandate states. So what are the six basic categories? It is usually about maintaining and building a secure network to firewalls or other devices. You should be protecting cardholder data wherever it is stored. You should have a vulnerability management program to make sure that your systems remain secure. Okay. Any issues come up, you're aware of it? We should have strong access control measures may be physical or logical. You should be regularly monitoring your network, okay? Don't assume your network is secure. Something might have happened. Of course, from the due diligence perspective, you should have a high level of governance through policies to charters, making sure that training is, are there people are aware of their requirements. Okay. So these are the goals. The goals and what are the requirements will go over each of these in detail, guys. But just to give you a high level requirement for maintaining a firewall, you should have standardization. You should be protecting cardholder data is with securing it over the network, protecting it from Albert, updating your systems. These are the first six. The next six, we're restricting access, be it logically or physically, having unique credentials, okay. No sharing of passwords, please. Having physical security, logging and monitoring what's happening doing VN, VN PT, okay. And document and assessing your risks which are happening. So these were the 12 or comments guys. These might seem like too much. Okay, 12 hour who is going to memorize this? So this brings me to my, some of the common mistakes which people make when they're implementing the requirements. And I want to make sure that you don't make the same ticket for me. Then this quite a lot of times some of the common mistakes is they try to memorize the standard. Okay. Please do not need to memorize the standard and the trunk requirements. Nobody does that. You don't have to do this. You can just understand the intent of feature Comment, okay? And then gone by when you can implement it, as long as you understand what they're basically comment is intending, you can have a lot of back-and-forth with the PCI auditor and you can satisfy, look, I am implementing the standard, maybe XYZ is not implemented, but you have done other stuff. We look into this in details. So that brings me to my next point, which is another mistake which people make is not engaging with the QSR earlier. You should, if you have a PCI auditor who's available, engaged with them right from the start. Tell them, I'm not doing this so that they are aware. Perhaps if you're making any mistakes, you can catch it right from the start. Okay. The audit don't treat treat this like you're trying to hide stuff from the auditor engaged with them right away. So I hope you understood how the standard is structured. What are the key goals, are the key requirements and whatever mistakes you should avoid. So in the next module, we're gonna be starting the process, okay? The PCI, DSS also as a process, it's not that you can just go ahead and start implementing the 12 requirements anyway. There's a standard process we have to follow and we'll deep dive into that. If you understand that the PCI DSS process will become, I can promise you it will become easier. So okay guys, let's jump into the next module. Thank you. 4. PCI DSS process ( Foundation ): Hi everyone, Welcome to this module which is about PCI DSS, understanding the process. So one thing I want to mention is a lot of people make the mistake. A lot of companies make the mistake that they've decided to implement PCI DSS, what they do is they jump, they download the standard and they just go ahead and start implementing it, right? They say, Okay, I have to enable multi-factor authentication. I have to harden my server, I have to patch XYZ, etc. That is not the way you want to start PCI DSS. That is setting yourself up. If you want to be PCI DSS compliant, there is a structured process to follow. You can't just start implementing the requirements straight away. It won't work. You will waste a lot of time and be Willis the Lewis, a lot of money also. So let's see what is the best way to go about implementing PCI, DSS, and environment? There are two phases. One is foundational, one is the implementation phase. If you do the hard work in the foundational phase phase, the implementation phase will become much, much easier. The implementation phase, but usually takes longer, but it is much more easier because we have a firm direction. Okay, so what are the steps? The key steps you need to do to successfully implement PCI DSS within your environment. Okay, let's start. In this module, I'm going to go over the foundational ones. First step, most important, and sometimes it gets missed out. Gathering, manage, management support. You need management support for your PCI DSS to be successful. Pci DSS, please note this very carefully. It is not an IT project. It, it deals with people, processes, operational technologies that must be tested and protected. It is not, it is a project, but it is not an IT project. A lot of companies, what they do is they empower the IT teams to go ahead and implement it. You can do it, but what is gonna happen? It's gonna be either fail or it'll be a onetime activity. You'll be compliant for the first year, second year, IT will get busy with other things. Did forget all about it. So you've wasted your time and money. You need to change the culture first, we need a management level sponsor, preferably the CEO or the CEO or somebody might have the syllable. You need that guy to send a clear message across organization. Pci, DSS is a priority and we're going to be implementing it and please nominate XYZ formula units. They will approve the budget because it is going to cost you, you need to implement stuff. Don't assume it's gonna be all free, but really management support ensures that your staff, everybody understands the importance of this. And you will make your life considerably easier later on. For larger organizations, if you want to have a continued PCI, DSS compliance, it needs a very strong culture of collaboration, communication, and commitment from executive leadership. Please do not stick this step. Nominate an executive sponsor who will be approving the budget and who will, to whom you will be sending your project updates. Hey guys, this is the status of the PCI DSS. So make it a project, but don't make an IT project. You can run it from your risk department, whatever department you have. But don't make it an IT project and make sure you have management support, okay? Okay. Second step. What is the second step into foundational phase? It is understanding your responsibilities, but what are you? Are you a merchant, your service provider, IU or bank. Okay. Because you have different processes, technologies, things which are in scope, okay? You will be interested, I'm sure you will know you are in PCI, DSS cope or not. But you need to find out what sort of business are you doing. Is that e-commerce is a point-of-sale, is that outsourcing? So usually I recommend reaching out to your career. It might be a bank, it might be a card scheme like Visa, MasterCard and ask them, I am doing XYZ, what what do I have to do to become PCI DSS compliant? Why do I say this? Because the PCA Council, they said down there, they've set down the PCR Standards Council white, but each payment brand new Visa, MasterCard, they have their own. These are validating it. So you should contact the payment brands or the acquiring bank. Okay. That will give you a clear what he called a tone for what? You have to do. A full audit, you have to fill out a questionnaire, do have to submit a Esri scans, these things you can find out from their websites or you can contact them themselves. I would recommend doing both just to make sure there is no ambiguity. And later on, you're not surprised by some use like a comet which suddenly comes up and you're not aware. Okay. So that is number two. What is the number third party? Third part. So you've contacted the payment bank or the acquirer. Now you find out what is your compliance obligation. Is it a self-assessment questionnaire or as a full audit? Sorry. Cq. The first one, SAQ is like a validation to Lisa questionnaire. What you do is you fill it out yourself. You don't have to have anybody else do it. You can do it yourself. Okay. If you're not required to do a full audit, you can just fill out an SAQ. It's a series of yes or no questions for each PCI, DSS or comments, you just fill it out 111, we sign it, and then you submit it as a data. That is one of the easier ways of passing on a PC audit. Okay. So it's exactly what it sounds like. It is a self-assessment questionnaire. You can fill it out yourself and it'll basically say, this is my current compliance posture. Nobody is going to verify it. That your work and you have to be truthful, please don't take this the long way. You have to be truthful, but nobody's going to verify it's really you can have your audit team check-in. That is the first part. Or you might be subject to a full audit, which is that the payment Granville asked for important compliance and also an attestation of compliance, which is an EOC that is basically a full audit. You will need to reach out to your Q essay. You'll need to engage with the company, which is like all UK, USA will discuss that later. They call a qualified security assessor. Okay. Basically, they had a PCI DSS audit. They will do a full audit. They will come assess your environment and say, Okay, this is satisfactory and give you a report that full auto civil get submitted to your payment band to your bank. Okay. But this one is more difficult, but I usually recommend doing the full audit just to make sure it is always best to have a third party come in and check it. Okay? So these are the two compliance obligations you might have. Okay. So now we've understood that, okay, I have to do PCA compliant. And now what do I do? A very, very key step that is, please do not skip. This is setting down the scope. Many organizations have any starch. They asked this question, okay, where do I implement PCA ideas is, if I have like 12 branches across, I don't know, 50 countries and 5 thousand staff do have to prevent PC IDSs and every one of them? No. So like I said, your scope is basically wherever it is storing, processing, transmitting the cardholder data environment. That is very hard to implement PCI, DSS. Many organizations that do have problems figuring out which systems are NPC idea of scope and which are not. Okay. For that, I would recommend dataset document. I'll try to touch it if I can, is called the PCI, DSS scoping and Netflix segmentation supplement. Okay. I think came out in May 2017. It really gives you it gives you guidance to identify what systems need to be in scope, what systems are not in scope, and how you can actually reduce your scope through segmentation. Very important guys, you need to understand your business environment, especially how the systems are interacting with cardholder data. Via cardholder data is being stored and we'll get into this. But you need to really sit down with your business. Don't just sit with the IT guys sit down with your business because the whole flow of cardholder data, you need to implement your controls on top of that. And those are the people, processes and technology on which the 12th PCI requirements will get implemented. Okay, so what, what advice at the scoping is a very important topics are going to take my time on this. So what comes into PCS scope? You need to first list, list, and confirm all the connected systems which are like processing, storing, or transmitted cardholder data. Okay. There are some guidance which the council gift simply put, any system that stores processes transmitted cardholder data or sensitive data, or any system which is on the same network has them. That's pretty simple. I think that's pretty logical, right? And what does okay, Apart from that, any systems which are providing them, which are connected to them, or providing them security. Okay. So what can that be? Okay, a system might be directly connected to your caudal and ramified through internal network connectivity. Or it might be indirectly connected, maybe like a jump server connection. Or it might impact your, the security of your cardinal environment. Maybe it's a web server, a DNS server, or maybe it's a server which is providing security, like network traffic filtering epoxy. Maybe it's distributing patches, single sign-on, or maybe it's a firewall which is segmenting off your card online environment from the other ones. Okay. Your firewalls are configured to block traffic light that will come into scope. Or it is supporting PCI, DSS or comments, maybe time server, your SIM solution. Okay? So this look at this diagram. It will help you to find out, okay? And of course, you can understand this looks like okay, managed kind of thing, a lot of system, the scope. How do you shorten the scope of PCI DSS, okay, there are things you can do to actually reduce the scope of PCI DSS within your environment. And the most important thing is segmentation. Without segmentation, your network becomes like a flat network. What does that mean? It means everything is on the same network. Okay. Your caudal environment, your security systems, your lawn card, older systems which have nothing to do. But you're cardholder data. All of them are the same network. And what happens is if one of the system is compromised, maybe your laptop gets compromised to connection to the Internet. Now the attacker can simply jumped from that server to your caudal environment. Without, because of this flattened, everything will be in scope. That's why you need to segment of your network. And it prevents out of scope system. So you're going to segment off your non cardholder related environment from your cardholder environment, okay? And what it does is it prevents those systems from talking to each other. And even if that non-causal environment is compromised, because it's not going to be as secure, it won't impact your card holder environment, okay? Even if an attacker gets in that document, not have access to the cardholder environment. Okay? So that's why it makes it difficult for the attacker to migrate from the point of entry. Maybe it was like a laptop or workstation to other systems. Okay. So usually what people do, they use firewalls for segmentation or you can create zones within your fibers. And let's take a look at how that happens. So just a simple integral in blue. This is like what a typical flight network will look like, guys. So this looks very institute. You have your network, right? The servers, your midas, heterolytic, your desktops, your point-of-sale machines. All of them have connected to a firewall on the same firewall, and they connected to the Internet. So you can see just said this is like a nightmare waiting to happen. One of them gets like a beach by an attacker. He can access pretty much everything you can jump from there to the cardholder environment. This is not the way to do it. So what do we have to do, guys? We create something called a segmented network. So what we do is we create a segment within the green zones, within the firewall. And we break it down into smaller networks like Cardano network like an on-call don't network like a business network. And you put firewalls or other devices between them. So that restricts their connectivity. This is how a segment and it will look like. So even if one environment is compromised, you cannot jump to your other environment, okay? Because you have other controls, segmentation can be tricky, especially if you don't have a technical background, okay? So I would always recommend having your network team double-check it. They just have your risk guy is the security guys. Check it, double-check all your segmentation. And you can, we're going to look into that. How do we check whether the segmentation is properly done? But I hope you understood guys, why it's so important. And now you can see how it is going to shrink the scope of your PCI DSS network, right? You will have in scope and out of scope. And just to be very clear guys, some funny talking about out of scope. So we're talking about systems. They are not in scope for PCI DSS, So you don't need to implement PCI DSS there. But then they won't have access to the caudal environment. But if they do, then you have to implement PCA, okay? You have to have controls like I mentioned, segmentation and other stuff to stop them from getting getting access. So within the PCA console, they've given some guidance. They say these other things so it cannot process cardholder data. It can't be on the same network, it cannot connect you and you just don't like it pretty much anything. If it does it to be considered out of scope, it needs to satisfy all this gray area and you need to have controls in place to provide the auditor assurance that like, you can't just change this tomorrow, right? You can't just bring this metric on the same network. You need to have other controls like firewalls, physical access controls, multi-factor authentication, restricting admin access, or actively monitoring this metric to make sure there is no network connectivity. Okay? And usually guys, one thing I recommend, and it's not popular. Why it's not required to implement PCI, DSS, an otoscope. But I always do recommend you can consistently implementing shade won't get audited, but it's just security best practice because the PCI, DSS is such a good control standard, you should implement it on out of scope networks also. Okay? So this is what it looks like, a typical network. Okay, That's what I was talking about when I mentioned. So you can see here guys, you have like a Caligula environment at the top right, you have a point of sale machine, your coordinate systems. It is connected to something shared services like Arctic territory, batching, logging. There's a jump server and you have an outer scope network, so there is no connectivity between the CDE, the corporate line, okay. There is a connectivity between the shared services and that. But you understand there is no direct connectivity. If there was any direct connectivity, then definitely it will become in scope. So this is, use this as a high-level guidance for how you want to segment off your network. Okay, So this is what I was talking about, segmentation. It's like an art. Honestly speaking, it changes depending on the size of the network, depending on how much control do you have, how many technical solutions you have, how good your network team is? And I would just recommend you reach out to your auditor before, show them the network diagram before and after how you're going to segment off, get their guidance. Don't assume they're not there to help you. They're not there to failure audit. They're there as partners. We'll help you out. So do reach out to them. It will save you a lot of problem later on. I hope this was useful to you guys and this was completes our foundational phase. So let's move on to the implementation phase now. Thank you. 5. PCI DSS process ( Implementation ): Hi guys, Welcome to this module, which is the second part of the PCI DSS process. Now we finished the foundational part right there. I'm going to talk about the implementation part, which is very important. Now. You've done the foundational, you've laid down all the basics. Now, the fun starts, which is actually implementing PCI DSS within your environment. Okay? So one of the major stuff you will do if you haven't done this already would be to engage UK, USA. Basically, the qualified security assessor. It's a designation which the PCA council gifts to certain people, then definitely they are qualified to perform now PCI suspense and consulting services and audits. To become a PCR, you need to meet certain like education recombinants you to pass a certification and take appropriate training from the PCA council. And then you're gonna be employed by a particular like I've security and auditing firm. And usually they have to be certified this annually. They invited the hierarchy USA. It is an independent third party by organizations who want to compete here, DSS compliant. Okay. And they want to make sure they will come and they will do the audit. They will advise you on how to become PCI DSS compliant. What during the pre-sale audit, the QSIF will determine whether your organization has satisfactorily met the PCF further comments, The Directory, or maybe you haven't mattered, but you put another controls, are compensating controls. If this is enough, then he's going to fill out a ROC and report on compliance, which is like a thick report, and an AUC which is an attestation of compliance. You and him a boat, I can assign that. Then you're going to send it to your payment scheme or your bank for verification. Basically, the three SQS as your friend is not there to make you fail. You're already Zai to help you. If he gives you a lot of observations, believe me, it is in your own benefit to make sure that those are rectified. Okay. A lot of people that just want to pass a PC audit and get done with it. Okay. They feel they've done their job No. Engage with them. Make sure you understand what the requirements are, why he's doing it. Treated like a partner. Okay. Treat him like a partner so that you're able to fully meet the requirement of the PCI DSS. Okay, so now you can get to the Kiva, say all the foundational work we have done now you can have the scope. You segmented off the network. Now you can start working on implementing the PCI DSS requirements. We're going to go into these in detail in the next section. So I'm not going to waste too much time on this. Basically, they are both operational and technical. Always the focus is on protecting cardholder data. We have six categories and 12 or comments and I'm going to go into detail on this. But the PCL or the QS say usually comes in and he does a filamentary like a gap audit. Okay. And he gives you your findings. So this is what it looks like. I'm first-time, I can assure you. First time and you do a gap audit, you're going to have like a like you're gonna be very depressed when you see the findings. They're gonna be lots and lots of findings is going to come in because no matter how much foundation that you've done, all these things you did not know about. You're going to find cardholder data clear in the most like unthought of the places that happens to everyone. This is based on my own experience of doing PCR for the past ten years. Okay. But there'll be lots and lots of gaps. Don't worry, it's a journey, not a destination. So you will make an action plan with a long list of items and start working on this. Okay? Implement a quick wins. There'll be things you can implement right away. Start for working on those and get regular updates, the QSEN, and then focus on the long ones. This is where I told you, remember where you are and what is the desired state. A lot of companies, they have the keywords to do this. You can do this yourself also, by the way, just to let you know or you can have a completely independent company, like a separate company from the USA. Some big companies, I know they have done it like this, okay. Also. So it's completely up to you how you do it. Okay? But like I said, focus on the quick screens and then you're going to have those findings. It's going to take some time. This is where the management support, which I talked about is going to NP-hard. Because if the CEO, the CEO is they're helping you out, believe me, things are gonna get moving. Otherwise, other departments have other priorities. They have other things on their plate day not their job is not doing PCI DSS. You will get a lot of support if you engage with the management support early on. Let's assume you've done it. You fix all the gaps. Now what So now comes the final part, which is the final audit. Before the final, you can test the QC. Okay. Fix everything, come in and let's do the final audit before that happens, gather on your documentation and your security policies, your change control accords, network diagram scan reports, documentation, training on and on. Okay. Makes sure all the stakeholders and align and ready. Don't assume they will just drop everything and come to your meetings because usually the QSEN needs to have like scheduled meetings, book everybody's in calendar, put and make sure that they understand the importance of this schedule, those reporting it makes your senior management is involved also, and the key people from IT, security applications, human resources, legal, all of those guys are there. Habits like sort of a team you can you can make a task force for PCA and you can have that loan lobby companies sometimes do that. Guys, please make sure put aside enough time to remediate findings. If your PCI compliance deadline is 15th of May, don't call the auditor and 14th of May, please don't assume they want to find things. You might find something completely unexpected. Have a buffer of two weeks, one month probably depends on your environment to make sure that just in case there's some completely unexpected findings, you have enough time to remediate them. Now. Congratulations. You've possibly say audit. The auditor is going to fill out the report on compliance ROC or that decision compliance or you might not need this with my digits filling out a self-assessment questionnaire. And you did not need the QSR at all. The reports are the official mechanism by which you, as a merchant or a service provider or a bank, you report your PCI compliance to your financial institution like a payment branded Visa, MasterCard. And sometimes you might need to submit SEQ report on compliance. Sometimes you might even need to submit a Stan. Okay. It it really depends. Like I said, it depends on how it's done. Sometimes you might also need to quarterly submit network scanning histories. Can we'll discuss deciliter. It really depends on the payment when it's difficult to just give you one one-size-fits-all for each environment. Okay? Okay. And now you pass the PCR that you've submitted it. What now? Very important guys, please, you need to implement PCA as a BAU process to ensure that security controls continued to be properly implemented, you need to fix it into your BAU processes as part of your overall strategy, like put it inside the other departments, operational manuals, their technical man who said that? No, they know this is something you have to do. Put it in your own calendar, the standards you have to do, the reviews, they have to do the ad. This is a way to monitor the effectiveness of your controls and it's going to maintain. So even if you're there, you're not there, somebody else comes in, maybe you're on leave. Everybody knows what they have to be doing. Okay? So you can monitor your security controls to make sure and you can make sure that if something is failing, maybe a scan is passing one-quarter is not passing the other quarter. If you have some sort of a calendar, this is a great mechanism to know how consistently are PCI DSS is going if you're passing scans every quarter, disk controllers mature now. So please make sure you implemented as part of a BAU. Don't forget about it and then lecture wake up, suddenly have to do this business. So this is how basically you implement PCI DSS in your environment, guys, like I said, it's a living process. It keeps changing, keeps evolving. The first year will be difficult. The second day you will see yourself improving. Third year you might face some huge challenges. Keep on improving the scope. Keep only, I think with the auditor change your auditors regularly. Don't rely on the same auditor for the next ten years. That's not a good practice. Keep on adding new things to your environment and you will definitely see your environment maturing, it will become more easier. And you'll actually start to enjoy the whole process of becoming PCA compliant. Okay guys, so this is completes the BCR process one. Now let's onto deep diving into the standard and the requirements which I've talked about earlier. I'll see you in the next module. Thank you. 6. Requirement 1: Hi everyone. Welcome to this module in which we're gonna do a deep dive into the PCI requirements. Previously we were talking about the process, about the standard itself. Now they're going to be deep diving into each of the trials requirements, okay? As I mentioned, I'm not going to go over each line of each requirement. Nobody wants to eat to do that. That you can do yourself honestly speaking, the main thing is you should understand the intent behind each requirement and try to meet that. Pca is a technical standard. Agreed. But it gives you a lot of room to maneuver. So let's start with the first comment and let's see. And remember, you can always reach out to your cell. So if you're confused about any requirement, treat him like a security partner. Okay, so let's start with the first requirement which is installing and maintaining a firewall. Just to recap, if you remember a fibers purpose, the primary purpose of a firewall. Why do you put a firewall here? Is to filter potentially harmful traffic, is the first line of defense. And simply installing a fiber network doesn't make it secure, right? So if your fiber is not configured and maintained properly and efficacy not secure in the default state. In summary, what I'm saying is a properly configured firewall is going to be the first line of defense is going to block unwanted network access. You're going to want to put it between your net, your systems and the Internet also within your cardholder network and your other networks also. Okay, so you're going to need multiple fibers. Usually that's how they do. And the firewall is usually when you do your segmentation, you're going to create your zones also. So that's i so when the auditor comes in, he's going to check if he finds out that you haven't reviewed your firewall for the past two years, that's gonna be a problem. If he sees that your firewall is still using the default passwords, like a full access open to the Internet. Nothing at all of those things are going to cause problems for you. Just to recap, we talked about before, remember how the segmentation works, right? So your rules and new environment is going to change over time. It's not going to be static. So you're going to make sure the segmentation is there and is reviewed every six months. Minimum. At least every six months you have to review your fiber, lose maintained it as a documentation, have a report there which proves that you actually reviewed the firewall. Whose guys remember that? Otherwise, the auditor will have no way of knowing whether you're doing it or not. And what are the key actions. So, like I mentioned before, a common mistake, a very, very common mistake that people make is assuming that firewall is like a pump plug and play technology. After you install it, additional effort is almost always required to restrict access and protect your cardholder data environment. See the end goal of firewall is to filter potentially harmful internet traffic and other untrusted networks. So like if you were working in, in e-commerce, the firewall would be there between your Internet and you're coddled environment, right? So you need to, this is where the scoping and all that hard work we did before That's going to come in. So you're going to make sure that all those things are there. You're going to have a denial rule. You're going to have pipe packet filtering unit. Anytime you open a port, they need to reprocess the IK unit opening upward. Was this checked by the teams, wasn't verified. If just one person is doing it, Nobody's looking at it. Okay. Remember you need to put it protected. Any inbound and outbound traffic from the caudal environment. You need to have standards for your firewalls, what is allowed, what is not allowed, and you need to have some sort of a review happening. Obviously, nobody is going to be reviewing your firewall or stealing nobody. Honestly, it's not even possible. But usually what people do is they make sure that everything is innocuous and francium. And they are alerts configured. And like, what do you call somebody who's monitoring it. Okay. If you generate a report, I think it generally comes like a three hundred, five hundred rules will come up in a small environment. So that's not even remotely practical, but the auditor is going to check the IU making sure your firewall is not just something you just put it in once and forget all about it. They are like reviews happening, standards are happening. It's being reviewed, it's being monitored, and it's properly placed. So it's going to look at where the fingerprints, the fiber network diagram also. So keep these things in mind and the fiber kilometer is pretty straightforward, I think honestly within your body calls security moment. It's funny. It's one of those things that should be there anyway. But the difference between PCA is how much effort they put so much focus and ports, the regular reviews and your due diligence happening. Running security rule is all that is needed to compromise your firewall environment. So all that I have that concept of trust but verify because the firewall makes sure that they're set up any reason happening and it's a perpetuity, the traffic is blocked. Okay. Make sure you have personally fibers also on your laptops and your PCAs, your mobile platforms. Okay. So it's not just a corporate firewall, make sure the firewall security is consistently applied across your network. So that's pretty much it. It's a straightforward or comment an ID and you can look at the standard to see what are the details like denial. And one of the things that should be happening, just make sure those rules are there. And you're reviewing and monitoring your firewall activity. 7. Requirement 2: Hi everyone, Welcome to this requirement. In this requirement we're going to do over the second one, which is configuration standards and about basically hardening and standardizing, standardizing your cardholder environment. If I was to tell you like one word to describe this, or two words actually to describe this requirement. It could be default settings. Traditionally, any or device, your router or your firewall, your server, it comes with certain default insecure settings, right? So PCM mandates that we have to make sure they are. They don't remain on their default settings and they are secured whatever you're putting in your Caldwell environment. It has been secured from its default. Setting. The easiest way for a hacker to access your internal network. Certified dry default passwords or exploits based on default settings, software settings in your Payment Card Infrastructure. You wouldn't believe that. I've seen many times merchants, they don't change default passwords for the point of sale machines or the cash registers. It's like you have a store and you've left it unlocked at night. Okay? So the vast majority of times it's default passwords and settings for network devices. They are widely known on the Internet. This information provided with some very freely available tools. They can give attackers unauthorized access very easily into your environment. You can secure it as much as you want. You can put as many followers as you want. But if you do, I haven't put in the move those default settings than you left the window open. You've locked the door, but you've left the window open. So what are the key points? How do you make sure that default passwords in different settings are hardened upon installation? Are you using those default password, 123 MVC, you know, the standard passwords. Is there a process present the auditor is going to look at is there anything present with which you can harden your standard IO falling some standard. Okay. Do you know that all the systems that do have like an inventory, like some automated way of finding out how many Southerners are there. What if you have like, you're supposed to have 50 servers, but we have actually a 100 servers and those 50 remaining, they are actually not secure. How would you know about that? Okay. On standards present value falling any industry standards. So these are the things you need to keep in mind. What are the key actions to take? Consistency is the main thing here. If you take away anything from this standard, it is consistency. So once you hadn't a server and you make, you have to make easy supposing you've created a harding standard, right? You say I'm going to follow the CIS benchmark. Okay? You have to apply to all environments and the customer consistent manner. So once you've configured the system and you've made sure everything is there. You have other work to do, right? You have to make sure this inventory is current. It's actually mapping to the environment. A lot of time people use some sort of automated system. Nobody is gonna do it manually. Okay? So that way if there is some system, system in the caudal environment which is not approved for use. It can be discovered, Wait. I usually use some sort of a system management software to assist in getting this inventory. They can report on the hardware which is being used or the software which is there. And as new devices are being bought online than they can enforce standards, okay. Admin will get an alert if your system isn't compliant with your internal standard. Usually a lot of times I've seen company using tools. Okay. So you need to have a secure way to managing the environment and inventory of everything, all the hardware and software and documented configuration standards. You don't need to make them from scratch, use something like the CIS benchmark, okay? And you have to have some secure way of accessing your systems. Makes sure that everything default is removed. How do you do that? There are many tools available, okay. Usually, it looks like this. Okay. So you you bring up a server or a firewall or an appliance in any city or state, your team is gonna do some hardening. They're going to do some scanning. They're going to look at the report. It's going to tell them, Okay. It's not hardened up as per the CIS benchmark. This password is there, these things are there. All these things are password settings are not there. You know, the basic part password settings complexity and all those things. Those are not there that the administrator's going to do the work and they're going to harden it. How do you enforce that consistently? Usually, people use something like a golden image or they have some sort of a script, toggles everything. And on top of that they have a scan which is happening consistently. That scan is happening and checking for any non-compliance. So you should have those tools in your environment. The auditor is going to take a look at that and make sure to find out if there are any deviations from your standards, okay, you should have a process to address that. So make sure those things are, they're just said, just remember no default settings or hardening and standardization and a monitoring process to be there to make sure that everything is standardized in your cardholder environment. Okay, I obviously this is pretty simple. I'm sure you might be thinking this is already there. Well, if it's already there, then formalize it and look at the requirements if there's anything that you're not meaningfully. Okay. Thanks guys. I'll see you in the next video. 8. Requirement 3: Hi everyone, Welcome to this module. Now, this is quite possibly the most important requirement for PCI DSS are a lot of times when people talk about PCI DSS, they're talking about this particular requirement only because it basically captures what PCI DSS as n. It's one of those unique things which PCI DSS has. Okay. And I'm talking about the protection of cardholder data. I don't remember what I told you earlier about not memorizing any requirements. It doesn't apply to this one. You should definitely know this requirement inside out because this is where the auditor is going to focus the most. Okay. This is where if you goof up and you don't follow it properly, you could potentially failed audit. So this is very, very important. So when we talk about cardholder data, basically we are talking about any information printed process, transmitted, or stored on a payment card, okay? If you are like accepting payment cards and you're expected to protect that data, whether it's printed or stored on a database or internal public network, or maybe a cloud. So the essential parties know where you're storing that data and what you don't need to not store it. And have some way of finding out where you're storing that data. You don't want the auditor finding it. You want to find it out yourself, okay? So those are the things. So PCI, DSS is very, very clear about what you can and cannot store. And you should know what you're storing, where you're storing, how you're storing it to make sure you are falling PCI DSS standards. So just to take a look, when you talk about carnival, the elements, what are we talking about? There is something called the account number, the cardholder number, basically the pan which we will call it, That's a 16 digit number. We have things like the cardholder name, the expiration date, the service code. On the back you have to track to data, the magnetic stripe data, and you have the CVD code you can use for e-commerce transactions. Basically, when you're storing this data, it has to be protected. Then you store it was showing this data. It has to be protected when you are printing the Delta, it has to be protected. The problem usually comes as people, unknowingly, they end up distorting and not protecting this data, which is where the vast majority of problems comes in. So what does PECSA and see like what should be stored? Okay? First of all, so it divides the data into two elements, okay? You're talking about cardholder data and sensitive authentication data. Okay. So your pan, you're cardholder name exploration service code, that is cardholder data. You can store it, but you have to protect it. And the other one which is sensitive authentication data like the data, the CVD code, the pin and the pin block, the pin, the pin you put in when you're doing a transaction that is sensitive authentication data or SAD, do not store it. If you're not, you do not have to store it after the transaction is authorized. Okay. Then the vast majority of times, those big compromises which happened, malicious people, they can, they find out this data being stored and they use it to reproduce your card and conduct a fraudulent transactions. The CPP code is you notice that three digit code that you use for e-commerce transactions card not present transactions. So the pin block is of course the pin which you are using. It, it becomes a pin block. It gets encrypted. But even if, even if it's encrypted, you cannot store it, guys, to just remember this, I think things you can store if it productions. So I think things you cannot store, okay? And this is the main thing you have to keep in mind if you are storing the Guardiola name and what do you call if you're storing the pan, you have to encrypt it. Or possibly if you're showing it, you have to do other things. So I'm gonna, what I'm gonna do is because they have many, many ways of doing it. What do you call protecting it. Then you're storing it when you're showing it, when you're printing it. I want to go one by one. What are the steps which PCA tells you? So firstly is masking or what is masking videos usually when you're displaying it on screens or receipts of printouts. It's not to be confused with the other requirements like storing, okay? So when you're showing on the screen, when you are vertical and that person does not have a requirement to see it. Okay? So what you can do is you can mask the pan, basically you can XXX way the card numbers are. Apart from that, you get the maximum. You can show us the first six and the last four. Everything else you can simply mask out. So you can see this is the storage tank. When it's being shared on the screen you can completely mascot, okay, we're not talking about how the data is stored. We're talking about when it's being shown. Okay. When people Missy's computer screens and when there is no business need to view the entire pan sometimes like your call center agents or some other people, they might have a neat to see the full pan, okay, you need to document that. But nine times out of things you don't have a need. Okay? So it basically conceding certain digits during display, even a holiday, regardless of how the pan is being stored, you can mask the taste. Okay, So the first step is masking. Find out where you're going need to mask it. And actually, masking should be the default only with somebody who has a business requirement. If your system has the ability to mask it, I just turn it on across the board after you check with the business. Okay. So this was the first one which is masking. The second inverse is truncation. You can also truncate the data when you're storing it. Truncation is similar to masking, but there you don't XXX our data, we simply discard those digits. So you can see here, this is a full pan number. And when you are storing it in a database, you could use simply discard it, okay? So basically it makes the card unreadable. Removing a segment of that data. And it usually is used, I've seen it being used in databases and files. So even if an attacker is able to get access to this day, they can't do anything because those digits have been removed. Sometimes companies can use this as a method also. This is more on the storage, okay? Okay, What else is there? You can do one way hashing. Then you're storing data. What is the one-way hash? It's like a cryptographic process. It takes your data and it converts it into a different type of string. So every time you do it on a pan, it's going to show a different result. Why do you call it a one-way hash? Because it's still reversible. So you can't get that vertical from the hash. You can't get the card number back. Okay? So a lot of time people use it to check if data has been modified or not, but you can also use it for storing it, okay? So it basically, you are creating an irreversible one-way hash of your data. It's up to you if you want to use this process. I've seen it being used. Just remember you cannot go back from that hash. You can't use it for future transactions, okay? Because that data is being irreversibly changed. Like sometimes we need candy you don't have to store, like you do is no need for masking. It isn't only for truncation and you don't need this data, you can store it as a hash. That's one way as possible. So we've talked about truncation guys just to go back. So this was Caucasian. When you're storing it, this is hashing. Now you know the difference. One thing very, very important guys. You cannot store truncated and hashed versions of the same payment card. Virginia caudal environment. Okay? Because what happens is these can be correlated. What do I mean by that? If attacker has access, what do you call to the truncated and that band and the hashed versions of record number, they can actually get back the original plan based on these two data. So when you're storing it in databases and flat files like spreadsheets or maybe like backup audit logs, you might have to protect it and do not store them together. Okay. He was one of the two, but do not store them together. A lot of people's I've seen sometimes they forget about this requirement and it's truncation and hashing is being done at the same time. Please do not do this. Okay, what else is there? Tokenization. Tokenization is a very simple process. What happens is sometimes you've seen that when you hash it, you truncate it. The 16 digit format changes, right? It's no longer as 16 digit number. Tokenization is a process that replaces the original card number. Another 16 digit number. That too it's called a token. The token may look like a legitimate cardholder number, but it's not, it has no value to an attacker. Ok? So usually what happens is this is reversible, so you can do tokenize that you have something called a token volt. So with the form that token, you can back, get back the original card number, okay, you can get it back. So tokenization, usually I've seen it, It's being used when people just want to store card holder, cardholder data for future transactions. But they want to make sure it's secure and they don't want that format to be changed. So I mean, you can there are multiple ways of doing it. You can do it from the pan. You can generate it randomly. You can have a token, a token vault being created, which is the tokenizing and D tokenizing data. There are multiple ways of doing it. Just understand the token it preserve storage, format the 16 digit pan, and you can reverse it so it can tokenize and D tokenize it. Sometimes your databases, they can store large amounts of data which would come out if you're hashing it and they need a 16 digit number. So tokenization helps you out. Tokenization also sometimes I'll even taking it out of scope. But there's a lot of work to be done around that. So this is the basic difference between tokenization and other functions. Lastly is encryption, which is the most common thing. Encryption is a bit similar to tokenization in that Japan is being replaced by other data that has no value. But encryption is somewhat different because first of all, it doesn't preserve the original format. And it uses a key manager like a wall with a cryptographic key. And it uses like a key manager because your kid, it uses a key and an algorithm to generate a huge number, which you cannot get back the original card number from that data. Okay? So typically the data size increases like it doesn't preserve the original format. So it's really up to you what you want to use. Some people prefer tokenization because they want to restore that format in the 16 digit of some people prefer encryption. Usually depends on your business requirements. Just know one thing. I talked about a key like you need a key to encrypt that data. So that key, you have to encrypt that key also with another key, and you have to store that separately. It's like you can refer to the requirement. Just know when you encrypt data, a cardholder data, you have to encrypt it with a key and you have to protect that key also, you have to encrypt that key again. So just remember that when you're talking about encryption, I know it's a lottery ticket guys. Just go through this, revise it and slowly, slowly you start to understand it. You don't have to implement all of these things are number that you can just make do with encryption or hashing or tokenization. Just know these different departments. Okay? Then you talk about, like I remember, I talked about finding our data. So you need to review your data sources to make sure that the NADH storing cardholder data unencrypted. You don't have any sensitive authentication data. Look at your transaction logs, the transaction data, your trace. Try as you know, sometimes people turn on tracing for troubleshooting. A lot of times that starts storing unencrypted data, okay. Look at your database schemas. Schemas might show you if there's any card number there. Okay. Look at your backups, any existing memory crash dump files. Okay. Your DLP, lots and lots of things are, they're just starting from the left. You can look at your payment terminals, whether you're mastering or truncating all the data you are storing any sensitive authentication data. You're not storing any data undetermined. Look at your screens and reports. Okay. Is there anybody who has a requirement to view data, cardholder data, if not, just muslin truncated on the reports, can use this extremity, this desolate data. What if you can stick it out? Okay. What if somebody has remote access, they can stick out this data. Do we have any DLP controls? What about databases and storage? Okay. So when you're storing that data, do we have a proton encryption there? Is there any sensitive authentication data? Usually people, what they do is they have some sort of a tool that scans the databases and it gets them report. You cannot do it manually. There will be millions of records, you cannot do it manually. And lastly, file share. A lot of times file shares or a blind spot. People don't know that employees are putting cardholder data in Excel sheets or what he called flat files and they don't know it and suddenly doing the audit, it comes up. So make sure you're scanning those also, and made sure that it cannot be exfiltrated out. These other things, guys, I've spent more time on this because this is very, very important to know. So key actions. Find out first video cardholder data is don't just use the technical method, talk to the people also, draw cardholder data diagram. Sit with your business and find out what the flow of data is from the point that data is captured, the cardholder to till such time it's authorized and stored. Okay. So you'll find it in databases, file shares, even e-mails, you'll find it a cloud outsource providers. And lastly, I want to talk about, okay, what if you can't implement PCA control soviet? I want to keep this in mind. We're going to talk about something called compensating controls later on. So that is something you have to keep in mind. What if you can't encrypted because it's a legacy application, right? So what are you going to do that? So this is something I want you to keep in mind. Okay. What does so you need to have a data retention policy. Maybe you don't need to stop cardholder data after 30 days, okay. Just delete it then there's no need to keep it. You should have a data flow diagram. The auditor is going to ask, how do you find out, first of all, where your data is stored? Do we have some sort of a tool which is regularly scanning your servers, databases, laptops, and most important guys, please do not store sensitive authentication data. After your card authorization is done. Remove your truck to data or MOOC. We don't stop in blocks masking out pines on customer receives. And if you are storing it, the cardholder information, then please mascot or truncated or security to encryption. Make sure that it's the databases or their storage is accessed by as few people as possible. Okay. So this was the requirement, guys. I hope it wasn't too much. Just take your time, go to the standard. The main thing is find out where your cardholder data is and protected accordingly. Then don't store data unless you do not need it. So just go through this model one more time. It will revise. So you have a better idea of it and make notes and then try to implement it within their environment. I can guarantee you. If you are in the card business, you will find cardholder data where you did not expect to find it. That's a common thing. Don't don't get scared by it. Just make sure you have a process to remediate it going forward. Okay, guys, I'll see you in the next section now. Hopefully, you got a better idea now and I'll see you in the next module. 9. Requirement 4: Hi guys, Welcome to this module. This module is relatively short. It's pretty simple, which is securing data, open and public networks. This is pretty simple. I think. I don't think I need to explain this too much but calculate it. I mean, if you're sending it over and open and public network, you have two encrypted, right? You don't want people just looking at this data. This is going to be sending it to a third party processor, maybe backups, maybe over the Cloud. And most importantly, cybercriminals can maybe intercept this transmission over Guardiola data. So it's important to put in controls their encryption can use it. You can put any encryption using strong cryptographic unit TLS and all these other controls. You might have point-of-sale terminals, which are sending data over the internet or wireless or GPRS. You have encryption over that, over your violinists and other cellular technologies. Okay. And what about messaging? Like email, instant messaging, SMS, chat. You can send cardholder data with that also. So you need to put in policies, you need to put in controls like DLP. So it's very, very important to have those things. There is some mixture of technical and operational controls. You might think It's very simple, but believe me, especially if you're using point-of-sale terminals, a lot of time what happens is point-of-sale terminals they using old versions of TLS, TLS 1.1, and we're not using the newer versions like 1.21.3. You need to make sure that you have a plan to migrate them. Just build off the dataflow diagrams we talked about earlier in common three, you will know the cardo date it is coming from NBC being sent outside. I want to make sure it's encrypted. When being sent over open public networks. You don't want to make sure that those encryption or they're having in-house policy not to send clear card numbers over SMS, over chat, over Slack teams. Please do not have that. Okay? You want to check your point-of-sale terminals to make sure they're encrypting get appropriately. If you're not maintaining them, you have a vendor reach out to the vendor and make sure those point-of-sale terminals, they're not susceptible to any known exploits, like standard vulnerabilities. Usually it's the vendor who tells you you can do your own testing. Also. A lot of times what these companies do, they make sure their point-of-sale terminals are already certified to PCI DSS. You can check the modal number. You can go to the website and actually putting the mortar lumbar, putting that version and see where there is lifestyle certified to is usually called the pink transaction PDF Standard. And I think there's one more standard, but you can check it on their website. It will tell you right away whether this device is secure or not is certifying data as per the PCI DSS standard. This is pretty much what it is. You guys make sure you have an inventory of all your data which is sending get out. Lot of times it's the point-of-sale terminals. Make sure you have control over your end-user messaging like emails, slack time, whatever you using. Those controls have to be there to prevent cardholder data for being sent out over the open public network. Okay, that wraps up this particular section. And we'll lastly, just make sure you're not using TLS 1, disable all those insecure protocols. You don't want to be using those early implementations of SSL and TLS because that's very easy to compromise. It's not considered to be secure. So check with your point of sale when their point of BI vendor and have some sort of a plan. If you find out that your point of sale devices are using it, you need to have a risk mitigation plan and a migration plan by leave it in the next 12 months or 18 months, I'm going to migrate everything to TLS 1.2 because believe me, the auditor is going to ask you that. Okay, that wraps it up, guys. I will see you in the next module. Thank you. 10. Requirement 5: Hi guys, Welcome to this section. This requirement is, I think distributed easiest for you, which is talking about if you don't have this, then there's only a bigger problem than not being PCI DSS certified. This requirement deals with antivirus, anti-malware that needs to be installed on all the systems commonly affected by malware. You need to make sure that you have an antivirus solution there, which is on there, that everything within the cardinal environment, you want to make sure it's there. It's regularly standing, is regularly up-to-date. And you should have a process to find out if there is some new attack happening. How will you find out if there's a zero-day exploit happening or some malware is there suddenly affecting all the systems? Do you have some sort of a way of finding out what's happening, what are the alerts coming in, okay. So make sure usually a PCSS that implement anti-malware on systems which are commonly affected. People take it to be in Windows, but you should put it on Linux also, lot of the Linux server flavors which are there, they do support anti-malware. Make sure it's there. Don't get lazy on Linux. And made sure that you have implemented anti-malware across-the-board. You're scanning it. And what happens. A lot of time people like they put an anti-malware, but if an alert comes, nobody's looking at it. Okay? So you want to make sure that those alerts are going somewhere in some ways actually taking an action based on that alert so that window of compromise, it needs to be very short. Those things make sure that your antibodies is up-to-date and it's sending alerts. Okay, don't assume anything here. Like I said, the key points are deploying antivirus on commonly affected systems and non commonly affected systems also, please guys, if you have some sort of like Linux or some other thing, if there is a possibility to implement anti-malware, please deploy. Don't get lazy, okay, make sure it's getting updated if set to scan automatically and if anything happens, those alerts are going somewhere. Okay. Your definition should be current. It should not be able to your IT administrator but can't just go and disable antivirus white, make sure there is a segregation of duties there. And you should make sure some sort of practices there that when you call them to regularly assess systems, like maybe you have an old legacy systems AS 424 tandem HP don't stop all those old systems which a lot of people don't use anymore. But have some sort of a regulatory risk assessment being done to find out if there are any industry alerts coming out. Maybe there's some new virus has come out recently which you don't know, and it's affecting those systems. So please make sure those controls are there and that is documented, that they can give that auditor that assurance like usaid that you have a process is dead and you are going well above and beyond. Okay? You're looking at the industry trends and you're putting in controls that have to be there. So this is a pretty easy standard to meet. I don't think any difficulties should be there. Usually people who run into problems when they're looking at those legacy systems. But apart from that, I think it should be straightforward to implement. Thank you guys. I'll see you in the next module. 11. Requirement 6: Hi everyone, welcome to this lesson. And in the view VHDL, we're halfway through the array to cram and six, which is developing and maintaining secure systems. Okay? And this is one of those departments which a lot of people hate because it has to do with patching. Again. I don't think anybody likes patching, but unfortunately, it is a mandatory part of any security system. And you need to, you need to have a system in place as propitiate to patch vulnerable systems. Why do you do that? It's pretty simple, right? Security vulnerabilities in systems and applications. They can allow criminals to bypass controls and access cardholder data. Most of these vulnerabilities can be eliminated by installing security patches. When they provided patches, we went from Microsoft or your third party vendor. And it's like it plugs into the security hole and what we call Asper PCIe. All critical systems, they need to have the recently released software patches installed within, I think it is as soon as possible within 30 days. And other ones you can do it within 90 days, but this is really one of the most difficult things to accomplish. You can understand why. Because critical servers, servers are very critical and you can't just have downtime happening. And at the same time you have attackers who are paid, possibly exploiting this. And it becomes more dangerous when it isn't. One interesting thing. So like you need to have a very strong patch management process in place for implementing critical security patches, guys, it is one of the most difficult and most important to comments and PCI. Okay? So what do you have to do? Well, you have to make sure the patch management policies in place and have a process. How do you know that some critical patches come in? You need to have that also a change management process has to be there for any chemical changes. How do you know that your changes are not introducing any new new security issues, right. And like I mentioned, have a month, one month, what we call installation there. Sometimes the companies cannot meet it. You need to have it than other compensating controls in place. You need to have a system for patching quickly, deploying patches on test environment, and then rolling it out to production. It is very, very difficult to meet, I know, but it is something from your security posture. Pci, DSS can actually help you out here because IT, IT teams can sometimes become lazy when it comes to implementing patches and PCI DSS will really help you out here. And it will help you to push the technology teams to implement patches as quickly as possible. This is more from the OS perspective. It applies to applications. Also, you will have application level patches coming in. But from the application side, requirements six introduce a certain new things which I need you to be on the available about understanding. What are they. So when you develop applications guys, your developers, they need to have training on application security vulnerabilities you will be familiar with, all right? It's likely a common standard for application security. They should be trained on what these vulnerabilities are. At the same time, your source code should be reviewed. Also. You should have some sort of a thing in place which actually is reviewing your code, letting you know if there are new vulnerabilities here and your development and drama, it cannot have any live cardholder data. Sometimes people do that for testing. They put Guardiola environment in testing or UAT or something like that, please. You cannot absolutely cannot have the thing happening. Okay. And then when you move to production Raman day should be a proper change management process there. If it's like an internet facing application, you need to mitigate. How do you mitigate that risk? You can either have a web application like a pen test happening, okay? Like abstract happening, which if I let you know if there any vulnerabilities or you can have a web application firewall, you know, I'm sure you must be aware of that. Ideally, I would recommend both. I don't believe that one replaces the other. You should have a vav and you shouldn't have an application security testing happening dies. So all of them work together. You have to understand, you're doing code review, your training developers and CCA-secure recording techniques. You're making sure no cartilage, there is datas than testing or UAT. You making sure the proper chain management is there. And then you have a web app scan and apps the coupling. So all of these really helped to mitigate the risk of some issue happening somebody, you know, how common application level vulnerabilities are there, right? But all of these, if you implement them properly, they really go a long, long way in mitigating application security risks. And they really helped to bring improve your security posture. Okay. Moving on guys. So what are the key actions which are there? Just to remember, you should have an application security policy formulas and distributed to your developers. You should have a secure coding training happening and a code review. Something which lets you know if there's insecure code and it doesn't let it propagate to production. You can use common commercial tools are there which really help the developers. You can have like open source tool also. Thirdly, how do you know if there is a pan in the development environment? You need to extend your scanning there. You need to make sure that there is no Only mask or like a interrupted or it has not even encrypted. You only master truncated or like completely numbers there. The development environment. Like I mentioned, you should have a Web Application Firewall plush and application security pen testing happening. And of course the chain management. So remember applications security will never ever be perfect, okay? They will never be a time to say now my application security has become perfect. I can stop it. No, no. That's why you have to keep refining this process. It only takes one security hole for the attacker to come in and to compromise your environment, right? So patching and application security, all of them but got together. This is one of the more difficult to comments, but it has one of the most benefits to your security posture posture if you implemented properly. So I hope you understood now, As all of this works together, like I said, I'm sure you will find in secret applications, you will find like old Windows versions which cannot be patched. So you need to take it into account. Either remove them from your current environment or put in other controls. They always ways of doing it. Many times I've seen applications which are running on old legacy applications. You can maybe visualize it, you can containerize it. You can put in some, in some sort of like a Citrix, something that's encapsulated, set or removes the day. A lot of ways of doing it reach out to your USA and I'm sure he will help you out. But just make sure that you are aware of these vulnerabilities and they don't catch you on a vase, okay. Okay, guys, I'll move on to the next recommit. Thank you. And I'll see you in the next lesson. 12. Requirement 7: Hi guys, Welcome to this lesson. This is one of them easier to comments, especially after the last one. And this has to do with restricting access, okay? Basically, if you're following the principle of least privilege, if you're not following, you should be following it. But if you add them, this becomes easy because your cartilage damage very sensitive. You should have something like a role-based access control, which makes you sure that only the people who have a legitimate requirement to view cardholder data is doing it right. You don't want your advanced user accounts which don't have any reason to look at cardholder data, they're coming in. So PCA, it requires an up-to-date list, like a role-based access control matrix. I'm sure you will have that matrix, right? You should have that. The auditor is going to take it. That list doesn't have each role. What role does what sort of things that has access to, what's the current privilege does it is it really needed? So based on that and you should be regularly certifying this, right? You should be looking at does IT have access to, I don't know, like they do programmers have access to production, right? Do system administrative access to application database writer, should they have that right? So these things you need to, you need to document it and you need to formalize it. On top of that, you need to be having regular reviews happening. So yeah, this is what we need. What are the key actions are written policy for all like detailing access controls, documented access control. You should map it to the job classification, right? So if there is like an Network Security Administrator, you should not have access to your production database, right? Why would you need access to that? Makes all those words in public should be defined least privilege, that is the key thing here. And you should have a detailed written policy only these grows will have access to cardholder data. Only the database administrator can have read access to the database and all these things. This will really, really help you out and you should have these regularly on a quarterly basis, on a daily basis, make sure these are being reviewed and recertified from all the users. So this is a pretty simple economy to make. A lot of companies have seen they already have some sort of thing in place, either manual or automated. So you just need to formalize it for your card holder environment. This wraps it up for this requirement. Let's move on to the next one. 13. Requirement 8: Hi guys, Welcome to this particular class. And this is one of the, again, rather easily requirement to meet if you're following good security hygiene already, which is using uniqueID potentials. So PCS states that basic good credentials like your parser should we change every 90 days, which should have length and complexity. Previously used to be seven characters now they're finally updated it. But if you're using something like Active Directory or a single sign-on, usually they do enforce strong password policy. You don't want to have a password which can be easily broken by a hacker to automated tools, right? Because computing power keeps increasing every year, computing power is getting more and more powerful. Brute forcing is becoming more and more easy. So you need to have complex passwords, make it very, very difficult for an attacker to compromise it. Okay? You don't want to have standard usernames, don't have administrator or KPIs leading him that I still see those people using some very basic stuff. So you don't want to have these things like which can be easily broken through social engineering attack or a brute forcing attack. Okay, This is very basic stuff, but it is so important that PCAs made it a separator climate. Another very important topic guys is MFA, multi-factor authentication. If you don't know what it is, like, I am sure you must be aware of it, but in addition to the user ID and password, you need another factor for, in PCI DSS for remote access or administrative access. So this can be something you have like a onetime password, like a token or something you are like a bio-metric, you know, like this can be things like something you have, can be a smartcard, physical, logical security token, onetime password in your smartphone, okay. And something you are would be a bio-metric like fingerprint retinal scan, pumps print, iris scan, any other thing which is unique to you from your biological perspective. So you can use one of these two in addition to the user ID and password. But remember, they have to be independent of each other, like if one gets compromised or there is not affected. So for example, if your smartphone is compromised rate and an attacker gets access to the onetime password OTP, he still won't have access to your user ID and password, right? So they have to be independent of each other. So remember that in this particular comment, you should have administrative access for remote access and multi-factor authentication for remote access and multi-factor authentication for your administrative access. 1 to note guys, this is going to become much more tougher NPCI version four. Okay, I'll get into more detail in another section where we're going to just discuss the PCA version four requirements, but just keep this in mind. The council is making this a little bit more tougher now going forward. Okay, So what are the key actions to take guys? Definitely you should have a password and MFA standard across the board consistently enforced. This is the p-value. These are the minimum positive comments and these are the MFA requirements for demote or administrative access. Make sure your remote accounts. A lot of times you got access to vendors, business partners, consultants, right? And they have to be monitored and disabled when they're not in use. You should only have them. Then as and when they use. A lot of people put in third-party applications like VDI or something like that. I mean, it's up to you how your environment is configured, but just have that in place. And that will really, so basically this is like a simple common sense requirement. I'm sure a lot of these things you will already have. If not definitely, you should be having MFA for your administrative environment, especially if it's the cardholder data environment. Definitely have that enforced. Okay guys, So that wraps up this will comment. Let's move on to the next one. 14. Requirement 9: Hi guys. Welcome to district comment. It says like one area which I always think of it as a blind spot, which is when it comes to PCI, DSS, which is physical security. A lot of companies, they put in a lot of technical controls, but they forget the physical side of things like printouts, reports. Lot of companies, you know, they have back-office is whichever repeat billing like they save the card number. They keep physical copies of current card. And you won't believe these are openly available, right? So you need to have things in place to protect things like data theft and sensitive access to sensitive areas. You should have physical security policies and procedures. You can only keep like for example, only keep confidential information. Workplace secured them in a locked area. Outsiders can't just walk in. Non-employees have to wear badges, are not storing sensitive information. The open V in my, one of my companies we used to clean the streets after office hours. We used to go and check that everybody has clean up their desk, right? There's no sensitive information there. So these are controls which are common sense, but they unfortunately that you get missed out for some reason, right? So what are the things you need to have? It need to have a proper physical security policy highlighting which other sensitive areas. One thing I forgot to mention is your network jacks, right? You don't want like people just plugging in their laptops and connecting your target environment. The physical media or backup and other things should be secured and strict control should be there. What if somebody cannot compromise the environment? What if is able to access gag, get access to the backup tape, right. Which has all the information you need to have like a put it into security, are clearly marked for that. Documents should have things like confidential to be shredded and you have to be able to destroy media, right? Diego said destroy it based on its classification. A lot of these things, again, they probably are doing, but you might not be extended it to your card holder environment. Make sure they get extended. You should be coordinating with your physical security teams to make sure that you have proper training is happening. Sensitive areas are cordoned off. Not every employee can just walk into your light sensitive areas. So all these controls Metrodorus unforced to have proper cctv coverage. It should be a mixture of preventative and detective controls. Basically the same things you put in your environment, right? Your technical environment like segmentation. Segmentation, you block off that area. Cctv is like an auditory and white badge and password badge and pins. They are like MFA. All those things, you just replicate it to a physical environment. One unique environment, guys, if you have like point-of-sale terminals, like point-of-sale machines. You should have a complete inventory of that. You should have an up-to-date inventory of those. You should know where they are. What's the physical location, serial number, naked model. Why? Because it should be inspecting it. What if somebody has tampered with it, but if somebody has replaced it with another C, then another environment, usually a lot of companies they maintain like advantages of it, right? What if somebody has gone in, tampered with it, injected some device and you don't know about it, right? You can do it basically, could do it every day, every month is based on yet like what sort of level you have, okay. You should have cctv coverage. Those, these are very subtle devices, okay? Make sure that top it's completely restricted. And you should be providing awareness for staff who are interacting with these things on a day-to-day basis, like a cashier, who is who has that point-of-sale type of machine, right? You should know if somebody has replaced it. If there's some device there, you should be able to know if somebody has like, you should be able to check the serial number. The basic physics. These are simple things you can have like a video training. You can visit physically and teach them and like, but just to make sure that the risk of substitution, somebody substituting the device when something or there's some other device maliciously or like tampering, tampering with that device, putting some other device on top of it. Those that vest has to be mitigated. From the perspective of PCI DSS. They are like many, many common trainings available even from the PCAOB website, you can find it. It's like a unique thing from PCI, the other physical controls you might already be doing. But this is something unique and you should make sure you have it in your environment, okay? Okay, that wraps up this recommit. Let's move on to the next one. 15. Requirement 10: Hi guys, Welcome to this lesson which is now we've reached almost the end, which is a common ten, logging and monitoring. Logging and monitoring. You know, it's one of those things which almost a lot of companies do. Almost every company does, but very few companies do it correctly. Because what happens is a lot of times they're just recording stuff. But nobody is taking any like intelligent action based on those alerts, right? Sim solutions, you got security information and event management. You are sending all the logs there, but you're not really looking at creating actionable alerts. You're not really refining same things. You need to capture everything which is where within the cardholder data environment, PCI actually has like a minimum list of events which should be captured. Okay? Most systems software generate logs securing operating system, browser pause, firewall, all of these things you should be capturing, okay, So make sure those things are there. Whether you have a SIM solution or some other thing, you need to be capturing everything. And I having actionable alerts based on that. Okay. So what are the things we started is going to be checking is gonna be checking whether you have an automated audit log tracking for all security events. How are you doing it? Is it like if somebody you're not going to have somebody looking at it and essentially write some automated system. Is there you have a process to review logs and security events daily. Usually it's like an SIM solution. Maybe you might have a SOC team, or you might have like shifts, or you might have us take a system administrative gets alerts. It really depends how you're doing it. You might have, if you're doing it in the Cloud, you might have automation, but the process needs to be there. Your audit logs, they need to be there at least one year and the last three months. They need to be online logs. You should be you can't have be archiving the last 90 days, okay. You need to have it online. And what are they eventually to be capturing PCI, DSS is very specific about it. Like admin activity is failed logins, changes to account privilege escalations. And you should carry capturing what they knew who the user was, what the event was, what the date and time, whether it was a success, what a failure where it happened, all those things. You'll easily find it within the standard. But make sure you're capturing it. Make sure you have those slots available and test it out. Don't assume that you will have these logs okay. A test it out and make sure that you have those events being captured. A lot of SIM solutions, they already have predefined templates for PCI DSS through it should not be that difficult. Just make sure those are turned on. That this one was pretty straightforward. Let's move on to the next. 16. Requirement 11: Hi guys. We're at the second last requirement, which is conducting vulnerability scans and PET is okay. Why do we do these things, guys? So simply put, these, you need to find out what are the weaknesses within your environment, right? You don't want to wait until an attacker comes and compromises your environment, right? Vulnerability scans and PTs are one of the best ways to find out what type of attacks you're susceptible to. Va is like a vulnerability scanner is an automated high-level scan. Okay. You just run a scan. They usually have it. You have some sort of a software that scans the environment, gives you a report, right? You have to run this internally and externally on a quarterly basis. And PT I'm sure you already familiar it's like a detail hands-on. Usually there's a real person there who tries to detect and exploit weaknesses in your system. And this, again, this has to be internal and external, both in your environment. Pcr requires these things to happen at multiple layers, okay? You can just do it in one layer and call it effective. We'll go into detail what I'm talking about, what sort of layers I'm talking about before we go. One thing very important guys, if you have public-facing Guardiola environment, right? Public IPs. Pcr requires businesses who conduct like external via scan and they call it and ESV scan to find out if they have any potential flaws. This you cannot do it yourself. You have to be done by a company called an Approved Scanning Vendor is called an ASP. Okay? You cannot do it yourself. You have to leach out to this company. So what happens is because you will be charged to this company and they will do the scan on a quarterly basis. You have to remediate any highest high vulnerability. So you have to keep on doing it until you pass. And they will give you a passing scan. And usually that you have to submit to the car schemes or to the blank. So this is not something you just scan it and forget about it. You have to do it on a minimum quarterly basis and you have to pass it. That is one of the most important thing. It's usually a very good requirement because public facing is like a high-risk environment. You need to be able to scan it and know what the vulnerabilities are. Okay, so just keep this in mind. Your bank or your payment scheme usually will tell you whether you, we talked about the obligations earlier on rate. So your bank or your payment brand will tell you if you are required to do this or not. But remember, I told you we have to do it at multiple levels. So this is what I was talking about. Just take a high-level view. If you're looking from the internet, you need to have ASP scans happening and a PD happening. Okay. From the external perspective, within your cardinal environment, you didn't have quarterly via scans, annual pay a PT is happening and something called file integrity monitoring. What is a file integrity monitoring? If you're not aware, basically, it's a software which stands for environment for any critical changes to files, okay. You might have sensitive files in your environment. You don't expect them to change a file integrity monitoring software will tell you if this file of change and will raise an alert. So you need to have that also within your environment. So supposing you're coddled application has a sensitive configuration file that is not supposed to change. What if that gets strange? Okay, So that file integrity monitoring solution will raise an alert and send it to you that should be there. And apart from that, if you have a wireless happening wireless environment, you need to release candidate for wireless cans also to make sure that the new insecure or maybe rogue wireless access points. Having created, usually we have three tools and commercial tools. You can scan the whole environment and we'll find out if there are any vulnerability or any road violence points there. And we talked about segmentation. Remember? We said that, okay, for the segmentation perspective, they should be something there is dropping. And so that will usually be a firewall and IDS and IPS. So we do something which is called a segmentations can, what is the segmentation scan? Segmentations can somebody actually tries to compromise the segmentation? So from the cardholder environment, he tries to jump to the non-cloud environment or from the non Guardiola umami taste The jumped to the cardo, the environment. He checks the adequacy of the segmentation which has happened, whether it is good or not. So this is why it's so important guys, as the all of these things you have to be doing, the different times that they are somehow I knew somehow half a semi-annual put it in your calendar. We talked about having a BAU process, right? This is what I was talking about. Usually what companies do and PCL mandates you should have a methodology for penetration testing. And you put what are external, internal, like what, what's going to happen annually? What's going to happen after every change? If segmentation changes, how are you going to test that? How are you going to do the application level one? How are you going to lay a switch? Can all have their documented in a proper formula is document and make it available to everyone. So this way, you won't get like a cotton surprise and you miss out on some critical scan that you're supposed to be doing. This is a high level, like a bit simplistic, but this tells you what the standards should be happening in your environment. So I hope this, this was like it gives you a clarity. Start with it. Initially becomes very overwhelming and slowly, slowly becomes like a BAU for you. Once you put it in your BAU process, you'll find that it becomes much more easier. Okay, guys. Okay, that wraps up the second last one. So we should move on to the last one. 17. Requirement 12: Hi everyone, welcome to this lesson. Now, we've reached the last requirement of parameter Alpha, which is documentation and risk assessments. So previous one was a very technical requirements regarding pen testing and b, a and P, D and all those things. Now we're talking about something which is much more simpler, documentation and risk assessments. So here guys, we're talking about something that you have to do like, from the due diligence perspective, the auditor needs to know that heavy formalized all your information security policies, other stuff away of what they should be doing and they should not be doing. This helps to protect you in case something happens, there's a breach. Then you can prove that you did everything from your perspective. You need to make sure your security policies have been approved and body called, communicated, and signed off by all the employees they've acknowledged at it. Okay. If you are a service provider, you need to have something called a PCI DSS charter. It says that who is responsible for PCI DSS and who's going to implement the program and who is accountable for PCI, DSS. It has to tell you who is the person responsible and how it will communicate with executive management, okay. Apart from that, you also need to have an inventory of any third-party vendors, outsource people or third party vendors who have access into your cardinal environment. Because if they get compromises potentially this to your environment, you need to have a list of all third party service providers and whether they are PECS certified or not. Okay. You need to have the list. Most of them has usually available and you can make this as part of your calendar, but make sure those dark, dark documentation is overdue. So this is pretty straightforward to comment is mostly about documentation. It takes a long time. But if you work with your TSA, a lot of times they are ready-made templates already available. So you should be able to save some time with this. Just like I mentioned, you have to have a written compliance and security policy. The charter should be here for your service provider. You need to make sure I have a quarterly review to make sure that everybody is following the requirements everybody has signed off on the security of illustrating. And lastly, a very important risk assessment, PCR requires everybody to perform an annual risk assessment to identify critical assets. Scratch vulnerability is okay because this will help you to prioritize risks. And if you take a proactive approach to this, this really pays off in the long run. This is something she says something people think this is like a formality afternoon every year. But if you do it properly and you give it the proper time and respect, I can tell you risk assessments can identify so many issues proactively, much more before then the auditor finds that I want to flag this before, because risk assessments are going to become very, very important in the upcoming revision, which is PCI DSS version for it. If you do, if you have not focused too much on this, this could become a problem for you. So definitely start focusing on this. I'll talk about it more in the future class, in the next class which I have, which are about PCI DSS 4. But please do not take risk assessment, likes art form formality that you have to do and forget about it. Okay? So really focus, there's won't copy paste what you did last year to the next year and really focused on it and it will definitely pay off in the long run. Okay, so that finishes off your lawsuit coming guys, I hope this was useful to you. Let's go on to a very important topic which we have to cover, which is compensating controls. That is what happens if you're not able to meet a requirement. I see you in the next class. 18. Compensating Controls: Hi guys. So very, very short class, but this is very important. So now you've covered all the trails requirements, right? But what happens if you can't miss a PCI requirement? Okay? Like, let's take an example. You have to apply patches within 30 days, right? Critical patches. What if we can't apply a patch? Or what if you can't implement file integrity monitoring? What happens then? So there's something called a compensating controls. This happens when a, when a party cannot meet a preset apartment, you do illegitimate reason. It's not there being lazy, maybe the system does not support it or they don't. There are some constraints there. But what you do is you put another controls there, okay? Maybe you can't patch it. But you have 24-seven monitoring and you have other tools which will alert you immediately if somehow somebody tries to exploit that patch. Okay? So it really depends. Data is really like an art. What do you say? It's like you have to sit with the QSEN, make him understand what you've done, how you've mitigated that risk and vary the effectiveness of this. It changes from environment to environment from few aesthetic USA. Okay? But remember that you really have to be good in risk assessments to do this. So the compensating control in short, you have to fill out a sheet to shore to the auditor. What does it look like? It's like this one. Like I took the example. This is, you have to finish this out. You have to show what are the constraints, okay, why you can't meet at a comment like why can't you patch this quarter or why can't you like implement file integrity monitoring, then you have to have the old definition. What are the controls you've implemented? What are the objective of this controls? What's the risk that because of the patching not be there or something, And how has the auditor validated dense compensating controls? And how are you going to make sure that nobody tampers with those controls? So this is something that we'll review. And you have to really satisfy him to make sure that this is not just you've just something you've put in there to escape? No, this is something you've thought about and you implemented it properly. So please, compensating controls are very important topic. They are going to be not replaced, but they are a new way of doing things which is coming up, which is called the customized approach. I'm going to talk about it in the PCI DSS version for module. But just know they're compensating controls are what you have to do if you're not able to meet a particular requirement. And there are other ways of doing this which are coming up. Okay guys, so this wraps up the requirements module. I hope you enjoyed it and I hope you learned a few things and see you in the next module. Thank you. 19. SAQ and its types: Hi everyone, welcome to this lesson. Now that are going to be talking about the types of self-assessment questionnaires you've completed the PCI, DSS requirements, right? And just to quickly recap, the SAQ, the self-assessment questionnaire. It's like a validation tool for merchants and service providers to report the results of the PCI DSS assessment. If you are not required to do a full audit and submit a ROC, write a report on compliance. It depending on the way you process transmitted stored in data, they are different SET was that he must fill out. Like if you don't have like an e-commerce store, you might be quite to fill out something else. Or if you have any constant, It's something as if you're required to. The way you're processing data, it changes the type of vesicular. I've seen sometimes people get confused when it comes to execute. So the types of them because they're like around it. So I thought it would be good to get like just give some guidance on what type of SEQ is required for what type of scenario. So let's take a look at this. Just a quick recap. What is the basic you guys just to let you know, if you're not required to do a full audit, you're required to fill out an SAQ is usually for small merchant service providers. It's a series of questionnaires. It can be quite long. It's like the runs up to sometimes 87 pages, yes or no questions. And like I said, there are eight times, so basically use and depending on what type of environment you have, you're going to after select that one. Don't try to do it yourself the first time you can check with the USA or your payment plan. And they asked them what sort of SEQ am I supposed to fill out. So it should not be difficult provided you do your homework properly. These are the types of SKUs. I'm not going to read off a boring table. I know nobody wants me to do that. But these are the terms around eight type of audio call acyclic. So let's take a look. Much the self-assessment questionnaire. So what does the PCA guidance says? This is if your company has completely ourselves the collection and processing of cardholder data to PCI compliant third-party service provider. If you're not doing anything regarding cardholder data, you've completely outsource everything. So usually what happens is, I've seen this in scenarios where there's a complete e-commerce, much like an e-commerce environment where you're not doing anything on your website when the user clicks by these, like they get redirected to somebody else and that is where the transaction happens. And you just come back and say, Okay, that transaction has been successful. You don't have to do anything. For these type of scenarios. I've seen a SAQ is most suited as a complete, complete outsourcing. And it's like you don't store process transmit card related at any point in time. So this is for the basic QA, is usually the best fit for that scenario. There's another one called SQL API. So again, there's an e-commerce environment and the collection of processing of cardholder data has been outsourced okay, to a PCI compliant third party. So it's similar to the previous one, but in this one, what is happening? You are controlling the flow of cardholder data to the service provider. Okay? So usually what happens customers, they want more customization on the environment. So they control how the website is sending cardholder data and they are what you call. They don't take cardholder data, but they do control the flow of how the users get redirected to the website for payment collection. Usually this happens when they don't like the third party is what you call default pages and they want to have some customization done. So for these sorts of scenarios where secure API, that is usually the correct choice for your compliance documentation. Okay. Questionnaire B. B. These are those four that mail-order, telephone order transactions you'd like bank approve payment terminals. They're usually does analog lines, not analog phone lines. So they don't have any electronic processing and storage of data. Basically, we are talking about phone lines and they're not connected to even voice-over IP like analog. You'll see these merchants which are usually kind of cut off from the world like far for every merchants they just feeling for what he called the terminals and the payment terminals which are connected to the phone lines because they don't have Internet connectivity and they don't have anything like that. They're using that for those sorts of questions. Seq B is the one being used. I haven't used it. I have not seen it being used that much. That is the scenario where you will use this one. What is SEQ BIP? So in this one, again, we have the mail-order, telephone order transactions and payment terminals, but you're also receiving it in person. And it's connected to an IP network. So what do you call? It's not, it's not like an analog connection here you have an IP connection. Suddenly they might have access to the internet or wireless like that. Usually results in faster processing times, but then you need to put in more colors, are more security controls in place, and you need to segment of that network, okay? Because in this case the payment data is being transmitted over the network. So this is where the BIP comes in. If you can check it from the name. Ip. In the previous 22 is just analog phone lines here. It's an IP network. Okay. What does essay Q. C. Okay. Yeah, So in this one, you're receiving the cardholder data in-person, and again, mail-order transactions and you're using a point of sales system. What was that in the previous one. So that was like a payment terminal of justice. But here you have a point of sale terminal and that does not show the full card data. Remember remember where he talked about, right, storage of card data. So usually here you have those cash registers and they're connected to a back of a server. And that server might be hosted outside. But this is what the scenario. So head, you have like a Point-of-sale terminal that is not configured to store the fuel card data. And you have like an accurate to about a back-end server. Usually, I've seen those retail merchants using those big cash registers, right? This is where the SAT usually applies to C v, t. And for this one, even just from the name itself, you can say this is like a Verbit's virtual terminal. So in some cases you don't have a physical terminal. Okay? So here you have a purpose virtual terminal. And usually there's like a workstation which is dedicated in a particular place for processing payments. Sometimes when you allow your customers could do self-service and all that, right? This is where this is coming in. Okay, P2. So P2, P0, P2P stands for point-to-point encryption. So this is a standard which the PCI council has introduced. The, all the, all the data is encrypted from the point of capturing kill the point sends back for processing. So if you're a merchant, you don't have to do it. It's a completely offshore standard, but it reduces the scope of Piaget compliance. I've seen a lot of service code isn't bank offer this as a solution to merchants if they want to reduce the complexity, we don't want to have the hassle of worrying about payment and all that. Usually has to have special terminals dedicated for this. Okay? Then the transaction gets back to send back to the service provider for decryption and processing. So here, the main thing is we're using validated point-to-point encryption terminals. Okay? If you're using that, then this is a questionnaire. This questionnaire is much more simpler than the other ones, and that's the whole point. You want to reduce the compliance burden. You don't want to fill out those big, big question is this, and this becomes like an incentive for merchants to adopt this type of solutions. Okay? And now we're at the last one, which is the security much and so anything which does not apply to the previous criteria. And you don't want like, you're storing cardholder information and you don't use like a point-to-point stratified system. And basically any of the previous criteria does not apply to you as security. A lot of times I've seen merchant start with this because in this scenario, you're just taking the safest approach and just fill up their security because they don't want to go to the hassle of finding out what exactly like what are the fine-tuning data secure comments, they just fill up their security and the submitted. So this is applies to merchants and the service providers, also service provider. I used to be in a service provider for many, many years. Basically, it's not like a payment went like Visa, MasterCard, and you're not like a bank, right? But you are conducting your processing, storing, transmitting cardholder data on behalf of a bank offer merchant. So you basically offload everything, okay? Usually service providers, they get the full audit done because their environment is much more critical. You are you don't have data. Entity, you have beta. God knows how many entities are hundreds of banks, hundreds of thousands of merchants. So they usually do the full audit, but you can fill up their security. You should check with your permanent run and find out what it thinks is applicable to you. I would recommend if you are a service provider to do the full audit, don't rely on a secure key because it's not independently verified. Tried to do with go over the full audit always. Especially if you're a service provider. Okay, guys. So that closes the body called SEQ part. And I'll see you in the next module, which is very important, which has to do with the key changes in their version 4 of the standard. Thank you guys. I'll see you next lesson. 20. PCI DSS v4 and the key changes: Hi everyone. Okay, So we've reached the final chapter, which is the final one and which is the most forward-looking, which is the key changes in the version 4 zeros. So you might be aware that version 4 husband released into the public. This was a result of various efforts by the PCA council to update the standard. You don't make it more relevant. You can the reason I didn't I made this a separate section is because I want you to keep calm and keep focusing on your compliance efforts with the current version of the standard. At the same time, take some time to read and plan for PCI DSS version 4. Do not try to implement 4 right now you will get older because it is a major change. It is not something you can just start implementing right away. You need to fully understand what the changes are and how they will fit into the larger picture. Okay guys, so just a cable, you don't get all excited and start implementing right away. So what are we talking about? First of all, why has the standard change? So if a major revision happened, well, that might be a question. You might say, why did the PCA console do such a major rewrite of the PCI DSS. And the PCI DSS is a fairly mature standards for reasons they want to make sure that it needs a security standards, the needs of the payments industry, right? Because technology is evolving. We didn't have cloud before and other things before, right? And they've made it more mature from a security perspective. Security was not so much like what we call link here to risk management and mature processes. Companies now have innovative technologies which they can meet the intent of the requirements. You remember what I told you before? Try to understand the intent. Don't try to just memorize the standard, okay? Because that will not help you. And it gives you a lot of flexibility, also support of additional methodology. So they've made it much more flexible, much more open-ended. You can have lots of discussions with the QS is just remember, but very, very important. But guys, you need to focus on risk management as a methodology. Don't just be technical. Understand how it is. How does management works? If you don't know already. The key timeline, just to me to make sense of this diagram, the standard, the new one remains option until March 31st, 2024. And then this version three will go the older version, 3.2.1, it gets retired. After that, your audits are going to be start happening against PCI DSS version 4.2 only. Some of the new requirements, they're also not become mandatory until March 31st, 2025. Until that time it will be considered best practice. Okay. So many comments have been added to the standard, their future dated March 2055, like I said, in order to allow the new processes to be developed before I need to do comments can be enforced. So that's the reason I focus. I made it a separate standard because I didn't want to confuse you, right. I'm going to be focused on the major changes. So you have until 31st, March 2024 to understand and roll out the new requirements to the standards. And the QS is we're going to be coming. They can start auditing against the standard. Okay. Now two years seems like a lot, but they're really not dice. Please don't underestimate just how quickly time passes by and how quickly things change. You will get a strong cup. Other things. I'll teach you how to focus on whatever things to focus on and what are the things you should be doing, okay? Okay? So the first thing is that it's not that big of a chain, but scoping. So previously scoping, if you look at this kind of scoping was like it was starting to any initial discussion. It was in the introduction. It wasn't part of the requirements of the standard, but now the council have moved it into the requirements standards. Okay? And they've made it a traceable requirement effective immediately for version 4. So this is not like future data into other ones. Okay? So you will need to document your scoping exercise. If you're a merchant, you have to do it annually and if any changes happen or something like that, if you're a service provider, you will need to do it every six months. Or a patron is data structure data. So if you're a merchant, make sure you're doing your, you should be doing you're scoping anyways, start documenting your scoping exercise on an annual basis. It might be a bit of a hassle first time, but then it becomes easier. If you are a service provider, know that after March 31st, 2025, you need to be doing this after every six months. But after any major changes, like something changed in a manner that people's systems processes, you need to take into that into account. Okay. What else is there a storage of sensitive authentication data? Well, you shouldn't be storing sensitive authentication data, but after authorization. So we already discussed this before, right? Some organizations. So before the transaction is authorized, they do keep store the data temporarily. It was recommended that okay. You storing it for a minute, half an hour, whatever it was recommended, you should try to encrypt a protected right. It wasn't required. Well, it's no longer it won't be a recommendation after March 31st, 2025. What has happened is they've seen a lot of attacks. Attackers can try to compromise it vanished within memory, this temporary storage, they try to compromise it. Okay. So even if you're storing it for five-minutes, then they will know and they try to get it from memory. So you will even within memory, but then temporary storage, you will need to encrypt it. Okay. So just keep this in mind. And this wouldn't be a recommendation after March 31st, 2025. Okay. What else is there remote access. So if you're using remote access into the cardholder environment, okay? Then you must prevent the copy and relocation of cardholder data case. Somebody can copy paste this data out. This is this has been mentioned before in the standard recommendation is going to be a requirement. A lot of companies have seen what they used to do things to put a policy around this. But it now it needs to be enforced by a technology, okay? Usually, it just should not be too difficult. Usually if you have settings in your remote access software that prevent copy paste or you have DLP functions, okay? So depending on what you have and your current process despite be very easy, it might be a bit difficult. You might need to invest in a few more technology is all you need to put some controls around this. So just keep this in mind for this requirement. Okay, Web Application Firewall. So this is pretty straightforward guys. Remember, I told you that you can have Web Application Firewall or application painters. It was a recommendation. Well, now you need to have it. It's no longer optional. Okay. You need to have a valve after March 21st, 2025. Honestly, you should have a rough like I told you before, don't try to make do with secure coding reviews or upset, you should have a web application firewall by default. So if you're not doing this, start doing it right now, start budgeting for it. Skips on payment pages. So this is quite enough interesting. This used to be like a supplement from the PTA Council. This must not initially not part of the PCI standard. If you have e-commerce pages with scripts which are running, you have to now what do we have to do if your scripts are being loaded? You need to make sure that they're authorized and nobody can tamper with those scripts. And you have an inventory of all the scripts which are running. Why? Why is this happening? Because phenomena called skimming payments, skimming, what attackers used to do it is to compromise these payment pages and inject their own scripts or tamper with the existing scripts. Okay, so it's like you're entering your data, but that data is actually being entered on attacker's page and the pH is genuine, right? But they just compared with the script. So it's not even like a phishing attack because the URL will remain the same. That's why now this is a very good comment personally because e-commerce has started. It's like almost e-commerce is slowly taking over the physical world. And you should have these controls. So definitely take a look at that. If you have an e-commerce engine which has come spring loaded, start taking a look at the how you're going to be implementing this. And you can take a look at the e-commerce supplement from the PCA council. That is also a very good document that goes into more detail. Okay. What else is the MFA requirements? So MFA has been expanded a little bit. So what do you call now if we received was to be for admin and remote access right now it's going to be expanded to cover access into the cardholder environment. Okay. So one more thing. So they've added a detail. It can be a little bit tricky. So what is this that previously what used to happen? Usually in most MFA solutions you will put in your user ID and password right? Click Enter, and then another screen comes up. Then you have to put in your MFA code right? Now. All of this has to happen at the same time. So it's not like a first-time user ID password. And then they enter the other factor right under the token. Now, they have to be happen at the same time and they can't tell you which way the user ID password field into token fail. You can't reveal that information. So most vendors should be updating it. But something to keep in mind. Other thing was finally good view. So like I told you before, the PCI DSS password requirements used to be like seven. Now they finally upgraded it to 12. They should not be a bigger issue. But if you have some of your systems which needs upgrading, maybe you need to change the password policy or something like that. Keep that in mind. A minor issue is they changed, they've removed the references to firewalls and routers. Now they mentioned it in effect, security controls and anti-malware. They've made it more in sync with what the industry terminology is. Most companies now they don't use a construct of antivirus reuse something anti-malware. Okay. What else is there? Authenticated scanning. So internal via scanning it now has to be authenticated. It now it means you can just scan your ports and services and call it a via scan. So if you have like a server or something like that, usually what you do is you give it a you will provide the appliance or user ID and password. It'll log into that machine and do a complete scan. Okay, get ready for a much larger report if you're not doing this already, honestly, we should be doing this already. You should always be doing authenticated scanning. Okay, but if you're not and when you turn this on yoga, because now it is going to be looking at, is going to authenticate and actually do a much deeper scan. A lot of things will come up, Okay guys, so be ready for the start doing this right now. Important part of this new requirement is that the, the credentials you enter, they have to be entered and stored securely. Okay. So take a look at that. If you have something like a password vault or maybe you can integrate a lot of these solutions they do integrate with Password works, so you don't have to manually enter it and store it anywhere. Okay. Just keep that in mind. Lastly, okay, the most, personally in my opinion, the biggest change has been the introduction of Customize Controls. So what used to happen? Like I told you before, if previously companies could not meet the requirements, they could propose something called a compensating control and use it to get around not meeting their comment. For example, you can't encrypt cardholder data legacy system located, put another controls. And that is like a mitigating that risk. A lot of time curious is they do get asked the question, right. The auditor The companies have asked me, okay, we have a security but I can't meet the specific requirement, but I have secure controls. Okay. The response used to be okay because you can implement a compensating control, which is a temporary solution until you meet the requirement, until you finally fix this. Okay? So version four of the standard, they have tried to resolve this scenario by introducing this concept of customized approach. So customer companies that have mature security, okay? And they have other controls, they can meet the requirement in other ways. So it's not a compensating control is so much like a much more complex and a much more better way of meeting the requirement. Okay? So previous things, the previous way of doing it and it was called a defined approach. Pci has been implemented is called a defined approach. Now you're going to have a separate section called the customized approach, okay? And basically you're going to be proposing a new control, that means the requirements. So you're not compensating you're not compensating for a gap. Okay. You're putting in a new that is meeting the PSA objective and that is of course, it'll be assessed by the PCI auditor. This is a great solution for companies who cannot directly meet the requirements, but they have mature risk management practices in place, and they have innovative technologies. Okay? How would it look like? It's a little bit like this. So the old one that defined approach was, well, I have a PCI requirement and I cannot meet it, so I'm going to put in a compensating control. I'm compensating for a lack of control and I'm documentary get short-term. The auditor used to say, Okay, we accept it now maybe after one year, five years, we have to implement some solution. Okay, now, I have a pizza I cannot meet, I have a customized control, I've made it and it meets the objective of the requirement. The PCI standard is saying This XYZ should not happen, cognitive should not get stolen. Okay, I'm meeting the requirement and I've implemented this. So you can still do compensating controls, but these new approaches are much more strategic way of meeting it. So like I said, just remember you're not compensating like in a short-term way. Now you're implementing a long-term approach for properly securing your PCI requirements. Okay? So this is how the standard is look like so that they can take a look at it and style it. You don't have to start implementing it right away. And it might seem a bit overwhelming. So I'm gonna give you the advice for that award. What to do about this, how to focus on it, okay? And just to be clear guys, this management and documentation is a big focus on the new strand. So when you're doing your activities, you need to do a targeted risk analysis of why you're doing stuff. You need to make sure those are signed off. You if you put in customized controls, they will need to be signed off by your Chief Risk Officer or CEO. Somebody senior, okay. This is not something like I mentioned before. Pci DSS is not an IT project. But in the new one they have much more emphasis on that. That you need to have clearly defined roles and responsibilities. Customized controls need to be signed off. And targeted risk assessment needs to be done. Don't think you can just make an Excel sheet with one column saying, I've done a risk assessment. No, it won't be accepted like this. How do you do it? 21. How to get ready: If you know Michael Lumia earlier before about gap assessment, same thing. Okay. What are the most important things to focus on right now? First of all, read the PCI DSS version for Standard, get familiar with the biggest changes that can impact your compliance process, then start making a gap assessment okay? To me, implement changes. Probation for input. You have time, start early and you won't have problems during your conversation. Okay, don't forget to keep implementing your current standard, 3.211, but start thinking about how you're going to be doing risk assessments. More like more formal risk assessment is documentation that required, okay? And most organizations will need to add processes and gain skills to do this correctly. Find out what sort of certifications are there. Start concerting with you. And the cube, even though they can't conduct a 4 assessment right now until they have been formally trained. But it's going to happen very, very quickly. Okay. But kind of get us this will give you advice, but please do not wait until 2024 to begin switching over to PCI DSS for fido, spread your efforts over the next couple of years and you will be just fine, okay? Okay. Just remember these things. Even have an increased focus on documentation. Targeted risk management started investing in this tree and there are many, many certifications for risk management. You can look at those certifications. I'm not going to nominate any specific one. You can take a look at that. It would be a great idea to invest in getting certifications for and risk management. These are not technical, but they will teach you the methodologies for doing proper risk assessments. Okay guys. Okay, so this wraps up the version 4. I hope you understand now the big changes which are coming in, how you can go about doing it. It seems like, like I said, two years, it seems far away. It can be very short, it can be very long. Spread your efforts out and have a proper action plan in place and you should be just fine with this. Okay, guys, I hope that was useful. That wraps it up and thank you for attending this training. Now we're gonna move on to the conclusion. And in this course, thank you so much for staying with me during this time. 22. Way forward : Okay guys, congratulations on reaching the end of this course. I hope you found it interesting. It wasn't boring. I tried to make it as practical as possible and give you as much actionable advice as I possibly could for the class project. I just want to remind you, remember we talked about Essex. I want you to collect an SAQ, make it as simple as security or anyone's for a physical on e-commerce merchant that will really teach you about the different standards, different departments. It'll give you a good idea of what other comments also, fill it out. Let me know how you go about it and if you face any challenges since reach out to me and let me know. Okay. What else can you do, guys? You can take a look at the PCI ISA program, internet security assessor, that's an internist certification which you can do for your company. It makes you almost equivalent to what USA, but you are not, you're, you're not like at usaid, you over your own internal auditor, but it gives you the full training for how to conduct these audits. If you're interested in this definitely which it out. Like I said, don't wait for the audit. Please start implementing this knowledge right now. And you will definitely this is the best way to retain that knowledge or say, one actionable tip I can give you create a PCI document or manual for your company for the e-commerce, how to implement these requirements daily rate for your organization. And you will learn a lot, believe me, you will learn a lot about your company and how the different comments are fitting in. And most importantly, start gapping against the PCI DSS version 4 is 0 today, don't put it off for next year or the year after that, otherwise, you will have serious problems. Start actioning it today. Take the knowledge I've taught you and present it to your management and these are the things we have to be doing. Okay, guys, that wraps it up. Thank you very much for attending this training. Please do leave a review. If you thought this training was useful, wonderful, please let me know. If you caught this training was like the worst thing you've ever attended, please let me know so I won't be offended. And I will use that to improve on its training or take. If you are interested, you can reach out to me on my channel, like the cloud security guy and other courses I have here, okay, do connect with me on LinkedIn. I'm happy to help you out if you have any problems. Okay, And that reaches the end of this course, guys, thank you so much. I hope you enjoyed this training as much as I enjoyed making it. Take a look at my other courses and do reach out to me. I wish you all the best in your PCI DSS journey and see you in other courses. Thank you very much and good luck.