Talk:National Industrial Security Program

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

PDF vs web page[edit]

Juanpdp has twice changed the NISPOM link to link directly to the PDF of the Feb 2006 edition of the NISPOM. I believe we are better served by keeping the link as it is now -- a link to the general NISPOM page at DSS. Direct linking to a PDF is considered sub-optimal by many, myself included. Many people find it surprising; not everyone can read PDFs; reading PDFs generally needs a new window or program to be opened; the PDF in question is large. The edition of the NISPOM is likely to change in the future, but the general DSS webpage is more likely to remain static. There is also more information available about NISPOM on the general web page. Currently, it's somewhat minimal, but it is still useful. The PDF being linked to is available from the general NISPOM page, so we are not loosing anything by linking to the web page. I do not see any benefit to linking directly to the PDF. --DragonHawk 12:55, 17 August 2006 (UTC)[reply]

Agreed. However, the link to the general NISPOM page has also changed now. At least update the current link so it is not broken. --Ryan Simoens, 0927, 25 September 2007 —Preceding unsigned comment added by 205.175.225.22 (talk) 14:35, 26 September 2007 (UTC)[reply]

Fixed. Thanks for pointing that out. Feel free to be bold and make such improvements yourself! :) —DragonHawk (talk|hist) 06:33, 25 November 2007 (UTC)[reply]

Categories[edit]

It was pointed out that this article should be categorized. True. I tried to find some existing categories which fit this article The NISP isn't really an agency per se (it's a program administered by multiple agencies), but that seemed the best fit. I put it under intelligence agencies because ultimately, it's the NSA which drives this stuff. I also put it under DoD agencies because most people associate it with the DoD/DSS. I put it under classified documents because it's one of the definitive references on classified document handling. That cateogory is already used to categorize not just articles about actual classified documents, but the field of classified documents (e.g., sanitization). Finally, I put it under data security because the idea that DoD 5220.22-M is a data security/file wipe standard is a popular misconception. Improvements/suggestions welcome. --DragonHawk 16:15, 28 November 2006 (UTC)[reply]

Warning says "reads like an advertisement"[edit]

As a government contractor I have done extensive work in the security field and with NISPOM. The article appears straightforward to me and does not sound like an "advertisement" for anything.204.249.77.1 15:39, 17 July 2007 (UTC)MikeReed[reply]

"Me too." I have asked the Wikipedian who added that tag to please comment here. —DragonHawk (talk|hist) 02:13, 26 July 2007 (UTC)[reply]
Okay, user never explained, I've removed the tag. —DragonHawk (talk|hist) 01:50, 4 September 2007 (UTC)[reply]

C&SM rev date[edit]

EvilCouch changed the date on the cite for the C&SM (Clearing and Sanitization Matrix) to 28 June 2007. Mr. Couch is correct in that that's the date given in the document itself. The 12 Nov 2007 date I gave in my original cite was based on this DSS web page, which states "Clearing & Santization Matrix (06/28/07, revised 11/12/2007)". I'm not really sure what the "most correct" action here is. I suppose it could just be the link that was revised, or something else trivial like that, and not the actual document. That would prefer the June date. Or it could be the document was revised, but they forgot to change the date in the document. That would prefer the Nov date. Lacking a better idea, I'm gonna leave it at the June date, but wanted to note this info here. —DragonHawk (talk|hist) 03:19, 25 December 2007 (UTC)[reply]

An overwriting standard: there was some truth to it in the past[edit]

Having stumbled upon this article a couple days ago and reading many of the relevant documents from the DSS and DoD, my first thought was: 'Is this yet another case of many fools on the Net merely parroting an error made by one?' But closer examination of old superseded copies of DoD 5220.22-M, reveals what started the flood of quotes about how to perform a so-called DoD-Wipe "per 5220.22-M": Its origin can only be found in older copies, such as the January 1995 or the 'Change 1' document of 1997; but definitely not in the 2007 edition of NISPOM. In the file here: http://www.allegro.com/products/d522022m.pdf, inserted between sections "8-306(i.)" and "8-400. Networks," is a freestyle table titled "Clearing and Sanitization Matrix." Three of the notes (c., d. and e.) listed underneath this table are relevant to hard disk overwriting:

