Patent Description:
The present invention is directed to inspecting files being copied between a host computer and a removable storage device for malware.

Operational Technology (OT) security refers to securing industrial control systems, such as those used in manufacturing facilities, power plants, and other OT sites. In contrast to cybersecurity, which protects computers and information in general, OT security prevents tampering and unauthorized control of industrial control systems. Like cybersecurity, OT security is concerned with detecting and blocking malware, i.e., malicious code. However, the stakes are higher in OT security because malware infection of an industrial control system can result in physical injuries or even death. Consequently, some industrial control systems are not directly connected to the Internet.

An OT security issue arises when files are to be copied to and between industrial control systems. A popular way of copying files to an industrial control system is by removable storage devices, such as Universal Serial Bus (USB) storage devices. As part of OT security procedure, a USB storage device needs to be scanned for malware before allowing the USB storage device to be connected to a workstation or industrial equipment of an industrial control system.

One way of scanning a USB storage device for malware is to provide a dedicated scan box, such as a computer with a traditional scanner, at the entrance of an OT site. Visitors of the OT site (e.g., vendors, consultants, field engineers) are required to scan a USB storage device at the scan box before the USB storage device is allowed to be inserted to an industrial control system. A problem with using a dedicated scan box is that a USB storage device needs to be re-scanned after each insertion to an industrial control system, because the USB storage device may have been infected in-between insertions. Enforcing OT security by installing a special security driver on the industrial control system to check for scanned USB storage devices is problematic because special security drivers on an industrial control system may require validation for compliance with regulatory agencies or may void warranty.

Another way of scanning a USB storage device for malware is to use a special-purpose USB storage device with a built-in scanner, such as the Trend Micro™ USB Security product. A potential problem with this solution is that some visitors may be hesitant to copy proprietary files to such special-purpose USB storage device, preferring to use regular, ubiquitous USB storage devices.

<CIT> describes a USB-based intermediary for protecting a host device from malware and electrical anomalies originating from connected peripheral devices. It features a data cable linking the host and the security device, a memory buffer to temporarily store data, and malware detection logic that inspects data for known threats using comparison, cryptographic decryption, or hash calculations. When malware is detected, the device prevents malicious data from reaching the host and may delete it from the buffer. The device includes a descriptor table to differentiate trusted from non-trusted devices. It can alert users via a graphical interface, offering actionable options for detected threats.

<CIT> discloses a virus detection system that employs a USB relay device with a connection switching unit to manage file transfers between a USB client and a USB host controller while performing real-time virus checks. The device features a virus check engine for inspecting files and a control unit for relaying data. It dynamically switches among three states: direct connection, controlled relay, and disconnection, based on the virus check results. If a file is deemed safe, connections are established; if flagged as malicious, the system isolates the device or file by disconnecting the path. The system also supports logging with a file check history database and a specimen isolation history database for tracking inspection results. Additionally, the system adapts to non-storage USB devices by maintaining direct connections when appropriate.

<CIT> discloses a virus check device that is designed as an intermediary between a portable storage medium and a target connection device, ensuring secure data communication. It incorporates a first and second connection terminal, a data buffer for temporary data storage, and a virus pattern file storage unit. Using a checking mechanism, it compares buffered data against stored virus patterns. If a match is found, the device invalidates data communication by disabling connections and optionally deletes the malicious data. If no match is detected, it permits data transfer. The device may include a display for judgement results and ensures secure operation by enforcing virus checks before enabling data communication.

In one embodiment, an adaptor includes non-volatile memory that stores a scan engine. A removable storage device is connected to the adaptor, which in turn is connected to a host computer. Files being copied between the removable storage device and the host computer through the adaptor are scanned for malware using the scan engine.

These and other features of the present invention will be readily apparent to persons of ordinary skill in the art upon reading the entirety of this disclosure, which includes the accompanying drawings and claims.

The use of the same reference label in different drawings indicates the same or like components.

