Operating systems such as Windows keep track of devices—disk-on-keys, printers, cameras, headphones, mobile phones, and the like—utilized by users. These devices can be connected via physical or wireless ports, utilizing more than two-dozen protocols ranging from wired protocols such as USB and Firewire, to wireless protocols such as IrDa, Wi-Fi, and Bluetooth.
Although the information Windows saves differs depending on the device and protocol at hand, users can usually acquire information about devices previously connected to a computer. For example, you can learn that a user connected an encrypted disk-on-key to "Joe's" computer, the key manufacturer was Kingston, the key size 128 MB, and so on. Metadata describing this information can be retrieved years after the device was connected to the computer.
This data is valuable to security professionals who use it to learn how computers are used within organizations. For example, a Chief Security Officer (CSO) conducting a risk assessment or incident research would find such information helpful. However, this information could also be used by an unauthorized person who may learn about the organization's device usage from a computer he has access to while breaching the company's privacy.
Modern hardware devices contain information that assists the operating system in finding appropriate drivers to handle the device. This is true for all modern ports—USB, Firewire (IEEE 1394), Bluetooth, PCI, and PCMCIA.
Take USB, for example. Each USB device has to report the information in Table 1 during its handshake process with the host computer. While Table 1 has parameters that are unique to the USB port, other ports have other identifier types. To identify devices in a generic way, Windows translates these IDs to the standard IDs in Table 2. This translation is done by the USB drivers that are an integral part of Windows 2000/XP/2003/VISTA.
| Field name | Description |
| VID (Vendor ID) | Two bytes identifying the vendor; e.g., 8086 is Intel's vendor ID. This ID is assigned to vendors by the USB-IF group. |
| PID (Product ID) | Two bytes identifying the product. Each vendor assigns a unique product ID for each of its product (the same PID may be used by different vendors for different products, of course). |
| REVID (Revision ID) | Two bytes identifying the revision of this product. |
| USB Class | Two bytes identifying the USB class that this device is a member of. Examples of classes: Audio (01), Communications (02), Human Interface devices (03), etc. |
| USB Subclass | Two bytes identifying the subclass of the USB class that this device is a member of. The list of subclasses in the audio class is: Control Device (01), Streaming (02), and MIDI Streaming (03). |
| USB Protocol | Two bytes identifying the protocol to be used. This parameter is relevant only to some USB classes. Examples of protocols taken from the Communication class (02) subclass modem (02): None (00), GSM (04), 3G(05), CDMA (06), Vendor Specific (FF). |
| Serial Number | (Optional) Eight bytes identifying the device uniquely. There shouldn't be two devices with the same VID,PID, and Serial Number. Unfortunately, there are vendors not obeying this rule and issuing non-unique serial numbers. |
| Identifier name | Description | USB example |
| Hardware ID | A series of IDs identifying the device's model, manufacturer, or revision. | USB\Vid_XXXX USB\Vid_XXXX&Pid_XXXX USB\Vid_XXXX&Pid_XXXX&Rev_XXXX |
| Compatible ID | A series of IDs identifying which devices this device is compatible to. | USB\Class_XX USB\Class_XX&SubClass_XX USB\Class_XX&SubClass_XX&Prot_XX |
| Device Instance ID | A unique ID for the particular device. | USB\Vid_XXXX&Pid_XXXX\SERNUM (where SERNUM is replaced with the hexadecimal representation of the serial number of the device) |
