Mark Russinovich has an excellent post on his Sysinternals blog: Sony, Rootkits, and Digital Rights Management Gone Too Far, where he says:

"Rootkits are cloaking technologies that hide files, Registry keys, and other system objects from diagnostic and security software, and they are usually employed by malware attempting to keep their implementation hidden (see my “Unearthing Rootkits” article from the June issue of Windows IT Pro Magazine for more information on rootkits). "

Greg Hoglund, author of the book "Rootkits" defines them this way (page 4):

"a rootkit is a set of programs and code that allows a permanent or consistent, undetectable presence on a computer."

The question in my mind is, is this really a rootkit? Mark uses the term in his discussion, and it appears that what he found fits into his definition (above) simply because it hides itself. Schneier seems to agree as well, based on his use of the word. Shostack focuses on the DRM/control aspect of things and never uses the word "rootkit" (I wonder if that was on purpose).

When I look at the two definitions offered above, there is a glaring difference in focus: Russinovich considers the hiding techniques to be the driving indicator while Hoglund suggests it is the utilities and/or the malware. I think rootkits, botnets, and spyware all share similar characteristics in their interest in hiding. Traditionally, the notion of a "kit" was to have that toolbox of utilities and implies ongoing, at-will control over the box – perhaps bot-like, but not necessarily so – by an attacker.

The only real reason this matters is if you are doing an in-depth risk analysis. There are a few of important questions to ask:

1) How much control does an attacker have over the system? Is it direct, interactive control or remote control or no control? (In the case of Sony, it is either no control or an argument for indirect control).

2) What can the attacker do on the system? Can it use the system in an attack, steal information from the system, store inappropriate data, etc…?

3) What impact does the software have on the system? Does it disrupt processing in some way?

Your answers to these questions may assist in determining whether you need a dedicated tool to focus on the problem area, can leverage an existing multi-layered approach, or use a general purpose single solution.