Ron,
Please, read carefully my first words:
I did mean DISK overwrite.
Eazytier or other vendors features, or SVA-like type of emulation make
it hard to overwrite DISK (physical disk) from host level. However your
point contains another assumption, untypical IMHO: logical volume
overwrite. Not whole dasd array, but (single) logical volume. Well, even
RVA/SVA can be overwritten effectively when you fill up all the volumes
with uncompressible data, like mentioned MP3 files. The same would apply
to current HDS array, even with Eazytier - just because one overwrites
whole array.
Of course it's still not as good as overwrite of physical disks, because
every array do have spare disks, "special" disks for internal purposes
(are there business data there?), etc.
Regards
--
Radoslaw Skorupka
Lodz, Poland
W dniu 2014-01-29 09:34, Ron Hawkins pisze:
Radoslaw,
One of the problems I see with Host based overwrite is that you can only
overwrite the current location of the logical volume.
If you are using IBM's Eazytier, or Hitachi's HDT you really do not know the
past location of the chunks of the volume, only the last location. The same
problem exists for volumes copied with volume copy products that dynamically
allocate the target address. Once the relationship is removed how do you
know where it was and what is left behind.
I'm a strong believer in encryption of data at rest. I can't imagine that
anything can be assembled from the residual image at the edges of a track
when said track is encrypted with a strong key length. A single overwrite
will defeat decryption by luck or stealth
I would hope that best practice for overwriting a disk array before removal
would be to format the drives as useable volume space front to back and
overwrite all of those volumes. One pass is enough with encryption at rest,
and as many as you feel is enough for data in the clear.
Ron
1. I did mean DISK overwirte. Not some emulated gismo, especially not dasd
arrays like Iceberg/RVA. That's completely different story and - important
-
it's still not applicable to number of writes. The problem in such arrays
is to
really overwrite the disks, no matter how many times. It's important to
overwirte al least once, but every disk area, each copy. It's more like
caution
to delete dataset *and* its copies and backups.
(Disclaimer: spare sectors on HDD is yet another story.) 2. Fun story:
some
company used special software to overwrite PC HDDs.
The number of writes was set to 5. Reason: default was 3, "but we want
more security".
3. Regarding possibility rto read *valuable* information overwritten
once: Such theoretical possibility assumes one use good microscope and
watches single magnetic domain. There is no hidden HDD command like
"read deleted info". And now: what is easier: decrypt encrypted content of
play with 100000000000000000-element puzzle of domains?
--
Radoslaw Skorupka
Lodz, Poland
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
--
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