c. Overwrite all addressable locations with a single character.
d. Overwrite all addressable locations with a character, its complement,
then a random character and verify. THIS METHOD IS NOT APPROVED FOR
SANITIZING MEDIA THAT CONTAINS TOP SECRET INFORMATION.
e. Overwrite all addressable locations with a character, its complement,
then a random character.

I know this isn't very specific, but note "d." does contain enough information for what I'd call a 3-pass overwrite with a verification process in order to sanitize a disk. I have, however, yet to discover why many web sites refer to a 7-pass 'DoD-wipe' (usually a pair of 'byte then its complement' passes, 3 times in a row; for 6-passes, followed by either a random or another specific byte)! Daniel B. Sedory (talk) 09:44, 16 June 2008 (UTC)[reply]

After spending a great deal of time researching more security documents dealing with overwriting (e.g., see references in the article Data_remanence under the section "Standards"), I'm starting to think my initial suspicion may be correct: That some person or group incorrectly interpreted the notes you see above by deciding that each one was supposed to be combined as a single process! If you add up all the passes, you get 1 (note c.) + 3 (note d.) + 3 (note e.) = 7 passes. This would be similar to how many ignorant readers have thought that Prof. Gutmann's paper on data remanence was suggesting we perform 35 passes on each hard disk, whereas he actually described various sets of overwrites depending upon the hard disk's construction (type of drive; e.g., MFM, etc). If you search the Net for any reference to a 7-pass wipe, you may also find "DoD 5220.22-M" followed by either "/E /C /E" or "(ECE)" which is possibly nothing more than a corruption of "c., d. and e." (in other words, merely a reference to the same notes shown above). Interestingly, they almost always leave out the verification pass mentioned in note "d." (presumably that's more difficult to implement in their software) and very few pages discuss what to do if a disk has 'bad sectors' that could not be overwritten. Daniel B. Sedory (talk) 07:45, 24 June 2008 (UTC)[reply]

As soon as I woke up this morning, I realized any reference to a "DoD 5220.22-M (ECE)" is highly likely to be directly related to the notes shown above in an effort to make the original DoD 5220.22 document conform to someone else's so-called 'government 7-pass overwrite' method: They simply pick a number of passes from the notes by combining "e." (3 passes) then "c." (1 pass) followed by "e." (3 passes) again to arrive at a '7 pass' total; a sort of last ditch effort to keep their citations of DoD 5220.22 by making them at least appear feasible. Any rational reading of the Clearing and Sanitization Matrix (C&SM) table embedded in the 1995/1997 editions of NISPOM shows that to be a ridiculous idea. The table clearly shows that none of the media listed there have both "e" and "c" specified (let alone using "e", twice). Furthermore, hard disks (listed as "Non-Removable Rigid Disks" in the table) are to be cleared by just following note "c" and sanitized by following notes "a, b, d, or m". Note the word "or " in that list for sanitization; it meant that one could degauss a drive using "a" or "b," physically destroy a disk using the methods in note "m" ("Destroy - Disintegrate, incinerate, pulverize, shred, or melt.") or follow note "d" (as shown above). There were no extra passes specified in this document; just 3 plus verification. Daniel B. Sedory (talk) 07:48, 25 June 2008 (UTC)[reply]

