HK1254985B - Dual memory introspection for securing multiple network endpoints - Google Patents

Description

Dual memory introspection for protecting multiple network endpoints

Related applications

This application claims the benefit of the filing date of U.S. Provisional Patent Application No. 62/269,952, filed December 19, 2015, entitled “Dual Memory Introspection for Securing Multiple Network Endpoints,” which is incorporated herein by reference in its entirety.

Background Art

The present invention relates to computer security systems and methods, and in particular, the present invention relates to systems and methods for protecting hardware virtualization environments from computer security threats.

Malicious software, also known as malware, affects numerous computer systems worldwide. Malware, in its many forms (such as computer viruses, worms, Trojans, and spyware), poses a serious threat to millions of computer users, exposing them to the loss of data and sensitive information, identity theft, and lost productivity.

Computer security software can be used to protect computer systems from malware. However, in distributed computing systems (such as enterprise networks and cloud computing systems), conventional security software often fails to respond effectively to attacks. Even when security software is able to detect an attack, analysis and remediation may still require dispatching human operators to the affected client systems, for example, to apply patches, recover lost data, and so on. Furthermore, once new threats are detected and analyzed, updated versions of security software must be promptly distributed to all protected computer systems.

Alternative computer security systems can be executed on a central server computer, which receives relevant data from security clients via a communications network. Based on the received data, the server can determine whether the respective client is infected with malware and transmit the determination to the respective client. While this configuration is well-equipped to handle emerging threats, it requires significant server-side computing power.

Computer security operations have been further complicated by the advent of hardware virtualization. As more goods and services are traded online, and as work becomes increasingly decentralized, Infrastructure as a Service (IaaS) has become a viable alternative to owning computer hardware. A significant portion of computing activity is now performed using virtual machines. In typical applications, such as server farms and cloud computing, hundreds of virtual machines can execute simultaneously on a single hardware platform. All of these virtual machines may require malware protection.

Adapting to the ever-changing nature of malware and the challenges of a mobile workforce requires the development of novel computer security systems and protocols, and in particular, the development of systems and methods that enable efficient management of computer security operations across multiple distributed clients.

Summary of the Invention

According to one aspect, a client computer system includes a hardware processor configured to execute a hypervisor, an in-situ introspection engine, and an on-demand introspection engine. The hypervisor is configured to expose a client virtual machine (VM) and a secure VM distinct from the client VM, wherein the on-demand introspection engine executes within the secure VM, and wherein the in-situ introspection engine executes externally from the client VM and the secure VM. The in-situ introspection engine is configured to, in response to detecting an occurrence of an event within the client VM, transmit an indicator of the event to a remote server computer system via a communication network. The on-demand introspection engine is configured to, in response to the in-situ introspection engine transmitting the indicator of the event to the remote server computer system, receive an analysis request from the remote server computer system, the analysis request indicating a security tool residing in a remote tool repository, the remote tool repository configured to distribute security tools to a plurality of clients including the client computer system, the security tool including software configured to analyze the occurrence of the event, the security tool being selected by the remote server computer system based on an event type of the event. The on-demand introspection engine is further configured to: in response to receiving the analysis request, identify the security tool according to the analysis request, and in response, selectively retrieve the security tool from the tool repository, wherein retrieving the security tool includes connecting to a central tool repository via the communication network. The on-demand introspection engine is further configured to: in response to selectively retrieving the security tool, execute the security tool, and transmit a result of executing the security tool to the remote server computer system.

According to another aspect, a server computer is configured to perform computer security transactions with multiple client systems. The server computer system includes a hardware processor configured to: in response to receiving an event indicator from a client system of the multiple client systems, the event indicator indicating the occurrence of an event within a guest virtual machine (VM) executing on the client system, select a security tool residing in a remote tool repository configured to distribute security tools to the multiple client systems, the security tool including software configured to analyze the occurrence of the event, wherein the selection of the security tool is performed based on an event type of the event. The hardware processor is further configured to: in response to selecting the security tool, transmit an analysis request to the client system via a communication network, the analysis request including an identifier of the security tool; and in response, receive from the client system a result of executing the security tool on the client system. The client system is configured to execute a hypervisor, an in-place introspection engine, and an on-demand introspection engine. The hypervisor is configured to expose the guest VM and a secure VM distinct from the guest VM, wherein the on-demand introspection engine executes within the secure VM, and wherein the in-place introspection engine executes externally from the guest VM and the secure VM. The on-site introspection engine is configured to, in response to detecting an occurrence of the event, transmit the event indicator to the server computer system. The on-demand introspection engine is configured to, in response to receiving the analysis request, identify the security tool according to the analysis request. The on-demand introspection engine is further configured to, in response to identifying the security tool, selectively retrieve the security tool from the tool repository, wherein retrieving the security tool includes the client system connecting to the remote tool repository via the communication network. The on-demand introspection engine is further configured to, in response to retrieving the security tool, execute the security tool to generate the result.

According to another aspect, a non-transitory computer-readable medium includes a set of instructions that, when executed on a hardware processor of a client computer system, cause the client computer system to form a hypervisor, a live introspection engine, and an on-demand introspection engine. The hypervisor is configured to expose a guest virtual machine (VM) and a secure VM distinct from the guest VM, wherein the on-demand introspection engine executes within the secure VM, and wherein the live introspection engine executes externally from the guest VM and the secure VM. The live introspection engine is configured to, in response to detecting the occurrence of an event within the guest VM, transmit an indicator of the event to a remote server computer system via a communication network. The on-demand introspection engine is configured to: in response to the live introspection engine transmitting the indicator of the event to the remote server computer system, receive an analysis request from the remote server computer system, the analysis request indicating a security tool residing in a remote tool repository, the remote tool repository configured to distribute the security tool to a plurality of clients including the client computer system, the security tool including software configured to analyze the occurrence of the event, the security tool selected by the remote server computer system based on the event type of the event. The on-demand introspection engine is further configured to: in response to receiving the analysis request, identify the security tool according to the analysis request, and in response, selectively retrieve the security tool from the tool repository, wherein retrieving the security tool includes connecting to a central tool repository via the communication network. The on-demand introspection engine is further configured to: in response to selectively retrieving the security tool, execute the security tool, and transmit a result of executing the security tool to the remote server computer system.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing aspects and advantages of the present invention will be better understood after reading the following detailed description and referring to the drawings, in which:

1 illustrates an exemplary configuration in which multiple client systems are protected from computer security threats, according to some embodiments of the present invention.

