"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.