I think you have switched forums Phil. This stream started on RACF-L Lennie
-----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Phil Smith III Sent: 01 March 2023 21:48 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DATASET encryption POC Eric D Rossman wrote, in part: >Not really. Can you give me a reasonable use case where having the >encrypted data would be of ANY use to you? There is nothing to >compare/correlate. Since the data is (maybe compressed) and encrypted, >there is nothing to look at other than the length of a given record. At a minimum, the ability to copy/compare data sets. If protection was at a record level, it would be more useful. But I agree it'd be a fairly small benefit here. Again, though, that wasn't my full point: it'd be harmless at worst (and provide the benefits I listed) at least; the problem, as I said, is that it's been oversold as "Now you're protected from attacks" when you aren't. That isn't your fault, it's a marketing/presentation thing. >That is exactly the case we were trying to protect against: a >misconfigured system. Someone who has access to open the data set >should also have access to the key protecting it. If they do not, that >is a misconfiguration and one that we explicit explain how to avoid in >the red book. OK, I guess.though I'd give the customer the option. And access is already controlled by SAF; the point I was making is that in terms of access *on the system*, the encryption doesn't provide any real protection against anything except the two use cases I described. Put another way: in terms of access *on the system* (and, again, besides storage admins) just adding a second SAF profile to protect the data set - "This is an important data set, so you need not only access to it implicitly as part of the DATASET class, but also via a second profile in the VIP class" - the result would be the same. >I disagree here as well. We're not merely trying to protect it from the >same things that SAF access protects it from. We are really protecting >it from the storage admins (i.e. on DASD as well as on the wire). >Security is a layered approach. Right, I said that. That's one of the two things it DOES provide protection from. But that's not an attack vector people commonly worry about in my experience. >A.k.a. a layered approach. DASD encryption, data set encryption, and >format-preserving encryption are all pieces of the puzzle. Each >protects from a different attack vector. There are use cases where data >set encryption is the right solution and others where field-level FPE >is and others where both are good together. I don't disagree-again, however, people are sold on "We encrypted something, now we're protected!" and I think that's doing a disservice to the customers. And cases where data set encryption alone provides real protection seem to be pretty few and far between. >Oh, by the way, ICSF provides FPE which fits beautifully into this. ICSF provides Visa FPE, which is malleable and thus only usable if you use a different key for each element. That's a very significant limitation that makes Visa FPE not really very useful, since it breaks referential integrity. FF1 is NIST-standard, not malleable, better. The doc I've seen about FPE through ICSF also doesn't make this very clear, which concerns me: it's too easy for people to miss it and wind up with protection that's trivially breakable. Just to reiterate: whole-data set encryption isn't a Bad Thing, it just sort of becomes one when people get fooled into thinking it solves their encryption needs, when it really does only a tiny part of that. That leaves a bad taste in my mouth, so I'm probably overly negative about it as a result: it's clearly at least somewhat useful as an adjunct. Cheers, ...phsiii ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