In the present disclosure, numerous specific details are provided, such as examples of systems, components, and methods, to provide a thorough understanding of embodiments of the invention. Persons of ordinary skill in the art will recognize, however, that the invention can be practiced without one or more of the specific details. In other instances, well-known details are not shown or described to avoid obscuring aspects of the invention.

Embodiments of the present invention are explained in the context of Universal Serial Bus (USB) storage devices and the Microsoft Windows™ operating system as examples. As can be appreciated, embodiments of the present invention are generally suitable for other removable storage devices and other operating systems.

<FIG> shows a logical diagram of an industrial control system (ICS) <NUM> in accordance with an embodiment of the present invention. The ICS <NUM> includes a host computer <NUM> (e.g., workstation, control module) that is used to control and monitor the operation of one or more industrial equipment <NUM>. The host computer <NUM> includes a non-volatile storage device <NUM> that stores one or more files, which in the following examples include a file <NUM>-<NUM> ("FILE4") and a file <NUM>-<NUM> ("FILE5").

An industrial equipment <NUM> may be an industrial robot, process control device, automation equipment, manufacturing equipment, or other industrial equipment. The host computer <NUM> may communicate with the industrial equipment <NUM> over a computer network <NUM>.

In the example of <FIG>, the ICS <NUM> includes an anti-malware adaptor (AMA) <NUM> for moving files to and from the host computer <NUM>. The AMA <NUM> is configured to control access to files stored in a removable storage device <NUM> and to facilitate scanning of files being copied between the host computer <NUM> and the removable storage device <NUM> for malware. In one embodiment, the AMA <NUM> has a male USB connector <NUM> on one end and a female USB connector <NUM> on another end. The USB connector <NUM> is configured to be removably connected to a female USB connector <NUM> of the host computer <NUM>. A male USB connector <NUM> of the removable storage device <NUM> is configured to be removably connected to the USB connector <NUM>.

The removable storage device <NUM> may be a commercially-available removable USB storage device, such as a so-called USB stick or USB flash memory. The removable storage device <NUM> has the male USB connector <NUM>, which is configured to be removably connected to the female USB connector <NUM> of the AMA <NUM>. As can be appreciated, the form factors of the AMA <NUM> and the removable storage device <NUM> do not necessarily have to be the same. Furthermore, the connectors <NUM>, <NUM>, <NUM>, and <NUM> may vary depending on the associated interface standard.

The removable storage device <NUM> includes a non-volatile memory in the form of a flash memory <NUM>. The flash memory <NUM> stores one or more files, which in the following examples include a file <NUM>-<NUM> ("FILE1"), a file <NUM>-<NUM> ("FILE2"), and a file <NUM>-<NUM> ("FILE3").

<FIG> shows a logical diagram of the AMA <NUM> in accordance with an embodiment of the present invention. In the example of <FIG>, the host computer <NUM> includes a hardware processor <NUM> (e.g., central processing unit (CPU)), a memory <NUM> (e.g., random access memory), and the data storage device <NUM> (e.g., hard drive, solid state drive, flash memory). The memory <NUM> stores an operating system <NUM>, which includes kernel layer components and native drivers <NUM>. In one embodiment, the operating system <NUM> is the Microsoft Windows™ operating system, and the drivers <NUM> include storage class drivers and storage port drivers that enable the Microsoft Windows™ operating system to recognize USB mass storage devices and control them as a drive with file system operations. The data storage device <NUM> may store a plurality of files, which in the following examples include the file <NUM>-<NUM> and the file <NUM>-<NUM>.

In the example of <FIG>, the removable storage device <NUM> comprises the flash memory <NUM>, which in the following examples stores the file <NUM>-<NUM>, the file <NUM>-<NUM>, and the file <NUM>-<NUM>. Other components of the removable storage device <NUM>, such as a USB controller, are not shown for clarity of illustration.

