Bruce Schneier points out, rightly, that Microsoft should release its internal-only security tool (codenamed GhostBuster) as an open source project, or at the very least, as a commercial tool for people managing Windows deployments. He is absolutely dead on; no matter what state this product is in, it is in Microsoft's, and all of our, interest to get that in the hands of the public as soon as possible.

However, I'm not quite as keen on this tool as I am on something like Tripwire. GhostBuster relies on something inherently unreliable to do its job: the behavior of malicious software. One of the most common kinds of security problems found in the wild are rootkits. These are pieces of software that live on the machine, waiting for instructions from off-server (usually from an IRC server). More insidiously, they usually hijack system services to hide their existence, by filtering system requests for directory listings, registered ports, etc.

GhostBuster works by running a program within the potentially affected OS to, essentially, list all the files on the machine (its more complicated than that). Then, you boot to the GhostBuster CD and run the same program, this time from the bootable OS on the CD. This version of the program won't be infected by any rootkits, and any files hidden during the first run will show up. GhostBuster then compares the two result sets and alerts you to the different (malicious) files.

This is a great idea, but as I said earlier, it relies on assumptions about what the rootkit is doing in order to work effectively. If a rootkit adapts to recognize when the GhostBuster program is being run, it can choose not to hide the offending results from the program. This will cause a tit-for-tat war of escalation, exactly like what we have in the anti-virus world.

Tripwire, and tools like it, work differently. You only run these tools from bootable CD, thus ensuring that they are never tainted. The tools check the files on a given disk, and record statistics about those files. Using highly configurable rules, the app then checks the results of future runs against the baseline, alerting you to changes. This means that, instead of fighting against the behavior of malicious code, you are fighting against the behavior of your own system administrators (changes will either be malicious code or normal changes to the system, and your rules have to rule out the good changes). This strikes me as an inherently more stable approach.

However, I'd love to have GhostBuster in my own tool-chest, and a truly effective rootkit detection strategy would employ both approaches.