Encryption Requirements in PCI DSS
Encryption has become a necessary part of data security. Best practices have us using encrypted protocols and tunnels, PCI DSS requires encryption of credit card data, and consumer privacy requirements mandate protection of personal information.
Within the PCI DSS encryption is required for the following items:
- Wireless (Requirements 2.1.1, 4.1.1)
- Non-console administrative access (Requirement 2.3)
- Data at rest (Requirement 3)
- Data in transit (Requirement 4.1)
- E-mail (Requirement 4.2)
- Passwords in transit or stored (Requirement 8.4)
This post outlines the requirements for each requirement but does not focus on compensating controls or implementation strategies.
Wireless: Companies have two options for securing their wireless networks. They can either implement WPA with proper authentication and encryption (think RADIUS authentication, individual certificates, and WPA2) or they can use WEP with another form of encryption (i.e. IPSec, VPN, or encrypted SSL). WEP is insecure and should not be trusted as a protection mechanisms. Tools such as wepcrack exist that can determine a WEP encryption key in under an hour.
Non-Console Access: This means the elimination of TELNET, FTP, R-services, and any other protocol used for administrative access. Most companies struggle replacing TELNET with SSH, but they should also look to places where VNC is used for administrative access and FTP is used for batch administration. Any plain text protocol needs to be replaced or encapsulated with an encrypted alternative.
Data at Rest: This is the biggest requirement for data encryption throughout the PCI DSS. This mandates three things:
- Industry accepted encryption algorithm with proper key length (i.e. AES at 128-bit)
- Encryption key management
- Encryption key rotation
For some organizations a hardware security module (HSM) or tamper resistant security module (TRSM) are used to perform all the key management and rotation steps. Other companies will opt to implement these requirements in their own software and they will need to work with a qualified assessor to determine if they are meeting each of the three key requirements.
Requirement 3 lists two alternatives to cardholder data encryption being Truncation and Hashing. If you choose either of these alternatives you do not need to encrypt the data, although some companies find it helpful to store both the encrypted and hashed or truncated account numbers within the same data store. (If you go the way of hashing it’s good security sense to ’salt’ your hash values.)
Data in Transmission: Contrary to the wording cardholder data does not need to be encrypted when transmitted over private networks — only when traversing public networks. So what is considered a public network? The Internet, DMZ, and Wireless networks. Companies need to verify the cardholder data traversing public networks is encrypted (i.e. Encrypted SSL for Internet traffic, IPSec for DMZ connections, and WPA2 for wireless networks.)
If data is transmitted over a private network (i.e. Frame-relay, private T1, MPLS, VPN, etc.) the cardholder data does not need to be encrypted.
E-Mail: Cardholder data should never be sent un-encrypted via e-mail. If the e-mail traverses a public network (as described above) it would need to be encrypted as per PCI DSS Requirement 4.1, which causes many companies to think they do not need to encrypt internal e-mails that contain credit card numbers. The problem is that e-mail is static most of the time, either in personal mail folders on workstations or on the e-mail server itself. If these locations contain un-encrypted credit card numbers they are considered data stores and must themselves be encrypted as per PCI DSS Requirement 3.
What is the solution? Deploy e-mail encryption software to all employees who will need to send and receive card card data, which will prevent un-encrypted data stores from being created.
Encrypt Passwords: This requirement applies to all network, system, and application passwords that are stored. Companies who use VNC and pcAnywhere must be cautious because these passwords are not stored encrypted. Native pcAnywhere passwords and VNC passwords are stored in an easy to unscramble format. Other than that, watch out for router passwords that are not store encrypted (think ’service password-encryption’) and application level passwords. Many companies implementing password encryption forget about application passwords that also need to be encrypted (or hashed).
Bookmark to:
