Does Document Detective replace the NTToolkit (Buster, Secure Copy, and Flush)?

Document Detective will scan any file for keywords, so it does replace Buster. Document Detective will warn you when the file type is not recognized, which means the scan is not reliable. Buster is also unreliable in these circumstances, but it may not warn you.

The requirement for Secure Copy and Flush is a bit more complicated, because it is governed by outdated institutional policies. Technically speaking, Secure Copy and Flush are not required as long as you are using a Windows NT based operating system with NTFS formatted media. Unfortunately, we have not been able to get the Government to recognize this or to establish updated policies. You will have to go by your organization's requirements.

The following information is provided to help you request a deviation to your organization's security policies. It is an excerpt from an email exchange between our lead developer and an engineer at Space and Naval Warfare System Command (SPAWAR) who researched this issue for the Government.

From: Mildner, John Spawar
Sent: Monday, April 28, 2008 8:50 AM
Subject: FW: DD Class (UNCLASSIFIED)

I support the community as a resident geek and have worked the slack and free space issue for decades. As Ron Hackett notes, this issue emerged in the days of MS DOS. DOS and the single user Windows did a lot of block level writing where whatever data happened to be in a disk buffer would written in the last block/sector of a file. NT imported the Unix data stream concept, access control, and object reuse into NTFS. NT does zero the slack space when writing. NT eliminated most concerns of unintended data being appended when files were moved from one media to another. Assuming that your application (e.g., file explorer, Nero, etc) is using the Windows file stream interfaces (and there is little reason for them not to), then those application cannot read any data past the end of file. If applications don't receive slack space data, then applications can't pass the slack data down to the releasable media.

If you use releasable media as the destination media for the transferred data and use a "modern" OS, then there is no need to overwrite the free and slack space on the media prior to release. If you are concerned that there are malicious processes operating on your transfer system and are performing covert exfiltration of classified data, then you need tools that do more than just overwrite the free and slack space on media. Free and slack space overwrite tools are appropriate for sanitizing media involved in classified spillage incidents but, these days, are typically unnecessary for AFT [Assured File Transfer].

v/r
John W. Mildner, CISSP
Chief Engineer, IA Division
SPAWAR Systems Center, Charleston

Furthermore, a disk filler routine is not necessary for flattened Microsoft Office documents. When Document Detective flattens the document, it forces the storage type to OLE 2.0 specific file types to ensure the document can be properly reviewed. One advantage of the OLE 2.0 file formats used by Document Detective is that they are always divisible by 512 bytes. Unless someone alters the default cluster size of an NTFS file system, the file will always fill the available disk space. Even if someone alters the cluster size, the hardware buffer for the ATA hard drive is 512 bytes, which mitigates the effect of the larger cluster size.

This is not necessarily true for Office files that have not been flattened. There are older Office formats that are not divisible by 512 bytes, and unless the user knows what to look for, these files do not appear to be different than newer Office formats.