Patent Description:
With Internet use forming an ever-greater part of day to day life, security exploits that steal or destroy system resources, data, and private information are an increasing problem. Governments and businesses devote significant resources to preventing intrusions and thefts related to these security exploits. Security exploits come in many forms, such as computer viruses, worms, trojan horses, spyware, keystroke loggers, adware, and rootkits. These exploits are delivered in or through a number of mechanisms, such as spearfish emails, clickable links, documents, executables, or archives. Some of the threats posed by security exploits are of such significance that they are described as cyber terrorism or industrial espionage.

Detecting such security exploits in firmware of a computing device after an operating system (OS) has loaded creates additional risks for that system. Security software may access different memory locations in attempts to find and scan firmware, but such accesses may harm system performance. Other techniques for detecting firmware exploits are also problematic, causing race conditions and other issues. For reasons such as these, firmware scans are often only performed using command line tools before the OS has loaded.

<CIT> discloses a method for preventing BAD USB activation including: a step of performing code integrity verification of a USB device; a step of detecting falsification or modulation of the USB device by performing the code integrity verification; and a step of preventing the installation of the BAD USB by detecting falsification or modulation of the USB device.

<CIT> discloses a security service processor with an independent network interface for communicating with a remote server over a network. The security service processor can provide remote management and security functionalities for various devices connected using different buses on a platform in each host computer. The security service processor can provide a centralized mechanism to verify and authenticate firmware updates for various devices using different buses. A hardware interface can allow the security service processor to provide remote debugging and diagnostic capabilities. The security service processor can also provide some of the typical functionalities of a baseboard management controller or can be used in addition to the baseboard management controller.

<CIT> discloses an apparatus and method to authenticate firmware stored in a firmware storage unit. The apparatus includes a controller to command an authenticator to start firmware authentication, the authenticator, which performs authentication of the firmware using a signature read from the firmware storage unit, and a bus controller to controls a data transmission bus to a decoder.

There is provided a method, a computing device, and a computer-readable medium as detailed in the claims that follow.

This disclosure describes, in part, a bus filter driver and other security agent components configured to retrieve and analyze firmware images. The bus filter driver may attach to a bus device associated with a memory component and retrieve a firmware image of firmware stored on the memory component. Such attachment may be conditional based on chipset including the memory component and the retrieval may occur at boot time, responsive to the bus device receiving a start message. The bus filter driver may utilize either a bus interface or a specified memory location, depending on bus driver metadata, in retrieving the firmware image and hardware metadata. The bus filter driver may also retrieve hardware metadata, such as data from one or more registers.

The kernel-mode component of the security agent may then retrieve the firmware image and hardware metadata from the bus filter driver and provide the firmware image and hardware metadata to a user-mode component of the security agent for security analysis. The user-mode component may determine at least one of a security status associated with the firmware or an occurrence of a suspect pattern of information.

The security agent components may then provide results of the analysis and/or the firmware image and hardware metadata to a remote security service to determine a security status for the firmware. In determining security status, the remote security service may compare type information for the computing device (e.g., information about the chipset of the computing device) and at least one of the firmware image or hardware metadata to at least one of prevalence information, expected values for firmware or hardware, or a whitelist or a blacklist.

<FIG> illustrates an overview of a system including a remote security service and a computing device having a bus filter driver to retrieve a firmware image and other security agent components to analyze the firmware image. As illustrated, a computing device <NUM> may be in communication with a remote security service <NUM> and may include hardware <NUM>, kernel-mode components <NUM>, and user-mode components <NUM>. The hardware <NUM> may include a memory component <NUM> storing firmware <NUM> and accessible through a bus device <NUM>. The kernel-mode components <NUM> include a bus filter driver <NUM>, registry/tables <NUM>, and the kernel-mode component <NUM> of the security agent. The user-mode components <NUM> may include a user-mode component <NUM> of the security agent.

