Spider2008 differs from previous Spiders in several key ways: One-user/One-cleanup model.

l. That is, Spider2008 is intended to be run by an end user, across their own files, and revisited periodically as part of a sensitive data cleanup effort. To keep performance up and false positives to a minimum, Spider2008 takes a files-to-scan approach in contrast to its predecessors files-to-skip approach. That is, without changes to the default configuration, Spider2008 scans a limited handful of file types likely to contain sensitive data: o Mailboxes o Office documents, including OpenOffice, MS Office 2007, MS Office through 2003 o PDFs o Some database formats, including FoxPro, Access, FileMaker, most dBase III/IV derivatives o Compressed archives including ZIP, Gzip, and BZip. o HTML o Legacy formats such as Quattro and Lotus 1-2-3 files Included regular expressions have been consolidated and tuned for better performance. For example, the SSN regular expression assumes a search for both 3-2-4 and 9-digit formats, with the former taking a wide variety of possible delimiters. Spider2008 can scan EFS encrypted files, provided key material is available to the user context in which it runs. Spider2008 will also attempt to reset file access times as it scans. This is a convenience function only and should not be used in an incident response or forensics context without appropriate measures to prevent modification of evidence. Stateful scanning. A scan history, including enough configuration information to repeat a scan, is stored in \documents and settings\you\local settings\application data\spider\state Scan histories are unique with hourly granularity. This means that repeating a scan within an hour implies the need to import the previous scan and resume work. This is done by searching for changed files and giving the user the choice to scan changed files, scan files not processed in the last scan, or proceed without a new scan. Scan histories are transparently encrypted by SQLite. The key for this purpose lives alongside Spider2008s installation and should be changed from the distributed key. This key should be unique per machine, domain, subnet, business unit, or whatever site-specific partitioning is appropriate. Spider2008 supports transparent Web updates and unattended scanning. Both features are not tested to the degree necessary

for this release (12 Jan 2009) and are disabled until theyre ready. Remediation convenience features are included in the utility: o Securely erase or move a file, using DoD 5220.22M overwrite o Move the file to the recycle bin o Ignore the file as a false positive o Mark the file as having valid hits but the file must be retained on the system o Open the file in its native application o For text files and mailboxes, redact matches individually or in total A few deployment notes: Spider State Files: These things end in .ss3 and are SQLite databases. Spider keeps some config information inside, as well as matches and text surrounding a match. These are sensitive data by virtue of this. Handle them as such. Though encrypted, they should be treated with the same care as the original files they reference. SQLite Encryption: This is handled transparently by Spider2008. The file entropy in its install location is the key. Yes, I know there are better key management practices, but until the sensitive data is removed from the machine, the weakness of this design is the least of your worries. Once the cleanup is done, erase the SQLite state files ASAP. One of the obvious implications of this design is that unless you replace that file with one of your own (doesnt matter what kind or how big; a JPEG is a good choice), anyone with a copy of our distribution can read the state files. Spider will make every effort to remove cached hits from its state database as files are cleaned up through its interface. Still, state files should be considered sensitive and removed when the cleanup effort is done. Spider Incremental Scanning: Spider assumes any scan repeated within one hour is intended to be the previous scan. That is, itll import the settings and matches from the scan state file that exists for that hour, search the DB for unscanned files, and search the drive for files that have changed. The only way to change this behavior is to nuke the previous state file.