todd@CINCOM.UMD.EDU.UUCP (12/05/86)
Well, all you VMS security buffs out there. Here's a puzzle to stretch your minds and ease my worries: One of our employees created and edited three technical reports of a hitherto unclassified nature. The files sat on the disk (an RA81) for approximately two weeks, before being TeXed and deleted. After presentation of the reports, they were classified (SECRET-level only). I have none of the wonderful VMS security features enabled. No ACLs, no highwater marking, no erase on delete, etc. Now my questions are (there are several, of course): 1) Is there any option available to me now short of a backup-entire-disk/format-and-write-special-pattern/ restore-entire-disk to ensure (to DIS) that all information in the reports is absolutely unscavengable? 2) Is this backup/overwrite/restore cycle *sufficient* to ensure this (in the eyes of DIS)? You and I both know that the odds of any of the data remaining is slim (the disk subsequently reached 90% capacity), but not slim enough for DoD, I think. I really don't want to have to backup/overwrite/restore an RA81 with a less-than-reliable 1600bpi drive! Anyone got a suggestion to help me out? Thanks, Todd Aven Systems Engineering, Inc. (301)345-1692 ------
GKN@SDSC.ARPA (Gerard K. Newman) (12/08/86)
From: "TODD AVEN" <todd@cincom.umd.edu> Subject: request for help re: proving a file is deleted ... The files sat on the disk (an RA81) for approximately two weeks, before being TeXed and deleted. After presentation of the reports, they were classified (SECRET-level only). ... ... Now my questions are (there are several, of course): 1) Is there any option available to me now short of a backup-entire-disk/format-and-write-special-pattern/ restore-entire-disk to ensure (to DIS) that all information in the reports is absolutely unscavengable? First off, you should probably fire a $ Delete/Erase at the specified file. This will at least over-write the blocks which used to belong to that file with whatever the default erase patterns are. These patterns can be changed by doing what the comments in the file SYS$EXAMPLES:DOD_ERAPAT.MAR suggest. I doubt very seriously that this will be sufficient, however. 2) Is this backup/overwrite/restore cycle *sufficient* to ensure this (in the eyes of DIS)? That is really a question for DIS - there should be some computer security spooks at the local DIS office who can tell you the exact requirements for the classification level of the data involved. Anyone got a suggestion to help me out? You'll be lucky if you get away with just reformatting the disk ... gkn -------------------------------------- Arpa: GKN@SDSC.ARPA Bitnet: GKN@SDSC Span: SDSC::GKN (5.600) USPS: Gerard K. Newman San Diego Supercomputer Center P.O. Box 85608 San Diego, CA 92138 AT&T: 619.534.5076 -------