In various implementations, the computing device <NUM> and the device(s) of the remote security service <NUM> may each may be or include a server or server farm, multiple, distributed server farms, a mainframe, 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, or any other sort of device or devices. In one implementation, the device(s) of the remote security service <NUM> represent a plurality of computing devices working in communication, such as a cloud computing network of nodes. In some implementations, one or more of the computing device implementing the security agent <NUM> or the device(s) of the remote security service <NUM> represent one or more virtual machines implemented on one or more computing devices. An example computing device capable of serving as the computing device <NUM> or as one of the device(s) of the remote security service <NUM> is illustrated in <FIG> and described below with reference to that figure.

The computing device <NUM> and the device(s) of the remote security service <NUM> may be connected by a network. The network may include any one or more networks, such as wired networks, wireless networks, and combinations of wired and wireless networks. Further, the network may include any one or combination of multiple different types of public or private networks (e.g., cable networks, the Internet, wireless networks, etc.). For example, the network may be a private network. In some instances, computing devices communicate over the network using a secure protocol (e.g., https) and/or any other protocol or set of protocols, such as the transmission control protocol/Internet protocol (TCP/IP).

As illustrated in <FIG>, the computing device <NUM> includes hardware <NUM>, kernel-mode components <NUM>, and user-mode components <NUM>. The hardware <NUM> may include tangible components of the computing device <NUM>, such as the memory component <NUM> and bus device <NUM>. Hardware <NUM> may also include other tangible components, such as those illustrated in <FIG> and described below with reference to that figure. The computing device <NUM> may also include an OS, a registry (such as registry/tables <NUM>), and applications. The registry is a kernel mode component <NUM>, the OS may include both kernel-mode components <NUM> and user-mode components <NUM>, and applications may be either or both of kernel-mode components <NUM> and user-mode components <NUM>.

In some implementations, the bus device <NUM> and memory component <NUM> may be associated with a chipset (e.g., a chipset with the Northbridge-Southbridge architecture). The bus device <NUM> may include a root bus, such as a peripheral component interconnect (PCI) bus or a PCI express (PCIe) bus, and the root bus may in turn include a bus connected to the memory component <NUM>, such as a low pin count (LPC) bus or an enhanced serial peripheral interface (eSPI) bus. The bus device <NUM> may provide access to connected devices, such as memory component <NUM>, through a PCI bus interface. Such an interface may provide access to components connected to the LPC bus through, e.g., a serial peripheral component base address register (SPIBAR) located through the bus interface. Alternatively, when the bus device <NUM> includes an eSPI bus or other bus that is not available through the PCI bus interface, access to the memory component <NUM> may be achieved by way of a specified memory location of the memory component <NUM>.

In various implementations, the memory component <NUM> may be a flash memory device of the chipset of the computing device <NUM>. As shown in <FIG>, the memory component <NUM> may store firmware <NUM>, which may be a basic input output system (BIOS) or a unified extensible firmware interface (UEFI) of the computing device <NUM>.

In addition, kernel-mode components <NUM> of the computing device <NUM> may also include an OS stack for attaching to drivers of hardware <NUM> and enabling the OS and applications to communicate with the hardware <NUM> through its drivers. The OS stack may include multiple filter drivers, such as upper-device filter drivers or lower-device filter drivers, each attached to a component of hardware <NUM>. In some implementations, a filter driver (e.g., bus filter driver <NUM>) attaching to a bus device (e.g., bus device <NUM>) may attach as an upper-device filter driver. The OS stack may also be referred to as a plug-and-play (PnP) stack and filter drivers as PnP filter drivers (e.g., PnP upper-device filter drivers and PnP lower-device filter drivers).

The registry/tables <NUM> may be any sort of registry for storing attributes about hardware and software components of the computing device <NUM>. For example, the registry/tables <NUM> may store a vendor identifier (ID) or chipset ID of the chipset of the computing device <NUM>.

In various implementations, the kernel-mode component <NUM> and user mode-component <NUM> are both components of a security agent. The security agent may monitor and record activity on the computing device, may analyze the activity, and may generate alerts and events and provide those alerts and events to the remote security service <NUM>. The security agent may be installed by and configurable by the remote security service <NUM>, receiving, and applying while live, configurations of the security agent and its component(s), such as the kernel-mode component <NUM> and user mode-component <NUM>. An example security agent is described in greater detail in <CIT>, which issued as U. patent number on May <NUM>, <NUM>.

