Patent Description:
Many security exploits are delivered through devices on an enumerated bus, such as universal serial bus (USB) devices, or through devices, processes, or threads posing as such devices on an enumerated bus. Other threats tied to devices on an enumerated bus include insider threats (e.g., stealing proprietary information) and insertion of a base device (e.g., on a laptop, by mistake or directly, by a malicious person). Current techniques for detecting these security exploits and threats are limited. For example, if serial numbers of malicious USB devices are known, such devices may be detected and blocked. Device serial numbers are not always known or available, however.

The relevant state of the art is represented by <CIT> and <CIT>. In addition, <CIT> describes security arrangements for extended USB protocol stack of a USB host system.

The present invention provides a method as detailed in claim <NUM>. Advantageous features are provided in the dependent claims. Also provided is a system according to claim <NUM> and a computer program according to claim <NUM>.

This disclosure describes, in part, a PnP driver associated with a security agent. The PnP driver attaches to device stacks of devices of an enumerated bus (also referred to herein as "enumerated bus devices") of a computing device as upper-device or lower-device filters based on the device classes of the enumerated bus devices. For example, the PnP driver may attach to the device stack of a hub or controller device as an upper-device filter and to device stacks of other devices as lower-device filters. Either while attaching or after attachment, the PnP driver may take action to alter, limit, or otherwise block functionality of an enumerated bus device, such as a USB device. The PnP driver may also perform a system inventory of enumerated bus devices connected to the computing device and create fingerprints for one or more of the computing devices. Additionally, the PnP driver may create and remove CDOs to enable communication with user-mode processes or threads.

As used herein, "enumerated bus devices" include a broad range of device types, such as USB devices defined by the USB specification regardless of whether or not those device types are specifically classified as USB devices by the operating system of the computing device. Enumerated bus devices may include, for instance, any internal or external devices on an enumerated bus.

In various implementations, when loaded, the PnP driver receives a message, such as an enumeration of enumerated bus devices attached to a hub device or controller, from a driver of that hub device or controller. The PnP driver may be attached as an upper-device filter in the device stack of such a hub device or controller. Upon receiving the message, the PnP driver iterates through the enumerated bus devices and determines, for each enumerated bus device, whether the enumerated bus device is a hub or controller. The PnP driver then attaches as an upper-device filter or lower-device filter in the device stack of each of the enumerated bus devices based at least in part on the device class of that enumerated bus device (e.g., whether the enumerated bus device is a hub/controller or is another sort of device).

In some implementations, in a decision phase prior to attachment to an enumerated bus device, the PnP driver may compare indicative features of that enumerated bus device to configuration policies of the PnP driver and may decide to alter, limit, or otherwise block functionality of the enumerated bus device. Such configuration policies may include combinations of indicative features that form indicators of attack (IoA) associated with known security exploits or devices that contain known malicious firmware or firmware that is determined to be malicious based on static properties extracted from indicative features and/or behavioral properties extracted from inspection of data sent to/from the device. Upon determining that functionality of an enumerated bus device should be altered, limited, or otherwise blocked, the PnP driver stores an indication of the decision and may act upon it in one or more enforcement phases, as specified in configuration policy.

In some implementations, the PnP driver or another component may calculate a hash or other unique descriptor for an enumerated bus device. Such a calculation may occur during or after a first appearance of that enumerated bus device for comparison of its indicative features to the configuration policy. The decision reached during the decision phase may then be associated with the hash or unique descriptor so that upon any subsequent attachments/appearances of the enumerated bus device, previous decision is referred to and the comparison to the configuration policies is not repeated. Thus, use of the hash or unique descriptor and its association with a decision saves the need for subsequent processing which would simply repeat the comparison of indicative features to configuration policy.

The ability to identify unique devices also greatly reduces data transmission and storage costs when sending device information to a cloud service, such as a remote security service. For example, a company may standardize on a certain type of mouse for their employees. Assuming these mice are all the same type and were made on the same assembly line, they will all contain the exact same firmware image. This may mean that their indicative features will be identical. Ideally such a hash or unique descriptor would only be reported once, the first time it is seen on any computer, or once per system, for every system. Bounding these hash or unique descriptors is done by restricting transmission based on the SHA-<NUM> hash of all of the indicative features that are collected (currently device, configuration, interface, endpoint), which are called a descriptor set. The PNP driver retrieves a device's indicative features, hashes them, and transmits them to a remote security service if they have not previously been sent on that system. If the same indicative feature set is seen again on this system (e.g., the device is plugged into a different port, ejected and reinserted, or a second identical device is plugged in), it will not be transmitted to the remote security service. This bounding is persisted across system reboots.

