Reminds me of something that happened decades ago. A failing 3350 disk was replaced. The failing disk was returned to supplier. The platters were very shiny. The disk had been through a sand blasting machine đ
________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of Radoslaw Skorupka <[email protected]> Sent: 16 April 2024 10:23 To: [email protected] <[email protected]> Subject: Re: [EXTERNAL] Re: IBM key management products "take disks back to work" Well, an auditor could be very happy of this finding. The disk was somewhere outside. Who read it? Was it replaced with another one? Etc. No, it is not so funny. I know the case, financial company ordered disks destroyment. A lot of disks - over 4000 approximately. What happened? Some disks fell out of the truck during transportation. Yes, and guys responsible for that stopped the truck on a highway and collected fallen disks. All of the disks? Nobody knows. Obviously there were no list of of the disks. Despite security dept. rules saying that every erased disk should be registered, with model, type and serial number. Ho, BTW: the company had degausser machine - it was enough to hire some student to degauss all of the disks. (no SSD at the time) -- Radoslaw Skorupka Lodz, Poland W dniu 15.04.2024 o 20:51, Pommier, Rex pisze: > Nope, but I did take the now-holy disks back to work to show them the > destruction. đ > > -----Original Message----- > From: IBM Mainframe Discussion List<[email protected]> On Behalf Of > rpinion865 > Sent: Monday, April 15, 2024 1:37 PM > To:[email protected] > Subject: Re: [EXTERNAL] Re: IBM key management products > > Did you have the auditors present so they could certify your actions :) ? > > > > > Sent with Proton Mail secure email. > > On Monday, April 15th, 2024 at 2:32 PM, Pommier, Rex<[email protected]> > wrote: > >> Didn't phase the drill bit one bit (sorry for the bad pun). I just had to be >> careful not to punch a hole in the bottom of the drives so as to not get >> glass shards dropping on my (very messy) shop floor. >> >> -----Original Message----- >> From: IBM Mainframe Discussion [email protected] On Behalf >> Of Tom Brennan >> >> Sent: Monday, April 15, 2024 12:57 PM >> To:[email protected] >> Subject: Re: [EXTERNAL] Re: IBM key management products >> >> Nice! That's the first I've heard of glass platters. Hope your drill >> bit survived the trauma :) >> >> On 4/15/2024 8:33 AM, Pommier, Rex wrote: >> >>> Hi Tom, >>> >>> Regarding #2, at a former job I got to decommission an HDS box that >>> was shared between the mainframe and Unix boxes. Unencrypted disk in >>> it. Mgmt wanted the data destroyed so they asked me to take the >>> individual drives home and drill through each of them. That was when >>> I found out that this particular disk drive had glass platters. >>> There was no getting data off them when the drill bit shattered >>> every platter in every spindle. đ >>> >>> Rex >>> >>> -----Original Message----- >>> From: IBM Mainframe Discussion [email protected] On >>> Behalf Of Tom Brennan >>> Sent: Friday, April 12, 2024 1:41 PM >>> To:[email protected] >>> Subject: [EXTERNAL] Re: IBM key management products >>> >>> We use SKLM/GKLM for data-at-rest encryption of DS8000/TS7000 devices, all >>> internal disk storage, no external cartridge tapes. So what does that do >>> for the customer, since (unless you're using an additional form of >>> encryption on the mainframe) the data is still spit out of the devices >>> unencrypted (not counting the additional feature that allows >>> FICON-in-transit encryption). >>> >>> I have a few theories on this: >>> >>> #1 If someone gets into the datacenter and steals disks (or the entire >>> DS/TS box), the encrypted contents should be useless. >>> >>> #2 When a DS/TS box is decommissioned, a customer could "potentially" >>> skip any further destruction of the data in the box. Still, what >>> I've seen in reality for decom is to run the IBM SDO (secure data >>> overwrite to blot out the disks) and sometimes even shred the >>> individual disks (I'd sure like to see that in action!) >>> >>> #3 If you steal a DS/TS box, make sure you steal the associated key server >>> unit too. >>> >>> I'd appreciate any comments on these theories. >>> >>> On 4/12/2024 9:21 AM, Jousma, David wrote: >>> >>>> 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 [email protected] on >>>> behalf of Rick Troth >>>> [email protected] >>>> Date: Friday, April 12, 2024 at 10:59âŻAM >>>> To:[email protected] [email protected] >>>> 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. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
