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

Reply via email to