In an enforcement phase, the PnP driver may alter, limit, or otherwise block the functionality of the enumerated bus device. Such altering, limiting, or blocking may occur during installation for the enumerated bus device, before its driver has been located, or after installation, during a device start for the enumerated bus device. In this latter case, the PnP driver attaches to the USB device as a filter in the device stack of the enumerated bus device. The PnP driver may then fail a device start command from a PnP manager, causing the device start to fail and the device stack for the enumerated bus device to be torn down. Other altering, limiting, or blocking techniques include altering installation strings or capability flags for the enumerated bus device; requesting powering off, disabling, or power cycling of the port for the enumerated bus device; returning a failure status for an add device routine; removing an identifier of the enumerated bus device from an enumeration of enumerated bus devices; suspending the enumerated bus device by updating a state machine of a hub device; or taking any further action based on the configurable policies.

In some implementations, the PnP driver may also decide to alter, limit, or otherwise block an enumerated bus device after its installation and start based on analysis of traffic associated with the enumerated bus device. For example, the PnP driver, which may be attached to the device stack of the enumerated bus device, may generate traffic and transmit the traffic to the driver for that enumerated bus device. The PnP driver may then monitor the response, and if the response indicates that the enumerated bus device may be different from what it claims to be, the PnP driver may decide to alter, limit, or otherwise block functionality of the enumerated bus device or to monitor it further.

In various implementations, the PnP driver may inventory the enumerated bus devices connected to the computing device and provide that information to a security agent on the computing device or to a remote security service. Such an inventory may be provided in the form of a PnP device tree, for example. The information gathered while inventorying enumerated bus devices may also be used to create a fingerprint for each enumerated bus device that may be used like a serial number to uniquely identify the enumerated bus device. Such gathered information may also be combined with information maintained by a remote security service to generate the fingerprints.

In further implementations, the PnP driver may create a CDO to enable communication between the PnP driver and a user-mode process or thread. The CDO enables the user-mode process or thread to configure or control the PnP driver. The PnP driver may also remove the CDO when either a count associated with USB devices connected to the computing device reaches zero or when the PnP driver receives a shutdown command from the user-mode process or thread.

<FIG> illustrates an example computing environment including a computing device, enumerated bus devices connected to that computing device, and software components for managing and securing the computing device and enumerated bus devices. As illustrated, a computing device <NUM> may include an enumerated bus hub <NUM> (internal to the computing device <NUM>), such as a USB hub, and may be connected to multiple enumerated bus devices such as a mouse <NUM> and a thumb drive <NUM>. Additionally, the computing device <NUM> may be connected to a security service cloud <NUM> and receive security service from the security service cloud <NUM>. The computing device <NUM>, may also include a processor <NUM> and memory <NUM>, the memory <NUM> storing an operating system <NUM>, a registry <NUM>, aPnP manager <NUM>, and device stacks <NUM>. The device stacks <NUM> may each include an enumerated bus driver/physical device object (PDO) <NUM> and a PnP driver <NUM> attached as a filter. Such a filter is often referred to as an F-DO. The memory <NUM> may also store CDOs <NUM> and a security agent <NUM>. Additionally, the computing device <NUM> may have other memory devices <NUM>, be connected to other enumerated bus devices <NUM>, be connected to input/output devices <NUM>, and have connections <NUM> with other computing device(s). Further, the device stacks <NUM> may include at least device stacks <NUM> for the hub <NUM>, mouse <NUM>, and thumb drive <NUM>, each device stack <NUM> including a PDO <NUM> and a function device object (FDO) <NUM>, as well as a PnP driver <NUM> attached either as an upper-device filter above the FDO <NUM> or as a lower-device filter between the PDO <NUM> and FDO <NUM>.

In various implementations, a computing device <NUM> may be any sort of computing device equipped with one or more external enumerated bus ports and/or one or more internal ports found on internal hubs. For example, the computing device <NUM> may be a work station, a personal computer (PC), a laptop computer, a tablet computer, a personal digital assistant (PDA), a cellular phone, a media center, an embedded system, a server or server farm, multiple, distributed server farms, a mainframe, or any other sort of device or devices.

