Dynamic guest image creation and rollback

Description

1. FIELD

Embodiments of the disclosure relate to the field of data security. More specifically, one embodiment of the disclosure relates to a system, apparatus and method for increasing the accuracy in detecting exploits in flows through the use of dynamic guest images and substantially decreasing the amount of time for remediation of an infected electronic device.

2. GENERAL BACKGROUND

Over the last decade or so, malicious software has become a pervasive problem for Internet users as most computers include software vulnerabilities that are subject to attack. For instance, over the past few years, more and more vulnerabilities are being discovered in software that is loaded onto a networked computer or other electronic device. While some vulnerabilities may be addressed through software patches (e.g., to close operating system “OS” vulnerabilities), electronic devices will continue to be targeted by exploits in efforts to acquire sensitive information or adversely affect operations of various enterprises.

In general, an exploit is executable code or other information that attempts to take advantage of a vulnerability by adversely influencing or attacking normal operations of a targeted electronic device. As an illustrative example, a Portable Execution Format (PDF) file may be infected with an exploit that is activated upon execution (opening) of the PDF file and takes advantage of a vulnerability associated with particular version or versions of Acrobat® Reader or another PDF reader application. This type of malicious attack may be designed to control operations of the targeted electronic device, which may include secretive transmission of stored sensitive information.

Currently, security devices may be implemented with a conventional exploit detection scheme that includes virtual machines (VMs) configured to process incoming objects in which the resultant behaviors are monitored during such processing. These “behaviors” may include expected behaviors by the VMs as well as unexpected (anomalous) behaviors such as communication-based anomalies or execution-based anomalies that may alter the functionality of a computer.

More specifically, for this conventional exploit detection scheme, the VMs are configured with general software profiles that are pre-selected in order to widely test different OS and application types commonly used by computers. For instance, general software profiles may be selected to virtualize a particular and widely adopted operating environment for testing purposes. While general software profiles are normally selected to test popular software configurations, these profiles normally differ, and in some cases substantially differ, from the actual operating states of computers currently deployed on a network. Hence, the conventional exploit detection scheme may produce false negatives as many exploits are not captured due to the generalization of the software profiles.

Additionally, once a computer becomes “infected” (e.g., an exploit now resides within internal storage of the computer), conventional remediation techniques are unable to be conducted within minutes of infection. Rather, such remediation may take hours or even days to occur and may be labor intensive.

It is well known that conventional remediation techniques within an enterprise are arduous and time consuming. For example, the infected computer would need to be physically delivered to the information technology (IT) department for analysis or the infected computer would be placed into an non-operational state until an IT member is available to run diagnostics. Hence, conventional remediation techniques are slow and may adversely affect productivity of the employee having the infected computer.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention are illustrated by way of example and not by way of limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which:

FIG. 1A is a block diagram of a first embodiment of an exemplary network adapted with a threat detection and prevention (TDP) system utilizing dynamic guest images for VM configuration.

FIG. 1B is a block diagram of a second embodiment of an exemplary network adapted with a TDP system utilizing dynamic guest images for VM configuration.

FIG. 2A is an exemplary embodiment of a logical representation of the memory blade being a component of the TDP system of FIG. 1A.

FIG. 2B is an exemplary embodiment of a logical representation of the processor blade being a component of the TDP system of FIG. 1A.

FIG. 3 is an exemplary embodiment of a first interactive display screen produced by the TDP system of FIG. 1A or 1B.

FIG. 4 is an exemplary embodiment of a second interactive display screen for operation selection produced by the TDP system of FIG. 1A or 1B.

FIG. 5 is an exemplary embodiment of a third interactive display screen produced by the TDP system of FIG. 1A or 1B.

FIG. 6 is an exemplary embodiment of a fourth interactive display screen for relating an uploaded master image to one or more groups within an enterprise.

FIG. 7 is an exemplary embodiment of a fifth interactive display screen that produces a listing of the groups maintained by the LDAP server.

FIG. 8 is an exemplary embodiment of a fifth interactive display screen produced by the TDP system of FIG. 1A or 1B.

FIG. 9 is an exemplary embodiment of a sixth interactive display screen produced by the TDP system of FIG. 1A or 1B that operates as a dashboard.

FIG. 10 is an exemplary embodiment of a seventh interactive display screen produced by the TDP system 110 of FIG. 1A or 1B in response to selection of the second tab of the dashboard.

FIG. 11 is an exemplary embodiment of an interactive display screen for remediation.

FIG. 12 is an exemplary flowchart of a remediation scheme for transitioning a client device from an infected state to an uninfected state.

DETAILED DESCRIPTION

Various embodiments of the disclosure relate to a threat detection and prevention (TDP) system, in the form of a security appliance or security cloud services (generally referred to as a “security system”), which analyzes objects associated with monitored network traffic using one or more virtual machines (VMs) each dynamically configured with a guest image representing the actual (and current) operating state of a targeted client (electronic) device. Through VM configuration using guest images, the TDP system is able to perform a concentrated dynamic analysis on network traffic from/to a particular client device as well as to conduct real-time remediation of the particular client device upon infection.

Herein, each “guest image” is an image of the content and structure of the storage volume for a specific client device at a particular point in time, namely a “snapshot” of the stored information including software along with metadata associated on the operating system (OS) and Open Systems Interconnect (OSI) Application layer data supporting the software (e.g., address location, size information, registry keys set by software, etc.). Hence, each guest image represents the current operating state of the client device at the time that the guest image is generated and is specific to only that client device. A timestamp may be applied to each guest image, where the time at least provides information as to the chronological order of its guest image to other guest images (e.g., time, monotonic count value, etc.).

