When I specifically asked about this, I was told that if you did not have rights to both SAF profiles, you could not read the data set at all. Are you reading things that suggest this is not the case? Sure, access to two profiles is a bit more security than one—that is, it’s more likely that someone accidentally authorizes you to read CRITICAL.STUFF.* than that they accidently authorize you both to read it and access the appropriate key. But if you can’t read the data set *at all* without the key, then it’s still largely an on/off switch, and you have to decrypt all of the data to do anything with it.
But yes, it’s a good step forward! Whole-data set encryption has its value. I just happen (for some reason) to think that the higher security of data-centric persistent encryption is more useful. As for VSAM keys—those can be protected with NIST-standard Format-Preserving Encryption (FF1, which is considered secure and appropriate for data at rest, unlike FF3 or Visa FPE), and things still work. But it does require that the application be aware to the extent that it encrypts the value it’s looking for, so it isn’t as transparent. Again, though, it’s providing a lot more security… “It’s turtles all the way down!” …phsiii ---------- Forwarded message ---------- From: Greg Boyd <[email protected]<mailto:[email protected]>> Date: Mon, Jul 17, 2017 at 7:43 PM Subject: Re: IBM z14 To: [email protected]<mailto:[email protected]> Phil, I agree with most of your comments, but only half of this sentence: Transparent, whole-file encryption has its uses, but adds very little real security: if you can read the data set, you get the cleartext. Pervasive encryption does encrypt the whole file, but getting read access to the data set does not necessarily get you access to the cleartext. That is, you must have a) access to the dataset AND b) access to the key that protects the data set. When you create a data set in this new world, you set a flag that says 'This data set must be encrypted' and associate a key with that data set. One of the ways you can set these values is in the DFP Segment of the data set profile or via ISMF, so that data set profile may control a single data set or a slew of data sets. You could have a unique key protecting each data set or a single key protecting all of the data sets controlled by the profile. The net is that there must be two SAF profiles in place, one giving access to the data set and another to the key material. (And you must have the appropriate authority to both.) I could argue that this is a better solution than file-system encryption because read access to the data does not get you access to the cleartext. Is this the solution to end all solutions ... probably not. But it's a whole lot better than the current z/OS support. And the big advantage is that now you can protect your VSAM data sets! Up to this point, the only way to protect data within a VSAM file was to do it within the application. You could invoke ICSF APIs or Voltage APIs or anybody's APIs, but the application had to handle the complexities of encrypted VSAM keys. With this solution, your RACF administrator can set the flags in the DFP Segment or your Storage Admin can set the flags in ISMF and the data set will be encrypted and the application will never notice. I still think there will be a place for other solutions because ultimately, the most efficient, most secure way to protect your data is within the application. And I also think there are still cases where multiple solutions will be in play. That is, I can make a case for using both the Infosphere Guardium Data Encryption Tool for DB2 and IMS as well as pervasive encryption. Yes, double encryption adds overhead, but every solution protects from against a different attack. I haven't reviewed the announcement, but it will be interesting to see the performance metrics that IBM publishes for this technology. Pervasive encryption is a big step forward. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