The computing device <NUM> includes as least one hub <NUM>. The hub <NUM> may be a root hub, a non-root hub, or a child hub connected to a root hub. Hub <NUM> may represent multiple connected hubs of the computing device <NUM>. Hub <NUM> may include one or more external enumerated bus ports for physically connecting to external enumerated bus devices, such as mouse <NUM>, thumb drive <NUM>, or other enumerated bus devices <NUM>. Mouse <NUM> may be a cordless mouse that wirelessly communicates with a USB dongle that couples with an enumerated bus port of hub <NUM> or a wired mouse with an enumerated bus connector that couples with an enumerated bus port of hub <NUM>. Thumb drive <NUM> may be any sort of thumb drive that includes an enumerated bus connector that couples with an enumerated bus port of hub <NUM>. Further, the other enumerated bus devices <NUM> may be any sort of enumerated bus devices, such as keyboards, microphones, display devices, audio speakers, printers, barcode readers, image scanners, webcams, game controllers, light pens, projectors, digital cameras, etc..

In some implementations, the computing device <NUM> and security service cloud <NUM> may be connected by any sort of network or networks, such as wide area networks (WANs), local area networks (LANs), the Internet, or any combination of such networks.

In various implementations, the security service cloud <NUM> implements a remote security service that interfaces with security agents <NUM>, security agent PnP drivers <NUM>, or both from computing device <NUM> and other computing devices. The security service cloud <NUM> may aggregate and analyze information received from the computing device <NUM> and other computing devices (such as system inventories, enumerated bus device fingerprints, traffic information, user-login identifications, etc.) and may take actions, such as updating configurations of security agents <NUM>, security agent PnP drivers <NUM>, or both, or sending commands to the computing devices to take some action (e.g., alter, limit, or otherwise block functionality of a device or process). The security service cloud <NUM> may also participate in creating fingerprints for enumerated bus devices, as discussed in greater detail herein.

The security agent <NUM> may be a kernel-level security agent, which may monitor and record activity on the computing device <NUM>, may analyze the activity, and may generate alerts and events and provide those alerts and events to the security service cloud <NUM>. The security agent <NUM> may be installed by and configurable by the security service cloud <NUM>, receiving, and applying while live, configurations of the security agent <NUM> and its component(s), such as security agent PnP driver <NUM>. An example security agent <NUM> is described in greater detail in <CIT>, which <CIT>.

In various implementations, the security agent PnP driver <NUM> (also referred to herein as PnP driver <NUM>) may be a component of the security agent <NUM> loaded based on actions of the security agent <NUM>, operating system <NUM>, and the PnP manager <NUM>. For instance, the security agent <NUM> may write a registry key associated with a hub device, such as a root hub, to the registry <NUM>, causing the PnP manager <NUM> to load the PnP driver <NUM> as an upper-device filter in the device stack <NUM> of the hub device. Once loaded, the PnP driver <NUM> may attach to device stacks of other enumerated bus devices of the computing device <NUM> as a filter, may perform a system inventory on the enumerated bus devices, create fingerprints for the enumerated bus devices, and alter, limit, or otherwise block enumerated bus devices. The PnP driver <NUM> may also create a CDO <NUM> to communicate with the security agent <NUM>, enabling the security agent <NUM> to control and/or configure the PnP driver <NUM> through the CDO <NUM>. Further, the PnP driver <NUM> may identify the user logged in at the time that the already-logged-in user plugs in a new enumerated bus device and report the association of the user-login information with the enumerated bus device to the security agent <NUM> or to a remote security service. The loading, attaching, and other operations of the PnP driver <NUM> are described herein in greater detail with reference to <FIG>.

In some implementations, the processor(s) <NUM> include a central processing unit (CPU), a graphics processing unit (GPU), or both CPU and GPU, or other processing unit or component known in the art.

In various implementations, memory <NUM> may be system memory and is volatile (such as RAM), non-volatile (such as ROM, flash memory, etc.) or some combination of the two. Computing device <NUM> also includes additional data storage devices (removable and/or non-removable) such as, for example, magnetic disks, optical disks, or tape. Such additional storage is illustrated in <FIG> by other memor(ies) <NUM>. Non-transitory computer-readable media may include volatile and nonvolatile, removable and non-removable tangible, physical media implemented in technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. System memory <NUM> and other memor(ies) <NUM> are all examples of non-transitory computer-readable media. Non-transitory computer-readable media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other tangible, physical medium which can be used to store the desired information and which can be accessed by the computing device <NUM>. Any such non-transitory computer-readable media may be part of the computing device <NUM>.