The security agent may include the bus filter driver <NUM>, the kernel-mode component <NUM>, the user-mode component <NUM>, and an external component library (ECL) <NUM>. Those components are described below in detail with respect to <FIG>.

<FIG> illustrate interactions between components of the computing device, including the bus filter driver and other security agent components, and the remote security service.

As illustrated in <FIG>, the kernel-mode component <NUM> of the security agent may install, at <NUM>, the bus filter driver <NUM>. The kernel-mode component <NUM> may include one or more components configured to retrieve information from hardware <NUM>, communicate with an ECL <NUM>, update the registry/tables <NUM>, and communicate with the user-mode component <NUM> and the remote security service <NUM>.

The bus filter driver <NUM> may be a PnP upper-device filter driver installed, at <NUM>, in the OS/PnP stack of the computing device <NUM>. At <NUM>, after installation, the bus filter driver <NUM> may retrieve, from the registry/tables <NUM> a vendor ID or chipset ID identifying a version of the chipset of the computing device <NUM>. At <NUM>, if the vendor ID or chipset ID are among those supported (e.g., according to a configuration of the bus filter driver <NUM>), the bus filter driver <NUM> attaches to the bus device <NUM> (e.g., by attaching to a driver of the bus device <NUM>). This attachment enables the bus filter driver <NUM> to passively receive messages/information from the bus device <NUM> and components connected to the bus device <NUM>.

The bus filter driver <NUM> is further configured to either acquire, at <NUM>, the bus interface (e.g., a PCI bus interface) of the bus device <NUM> or identify a specified memory location. The bus filter driver <NUM> may elect between these alternatives based on bus driver metadata, such as a version or type of the bus filter driver <NUM>. For example, if the type of the bus driver <NUM> is LPC, the bus filter driver <NUM> may acquire the bus interface and utilize the bus interface to identify (e.g., through the SPIBAR) the location of the memory component <NUM>. If the type of the bus driver <NUM> is eSPI, then the bus filter driver <NUM> may utilize a specified memory location as the location of the memory component <NUM>.

Also at <NUM>, the bus filter driver <NUM> may create an ECL <NUM> for communication with the kernel-mode component <NUM>, enabling bi-directional communication through the ECL <NUM>.

In various implementations, at <NUM>, the bus filter driver <NUM> may receive, via the OS/PnP stack, a start message sent to the bus device <NUM> at boot up of the computing device <NUM>. A IRP_MN_START_DEVICE message is an example of such a start message. Responsive to the start message, the bus filter driver <NUM> may retrieve, at <NUM>, a firmware image of the firmware <NUM> and may retrieve hardware data, such as processor-related register values, PCI config-related register values, memory-mapped input/output (MMIO)-related register values, SPIBAR related register values, or extensible firmware interface (EFI) variables. In some implementations, the bus filter driver <NUM> may be configured to only retrieve, at <NUM>, the firmware image and hardware data responsive to receipt by the bus driver <NUM> of a start message and not to retrieve, at <NUM>, the firmware image and hardware data at other times. In some implementations, if the vendor ID/chipset ID at <NUM> indicates that the chipset is not supported, then the bus filter driver <NUM> retrieves a subset of hardware metadata.

As illustrated in <FIG>, at <NUM>, the kernel-mode component <NUM> requests the firmware image and hardware metadata from the bus filter driver <NUM>. Such a request may be transmitted through the ECL <NUM>, which is created by the bus filter driver <NUM>. The kernel-mode component <NUM> may send the request upon coming online after a boot of the computing device <NUM>. At <NUM>, the kernel-mode component <NUM> receives the firmware image and metadata. In some implementations, if the chipset is not supported, the kernel-mode component <NUM> receives a subset of the hardware metadata rather than the firmware image and hardware metadata.

In various implementations, upon receiving the firmware image and hardware metadata, the kernel-mode component <NUM> may send, at <NUM>, a subset of the hardware metadata to the remote security service <NUM> and may send, at <NUM>, the firmware image and hardware metadata to the user-mode component <NUM> for analysis.

