I agree that it is quite unlikely that our DASD will be hacked. My manager thinks the same. Regardless, our management has chosen certified crushing and shreding of retired DASD, Tape, etc.
-----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Friday, December 14, 2012 1:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: dsf to write over entire volume W dniu 2012-12-13 18:22, Ron Hawkins pisze: > Radosalw, (Radoslaw, pronounced like Radoslav ;-) ) >> Encryption is a matter of time and cost. The question is WHEN I will > decrypt >> the data, not IF. And WHEN depends on my budget (the more money the >> more zombies works for me) and piece of good luck (I can guess the >> key 5 min. after start or as last possible value). >> > [Ron Hawkins] I'm not sure I follow the point. Encryption occurs when > the data is destaged to the array group, and decrypted when you read > it from the disk. There's no overhead to this . If you mean switching > encryption on for existing array groups then yes there will be some planning involved. I think you missed the point. Encryption does not prevent data from being read, it does DELAY the moment when "hacker" will read the data. If the dealy is measuer in centuries that's OK, but nowadays the are methods to accelerate decryption (brute force) attacks i.e. using grid, cloud or just bunch of PC's, possibly using GPU ("VGA" card processors), possibly using hacked machines without onwers awareness. BTW: This is significant: few years ago nobody suggested (and offered) full disk encryption inside dasd arrays, nobody was selling security erasure features for those arrays, nobody was selling data erasure programs operating at OS (MVS) level. However degaussers for tape carts were around us even then. What was changed? Physics? No. Maybe with exception of SSD as new media. The issues addressed by the above means had existed for years. 15 years ago it was also possible to play with bad sectors of disk coming from dasd array, or preferrably with whole healthy tracks on such disk. What was changed? IMHO two things: minor change in available tools for potential hackers and major change in our minds. Changes driven by "horror stories" presented in IT newspapers. Majority of them does not describe real attacks but possibilities of such attacks. Considerations how many times should the track be overwritten with random data to erase residual vestiges of data at sides of the track... That remains me thesis from some movie - probably Bowling for Columbine - the number of violence acts decreased sligthly over the years, but the percentage of report about those acts in the news increased 10 times. There are specialized TV teams "hunting" for accidents, fussilades, bank robberies, madmen with guns, etc. Maybe it's the same in IT - the vulnerabilities remain unchanged for years, but we talk about them much more. ;-) -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 0000025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych. ---------------------------------------------------------------------- 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