In further implementations, computing device <NUM> also has input and device(s) <NUM>, such as a keyboard, a mouse, a touch-sensitive display, a voice input device, a display, speakers, a printer, etc. These devices are well known in the art and need not be discussed at length here. Ones of such input/output devices <NUM> may be among the enumerated bus devices <NUM>-<NUM> and <NUM> or may be connected to computing device <NUM> through different mechanisms (e.g., a video graphics array (VGA) connector).

The computing device <NUM> also contains communication connections <NUM> that allow the computing device <NUM> to communicate with other computing devices, such as device(s) of the security service cloud <NUM>.

In various implementations, the operating system (OS) <NUM> may be any sort of operating system, such as a Windows® operating system, a UNIX-based operating system, etc. The OS <NUM> may be any sort of software that supports basic functions of the computing device <NUM>, such as scheduling tasks, executing applications, and controlling peripherals (such as enumerated bus devices).

The registry <NUM> is a database that stores low-level settings for the OS <NUM> and for applications of computing device <NUM> configured to use the registry <NUM>. The registry <NUM> may also be part of OS <NUM> or a separate component that interfaces with the OS <NUM>. The kernel of OS <NUM>, device drivers (including enumerated bus device drivers <NUM>), and other services may all use the registry <NUM>. Settings stored in the registry <NUM> may be stored as values associated with registry keys of the registry <NUM>.

The PnP manager <NUM> supports plug-and-play functionality for the OS <NUM>, and may be part of OS <NUM> or a separate, interfacing component. The PnP manager <NUM> is responsible for PnP device detection and enumeration during a boot phase of the computing device <NUM> or of attached PnP devices (e.g., enumerated bus devices) and for adding/removing PnP devices while the system is running. PnP devices include enumerated bus devices, such as hub <NUM>, mouse, <NUM>, thumb drive <NUM>, and other enumerated bus devices <NUM>, and PnP manager <NUM> accordingly manages and interfaces with such devices. Among its functions, the PnP manager <NUM> may call the DriverEntry and AddDevice routines of any PnP device driver (including enumerated bus device drivers) and may send a start device command (e.g., IRP_MN_START_DEVICE) to PnP devices (including enumerated bus devices). The PnP manager <NUM> may also build and maintain a PnP device tree of PnP devices on the computing device <NUM> based on information received from drivers of those PnP devices.

In some implementations, device stacks <NUM> each correspond to a device node for an enumerated bus device in a PnP device tree. Each device stack <NUM> includes at least one device object associated with a PnP driver. For example, each device stack <NUM> includes at least a PDO <NUM> for the PnP enumerated bus driver of an enumerated bus device. Creation of the PDO <NUM> may precede creation of the device stack <NUM> and the device stack <NUM> may be created with the PDO <NUM> as the base/lowest-level device object of the device stack <NUM>. The device stack <NUM> may also include an FDO <NUM> associated with a function driver for the enumerated bus device, the function driver handling read, write, and device control requests received, for example, from the PnP manager <NUM> or from a filter driver. Above or below the FDO <NUM> in the device stack <NUM>, the device stack <NUM> may include one or more filter device objects associated with filter drivers, such as PnP driver <NUM>. Such filter drivers may be upper-device filters, with their object placed above the FDO <NUM> in a device stack <NUM>, or lower-device filters, with their object placed between the FDO <NUM> and PDO <NUM> in a device stack <NUM>.

In <FIG>, three device stacks <NUM> are shown for illustrative purposes. Device stack 122a corresponds to hub <NUM>. Device stack 122b corresponds to mouse <NUM>. Device stack 122c corresponds to thumb drive <NUM>. Device stack 122a includes PDO 124a, FDO 140a, and an object for PnP driver 126a attached as an upper-device filter. Device stack 122b includes PDO 124b, FDO 140b, and an object for PnP driver 126b attached as a lower-device filter. Device stack 122c includes PDO 124c, FDO 140c, and an object for PnP driver 126c attached as a lower-device filter. As discussed further herein, PnP driver <NUM> attaches as an upper-device filter for hubs and controllers and as a lower-device filter for other enumerated bus devices.

In various implementations, PnP driver <NUM> may create a CDO <NUM> to enable communication between the PnP driver <NUM> and security agent <NUM>. CDO <NUM> may be any sort of CDO, such as an object representing a software-only virtual device. The CDO <NUM> may not be part of the device stacks <NUM> but may be utilized by drivers that are part of the device stacks <NUM>, such as PnP driver <NUM>, for communication with user-mode processes or threads, such as security agent <NUM>.

