I’m no PCI assessor, but I am involved in helping a business reach PCI DSS compliance. On the encryption front, the PCI standard requires cardholder data to be stored in an approval PCI encrypted format on the backend database. In addition to this, PCI has a big focus with the database encryption key management, ensuring the private key is not known in full by a single person etc. I don’t have any issues with this despite good key management being a real pain to implement, it all makes good security sense, but here’s my observation and big issue with the PCI encryption requirements.
When the merchant sends the cardholder data to the bank for the card payments to be processed, the cardholder data is exported from the database unencrypted and sent to the bank in an unencrypted format, sure it’s over a point-to-point private connection, but wasn’t whole PCI point to prevent the cardholder data from being readable on the database Server? The bank payment process is a requirement of the bank, who can only accept the card payment in an unencrypted format. I see a potential threat from an inside attacker to capture significant clear text cardholder data by intercepting this payment process.
I don’t whether this is already a commonly known PCI issue, or just an issue with UK banks, or whether it's just with a specific “big named” UK bank, but when I addressed a professional PCI auditor with this concern, he didn’t give much of response and just stated it wasn’t the first time he’d been asked about it.
For me, it appears to be a significant hole with the PCI encryption practice, especially as the database encryption is what most PCI auditors appear to care about the most, PCI auditors just love to go on (and on) about “Key Management”. It certainly would be interesting if this was a general problem with the banks, who sit in their ivory towers carrying significant weight on the PCI board and setting out the PCI standards, but when it comes down to them actually spending the money on improving cardholder security themselves, they just aren’t doing it, hardly a balanced and fair approach, is it?
It's not a specific "big named" bank, it's general.
ReplyDeleteOur Acquirer isn't PCI DSS compliant and yet they are very active in the arena. When asked when they will be compliant, the answer could have been written by a politician. Basically, it's a "we fully expect to have made significant progress within the timescale presented to us" type thing.
When is that, you may ask? That's when it gets even more vague.
I have been meaning to study the PCI Standard (or should I say, Audit Procedures document which is where the real information is) regarding this topic for a while. However, my current feeling is that to be fully PCI DSS compliant, not only must the transmission be encrypted (i.e. SSL) but also the data within the transmission must be encrypted.
While you are not the first person to notice this, it might be worth stepping back a bit.
ReplyDeletePCI specifies a framework for protecting card holder data. The framework is highly prescriptive and tightly focused (recovery is hardly mentioned). It's also driven by the collective breach experience of the industry.
The details of this (breach) knowledge are not generally available even to QSA's. So there is always going to be the unsettling sense that the foundation of the framework will shift somewhat.
This effect of this breach knowledge also accounts for the sense that some things are less of a concern and others more even though on the surface they would seem to be the similar.
It's also a consequence of a real world framework. Regardless of if we like it or not, PCI will change and there will be shifts in interpretation.
Looking at the risk in the situation you describe. The general consensus is that data at rest is more at risk than data in flight. Databases can be read, disks removed, backups stolen. Encryption mitigates at rest risks.
The key management parts are heavily borrowed from the controls covering ATM networks. Key management is often one of the largest expenses associated with strong cryptography. Setting the standard lower and moving up the bar piecemeal would be expensive and painful.
What risks remain? Insider/attacker tampering with the decrypting server to get at the data as it’s decrypted and transferred? PCI has a large number of controls that should mitigate these risks. Interception of the transmission by an attacker at the merchant or communications company? Some additional risk analysis is probably justified here. Perhaps even some compensating controls may be needed. The risk at the bank’s end is not directly a concern of the merchant.
Strictly speaking the telco is a third party service provider and should be required to demonstrate compliance for the services they offer. Is PCI focusing attention on this now? It’s a much lower risk and priority than providers of shared e-commerce hosting systems. But, if someone should learn to drink from the fire-hose, the merchant may very well end up paying for their meal!
Banks are big players in PCI. Banks generally have a lot of security. Do they have lapses? Yes. Are they perfect? Certainly not. Are there major high risk holes? Less likely. They are part of the compliance enforcement if they are an Acquirer. They are already paying for other parties breaches if they are an Issuer. Their agenda is that they want other parties to catch up to them first.
I expect that a requirement for encrypted transmission over PRIVATE networks is coming. I just can’t say when.
We can all argue about what we don’t like about PCI. It would have been nice to see requirements that were phased in (It’s starting to happen) as it would have allowed merchants a bit more flexibility in getting there. But ultimately, we don’t have the data behind us to know it they tightened some screws a bit quickly. It would also have been helpful and useful to have the standard risk weighted with more than just an all or nothing pass/fail. But, it isn’t.
Now as for the nameless bank. Shame on them. They know better and they should move to offer a more secure service.
Perhaps the merchant should think about switching! At the very least they should do some due diligence and compare against another bank.
@Andrew - your over cooking the encryption.
ReplyDeletePerception is king. You stated "PCI has a big focus with the database encryption key management." Not exactly true, as it is only one of twelve sections from the standard. Many sectors (both merchants and service providers) were developed with encryption and good key management from the outset and have already addressed these requirements, they in turn are hung up on other requirements.
ReplyDeletePerhaps your focused towards key management as you state "good key management being a real pain to implement." It can be a pain, especially if you starting with a legacy system though HSMs with database and application interfaces can rapidly take away this pain.
I agree with the comments from Anon dated 06 June 2007 15:50 that the risk during transit is far less than at rest and the acquirers are taking real steps to address their own issues, though they have a problem of scale so naturally it will take them longer. Also there are compensating controls available and many other risks to consider, such as why would a hacker care if the database is encrypted or not if they have a nice user friendly application to extract the information they require?
On Anon's point that recovery is hardly mentioned. In version 1.0 and prior (SDP/AIS/DSS) recovery had a higher profile, though this is an information security standard, ultimately it has no bearing on security whether you are able to recover following an event only that the data is protected.
Thanks for all the comments and view points posted by everybody, I value them all greatly. Just on the perception thing, yes you are indeed right, data encryption at rest and key management was the biggest issue within my own PCI scenario, and it was the PCI assessor’s favourite bleat as well, but I also saw some stats on a VeriSign “white paper” which showed a break down of the sections where companies had failed PCI assessments, the “3. Protect Stored Data” (encryption) section topped the list, check it out at https://www.verisign.com/static/PCI_REASONS.pdf , it’s interesting reading.
ReplyDeleteI totally agree with the comments about banks being less than perfect, there are several interesting "public" examples on the UK side, which I'll post about another time. Recently one UK bank called Nationwide, got fined the equivalent of $2 Million dollars after the theft of laptop which held "a lot" of unencrypted customer personal data. The worst bit was they did nothing about it until three weeks after the theft occurred, like actually bother to tell their customers!
hi, I am looking into PCI at work. I am fairly new to all this, but have come across a problem which I can't find an answer too.
ReplyDeleteI understand that we need to encrypt our data which is fine, the issue however is how are you meant to manage the keys as having them just sit on the server isnt very secure.
Do you have any advice on how I should be managing my encryption keys?
Avoid storing the key on the Server.
ReplyDeleteI know the majority of companies going through PCI find the Key Management the hardest issue to resolve.
I don't know much about products to recommend with the key management process myself, as my own experience with key management has always been with inhouse written applications. Which as you imagine requires more than one person to input individual passwords to generate the key etc.
Sorry it's not much help to your quiery, but if you do find anything or anyone else reading this has any recommendations, please post, as I'm always interested to learn.
Anyway here's a reminder of what PCI say about key management...
3.6 Fully document and implement all key management processes and procedures for keys used for
encryption of cardholder data, including the following:
3.6.1 Generation of strong keys
3.6.2 Secure key distribution
3.6.3 Secure key storage
3.6.4 Periodic changing of keys
• As deemed necessary and recommended by the associated application (for example,
re-keying); preferably automatically
• At least annually.
3.6.5 Destruction of old keys
3.6.6 Split knowledge and establishment of dual control of keys (so that it requires two or three
people, each knowing only their part of the key, to reconstruct the whole key)
3.6.7 Prevention of unauthorized substitution of keys
3.6.8 Replacement of known or suspected compromised keys
3.6.9 Revocation of old or invalid keys
Dave,
ReplyDeleteI need to encrypt column values in Oralce / UDB tables for my in-house applications but have problem solving the key management issue to be PCI DSS compliant. Would appreciate if you could share with us how you resolve it for your in-house applications pls. Thank you!
We had a PCI/CISP problem before. We were impressed with solutions provided by JSA Networks http://www.jsanetworks.com. They have found some clever ways to integrate with most programming languages. I do not like to do product endorsements, but it helped me tremendously.
ReplyDeleteThanks for writing this.
ReplyDelete