Initially, one or more master images may be uploaded into the TDP system by an end user or administrator of the network. A “master image” represents a base amount of content (e.g., software and corresponding metadata) that is loaded into client devices for use by a member (user) of a particular group. The groups may be segregated according to any desired rubric. For instance, each group may correspond to one or more departments and/or sub-departments within an enterprise. Alternatively, each group may correspond to different regions, different languages, or in fact, may correspond to different enterprises where the TDP system supports an entire conglomerate.

More specifically, according to one embodiment of the disclosure, the master image may represent the initial “storage volume” of a client device supplied to a member of a particular group or groups within the enterprise, namely the initial content to be stored in persistent storage (e.g., hard disk, flash memory, etc.) of the client device. According to another embodiment of the disclosure, the master image may represent the requisite software, perhaps differing among the groups, which is loaded into the client device having connectivity to an enterprise network.

After uploading the master images to the TDP system and relating each master image to its assigned group or groups, each group member (or client device) may be related to at least one master image based on information within a Lightweight Directory Access Protocol (LDAP) server. Initial and subsequent access to the LDAP server may be accomplished by the TDP system through supplied LDAP credentials. Of course, after initial uploading of the master image(s), it is contemplated that each master image may undergo a one-way hash operation to produce a (master) hash value that may be used, at least initially, to confirm that the client device has been configured properly.

Besides relating one or more master images with each client device (or member of an enterprise), guest images may be generated and stored in response to changes in the storage volume of the client device. For instance, in response to a triggering event, the client device may initiate a native Volume Back-up program (e.g., Volume Shadow Copy for Windows® OS; Time Machine for iOS®, Google® Sync for Android® OS; iTunes® Sync for Mobile iOS®, etc.) to upload changes in the operating state of the client device to the TDP system. These changes in operating state may be uploaded through an “image update message,” such as an Application Programming Interface “API” call for example, which is prompted by a triggering event at the client device. One example of a “triggering event” includes a predetermined amount of change in storage volume at the client device (e.g., a change of persistent storage of 1 kilobyte “Kb”, 10 Kb, 100 Kb, etc.). Another triggering event may include installation and/or deletion of a software application at the client device. Yet another triggering event may include completion of a download of data (e.g., a Portable Document Format “PDF” file, text document, an image, or a video clip) attached to an electronic mail (email) message at the client device.

When triggered by a change in storage volume due to installation of new software, the image update message (e.g., API call) may comprise the newly installed software along with metadata changes on the OS and OSI Application Layer which support the newly installed software (e.g., address location, size changes, registry keys changes to support the software application, etc.). Where the image update message is triggered by removal of software, the metadata changes may include changes to denote removal of the software as well as changes to the OS and OSI Application Layer in response to removal of the software.

It is contemplated that one or more previous guest images along with information within the image update message may be used to create, in real time, a current guest image for the user's client device. For remediation, multiple guest images (e.g., up to ten guest images) may be retained for each client device. As a result, in response to detecting an object suspected of being exploit and the object being activated (e.g., opened, run, etc.) by the “infected” client device, the TDP system may generate an alert to identify that the client device has transitioned from a non-infected state to an infected state. After generating the alert, an administrator or someone with high-level credentials (e.g., super user) may restore the client device to a non-infected state in accordance with the remediation policy for the customer. For instance, the most recent guest image prior to infection may be restored on the client device. Furthermore, the administrator may view the operations of the suspect (or suspicious) exploit in detail and/or may be able to reload non-malicious information lost by restoration of the most recent guest image.

Besides dynamic guest image creation along with triggered or automatic remediation in response to the electronic device becoming infected, the TDP system is adapted to conduct VM-based processing using these guest images to enhance accuracy in exploit detection. Also, an interface (dashboard) is provided that allows an administrator to have a complete visualization from a system level perspective (e.g., number of master & guest images stored, number of remediated/infected electronic devices) and from a user perspective (e.g., number of infections on electronic device operated by a particular user, types of software infected, etc.).

I. Terminology

In the following description, certain terminology is used to describe features of the invention. For example, in certain situations, both terms “logic” and “engine” are representative of hardware, firmware and/or software that is configured to perform one or more functions. As hardware, logic (or engine) may include circuitry having data processing or storage functionality. Examples of such circuitry may include, but is not limited or restricted to a microprocessor; one or more processor cores; a programmable gate array; a microcontroller; an application specific integrated circuit; receiver, transmitter and/or transceiver circuitry; semiconductor memory; or combinatorial logic.

Logic (or engine) may be in the form of one or more software modules, such as executable code in the form of an executable application, an application programming interface (API), a subroutine, a function, a procedure, an applet, a servlet, a routine, source code, object code, a shared library/dynamic load library, or one or more instructions. These software modules may be stored in any type of a suitable non-transitory storage medium, or transitory storage medium (e.g., electrical, optical, acoustical or other form of propagated signals such as carrier waves, infrared signals, or digital signals). Examples of a “non-transitory storage medium” may include, but are not limited or restricted to a programmable circuit; a semiconductor memory; non-persistent storage such as volatile memory (e.g., any type of random access memory “RAM”); persistent storage such as non-volatile memory (e.g., read-only memory “ROM”, power-backed RAM, flash memory, phase-change memory, etc.), a solid-state drive, hard disk drive, an optical disc drive, or a portable memory device. As firmware, the executable code is stored in persistent storage.

The term “object” generally refers to a collection of data, such as a group of related packets, normally having a logical structure or organization that enables classification for purposes of analysis. For instance, an object may be a self-contained element, where different types of such objects may include an executable file, non-executable file (such as a document or a dynamically link library), a Portable Document Format (PDF) file, a JavaScript™ file, Zip™ file, a Flash file, a document (for example, a Microsoft Office® document), an email, downloaded web page, an instant messaging element in accordance with Session Initiation Protocol (SIP) or another messaging protocol, or the like.