<FIG> illustrate example processes <NUM>, <NUM>, <NUM>, and <NUM>. These processes are illustrated as logical flow graphs, each operation of which represents a sequence of operations that can be implemented in hardware, software, or a combination thereof. In the context of software, the operations represent computer-executable instructions stored on one or more computer-readable storage media that, when executed by one or more processors, perform the recited operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures, and the like that perform particular functions or implement particular abstract data types. The order in which the operations are described is not intended to be construed as a limitation, and any number of the described operations can be combined in any order and/or in parallel to implement the processes.

<FIG> illustrates an example process for loading a plug-and-play (PnP) driver as an upper-device filter in a device stack of a root hub or a non-root hub of a computing device and for attaching the PnP driver to device stacks of other enumerated bus devices of the computing device as either an upper-device filter or lower-device filter depending on device classes of those enumerated bus devices. Process <NUM> illustrates, at <NUM>, the security agent <NUM> or PnP driver <NUM> receiving, and applying while live, a configuration update without rebooting. Such an update may affect policies, IoAs, threat responses, etc. If both the security agent <NUM> and PnP driver <NUM> are loaded, the configuration update may be provided through CDO <NUM>, as described further herein. While the receiving of the configuration update at <NUM> is shown as occurring before loading of the PnP driver <NUM> and attaching of it to device stacks <NUM>, the receiving at <NUM> may occur at any point during the operations shown at <FIG>.

At <NUM>, the security agent <NUM> may cause the computing device <NUM> to load the PnP driver <NUM> as an upper-device filter in a device stack <NUM> of a hub. This may include, at <NUM>, writing a registry key to the registry <NUM> to indicate to OS <NUM> that the PnP driver <NUM> should be loaded as an upper-device filter in the device stack <NUM> of the hub upon initialization of the hub. The security agent <NUM> may then restart the hub, at <NUM>, to cause the OS <NUM> to load the PnP driver <NUM> (e.g., by calling its AddDevice routine). After its AddDevice routine is called, the PnP driver <NUM> may inspect the device instance path for to determine if the device is a hub. Based on that inspection, the PnP driver <NUM> attaches to the device stack <NUM> of the hub as an upper-device filter.

At <NUM>, the PnP driver <NUM> then receives a message listing an enumerated bus device that is connected to the computing device <NUM>. For example, when the PnP manager <NUM> issues a request (e.g., IRP_MN_QUERY DEVICE RELATIONS) to the bus driver for it to enumerate the enumerated bus devices attached to it, the PnP driver <NUM>, as an upper-device filter in the device stack <NUM> of the hub, will see both that request and the response. The PnP driver <NUM> may also check to ensure that it is attached to the device stack <NUM> of a hub as the PnP driver <NUM> may not be configured to evaluate enumerations received from non-hub devices.

At <NUM>, the PnP driver <NUM> determines whether at least one enumerated bus device mentioned in the received message belongs to a device class. For example, for each enumerated bus device mentioned in an enumeration response from the hub driver, the PnP driver <NUM> may determine the type of the enumerated bus device. To determine the type of each enumerated bus device, the PnP driver may issue a request for the indicative features for that enumerated bus device (e.g., from the hub driver).

At <NUM>, the PnP driver <NUM> then attaches as an upper-device filter or a lower-device filter in a device stack <NUM> associated with each of the enumerated enumerated bus devices. For example, if the indicative features for a given device indicates that it is a hub or controller, the PnP driver <NUM> waits for its AddDevice routine to be invoked to be added as an upper-device filter for that hub or controller. If the indicative features indicate that the enumerated bus device is a different sort of enumerated bus device, other than a hub or controller, then the PnP driver <NUM> attaches to the device stack <NUM> of that enumerated bus device as a lower-device filter.

In some implementations, an enumerated bus device may include multiple device drivers and multiple associated device stacks <NUM>. For such devices, it is possible that the PnP driver <NUM> may attach as an upper-device filter in one of the device stacks <NUM> and as a lower-device filter in another of the device stacks <NUM>.

<FIG> illustrates an example process for taking actions by a PnP driver attached or attaching to a device stack of an enumerated bus device as a filter, including altering, limiting, or otherwise blocking, inventorying, and fingerprinting, among others. Process <NUM> shows, at <NUM>-<NUM>, a number of different operations that the PnP driver <NUM> may perform when attached/loaded to device stack(s) <NUM>.

