"You lose/destroy the key(s), you have lost your data." My answer: "You
lose/destroy the password(s), you have lost your data." Do you use RACF
(or TSS, ACF2)? Oh, it is not a joke. I know such scenario. Government
owned organisation. Yes, every new thing does require some preparation
and procedures. Even knife. Or fire. And after thousands of years we
still have some accidents with both. However we adopted those things and
we use them.
BTW: I *did not* ask about dataset encryption. :-)
However I asked about the tools which could help manage the keys.
Because sometimes we have to encrypt and it is good idea to managed the
keys properly.
No, I'm still not talking about dataset encryption.
But what about physical tapes leaving VTS-attached library?
What about VTS cache?
What about application-specific keys?
Regards
--
Radoslaw Skorupka
Lodz, Poland
W dniu 12.04.2024 o 18:21, Jousma, David pisze:
To place a bit more focus on what Rick says….. You lose/destroy the key(s),
you have lost your data. There is a lot of discussion about the scope/use of
the keys. One key, or one per application, or one per dataset, etc. There
is no right/wrong answer (well just one key for everything is probably not
advisable).
I personally am still having a hard time wrapping my head around the “real
benefit” of dataset encryption. Everyone who has READ or more access to the
dataset, must also be permitted to the Key. Those same people are still able
to copy/print/steal that data. So who does that leave? Those that are not
permitted to the dataset, and those who administer the storage. Those that
don’t have access to the dataset aren’t going to get the data, encrypted or
not. Those who administer the storage usually have access to move/manage the
installations data. These are the people who dataset encryption is
protecting against. That is a very small population to go to this effort on.
Dave Jousma
Vice President | Director, Technology Engineering
From: IBM Mainframe Discussion List<IBM-MAIN@LISTSERV.UA.EDU> on behalf of Rick
Troth<0000058ff5c2d0a7-dmarc-requ...@listserv.ua.edu>
Date: Friday, April 12, 2024 at 10:59 AM
To:IBM-MAIN@LISTSERV.UA.EDU <IBM-MAIN@LISTSERV.UA.EDU>
Subject: Re: IBM key management products
Not discounting Luke's excellent response: key management is hard. Look for
utilities with reliable import/export capability. Be prepared to OWN your keys.
I say this again as a CISSP, own your keys. This is your bread and butter, so
to speak,
Not discounting Luke's excellent response: key management is hard.
Look for utilities with reliable import/export capability. Be prepared
to OWN your keys.
I say this again as a CISSP, own your keys. This is your bread and
butter, so to speak, the family jewels.
So take care when using these products to ensure that they do what you
want them to do and that you know what they're doing.
One shop where I recently worked had a great slogan, "crypto is easy;
key management is hard".
It's not that the crypto was easy but that it's done already,
implemented, coded, packaged. But the keys *must* be managed by you and
your team, not the kind of thing which can be outsourced.
Keys and certs cannot be installed and forgotten. And sadly, some of the
expirations we are given are too short to be practical. (Various
government issued IDs and licenses commonly last FIVE years. Why do PKI
certs last only two? ... or ONE?)
But I'm getting off topic. Sorry.
The point is, keys are fundamentally different than any other software
or data that we have to manage.
And it's a good idea to limit keys to individuals when you can. (Like
the combination to the bank vault.)
It's all about trust.
This e-mail transmission contains information that is confidential and may be
privileged. It is intended only for the addressee(s) named above. If you
receive this e-mail in error, please do not read, copy or disseminate it in any
manner. If you are not the intended recipient, any disclosure, copying,
distribution or use of the contents of this information is prohibited. Please
reply to the message immediately by informing the sender that the message was
misdirected. After replying, please erase it from your computer system. Your
assistance in correcting this error is appreciated.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email tolists...@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