At <NUM>, the user-mode component <NUM> may parse the firmware image and analyze both the parsed firmware image and hardware metadata. Such analysis could include determining a security status of the firmware <NUM> or detecting a pattern of suspicious activity, also known as an "indicator of attack. " In some implementations, the user-mode component <NUM> may also hash the parsed firmware image and/or hardware metadata. At <NUM>, the user-mode component <NUM> may then provide results of the analysis, the parsed firmware image, the hardware metadata, and/or the hashes to the remote security service <NUM> through a kernel-mode communications component <NUM>.

The remote security service <NUM> may then determine a security status for the firmware <NUM>. In determining security status, the remote security service <NUM> may compare type information for the computing device <NUM> (e.g., information about the chipset of the computing device <NUM>) and at least one of the firmware image or hardware metadata to at least one of prevalence information, expected values for firmware <NUM> or hardware <NUM>, or a whitelist or a blacklist. The prevalence information may be based on a reference source or may be constructed from firmware images and/or hardware metadata received from multiple computing devices.

In some implementations, the kernel-mode component <NUM> may receive notice of a power resume for the computing device <NUM> (e.g., returning from sleep mode or a low power mode). Upon receiving the notice, the kernel-mode component <NUM> may request hardware metadata from the bus filter driver <NUM> through the ECL <NUM>. The bus filter driver <NUM> may then retrieve a subset of the hardware data, such as hardware metadata available without use of the bus interface, and provide that hardware metadata to the kernel-mode component <NUM> through the ECL <NUM>.

<FIG> illustrate example processes. 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 retrieving a firmware image and hardware metadata, analyzing the retrieved firmware image and metadata, and providing results of the analysis and/or the firmware image and hardware metadata to a remote security service. The process includes, at <NUM>, a bus filter driver on a computing device retrieving a vendor identifier or chipset identifier for a memory component of the computing device from a registry. In some implementations, the bus filter driver may be a PnP upper-device filter driver.

At <NUM>, the bus filter driver conditionally attaches to the bus device based on the vendor identifier or chipset identifier indicating that the chipset is supported. In some implementations, the bus device may include a PCI bus or PCIe bus, and the PCI bus or PCIe bus may include a LPC bus or an eSPI bus connected to the memory component.

At <NUM>, when a chipset of the computing device is not supported, the bus filter driver extracts a subset of firmware information, chipset information, or register values.

When the chipset of the computing device is supported, the operations continue as shown at <NUM>-<NUM>. At <NUM>, the bus filter driver i) acquires a bus interface and utilize the bus interface to locate the memory component or ii) uses a specified memory location as a memory location of the memory component. The acquisition of the bus interface or use of the specified memory location may be based on a comparison of hardware metadata, such as bus device metadata, to a specified date or specified version.

At <NUM>, the bus filter driver retrieves a firmware image of the firmware from the memory component. At <NUM>, the retrieval may occur responsive to receipt of a start message by the memory component at boot time of the computing device. The bus filter driver may further retrieve hardware metadata from at least one of chipset tables or registers. The hardware metadata may include at least one of processor-related register values, PCI config-related register values, MMIO-related register values, SPIBAR-related register values, or EFI variables.

At <NUM>, a kernel-mode component of the security agent may retrieve the firmware image and hardware metadata from the bus filter driver and provide the firmware image and/or hardware metadata to a user-mode component of the security agent and to a remote security service. In some implementations, the kernel-mode component may access the firmware image and hardware metadata from the bus filter driver via an ECL.

At <NUM>, the user-mode component of the security agent analyzes the firmware image and the hardware metadata to determine at least one of a security status associated with the firmware or an occurrence of a suspect pattern of information. In some implementations, the analysis may include performing, based on the firmware image and hardware metadata, at least one of determining indicators of attack, determining prevalence for the firmware, determining presence of the firmware on whitelists or blacklists, or determining that the firmware is an expected firmware for hardware of the computing device.

At <NUM>, the user-mode component of the security agent then provides the security status or the indicator of the suspect pattern to the kernel-mode component for transmission to the remote security service.

<FIG> illustrates an example process for a security service to retrieve firmware images and hardware metadata from computing devices and to determine security statuses for those devices based on the firmware images and metadata.

