"Fundamentals of PCI-DSS" Course Preview: Requirement #3 (Protect Stored Data)

🎓 FULL "3-in-1 Fraud Prevention, Dispute Resolution, PCI-DSS Masterclass" Course 🎓 https://bit.ly/fraud-dispute-course Including: ✅ 11.5 hours of video ✅ 112 lessons (with PDF slides + quizzes) ✅ Instructor support with Vasco via message 🎥 ALL Preview Lessons on YouTube (Single Playlist) 🎥 https://bit.ly/pcidss-yt ------ Video transcript (possibly truncated due to char. limit): Let's talk about Requirement #3, "Protect Stored Data". It's not just about data security in your database - although it also is about data security! - with strong encryption, key management, key lifecycle, and so on - but it includes other topics, such as, for example, not storing data that you don't need to store in the first place, or purging data that you don't need anymore or, for example, never, ever storing Sensitive Authentication Data (SAD). But there are other topics that we must comply with. Let's take a look. Requirement #3, with the official name of, "Protect stored Cardholder Data", is very straightforward, and it's all about making sure that your stored Cardholder Data is properly protected. It's about both making sure that the encryption used is strong by nature, but that it's also properly managed itself. For example, with proper key management and key lifecycle. It's also about protecting the Personal Account Number (PAN) stored. Remember, stored data are not just digital data. They're also receipts on paper, logs on paper, or any other medium that contains Cardholder Data (CHD). Sub-requirements of Requirement #3 include: First, limiting the storage and retention of card data to the essential. The most secure way to store data is to never have to store it in the first place! Then, not storing Sensitive Authentication Data (SAD) - such as the CVV number, or the PIN. Period. Then, 3.3, is about masking stored Personal Account Numbers (PANs). Usually, you can show the first 6 digits - also known as the BIN number, or Bank Identification Number, because these are related to the bank that issued that card - as well as the last 4. Everything else in the middle, that's hidden, is the unique part. If you've ever obtained a receipt, for example, at a restaurant, and the credit card number is shown, but you just see a lot of asterisks in the middle, and you see the first 6 digits and the last 4, this is PCI-DSS at play. Then, 3.4 is rendering the Personal Account Numbers (PANs) unreadable on all communication channels. Encrypting it, masking it, etc. Just making sure that, if an attacker intercepts your communication, they can't read the numbers. 3.5 is about procedures for key protection. The keys used to encrypt the card data. And 3.6 is about procedures to manage those keys. The cryptoperiod, having a key custodian, maybe split knowledge, and so on. And finally, 3.7 is the customary "document and enforce" all of these policies and procedures. So, all of these points must not be done informally, but instead with written-down policies, that are put into practice. So, first comes requirement 3.1. Cardholder Data (CHD) must be limited in terms of what is stored and what is retained. And note that this process covers both logical and physical Cardholder Data (CHD). So both databases, but also paper receipts or copies that contain card numbers. And it also covers for how long it may be kept, and how it's disposed of. So, first, you need a data retention policy. What data are kept, and for how long. And this must be what happens in reality. It's not worth it to have a policy that says you store numbers for 30 days, if in practice, they are in the database for years, which is why you also need to clarify how the deletion is done. So printed data can be shredded or burned, and digital data, such as hard drives, can be securely deleted by zeroing out the deleted data - or in the case of physical destruction, they can be demagnetized, shredded or others. But the key here is: Use common sense. Have a procedure And this policy must be frequently reviewed, at least quarterly. As with many other things, this is because technology changes, your infrastructure changes, and your data retention policy needs to keep up with those. 3.2 is very simple: No storing Sensitive Authentication Data (SAD). Period. Remember. What's usually on the back of the card, such as the CVV code, or the magnetic track, or the PIN number, should never be stored. It's not needed. It can be transmitted, naturally, but it is immediately deleted afterwards. You will notice that with a retailer, like Amazon, when you add your credit card number, it asks you for the number and expiration date. But it doesn't ask you for the CVV. And then, when you go to pay, it asks you for the CVV, in real time. Unlike the rest of the data, Sensitive Authentication Data (SAD) are never stored. Just used in the moment. But now here's the key: You can't just say that you don't store it.