At <NUM>, the PnP driver <NUM> may compare indicative features, traffic, fingerprints (described further herein), or other information for an enumerated bus device to IoAs. Such IoAs may be configurable policies that form part of a configuration of the PnP driver <NUM>. During a decision phase for altering, limiting, or otherwise blocking of enumerated bus devices, the PnP driver <NUM> may utilize the IoAs to determine whether to alter, limit, or otherwise block ones of the enumerated bus devices. For example, the PnP driver <NUM> may retrieve the indicative features for an enumerated bus device, as mentioned above, and determine that information included in the indicative features matches an IoA. The PnP driver <NUM> may then store an indicator that the enumerated bus device associated with the indicative features is to be altered, limited, or otherwise blocked in an enforcement phase.

At <NUM>, the PnP driver <NUM> may take action to alter, limit, or otherwise block functionality of an enumerated bus device. Such action may occur during an enforcement phase and may have been made based on matches with one or more IoAs. Altering, limiting, or otherwise blocking of functionality is discussed in greater detail with reference to <FIG>.

At <NUM>-<NUM>, the PnP driver <NUM> may take further diagnostic actions that it may then use to provide intelligence to the security agent <NUM> or security service cloud <NUM> or to alter, limit, or otherwise block an enumerated bus device. At <NUM>, the PnP driver <NUM> requests through a device stack <NUM> that the enumerated bus device associated with that device stack <NUM> perform an action. For example, the PnP driver <NUM> may transmit a USB request block (URB) to the driver of the enumerated bus device requesting that it perform an action. At <NUM>, the PnP driver <NUM> monitors the traffic generated responsive to the request to determine whether the at least one enumerated bus device has performed the requested action. For example, if the enumerated bus device is claiming to be a keyboard, and the response to the request either shows the device performing an action that a keyboard cannot perform or failing to perform a task that a keyboard can perform, the PnP driver <NUM> may conclude that the enumerated bus device is not in fact a keyboard.

At <NUM>, the PnP driver <NUM> may perform an inventory of enumerated bus devices connected to the computing device <NUM> by examining messages passed through device stacks <NUM> of the enumerated bus devices. Such messages may include enumerations of child devices, indicative features, configuration descriptors, interface descriptors, interface association descriptors (IADs), human interface device (HID) classes, OS descriptors (e.g., Microsoft® OS descriptors (MODs)), device serial numbers, other device identifiers provided by the OS <NUM> or by vendors of the enumerated bus devices (e.g., through firmware or hardware), device location information, and/or other traffic. For example, the inventory may include an enumeration of enumerated bus ports available on the computing device <NUM>, types of enumerated bus technology used on the computing device <NUM>, internal or external hubs of the computing device <NUM>, numbers of ports associated with each hub of the computing device <NUM>, speeds of ports of the computing device <NUM>, power draws of ports of the computing device <NUM>, type(s) of controller(s) on the computing device <NUM>, identifications of any port that a keyboard is plugged in to, or identifications of any port that a mass storage device or a hacking device is plugged in to. At <NUM>, the PnP driver <NUM> may then report the inventory to the security agent <NUM> or security service cloud <NUM>. The inventory may be organized as a PnP device tree. The PnP driver <NUM> may construct the tree by retrieving the tree maintained by the OS <NUM> and by updating that tree.

At <NUM>, the PnP driver <NUM> may create a fingerprint for an enumerated bus device based on information collected by the PnP driver <NUM>, such as the information collected for the system inventory and/or other information captured from enumerations, indicative features, configuration descriptors, interface descriptors, IADs, HID classes, OS descriptors (e.g., MODs), device serial numbers, other device identifiers provided by the OS <NUM> or by vendors of the enumerated bus devices (e.g., through firmware or hardware), device location information, and/or device stack traffic. At <NUM>, creating the fingerprint may be based on both the information collected by the PnP driver <NUM> and on information gathered by a cloud service, such as security service cloud <NUM>. In such implementations, the security service cloud <NUM> may provide information to the computing device <NUM> to enable fingerprint creation by the PnP driver <NUM> or security agent <NUM>, or the PnP driver <NUM> may provide information to the security service cloud <NUM> to enable fingerprint creation by the security service cloud <NUM>. The fingerprint may then be included in subsequent deployments of configurations for the security agent <NUM> and/or the PnP driver <NUM> to be used to trigger altering, limiting, or otherwise blocking or monitoring.

At <NUM>, the PnP driver <NUM> may create a CDO <NUM> to communicate with a user-mode process or thread, such as security agent <NUM>. At <NUM>, the PnP driver <NUM> may then subsequently remove the CDO <NUM> when either a count associated with enumerated bus devices connected to the computing device <NUM> reaches zero or when the PnP driver <NUM> receives a shutdown command from the user-mode process or thread. The actions shown at <NUM>-<NUM> are described below in further detail with respect to <FIG>.