FIG2-A illustrates an exemplary hardware configuration of a client system according to some embodiments of the present invention.

FIG2-B shows an exemplary hardware configuration of a secure server computer system according to some embodiments of the present invention.

3-A shows an exemplary set of virtual machines and a pair of exemplary introspection engines exposed by a hypervisor executing on a protected client system, according to some embodiments of the invention.

FIG3-B illustrates an alternative configuration of a security component according to some embodiments of the present invention.

4 shows an exemplary sequence of steps performed by an installer application to set up computer security on a client system, according to some embodiments of the invention.

5 illustrates configuring a virtual private network (VPN) secure connection between a client system and a secure server, according to some embodiments of the present invention.

6 shows an exemplary data exchange between a client system and a secure server that occurs during malware detection, according to some embodiments of the present invention.

FIG7 shows an exemplary sequence of steps performed by a scene introspection engine according to some embodiments of the invention.

FIG8 shows an exemplary sequence of steps performed by an on-demand introspection engine according to some embodiments of the invention.

FIG9 illustrates an exemplary sequence of steps performed by a security server according to some embodiments of the present invention.

DETAILED DESCRIPTION

It should be understood that in the following description, all connections between structures may be direct operational connections or indirect operational connections through intermediate structures. A group of elements includes one or more elements. It should be understood that any statement of an element refers to at least one element. A plurality of elements includes at least two elements. Unless otherwise required, any method steps described do not necessarily need to be performed in the specific order described. A first element (e.g., data) derived from a second element encompasses a first element that is equal to the second element, and also encompasses a first element generated by processing the second element and, optionally, other data. Making a determination or decision based on a parameter encompasses making a determination or decision based on the parameter and, optionally, other data. Unless otherwise specified, an indicator of some quantity/data may be the quantity/data itself or an indicator different from the quantity/data itself. Computer security encompasses protecting users and devices from accidental or unauthorized access to data and/or hardware, accidental or unauthorized modification of data and/or hardware, and destruction of data and/or hardware. A computer program is a sequence of processor instructions that performs a task. The computer programs described in some embodiments of the present invention may be independent software entities or sub-entities (e.g., subroutines, libraries) of other computer programs. Unless otherwise specified, client software executes within a virtual machine. A program is said to execute within a virtual machine when it is executed on a virtual processor of the respective virtual machine. Unless otherwise specified, a page represents the smallest unit of virtual memory that can be individually mapped to the physical memory of the host system. Unless otherwise specified, a snapshot of a client system includes a copy of the contents of a memory segment used by the respective client system. Computer-readable media encompasses non-transitory media, such as magnetic, optical, and semiconductor memory media (e.g., hard drives, optical disks, flash memory, DRAM), and also encompasses communication links, such as conductive cables and fiber optic links. According to some embodiments, the present invention provides (among other things) a computer system comprising hardware (e.g., one or more microprocessors) programmed to perform the methods described herein, and also comprising a computer-readable medium encoding instructions to perform the methods described herein.

The following description illustrates embodiments of the invention by way of example and not necessarily by way of limitation.

FIG1 shows an exemplary configuration for protecting multiple client systems 12a-d from computer security threats according to some embodiments of the present invention. Exemplary client systems 12a-d include personal computer systems, mobile computing platforms (laptops, tablets, mobile phones), entertainment devices (TVs, game consoles), wearable devices (smart watches, fitness bands), home appliances, and any other electronic device that includes a processor and memory and is capable of operating a hardware virtualization platform. Another exemplary class of client systems includes data center servers and hardware virtualization platforms running cloud-based applications, such as website servers and/or virtual desktop infrastructures.

Client systems 12a-d are interconnected via a communication network 11, such as a home network, an enterprise network, the Internet, etc. Network 11 includes at least one switch and/or router. Components of network 11 may include a local area network (LAN) and/or a telecommunications network (e.g., a 4G mobile phone network, a wireless LAN).

In some embodiments, security server 14 is communicatively coupled to client systems 12a-d via network 11 and collaborates with client systems 12a-d to circumvent computer security threats, as described in detail below. Server 14 generally describes a group of interconnected computing systems that may or may not be in physical proximity to one another. In some embodiments, server 14 is configured to receive event notifications from client systems 12a-d and, in response, select a type of forensic analysis, threat mitigation protocol, and/or cleanup tool to be used by the respective client system based on the type of event. Exemplary forensic analysis includes, for example, obtaining specific data regarding the cause and/or context of the respective event. Threat mitigation protocols may be selected based on the type of malware indicated by the respective event and may include downloading and/or executing specific cleanup and/or damage control code on the respective client.

In some embodiments, the security server 14 is further configured to interface with a client database 17. In an exemplary client database 17, each entry is associated with a protected client system 12a to d and/or a virtual machine executing on the respective protected client system, and may include a log of triggering events and/or forensic reports (see below) reported by the respective client system/virtual machine. An exemplary entry of the database 17 may further include system profile data for the respective client system/virtual machine (e.g., including OS version, installed applications, various settings, owner, contact information, etc.). Another exemplary entry of the client database 17 may include a set of parameter values representing client-specific security policies associated with the respective client system. Such settings may be specified by a human operator or may be automatically set according to a set of rules. In some embodiments of the present invention, client-specific policies and/or security settings change dynamically in response to events occurring on the respective client or other protected clients.

In some embodiments, client systems 12a-d are further connected to a central tool repository 15 via network 11. Tool repository 15 may comprise computer-readable media or a physical machine storing security tools and resources in the form of code (computer programs) and/or data. Client systems 12a-d can connect to repository 15 to selectively retrieve tools and data based on instructions received from security server 14, as described in detail below. Tool repository 15 is available to multiple clients, so in a preferred embodiment of the present invention, repository 15 does not reside on any particular client system. Connecting to repository 15 thus includes transmitting and/or receiving communications to and from repository 15 via the respective client system's network adapter. Such communications may traverse network switches or routers along the way.

The security tools stored in repository 15 may include forensics, anti-malware, and/or threat mitigation tools. The repository data may further include parameter values for configuring or tuning the respective tools based on the type of incident under investigation or based on the local hardware/software configuration. Anti-malware tools enable detection of malware executing on client systems 12a-d and may include an encoding of a set of heuristic rules and/or a database of malware identification signatures. Threat mitigation tools may include cleanup tools programmed to remove or otherwise disable malware agents executing on a client system. Other exemplary threat mitigation tools are programmed to prevent an infected client system from transmitting malware to another client system, for example, by controlling the infected client system's use of its network adapter.

