It's not enough to just encrypt at the DASD level. The exposure is not just the systems, but also (or even mainly) insider malfeasance.
Application programmers need access to (some form of) production data to perform valid regression testing at each change cycle. This argues for security-product-protected production PAN files (no access at all except by production jobs submitted from the scheduling system and production-emergency-only authorized userid's) and duplicate masked or hashed PAN files where no programmer (or any other employees with file-viewing privileges) can view the real data. How to mask or hash the copied data so that production code still operates correctly during unit and regression testing is an application-dependent issue. None of this is easy. It requires management buy-in for the additional DASD and processes to hash or mask the data, the effort required to determine how to do the hash or mask for each application and then to implement those processes, and then the additional CPU and DASD usage required by those processes forever afterwards. And then there are report files produced for clients. Do they have PAN data too? How do your customer service personnel help the client if they can't see the real data the client sees? Peter -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Frank Swarbrick Sent: Friday, May 15, 2015 1:36 PM To: [email protected] Subject: PCI DSS compliance for z/OS 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? Frank -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
