PCI DSS 3.4 – Render PAN unreadable

PCI DSS 3.4 – Render PAN Unreadable
Before tacking requirement 3.4 it is important that organisations understand what is acceptable from a storage perspective and what isn’t. The following table taken from the PCI Security Standards Council website explains what can and cannot be stored according to the standard:

Table 3

table 2

Tips for complying with requirement 3.4
There are many different ways of hashing data and encrypting data, generally making the data ‘unreadable’. So first things first, in the scoping exercise use tools such as Enterprise Recon from Groundlabs or otherwise to discover where credit cards are on the network. Once discovered, make sure that they are not stored in clear text. If they are – remediate. Either remove (if not necessary) or else implement one of the recommendations outlined in requirement 3.4. Assuming you have got to this point, examples of the how card data can be stored are as follows:

1. One-way hashes based on strong cryptography
As per Wikipedia (http://en.wikipedia.org/wiki/Cryptographic_hash_function)
A cryptographic hash function is a hash function which is considered practically impossible to invert, that is, to recreate the input data from its hash value alone. These one-way hash functions have been called “the workhorses of modern cryptography”.[1] The input data is often called the message, and the hash value is often called the message digest or simply the digest.
The ideal cryptographic hash function has four main properties:
• it is easy to compute the hash value for any given message
• it is infeasible to generate a message that has a given hash
• it is infeasible to modify a message without changing the hash
• it is infeasible to find two different messages with the same hash.

Common examples of hashing algorithms are: MD5, MD6, SHA1, SHA2.

PCI-DSS 1.2 discourages the use of MD5, in favor of the newer and better SHA1 algorithm.

In addition, adding a salt value (http://en.wikipedia.org/wiki/Salt_(cryptography) to hash algorithms greatly reduces the risk of compromise as they help defend against dictionary attacks versus a list of password hashes and against pre-computed rainbow table attacks.

2. Truncation
Truncated data is permitted to be first 6, last 4 of the 16 digit credit card number (PAN)
such that the middle 6 digits are masked.

VISA has also issued best practice guidelines on PAN truncation:

3. Index tokens and pads, with the pads being securely stored
This option refers to tokenisation. As per Wikipedia (http://en.wikipedia.org/wiki/Tokenization_(data_security)

Tokenization, when applied to data security, is the process of substituting a sensitive data element with a non-sensitive equivalent, referred to as a token, that has no extrinsic or exploitable meaning or value. The token is a reference (i.e. identifier) that maps back to the sensitive data through a tokenization system. The mapping from original data to a token uses methods which render tokens infeasible to reverse in the absence of the tokenization system, for example using tokens created from random numbers.

Tokenisation can greatly reduce the scope for PCI DSS compliance.

There are many Tokenisation service providers (TSP), e.g. Transaction Network Services (TNS), AuricVault, Bluefin, NuBridges and Voltage Security.
More information on Tokenisation is available at the following:
• http://en.wikipedia.org/wiki/Tokenization_(data_security)
• https://www.pcisecuritystandards.org/documents/Tokenization_Guidelines_Info_Supplement.pdf
• http://resources.infosecinstitute.com/want-limit-pci-dss-scope-use-tokenization/
• http://pciguru.wordpress.com/2011/0h8/05/tokenization/
• http://info.intel.com/rs/intel/images/Tokenization-Buyers-Guide.pdf
• https://securosis.com/assets/library/reports/Securosis_Understanding_Tokenization_V.1_.0_.pdf

4. Strong cryptography, with associated key-management processes and procedures.
Ok, so firstly the mathematics behind Cryptography and a description of the underlying algorithms is way out of scope of this site. If you are interested, two books I really enjoyed as an introduction are:
• Applied Cryptography by Bruce Schneier
• Handbook of Applied Cryptography by Menezes / Van Oorschot / Vanstone

Encryption policies, processes and procedures are also out of scope for this site, although this information is provided to members in the created documentation packs.

So how do Small to Medium sized companies comply with the encryption requirements outlined in the standard? In most cases – buy a Hardware Security Module (HSM); this will cover most of the requirements and then creation of secures key management processes as well as owning a secure safe will cover the others (In theory!).

Samples of HSM’s that can be purchased are:
• https://www.thales-esecurity.com/products-and-services/products-and-services/hardware-security-modules
• https://www.yubico.com/products/yubihsm/
• http://www.safenet-inc.com/data-encryption/hardware-security-modules-hsms/
• http://www8.hp.com/au/en/software-solutions/hardware-security-module-hsm-atalla-nsp/
• http://www.swift.com/products_services/hardware_security_module_overview
• http://www.futurex.com/hardware_security_modules.asp
• aws.amazon.com/cloudhsm/pricing/

Other great HSM related resources:
• https://www.pcisecuritystandards.org/documents/PCI%20HSM%20Security%20Requirements%20v1.0%20final.pdf
• https://wiki.opendnssec.org/display/DOCREF/HSM+Buyers’+Guide#HSMBuyers’Guide-TypesofHSMs
• http://en.wikipedia.org/wiki/Hardware_security_module
• http://www.sans.org/reading-room/whitepapers/vpns/overview-hardware-security-modules-757 (a bit dated, but still a good read)
• http://www.openpgp.org/
• http://www.symantec.com/encryption/