Forensic tools enable analysis of security-related events occurring on client systems 12a-d. Some examples of forensic tools include snapshot generation tools that are programmed to obtain a memory snapshot of a client system or a memory snapshot of a virtual machine executing on the respective client system. The snapshot may include memory data associated with an operating system (OS) or associated with another application currently executing on the respective client system. A snapshot of an OS kernel may include, among other things, a copy of the kernel's code and data segments, various in-memory kernel drivers (code and/or data segments), in-memory kernel threads and their corresponding stacks, and kernel data structures of the OS, such as a list of loaded modules, a process list, and the like. An exemplary snapshot of an application includes a memory image of the application (including its code and data segments), in-memory stacks used by the application's threads, a copy of the respective application's heap memory pages, and the like.

In some embodiments, generating a memory snapshot includes suspending execution of guest VM 32 to allow the contents of the corresponding memory segments to be copied. Alternative embodiments perform "live" memory forensics without generating a snapshot. In such embodiments, hypervisor 30 may map a set of physical memory pages used by guest VM 32 to virtual memory pages used by secure VM 33. Secure VM 33 may then examine the contents of the corresponding memory pages, for example, in response to a specific event, without having to suspend execution of guest VM 32 or copy and transfer the corresponding contents. One example of a "live" memory forensics tool is the framework from the Volatility Foundation.

Another example of a forensic tool is an application inventory tool configured to enumerate software entities currently installed on a client system and/or currently executing on a client system. Yet another example of a forensic tool is a configuration crawler programmed to obtain a set of configuration settings (e.g., current values of various OS parameters, hardware settings, security settings, firewall settings, etc.). Other exemplary forensic tools are programmed to collect system and/or application event logs or system crash data (e.g., crash minidumps).

FIG2-A shows an exemplary hardware configuration of a client system 12 (e.g., systems 12a to d in FIG1 ). For simplicity, the client system illustrated is a computer system; the hardware configuration of other client systems (e.g., mobile phones, watches, etc.) may differ slightly from the illustrated configuration. Client system 12 includes a set of physical devices, including a hardware processor 16 and a memory unit 18. In some embodiments, processor 12 includes a physical device (e.g., a microprocessor, a multi-core integrated circuit formed on a semiconductor substrate, etc.) configured to perform computing operations and/or logical operations using a set of signals and/or data. In some embodiments, such operations are delivered to processor 12 in the form of a sequence of processor instructions (e.g., machine code or other type of encoding). Memory unit 18 may include volatile computer-readable media (e.g., DRAM, SRAM) that stores instructions and/or data accessed or generated by processor 16.

Depending on the type and capabilities of the devices, client system 12 may further include a set of input devices 20, such as a keyboard, mouse, touch screen, etc., which enable a user to enter data and/or instructions into client system 12. A set of output devices 22, such as a monitor or liquid crystal display, can convey information to the user, for example, via a graphical user interface. Storage devices 24 include computer-readable media that enable non-volatile storage, reading, and writing of processor instructions and/or data. Exemplary storage devices 24 include magnetic and optical disks and flash memory devices, as well as removable media such as CD and/or DVD disks and drives. A set of network adapters 26 enables client system 12 to connect to communication network 11 and/or to other devices/computer systems. Controller hub 28 generally represents multiple system, peripheral, and/or chipset buses and/or all other circuitry that enables communication between processor 16 and devices 18, 20, 22, 24, and 26. For example, controller hub 28 may include a memory management unit (MMU), an input/output (I/O) controller, an interrupt controller, and the like. In another example, controller hub 28 may include a north bridge that connects processor 16 to memory 18 and/or a south bridge that connects processor 16 to devices 20, 22, 24, and 26. In some embodiments, controller hub 28 may be partially or fully integrated with processor 16, e.g., an MMU may share a common semiconductor substrate with processor 16.

FIG2-B shows an exemplary hardware configuration for secure server 14. Server 14 includes a hardware processor 116, server memory 118, a set of server storage devices 124, and a set of network adapters 126, all of which are connected by a server controller hub 128. The operations of devices 116, 118, 124, and 126 may mirror the operations of devices 16, 18, 24, and 26 described above. For example, server processor 116 may include an integrated circuit configured to perform computing operations and/or logical operations using a set of signals and/or data. Server memory 118 may include non-transitory computer-readable media (e.g., RAM) that stores data/signals accessed or generated when computing by processor 116. Network adapter 126 enables secure server 14 to connect to communication network 11.

In some embodiments, client system 12 is configured to expose a set of virtual machines, for example, as illustrated in Figures 3-A to B. Virtual machines (VMs) emulate actual physical machines/computer systems using any of a variety of techniques known in the art of hardware virtualization. In some exemplary configurations, a hypervisor 30 is executed on client system 12, which is configured to create or enable multiple virtualized devices, such as virtual processors and virtual memory management units, and present such virtualized devices to software to mimic the actual physical devices of client system 12. Such operations are generally known in the art as exposing virtual machines. Hypervisor 30 can further enable multiple virtual machines to share the hardware resources of host system 12 so that each VM can operate independently and is unaware of other VMs currently executing on client system 12. Examples of popular hypervisors include VMware and open source hypervisors from VMware Inc., among others.

In the exemplary configuration illustrated in Figures 3-A to B, a guest VM 32 executes a guest operating system 34 and applications 36. Although Figures 3-A to B show only one guest VM, in applications such as virtual desktop infrastructure (VDI) and server farming, client system 12 may execute multiple such VMs (e.g., hundreds of VMs) simultaneously. Each guest VM includes at least one virtualized processor and may further include other virtualized devices, such as virtualized input, output, storage, and network devices, as well as a virtualized controller. Each virtualized processor includes an emulation of at least some functionality of a hardware processor 16 and is configured to receive processor instructions for execution. Software that uses a virtual processor for execution is said to execute within the corresponding virtual machine. For example, in the example of Figures 3-A to B, guest OS 34 and applications 36 are said to execute within guest VM 32. In contrast, hypervisor 30 is said to execute outside or below guest VM 32.

OS 34 provides an interface between application programs 36 and the virtualized hardware of client VM 32. Operating system 34 may include any widely available operating system, such as Microsoft Windows or Windows XP. Application programs 36 generally represent any computer program, such as word processing, image processing, media players, databases, calendars, personal contact management, browsers, games, voice communications, and data communications applications.

