W dniu 2014-01-20 21:18, Phil Smith pisze:
R.S. wrote:
Well, two points:
1. Encryption means the data is still there, but you need a lot of time or
...just good luck to access it. So, when you dispose encrypted media then it's
very unlikely someone could read it, but when you dispose erased media then you
are sure.
2. LAS, BUT NOT LEAST: you assumed site's policies are reasonable. Security
people are reasonable. Bad assumption. There are so many cases proving the
opposite. As an example I've met lately: one has to degauss disk drives which
were never ever used for storing company data. Whole dasd box was never
attached to any host. However, in order to dispose the box, despite of common
sense, he has to remove every disk drive, degauss it, store it's serial number
in the protocol (as well as the vendor and type/model). Why? Policy!
1) Only in theory. Assuming strong encryption (TDES or better-hopefully better,
nowadays), it's more likely that they'll guess what's on the disk than that they'll be
able to decrypt it. http://www.youtube.com/watch?v=koJQQWHI-ZA for a good, intelligible
discussion. Remember that when cryptographers assess attacks on crypto, they make lots of
assumptions that help the attacker, like known plaintext/ciphertext pairs. This makes
sense, as it means "In the worst case, algorithm x is y bits strong". But in
the real world, such assumptions often don't apply, and so even relatively weak crypto
can be de facto quite secure.
So from a practical standpoint, "good luck" just isn't going to happen, at least not in
this time-space continuum, nor is "a lot of time" going to suffice. The vastness of the
keyspace alone makes that true: you're talking many, many times the heat-death of the universe,
even with every computer on the planet working 24x7.
Add in the requirement to recognize the decrypted data when you've found it,
and it's even worse. A simple example: if I encrypt a ZIP file with DES (56 bit
keystrength) and you believe it's a .doc file, you will cheerfully cruise right
by the correct key, because you won't see the .doc signature you're expecting.
If you're trying to decrypt an encrypted volume, maybe you can look for
eyecatchers in the VTOC or something; but if not, the problem is orders of
magnitude harder right off the base.
2) Not to pick a fight, but this doesn't strike me as that unreasonable.
Seems cheaper to do the degaussing to all drives rather than trust internal
records to be correct as to which volumes were used where: the cost of being
wrong is less than the cost of the wasted effort. But sure, we can easily come
up with cases where applying policy is even less plausible.
(I couldn't resist) Cheaper??? Absolutely obvious case - never used,
never attached dasd array vs process of demounting several dozens disk
drives, one, by one. What's cheaper here? What's wrong with declaration
it was never used? Last, but not least: what is warranty that
"degaussed" disks were really degaussed? A paper protocol? People lie,
people do make mistakes.
And what about n-times overwrite policies? What number is proper? Does
one need to overwrite disk content once, twice, 3 times, 7 times or 21
times? What's the magic number? And what is the reason for the number?
--
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 authorized 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.
mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: [email protected]
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.2014 r. kapita zakadowy mBanku S.A. (w caoci wpacony) wynosi 168.696.052 zote.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
