David L. Craig wrote: >This is a golden opportunity, IBM. Please don't blow it. >This will require better than usual marketing. Prove to us >there are no backdoors and that decrypted data cannot be >exfiltrated by SEs and HMCs.
Not understand concern re backdoor-it's AES; if it's keys you're concerned about, Crypto Express provides that security. >If you can do that, you will >have no competition for enterprises that are serious about >keeping their secrets secret. Enterprises like IBM, for >instance. <self-serving post follows> On the contrary, they'll continue to have competition. Transparent, whole-file encryption has its uses, but adds very little real security: if you can read the data set, you get the cleartext. Persistent, data-centric encryption, like HPE SecureData z/Protect<https://www.voltage.com/z> (https://www.voltage.com/z), available for almost a decade, provides much higher security, because (a) the ability to decrypt a given field is granular, at the user/field level and (b) format-preserving data protection means that a significant amount of processing can be performed with the data in its protected state, avoiding the need to decrypt it at all. For example, consider a retail organization that processes credit cards. As a store, you mainly care about the card only in that you have one and that it's consistent. If you protect it as soon as it enters the enterprise, it can be stored, passed between applications, etc. without every decrypting it, until and unless it's sent up to the processor for settlement. So all of those intermediate applications and data stores need *no* changes at all: they see something that looks like a credit card number and happily store it, pass it on, etc. (Yes, you can protect just the "middle six", as PCI DSS requires, thus preserving the IIN and the "last four" for routine/verification-more use cases where you need not decrypt with format-preserving data protection.) Plus it's ASCII-EBCDIC transparent, so if you protect a value on z/OS in EBCDIC and transfer that data to a Windows application, translating it along the way, you don't need to decrypt it at the boundary. Or, for the above scenario, you'd like acquire the credit card information in ASCII, protect it then, and it would pass through the web server, middleware, etc. in its protected form, winding up in DB2 (forgive me, that's "Db2" now) on z/OS, and being decrypted only for settlement. There's lots more goodness to HPE SecureData z/Protect, but I'll stop there. And I'm really not dissing the whole-file encryption in z/OS: it's useful for satisfying checkbox requirements, for securing backups, for protecting data across shared DASD, and for simplifying DASD decommissioning. Just don't fool yourself into thinking that it's providing all that much protection. Any time that you decrypt data, you're increasing attack surface. The best security lies in doing that as rarely as possible. Transparent solutions are Tylenol; HPE SecureData z/Protect actually fixes the ailment. -- ...phsiii Phil Smith III Senior Architect & Product Manager, Mainframe & Enterprise Distinguished Technologist HPE Data Security ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
