Learn how to fulfill PCI Requirement 3.
|By: Jen Stone|
Here are some things to remember when it comes to complying with PCI Requirement 3.
Encrypt stored card dataWhen cybercriminals hack a payment system, they can’t steal cardholder data that isn’t there. That’s why it’s important to keep your system clean of insecurely stored card data. The problem is that unencrypted payment card data has a way of creeping in where you least expect it.
Stored card data must be encrypted using industry-accepted algorithms (e.g., AES-256). Unfortunately, many merchants don’t know they are storing unencrypted Primary Account Numbers (PANs). In the latest study by SecurityMetrics, 61% of merchants were found to store unencrypted PANs.
Some places that may be hiding card data unintentionally include:
- Error logs: often contain full card data when an error in card authentication occurs
- Sales departments: may have emailed or printed forms containing card data
- Customer service representatives: may take card numbers over the phone, have handwritten card data
- Administrative assistants: may have a spreadsheet containing an executive’s card number for quick access
Protect encryption keysNot only must card data be protected, but also the encryption keys must be protected. Leaving encryption keys unprotected is like storing your house key by leaving it in your front door lock, so it’s critical to use a solid PCI DSS encryption key management process.
Find stored card dataPayment card data can easily leak due to poor processes or misconfigured software. You must look where you think the data is, and then look where it shouldn’t be.
PCI DSS 3.2 Requirement 1.1.3 requires a current diagram for all card data flows in your organization. A card data flow diagram is a graphical representation of how card data moves through an organization. As you define your environment, ask all organizations and departments if they receive cardholder information, and determine how their answers may change your current understanding of your organization’s card data flows.
Here are a few questions you should ask when making a card data flow diagram:
- What device(s) am I using for transactions? A virtual terminal? POS system?
- What happens to the card data after a transaction?
- Is data encrypted? If so, when is it encrypted? Is encryption managed internally or by a third party?
- Do I store card data after it’s sent to the processor for approval? Do my logs inadvertently store card data held in memory? Do manual processes allow card data storage in notes fields or other unprotected locations?
- When does authorization occur? Real-time or end-of-day?
- When a transaction is authorized, what cardholder data is returned by the processor? Is it encrypted? Tokenized?
- Is card data backed up on my system? Are backups encrypted? Is my backup server at a different location? Does that location meet PCI DSS requirements?
- Where might card data be transmitted or stored in processes not part of authorization?
Assign the responsibility of keeping unencrypted card data off your systems to an individual or team. Have them define and follow a process of periodic data discovery cycles to recheck and ensure systems remain clean of unencrypted card information.
SEE ALSO: How Much Credit Card Data do You Store? (It’s More Than You Think.)
Additional tipsHere are a few more things to think about while fulfilling Requirement 3:
- Reduce your PCI scope: The less you have to secure, the better. Streamline your card data flows and make sure you’re only storing what’s necessary
- Segment networks: While not required by the PCI DSS, network segmentation keeps your cardholder data environment separate from the rest of your network, reducing risk
- Place an individual in charge of PCI compliance: Becoming compliant can take time and effort. Establishing responsibility for PCI compliance can reduce confusion and increase accountability
Need help with PCI compliance? Talk to us!
Jen Stone (MSCIS, CISSP, QSA) is a Security Analyst at SecurityMetrics with an extensive background in Information Security and 20+ years in IT.