On Thu, Feb 14, 2013 at 2:40 PM, Lizette Koehler <[email protected]<mailto:[email protected]>> wrote: I have been asked by a friend to find out what is used to encrypt IMS Data Bases that are PCI compliant.
The data is small. But they just want to make sure no one can get to the data. If it goes to Tape I know what that should be, but the curiosity is what is done on the data bases themselves. Or do you just ensure the SAF rules are strong enough? No, SAF cannot provide PCI compliance. You need strong encryption and/or tokenization on the PCI data (credit card numbers or, more specifically, the PANs - Primary Account Numbers - that are part of CCNs). It's a whole theology, and has its own peculiar rules, but the good news is that the PCI DSS document is quite readable and not that long. One aspect is "PCI scope", which has to do with whether a given application or environment even has access to the plaintext. Using encryption/tokenization wisely can remove entire subsystems and even systems from PCI scope, which makes audits much faster and easier (and cheaper). For example, whole-database encryption may get you through a PCI audit-depending on the QSA (Qualified Security Assessor-the auditor), but every app that uses the data will be in scope. In case you can't tell, this is one of the things we do here at Voltage Security, Inc., with our Voltage SecureData product, which includes native encryption and tokenization on z/OS. With application-level, Format-Preserving Encryption and Format-Preserving Tokenization, only those applications that will do decryption/detokenization are in scope-and with format-preserving data protection, that's not every application that uses the data. Consider a credit card number: the only times you likely ever have the unprotected number are when it comes in (from a screen, partner, whatever-and if that source is "a web page", you encrypt the PAN *in the page*, so it's protected all the way through), when you send it on to the bank for settlement, and perhaps when fraud analysis finds a victim and needs to get back to the real data to report it. Otherwise, apps that "use" that number are likely to just be passing it along, perhaps checking that there *is* a value. So they don't need to do decryption-and since it's protected with a format-preserving technology, they don't even need any changes at all. Indexes still work, referential integrity is maintained-it's really reduces the pain of a data protection project significantly. I've probably gone on enough here; if you'd like more information, drop me a line. Cheers, -- ...phsiii Phil Smith III [email protected]<mailto:[email protected]> Voltage Security, Inc. www.voltage.com<http://www.voltage.com/> ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