In the example of <FIG>, the AMA <NUM> comprises a non-volatile memory in the form of a flash memory <NUM> and an AMA controller <NUM>. The AMA controller <NUM> may comprise a flash memory controller, a microcontroller, main memory, and other electrical circuits. In one embodiment, the AMA controller <NUM> is configured to screen access to the files stored in the removable storage device <NUM> and to facilitate malware scanning of files being copied between the host computer <NUM> and the removable storage device <NUM>.

A host computer and a USB mass storage device may communicate using Small Computer System Interface (SCSI) commands. A SCSI command has a corresponding opcode. The SCSI standard defines several types of devices. Each type of device has a corresponding set of SCSI commands, which are referred to herein as "conventional SCSI commands" for that type. For each type of device, there are <NUM> opcodes that can be divided into three classes, namely Class <NUM>, Class <NUM>, and Class <NUM>. Class <NUM> opcodes are "conventional storage-access SCSI opcodes"; Class <NUM> opcodes are "conventional non-storage-access SCSI opcodes"; and Class <NUM> opcodes are "nonconventional SCSI opcodes. " For brevity, conventional SCSI commands with Class <NUM> opcodes are also referred to herein as "Class <NUM> commands," and conventional SCSI commands with Class <NUM> opcodes are also referred to herein as "Class <NUM> commands.

Class <NUM> commands are conventional SCSI commands that operate on the files and file system of the device. For a USB flash drive, Class <NUM> commands include READ10, WRITE10, FORMAT, etc. Class <NUM> commands are conventional SCSI commands that do not operate on the files or file system of the device. Class <NUM> opcodes are opcodes that are not specified in the SCSI standard for use with the device type. Examples of Class <NUM> opcodes for a USB flash drive include 0x06, 0x09, 0xC0-0xFF, etc..

Conventional programs use Class <NUM> commands and Class <NUM> commands to communicate with a USB mass storage device, such as the removable storage device <NUM>. Vendor-specific programs may, in addition, use several Class <NUM> opcodes for "vendor-specific SCSI commands" to implement features that are specific to the vendor. The AMA controller <NUM> is configured to prevent direct transmission of Class <NUM> commands and vendor-specific SCSI commands between the host computer <NUM> and the removable storage device <NUM>. This prevents conventional programs and vendor-specific programs that are not associated with the AMA <NUM> from accessing the files and file system of the removable storage device <NUM>.

In one embodiment, an AMA app (i.e., application program) <NUM> is configured to communicate with the AMA controller <NUM> using the AMA's <NUM> vendor-specific SCSI commands, which are also referred to herein as "AMA SCSI commands. " The AMA SCSI commands are in a specific format with specific patterns that are recognized by the AMA app <NUM> and the AMA controller <NUM>. The AMA controller <NUM> translates AMA SCSI commands into corresponding conventional Class <NUM> commands to facilitate access to the files and filesystem of the removable storage device <NUM>.

The AMA SCSI commands may use opcodes that are in the range for Class <NUM> opcodes of the removable storage device <NUM>. The AMA controller <NUM> is configured to recognize an AMA SCSI command by checking the command's opcode, format, and pattern, e.g., by looking for a <NUM>-byte magic number at a specific offset. In one embodiment, the AMA app <NUM> does not send Class <NUM> commands; the AMA app <NUM> only sends AMA SCSI commands and Class <NUM> commands.

As will be more apparent below, the AMA app <NUM> may be loaded and executed in the host computer <NUM>. While running in the host computer <NUM>, the AMA app <NUM> may send AMA SCSI commands to the AMA controller <NUM>. The AMA SCSI commands are sent through the native drivers <NUM>, which support a pass-through feature. The AMA controller <NUM> is configured to translate AMA SCSI commands to corresponding Class <NUM> commands that are understood by the removable storage device <NUM>. The AMA controller <NUM> provides the corresponding Class <NUM> commands to the removable storage device <NUM>. The removable storage device <NUM> responds to the Class <NUM> commands in accordance with the SCSI command standards. The AMA controller <NUM> converts the response from the removable storage device <NUM> to a custom response, which the AMA controller <NUM> forwards to the AMA app <NUM>. The AMA app <NUM> understands the custom response and acts accordingly.

