3.5 Requirement 3 Part 1

00:00

welcome to the side. Very D mystifying PC idea says compliance Course.

00:06

This module will focus on the goals of the P C I D. Assess and the requirements associated with them.

00:12

This video introduces you to a requirement 3.1 through 3.5.

00:16

We will talk about some of the requirements associated with protecting cardholder data.

00:22

The learning objective of this video is that explore how to satisfy requirements around protecting cardholder data and ways you can satisfy the P. C. I. D. S s requirement 3.133 dot by

00:34

requirement three is around the protections us A. Merchant need to have in place when dealing with card data.

00:40

Mechanisms such as encryption, truncation, masking and hashing should be leveraged to protect cards from an intruder.

00:47

You should also only store and maintain this data if it is absolutely necessary.

00:53

Which leads us to requirement 31

00:56

Onley. Keep this data if it is necessary and maintain on lee the minimum data needed.

01:02

You should also have in place policies and procedures around the retention in the disposal of cardholder data.

01:08

Requirement 31 states that the merchant must limit data storage amount and retention time to that which is required for legal, regulatory and or business requirements.

01:19

You should implement specific retention requirements for cardholder data and established processes for secure deletion of data When it's no longer needed.

01:27

As a merchant, you must continually conduct a quarterly process for identifying and securely deleting stored cardholder data that exceeds to find retention.

01:38

This quarterly process can be either automatic or manual.

01:42

An auditor will come in to examine all of the policies around these requirements and confirmed that the relevant personnel are all trained on the policy and execute procedures to align with them.

01:55

The requirement, Group 32 states that you are not to store sensitive authentication data after authorization.

02:01

It doesn't matter if it's encrypted or hashed.

02:07

Requirement three dot to 3.0.1 mandates that the merchant does not store the full contents of credit card track.

02:14

The track is a magnetic strip on the back of a card or the chip that's embedded in the card.

02:19

An auditor may expect logs and databases to ascertain what card information is being maintained after a car has been authorized.

02:28

Now, requirement 3 to 2 mandates that we do not store the card verification code or value after authorization.

02:36

The card verification value code, or what could be called the Cvv cvb to see VC TO or C I. D is the 3 to 4 digit number that is printed on the card and use for card, not present transactions.

02:51

Encrypting or hashing these values and then storing them still about violates this requirement.

02:58

There shouldn't be any reason for merchants to maintain this information after processing a payment.

03:02

It should not be stored because if a cardholder data is compromised,

03:07

then the attacker would be able to make payments remotely.

03:12

The code is not needed for card on file or recurring transactions.

03:15

Merchants and service providers should contact their acquirer or the payment brands directly, as applicable

03:23

for guidance on how to process recurring or card on file transactions without requiring the transmission or storage of prohibited data.

03:32

Requirement 32.3 is in the same name

03:37

As a merchant, you cannot store any data that facilitates the authorization of transactions.

03:42

The merchant is not to store the personal identification number, pen

03:46

or encrypted pin block after authorization.

03:50

Encryption or hashing does not satisfy this requirement.

03:54

Requirement 33 is one that most of us have been exposed to

04:00

whatever. You set up auto pay on a website and you go back to it. You'll only see let Fast. Four digits of the card that you have entered is displayed

04:09

even on the merchants back in systems it should be office skated to the majority of the staff.

04:14

This is centered around the mandate that merchants must mass the primary account number Information as one display.

04:21

The 1st 6 in the last four digits are the maximum number of digits that can be displayed

04:27

As a merchant, you must demonstrate the need for specified personnel with a legitimate business. Need can see. This can see more than the first sticks or last four digits of the pan.

04:38

The auditor will look to see that this is documented somewhere.

04:44

Requirement 34 mandates that merchant surrender the primary account numbers unreadable anywhere where it's stored,

04:50

so this includes any backup media logs, USB drives or anywhere else.

04:57

This could be done via one way. Hash is based on strong cryptography, truncation, index tokens and pads.