In some embodiments, hypervisor 30 further exposes a secure VM 33, which can execute concurrently with guest VM 32, thereby protecting guest VM 32 from computer security threats, such as malware and intrusions. A single secure VM can protect multiple guest VMs executing on a corresponding client system. The virtual environments of guest VM 32 and secure VM 33 can be isolated from each other to ensure that malware executing within guest VM 32 does not infect or otherwise interfere with software executing within secure VM 33. For example, the virtual processor of secure VM 33 is different from the virtual processors of other virtual machines executing on client system 12; memory translation for secure VM 33 and guest VM 32 uses different sets of page tables. Secure VM 33 can be configured to cooperate with secure server 14, as described in detail below. Some embodiments of secure VM 33 include a lightweight minimal operating system (e.g., a customized version of the OS), an on-demand introspection engine 42, and a network filter 44. In an alternative embodiment, network filter 44 executes outside of secure VM 33 , such as at a processor privilege level (eg, root level, ring-1) of hypervisor 30 .

In some embodiments, hypervisor 30 may expose only a subset of virtualized devices to guest VM 32 and may grant secure VM 33 direct and exclusive use of some hardware devices of client system 12. In one such example, guest VM 32 may have exclusive use of input devices 20 and output devices 22, but lack exclusive use of a virtualized network adapter. Meanwhile, secure VM 33 may have direct and exclusive use of network adapter 26. In one such embodiment, all communications to and/or from guest VM 32 are sent/received via secure VM 33. For example, hypervisor 30 may actively route network packets between guest VM 32 and secure VM 33 using a memory sharing mechanism. Secure VM 33 may further use filters 44 to selectively allow or prevent communications between guest VM 32 and remote parties. Such a configuration may be implemented, for example, using techniques from [ 15 ].

In some embodiments, the security software executing on the client system 12 further includes an on-site introspection engine 40 executing externally to the protected guest VM 32. The term "introspection" is used herein to refer to activities aimed at collecting information about software executing within a target VM from a location external to the respective VM. Examples of introspection include, among other things, determining whether the software executing within the respective VM performs certain actions (e.g., executes certain processor instructions, accesses certain hardware resources, uses certain services of the OS, accesses certain memory locations, etc.). Other examples of introspection include determining memory addresses used by various software objects executing within the respective VM and/or controlling access to memory locations indicated by such addresses.

Engine 40 may be incorporated into hypervisor 30, e.g., as a library, or may be delivered as a computer program distinct and independent from hypervisor 30 but executing at the processor privilege level (e.g., root mode, ring-1) of hypervisor 30. In alternative embodiments, the field introspection engine may execute in a separate virtual machine distinct from guest VM 32. Engine 40 may be a process with a separately scheduled thread of execution, or may operate as a collection of unscheduled code objects that execute when triggered by certain events, as shown below.

Engine 40 is configured to monitor the behavior of multiple executable entities (e.g., processes, threads, applications). This may include detecting the occurrence of various events during the execution of the corresponding software and selectively reporting such events to security server 14. Various types of events can be detected in this manner, such as invocations of certain OS functions, system calls, and the like. Other examples of detected events include attempts to modify the functionality of OS 34 (code manipulation commonly known in the art as code patching or hooking), attempts by one software entity to inject code into another software entity, attempts to launch software components without digital signatures, attempts to circumvent digital signature verification, and the like. Other types of detected events may include opening a file, creating a file, writing to a file, deleting a file, copying a file, creating a process, terminating a process, scheduling a thread for execution, suspending a thread due to a synchronization event (e.g., mutual exclusion), creating a heap, allocating memory from the heap, extending the size of the execution stack, changing memory access permissions, performing a swap-in (e.g., disk to memory) operation, performing a swap-out (e.g., memory to disk) operation, loading an executable module (e.g., a shared library - DLL), opening a registry key, renaming a registry key, detecting the attachment of a new hardware device, establishing a new network connection, receiving a network packet, increasing the execution privileges of a thread, and changing the discretionary access control (DAC) permissions associated with a file.

Several methods for detecting such events are known in the art. These include hooking certain OS functions, modifying dispatch tables, and the like. In hardware virtualization platforms, a special class of methods for detecting security-related events relies on detecting violations of memory access permissions. Most modern computer systems are configured to operate with virtual memory and use dedicated data structures (e.g., page tables) to manage memory address translation. Systems configured to support hardware virtualization typically use a second level of address translation from the guest physical memory seen by each exposed VM to the actual physical memory 18 of the client system 12. This second address translation is typically implemented using a hardware-accelerated dedicated data structure and a mechanism controlled by the processor 16, referred to as the Second Level Address Translation (SLAT). Popular SLAT implementations include the Extended Page Table (EPT) on the platform and the Rapid Virtualization Index (RVI)/Nested Page Table (NPT) on the platform. The SLAT typically allows for setting memory access permissions for each memory page, such as read/write/execute.

In some embodiments, the field introspection engine 40 cooperates with the hypervisor 30 to set access permissions for certain memory pages using the SLAT mechanism described above. In one such example, a particular memory page controls code belonging to a particular OS function. Marking the corresponding page as non-executable triggers a permissions violation when attempting to execute the corresponding OS function. The violation can be interpreted by the introspection engine 40 as an indicator that an attempt to execute the corresponding OS function has occurred.