<FIG> illustrates an example process for taking action by a PnP driver to alter, limit, or otherwise block functionality of an enumerated bus device. Process <NUM> shows, at <NUM>, the PnP driver <NUM> receives a message directed through the device stack <NUM> of an enumerated bus device that the PnP driver <NUM> is attached to. The message may specify indicative features of at least one of the enumerated bus devices connected to the computing device <NUM> or command the at least one of the enumerated bus devices to take an action. For example, the message may be a response to an enumeration request received at a device stack <NUM> of a hub device. The message may list enumerated bus devices connected to the hub device. The PnP driver <NUM> may then query for information associated with those listed enumerated bus devices and make an altering, limiting, or otherwise blocking decision for each such enumerated bus device. For example, as discussed further herein, the PnP driver <NUM> may compare the information received in the message to one or more fingerprints or configurable policies to determine whether to alter, limit, or otherwise block an enumerated bus device. If the PnP driver <NUM> decides to alter, limit, or otherwise block functionality of the enumerated bus device, the PnP driver <NUM> may store an indication of the decision for use in a subsequent enforcement phase. In one implementation, the PnP driver <NUM> may also store an indication of a method to be used in altering, limiting, or otherwise blocking functionality of the enumerated bus device.

At <NUM>, the PnP driver <NUM> takes action to alter, limit, or otherwise block functionality of an enumerated bus device. Such action may occur in an enforcement phase (e.g., during installation or starting of the enumerated bus device).

At <NUM>, the action taken may be sending a request to a hub device requesting that an individual port of the hub associated with the enumerated bus device be powered off, disabled, or power cycled.

Alternatively, at <NUM>, the action may be altering installation strings or capability flags for the enumerated bus device. The PnP driver <NUM> may filter the PnP manager <NUM>'s IRP MN_QUERY_ID message and alter the returned strings (e.g., hardware ID strings and/or compatibility ID strings) to a string that does not map to any driver INF file on the computing device <NUM>, or which alters the strings to map to a different INF file. The technique may then further include the PnP driver <NUM> filtering and altering flags in IRP_MN_QUERY_CAPABILTIES, for purposes such as stealth blocking, so as not to alert the user in device manager, toasts, popups, or other user indications.

In another implementation, a set of files associated with the PnP driver or security service are pre-installed into the system that register the PnP driver or security service as a new "device class". At that point, the installation string is modified to pretend that the device is part of the new device class, and various other descriptive strings are set to those of the blocked device. This may cause the operating system to look for a descriptor for this device class, and it finds the new device class, which says "Blocked Device". Because such files are pre-installed, the PnP driver or security service is effectively added to the operating system Device Manager and a user can see the device, as well as any descriptive strings encoded from the original device. Furthermore, a "property sheet library" is also installed, which displays a custom interface to the user when they double click on such a device (e.g., from within the Microsoft Device Manager UI), including with a password-protected unblock command and other capabilities, such as to inspect device property details and to determine why the device was blocked.

Alternatively, at <NUM>, the action may be failing, by the PnP driver, a start routine initiated by a start device message received from a PnP manager <NUM>. The PnP manager <NUM> may send an IRP_MN_START_DEVICE message which may be received by the FDO <NUM> of the enumerated bus device. The functional driver of the enumerated bus device is then loaded and the message passed to the PnP driver <NUM>. The PnP driver <NUM> then returns a failure status code to PnP manager <NUM>, causing the function driver to be unloaded and the device stack <NUM> to be torn down.

Alternatively, at <NUM>, the action may be returning a failure status for an AddDevice routine to a PnP manager <NUM> to cause a device stack for the enumerated bus device to be torn down. Such a technique may be used, for example, for hub or controller devices for which the PnP driver <NUM>'s AddDevice routine is called.

Alternatively, at <NUM>, the action may be removing an identification of the enumerated bus device from an enumeration of the one or more enumerated bus devices. Such a removal may be made by the PnP driver <NUM> to the enumeration response from a hub driver. When the PnP manager <NUM> receives the altered response, it will not see an identification of the enumerated bus device and thus will not allocate PnP resources to it and the device will not function at all on the system.

Alternatively, at <NUM>, the action may be suspending the enumerated bus device by updating a state machine of a hub device. This suspension - referred to as selective suspend - may be achieved via PnP messages to the PnP manager <NUM> rather than through direct communication with the hub device.

Alternatively, at <NUM>, the action may be any other sort of altering, limiting or blocking action taken based at least on part on configurable policies of the PnP driver <NUM>.

