New PCI DSS is out
The Payment Card Industry Digital Security Standard, version 1.1, has been released [pdf]. This was widely anticipated, and has been remarked upon here at EC.
A noteworthy change is that stored card numbers needn’t be encrypted:
Compensating Controls for Requirement 3.4
For companies unable to render cardholder data unreadable (for example, by encryption) due to technical constraints or business limitations, compensating controls may be considered. Only companies that have undertaken a risk analysis and have legitimate technological or documented business constraints can consider the use of compensating controls to achieve compliance.
Companies that consider compensating controls for rendering cardholder data unreadable must understand the risk to the data posed by maintaining readable cardholder data. Generally, the controls must provide additional protection to mitigate any additional risk posed by maintaining readable cardholder data. The controls considered must be in addition to controls required in the PCI DSS, and must satisfy the “Compensating Controls??? definition in the PCI DSS Glossary. Compensating controls may consist of either a device or combination of devices, applications, and controls that meet all of the following conditions:
1. Provide additional segmentation/abstraction (for example, at the network-layer)
2. Provide ability to restrict access to cardholder data or databases based on the following criteria:
• IP address/Mac address
• Application/service
• User accounts/groups
• Data type (packet filtering)
3. Restrict logical access to the database
• Control logical access to the database independent of Active Directory or Lightweight Directory Access Protocol (LDAP)
4. Prevent/detect common application or database attacks (for example, SQL injection).
Makes sense to me. Encryption as a panacea is absurd.
Disk encryption software: $25,000
Backup encryption hardware: $100,000
Putting your customer’s privacy at risk because merchants complain: Priceless
Mr X.,
Encryption’s not a panacea, but it’s a very effective way to mitigate a broad class of important risks, which the new criteria miss, including equipment theft, equipment resale with improper sanitization, and backup loss.
Thanks to 1386 and family, we now know that all three of these are reasonably common. We certainly get more reports of them than we get of SQL injection attacks.
The reason they don’t (require) encrypt the card numbers is because it isn’t practical. There are hundreds of places where it would need to be done, and hundreds of potential exposures.
OTOH, once we assume that the numbers are probably open, then we could take the next step of designing it such that the open numbers don’t result in a threat. This we know how to do. This *they know how to do*. What is interesting is why they don’t do it.
I think we are in violent agreement.
My company has had (on quite regular occasion) requests from customers for the disks in our application servers – that simply serve content – to be encrypted. It’s that sort of thinking that I find absurd, that throwing encryption at the problem somehow solves it in a universal way.
Now in the laptop domain, it’s different.
But the idea of compensating controls is very worthwhile, although the phrase “compensating controls” is itself becoming a bit worn, IMNSHO…
Two imporant points
1. For large processors and merchants, the compensating control needs to be approved by the auditor / PCI authority in your region (for us this is VISA), and the track record of these being being approved to date is low. So encryption or masking are effectively still required in the big league. IMHO these large merchants and smaller processors are a major vulnerability in the payment network and it would be a major backward step if this sensible addition of flexibility in the standard is seen as an opportunity to gut the initiative
2. The major threat to compromise remains INTERNAL (either by commision or ommision), not hacking. Masking and encryption is an excellent way of making this data hard to mishandle. The people who say that the use of a data encryption mechanism (and by that I mean the complete cryptographic subsystem including the procedures around key management) does not provide an effective solution to this issue, display their ignorance on the topic. I would agree that I often see cryto misapplied in various ways – but this is not a weakness of the tool, but of the fool using it.
This is good:
“OTOH, once we assume that the numbers are probably open, then we could take the next step of designing it such that the open numbers don’t result in a threat. This we know how to do. This *they know how to do*. What is interesting is why they don’t do it.”
Can anyone answer why this isn’t being done with some level of urgency? Political issues? Intellectual property? Too costly?