Patent Application
20070006304
The speed with which malware can infect massive numbers of networked devices before being detected presents numerous challenges in defending against malware attacks. Servers that host content or other types of shared storage resources are particularly at risk of receiving infected files from attached clients. For example, a client may attach to a server and inadvertently deposit an infected file on the server's resources even if attached for only a short period of time. The server has no way to trace the client from which the infected file was received. Even if subsequently disinfected, the next time the client attaches to the server it may be re-infected if the infected file remains on the server. Other clients accessing the server could also get infected even though the client from which the infected file was received has detached. Even clients protected by anti-virus software may propagate viruses in this way if the software is not up-to-date, or if the client is infected with new viruses for which anti-virus signatures are not yet available.
One of the previously accepted approaches to this problem is to have the client's anti-virus software scan the attached file servers to disinfect them. However, this approach is not reliable, since there is no guarantee that the client has any file server shares mounted at the time that the infection is discovered. Another is to have the server's anti-virus software continuously scan all of the files on the server every time a new signature becomes available. However, given the large number of files that typically reside on a server, such indiscriminant scanning may be too resource-intensive and thus impractical, especially since signatures may be updated daily, or even several times a day.
The foregoing problems with the prior state of the art are overcome by the principles of the present invention, which is directed toward methods, systems, computer program products, and data structures for optimizing recovery from malware attacks on devices within a trust boundary.
According to one aspect of the invention, malware recovery optimization monitors malware detection processes on a device for events indicating a breach of security of the device, such as the presence of an infection or other evidence of a malware attack. The malware detection processes include but are not limited to anti-virus software and other types of malware behavior trigger engines that detect breaches of security of a device.
According to another aspect of the invention, malware recovery optimization notifies a centralized event collector when an event occurs indicating a breach of security. Notification may be performed by causing the device to report information to the centralized event collector about each event that occurs, including but not limited to, any available identification of the malware attack that caused the event to occur, the name of the device that was attacked, and the time that the attack actually or likely occurred. In some cases, the reported event information may further include the names of other devices and/or resources within the trust boundary that might also have been compromised as a result of the malware attack. For example, the reported event information may indicate the names of servers and files to which a client was attached.
According to one other aspect of the invention, malware recovery optimization may also monitor malware detection processes on a device for events indicating a breach of security during a protocol exchange between the device and another device using file sharing and other types of communication protocols, including various electronic mail and internet related protocols. During the protocol exchange, malware recovery optimization may monitor malware detection processes and protocol processes on one device as applied to communications received from another device. Monitoring the malware detection processes during a protocol exchange may be particularly advantageous when the malware detection processes on the device from which the messages are received are either non-existent or inadequate to detect the newest types of malware attacks. Similar to monitoring malware detection processes on a device for events indicating a breach of security of the device, when monitoring protocol processes malware recovery optimization notifies the centralized event collector when an event occurs indicating a breach of security during a protocol exchange.
According to one other aspect of the invention, the centralized event collector alerts some or all of the other devices within the trust boundary about each reported event in accordance With an alert configuration. The alert configuration may include rules for generating alerts that are implicitly derived from or explicitly specified by devices that have registered with the centralized event collector to receive alerts from some or all of the devices within a trust boundary. In some cases, the event collector may send alerts only to devices that have registered to receive alerts. In other cases, the event collector may send alerts only to devices that may have been compromised as a result of the malware attack, such as the servers that were attached to the client that is reporting the event. In yet other cases, the event collector may broadcast alerts to all devices within the trust boundary, such as all devices on a network. The centralized event collector may further provide an application programming interface (API) to facilitate the reporting of events to the event collector from devices, as well as to facilitate the receipt of alerts issued from the event collector to devices.
According to one other aspect of the invention, a device may receive an alert that an event was reported by another device within the trust boundary indicating a breach of security, such as the discovery of an infection or other evidence of a malware attack on the reporting device. Upon receipt of the alert, the receiving device may initiate malware recovery optimization to assess whether the breach of security on the reporting device may have also compromised the receiving device and/or resources. For example, malware recovery optimization may cause a file server to consult a server log file to determine whether the reporting client had access to files on the file server after the malware attack occurred, which could indicate that those files may have been compromised.
According to yet another aspect of the invention, after determining that the receiving device and/or resources may have been compromised, malware recovery optimization activates the receiving device's malware detection processes to begin the process of malware recovery. For example, malware recovery optimization may activate the receiving device's anti-virus software to initiate a targeted scan of those resources that may have been compromised. In this manner, malware recovery processes are optimized to recover, rollback, disinfect, or quarantine the receiving device and/or resources when indicated.
According to yet another aspect of the invention, in some cases the determination that the receiving device and/or resources on the receiving device may have been compromised can be made by the device that reports the event, and/or the centralized event collector that issues the alert. For example, in some cases a client may be able to identify in the reported event information which servers and files the client attached or accessed, and thus possibly compromised, subsequent to the malware attack. In other cases, the event collector may determine whether a registered server may have been compromised as a result of a malware attack reported by a client based on information that the server previously provided to the event collector at the time the server registered with the event collector. In this manner, the event collector may issue alerts that are properly targeted to those receiving devices that need them so that malware recovery processes are further optimized to recover, rollback, disinfect, or quarantine the receiving device and/or resources when indicated.
In accordance with yet other aspects of the present invention, a computer-accessible medium for malware recovery optimization is provided, including a medium for storing data structures and computer-executable components for malware recovery optimization functionality and a centralized security event collector. The data structures define the application programming interfaces and/or protocols to report events to the event collector and to issue alerts from the event collector in a manner that is generally consistent with the above-described systems and methods. Likewise, the computer-executable components are capable of performing malware recovery optimization functions that are generally consistent with the above-described systems and methods.
The foregoing aspects and many of the attendant advantages of this invention will become more readily appreciated as the same become better understood by reference to the following detailed description, when taken in conjunction with the accompanying drawings, wherein:
The speed with which networked devices can be attacked with malware as well as the large number of files that may be exposed to such attacks in a typical file server environment suggests that it would be beneficial to optimize the malware recovery process. In the following discussion, a computing system that is suitable for implementing malware recovery optimization in accordance with embodiments of the present invention is described in detail. Optimization is achieved by initiating malware recovery of a device after determining that the device may have been compromised by a breach of security within the trust boundary, as opposed to every time the device attaches to another device, or a new anti-virus signature becomes available. Optimization is also achieved by targeting the malware recovery of a device, where the targeting narrows down the extent of the resources on the device which need to be scanned, searched, examined and remedied. Among other advantages, optimization provides devices with the ability to better respond to a malware attack so that fewer devices and files are exposed to the attack.
In one embodiment, other devices within the trust boundary 102 may operate without having the recovery optimizer process 106, such as the illustrated devices Device D 114 and Device G 120, and the aforementioned Device E 116. Devices without the recovery optimizer process 106 may co-exist with the devices that do have the recovery optimizer process 106; however, they may not be able to benefit from or participate in optimized recovery other than the fact of their co-existence with devices that do have the recovery optimizer process 106 and which are, therefore, less susceptible to attack and better able to quickly recover from an attack.
In a typical embodiment, the recovery optimizer process 106 operates in conjunction with the device on which it resides and/or any of the device's malware detection processes 108 to monitor events indicating a breach of security of the device, such as the presence of malware objects indicating an infection, or other evidence of a malware attack, including the presence of malware in memory. When such an event occurs, the recovery optimizer process 106 causes the device in which the event occurred to report the event to a security event collector 122. For example, in the illustrated embodiment, Device A 104 may discover through its malware detection processes 108 that a security breach 128 has occurred. The recovery optimizer process 106 monitors the discovery of an event indicating the security breach 128 by the malware detection processes 108 and causes Device A 104 to notify 124 the security event collector 122. The security event collector 122, in turn, issues an alert 126 about the event to some or all of the other devices, Devices B-G, 110, 112, 114, 116, 118, and 120, within the trust boundary so that they can take actions to protect themselves from a breach of security that might occur, or to recover from a breach of security that may have already occurred, as a result of the security breach 128 on Device A.
In a typical embodiment, the recovery optimizer process 106 further operates in conjunction with the device on which it resides and/or any of the device's malware detection processes 108 to receive and process alerts of events indicating a breach of security within the trust boundary 102, such as the security breach 128 on Device A. When such an alert is received from the centralized event collector 122, the recovery optimizer process 106 causes the device in which the alert was received to conduct a self assessment to determine whether the device may have been compromised as a result of the alerted event. The self-assessment may be conducted using just the event information provided in the alert, and/or in conjunction with other information that may be available to the device, such as a history of the device's interactions with the device from which the event originated. For example, in the client/file server context, a server may conduct a self-assessment upon receipt of an alert about an event on a client using a log file documenting the server's interactions with the client, as will be described in further detail with reference to
In a typical embodiment, the devices A-G, 104, 110, 112, 114, 116, 118, and 120 report events and receive alerts issued by the security event collector 122 through an application programming interface (API) to the event collector, as will be described in further detail with reference to
The ABC file server 216 has registered 222 with the security event collector 122 to receive events from the event collector 122, as evidenced in the alert configuration 212 having a rule 214 to alert the ABC file server 216 about events reported by the XYZ client 202. Accordingly, the security event collector 122 issues an alert 224 about the event on the XYZ client 202 to the ABC file server 216.
In a typical embodiment, upon receipt of the alert 224, the recovery optimizer process 220 on the ABC file server 216 conducts an assessment of whether its resources may have been compromised as a result of the event reported by the XYZ client 202. In the illustrated example, the resources that may have been compromised include three file shares maintained in the ABC file server 216, namely file share A 232A, file share B 232B, and file share C 232C. In one embodiment, the recovery optimizer process 220 on the ABC file server 216 performs the assessment by consulting a server log file 226 in which exists a map 228 of the various clients that it serves and the resources that those clients may access. From the map 228, the recovery optimizer process 220 determines that file share B 232B is a resource that may have been compromised. Accordingly, the recovery optimizer 220 operates in conjunction with the anti-virus software 218 on the ABC file server 216 to initiate a targeted scan 230 of file share B 232B. As illustrated, the scan 230 of file share B 232B will reveal that the MyDoom virus 234 is present, evidence that the file share B has, in fact, been compromised.
In a typical embodiment, the ABC file server 216 then operates in conjunction with the anti-virus software 218 to take the appropriate actions to recover, disinfect, quarantine or rollback the compromised file share B 232B and/or the ABC file server 216 so that other clients and servers are not at risk of being compromised by accessing file share B 232B. In this manner, the malware recovery optimization system 200 is able to quickly recover from the MyDoom attack, and prevent the spread of the MyDoom virus 234 to other client and server devices that may attach to the ABC file server 216.
In the above-described client/file server example, it should be understood that the recovery optimizer process 220 may employ other methods of conducting an assessment of whether a device, such as the ABC file server 216, and/or its resources have been compromised without departing from the claims that follow. For example, in some embodiments, the information that a reporting device, such as the XYZ client 202, reports about an event may include all of the information that the receiving device, such as the ABC file server 216, needs in order to make that assessment, in this case the identification of the ABC file server as a device that should be alerted, and/or the identification of file share B 232B as a resource that may have been compromised. In some embodiments, the information that the receiving device needs to make that assessment may be determined, at least in part, by the security event collector 122 that issued the alert. For example, the determination of which file server should be issued an alert may be determined by the security event collector 122 using the information provided by the devices that registered with the collector 122 to receive alerts about events from certain other devices, such as the information provided by the ABC file server 216 when it registered with the event collector 122 to receive alerts about events from the XYZ client 202 as indicated in the alert configuration 212 and rule 214.
In a typical embodiment, upon receipt of the message 324, the security event API 326 reports the information about the event by serving security event messages 328 to a security event collector 122. The security event collector 122 is in communication with the Network 310, and similarly to the security event collector described with reference to
In the above-described protocol example described in
Further, with reference to both
Still further, not all of the components described in
Turning now to
In a typical embodiment, the method 400A continues at process block 410 to report the generated event data to a centralized event collector. In one embodiment, reporting the generated event data may be performed through an event collector API and/or in accordance with a protocol used to communicate between the devices and the event collector. After reporting the event data, the method 400A continues to monitor the device for events at processes 404 and decision block 406.
In a typical embodiment, the method 400B continues at process block 418 in which a device receives an alert issued by the centralized event collector about a security event on another device within the trust boundary shared with the receiving device. Using the example described in
Upon receipt of the alert, the method 400B continues at decision block 420 to make an assessment whether the receiving device may have been compromised as a result of the reported event. In one embodiment, the method 400B makes this assessment by determining whether the reporting device, i.e., the device on which the event occurred, had access to the receiving device after the event occurred. In such cases, the receiving device may consult additional historical information, such as a server log file 226, in order to make the determination. In other cases, the receiving device may make the determination from the information reported about the event alone, without having to consult any additional information. Either way, if the receiving device determines that it may have been compromised, then the method 400B continues at decision block 422 to continue the assessment. For example, at decision block 422, the receiving device may determine whether any resources on the device may have been compromised as a result of the reported event. Again, the receiving device may consult additional historical information, such as the server log file 226, or may make the determination from the information reported about the event alone.
In a typical embodiment, should the receiving device determine that any of its resources may have been compromised as a result of the reported event, then the method 400B continues at process block 424 to initiate a targeted scan of the resources that were determined to be at risk of having been compromised. For example, the method 400B may cause anti-virus software on the receiving device to scan the at risk resources and to recover, rollback, disinfect, or quarantine the device and/or at risk resources as appropriate, and to end processing and termination oval 426.
Turning now to
In a typical embodiment, at process block 506 the method 500 may optionally configure alerts by generating an alert configuration 212. The alert configuration 212 may include, among other data, rules for issuing alerts to devices about events that have been collected by the centralized event collector. In one embodiment, the rules may be derived from the registration requests received in process block 504. For instance, if a file server device has registered to receive alerts from specified client devices, then rules may be generated to insure that the event collector issues alerts to the file server device about events reported by any or all of the specified client devices, as was described in the example in
In a typical embodiment, the method 500 continues at process block 508 to receive in a centralized event collector reports of security events from reporting devices. The reports that are received may include various information about an event, such as the device ID of the device in which the event occurred, the file ID of files associated with the event, the threat ID associated with the event, the time that the event likely occurred, and so forth. In one embodiment, the information may be reported via a centralized security event API and/or in accordance with a particular protocol.
In one embodiment, the method 500 continues at decision block 510 in which the centralized event collector makes a determination in conjunction with the alert configuration 212 about whether to issue an alert about an event that was reported. In no alert is issued, the method 500 continues a processing oval 512 to return to oval 502 and continue to register devices and receive events reported from devices. If an alert is to be issued, the method 500 continues at process block 514 to issue a broadcast or targeted alert about a reported event to some or all devices that may be interested in the event in accordance with the alert configuration 212. In one embodiment, those devices that may be interested in the event may include those devices that have explicitly registered to receive alerts about events reported by specified devices, as well as those devices which may have been compromised as a result of the reported event, regardless of whether the device has registered to receive such alerts. The determination about the devices to which alerts should be issued may vary from one implementation to the next, and in some cases may be dictated by the information that the reporting device reports about the event. For example, in some cases the device that reported the event may be able to identify in the information reported about the event, the other devices within the trust boundary that may have been compromised as a result of the event. The method 500 concludes processing at termination oval 516.
In the foregoing discussion, a computing system suitable for implementing various features of malware recovery optimization in accordance with embodiments of the invention includes, for example, a personal computer usable in a distributed computing environment, in which complementary tasks may be performed by remote computing devices linked together through a communication network. However, those skilled in the art will appreciate that embodiments of the invention may be practiced with many other computer system configurations. For example, embodiments of the invention may be practiced with a personal computer operating in a standalone environment, or with multiprocessor systems, minicomputers, mainframe computers, and the like. In addition, those skilled in the art will recognize that embodiments of the invention may be practiced on other kinds of computing devices including laptop computers, tablet computers, personal digital assistants (PDAs), cell phones, game consoles, personal media devices, or any device upon which computer software or other digital content is installed.
For the sake of convenience, some of the description of the computing system suitable for implementing various features of the invention may have included references to the Windows operating system, and/or references to various other Microsoft products. However, those skilled in the art will recognize that those references are only illustrative and do not serve to limit the general application of embodiments of the invention. For example, embodiments of the invention may be practiced in the context of other operating systems such as the LINUX or UNIX operating systems, and other general-purpose software.
Certain aspects of embodiments of the invention have been described in terms of programs executed or accessed by an operating system in conjunction with a personal computer. However, those skilled in the art will recognize that those aspects also may be implemented in combination with various other types of program modules or data structures. Generally, program modules and data structures include routines, subroutines, programs, subprograms, methods, interfaces, processes, procedures, functions, components, schema, etc., that perform particular tasks or implement particular abstract data types.
Lastly, while numerous embodiments of the invention have been illustrated and described, it will be appreciated that various changes can be made therein without departing from the scope of the claims that follow. For example, in one embodiment of the present invention, the functionality of the various components of a system for optimizing recovery from a malware attack may be implemented in different combinations of processes, programs, interfaces, and repositories, and may be distributed across one or more computing devices. For example, with reference to