Made an important discovery last week: Though I've yet to figure out what possible train of thought could allow whomever actually authored the following statement to reach this conclusion from what precedes it, in a Memorandum disseminated by the Assistant Secretary of Defense (Command, Control, Communications and Intelligence; also known as "C3I") titled, "Disposition of Unclassified DoD Computer Hard Drives" [found as an attachment to this document: https://www.drms.dla.mil/rtd03/draft_conops.pdf] and dated June 4, 2001, we find under the section, "2. Overwriting Hard Drives for Sanitization" (of the original "Attachement 2"): "To purge the hard drive, the DoD requires overwriting with a pattern, and then its complement, and finally with another pattern (e.g., overwrite first with '00110101', followed by '11001010', then '10010111'). Sanitization is not complete until all six passes of the three cycles are completed." This is only mentioned one other time in subsection "2.1.5." of the attachment: "A capability to overwrite using a minimum of three cycles (six passes) of data patterns on all sectors, blocks, tracks, and slack or unused disk space on the entire hard disk medium." One can easily see from the example given (writing the three hex bytes of: 35h, CAh and 97h) and from earlier discussions in paragraph "2.1," that "pattern" refers to a single hexadecimal byte and "cycle" to writing the same hex byte to every location on the drive (i.e., three byte patterns = three cycles). But no logical justification is ever given for the "six passes" it mentions. It's presented in a way that seems we're supposed to already know (from some undisclosed document?) that the DoD always writes these three "cycles" a second time! Curiously, this still does not explain why the many commercial so-called DoD-wipe products perform 7 passes instead of the six passes found here. Any ideas? Daniel B. Sedory (talk) 12:30, 26 July 2008 (UTC)[reply]

Slightly revised some of the above, and wish to add: Symantec's documentation (or 'attempted correction') of their "GDisk disk wipe specifications" (ftp://ftp.symantec.com/public/english_us_canada/products/ghost/manuals/DoDwipe.pdf), never explains why it performs 7 passes when one document it refers to contains only a 3-pass wipe (note "d." of the DSS C&SM; what Symantec calls "action d" here) and the other (a "June 2001" DoD memorandum) describes a 6-pass wipe! Instead we find this description:

"GDisk performs a sanitize operation, as defined by action d, when performing a disk wipe operation with the /dod command modifier.

The following cycle occurs six times:

■ All addressable locations are overwritten with 0x35.
■ All addressable locations are overwritten with 0xCA.
■ All addressable locations are overwritten with a pseudo-random character.
■ All addressable locations are verified in hardware using the Verify Sectors command to the disk." (page 3 of Symantec PDF document; linked above)

It's difficult to conform the words "the following cycle occurs six times" with reality. What follows them is a list of four items (6 x 4 = 24 is obviously incorrect; so would 6 x 3 = 18 be, as well). I've tested their program, and it consistently completes overwrites to a disk in this order: 0x35, 0xCA, 0x97, 0x35, 0xCA, 0x97, 0x35 (yes, the drive always ends up with sectors full of 35h bytes), writing to a disk seven times in a row. In all fairness to Symantec, it's most likely an error that the final author of this document did not separate the last item listed above ("Verify Sectors") from the first three; in which case, you could understand the "cycle" repeats twice, for a total of 6 overwrite passes plus a verification pass. But I have yet to determine whether it actually performs any verification, and if so, then why does it write 0x35 to the whole drive after the first six passes? Logically, it should simply "verify" (by reading every sector on the drive) that the last byte it wrote is still there! Daniel B. Sedory (talk) 22:31, 27 July 2008 (UTC)[reply]

Feb. 2021 32 CFR Part 117 replaces 2006 NISPOM[edit]

https://www.dcsa.mil/mc/ctp/NISPOM-Rule/ "On February 24, 2021, 32 CFR Part 117, “National Industrial Security Program Operating Manual (NISPOM)” became effective as a federal rule." "...replaces the NISPOM previously issued as a DOD policy (DOD 5220.22-M)"

The full regulation can be found at https://www.ecfr.gov/current/title-32/subtitle-A/chapter-I/subchapter-D/part-117 — Preceding unsigned comment added by Allicin1975 (talkcontribs) 14:12, 26 February 2022 (UTC)[reply]