<FIG> illustrates an example process for creating, by a PnP driver, a control device object (CDO) to enable communication with a user-mode process or thread and for removing the CDO. Process <NUM> illustrates, at <NUM>, the PnP driver <NUM> creating a CDO <NUM> to communicate with a user-mode process or thread, such as security agent <NUM>. The PnP driver <NUM> may create the CDO <NUM> during a first device start command for a first enumerated bus device (e.g., IRP_MN_START_DEVICE). Alternatively, the PnP driver <NUM> may create the CDO <NUM> in its DriveEntry, which is called when the PnP driver <NUM> is first loaded. Once created, the PnP driver <NUM> can receive and respond to commands from a user-mode process or thread, such as security agent <NUM>, through the CDO <NUM> and/or receive configuration/policy updates from a user-mode process or thread, such as security agent <NUM>, through the CDO <NUM>.

At <NUM>, the PnP driver <NUM> removes the CDO <NUM> when a count associated with enumerated bus devices connected to the computing device reaches zero. The PnP driver <NUM> may keep a count of enumerated bus devices by incrementing a counter for each start device message (e.g., IRP_MN_START_DEVICE) sent and decrementing the counter for each remove device message (e.g., IRP_MN_REMOVE_DEVICE) sent. When the counter reaches zero, the PnP driver <NUM> may then remove the CDO <NUM>.

Alternatively to <NUM>, at <NUM>, the PnP driver <NUM> removes the CDO <NUM> when the PnP driver <NUM> receives a shutdown command from the user-mode process or thread. At <NUM>, the user-mode process or thread opens a handle to the CDO <NUM> and issues a shutdown command to the PnP driver <NUM>, e.g., as an IOCTL. At <NUM>, in response to the shutdown command, the PnP driver <NUM> takes a reference on the CDO <NUM> and deletes the CDO <NUM>. However, the CDO <NUM> remains because of the reference taken to it. At <NUM>, the user-mode process or thread closes the handle to the CDO <NUM>, which causes cleanup and close messages (e.g., IRP_MJ _CLEANUP and IRP_MJ_CLOSE) to be emitted, in that order, to the PnP driver <NUM>. At <NUM>, upon receiving the close message, and remembering that the user-mode process or thread previously sent the shutdown command, the PnP driver <NUM> removes the last reference on the CDO <NUM>, which results in the removal of the CDO <NUM>. Because the CDO <NUM> has been removed, the PnP driver <NUM> may be subsequently unloaded (e.g., upon restart of all enumerated bus devices).

Claim 1:
A method comprising:
loading (<NUM>) a plug-and-play, PnP, driver (<NUM>) as an upper-device filter (126A) in a device stack (122A) of a hub (<NUM>), including writing (<NUM>) a registry key indicating to an operating system (<NUM>) of a computing device (<NUM>) that the PnP driver should be loaded as an upper-device filter in the device stack of the hub upon initialization of the hub and restarting (<NUM>) the hub to cause the operating system to load the PnP driver;
receiving (<NUM>), by the PnP driver (<NUM>) implemented on the computing device (<NUM>), a message listing at least one enumerated bus device (<NUM>, <NUM>, <NUM>, <NUM>) that is connected to the computing device, wherein the message is a response to an enumeration request from a PnP manager (<NUM>) requesting to a receiving bus driver a list of all enumerated bus devices attached to the enumerated bus device represented by the receiving bus driver, and wherein the PnP driver, as an upper-device filter in the device stack (122A) of the hub, has visibility of both the request and the response;
determining (<NUM>), by the PnP driver, whether the at least one enumerated bus device belongs to a device class, wherein determining whether the at least one enumerated bus device belongs to a device class is based on the PnP driver issuing a request for indicative features for the at least one enumerated bus device;
based at least in part on the determining, attaching (<NUM>) the PnP driver as an upper-device filter or a lower-device filter in a device stack (<NUM>) associated with the at least one enumerated bus device;
creating (<NUM>, <NUM>) a fingerprint for the at least one enumerated bus device (<NUM>, <NUM>, <NUM>, <NUM>) based on information collected by the PnP driver (<NUM>) and on information gathered by a security service cloud (<NUM>);
receiving by the PnP driver (<NUM>) a configuration update from a security client implemented on the computing device or from a remote security service, the configuration update affecting an indicator of attack usable by the PnP driver (<NUM>) to limit or block the enumerated bus device <NUM>, <NUM>, <NUM>, <NUM>) that is connected to the computing device.