The term “flow” generally refers to a collection of related objects, communicated during a single communication session (e.g., Transport Control Protocol “TCP” session), perhaps between a source device and a destination device. A client device may be one of the source or destination devices.

A “message” generally refers to information transmitted as information in a prescribed format, where each message may be in the form of one or more packets or frames, an HTTP-based transmission, or any other series of bits having the prescribed format.

The term “transmission medium” is a physical or logical communication path with a client device, which is an electronic device with data processing and/or network connectivity such as, for example, a stationary or portable computer including a desktop computer, laptop, electronic reader, netbook or tablet; a smart phone; or wearable technology. For instance, the communication path may include wired and/or wireless segments. Examples of wired and/or wireless segments include electrical wiring, optical fiber, cable, bus trace, or a wireless channel using infrared, radio frequency (RF), or any other wired/wireless signaling mechanism.

In certain instances, the term “verified” are used herein to represent that there is a prescribed level of confidence (or probability) on the presence of an exploit within an object under analysis. Also, an “exploit” may be construed as information (e.g., executable code, data, command(s), etc.) that attempts to take advantage of a software vulnerability, namely a coding error or artifact of software (e.g., computer program) that allows an attacker to alter legitimate control flow during processing of the software (computer program) by an electronic device, and thus, causes the electronic device to experience undesirable or unexpected behaviors.

The term “computerized” generally represents that any corresponding operations are conducted by hardware in combination with software and/or firmware.

Lastly, the terms “or” and “and/or” as used herein are to be interpreted as inclusive or meaning any one or any combination. Therefore, “A, B or C” or “A, B and/or C” mean “any of the following: A; B; C; A and B; A and C; B and C; A, B and C.” An exception to this definition will occur only when a combination of elements, functions, steps or acts are in some way inherently mutually exclusive.

As this invention is susceptible to embodiments of many different forms, it is intended that the present disclosure is to be considered as an example of the principles of the invention and not intended to limit the invention to the specific embodiments shown and described.

II. General Architectures

Referring to FIG. 1A, a block diagram of a first embodiment of a client-based exploit detection scheme controlled by a threat detection and prevention (TDP) system utilizing dynamic guest images for VM configuration is shown. Herein, network 100 comprises a TDP system 110 that is configured to monitor network traffic propagating over a communication medium 120 being part of the network 100. The TDP system 110 is communicatively coupled to a Lightweight Directory Access Protocol (LDAP) server 130 and one or more client devices 140₁-140_J (J≥1).

As shown in FIG. 1A, TDP system 110 comprises one or more processor blades 150₁-150_N (N≥1) which may be organized in a vertical, centralized (rack) deployment as shown. The processor blades 150₁-150_N feature logic that is responsible for performing static and/or dynamic exploit analysis on objects extracted from network traffic propagating over the communication medium 120. For instance, as an illustrative embodiment, each processor blade 150_i (1≤i≤N) may operate as a stand-alone processing unit that is individually responsible for performing static and/or dynamic exploit analysis on objects extracted from network traffic associated with a particular set of client devices (e.g., client devices for a particular department, particular region, etc.). Alternatively, two or more (and perhaps all) processor blades 150₁-150_N may operate in a collective manner. For instance, a first processor blade 150₁ may operate as a master processing unit while processor blade 150₂ may operate as a slave processing unit or these processor blades 150₁-150_N may operate collectively in accordance with a selected load sharing scheme.

Additionally, the TDP system 110 includes one or more memory blades 160₁-160_M (M≥1). The memory blades 160₁-160_M comprise logic that is individually or collectively responsible for controlling TDP system configuration, which may include (1) uploading and/or storing master images, (2) generating and/or storing guest images for each client device 140₁, . . . , or 140_J, and/or (3) generating a dashboard or other display screens for configuration and control of the TDP system. For instance, each memory blade 160_i (1≤i≤M) may operate as a stand-alone storage unit that is individually responsible for maintaining master and guest images for particular group(s) of an enterprise (or different enterprises). Alternatively, two or more (and perhaps all) memory blades 160₁-160_M may operate in a collective manner. For instance, a first memory blade 160₁ may operate to store master images while the other memory blades 160₂-160_M may operate to store guest images for different groups within the enterprise (or different guest images for different enterprises). Of course, the particular configurations for memory blades 160₁-160_M as well as processor blades 150₁-150_N may be adjusted according to customer needs.

At initial set-up, the LDAP credentials for accessing a customer's LDAP server may be obtained by (and optionally stored in) at least one of the memory blades 160₁-160_M. The accessed LDAP credentials enable the memory blades 160₁-160_M to subsequently and automatically access content within the LDAP server 130 in order to identify group membership associated with each client device (user). The group membership signifies the particular master image assigned to the group member for configuration of his/her client device, where the master image provides an initial operating state (e.g., base software configuration). Thereafter, in response to storage volume changes made on the client device, one or more memory blades 160₁-160_M generate guest images for use in VM configuration. The guest images may be stored locally within the memory blades 160₁-160_M or externally, and the number of guest images stored per client device may be limited to a certain prescribed number set by an administrator.

More specifically, in response to a first storage volume change greater than a predetermined amount, the client device 140₁ outputs an image update message 142 to the TDP system 110. The image update message 142 causes the TDP system 110 to generate a first guest image. The first guest image is based on a particular master image assigned to the group member having control of client device 140₁ along with additional data that caused the storage volume change to occur. Similarly, a second guest image is based on the first guest image along with information contained within a subsequent image update message 144 produced by client devices 140₁, where the information includes the additional data from the first storage volume change to the second storage volume change. This reiterative process continues until “X” guest images are stored for a particular user (e.g., X≥10 guest images). Once the image buffer is written with “X” guest images, any subsequent guest images may overwrite the older guest images in accordance with a first-in, first out (FIFO) storage scheme.