In one embodiment, only the components of the AMA <NUM> are expected to use the custom AMA SCSI commands and responses. As can be appreciated, the SCSI commands discussed herein may be replaced with other suitable communication protocol.

In a first embodiment of the AMA controller <NUM>, the AMA controller <NUM> is configured as a USB compound device. Generally speaking, a USB compound device includes a USB hub and one or more USB mass storage devices. The hub functionality of the AMA controller <NUM> allows the removable storage device <NUM> to be connected to the host computer <NUM> through the AMA controller <NUM>. The USB device functionality of the AMA controller <NUM> allows the host computer <NUM> to access the contents of the flash memory <NUM> of the AMA <NUM>. The AMA controller <NUM> provides USB descriptors for the removable storage device <NUM> to the host computer <NUM>. The USB descriptors of the removable storage device <NUM> inform the host computer <NUM> to use the native drivers <NUM> in communications with the AMA <NUM>.

In the first embodiment of the AMA controller <NUM>, each AMA SCSI command has a corresponding Class <NUM> command. The AMA controller <NUM> is configured to reply to Class <NUM> commands and non-AMA vendor-specific commands by sending a masqueraded response to the host computer <NUM>. The response is "masqueraded" in that the response may indicate a successful or failed operation or acknowledgement despite the device <NUM> not performing the operations of the commands.

When the AMA app <NUM> sends an AMA SCSI command to access a file stored in the removable storage device <NUM>, the AMA controller <NUM> translates the AMA SCSI command to its corresponding Class <NUM> command and passes the Class <NUM> command to the removable storage device <NUM>. The AMA controller <NUM> receives a response of the removable storage device <NUM> to the Class <NUM> command. The AMA controller <NUM> converts the response into a custom response understood by the AMA app <NUM> and provides the custom response to the AMA app <NUM>.

In a second embodiment of the AMA controller <NUM>, the AMA controller <NUM> is configured to be a USB host to the removable storage device <NUM> and to be a USB device to the host computer <NUM>. The AMA controller <NUM> may be implemented as a system on a chip (SoC), for example. The USB host functionality of the AMA controller <NUM> detects and identifies the USB devices connected to the AMA <NUM>, which in this example is the removable storage device <NUM>. The AMA controller <NUM> appears as a USB device to the host computer <NUM>. The AMA controller <NUM> provides its USB descriptors to the host computer <NUM> to allow the host computer <NUM> to identify the AMA controller <NUM> (and hence the AMA <NUM>) as a USB mass storage device. The USB descriptors of the AMA controller <NUM> inform the host computer <NUM> to use the native drivers <NUM> in communications with the AMA <NUM>. The USB device functionality of the AMA controller <NUM> allows the host computer <NUM> to access the contents of the flash memory <NUM> of the AMA <NUM>.

In the second embodiment of the AMA controller <NUM>, the AMA <NUM> does not provide USB descriptors of the removable storage device <NUM> to the host computer <NUM>, so that the operating system <NUM> and conventional programs on the host computer <NUM> are not aware of the presence of the removable storage device <NUM>. When the USB device functionality of the AMA controller <NUM> receives a general Class <NUM> command from the host computer <NUM>, the AMA controller <NUM> treats the Class <NUM> command as a command to access the flash memory <NUM> of the AMA <NUM>. Only AMA SCSI commands, which are sent by the AMA app <NUM>, are able to access the files and file system of the removable storage device <NUM>.