The process includes, at <NUM>, a security service receiving, from a remote computing device, type information for the remote computing device, a firmware image of firmware of the remote computing device, and hardware metadata of the remote computing device. The firmware image and the hardware metadata data may be received from a kernel-mode component of a security agent of the remote computing device. The security agent may further be configured to implement a bus filter driver on the remote computing device for retrieving the firmware image and the hardware metadata data.

At <NUM>, the security service determines or retrieves at least one of prevalence information, expected values for firmware or hardware, or a whitelist or a blacklist. In some implementations, the prevalence information is based on a reference source or is constructed from firmware images and/or hardware metadata received from multiple remote computing devices.

At <NUM>, the security service compares the type information and at least one of the firmware image or hardware metadata to at least one of the prevalence information, the expected values for firmware or hardware, or the whitelist or blacklist.

At <NUM>, the security service determines a security status for the firmware based at least on the comparing.

<FIG> illustrates a component level view of a computing device configured with a bus filter driver to retrieve a firmware image from a memory component and with other components of a security agent to analyze the firmware image. As illustrated, computing device <NUM> comprises a memory <NUM> storing processes and data <NUM>. Also, computing device <NUM> includes processor(s) <NUM>, a removable storage <NUM> and non-removable storage <NUM>, input/output device(s) <NUM>, and communication connections <NUM> for communicating with other computing devices <NUM>.

In various embodiments, memory <NUM> is volatile (such as RAM), nonvolatile (such as ROM, flash memory, etc.) or some combination of the two. The processes and data <NUM> may be any sort of processes and data, such as firmware <NUM>, bus filter driver <NUM>, registry/tables <NUM>, kernel-mode component <NUM>, user-mode component <NUM>, ECL <NUM>, or kernel-mode communications component <NUM>, which are described above in detail with respect to <FIG>, <FIG>, and <FIG>.

In some embodiments, the processor(s) <NUM> is 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.

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 removable storage <NUM> and non-removable storage <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>, removable storage <NUM> and non-removable storage <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>.

Computing device <NUM> also has input/output device(s) <NUM>, such as a keyboard, a mouse, a touch-sensitive display, a voice input device, a camera, a display, speakers, a printer, etc. These devices are well known in the art and need not be discussed at length here.

Computing device <NUM> also contains communication connections <NUM> that allow the computing device <NUM> to communicate with other computing devices <NUM>, such as device(s) of a remote security service <NUM> (when the computing device <NUM> is an example of computing device <NUM>) or computing device <NUM> (when the computing device <NUM> is an example of device(s) of a remote security service <NUM>).

Claim 1:
A computing device (<NUM>, <NUM>) comprising:
a memory component (<NUM>, <NUM>) configured to store firmware (<NUM>) of the computing device (<NUM>, <NUM>);
a bus device (<NUM>) communicatively coupled to the memory component (<NUM>, <NUM>);
a bus filter driver (<NUM>) configured to:
attach to the bus device (<NUM>),
retrieve bus device metadata from the bus device (<NUM>), wherein the bus device metadata indicates a date, wherein when the bus device metadata indicates a date less recent than a specified date, acquire (<NUM>) a bus interface and utilize the bus interface to locate the memory component (<NUM>, <NUM>), and wherein when the bus device metadata does not indicate a date less recent than a specified date, use (<NUM>) a specified memory location as a memory location of the memory component (<NUM>, <NUM>),
retrieve (<NUM>) a firmware image of the firmware (<NUM>) of the computing device (<NUM>, <NUM>) from the memory component (<NUM>, <NUM>), wherein the bus filter driver is configured to retrieve (<NUM>) the firmware image responsive (<NUM>) to receipt of a start message by the bus device at boot time of the computing device (<NUM>, <NUM>), and
create an external component library, ECL, for communication with a kernel-mode component (<NUM>) of a security agent (<NUM>, <NUM>);
and the computing device (<NUM>, <NUM>) further comprises the security agent (<NUM>, <NUM>), wherein the security agent (<NUM>, <NUM>) is configured to:
retrieve, by the kernel-mode component of the security agent (<NUM>), via the ECL, the firmware image from the bus filter driver (<NUM>), and
perform, by a user-mode component of the security agent (<NUM>), a security analysis (<NUM>) of the firmware image.