FIELD OF THE INVENTION

[0001] A system and method for securing computer systems with otherwise nonsecure computer interfaces. Particular embodiments of the invention include methods and apparatuses for capturing, processing, delivering, and analyzing traffic on one or more computer interfaces based on security policies.

BACKGROUND OF THE INVENTION

[0002] Conventional computing devices typically include one to many conventional types of input/output (I/O) ports for communicating with connectable external devices such as mice, keyboards, wireless modems, etc. Such computing devices further include one or more internal connections between a host processor (e.g. CPU) with internal devices such as storage devices (e.g. SATA/SAS drives), In conventional devices, these internal and external communications are rarely secured.

[0003] With respect to I/O ports, for example, Universal Serial Bus (USB) is a standard communication protocol between a host computer and peripheral devices. However, USB does not provide any level of security for the data transmitted from the peripheral devices to the host system. This poses a huge risk for enterprises, and more particularly, IT administrators who are responsible for securing their IT systems and devices.

[0004] USB is inherently not secure for several reasons. One reason is that USB data is sent in plain text. The data can be captured and analyzed by any USB protocol analyzer or software application. Another reason is that any USB peripheral is capable of connecting to a host computer since USB specification doesn't provide any means to filter unwanted or potential ly harmful devices.

[0005] Relatedly, security can be compromised in various ways by the

communication of various types of data. In organizations and/or environments where the security for many different computer systems need to managed, mechanisms are needed to deal with certain types of data and communications in an efficient but fast way,

SUMMARY OF THE INVENTION

[0006] The present invention relates to methods and apparatuses for securing otherwise unsecured computer communications that addresses the above shortcomings among others, According to certain aspects, the invention relates to methods and apparatuses for implementing device snooping, in which some or all traffic passing between a host and a connected device is captured into memory and analyzed in real time by system software. According to other aspects, the invention relates to real time capture of certain types of traffic and communication of the captured traffic to a remote management system. According to still further aspects, the invention relates to detecting security threats in real time. Upon threat detection, possible actions are blocking individual devices or alerting a system administrator. According to certain additional aspects, the security functions performed by methods and apparatuses according to the invention can be logically transparent to the upstream host and to the downstream device.

[0007] In accordance with these and other aspects, a computer system according to embodiments of the invention includes an interface for sending and receiving data, a host that executes an operating system and applications that generate and utilize the data sent and received via the interface, and a secure subsystem interposed between the host and the interface for transparently capturing certain of the data sent and received via the interface.

BRIEF DESCRIPTION OF THE DRAWINGS

(0008) These and other aspects and features of the present invention will become apparent to those ordinarily skilled in the art upon review of the following description of specific embodiments of the invention in conjunction with the accompanying figures, wherein:

[0009] FIG. 1 is a block diagram illustrating an example system for securing otherwise unsecure interface communications according to embodiments of the invention;

[0010] FIG, 2 is a block diagram illustrating another example system for securing

USB I/O communications according to embodiments of the invention;

[0011 ] FIG. 3 is a block diagram illustrating another example system for securing

SATA and/or Ethernet I/O communications according to embodiments of the invention;

[0012| FIG. 4 is a more detailed block diagram illustrating an example subsystem that can be included in the systems shown in FIGs. 1 , 2 and 3 according to embodiments of the invention;

[0013] FIG. 5 is a block diagram illustrating an example configuration of snoop logic that can be included in a subsystem such as that shown in FIG. 4; [0014) FIG. 6 is a block diagram illustrating an example remote management system that can be included in the systems shown in FIGs. 1 , 2 and 3 according to embodiments of the invention; and

[0015] FIG. 7 is a flowchart illustrating an example methodology for snooping, capturing and/or analyzing I/O communications according to embodiments of the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0016) The present invention will now be described in detail with reference to the drawings, which are provided as illustrative examples of the invention so as to enable those skilled in the art to practice the invention. Notably, the figures and examples below are not meant to limit the scope of the present invention to a single embodiment, but other embodiments are possible by way of interchange of some or all of the described or illustrated elements. Moreover, where certain elements of the present invention can be partially or fully implemented using known components, only those portions of such known components that are necessary for an understanding of the present invention will be described, and detailed descriptions of other portions of such known components will be omitted so as not to obscure the invention. Embodiments described as being implemented in software should not be limited thereto, but can include embodiments implemented in hardware, or combinations of software and hardware, and vice-versa, as will be apparent to those skilled in the art, unless otherwise specified herein. In the present specification, an embodiment showing a singular component should not be considered limiting; rather, the invention is intended to encompass other embodiments including a plurality of the same component, and vice-versa, unless explicitly stated otherwise herein. Moreover, applicants do not intend for any term in the specification or claims to be ascribed an uncommon or special meaning unless explicitly set forth as such. Further, the present invention encompasses present and future known equivalents to the known components referred to herein by way of illustration.