In the second embodiment, an AMA SCSI command is interpreted by the AMA controller <NUM> as operations to the removable storage device <NUM>, which may include sending a sequence of conventional SCSI commands (i.e., Class <NUM> and Class <NUM> commands) to the device <NUM>. When the AMA app <NUM> sends an AMA SCSI command to access a file stored in the removable storage device <NUM>, the USB device functionality of the AMA controller <NUM> receives the AMA SCSI command and performs corresponding operations to the removable storage device <NUM>. The AMA controller <NUM>, as the USB host, sends one or more conventional SCSI commands to the removable storage device <NUM> to perform the operation indicated by the AMA SCSI command. The AMA controller <NUM> receives the response of the removable storage device <NUM> and converts the response to a custom response that is understood by the AMA app <NUM>. The USB device functionality of AMA controller <NUM> then sends the custom response to the host computer <NUM>. In the host computer <NUM>, the AMA app <NUM> receives the custom response by way of the native drivers <NUM>.

In light of the present disclosure, one of ordinary skill will appreciate that the AMA <NUM> may be implemented a variety of ways without detracting from the merits of the present invention. For example, a commercial USB device vendor may implement the AMA <NUM> as described herein. The AMA <NUM> may also include additional well-understood components, such as firmware, glue logic, discrete components, etc..

In the example of <FIG>, the flash memory <NUM> stores the AMA app <NUM>, a scan engine <NUM>, and malware patterns <NUM>. The scan engine <NUM> may comprise instructions for scanning a file for malware. In one embodiment, the scan engine <NUM> scans a file for data that match one or more of the malware patterns <NUM>. The scan engine <NUM> may scan a file for malware using a conventional pattern matching algorithm. The scan engine <NUM> may also be implemented using other conventional algorithms for scanning files for malware.

The AMA app <NUM> may comprise instructions for providing a user interface, sending and receiving files to and from the AMA <NUM>, and initiating scanning of files to be copied between the removable storage device <NUM> and the host computer <NUM>. In one embodiment, the AMA app <NUM> is provided as an executable file (see <FIG>, <NUM>). The AMA app <NUM> is launched to be executed by the hardware processor <NUM> of the host computer <NUM> when the AMA app <NUM> is activated by the user.

<FIG> show screen shots that illustrate an example operation of the AMA <NUM> in accordance with an embodiment of the present invention. The screen shots are from a display screen of the host computer <NUM> running the Microsoft Windows™ operating system as an example. The removable storage device <NUM> is plugged to the AMA <NUM>, which in turn is plugged to the host computer <NUM>.

Referring first to <FIG>, after the user plugged the AMA <NUM> to the host computer <NUM>, a logical drive F (see <NUM>) becomes visible in a Windows Explorer™ window <NUM>. The logical drive F corresponds to the flash memory <NUM> of the AMA <NUM> (see <FIG>, <NUM>), which contains the scan engine <NUM>, the patterns <NUM>, and the AMA app <NUM>. The AMA <NUM> is configured to present the flash memory <NUM> as storage of a conventional read-only USB device to the host computer <NUM>, allowing the operating system <NUM> of the host computer <NUM> to see and read the contents of the flash memory <NUM> using its native drivers <NUM>. In one embodiment, the scan engine <NUM> is stored in a directory <NUM>, the patterns <NUM> are stored in a directory <NUM>, and the AMA app <NUM> is provided as an executable file "AMAapp. Note that the contents of the removable storage device <NUM> are not visible on the Windows Explorer™ window <NUM>.

<FIG> shows a screen shot that follows <FIG> when the user activates the AMA app <NUM> to execute, such as by clicking on the executable file "AMAapp. The activation loads the AMA app <NUM> in the memory <NUM> of the host computer <NUM> for execution by the processor <NUM> of the host computer <NUM>. Upon execution, the AMA app <NUM> launches a user interface <NUM>, which in one embodiment is a custom file explorer, and loads the scan engine <NUM> and the malware patterns <NUM> in the memory <NUM> of the host computer <NUM>. The user interface <NUM> includes a tab ("Explore") for showing the contents of the flash memory <NUM> of the removable storage device <NUM> (see <FIG>, <NUM>), a tab ("Log") for showing log entries, and a tab ("About") for showing information about the AMA <NUM>.

