How Symantec Endpoint Protection Device Control processes Windows device GUIDs and device IDs.

Products

Endpoint Protection Critical System Protection

Issue/Introduction

Overview

This document explains Windows device GUIDs, device IDs and hierarchies and how this information is processed by Symantec Endpoint Protection (SEP) Device Control. A key concept is the Windows' organization of devices into device classes, which can include multiple types of physical devices through the device hierarchy. This document shows how SEP Device Control policies will be processed.

Resolution

Investigating device information

SEP operates specifically on the device GUID and device ID (“[guid]” and “[device id]” field in the device property window, See Fig. 1) when defining and matching rules. Windows device manager or the SEP DevViewer tool allows Windows device hierarchies to be easily examined. The SEP DevViewer tool (see related article) is recommended since the GUI is specifically designed to show all necessary device properties in a direct way.

Fig. 1

About Windows device GUIDs and classes

A device GUID is a unique identifier that identifies a device class. Symantec Endpoint Protection Manager (SEPM) displays a list of generic known device classes and GUIDs (See Fig. 2). DevViewer shows a list of real devices connected to that system. SEP Device Control can determine the list of device class GUIDs that apply to each physical device. By applying GUIDs in SEP Device Control policy, supported devices can be allowed or blocked, depending on the action of a rule.

For example, if the USB class GUID is specified in a blocking rule, all USB devices will be disabled when they are connected to USB ports. Notice that this device class operates within the hierarchy, since different kinds of physical devices such as cameras, mice and storage devices will all be blocked.

Fig. 2

Understanding logical device classes

The USB device class is an example of a logical device class present in the Windows device hierarchy which applies to multiple types of devices. These device classes can include multiple different types of physical device classes, potentially causing an unexpected overlap of the policy rules that apply to a specific physical device.

Another example of a logical device class is a “Storage volume” which does not correspond with a specific real physical device type. Windows creates a storage volume device class after a physical hard disk/USB disk/other storage device is connected to system and partitions (logical drive letters) are allocated.

Fig. 3

To show relationships between different devices, we can choose “View devices by connection” in DevViewer. In Fig. 3, The SanDisk Cruzer device hierarchy shows the system created USB mass storage disk drive and generic storage volume device classes. Switching the display to “View devices by type”, these disk and volume devices will now appear under the “Disk drives” and “Storage Volumes” branches. (Note: on Vista/Windows 7 systems, device hierarchies may not be displayed completely, however Device Control will still apply to all matching classes in the device hierarchy.)

Understanding the device hierarchy and logical devices helps administrators to configure Device Control that behaves as expected. From the above example, one can predict that a rule to block “Disk drives” will block all physical disks including internal and external USB disks. Similarly a rule to block “Storage volumes” will block all logical partitions without regard to type of the underlying storage.

About Device IDs

Device ID is a unique identifier that identifies a specific device in the system. Generally device ID consists of type string prefix, e.g.” IDE\CDROM”, followed by a string describing the specific device model. By applying device IDs in SEP Device Control policy, specific devices can be allowed or blocked, depending on the action of a rule. For example if “IDE\CDROM*” is specified in a blocking rule, all CD/DVD drives that are directly connected to motherboard will be disabled when the policy is applied. Device ID rules have the lowest potential for unexpected policy rule behavior, since these are most closely tied to a specific physical device.

How SEP Device Control works

SEP Device Control module monitors device change messages that are issued by the system. Each time a message occurs, SEP enumerates all devices in the system and checks each device against the rules that apply to the list of device classes associated with that device.

Depending on the rule condition type, SEP client checks device GUID/device ID in two different ways. If a device GUID is specified, a direct string comparison is performed. For device IDs, SEP does a regular expressions match. If a condition is matched, SEP will enable or disable the device depending on the rule action. The action to enable or disable the device is much like a user performs the same operation in Windows device manager.

Windows devices exempt from device control

Some Windows system critical devices can never be disabled. For example, Windows won’t permit disabling of the “CPU” device. In Windows device manager, the “Disable” or “Enable” menu item is not shown after right clicking on the “CPU” device. In DevViewer, the “[can be disabled]” field in the property window (See Fig. 4) can be examined. The SEP client checks this status before disabling a device and won’t operate on these devices.

Fig. 4

About the SEP built-in white list

To protect against policy configurations which render hardware unusable and allow the utilization of some broad logical device classes, SEP uses a built-in white list to prevent policy control on specific devices. SEP will ignore any Device Control policy for such devices.

Current white listed devices:

² USB/PCMCIA/FireWire(1394) controllers.

Blocking these devices can cause unexpected behavior, since the controller as well as any connected devices are affected. Create policy targeting the devices and device classes the controller supports.

² Disks and volumes containing the system OS or page file.

Blocking these devices can cause unrecoverable system errors (BSOD). SEP will not disable these devices, but other disks and volumes can be blocked with policy.