[0017] According to general aspects, embodiments of the invention enable device snooping, in which some or all traffic passing between a host and a connected device is captured into memory, stored and/or analyzed in real time by local or remote system software.

[0018] FIG. 1 is a system level block diagram of a management system 100 according to embodiments of the invention. As shown, system 100 includes a managed secure computer 120 comprising a Host 102, Secure Subsystem 104, and two directly attached (internally or externally) devices 1 10-1 and 1 10-2.

[0019] There are many possible configurations of system 100, host 102, subsystem

104 and attached devices 106 that all fall within the scope of the invention, and the present invention is not limited to any particular configuration. In one non-limiting example configuration, secure computer 120 is a standalone computer system, similar to a conventional desktop, laptop or pad computer. In such an example, host 102 is implemented by a CPU (e.g. x86), a conventional operating system such as Windows and associated device driver software, as well as I/O interfaces such as SATA hosts and USB hosts. In accordance with certain aspects of the invention, in this example, the operation and functionality of subsystem 104 is completely transparent to the host 102 and associated operating system and application software. Moreover, the operating experience of secure computer 120 by a user is identical to the experience of a conventional desktop, laptop or pad computer, apart from the security functionality of the present invention. So while the application software that can run on the computer is virtually unrestricted, use of devices 1 10 is strictly controlled by subsystem 106 which enforces security policies as will be described in more detail below.

[0020] In these and other embodiments, subsystem 104 is preferably an embedded system, As such, it runs a designated software system furnished together with an embedded processor, and can not be modified by the end-user of the computer under any circumstances. According to aspects of the present invention, subsystem 104 performs one or more of the following functions: capturing of traffic between host 1 02 and device(s) 1 10 (traffic can be USB, SAS, SATA, Ethernet, Firewire (IEEE 1394), Thunderbolt, etc.); pre-processing of traffic; buffering of traffic for later analysis and/or capture; delivering traffic to the remote management system 106; and monitoring of traffic to detect security threats in real time. Upon threat detection, possible actions can include blocking individual devices or alerting system administrator, In embodiments, the particular functions performed by subsystem can be configured based on security policies set by remote management system 106.