The AMA app <NUM> uses AMA SCSI commands to access the contents of the removable storage device <NUM>. The AMA <NUM> receives the AMA SCSI commands, translates the AMA SCSI commands to corresponding Class <NUM> commands, and passes the Class <NUM> commands to the removable storage device <NUM>. The removable storage device <NUM> provides one or more responses to the Class <NUM> commands. The AMA <NUM> receives the responses, converts the responses to custom responses, and forwards the custom responses to the AMA app <NUM>. The AMA SCSI commands and responses may be passed between the AMA <NUM> and the AMA app <NUM> running on the host computer <NUM> through the native drivers <NUM>, which as noted are the native drivers of the Microsoft Windows™ operating system.

The AMA app <NUM> reads the contents of the removable storage device <NUM> by way of AMA SCSI commands and responses as previously described. In the example of <FIG>, the removable storage device <NUM> contains the files <NUM>-<NUM>, <NUM>-<NUM>, and <NUM>-<NUM>. The AMA app <NUM> displays representations of the files <NUM>-<NUM>, <NUM>-<NUM>, and <NUM>-<NUM> on the user interface <NUM>, allowing the user to see the contents of the removable storage device <NUM>.

<FIG> shows a screen shot that follows <FIG> when the user selects a logical drive D of the storage device <NUM> of the host computer <NUM> (see <FIG>, <NUM>) and attempts to copy the files <NUM>-<NUM> and <NUM>-<NUM> to the removable storage device <NUM> (see arrow <NUM>), such as by dragging the files <NUM>-<NUM> and <NUM>-<NUM> to the user interface <NUM>. The AMA app <NUM> is configured to initiate copying to the removable storage device <NUM> one or more files that are dragged to the user interface <NUM>. The AMA app <NUM>, using the scan engine <NUM>, is configured to scan for malware any file that is being copied between the host computer <NUM> and the removable storage device <NUM>. Accordingly, in the example of <FIG>, the AMA app <NUM> invokes the scan engine <NUM> to scan the files <NUM>-<NUM> and <NUM>-<NUM> for malware (see action <NUM>). In the example of <FIG>, the file <NUM>-<NUM> is detected to be malware, and accordingly is blocked by the AMA app <NUM> from being copied to the removable storage device <NUM> (see action <NUM>). The AMA app <NUM> displays a message <NUM> on the user interface <NUM> to alert the user that the file <NUM>-<NUM> has been detected to be malware.

In the example of <FIG>, the file <NUM>-<NUM> passes the malware scanning, and accordingly is copied by the AMA app <NUM> to the removable storage device <NUM> through the AMA <NUM>. The AMA app <NUM> uses AMA SCSI commands to forward the file <NUM>-<NUM> to the AMA <NUM> by way of the native drivers <NUM>. The AMA <NUM> receives the file <NUM>-<NUM>, converts the AMA custom SCSI commands to corresponding Class <NUM> commands, which are natively recognized by the removable storage device <NUM>. The removable storage device <NUM> stores the file <NUM>-<NUM> in the flash memory <NUM> in accordance with the received Class <NUM> commands.

