Patent Application
20120144489
A virtual machine (VM) comprises software that executes on a guest partition of a hosting computer system to generally act as if it was an independent physical machine. A computer system may host multiple virtual machines, each running on a virtual machine monitor (VMM), also referred to as a hypervisor, that controls the sharing of the computer system's resources among the virtual machines. Typically virtual machines are run to utilize a physical machine's hardware resources more fully than can be done by conventional programs, and/or to run different operating systems on the same physical machine at the same time.
Virtual machines are becoming more and more prevalent, and, like any computer system, virtual machines are vulnerable to malicious software, or malware. As such, there exists a need for antimalware products to protect them. This may be accomplished by running traditional antimalware software on each guest partition.
However, there are drawbacks to operating this way, including that antimalware components are duplicated on each guest partition, whereby each partition consumes network, memory, and CPU resources for the antimalware components. Further, guest antimalware products cannot take advantage of virtual machine services, such as the ability to snapshot or roll back.
This Summary is provided to introduce a selection of representative concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used in any way that would limit the scope of the claimed subject matter.
Briefly, various aspects of the subject matter described herein are directed towards a technology by which an antimalware scanning mechanism (e.g., scanning components) are shared by a plurality of guest partitions that correspond to virtual machines in a virtual machine environment. To this end, guest partitions may include a guest antimalware agent that communicates with the scanning mechanism to use its shared antimalware scanning resources and shared antimalware scanning functionality. For example, the resources of the antimalware scanning mechanism may include antimalware signatures, so that each partition need not maintain its own signatures. The shared antimalware scanning functionality may comprise (e.g., code that performs) scanning of data such as objects (e.g., files) that are received from the guest antimalware agents. To leverage the capabilities of the guest operating system, the guest antimalware agents may execute instructions provided by the antimalware scanning component to collect additional scanning or telemetry information, or take remedial actions against detected malware.
In one aspect, a management component is coupled to the antimalware scanning mechanism so as to provide virtual machine management services to the antimalware scanning mechanism. For example, the antimalware scanning mechanism may communicate with the management component to pause a guest partition, resume a guest partition, snapshot a guest partition, or rollback a guest partition to a previous snapshot. The management component may also provide shared orchestration for scanning any guest partition.
In one implementation, the antimalware scanning mechanism resides in a guest partition that is separate from the other guest partitions that share the antimalware scanning mechanism. In an alternative implementation, the antimalware scanning mechanism resides on the root partition of the virtual machine environment.
Other advantages may become apparent from the following detailed description when taken in conjunction with the drawings.
The present invention is illustrated by way of example and not limited in the accompanying figures in which like reference numerals indicate similar elements and in which:
Various aspects of the technology described herein are generally directed towards an efficient way to protect virtual machines from malware, in which each virtual machine runs on a guest partition. In one implementation, the antimalware software is divided into separate components, including a lightweight agent, a shared scanning and signature update component, and a management component. An agent runs on supported guest partitions and provides real-time and online operating system interaction services. The scanning and signature update component, which may reside on a separate guest partition or the root partition, is configured to be used by each of the other guest agents. The management component provides centralized reporting and access to virtual machine services, and, for example, may reside on the root partition.
As will be understood, the technology described herein provides centralized anti-malware capabilities for multiple guest virtual machines in a virtual machine environment via the shared scanning component. This facilitates real-time antimalware protection by directing scan requests to the shared scanning component, including possibly on-demand scans and remediation on guest partitions, e.g., through the use of simple scripts provided by shared scanning component.
Moreover, the management component, by running on the root partition, provides pause/resume/snapshot/rollback and inspection services for the scanning component. This facilitates on-demand scans and remediation on guest partitions by the scanning component without the direct cooperation of the guest agent (e.g., if the guest agent is compromised or unavailable), while the guest partitions are paused via the management component, or while the guest is not running (offline), which may be used to detect malware that has stealth or protection capabilities from the perspective of the guest agent.
It should be understood that any of the examples herein are non-limiting. For example, while scanning of objects such as files is described, security evaluation of other content, such as for network intrusion protection, data leakage, guest verification and so forth may benefit from the technology described herein. As such, the present invention is not limited to any particular embodiments, aspects, concepts, structures, functionalities or examples described herein. Rather, any of the embodiments, aspects, concepts, structures, functionalities or examples described herein are non-limiting, and the present invention may be used various ways that provide benefits and advantages in virtual computing and/or protection against malware in general.
In general, the root partition 112 comprises a running operating system environment from which the state of other virtual machine guest partitions 106 and 1141-114m may be controlled. Each guest partition 106 and 1141-114m corresponds to any virtual machine or machine partition that is not the root partition 112.
Each guest partition 1141-114m for which real-time antimalware support is provided includes a respective guest agent 1161-116m, comprising software that provides real-time protection services for that guest partition, possibly along with other services. Each guest agent 1161-116m is specific to the operating system being run on its respective guest partition 1141-114m. Note that although not shown in
In order to protect guest agents from being tampered with by malicious code that successfully compromises a guest partition, a “privileged” protection component, (e.g., running inside the root partition or a dedicated security virtual machine) may monitor the integrity of the guest agent and other relevant components of guest virtual machine.
Each guest agent (e.g., 1161) provides real-time system monitoring with the capability to detect and block access to objects. To this end, the guest agent 1161 communicates bi-directionally (e.g., at high speed) with the scanning guest partition 106. Note that any communication mechanism is feasible, such as through the root partition, through a simulated network interface and so forth; however in one implementation communication is over a high-speed bus or shared memory block that exists between the partitions. Any guest agent (e.g., 1161) may be configured with a user interface, such as if guest partitions are often used interactively. Such a user interface may provide an interactive user of the guest visibility into the current security state of the guest, or allow an interactive user to request that the antimalware component begin a specific on-demand scan.
Each guest agent such as the agent 1161 may be (optionally) configured with the ability to run simple scripts, e.g., provided by the scanning guest partition 106 over a suitable bi-directional communication mechanism as generally described herein. Configuring the agents with the ability to run scripts avoids the need for the agent to be coded with its own logic with respect to making decisions on what to scan, what to do when malware is detected, and the like. For example, to scan a guest partition's files, a script may request that the agent feed its files or some subset thereof to the antimalware scanning mechanism 104, which scans them, may perform some needed remediation such as to clean a file, and may return results of the scanning/remediation to the agent, including a script with actions to take, e.g., files to delete or quarantine. Such scripts may include the ability to touch resources (e.g., triggering real-time transport protocol capabilities), and also to modify or terminate/delete resources.
The antimalware scanning mechanism 104 performs scanning, remediation, signature update operations, and in general enforces antimalware aspects of security policy with the cooperation of the guest agent and/or the management components. In general, the antimalware scanning mechanism 104 provides antimalware scanning as a service to the guest agents 1161-116m. Further, the antimalware scanning mechanism 104 also may initiate scanning or remedial actions against a guest partition, such as cooperatively using services of the guest agent, or alternatively without the guest partition's knowledge or consent, (e.g., while the guest partition is paused/offline), through the support of the management component 108.
With respect to real-time monitoring, the antimalware scanning mechanism 104 communicates bi-directionally with the guest agents 1161-116m, including in one implementation to identify any malware in content transmitted from the guest partitions. In general, for real-time monitoring, each agent feeds data such as an object set (comprising one or more objects such as files, registry data, processes or the like) to the antimalware scanning mechanism 104, which then evaluates the data against antimalware signatures, and returns a result, possibly taking a remedial action (e.g., cleaning the object) and/or including scripted instructions for the agent to take a remedial action (e.g., remove a file or quarantine a file), such as via a script.
Note that it is feasible to provide some or all of the guest agents 1161-116m with some scanning capabilities/intelligence themselves, rather than have them simply forward objects and receive and act on scripted results. For example, if a particular virus is currently widespread, the antimalware scanning mechanism 104 may provide the guest agent with a subset of signatures to look for with respect to a given file or file type, whereby the guest agent can handle scanning or remediation itself in the event such a file is encountered. This may be via a script, and/or possibly to some extent by coding basic scanning functionality into the agent.
Another benefit of the shared scanning mechanism 104 is that signatures as well as other scanning components may be updated, without experiencing significant scanning downtime. Further, information may be uploaded to a remote location, such as data, reports and sample object submission for subsequent analysis and so forth. This aspect of the shared scanning mechanism 104 is represented in
Moreover, the remote access capabilities of the antimalware scanning mechanism 104 may include communicating with a shared “cloud scanning” service for a decision (infected or clean) on suspicious content not yet matched by signatures. The antimalware scanning mechanism 104 may make such queries on behalf of multiple guests, such that guests get the benefit of the cloud service without needing Internet access directly. Also, the antimalware scanning mechanism 104 may cache the results, so that it only has to make one request to the cloud service even if multiple guests are seeing the same suspicious content.
The antimalware scanning mechanism 104 also has a communication link with the antimalware management component 108. As described above, this provides the antimalware scanning mechanism 104 with the ability to integrate antimalware scanning with virtual machine management capabilities. For example, the antimalware scanning mechanism 104 may request that the management component 108 pause a guest partition, thereby providing the scanning mechanism 104 with the ability to scan a guest partition (or a snapshot thereof) offline, and/or with the ability to manipulate offline guest partition (or a snapshot thereof) to remove malware. Offline scanning may be performed if a serious problem is detected, that is, reactively, such as if the guest has crashed, or if an operating system file that cannot be cleaned is infected, but cannot be replaced online because the file is needed to run the operating system. Offline scanning also may be performed proactively, e.g., before staring a guest partition; if a partition is known to be free of infections at startup, but then becomes infected while running, a rapid diagnosis may be made. This integration capability also provides the ability to perform scans and remediation on guests not supported by a guest agent.
The management component 108 thus comprises a component with access to the virtual machine management services 110. In the exemplified implementation of
Further, the management component 108 is able to act as a centralized collection point and intermediary for communication to and from the security management console 109. The management component 108 may provide the scanning partition 106 with the online ability to manipulate guest partitions, including the ability to stop an infected guest, or revert a guest partition to a snapshot. The management component 108 may provide the scanning mechanism 104 with the ability to manipulate a guest partition offline.
Note that although the management component 108 has access to the virtual machine management services 110, along with the ability to coordinate with the scanning mechanism 104, and the ability to report (and potentially be reconfigured) by any central security management services, the management component 108 is a distinct component from virtual machine management, antimalware management, and the scanning mechanism 104. The management component 108 need not even be on the same computer system as these components, as long as they can communicate, e.g., over network connections. However, deploying the management component 108 on the root partition 112 (as exemplified in
As shown in
In an alternative implementation, as generally represented in
By way of summary,
Steps 306-318 represent example actions performed by and from the perspective of the antimalware scanning mechanism, in which the agent relies on the antimalware scanning mechanism for the scan. Step 306 represents providing information such as a script to the agent. In a scan that is not a real-time scan, the script may identify what files, folders, or other operating system resources to provide for scanning, what file types to provide, and so forth. In a real time scan, the information may be an instruction or the like informing the agent that scanning is turned on, and that the agent is to provide each appropriate object to the antimalware scanning mechanism for real time scanning.
Step 308 represents the agent providing data such as an object set (e.g., one or more files, registry data or other data blobs) to the antimalware scanning mechanism, which receives it for scanning, as represented by step 310. If the data contains malware, step 312 takes action with respect to that data as represented by step 314. As described above, this may be by performing remediation in the antimalware scanning mechanism, e.g., cleaning data before returning it, and/or constructing a result that instructs the agent to take some remediation action (e.g., remove a file, quarantine a file, write a cleaned file back).
Note that sometimes, malware cannot be cleaned from a compromised virtual machine. In a computer system that is not configured as a virtual environment, human operator intervention is needed, usually by reinstalling a machine. However in a virtual environment, a management component can automatically (possibly after asking for administrator approval) restore the virtual machine to a previous known good snapshot, or by rebuilding a virtual machine image.
Step 316 returns the result to the agent, which may include a script of one or more actions for the agent to perform, and/or a request for the next set of data. Step 318 represents ending the scanning process if the scan is complete, or continuing the scanning process if more scanning is needed, either because there is at least one more set of data to scan, or because the scan is a real time monitoring operation, which continues indefinitely by waiting for the next set of data.
When complete, steps 414 and 416 are performed by the management component 108 to restore the guest partition to an online state. e.g., as requested by the antimalware scanning mechanism 104.
One of ordinary skill in the art can appreciate that the various embodiments and methods described herein can be implemented in connection with any computer or other client or server device, which can be deployed as part of a computer network or in a distributed computing environment, and can be connected to any kind of data store or stores. In this regard, the various embodiments described herein can be implemented in any computer system or environment having any number of memory or storage units, and any number of applications and processes occurring across any number of storage units. This includes, but is not limited to, an environment with server computers and client computers deployed in a network environment or a distributed computing environment, having remote or local storage.
Distributed computing provides sharing of computer resources and services by communicative exchange among computing devices and systems. These resources and services include the exchange of information, cache storage and disk storage for objects, such as files. These resources and services also include the sharing of processing power across multiple processing units for load balancing, expansion of resources, specialization of processing, and the like. Distributed computing takes advantage of network connectivity, allowing clients to leverage their collective power to benefit the entire enterprise. In this regard, a variety of devices may have applications, objects or resources that may participate in the resource management mechanisms as described for various embodiments of the subject disclosure.
Each computing object 510, 512, etc. and computing objects or devices 520, 522, 524, 526, 528, etc. can communicate with one or more other computing objects 510, 512, etc. and computing objects or devices 520, 522, 524, 526, 528, etc. by way of the communications network 540, either directly or indirectly. Even though illustrated as a single element in
There are a variety of systems, components, and network configurations that support distributed computing environments. For example, computing systems can be connected together by wired or wireless systems, by local networks or widely distributed networks. Currently, many networks are coupled to the Internet, which provides an infrastructure for widely distributed computing and encompasses many different networks, though any network infrastructure can be used for exemplary communications made incident to the systems as described in various embodiments.
Thus, a host of network topologies and network infrastructures, such as client/server, peer-to-peer, or hybrid architectures, can be utilized. The “client” is a member of a class or group that uses the services of another class or group to which it is not related. A client can be a process, e.g., roughly a set of instructions or tasks, that requests a service provided by another program or process. The client process utilizes the requested service without having to “know” any working details about the other program or the service itself.
In a client/server architecture, particularly a networked system, a client is usually a computer that accesses shared network resources provided by another computer, e.g., a server. In the illustration of
A server is typically a remote computer system accessible over a remote or local network, such as the Internet or wireless network infrastructures. The client process may be active in a first computer system, and the server process may be active in a second computer system, communicating with one another over a communications medium, thus providing distributed functionality and allowing multiple clients to take advantage of the information-gathering capabilities of the server.
In a network environment in which the communications network 540 or bus is the Internet, for example, the computing objects 510, 512, etc. can be Web servers with which other computing objects or devices 520, 522, 524, 526, 528, etc. communicate via any of a number of known protocols, such as the hypertext transfer protocol (HTTP). Computing objects 510, 512, etc. acting as servers may also serve as clients, e.g., computing objects or devices 520, 522, 524, 526, 528, etc., as may be characteristic of a distributed computing environment.
As mentioned, advantageously, the techniques described herein can be applied to any device. It can be understood, therefore, that handheld, portable and other computing devices and computing objects of all kinds are contemplated for use in connection with the various embodiments. Accordingly, the below general purpose remote computer described below in
Embodiments can partly be implemented via an operating system, for use by a developer of services for a device or object, and/or included within application software that operates to perform one or more functional aspects of the various embodiments described herein. Software may be described in the general context of computer executable instructions, such as program modules, being executed by one or more computers, such as client workstations, servers or other devices. Those skilled in the art will appreciate that computer systems have a variety of configurations and protocols that can be used to communicate data, and thus, no particular configuration or protocol is considered limiting.
With reference to
Computer 610 typically includes a variety of computer readable media and can be any available media that can be accessed by computer 610. The system memory 630 may include computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) and/or random access memory (RAM). By way of example, and not limitation, system memory 630 may also include an operating system, application programs, other program modules, and program data.
A user can enter commands and information into the computer 610 through input devices 640. A monitor or other type of display device is also connected to the system bus 622 via an interface, such as output interface 650. In addition to a monitor, computers can also include other peripheral output devices such as speakers and a printer, which may be connected through output interface 650.
The computer 610 may operate in a networked or distributed environment using logical connections to one or more other remote computers, such as remote computer 670. The remote computer 670 may be a personal computer, a server, a router, a network PC, a peer device or other common network node, or any other remote media consumption or transmission device, and may include any or all of the elements described above relative to the computer 610. The logical connections depicted in
As mentioned above, while exemplary embodiments have been described in connection with various computing devices and network architectures, the underlying concepts may be applied to any network system and any computing device or system in which it is desirable to improve efficiency of resource usage.
Also, there are multiple ways to implement the same or similar functionality, e.g., an appropriate API, tool kit, driver code, operating system, control, standalone or downloadable software object, etc. which enables applications and services to take advantage of the techniques provided herein. Thus, embodiments herein are contemplated from the standpoint of an API (or other software object), as well as from a software or hardware object that implements one or more embodiments as described herein. Thus, various embodiments described herein can have aspects that are wholly in hardware, partly in hardware and partly in software, as well as in software.
The word “exemplary” is used herein to mean serving as an example, instance, or illustration. For the avoidance of doubt, the subject matter disclosed herein is not limited by such examples. In addition, any aspect or design described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects or designs, nor is it meant to preclude equivalent exemplary structures and techniques known to those of ordinary skill in the art. Furthermore, to the extent that the terms “includes,” “has,” “contains,” and other similar words are used, for the avoidance of doubt, such terms are intended to be inclusive in a manner similar to the term “comprising” as an open transition word without precluding any additional or other elements when employed in a claim.
As mentioned, the various techniques described herein may be implemented in connection with hardware or software or, where appropriate, with a combination of both. As used herein, the terms “component,” “module,” “system” and the like are likewise intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution. For example, a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on computer and the computer can be a component. One or more components may reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers.
The aforementioned systems have been described with respect to interaction between several components. It can be appreciated that such systems and components can include those components or specified sub-components, some of the specified components or sub-components, and/or additional components, and according to various permutations and combinations of the foregoing. Sub-components can also be implemented as components communicatively coupled to other components rather than included within parent components (hierarchical). Additionally, it can be noted that one or more components may be combined into a single component providing aggregate functionality or divided into several separate sub-components, and that any one or more middle layers, such as a management layer, may be provided to communicatively couple to such sub-components in order to provide integrated functionality. Any components described herein may also interact with one or more other components not specifically described herein but generally known by those of skill in the art.
In view of the exemplary systems described herein, methodologies that may be implemented in accordance with the described subject matter can also be appreciated with reference to the flowcharts of the various figures. While for purposes of simplicity of explanation, the methodologies are shown and described as a series of blocks, it is to be understood and appreciated that the various embodiments are not limited by the order of the blocks, as some blocks may occur in different orders and/or concurrently with other blocks from what is depicted and described herein. Where non-sequential, or branched, flow is illustrated via flowchart, it can be appreciated that various other branches, flow paths, and orders of the blocks, may be implemented which achieve the same or a similar result. Moreover, some illustrated blocks are optional in implementing the methodologies described hereinafter.
While the invention is susceptible to various modifications and alternative constructions, certain illustrated embodiments thereof are shown in the drawings and have been described above in detail. It should be understood, however, that there is no intention to limit the invention to the specific forms disclosed, but on the contrary, the intention is to cover all modifications, alternative constructions, and equivalents falling within the spirit and scope of the invention.
In addition to the various embodiments described herein, it is to be understood that other similar embodiments can be used or modifications and additions can be made to the described embodiment(s) for performing the same or equivalent function of the corresponding embodiment(s) without deviating therefrom. Still further, multiple processing chips or multiple devices can share the performance of one or more functions described herein, and similarly, storage can be effected across a plurality of devices. Accordingly, the invention is not to be limited to any single embodiment, but rather is to be construed in breadth, spirit and scope in accordance with the appended claims.