[0021 [ An example architecture for implementing subsystem 104 together with host

102 is described in co-pending application No. 13/971 ,732 (UNI-012), the contents of which are incorporated by reference herein. Those skilled in the art will understand how to implement the principles of the present invention in various configurations of secure computer 120 after being taught by the present disclosure. [0022] Devices 1 10 can include peripheral devices such as keyboards, mice, touchpads, touchscreens, displays, monitors, printers, etc. Devices 1 10 can also include internal and external storage devices such as disk drives, thumb drives, memory cards, etc. Devices 106 can also include network access interfaces such as Ethernet, Firewire, etc. as well as other communication interfaces such as WiFi, Bluetooth, 3G or 4G-LTE, etc.

[0023] In general, the types of communications used by devices 1 10 and monitored by the present inventions are point to point. The differences between them are at the protocol level, and generally transparent to the security features performed by the present invention (with some exceptions).

[0024] Various aspects of secure computer 120 that can be adapted for use in, or practiced together with, the present invention are described in more detail in co-pending application No, 13/971 , 582(UNI-007), the contents of which are incorporated herein by reference in their entirety.

[0025] FIG. 1 further shows a Remote Management system 106 coupled to secure subsystem 1 04 of secure computer 1 20 by a communication channel 108, FIG. 1 also shows the different message types that can be sent over a Communication Channel 108, specifically status messages 1 12 from secure subsystem 104 to remote management system 106, control messages 1 14 from remote management system 106 to secure subsystem 104, and data messages 1 16 from secure subsystem 104 to remote management system 106.

[0026] Although FIG. 1 shows remote management system 106 coupled to only one secure subsystem 104, it should be apparent that one or more additional secure subsystems 104 may be similarly coupled to remote management system 106.

[0027] Channel 108 can be implemented in various ways, possibly depending on the number and type of devices to be managed by system 106, Channel 108 can be a separate direct point-to-point link between system 106 and subsystem 1 04, In other embodiments, channel 108 can be implemented by a transmission medium that is shared between many subsystems 104. In these and other embodiments, the medium can be any combination of wired or wireless media, such as Ethernet or Wireless LAN. In these and other embodiments, channel 108 can be implemented by various types and/or combinations of public and private networks using proprietary protocols or conventional protocols such as UDP or TCP. In embodiments, data sent over communication channel 108 is encrypted, for example using secure VPN, to improve security, According to general aspects, in embodiments of the invention, remote management system 106 is responsible for saving traffic captured from one or more subsystems 104 and analyzing the traffic. In embodiments, traffic from multiple subsystems 104 is saved into a databaselike structure that facilitates fast (near real-time) search for interesting events such as security threat signatures, For example, system 106 can analyze suspicious activity from multiple computers 120, cross-correlating snooping data from various PCs and looking for irregular or suspicious data and usage patterns. A more thorough forensic analysis can be also performed at slower speed. Background tagging and indexing of this database can be optionally implemented.

[0028] Control messages 1 14 sent from Remote Management System 106 to one or more Secure I/O Subsystems 104 contain different configuration commands and settings to be described in more detail below. Status messages 1 12 sent from one or more Secure I/O Subsystem 104 to Remote Management System 106 contain different notifications and alerts, Example of status messages 1 12 include alerts of security threats detected by Secure I/O subsystem 104 based on data communicated between host 102 and devices 1 10 and snooped by secure I/O subsystem 104. Data messages 1 16 from Secure I/O Subsystem 104 to Remote Management System 106 include (optionally) filtered and compressed data that has been captured from communications between host 102 and devices 1.10 by Secure I/O Subsystem 104.

[0029| FIG. 2 is a block diagram illustrating another example management system

200 according to embodiments of the invention. In this example, the system manages security of computer communications and the example type of traffic is USB. As shown in this example, the system includes two USB secure subsystems 204- 1 and 204-2 connected to Remote Management System 106 via respective communication channels 108- 1 and 108-2.

[0030] As is known, USB allows a more complex topology, and this diagram illustrates how the invention can be applied to this and other types of I/O with such topologies. For example, as shown in FIG. 2, remote management system 106 manages secure USB communications for four USB Hosts 202- 1 , 202-2, 202-3 and 202-4, two USB Hubs 212- 1 and 212-2, and six USB devices 210- 1 to 210-6 connected either directly to the Secure USB Subsystems 204- 1 and 204-2 or via USB Hubs 212- 1 and 212-2. As described above, USB Host 202- 1 or 202-2 can be included in a variety of computing devices including, but not limited to a server, a PC, or an embedded device such as secure computer 120. [0031 ] Example aspects of securing I/O communications such as USB in a computer system that can be adapted for use in the present invention are described in more detail in copending Application No. 1 3/971 ,582 (UNI-007).

[0032] FIG. 3 is a top-level block diagram of another example management system

300. It shows two different 10 types being managed - SATA and Ethernet, respectively connected to Secure I/O Subsystems 304- 1 and 304-2. The Two 10 Secure Subsystems are connected to Remote Management System 106 via connections 108- 1 and 108-2.

[0033] As shown, SATA secure subsystem 304- 1 has upstream port(s) coupled to

SATA initiator 302- 1 and downstream ports coupled to SATA target 3 10-1 - 1 and SATA expander 320. SATA expander 320 is further coupled to SATA targets 310-1 -2 and 31 -1 -3. Example aspects of a SATA secure subsystem that can be adapted for use in the present invention are described in co-pending application No. 13/971 ,732 (UNI-012), the contents of which are incorporated herein by reference in their entirety.

[0034] Secure I/O subsystem 304-2 is coupled between two Ethernet devices 310-2-1 and 310-2. In embodiments, subsystem 304-2 includes a secure CPU network inputs, Rx Packet Parsers, Packet Processors with associated Classification and Rules Tables, Packet Editors, a Security Engine, a Tx Packet Switch and network outputs. Incoming traffic is analyzed based on rules set by the secure CPU in the classification engines and then forwarded to the appropriate network output. It may also pass through the Security Engine thereafter for further processing (e.g. decrypting/encrypting and/or hashing). This enables the secure CPU to transparently track/snoop/enable/disable/etc.. . network packets, network flows (e.g. TCP, UDP, IPSec, SSL, etc. . . connections) and perform deep packet inspection to further analyze the content of the network traffic (e.g. to identify which web sites are being connected to, to try to identify malware, etc.).

[0035| In embodiments, secure subsystems 304- 1 and 304-2 are included in different secure computers 120- 1 and 120-2, in local or remote locations from each other. In other embodiments, the secure subsystems 304-1 and 304-2 are in a common secure computer 120, In such embodiments, connections 108-1 and 108-2 can be a shared connection, while subsystems 304-1 and 304-2 are implemented separately.

[0036] FIG. 4 is a block diagram of an example secure subsystem 504 that can implement certain or all of the traffic snooping/capturing functionality of subsystems 104, 204, 304 and 404 according to embodiments of the present invention. [0037| As shown in FIG. 4, example subsystem 504 consists of one to N instances of the I/O Bridge Logic 532, a controller 534, memory controller 536 for storing captured I/O traffic, register access interface 538 for providing access to registers of I/O Bridge(s) 532 and I/O Snoop Logic 544 by the Controller 534, DMA controller 540 for facilitating data transfer between memory controller 536 and remote management system 106, Ethernet controller 542, I/O snoop logic 544 (described in more detail below) and

compression/encryption/decryption block 546.

[0038] Each instance of logic 532- 1 to 532-N is connected between one or more I/O devices (e.g. USB hub/device, Ethernet peer, SAS/SATA target, etc.) and a corresponding I/O host (e.g. USB host, Ethernet peer, SAS/SATA initiator, etc.) . In embodiments, a single subsystem 504 includes logic 532 for only a single particular type of interface (e.g. USB). In other embodiments, a single subsystem 504 includes logic 502 for a plurality of different types of interfaces,

[0039] In embodiments, bridge logic 532 is responsible for providing access to traffic between I/O devices according to configuration policies. For example, when an administrator wishes to cause certain types of USB communications to be snooped (e.g. communications with all attached USB thumb drives), remote management system 106 configures its policies appropriately and communicates the configuration to subsystem 104. Thereafter, whenever the particular device is attached (e.g. when a USB thumb drive is plugged into a USB port), this is detected by the associated bridge logic 532-1 to 532-N. Controller 534 and logic 532 cooperate to configure the channel for snooping. For all subsequent communications between the USB device and host, USB packet contents are provided to snoop logic 544, transparently to both the USB device and host.

[0040] The embodiment of FIG. 4 depicts blocks that are common to different types of I/O channels such as USB, Ethernet, SAS, and SATA. One implementation of the example subsystem 504 shown in FIG. 4 for securing USB communications (e.g.

gatekeeping) is further described in co-pending U.S. Application No. 13/971 ,582 (UNI-007), and those ski l led in the art wi ll be able to implement the additional functionality of the present invention after being taught by the present invention. Those skilled in the art will further understand how to adapt the secure USB subsystem described in those applications for other types of communications and configurations for use with the management system 106 of the present invention after being taught by the present disclosure. [0041 ] In embodiments, controller 534 can be implemented as CPU running embedded software. In other embodiments, controller 534 can be implemented entirely in hardware. In this example embodiment, Ethernet controller 542 is used to handle communications of data with remote management system. Other types of communications are possible.

[0042] Embedded software running on controller 534 can compress and encrypt the data that is sent to remote management system 106. Alternatively, those functionalities can be offloaded to a separate module 546 implemented in hardware to improve performance as shown in the example of FIG. 4,

(0043 ) More particularly, encryption/decryption/compression block 546 can be optionally included to perform transparent encryption and decryption of data that is sent to and received from, respectively, downstream devices. Example aspects of an

encryption/decryption block 546 that can be optionally practiced with and adapted for use in the present invention are described in co-pending Application No. 13/971 ,632 (UNI-010), the contents of which are incorporated herein by reference in their entirety. Block 546 can further perform compression of data, for example compressing captured data before it is sent to system 106.

[0044) FIG. 5 is a block diagram of an example implementation of snoop logic 544 according to embodiments of the present invention. As shown in FIG. 5, example I/O snoop logic 544 includes one instance of trigger engine 642, filter engine 644 and capture block builder 646 for each associated bridge logic 532 1 to N, and Capture Buffer Controller 648.

It should be noted that in embodiments such as that shown in FIG. 5, each I/O channel (e.g. N channels shown in FIG. 4) consists of both Rx and Tx paths. So the N channels in FIG. 4 would have 2N trigger and filter engines such as those shown in FIG, 5. In other words, the quantities N in FIGs. 4 and 5 are different.

[0045] The purpose of Filter Engine 644 is to perform deep filtering of the captured

IO traffic. The importance of deep filtering is illustrated in the following example. Assume there are two USB 3.0 channels being monitored by subsystem 102. Each channel is bidirectional and capable of sending 400MByte/sec of useful payload, Further assume that subsystem 1 04 is connected to remote management system 106 over an Ethernet connection with available bandwidth of l OMByte/sec. Still further assume that remote management system 106 is capable of storing and analyzing the data at the Ethernet speed.

[0046] Therefore, a worst case filtering ratio of the USB traffic should be: 10/400*2*2=0.625%

[0047] This ratio is realistic because a system may have components with those typical rates. In general, available network bandwidth is typically smaller than client I/O bandwidth. For example, USB 3.0 (an example I/O associated with logic 532) is 5 Gbps whereas Ethernet (an example network connection for channel 108) is 1 Gbps. In reality, moreover, a network connection may only be on the order of tens of Mbps (for a WAN connection) or a few hundred Mbps in a LAN.

[0048] In embodiments, filter engine 644 accomplishes this ratio by not processing certain packet types, such as control packets and/or some or all of the contents of packet payloads. Another factor that can further complicate certain systems is the fact that available network bandwidth is constantly changing because it's shared among multiple connections. Accordingly, in embodiments, filter engine 644 constantly monitors packet queue size associated with channel 108, determines changing conditions, and adjusts the ratio accordingly.

[0049J Triggering is another mechanism to further reduce the amount of traffic sent to the remote management system 106. In embodiments, triggering engine 642 and filtering engine 644 work in tandem to reduce the amount of I/O traffic that is processed, for example in accordance with constantly changing available Ethernet or other bandwidth between subsystem 104 and system 106, For example, filtering reduces traffic based on "steady-state" criteria; i.e., reducing the overall traffic rate from x to y based on various filtering conditions. As stated, the filtering criteria can also change in order to ensure a max rate y is not exceeded. Triggering is a way to capture data only when a specific event occurs (i.e. a suspect IP address is contacted). In such a case, it is desirable to collect as much information about that event as possible, Accordingly, both filtering and triggering can work together, Traffic can be filtered but not passed on until a given Trigger occurs, or filtered traffic can always be forward to the remote management system 106 but if an event triggers then the snooped traffic is no longer filtered, or filtered differently,

[0050) Trigger engine 642 also enables security threats to be detected in real time so that communications involving an insecure device can be blocked, This is achieved by both simple packet triggering (field-based pattern matching) and a more complex transaction-level triggering, In such a case, according to embodiments of the invention, after a trigger event is detected, data is captured and sent to remote management system 106. If system 106 determines that the data involves a security threat, system 106 can instruct the secure subsystem 104 to completely block the associated device 1 10.

[0051] Both filtering engine 644 and triggering engine 642 can be configured by remote management system 106 and/or controller 534 based on security policies and the device(s) attached to the corresponding bridge logic 532.

[0052] Capture Block Builder (CBB) 646 receives filtered I/O data from filter engines

644 and matching I/O data from trigger engines 642. CBB 646 encapsulates the data in a format suitable for software post-processing and analysis (data blocks). For example, CBB 646 can add timestamp and other metadata to be able to correlate 10 traffic from different channels. Capture Buffer Controller 648 aggregates data blocks from multiple CBB 646 modules and commits them into memory via memory controller 536.

[0053] In the example embodiment shown in FIG. 4, controller 534 can then read the data blocks and send them to remote management system 106 over an Ethernet connection.

[0054| FIG. 6 is a block diagram illustrating an example implementation of a Remote

Management System 106 according to embodiments of the invention. In the example of FIG. 6, Remote Management System 106 includes a Processor 702, a Communication Channel Interface 704, a Captured Data Repository 706, and Administrator Interface 708 and Policies 710.

[0055] Processor 702 can include any suitable type of CPU or processor (e.g. x86, etc.) executing any suitable type of operating system (e.g. Unix, Linux, Windows, etc.) and/or application software. Such application software can implement and/or include functionality to manage elements 704, 706, 708 and 710, as will become more apparent to those skilled in the art after being taught by the present disclosure.

[0056] Communication channel interface 704 is responsible for exchanging messages and/or data between system 106 and subsystem(s) 104 via communication channel(s) 108. The implementation details of interface 704 can depend on the type of communications used on channel 108. In one possible implementation, communication channel interface 704 includes an Ethernet interface.

[0057] Captured data repository 706 includes data captured by security subsystems

104 and communicated to system 106 via channels 108 and interface 704. In embodiments, repository 706 comprises a database-like structure that facilitates fast (near real-time) search for interesting events such as security threat signatures. Moreover, processor 702 can perform rapid and basic analysis on selected incoming data from interface 704. The analysis algorithms can include pattern matching, network flow analysis, etc. A more thorough forensic analysis of data in repository 706 can be performed at slower speed, perhaps in the background, and perhaps using many servers to analyze and cross-correlate data from multiple secure computers 102. These algorithms can be very complex and are typically proprietary (for example "big-data" analysis). Background tagging and indexing of database 706 can be optionally implemented.

[0058| Administrator interface 708 provides an interactive user interface that allows an administrator to configure policies 710 and/or receive alerts regarding communications with managed I/O devices.

[0059] Policies 710 define operational aspects of how devices associated with subsystem(s) 104 are configured, including policies for secure communications. The number and type of policies 710 managed by system 106 depend on the number and types of device configurations and communication security functions that are desired for a particular implementation of secure system 100, These can include any number and combination of configurations and security functions described in co-pending applications Nos. 13/971 ,582 (U -007), 13/971 ,71 l (UNI-008), 13/971 ,632 (UNI-010), 13/971 ,732 (UNI-012),

13/971 ,651 (UNI-013), and 13/971 ,692 (UNI-015). Those skilled in the art will be able to implement policies 710 for any such number of configurations and security functions after being taught by the present disclosure and the co-pending applications,

[0060] In connection with the traffic snooping/capturing functionalities of the present invention, policies 710 can include a list of types of devices from which to capture data and/or pre-defined keywords to detect. Additionally and relatedly, policies 710 can include situations when an alert is generated, For example, an alert may be issued when certain Ethernet packet header information is detected, if certain online addresses are accessed, if certain types of files (e.g. known malware) are communicated, etc.

[0061 ] Additional aspects of policies 710 and how they are managed and used according to embodiments of the invention will become more apparent from co-pending application No. 13/971 ,71 1 (UNI-008).

|0062] FIG. 7 is a flowchart illustrating an example methodology performed by subsystem 104 and management system 106 for managing security of I/O channels according to embodiments of the invention. [0063] In step S802, policies 710 are configured. This can include adding new policies, deleting policies, and changing policies. In embodiments, such additions, deletions and changes are performed by an administrator interacting with a user interface that presents fields for different types of I/O channels and different security options. In other embodiments, policies are downloaded from an external source as scripts or configuration files.

[0064] Policies can be any variation between broad and specific. For example, policies can be configured that apply to an entire I/O type, to a device class, to a device vendor, to a specific product ID, unique device serial numbers, etc. Policies can also be dependent on a specific secure computer 120, a given user, or the attached devices of a given secure computer 120 and/or its user In general, policies dictate every operational aspect of the secure computer 120 and its associated complexes; their configuration, how and when they should operate, if and how they should snoop, what they should report as status, etc. As further set forth previously, policies can include any of a variety of actions to be taken such as limiting the devices that are allowed to be connected to the host (e.g. gatekeeping by device class), performing encryption, snooping, etc. Accordingly, the complexity and variety of actions in step S802 can depend on the configuration and security options available in the policies for any given application.

[0065] In step S804, the configured policies are sent to secure computers 120. In embodiments such as that shown in FIG. 7, policies are sent to computers 120 and in step S806 subsystems 104 are responsible for implementing the policies, such as configuring trigger/filter engines when snooping is required for a particular type of I/O or attached device. In other embodiments, policies are maintained only by the system 106, and system 106 communicates policies to secure subsystems only on an as-needed basis, such as when a new I/O device is connected to a system managed by a secure subsystem, or when a host device (e.g. PC) associated with a secure subsystem "boots" (i.e., wakes up). In these and other embodiments, there can be a set of default policies per computer 120 (or group of computers 120) and/or per user that are locally pre-stored in computers 120 and accessed by subsystems 104 whenever the computers are powered on, These policies can then be modified/updated dynamical ly by system 106 (automatically) or by the system administrator (manually) via the system 106 and downloaded when needed.

|0066) It should be apparent that other security actions can be taken when a device managed by the system boots or seeks network access. For example, the system can interact with secure computers 120 to first establish a VPN connection with the remote management system 1 06 and only thereafter access an overall network,

[0067) In step S808, as computer 120 is operating, any communications with devices configured for snooping are sent by logic 532 to the snoop logic 544, In step S810, snoop logic 532 determines if and what data is to be captured. These determinations can be made by the trigger and filter engines 642 and 644 as described above. In embodiments, there can also be a non-event type of data snooping. For example, all user mouse and keyboard input data can be configured to be sent to the remote management system 106. As another example, all user log-in/off information and/or all device attachment information can be sent to system 106.

[0068] In step S812, if data is to be captured, snoop logic 544 collects the (optionally filtered) data and subsystem 104 sends it to remote management 106, perhaps after further compression. Otherwise, processing returns to step S810 to determine if any data needs to be captured.

(0069) In step S814, system 106 can analyze the captured information (in real time or in a background mode) to determine whether any alert condition exists. If so, the alert is handled in step S816. An alert can be generated, for example, when a device has been configured for traffic snooping and a violation of a policy has been detected. As described above, a violation can be the occurrence of any number or combination of pre-defined keywords in snooped traffic. Other types of alerts can be generated automatically such as periodic status notifications from secure subsystems (e.g. heartbeat).

[0070] In embodiments, the handling of an alert can include generating an audible and/or visual signal for an administrator, The alert can also include an email message, a text message, a voice call, a desktop alert, etc. Handling an alert can also include updating a policy, applying a new or changed policy to an affected device, directly accessing the managed device, etc. In such a case, processing may return to step S804 where updated policies are sent back to the affected computer 120.

Although the present invention has been particularly described with reference to the preferred embodiments thereof, it should be readily apparent to those of ordinary skill in the art that changes and modifications in the form and details may be made without departing from the spirit and scope of the invention. It is intended that the appended claims encompass such changes and modifications.