<FIG> shows a screen shot that follows <FIG> when the user attempts to copy the files <NUM>-<NUM>, <NUM>-<NUM>, and <NUM>-<NUM> from the removable storage device <NUM> to the logical drive D of the data storage device <NUM>, such as by dragging the files <NUM>-<NUM>, <NUM>-<NUM>, and <NUM>-<NUM> from the user interface <NUM> to the window <NUM> (see arrow <NUM>) with the logical drive D being selected (see <FIG>, <NUM>). The AMA app <NUM> is configured to initiate copying to the host computer <NUM> one or more files that are dragged from the user interface <NUM> to the window <NUM>. The AMA app <NUM> is configured to scan for malware any file that is being copied between the host computer <NUM> and the removable storage device <NUM>. Accordingly, the AMA app <NUM> reads the files <NUM>-<NUM>, <NUM>-<NUM>, and <NUM>-<NUM> from the removable storage device <NUM> using AMA SCSI commands as previously described and loads them into the memory <NUM> of the host computer <NUM>. The AMA app <NUM> thereafter invokes the scan engine <NUM> to scan the files <NUM>-<NUM>, <NUM>-<NUM>, and <NUM>-<NUM> for malware in the memory <NUM> of the host computer <NUM> (see action <NUM>).

In the example of <FIG>, the file <NUM>-<NUM> is detected to be malware and accordingly is blocked by the AMA app <NUM> from being copied to the host computer <NUM> (see action <NUM>). Blocking the copying of the file <NUM>-<NUM> includes removing the file <NUM>-<NUM> from the memory <NUM> of the host computer <NUM> and preventing subsequent copying of the file <NUM>-<NUM> through the AMA <NUM>. This results in the file <NUM>-<NUM> being prevented from being stored in its intended destination in the host computer <NUM>, which is the logical drive D in this example. The AMA app <NUM> displays a message <NUM> on the user interface <NUM> to alert the user that the file <NUM>-<NUM> has been found to be malware. In the example of <FIG>, the files <NUM>-<NUM> and <NUM>-<NUM> are not detected to be malware. Accordingly, the AMA app <NUM> stores the files <NUM>-<NUM> and <NUM>-<NUM> in their intended destination in the host computer <NUM>, which is the logical drive D.

In the above embodiments, the AMA <NUM> is configured to perform malware scanning using computing resources (i.e., processor <NUM>, memory <NUM>) of the host computer <NUM>. As can be appreciated, malware scanning may also be performed in the AMA <NUM> depending on the computing resources of the AMA <NUM>. For example, the AMA <NUM> may be implemented with a relatively fast processor, fast and large memory, etc. Doing so would result in increased performance and effectiveness, but would also increase the manufacturing cost, complexity, and power consumption of the AMA <NUM>. As can be appreciated, in the implementation of the AMA <NUM>, engineering trade-offs may be made to address particular OT security requirements.

<FIG> shows a flow diagram of a method <NUM> of scanning files being copied between a host computer and a removable storage device for malware in accordance with an embodiment of the present invention.

In the method <NUM>, a removable storage device is removably connected to an adaptor (step <NUM>) and the adaptor is in turn removably connected to a host computer (step <NUM>). A scan engine of the adaptor scans for malware a first file being copied from the host computer to the removable storage device through the adaptor (step <NUM>). Similarly, the scan engine of the adaptor scans for malware a second file being copied from the removable storage device to the host computer through the adaptor (step <NUM>). Any file that is detected to be malware is blocked from being copied between the removable storage device and the host computer (step <NUM>). Blocking copying of a file includes preventing the file from being transferred through the adaptor after detecting the file in the host to be malware. Blocking copying of the file also includes preventing the file from being stored in its intended non-volatile memory storage destination in the removable storage device or the host computer. Any file that is not detected to be malware is allowed to be copied between the removable storage device and the host computer through the adaptor (step <NUM>).

Claim 1:
An anti-malware adaptor comprising:
a first connector that is configured to be removably connected to a connector of a removable storage device;
a second connector that is configured to be removably connected to a connector of a host computer;
a non-volatile memory that stores a scan engine and an application program that are loaded and executed in the host computer; and
a controller that is configured to translate vendor-specific Small Computer System Interface (SCSI) commands received from the application program executing in the host computer into SCSI commands that operate on files stored in the removable storage device to load the files from the removable storage device into the host computer for scanning by the scan engine for malware.