As an illustrative example, one or more master images may be uploaded by an administrator of the network 100 into the TDP system 110. These master images may be fetched from persistent storage accessible to the administrator (e.g., administrator's computer, dedicated server, disc, flash drive, etc.). For illustrative purposes, the master images correspond to base software configurations on a department and/or sub-department basis, where a master image for members of a first department (or sub-department) may differ from the master image for members of a second department (or sub-department). For security reasons, a master image may undergo static and dynamic analysis by one of the processor blades 150₁-150_N before that master image is uploaded to any of the memory blades 160₁-160_M.

After uploading of the master images to one or more of the memory blades 160₁-160_M and relating the master images to the particular groups, the particular users (and their corresponding client devices) may be related to the groups through information stored within the LDAP server 130. More specifically, logic within the memory blades 160₁-160_M may be adapted to create one or more tables that provide correspondence between (1) client devices (identified by an identifier such as assigned computer name, MAC address, etc.); (2) assigned user for each client device; (3) group (e.g., department or sub-departments, etc.) to which the user belong; (4) addressing information associated with the master image corresponding to the group; and/or (5) addressing information for guest images associated with each particular user.

It is contemplated that multiple guest images may be generated and stored for each client device in response to changes in the storage volume of that client device. For example, in response to a predetermined amount of change in storage volume, the client device initiates a native Sync program (e.g., Volume Shadow Copy for Windows® OS; Time Machine for iOS®, Google® Sync for Android® OS; iTunes® Sync for Mobile iOS®, etc.) to commence transmission of an image upload message (e.g., messages 142, 144, etc.) that includes changes in the operating state of the client device (e.g., newly installed software application, metadata changes on the OS and OSI Application Layer that support the installed application, etc.). These operating state changes along with the image of a prior operating state (e.g., master image, preceding guest image, etc.) are used to generate a current guest image for the client device.

Prior to conducting VM-based exploit analysis on one or more objects extracted from network traffic from/to a particular client device 140₁, . . . , or 140_J (e.g., client device 140₁), one or more processor blades 150₁-150_N (e.g., processor blade 150₁) are configured to access at least a current guest image for client device 140₁ from memory blade 160₁-160_M (e.g., memory blade 160_M), where the current guest image is used for configuring one or more virtual machines operating within processor blade 150₁. Of course, it is contemplated that other guest images, such as older guest or images for client devices other than client device 140₁ (e.g., client devices associated with users belonging to the same department), may be tested to confirm that any detected exploits are isolated to newly added content or content exclusively contained within that particular client device.

Referring now to FIG. 1B, a block diagram of a second embodiment of a client-based exploit detection scheme controlled by the TDP system utilizing dynamic guest images for VM configuration is shown. Herein, deployed as part of a private network or part of a publicly accessible network, TDP system 110 operates as security cloud services configured to monitor network traffic propagating over the communication medium 120 that partially forms the network 100. Similar to the connectivity described in FIG. 1A, the TDP system 110 is communicatively coupled to LDAP server 130 and one or more client devices 140₁-140_J.

As shown in FIG. 1B, the security cloud services forming TDP system 110 comprises one or more databases to maintain master images of an enterprise as well as multiple guest images for each client device 140₁-140_J and control logic to maintain these databases. At initial set-up, being part of the security cloud services, the LDAP server communication logic 175 may be configured to obtain LDAP credentials in order to gain access a customer's LDAP server 130. The information accessed from the LDAP server 130 may be used to map (i) identifiers of the client devices 140₁-140_J to particular users assigned to these client devices, and (ii) the particular users to corresponding groups (e.g., departments or sub-departments). From this information and prior identification as to which groups corresponding to which master images, control logic 185 within the security cloud services is able to determine which master image is the base image for which user. The master images may be stored in master image database 190.

Thereafter, in response to volume changes made on the client device 140₁, control logic 185 generates guest images based originally from the master image associated with that client device 140₁. For instance, a first guest image for client device 140₁ may be based on (i) a particular master image assigned to the user of client device 140₁ and (ii) the differential information associated with the storage volume change. As an example, the differential information may include a newly installed software application and metadata (OS and OSI Application layer) to support the software application. The guest images are stored in guest image database 195.

The generation of second and subsequent guest images may be performed in a reiterative manner until “X” guest images are stored for each particular user. Once the “X” guest images are stored, any subsequent guest images may overwrite the oldest guest image in accordance with a first-in, first out (FIFO) storage scheme for example.

Referring to both FIGS. 1A-1B, it is contemplated that a hash value may be generated and stored for each master image for subsequent confirmation that the base software configuration for a particular client device (controlled a particular user) is accurately assigned. This may be accomplished by conducting a hash operation on the initial configuration and comparing the resultant hash value to the hash value for the master image assigned to the client device. Additional hash values may be generated for each change in storage volume where a series of hash values may be used to confirm upload accuracy.

Referring to FIG. 2A, an exemplary embodiment of a logical representation of the memory blade 160₁ of FIG. 1A is shown. Herein, the memory blade 160₁ comprises a communication interface 200, a memory controller 210, a first data store 220 and a second data store 235. The communication interface 200 provides connectivity with resources within network 100, including LDAP server 130 and one or more client devices 140₁-140_J illustrated in FIG. 1A. Furthermore, the communication interface 200 provides connectivity with one or more processor blades 150₁-150_N and/or one or more of the remaining memory blades 160₂-160_M of FIG. 1A. Hence, the blade server implementation for the TDP system 110 provides scalability through increased software image storage capacity through increased memory blades and/or increased processing capability through increased processor blades.

Memory controller 210 is configured to control the initial configuration of the memory blade based on initial upload of one or more master images 225, relate the master image(s) to client devices adapted to access the network, and generate guest images 230 for changes in operating state at the client devices.

More specifically, in response to a login request by an administrator, the memory controller 210 executes system control logic 240 that produces one or more interactive display screens to enable the administrator to upload and relate master images 227₁-227_K to particular groups as well as download a dashboard to view system status and control remediation, as described below.

Where the administrator selects to upload one or more master images, the memory controller 210 controls storage of master images 227₁-227_K within the first data store 220. The memory controller 210 may further store addressing information of each master image 227₁-227_K within internal memory (not shown) or within one of the data stores 220 and 235.

After completing an upload of the master image(s), the memory controller 210 may control relating the master image(s) to one or more (“J”) client devices based on information acquired from the LDAP server. In particular, the memory controller 210, under control by the system control logic 240, generates one or more interactive display screens into which LDAP credentials 242 for accessing a customer's LDAP server may be conveyed. The LDAP credentials 242 may be optionally cached (as shown) to enable the TDP system to automatically access the LDAP server in response to subsequent master image uploads or to periodically check if any users have moved departments (where the software configuration should be changed) or have left the enterprise (where guest images can be deleted or downloaded to external storage for retention). Contents within the LDAP server enable the master image to be related to particular client devices that should be loaded with the software configuration represented by the master image.

As further shown in FIG. 2A, the first data store 220 of memory blade 160₁ may be configured to store guest images for each of the client devices 140₁-140_J. For instance, as an illustrative example, a maximum of ten guest images 232₁-232₁₀ are stored for a first client device 140₁, ten guest images 233₁-233₁₀ are stored for a second client device 140₂, and three guest images 234₁-234₃ are currently stored for an L^th client device 140_L.

In response to receiving a native Sync program signal and subsequent image update message, under control by the image update control logic 244, the memory controller 210 may locate the most recent guest image associated with the client device that initiated the image update message through timestamp review and extract update information associated with the storage volume changes from the update image message. The most recent guest image and the extracted update information are provided to the guest image generation logic 246. Processed by the memory controller 210, the guest image generation logic 246 creates a current guest image representing the current operating state of the client device based on the most recent guest image and the update information. The current guest image along with its timestamp may be stored in an address range reserved for guest images for the particular client device.

Referring now to FIG. 2B, an exemplary embodiment of a logical representation of the processor blade 150₁ is shown. Herein, the processor blade 150₁ comprises a communication interface 250, a static analysis engine 255, a schedule 260, a dynamic analysis engine 270, a classification engine 285 and reporting logic 290. The communication interface 250 provides connectivity with resources within network 100 of FIG. 1A, including one or more client devices to which alerts may be generated. Furthermore, communication interface 250 provides connectivity with (i) one or more memory blades 160₁-160_M from which guest images for configuring one of more virtual machines within the dynamic analysis engine 270 may be obtained and/or (ii) one or more of the remaining processor blades 150₂-150_N.

Herein, according to this embodiment of the disclosure, processor blade 150₁ is an electronic device deployed within the TDP system 110 (see FIG. 1A) that is adapted to (i) intercept network traffic that is routed over a communication network to/from a particular client device (not shown) and (ii) monitor, in real-time, content within the network traffic. Although not shown, the processor blade 150₁ is communicatively coupled to a management system that may be configured to automatically update one or more exploit signatures and/or vulnerability signatures used by logic within static analysis engine 255. Stored in signature database 256, each of these signatures may represent a prior detected exploit or an uncovered software vulnerability. Such sharing may be conducted automatically or through manual uploads. Also, such sharing may be conducted freely by the TDP system 110 with other TDP systems or subject to a subscription basis.

Herein, according to the embodiment illustrated in FIG. 2B, the static analysis engine 255 may include one or more software modules that, when executed by one or more processors, performs static scanning on a particular object. Examples of different types of static scanning may include exploit signature checks and/or vulnerability signature checks. Signature check operations may involve accessing pre-stored signatures from one or more non-transitory storage mediums such as signature database 256.

In general, referring to FIG. 2B, the static analysis engine 255 is communicatively coupled to receive one or more objects from network traffic which may be related or unrelated to each other. For instance, one object may be a series of HTTP packets operating as a flow routed over the network. The static analysis engine 255 comprises exploit matching logic 257 that performs exploit signature checks, which may involve a comparison of one or more pre-stored exploit signatures (pre-configured and predetermined attack patterns against the suspect object) from signature database 256. Similarly, the signature matching logic 258 performs vulnerability signature checks, which may involve a process of uncovering deviations in messaging practices set forth in applicable communication protocols (e.g., HTTP, TCP, etc.). As an illustrative example, HTTP messages may be analyzed to determine compliance with certain message formats established for the protocol (e.g., out-of-order commands). Furthermore, payload parameters of the HTTP messages may be analyzed to determine further compliance.

Upon detecting a match during the exploit signature check and/or the vulnerability signature check (an object under analysis has characteristics that suggest the object is an exploit), the static analysis engine 255 determines that the object is “suspicious,” namely has characteristics that suggest the object is an exploit, and routes the suspect object to the dynamic analysis engine 270 for more in-depth analysis. In one embodiments, the static analysis may alternatively or additionally include applying heuristics to identify suspicious characteristics of the object such as communication protocol anomalies for example in a flow.

The dynamic analysis engine 270 is configured to provide more in-depth analysis of suspect object(s) from the static analysis engine 255 by analyzing behaviors during processing of the suspect object(s) in order to verify whether or not the suspect object is an exploit.

More specifically, after static scanning has been completed, the static analysis logic 255 provides the suspect object to the dynamic analysis engine 270 for in-depth dynamic analysis using virtual machines (VMs) 276₁-276_R (R≥1). For instance, the dynamic analysis engine 270 may simulate transmission to and receipt by a destination device comprising the virtual machine. Of course, if the object is not suspected of being an exploit, the static analysis engine 255 may simply discard the results or store them with an external data source.

According to one embodiment, one or more VMs 276₁-276_R within the virtual execution environment 275 may be configured based on metadata extracted from the network traffic (e.g., address information to identify the client device operating as the source or destination of the network traffic). In particular, one or more guest images for the identified client device are selected by VM provisioning logic 265 within the scheduler 260 and provided to the VM execution environment 275, where VM 276₁ may be configured with the most recent guest image of the client device. This provisioning of guest images for the identified client device provides a more accurate VM configuration for analyzing the suspect object than conventional means.

According to one embodiment of the disclosure, the dynamic analysis engine 270 is adapted to execute one or more VMs 276₁-276_R to simulate the receipt and execution of content associated with the suspect object within a run-time environment as expected for the suspect object. For instance, the dynamic analysis engine 270 may include processing logic 272 that “replays” the network communication in a virtual machine (e.g., VM 276₁) in accordance with (e.g., in a sequence prescribed by) the applicable communication protocol by sending its data packets to VM 276₁, and synchronizes any return network traffic generated from the VM 276₁ in response to the network communication. The processing logic 272 may suppress (e.g., discard) the return network traffic such that it is not transmitted to any host or other real (“live”) device but is nonetheless intercepted for analysis. The processing logic 272 may change destination IP addresses of data packets in the network communication to one or more IP addresses assigned to the VM 276₁ or may alter a time scale to assist in detonation of time bomb exploits.

Herein, the static analysis engine 255 and the dynamic analysis engine 270 may be one or more software modules executed by the same processor or different processors, where these different processors may be located within the same processor package (e.g., different processor cores) and/or located at remote or even geographically remote locations that are communicatively coupled (e.g., by a dedicated communication link) or a network.

As further shown in FIG. 2B, the monitoring logic 278 within the dynamic analysis engine 270 may be configured to monitor behavior of the suspect object being analyzed by one or more VMs 276₁, . . . , and/or 276_R, for detecting anomalous or unexpected activity indicative of an exploit. If so, the suspect object may be determined as being associated with malicious activity, and thereafter, monitoring logic 278, perhaps operating with a score determination logic (not shown), may route the VM-based results 280 (e.g., computed score, information associated with the detected anomalous behaviors, and other information associated with the detected malicious activity by the suspect object) to classification engine 285.

According to one embodiment of the disclosure, the classification engine 285 comprises prioritization logic 287 and score determination logic 289. The prioritization logic 287 may be configured to apply weighting to the VM-based results 280 provided from dynamic analysis engine 270 and/or results from the static analysis engine 255 (represented by a dashed input). These results may include a score produced by score determination logic implemented within dynamic analysis engine 270 and/or static analysis engine 255, where the “score” is a value that classifies the threat level of the detected potential exploit.

Herein, the score determination logic 289 comprises one or more software modules that are used to determine a probability (or level of confidence) that the suspect object is an exploit. Based on the VM-based result 280 and/or results from the static analysis engine 255, score determination logic 289 may be configured to generate a value (referred to as an “overall score”) that classifies the object or a series of objects as an exploit. It is contemplated that the score may be assigned to the suspect object as a whole by mathematically combining scores determined by analysis of different content associated with the same suspect object to obtain an overall score for that suspect object.

If the score determination logic 289 generates an overall score that represents the suspect object has been verified to be an exploit, information may be provided to alert/report generation logic 295 within the reporting logic 290 to notify a network administrator of the exploit detected and such information may be stored within one of the memory blades 160₁-160_M for extraction and display within a dashboard as described below.

III. Exemplary Dynamic Guest Image Creation

Referring to FIG. 3, an exemplary embodiment of a first interactive (Login) display screen 300 produced by TDP system 110 of FIG. 1A or 1B is shown. Herein, in order to gain access to the TDP system 110 for loading of one or more master images that are used in the generation of guest images for VM configuration, an administrator initially establishes a network connection with the TDP system. This network connection may be established in accordance Hypertext Transfer Protocol (HTTP) Request or HTTP Secure (HTTPS) communication protocols.

As shown, an initial request for access to the TDP system is redirected to provide a Login display screen 300 that features at least two entry fields; namely a User Name 310 and a Password 320. The User Name entry field 310 requires the user to enter a registered user name in order to identify the user seeking access to the TDP system. Password entry field 320 allows the user to enter his or her password.

Once a login button 330 is selected, the user name and password are provided to logic within the TDP system, such as the system control logic 240 of FIG. 2A. Once the user seeking access to the TDP system has been authenticated, access privileges for that user are set and the user is provided with a second interactive display screen 400 as shown in FIG. 4.

Referring now to FIG. 4, an exemplary embodiment of the second interactive display screen 400 for operation selection is shown. Herein, interactive display screen 400 comprises a plurality of select area 410 and 420 that, when selected, signal the TDP system as to which operations are requested. As shown, the select areas 410 and 420 comprise (1) a link 410 to commence uploads of one or more master images and (2) a link 420 to download a dashboard (area 420).

For instance, upon first area 410 being selected, the TDP system produces a third interactive display screen, namely master image upload display 500 as shown in FIG. 5. Master image upload display 500 includes a “Browse” button 510 that, when selected, causes a pull-down listing 520 to be displayed. The pull-down listing 520 comprises a plurality of storage locations 525 from which a particular master image 530 may be retrieved for uploading to the TDP system. These storage locations 525 may include local storage at the network administrator's computer (e.g., hard disk drive, optical drive, etc.), external storage at a remote file share, or the like. Hence, upon selection of the particular master image that is sequentially displayed in search area 540 and activation of the “Upload” button 550, the particular master image is uploaded to one of the memory blades 160₁-160_M (FIG. 1A) or master guest database 190 (FIG. 1B).

In lieu of uploading single master images to the TDP system, master image upload display 500 provides a capability of batch uploads. According to one embodiment of the disclosure, a folder 560 from the pull-down listing 520 may be selected where, upon being displayed in search area 540 and activation of the “Upload” button 550 occurs, all master images within the selected folder are uploaded. Alternatively, the master images may be uploaded using a command string. For instance, a File Transfer Protocol (FTP) command string (e.g., “sftp -b batchfile . . . ”, where batchfile has a list of “Put” commands for master images along with their storage locations) is entered into search area 540 and upon activation of the “Upload” button 550, all master images identified in the list (batchfile) are subsequently uploaded by the TDP system.

Referring now to FIG. 6, an exemplary embodiment of a fourth interactive display screen 600 produced by the TDP system 110 of FIG. 1A or 1B for relating an uploaded master image to one or more groups within an enterprise is shown. Herein, display screen 600 comprises a plurality of entry fields area 610 and 620 in order to relate content within the LDAP server for the enterprise network with the uploaded master images. A first entry field 610 requires entry of a LDAP credential such as a user name for accessing the LDAP server. A second entry field 620 requires entry of a password to gain access to content within the LDAP server, which is a database including groups and members (or client devices) being part of the corresponding group.

Once a login button 630 is selected and the entered LDAP credential has been authenticated, a fifth interactive display screen 700 is provided that produces a listing of the groups maintained by the LDAP server, as shown in FIG. 7. Herein, a listing 710 of the groups comprises different departments and sub-departments of an enterprise. For instance, the departments may include Marketing 721, IT 722, Product Management 723, Engineering 724, Legal 725, Customer Support 726 and Sales 727. The sub-departments for the Engineering department 724, such as Sustenance 730, Back-End 731 and Front-End 732, may be selected to provide greater group granularity so that client devices controlled by members in different sections within the department may be configured differently.

As an illustrative example, members of the Engineering department 724 within an enterprise may be associated with a different master image (e.g., different software and/or versions of software) than member of the Marketing department 721. Similarly, members within the Back-End section 731 of the Engineering department 724 may be associated with a different master image (e.g., different software and/or versions of software) than member of the Front-End section 732 of the Engineering department 724.

One or more of these departments and/or sub-departments may be selected, and upon selection of the “Select & Finish” button 740, the TDP system relates the particular master image to the selected department(s) and/or sub-department(s). As an illustrative embodiment, the Marketing department 721 has been selected for relating a master image thereto.

Referring now to FIG. 8, an exemplary embodiment of a fifth interactive display screen 800 produced by the TDP system 110 of FIG. 1A or 1B is shown. In response to successfully relating (linking) the master image (enterprise-mktgdept-win7.iso) to the LDAP's Marketing department as illustrated in FIGS. 5-7, a message 810 indicating the successful relation of the master image to a particular LDAP group is generated along with an image 815 identifying the successful relation. Thereafter, for every prescribed change in storage volume at every registered client device associated with a user of the Marketing department, the TDP system produces a new guest image associated with that client device.

According to one embodiment of the disclosure, where guest images are generated in accordance with a “push” update scheme, the client device is loaded with a native Sync program that periodically, aperiodically, or continuously monitors for changes in storage volume at the client device. In response to a difference in volume exceeding a prescribed amount, the client device issues an image update message with information associated with the differences in operating state based on the storage volume changes. According to another embodiment of the disclosure, where guest images are generated in accordance with a “pull” update scheme, the TDP system may be configured to periodically or aperiodically poll the client devices to inquire whether such devices have experienced a storage volume change that exceeds the prescribed amount since the last polling event. If so, the client device issues an image update message with information associated with the differences in operating state based on the storage volume changes. These differences are used to create a current guest image associated with the client device that is used for exploit detection as described above.

Referring back to FIG. 8, the fifth interactive display screen 800 comprises a first display element 820 that, when selected, returns to the third interactive screen display 500 to continue uploading of additional master images. Screen display 800 further comprises display elements that, when selected, cause the TDP system to (i) display all uploaded master images (display element 830), (ii) view the dashboard (display element 840; FIG. 9) or (iii) disconnect communications with the TDP system (display element 850).

IV. Exemplary Dashboard Graphic User Interface

Referring to FIG. 9, an exemplary embodiment of a sixth interactive display screen 900 produced by the TDP system 110 of FIG. 1A or 1B that operates as a dashboard is shown. Herein, dashboard 900 comprises a plurality of tabs 910, 940 and 980 that are used to provide a TDP system overview, client device overview and guest image update history associated with each client device.

As shown, as a default or upon selecting of a first tab 910, the TDP system overview is provided. The TDP system overview comprises a plurality of display elements 915, 920, 925, 930 and 935 directed to image storage and client device infections. For instance, first display element 915 displays the total number of master images submitted and relied upon by the TDP system. This information enables a network administrator to visually confirm the current grouping scheme for the enterprise. The second display element 920 displays the total number of dynamic guest images for the client devices operating within the enterprise network. This information enables a network administrator to visually identify processor and/or storage constraints (e.g., encourage purchase of additional processor and/or memory blades) or reduce the number of guest images retained for each client device, as needed.

The third display element 925 identifies the number of unique OSes associated with the stored guest images. This information is useful to identify the breadth of client devices supported by the network and also the breadth of VM-analysis for exploits.

The fourth display element 930 identifies the number of infected client devices that have been remediated while the fifth display element 935 identifies the number of infected client devices that are awaiting remediation. These display elements enable the network administrator to monitor the number of client devices that have needed remediation and identify any infected client devices where remediation has not yet been accomplished so that network administrators can investigate the reasons for the delay. For instance, the user may have left for the evening prior to detection of an exploit and the infected client device still awaits permission to commence remediation. After prolonged lack of remediation, however, the network administrator may be able to conduct remediation without member (user) approval.

Referring now to FIG. 10, an exemplary embodiment of a seventh interactive display screen 1000 produced by the TDP system 110 of FIG. 1A or 1B in response to selection of the second tab 940 of the dashboard 900 is shown. Herein, display screen 1000 is configured to provide an overview of the current operating state of the client devices along with selectable views of the operating state over a prescribed duration and selectable remediation.

Herein, display screen 1000 comprises a listing 1010 of client devices associated with the enterprise network, where the client devices represented in the listing 1010 may be displayed based on assigned groups, alphabetically by device name, greatest number of alerts, and/or OS type. In particular, listing 1010 includes a client name category 1020, alert category 1030, OS type 1040, and actions 1050.

The client name category 1020 lists each client device by identifier (e.g., assigned name for the client device). As shown, three client devices 1022, 1024 and 1026 are illustrated to show how client devices may be listed.

The alert category 1030 identifies the number of alerts (finding of potential exploits) within network traffic involving each client device along with a color coding to identify whether all of the alerts have been remediated. For instance, as shown, client device-1 alert 1032 identifies three (3) alerts in which exploits were verified by the dynamic analysis engine and remediation occurred based on the particular color of the alert identifier. Also, client device-2 alert 1034 identifies twenty-two (22) alerts of which all involved exploits verified by the dynamic analysis engine that have been remediated. Client device-3 alert 1036 identifies one (1) alert which has not yet been remediated based on the different color coding than alerts 1032 and 1034.

The OS type category 1040 identifies the current OS type (and version) implemented within the corresponding client device. As shown, each of these client devices 1022-1026 have a different OS, namely Windows® 8, Android® Jelly Bean™ and iOS7, respectively.

Finally, the actions 1050 provide links that, when selected, enable the administrator to manually perform a number of operations. For instance, the administrator may select the remediation link 1052 that, after selection, causes images 1100, 1110 and 1120 representative of the stored guest images for the client device to be displayed as shown in FIG. 11. For instance, image 1100 identifies the content and structure of the storage volume for the client device in an infected state at time “t” while images 1110 and 1120 identify the content and structure of the storage volume of the client device in an earlier non-infected state at time “t-1” and “t-2”, respectively. Remediation may be conducted for the corresponding client device by selecting most recent guest image 1110 (time t-1) in a non-infected state. Of course, in lieu of conducting remediation with the most recent guest image 1110, there may be an ability to select previous guest images (e.g., guest image 1120) for remediation.

Furthermore, the administrator may select the timeline link 1054 that provides a chronological illustration of guest image updates and detected infections.

V. Remediation Scheme

Referring to FIG. 12, an exemplary flowchart of a remediation scheme for transitioning a client device from an infected state to an uninfected state is shown below. Initially, remediation may be conducted in response to detection a triggering event (block 1200). The triggering event may be periodic or aperiodic in nature. For instance, as an illustrative example, the remediation scheme may be invoked in response to detection by the TDP system of an exploit within an object of network traffic from/to a client device. Where the exploit was identified after receipt of the object by the client device and activation of the exploit, the client device has transitioned from a non-infected state to an infected state.

Upon detecting a triggering event, the TDP system may initiate an alert to the client device (block 1210). According to one embodiment, the receipt of an alert may cause the client device to request restoration of a guest image stored prior to infection of the client device and commence restoration (blocks 1220 and 1230). For instance, the alert may prompt the user to manually request remediation and commence remediation by restoring the most recent “non-infected” guest image on the client device. As an alternative, the alert may cause automatic remediation by automatically restoring the most recent “non-infected” guest image on the client device.

If remediation is successful, metadata used in the dashboard display screen and other display screens is uploaded (blocks 1240 and 1250). If remediation is unsuccessful, a retry may be conducted or a different guest image may be selected after successive failed retries.

Additionally, the alert may prompt an administrator with higher level credentials (e.g., super-user rights) to view the operations of the exploit, replay and push back non-malicious information lost by the reinstallation of the most recent “non-infected” guest image.

Furthermore, it is contemplated that statistics concerning detected malicious attacks (e.g., particular application types/versions; OS types/versions) may be used to harden the TDP system. Such hardening of the TDP system may include, but is not limited or restricted to (i) producing enterprise rules to decrease vulnerabilities (e.g., no client device may be uploaded with certain software, etc.); (ii) sharing with third parties to increase awareness of potential attacks, especially zero-day; and (iii) determine types of applications that are more vulnerable than others, which may allow an administrator to enable, disable or otherwise update specific applications within the guest image as new software is deployed and existing software is updated.

In the foregoing description, the invention is described with reference to specific exemplary embodiments thereof. For instance, it is contemplated that, in lieu of the interactive display screens described above, features of these interactive display screens may be provided through different types of display screen or even multiple display screens. The display screens are provided for illustrative purposes. It will, however, be evident that various modifications and changes may be made to the illustrative embodiments without departing from the broader spirit and scope of the invention as set forth in the appended claims.