05:03

A common question is, what about Pan and Memory

05:08

PC? I does not require that this requirement be applied to pan and memory,

05:13

but it does require that controls be put in place to ensure that memory maintains a non persistent state.

05:18

So, for example, if swap files or temporary folders are used, it needs to be purged or have correspondent controls that match PC I requirements applied to it.

05:31

Requirement 341 states that if a merchant is using disc encryption,

05:35

logical access must be managed separately. An independent of the native operating systems authentication and access control mechanisms

05:44

so you can't use local user account databases or general network log in credentials.

05:49

Basically, the authentication credentials that can decrypt the disc need to be separate from the credentials that log into the system.

05:57

This makes it so that Attackers need to compromise two sets of credentials to access data

06:02

as a note. Using whole disk encryption makes it difficult to meet PC I. Requirement 3.4

06:10

Because once you've brooded the system and mounted the drive, there's a transparent data encryption that it's accessible to the end user.

06:16

Many disc encryption solutions intercept the operating system, read, write operations and carry out the appropriate cryptographic transformation without any special action by the user other than supplying the use the password or pass for eighth upon system startup.

06:32

If you're using whole disk encryption to meet requirement 3.4 dot one, be prepared to have a conversation with your assessor about the controls. Your music.

06:44

The requirement Group 35 is all around the documentation and procedures put in place to protect keys usedto secure stored cardholder data against disclosure and misuse.

06:55

As a merchant, you need to make sure you haven't the infrastructure in place to maintain the security of your cryptographic keys.

07:03

The 351 requirement is mandated for his service providers only.

07:08

They need to maintain a documented description of the cryptographic architecture that includes the details of all algorithms, protocols and keys use for the protection of cardholder data, including key strength, an expiry date,

07:21

description of the key usage for each key

07:24

inventory of any hardware, security modules and other secure cryptographic devices used for key management

07:32

for crime. It 352 is an easy one.

07:35

Always limit access to everything to the fewest number is possible.

07:41

The same is true for cryptographic keys.

07:43

Restrict access to cryptographic keys to the fewest number of custodians necessary

07:47

again, the auditor will look to see how you've defined this group and maintained access.

07:55

The 353 requirement is to store secret and private keys used to encrypt and decrypt cardholder data and one or more of the following forms at all times.

08:05

It should be encrypted with a key encrypting key

08:09

that is at least a strong is a data and data encrypting key and that is stored separately from the data encrypting key

08:16

within a secure cryptographic device such as, AH hardware, security module or Pts approved point of interaction device.

08:24

And as atleast two full key length components are key shares in accordance with industry accepted method,

08:33

merchants need to protect your keys from unauthorized access and prevent them from getting the information contained in the keys, even if they happen to, even if they do happen to obtain them.

08:43

Basically, the keys that are used to decrypt your data need tohave. Strong security controls apply to them and are never in clear text.

08:52

The 354 requirement is just simply store your keys in its few locations as possible.

08:58

As your keys proliferate throughout the environment, the security of them is inversely impacted

09:05

most only have the number of house keys that they need necessary for the people to get in and perhaps the spare key.

09:13

The same type of thinking should be applied to your crypto keys.

09:18

In summary, we discuss all of the mandates associated with PC I requirements. 31 through 35

09:24

we went through some of the protections that have to be in place for protecting cardholder data

09:31

and F for quick quiz.

09:33

True or false.

09:35

After authorization, merchants may contain CVB data to facilitate recurring payments.

09:45

Merchants air not to maintain cvv or pens after authorization.

09:52

The challenge for full disk encryption is a access to encryption technology.

09:58

Be boldness cannot be really encrypted.

10:01

See separation from user, password and decryption, password

10:05

and D. The encryption is not strong enough.

10:13

The authentication credentials that can decrypt the disc need to be separate from the credentials that log into the system.

10:18

This makes it so the Attackers need to compromise two sets of credentials to access data.