Warning: long post ahead, and of course it’s pushing the hammer that we sell, but (I believe) there are universal truths included.
Frank, You’re asking the right questions. The basic followup question I’d ask is, “Do you want to pass an audit, or do you want to be secure?” Because those answers are different—as Target, Sony, Neiman Marcus, and a host of other companies who were PCI compliant and had passed audits can testify. Industry opinion agrees with Peter Farley’s post: we do not believe that disk-level encryption satisfies PCI DSS, in part because it does not meet the Separation of Duties (SoD) requirements: if you read the DASD, you get the data. That’s not SoD. In the “lattice of coincidence” department, I *just* read the following: https://pciguru.wordpress.com/2015/05/15/whole-disk-encryption-explained/ I know you said you didn’t like the idea of application-level encryption, but that’s the only real way to get security. If you think of a stack: · Applications · Middleware · Database · OS/filesystem · Hardware (and we could quibble about whether there are more layers in there or not, but close enough), then anything “above” the layer where you protect the data is not protected. So DASD-level encryption only protects against someone stealing the RVA (or backup tapes—it’s useful there for sure). OS/filesystem-level (not really relevant to z/OS, but to other platforms) doesn’t help with attacks against the databases, middleware, or applications. And so on. The best security is thus at the application level. But of course you say “I don’t want to do that, that’s too hard”. It need not be. Format-preserving data protection methods achieve PCI DSS compliance while enabling persistent, data-centric security. “Format-preserving” means that the encrypted/tokenized values look and feel like plaintext: same length, same character set. This allows you to protect the data as soon as possible when it enters your security perimeter (or before, in some cases!) and it stays protected throughout the system, being accessed (decrypted) only when absolutely necessary. The simplest example of this is actually credit card numbers, at least for non-banks: if you have customer credit card numbers, you mostly don’t care what they are, just that you have them and that they appear consistently throughout your systems. So if you protect the PAN when it’s entered by the phone rep, or on the web page, or at least as soon as it gets to the outermost system of yours that touches it, then it can traverse the rest of the systems in its protected state. The only time you’ll need to decrypt/detokenize it is when you pass it to the bank for settlement, or perhaps in very specific fraud analysis cases. Since the data protection is character set-transparent, the data can come in as ASCII and get translated to EBCDIC in its protected form without requiring changes, too. So we’ve found that well over 90% of applications require NO changes at all, since they don’t know or care that the data is now protected—but they’re instantly out of audit scope. This is a different way of looking at data protection, but we believe it provides the most security with the least impact. No, it’s not 100% transparent, like encrypting DASD—but those approaches also don’t add much real security. We have many very large, Fortune 50 customers happily using HP SecureData to protect data in this manner. Our data protection methods are standards-based (our Format-Preserving Encryption technology is a draft standard with NIST, as FFX-mode AES), and we have independent security proofs available. The other hard part—indeed, many folks find it the hardest part—of any data protection project is key management. HP SecureData includes a pretty interesting approach to solving this problem, too. Of course I’d be happy to discuss this in far more detail with you or your management! -- …phsiii Phil Smith III Senior Architect & Product Manager, Mainframe & Enterprise HP Security Voltage [email protected]<mailto:[email protected]> T 703-476-4511 M 703-568-6662 Hewlett-Packard Company Herndon, VA ---------- Forwarded message ---------- From: Frank Swarbrick <[email protected]<mailto:[email protected]>> Date: Fri, May 15, 2015 at 1:35 PM Subject: PCI DSS compliance for z/OS To: [email protected]<mailto:[email protected]> There has been a lot of discussion back and forth at my company as to what it means to meet the PCI DSS (Payment Card Industry Data Security Standard) requirement for data at rest, which I believe refers to the following from the PCI DSS v3.0: 3.4 Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using any of the following approaches: - One-way hashes based on strong cryptography, (hash must be of the entire PAN) - Truncation (hashing cannot be used to replace the truncated segment of PAN) - Index tokens and pads (pads must be securely stored) - Strong cryptography with associated key-management processes and procedures. The argument is whether or not hardware disc encryption of mainframe DASD meets this requirement. On non-mainframe platforms it is my understanding that "encrypted file systems" are what is used for PANs in "non-database" repositories. Basically, flat files. For databases I believe there are things done at the database level that encrypt the data prior to it being stored within the databases file system. (Or maybe they do both?) Anyway, other than maybe z/OS Unix files, I don't think that z/OS really has anything similar to non-mainframe files systems. So does encryption just at the disc/DASD level comply with the requirement? IBM would love to sell us their IBM InfoSphere Guardium Data Security product, but that only supports DB2 and IMS databases. This does not address VSAM files or simply sequential datasets (flat files). Our card system stores all of its data in VSAM (for "master files") and uses flat files for "work files" during batch reporting. So if encrypted disc doesn't comply, what are our options? I argue that encrypted disc does comply, but I seem to be losing that battle. One thing I am absolutely against is changing applications that handle card data to do encryption/decryption at the application level, calling some sort of encryption API. There needs to be a "system level" answer. I know there must be others out there that deal/struggle with this. What do you do? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
