by
Bookmark

Timeline for PCI DSS 4.0: The Third Requirement and Protecting Stored Data

While having only 12 requirements might make PCI DSS seem like a simple standard, each requirement is incredibly important and, if you aren’t paying attention, can specify practices you aren’t implementing. In the case of the third requirement, this could mean that you’re not actually protecting the most critical data that is in your possession–that is, the private and financial information of your customers. 

Therefore, if you want to avoid scandal, fraud, and the loss of your customers’ trust, you must follow the third PCI DSS requirement. With the continued launch of PCI DSS 4.0, we’re now moving on to a discussion of the third PCI DSS requirement.

 

What Does it Mean to Protect Stored Data in PCI DSS?

“Stored” data is any data that is considered to be “at rest.” Any data saved in a hard drive, cloud storage system, removable media, or mobile device. 

This is an important distinction from protecting data transmitted (or “in transit”) because stored data is positioned in a way where malicious or accidental breaches can occur. 

 

What Are Common Threats to Stored Data?

Because stored data is “stationary” or available (ideally only to authorized users), it remains vulnerable without the proper safeguards. 

Some of the most common threats to data at rest include:

  • Brute-Force Attacks: Some simple and uncommon attacks utilize brute-force authentication attacks, zero-day vulnerabilities, or unpatched vulnerabilities to access sensitive systems and cardholder data.
  • Insider Threats: If someone inside a company is a potential threat (due to intended criminal activities or revenge tactics stemming from disciplinary action or termination), they may have unfettered access to cardholder data or at least the ability to escalate their permissions to view cardholder data.
  • Phishing Attacks: The most common attack today is a phishing attack, where a hacker tricks an employee to turn over authentication credentials via email, SMS or other communication technologies. With such access, a hacker can access any information available to that user, often without administrators knowing about it.
  • Accidental Disclosure: Sometimes, people just see something they weren’t meant to see. An unobfuscated card number could display on a workstation monitor, free to view for any otherwise honest employee. And, while accidents happen, it’s not secure or acceptable to forgo the prevention of accidental disclosure.

 

What Is the Third Requirement for PCI DSS 4.0?

PCI DSS 4.0

The third requirement of PCI DSS is explicitly focused on protecting stored data at rest. To address the potential threats and vulnerabilities to consumer data stored in enterprise systems, this requirement includes provisions on proper data handling, data obfuscation, and the retention and deletion of data. 

These practices are perhaps some of the most important for risk assessment and management, as they require your organization to fully understand the full extent of the need for processing cardholder information, what systems will process and hold that information, and how to eliminate it extraneous data storage.

 

3.1 – Processes and Mechanisms for Protecting Stored Account Data

  • Procedures, Roles, and Responsibilities: As with every other requirement, the first aspect of the third requirement is a clear understanding of the hierarchy of roles, policies, and processes that will maintain responsibility over the practices listed below. This includes having clear documentation and auditing of these practices.

 

3.2 – Storage of Account Data 

  • Minimizing Storage of Data: To reduce attack surfaces and data theft or loss risks, PCI DSS compliant companies must strictly minimize the amount of data they store to meet business needs.
  • Data Retention and Disposal: To minimize data exposure, your organization should include clear data retention and disposal property. This includes creating policies that define precisely what data needs to be stored, where to store it, how to secure it, and what to do after it is no longer needed. Furthermore, deletion methods should be well-defined and their application, including processes that render such data unrecoverable.
  • Retention Audits: At least once every three months, your organization should audit stored data to ensure that any information that exceeds your retention policies has been properly disposed of. 

 

3.3 – Sensitive Authentication Data (SAD)

  • Eliminating Retention of SAD: No Sensitive Authentication Data will be retained after its use for authorization, even in an encrypted state. Once used, SAD must be rendered unrecoverable. This also includes data from any “track,” such as magnetic strip information, verification codes, and PINs.
  • Encryption: If SAD is stored locally during the authentication or authorization process, it must be encrypted with strong encryption.
  • Special Encryption Standards for Issuers: Any use of encryption to encode SAD should be distinct from the encryption methods used to store PAN. Issuers must follow the same requirements as other organizations when using SAD information. 

 

3.4 – Restriction to Primary Account Numbers 

  • Masking PANs: When PAN is displayed, it must be masked with no fewer than the first six digits of the account number (the Business Identification Number, or BIN) and the last four digits of the account number. Furthermore, masking should cover any digits that are not required for business purposes.
  • Remote Access to Systems Containing PAN: Any remote device accessing systems containing PAN must have valid authorization to see and process that information. They may not relocate PAN to unauthorized devices. 

 

3.5 – Secure PAN Storage

  • Rendering PANs Unreadable: PAN must be rendered unreadable anywhere it is stored, either through one-way hashing, truncation, encryption, or tokenization.
  • Special Encryption Rules: Disk- or partition-level encryption (as opposed to file-, column-, or field-level encryption) is only authorized for removable media. If used for non-removable media, it must be implemented alongside another form of encryption. Furthermore, encryption and decryption keys cannot be associated with user accounts, and security safeguards (authentication credentials, cryptographic keys) are stored under security. 

 

3.6 – Securing Cryptographic Keys

Your organization must secure cryptographic keys against disclosure. This includes using least-privilege principles for crucial access, utilizing encryption keys that are at least as strong as the encryption they protect, storing key-encryption keys and data-encryption keys in different locations, and minimizing the locations where keys are stored. 

 

3.7 – PCI DSS Cryptographic Key Lifecycle Management

  • Using Strong, Secured Cryptographic Keys: All encryption keys must use strong forms of encryption (at least 128-bit) and be secured using clearly-defined key storage policies.
  • Key Cryptoperiods: You must have a defined cryptoperiod under which a specific set of keys will expire, and no keys will be used beyond that period. A process must be in place to move from one set of keys to the next at the end of that cryptoperiod.
  • Key Lifecycle Management: Procedures must be in place to ensure that keys have a well-defined end of use, those that have been weakened or compromised and those that have been lost can be replaced quickly and efficiently.
  • Personnel Authorization: Encryption key custodians must acknowledge their responsibility in writing or through electronic signature. Furthermore, if these custodians manage clear-text keys, two or more custodians must have split knowledge of those keys. This split cannot be a two-part split, but one where components are split using secure cryptography or hardware security modules so neither custodian can determine the other part of the key by what they currently hold. 

 

Prepare for PCI DSS 4.0 with Lazarus Alliance

As we dig into the requirements of PCI DSS, you will see the increasing complexity and interoperability of the different technologies, policies, and practices you’ll need to deploy to receive PCI verification and maintain compliance. These practices aren’t just to complete a checklist. However–they are tried-and-true security practices that will help support your security efforts ten years from now.

 

Are You Thinking Ahead for PCI DSS 4.0?

Call Lazarus Alliance at 1-888-896-7580 or fill in this form. 

[wpforms id=”137574″]