Onderwerp: Putting the "NSA Data Overwrite Standard" Legend to Death...

OK, I'm sure this one will start a flame war, but...I work for a vendor
whose products overwrite files when "deleting" them as a way of protecting
old data. Lately several customers have been asking for "NSA" or "DoD"
standard overwrites, usually with a value of 3, 7 or 9. (Our response to
the feature was to more or less let the owner of the product pick the
number of overwrites; the obvious tradeoff is morewrites=slowerdisk.)

Anyway, while researching how we wanted to document recommended values for
the overwrite feature, I looked into the "DoD" and "NSA" standards.

I was not surprised to see that a "DoD standard" DOES exist:
Government name: DoD 5220.22-M
A nice summary: http://www.zdelete.com/dod.htm (not my product)
Some original documents: http://www.dss.mil/isec/nispom.htm
Long story short: 1 overwrite = CLEAR, 3 overwrites = SANITIZED
(non-removable rigid disk)

I was surprised, however, to learn that a "NSA standard" DOES NOT exist.

I did the usual Google searches and came up with nothing but various sites
and postings claiming the standard was anything from 5 to 20
overwrites. Then I called the NSA (1-800-688-6115
- http://www.nsa.gov/isso). The first person I chatted with passed on the
question, but the second answered the question in no uncertain terms - NSA
is aware of DoD 5220.22-M and DOES NOT have a separate recommendation.

So...could this finally be the end of IT employees casually tossing around
the "NSA overwrite standard" - or is there something I'm missing?

Second, where did the number 7 really come from? (It seems to be the
leading recommendation out there right now for number of overwrites and is
frequently attributed to the NSA.)

- Jonathan Lampe, GCIA, GSNA
- jonathan.lampe@stdnet.com

--Er/3qITiDpnrteFh
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline



> Near as I can tell if someone says they are doing NSA overwrites, they are
> full of shit. In addition, based upon Mr. Gutmann's paper and the fact
> that it is quite old, one can assume that with advanced forensics the
> simple 3, 7, or 9 time overwrites that these products are claiming as
> secure actually are not even close to the level of security they claim. In
> fact, by following this "glossy brochure" de facto standard, data is not
> secured from recovery by an advanced recovery effort at all.

And worse yet, your data may well live in other places aside from the
official blocks on the disk. If you're using a journaling file system,
your data was probably written to the journal before going to the
final blocks. If the data was read by a process that swapped, your
swap partition may contain a copy of the data. If the filesystem
layer decided to move your data around on the physical disk for
some reason then the original location will not be overwritten by
our standand 'write junk x times' method.

To my knowledge there is no 100% guarenteed method to delete your
bits irrevocably from the hardware without writing over the
entire disk[1], not just the parts officially allocated to the file
at any given time.

[1] multiple times with different data each time, as meantioned before.

--
Brian Hatch "Cannot say. Saying I
Systems and would know. Do not know,
Security Engineer so can not say."
www.hackinglinuxexposed.com

Every message PGP signed

--Er/3qITiDpnrteFh
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAj5ASqkACgkQidaA3abfMorVNwCeOmFvxseZPR nEEdPPxRTztO1o
KQIAniupFqDWXtUsWit4/EQv+7hgrDWg
=ZTPV
-----END PGP SIGNATURE-----

--Er/3qITiDpnrteFh--

This is the tip of the iceberg.

Another concern is NTFS filesystems, data can be stored in the MFT if it is
small enough (i.e. under 1 or 4k depending on how your drive got formatted).
I also found that when using alternate data streams:

cat "this_is_a_string_of_text" > somefile.txt:an_ads_stream

that the string was then found on the HD twice immediately afterwards.
Wiping the file (with tools that wiped alternate data streams properly) got
rid of one copy, but you had to do a wipe free space to get rid of the
other. Not sure if this was a journaling issue or what, but if you want to
get rid of alternate data streams make sure you wipe free space.

There are other hardware/software issues too:

IDE/scsi bad block mapping at the device level
bad block mapping at the OS level (although intelligent software might be
able to deal with this)
RAID arrays, I haven't yet experimented much with wiping data on RAID 0 or 5
arrays for example but I suspect the results will be interesting.
Increasing reliance on network storage
Disk defragmentation, your data just got copied around, possibly more then
once (ever watch the soothing patterns in Win98 defrag =).

I did a presentation on data deletion and wiping at Hivercon, the
presentation is available in PowerPoint at:
http://www.hivercon.com/hc02/speaker-seifried.htm

The next version should manage to be even more depressing.

Kurt Seifried, kurt@seifried.org
A15B BEE5 B391 B9AD B0EF
AEB0 AD63 0B4E AD56 E574
http://seifried.org/security/