The processor 16 can be configured to trigger a processor event (e.g., an exception, a fault, etc.) when software attempts to access a corresponding page in a manner that violates current access permissions. One type of processor event includes a VM exit event (VMExit on a platform), in which the processor 16 switches from executing code within the corresponding VM to executing a handler routine outside the corresponding VM in response to a memory access permission violation. Another type of processor event includes a virtualization exception (#VE on a platform), in which the processor 16 switches to executing a handler routine within the corresponding VM.

In the exemplary configuration of FIG3-A , event handler 46 a executes outside the monitored guest VM at the processor privilege level of hypervisor 30. Such embodiments may rely on VM exit events to notify the introspection engine 40 of the occurrence of events within guest VM 32. In contrast, in FIG3-B , event handler 46 b executes within the monitored VM, for example, at the processor privilege level of guest OS 34 (e.g., ring 0, kernel mode). Such a configuration may rely on virtualization exceptions to detect events within the VM. Handler 46 b may use an inter-process communication mechanism (e.g., using a shared memory segment) to send event information to introspection engine 40. The configuration shown in FIG3-B may be more efficient in information collection than the configuration shown in FIG3-A because handler 46 b executes within the monitored VM and can therefore use the functions and mechanisms of guest OS 34 to determine the semantics of each detected event. However, by executing within guest VM 32, handler 46 b may be more vulnerable to malware than handler 46 a.

Instead of relying solely on the on-site introspection engine 40 or software executing within a protected VM to analyze security events, some embodiments of the present invention further deploy a second on-demand introspection engine 42. The on-site introspection engine 40 can detect the occurrence of various events within the monitored client VM, but cannot perform complex forensic analysis of such events because such analysis is computationally expensive and would negatively impact the user experience. Instead, the on-demand introspection engine 42 can be invoked to perform the corresponding forensic analysis, but can selectively trigger such forensic analysis only for a subset of events detected by the on-site introspection engine 40. In some embodiments, the decision to perform forensic analysis of an event is made by the security server 14 and communicated to the corresponding client system 12.

In some embodiments, the field introspection engine 40 and the on-demand introspection engine 42 may communicate with each other, for example, via a shared memory segment and via signaling implemented by the hypervisor 30. For example, when performing forensic activities, the on-demand introspection engine 42 may read and use the current state of the field introspection engine 40. The field introspection engine may, in turn, receive notifications from the on-demand introspection engine, for example, signaling that a forensic activity is currently being performed.

FIG4 illustrates an exemplary sequence of steps performed to set up computer security on a client system 12, according to some embodiments of the present invention. In a typical scenario for protecting an enterprise network from computer security threats, a network administrator may install a security application on each client system 12a-d requiring protection. The security application may include various components, such as a hypervisor 30, introspection engines 40-42, event handlers 46a-b, and the like. The illustrated sequence of steps may be implemented, for example, by an installer tool for the respective security application. When installed in the absence of a hardware virtualization environment, the security software may first take over the processor 16 and install the hypervisor 30 at the highest processor privilege level (e.g., root mode, ring-1). The hypervisor 30 may then expose a guest VM 32 and move all software previously executing on the respective client system to execute within the guest VM 32. The hypervisor 30 may further set up a secure VM 33 and configure methods for sharing the respective client system's hardware between VMs 32-33. The installer may then install and launch the software executing within the secure VM 33, as well as the live introspection engine 40.

In some embodiments, the hypervisor 30 and/or secure VM 33 may use a secure boot mechanism or another form of authenticated boot known in the art to ensure that the secure VM 33 executes trusted software. Setting up the secure VM 33 (step 204) and/or other software executing within the secure VM 33 may include an authentication exchange (e.g., hash verification) with the secure server 14 or other authentication entity. In one exemplary embodiment, the secure boot may utilize a secure storage hardware component of the client system 12, such as a Trusted Platform Module (TPM) on the platform, and further utilize an integrity authentication mechanism, such as Trusted Execution Technology (TXT).

In some embodiments, step 206 sets up remote management access from secure server 14 to secure VM 33. This access enables secure server 14 (automatically or with the assistance of a human operator) to send instructions and commands directly to the protected client system, for example, to instruct on-demand introspection engine 42 to perform a specific type of forensic analysis or implement a specific sequence of cleanup steps. Setting up remote management access may include setting up a tunnel (i.e., a point-to-point secure communication channel) between server 14 and secure VM 33, for example, via a secure shell (SSH) or virtual private network (VPN) protocol. FIG5 shows this exemplary exchange. Tunnel request 48 may be issued by either client system 12 or server 14. Request 48 may include an indicator of the exchange protocol and a set of encryption keys. In response, the communicating parties set up secure tunnel 49, which includes a specific method of encrypting and routing network packets between the communicating parties. In some embodiments, hypervisor 30 routes network packets received from secure server 14 directly to secure VM 33.

6 shows an exemplary data exchange between a secure server 14 and a protected client system according to some embodiments of the present invention. A client system 12 may send an event indicator 50 to notify the server 14 that an event has occurred during execution of software within a client VM 32. The event indicator 50 may include an indicator of the event type of the corresponding event, a timestamp of the event, and an identifier (client ID) of the corresponding client system 12 and/or client VM 32.

In response, server 14 may send an analysis request 52 to client system 12, instructing on-demand introspection engine 42 to perform certain forensic activities on client system 12. Analysis request 52 may include an indicator of a forensic tool to be used by engine 42 to perform data collection/event analysis, and/or an indicator of some other type of security resource. In some embodiments, analysis request 52 may be sent out to a client system in response to receiving an event indicator from another client system.

In some embodiments, in response to performing the requested forensic activity, the on-demand introspection engine 42 transmits a forensic report 54 to the server 14, including the results of performing the corresponding forensic activity. The report 54 may include, for example, a list of software objects, a list of memory addresses, a security list, or a list of hardware settings.

In response to receiving the forensic report 54, the server 14 may determine whether the corresponding client system/customer VM is vulnerable to a particular type of computer security threat, for example, whether the corresponding client system/customer VM is infected with malware. When a computer security threat is detected, the server 14 may transmit a security alert 56 to the corresponding client system 12. Some embodiments of the server 14 further transmit a mitigation indicator 58, which may include, for example, an indicator of a cleanup tool or a set of parameter values for configuring the network filter 44.

FIG7 shows an exemplary sequence of steps performed by the live introspection engine 40 according to some embodiments of the present invention. The engine 40 may be configured to listen for at least two types of messages/notifications: notifications from event handlers 46a-b regarding events occurring within the client VM 32; and notifications from the security VM 33 (e.g., notifications from the on-demand introspection engine 42 signaling to the engine 40 that forensic activity is currently occurring). Upon receiving an event notification, the engine 40 may perform a preliminary analysis of the event notification in step 226. In some embodiments, such preliminary analysis has minimal computational cost to keep the impact on the user experience as low as possible. For example, step 226 may filter the event notifications using a relatively simple set of rules. Only certain types of events may be reported to the security server 14 (steps 228-230). In one exemplary embodiment, the events transmitted to the security server 14 include, among other things, attempts to hook or patch the OS kernel, injection of unknown modules, and attempts to execute code from specific memory regions. When the detected event does not fall into a reportable event category, some embodiments of engine 40 simulate a corresponding event and then resume execution of guest VM 32 .

When the detected event includes a notification from the security VM 33 (step 232), some embodiments may display a warning message on an output device of the client system 12, for example, to inform the user that the client system 12 may experience a temporary slowdown due to ongoing forensics or threat mitigation activities. In another step 236, some embodiments of the on-site introspection engine 40 may collaborate with the auxiliary on-demand introspection engine 42 to perform forensics/mitigation activities. An example of such collaboration includes the on-demand introspection engine 42 querying the on-site introspection engine 40 for its current status.

FIG8 shows an exemplary sequence of steps performed by on-demand introspection engine 42 according to some embodiments of the present invention. In step sequence 250-252, engine 42 may listen for analysis requests from server 14 (see FIG5 ), for example, via secure tunnel 49 established between server 14 and secure VM 33. In some embodiments, hypervisor 30 may automatically switch from executing guest VM 32 to executing secure VM 33 and on-demand introspection engine 42 in response to receiving analysis request 52.

The request 52 may indicate a set of tools and/or security resources to be used in the forensic activity. For example, the analysis request 52 may include a location indicator (e.g., a memory address, a network path) that allows the selective retrieval of the corresponding tools from the tool repository 15. In step 256, the engine 42 accesses such tools/resources via the communication network 11. Accessing the tools/resources may include downloading the corresponding tools/resources from the tool repository 15 to the local storage device 24 of the client system 12 (Figure 2-A). In a preferred embodiment, accessing the tools/resources includes the on-demand engine 42 installing the corresponding tools/resources from its remote location. Installation in this article refers to creating a connection between the remote resource (controlled by the tool repository 15) and the local file system of the security VM 33 so that the security VM 33 can access the corresponding resource via the local file system. For example, in the file system, installation is achieved via the "install" command, and the connection includes the mount point.

In some embodiments, the server 14 may explicitly instruct the engine 42 to access and/or install the corresponding tool/resource via the tunnel 49. In response to accessing the tool/resource, the engine 42 may perform the requested forensic activities, send the forensic report 54 to the server 14, and uninstall or otherwise discard the corresponding tool/resource in a sequence of steps 258 to 260 to 262. Discarding the tool/resource at the end of the forensic analysis may be beneficial because it prevents malware from spreading between different sessions of forensic analysis and ensures that the client systems 12a-c always use the latest version of the corresponding resource available in the tool repository 15.

FIG9 shows an exemplary sequence of steps performed by security server 14 according to some embodiments of the present invention. Server 14 may be configured to listen for communications received from client systems 12a-d (steps 280-282). When such communications include an event indicator (i.e., a notification that an event has occurred on a protected client system), some embodiments record the corresponding event (step 286) and determine, based on event indicator 50, whether to request forensic analysis and what type of analysis to request. In one such example, when event indicator 50 indicates that code injection has occurred, server 14 may request analysis using "application imaging snapshots" and/or memory forensics tools. In some embodiments, certain types of events generate requests for complex analysis using multiple tools and resources.

The decision may be made based on the type of event indicated by the current notification and/or based on the security policy currently in effect for the corresponding client system/client VM. The decision process may therefore include querying the client database 17 for event history and/or client-specific policies (step 290). Other decision criteria may include the hardware configuration of the corresponding client system (e.g., whether the client system 12 has specialized hardware components, such as a specific type of processor, network adapter, etc.). Other criteria may include software aspects, such as a type of operating system and a type of application 36 (web server, database processing, etc.) executed within the client VM 32. Such decision strategies rely on the knowledge that certain software is vulnerable to specific computer security threats. The decision process may employ a set of heuristic rules, a decision tree, or any other method known in the art. One exemplary embodiment may use an artificial neural network that receives data (e.g., event type and various policy feature values) as input and outputs a decision indicator (e.g., yes/no) indicating whether to request forensic analysis.

In some embodiments, the decision of whether to request forensic analysis and/or what type of analysis to request can further take into account a history of events that occurred on the same client system. Such embodiments allow for correlation of events that occurred at different times and, thus, can allow for detection of complex malware that distributes its malicious payload across numerous software entities (e.g., some actions are performed by a first entity and other actions are performed by children of the first entity or by a second entity containing code injected by the first entity).

In some embodiments, the decision-making process may consider a history of events that occurred on client systems other than the sender of the event notification 50. In one such example, the server 14 may query the event log for information about whether a particular type of event has recently occurred on other client systems. A burst of such activity may signal a wave of malware (zero-day threats) spreading among client systems or a coordinated attack being carried out by multiple client systems.

When the notified event authorizes forensic analysis (step 292), step 294 selects resources and/or forensic tools to be used by the corresponding client system to perform the required forensic analysis. The selection may be made based on a set of rules, a decision tree, etc. In one example, in response to receiving a notification that a code injection has occurred, server 14 may request analysis using an "application snapshot" tool. In some embodiments, certain types of events generate requests for complex analysis using multiple tools and resources.

When the communication received from the client system 12 includes a forensic report 54 (step 298), the server 14 may analyze the corresponding report (step 300) and may corroborate the report 54 with other reports from the same or other client systems and determine whether any of the client systems 12a-c are vulnerable to a computer security threat (e.g., may be under attack by a malicious entity). When it is determined that any of the client systems 12a-c are vulnerable to a computer security threat, the server 14 may send a warning to an administrator and/or send a security alert 56 to the affected client system. In another step 306, the server 14 may send a mitigation indicator 58 to the corresponding client system, for example, via the secure tunnel 49. The mitigation indicator 58 may include commands, instructions, and/or an indicator of a set of cleanup tools.

In the exemplary embodiment described above (Figures 7-8-9), the decision as to whether to request forensic analysis and/or what type of analysis to request is made by the security server 14. In an alternative embodiment, the on-demand introspection engine 42 receives the analysis request 52 and the event indicator 50 directly from the live introspection engine 40, for example, via an inter-process communication mechanism managed by the hypervisor 30. The on-demand introspection engine 42 can then select a set of forensic tools/resources to use based on the event indicator 50 and/or other criteria, as described above. In such an embodiment, the decision to access (e.g., install) the corresponding resources is therefore made at the protected client system.

Some embodiments of the present invention further enhance computer security by employing network filters 44 to regulate communications between client system 12 and security server 14, or between client system 12 and other entities connected to communications network 11. In one example, security VM 33 can be configured to have exclusive use of client system 12's network adapter 26. Hypervisor 30 can then route all communications to/from guest VM 32 via security VM 33's network filters 44. In some embodiments, when server 14 determines that client system 12 is vulnerable to or may be under attack by a malicious entity, server 14 can instruct network filters 44 to block all communications to/from guest VM 32, thereby preventing guest VM 32 from connecting to other client systems over the local network or accessing the Internet. In alternative embodiments, network filters 44 can block or otherwise regulate communications between guest VM 32 and another entity while on-demand introspection engine 42 is performing forensic activities.

Some embodiments of the present invention allow a relatively large number of client systems (e.g., an enterprise network) to be protected from computer security threats such as malware, spyware, adware, and unauthorized intrusions. Some embodiments may further allow security to be easily and reliably managed from a central point, such as from a secure server communicatively coupled to the protected client systems. This centralization may be particularly advantageous for cloud computing applications, such as web server farming and virtual desktop infrastructure management, where hundreds of virtual machines may be operating simultaneously on a single hardware platform.

In some embodiments, each protected client operates an on-site introspection engine and an on-demand introspection engine. The on-site introspection engine detects the occurrence of certain events within a protected virtual machine exposed on the corresponding client system and transmits the occurrence to a remote security server. The server can, in turn, select a forensic tool from a tool repository based on the event type of the reported event and/or based on the hardware and/or software specificities of the corresponding client. The on-demand introspection engine can retrieve the forensic tool and execute the forensic tool to perform a forensic analysis of the event (e.g., to reveal the context of the corresponding event). The results of the forensic analysis can then be transmitted to the security server, which can use the information to determine whether the corresponding client is under attack by malware or an intruder.

Some embodiments of the present invention rely on the insight that typical computer security solutions used to protect large numbers of clients do not respond well to attacks. Even when existing solutions are able to detect an attack, analysis and remediation may require dispatching human operators to the affected client systems, especially in the case of complex threats such as ransomware and malicious intrusions. In contrast, in some embodiments of the present invention, customized data collection/fact-finding (forensic analysis) and threat mitigation (e.g., malware cleanup) are automatically performed on the client machine under the direct guidance of a security server. One exemplary embodiment of the present invention establishes a secure point-to-point communication channel between a protected client and a security server, which allows a human operator to remotely configure the respective client and even perform forensic/cleanup operations on the respective client from a remote terminal.

By aggregating event detection and forensic analysis results from multiple clients, some embodiments can enable rapid detection of previously unknown malware (referred to in the art as zero-day attacks). Conventional server-side threat detection typically requires significant server-side computing power. In contrast to typical client-server detection scenarios, in some embodiments of the present invention, some expensive security-related operations (such as event filtering and forensic analysis) are performed by the client system itself. Some embodiments thus utilize the distributed computing power of multiple client machines to perform some expensive threat detection and analysis operations, instead of shifting most of the computational burden to a security server.

Some embodiments of the present invention further rely on the observation that not all events occurring in a computer system inherently signal or indicate a computer security threat. The same type of event (e.g., accessing a URL, opening a disk file, etc.) may indicate malicious intent in some scenarios while being completely benign in other scenarios. In one such example, an event may not indicate malicious intent when isolated, but may indicate malware when it occurs as part of a specific sequence of events. For example, writing to a disk file may be a benign operation when isolated (i.e., a group of processes and applications legitimately access the disk). However, a write event may be suspicious when the entity performing the write is the recipient of code injected from another entity. In some embodiments of the present invention, a field introspection engine pre-filters detected events based on various criteria and reports only a selected subset of such events to the security server. This strategy further reduces the computational burden imposed on the server.

In conventional computer security applications, client-side security tools (e.g., anti-malware routines, signature databases, etc.) reside on client computer systems and are kept up to date through periodic software updates. In contrast, in some embodiments of the present invention, security tools are maintained in a centralized repository (e.g., a dedicated server on an enterprise network). Client systems can retrieve only the required tools on demand when directed by the security server, eliminating the need for extensive software updates and time-consuming network management. In a preferred embodiment, client systems access security tools remotely by mounting a remote centralized tool repository on the client's file system.

Keeping most security tools in a central repository (as opposed to protected clients or security servers) ensures that clients can utilize the latest versions of the corresponding security tools. Another significant advantage of this type of configuration is that it allows the client-side and server-side software to be significantly smaller than in conventional security systems. Such lightweight components (e.g., hypervisor 30, field and on-demand introspection engines 40-42) are easy to develop, maintain, and deploy to clients. They also require fewer updates than all-in-one security solutions that include forensics and/or threat mitigation tools. In addition, lightweight components expose a relatively small attack surface to malware and hackers.

It will be apparent to those skilled in the art that the above embodiments may be modified without departing from the scope of the present invention. Therefore, the scope of the present invention should be determined by the appended claims and their legal equivalents.

Claims (25)

1. A client computer system comprising a hardware processor configured to execute a hypervisor, a live introspection engine, and an on-demand introspection engine, wherein: the hypervisor being configured to expose a guest virtual machine and a secure virtual machine distinct from the guest virtual machine, wherein the on-demand introspection engine executes within the secure virtual machine, and wherein the in-situ introspection engine executes external to the guest virtual machine and the secure virtual machine; The live introspection engine is configured to transmit an indicator of the event to a remote server computer system over a communications network in response to detecting an occurrence of the event within the client virtual machine; and The on-demand introspection engine is configured to: receiving, in response to the field introspection engine transmitting the indicator of the event to the remote server computer system, an analysis request from the remote server computer system, the analysis request indicating a security tool resident in a remote tool repository, the remote tool repository configured to distribute security tools to a plurality of clients including the client computer system, the security tool including software configured to analyze the occurrence of the event, the security tool selected by the remote server computer system based on an event type of the event, In response to receiving the analysis request, identifying the security tool according to the analysis request, In response to identifying the security tool, selectively retrieving the security tool from the remote tool repository, wherein retrieving the security tool comprises connecting to the remote tool repository over the communication network, In response to selectively retrieving the security tool, executing the security tool, and In response to executing the security tool, results of executing the security tool are transmitted to the remote server computer system. 2. The client computer system of claim 1, wherein the remote server computer system is further configured to determine whether the client computer system includes malware based on the result. 3 . The client computer system of claim 1 , wherein the remote server computer system is further configured to detect malicious intrusion of the client computer system based on the result. 4. The client computer system of claim 1 , wherein the on-demand introspection engine is further configured to: In response to transmitting the result to the remote server computer system, receiving from the remote server computer system an indicator of a mitigation tool resident in the remote tool repository, the mitigation tool comprising software configured to disable malware executing on the client computer system; and In response to receiving the indicator of the resolution tool, the resolution tool is retrieved and executed. 5. The client computer system of claim 1 , wherein the site introspection engine is further configured to: In response to detecting the occurrence of the event, determining whether an event qualification condition is satisfied based on an event type of the event; and In response, the indicator of the event is transmitted to the remote server computer system only when the event qualifying conditions are met. 6 . The client computer system of claim 1 , wherein retrieving the security tool from the remote tool repository comprises mounting the remote tool repository on a file system of the secure virtual machine. 7. The client computer system of claim 1, wherein the secure virtual machine further comprises a network filter, and wherein the hypervisor is further configured to route network traffic between the client virtual machine and a remote party via the network filter. 8. The client computer system of claim 7, wherein: The remote server computer system is further configured, in response to determining whether the client computer system includes malware, to send a security alert to the client computer system when the client computer system includes malware; and The network filter is configured to restrict network traffic between the guest virtual machine and the remote party in response to the client computer system receiving the security alert. 9. The client computer system of claim 1, wherein the result of executing the security tool includes a copy of the contents of a memory segment used by the guest virtual machine. 10. The client computer system of claim 1, wherein the result of executing the security tool comprises a list of software entities executing within the client virtual machine. 11. The client computer system of claim 1 , wherein the result of executing the security tool includes an indicator of a hardware configuration of the client computer system. 12. The client computer system of claim 1, wherein: The hypervisor is configured to establish a secure peer-to-peer communication channel between the remote server computer system and the secure virtual machine; and The on-demand introspection engine is configured to receive the analysis request and transmit the results via the secure peer-to-peer communication channel. 13. A server computer configured to perform computer security transactions with a plurality of client systems, the server computer system comprising a hardware processor configured to: in response to receiving an event indicator from a client system of the plurality of client systems, the event indicator indicating an occurrence of an event within a client virtual machine executing on the client system, selecting a security tool residing in a remote tool repository configured to distribute security tools to the plurality of client systems, the security tool comprising software configured to analyze the occurrence of the event, wherein selecting the security tool is performed based on an event type of the event; In response to selecting the security tool, transmitting an analysis request to the client system over a communications network, the analysis request including an identifier of the security tool; and In response to transmitting the indicator of the security tool, receiving from the client system a result of executing the security tool on the client system, The client system is configured to execute a hypervisor, a live introspection engine, and an on-demand introspection engine, wherein: The hypervisor is configured to expose the guest virtual machine and a secure virtual machine distinct from the guest virtual machine, wherein the on-demand introspection engine executes within the secure virtual machine, and wherein the in-situ introspection engine executes external to the guest virtual machine and the secure virtual machine, The scene introspection engine is configured to transmit the event indicator to the server computer system in response to detecting the occurrence of the event, and The on-demand introspection engine is configured to: In response to receiving the analysis request, identifying the security tool according to the analysis request, In response to identifying the security tool, selectively retrieving the security tool from the remote tool repository, wherein retrieving the security tool comprises connecting the client system to the remote tool repository over the communication network, and In response to retrieving the security tool, executing the security tool to produce the result. 14. The server computer of claim 13, wherein the hardware processor is further configured to determine whether the client system includes malware based on the result. 15. The server computer of claim 13, wherein the hardware processor is further configured to detect a malicious intrusion of the client system based on the result. 16. The server computer of claim 13, wherein the hardware processor is further configured to: In response to determining whether the client system includes malware, selecting a mitigation tool from the remote tool repository when the client system includes malware, the mitigation tool including software configured to render the malware inoperable; and In response to selecting the resolution tool, an indicator of the resolution tool is transmitted to the client system. 17. The server computer of claim 13, wherein the site introspection engine is further configured to: In response to detecting the occurrence of the event, determining whether an event qualification condition is satisfied based on an event type of the event; and In response, the indicator of the event is transmitted to the server computer system only when the event qualifying conditions are met. 18. The server computer of claim 13, wherein retrieving the security tool from the remote tool repository comprises mounting the remote tool repository onto a file system of the secure virtual machine. 19. The server computer of claim 13, wherein the secure virtual machine further comprises a network filter, and wherein the hypervisor is further configured to route network traffic between the client virtual machine and a remote party via the network filter. 20. The server computer of claim 19, wherein the hardware processor is further configured to, in response to determining whether the client system includes malware, send a security alert to the client system when the client system includes malware; and wherein receipt of the security alert by the client system causes the network filter to limit network traffic between the client virtual machine and the remote party. 21. The server computer of claim 13, wherein the result of executing the security tool includes a copy of the contents of a memory segment used by the guest virtual machine. 22. The server computer of claim 13, wherein the results of executing the security tool include a list of software entities executing within the client virtual machine. 23. The server computer of claim 13, wherein the result of executing the security tool includes an indicator of a hardware configuration of the client system. 24. The server computer according to claim 13, wherein: The hypervisor is configured to establish a secure peer-to-peer communication channel between the server computer and the secure virtual machine; and The hardware processor is further configured to send the indicator of the security tool and receive the result of executing the security tool via the secure peer-to-peer communication channel. 25. A non-transitory computer-readable medium comprising a set of instructions that, when executed on a hardware processor of a client computer system, cause the client computer system to form a hypervisor, a live introspection engine, and an on-demand introspection engine, wherein: the hypervisor being configured to expose a guest virtual machine and a secure virtual machine distinct from the guest virtual machine, wherein the on-demand introspection engine executes within the secure virtual machine, and wherein the in-situ introspection engine executes external to the guest virtual machine and the secure virtual machine; The live introspection engine is configured to transmit an indicator of the event to a remote server computer system over a communications network in response to detecting an occurrence of the event within the client virtual machine; and The on-demand introspection engine is configured to: receiving, in response to the field introspection engine transmitting the indicator of the event to the remote server computer system, an analysis request from the remote server computer system, the analysis request indicating a security tool resident in a remote tool repository, the remote tool repository configured to distribute security tools to a plurality of clients including the client computer system, the security tool including software configured to analyze the occurrence of the event, the security tool selected by the remote server computer system based on an event type of the event, In response to receiving the analysis request, identifying the security tool according to the analysis request, In response to identifying the security tool, selectively retrieving the security tool from the remote tool repository, wherein retrieving the security tool comprises connecting to the remote tool repository over the communication network, In response to selectively retrieving the security tool, executing the security tool, and In response to executing the security tool, results of executing the security tool are transmitted to the remote server computer system.