Abstract:
Computer implement methods, apparati, and computer-readable media for enabling a first computer ( 12 ) to determine that it is safe to communicate with a second computer ( 10 ) coupled to the first computer ( 12 ) over a network ( 15 ). In a method embodiment of the present invention, the first computer ( 12 ) detects ( 21 ) that the second computer ( 10 ) has initiated a test open of a file ( 14 ) associated with the first computer ( 12 ). When the test open is followed by an actual open command by which the second computer ( 10 ) seeks to actually open the same file ( 14 ), the first computer ( 12 ) determines ( 23 ) that it is safe to communicate with the second computer ( 10 ).

Description:
RELATED APPLICATION 
   This patent application claims priority upon commonly owned U.S. patent application Ser. No. 10/846,100 filed May 14, 2004, entitled “Opening Computer Files Quickly and Safely Over a Network”, which patent application is hereby incorporated by reference in its entirety into the present patent application. 
   TECHNICAL FIELD 
   This invention pertains to the field of protecting a computer coupled to a network from malicious code infections. 
   BACKGROUND ART 
   As used herein, “malicious computer code” is any code that enters a computer without the knowledge and/or consent of an authorized user of the computer and/or a system administrator of an enterprise incorporating the computer. Thus, “malicious computer code” encompasses, but is not limited to, viruses, worms, Trojan horses, spam, adware, and unwanted popups. The most common types of malicious code thwarted by the present invention are viruses, worms, and Trojan horses. 
   With reference to  FIG. 1 , when a computer  12  is running in a network environment, said computer  12  may be accessed by other computers  10  that are also coupled to the network  15 .  FIG. 1  illustrates a plurality n of such network computers  10 . Computers  10 , 12  may be part of an enterprise  1 , such as a corporation or university. n can be any positive integer. 
   When computer  12  is a server, it is particularly susceptible to being accessed by other computers  10 , because the raison d&#39;être of a server is to be so accessed. When computer  12  is a client computer, it may also be accessed by network computers  10  via file shares established between computer  12  and one or more network computers  10 . These file shares may have been established for legitimate business, academic, or governmental purposes. Interposing a firewall between computer  12  and the network  15  would not protect computer  12  from malicious code entering through one of these file shares, because the firewall would be programmed to intentionally allow communication between computer  12  and those computers  10  with which computer  12  is authorized to share files. It is desired to prevent a computer  10  that is infected with malicious code from modifying any files on computer  12 . Such a modification might damage the infected file, so that it may not be completely repairable, or not repairable at all; or the file could be completely deleted. It is also desired to minimize the coupling between computer  12  and a computer  10  that is unprotected. By “unprotected” is meant that such a computer  10  either does not have a malicious code scanning means, or else it has a malicious code scanning means but said means is ineffective, e.g., it contains outdated malicious code definitions. 
   Any one or more of computers  10 , 12  could be a laptop computer or a PDA (Personal Digital Assistant) that an employee of, or a vendor to, enterprise  1  has coupled to network  15 . Such computers  10 , 12  are capable of infecting other enterprise computers  10 , 12  with malicious code, and are also susceptible to themselves being infected with malicious code (e.g., by a third party), thus presenting dangers when they are coupled to network  15 . 
   The present invention protects computers  10 , 12  in a network environment, without imposing a high administrative burden in tracking down and protecting unprotected computers  10 , 12 . 
   DISCLOSURE OF INVENTION 
   Computer implement methods, apparati, and computer-readable media for enabling a first computer ( 12 ) to determine that it is safe to communicate with a second computer ( 10 ) coupled to the first computer ( 12 ) over a network ( 15 ). In a method embodiment of the present invention, the first computer ( 12 ) detects ( 21 ) that the second computer ( 10 ) has initiated a test open of a file ( 14 ) associated with the first computer ( 12 ). When the test open is followed by an actual open command by which the second computer ( 10 ) seeks to actually open the same file ( 14 ), the first computer ( 12 ) determines ( 23 ) that it is safe to communicate with the second computer ( 10 ). 

   
     BRIEF DESCRIPTION OF THE DRAWINGS 
     These and other more detailed and specific objects and features of the present invention are more fully disclosed in the following specification, reference being had to the accompanying drawings, in which: 
       FIG. 1  is a system level diagram illustrating a typical configuration of the prior art. 
       FIG. 2  is a flow diagram illustrating a method embodiment of the present invention. 
       FIG. 3  is a system level diagram illustrating items usable in the present invention. 
       FIG. 4  is a flow diagram illustrating a method by which computer  10  can safely and quickly open file  14  over network  15  by determining that computer  12  has acceptable malicious code scanning means  33 . 
   

   DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
   With reference to  FIG. 3 , computer  10  and computer  12  are coupled to each other over a network  15 . Computer  10  can be one of a plurality of network computers  10  as illustrated in  FIG. 1 . As used herein, “coupled” means any direct or indirect coupling by which computers  10  and  12  may communicate with each other. Network  15  can be any wired or wireless network, or any combination of wired and wireless networks. Thus, network  15  can comprise the Internet, a local area network (LAN), a wide area network (WAN), a WiFi network, a Bluetooth network, etc. Computers  10 , 12  can be any combination of server computers and client computers. Associated with computer  10  is malicious code scanning module  11 . This may be a real-time module that is capable of detecting malicious code within a computer file such as file  14  associated with computer  12 . A suitable example of module  11  is AutoProtect manufactured by Symantec Corporation of Cupertino, Calif. 
   Similarly, computer  12  may have associated therewith a malicious code scanning means  33 . As with scanning module  11 , scanning means  33  may be a real-time module capable of detecting malicious code in a computer file such as file  14 . Results of the scanning of file  14  by scanning means  33  may be placed into a scanned file cache  16 , which can be any type of memory device associated with computer  12 . 
   The broad method steps of the present invention may be performed by suitably modifying scanning means  33 . These modifications can be performed by one of ordinary skill in the software art. Alternatively, said method steps may be performed by one or more computational modules  39  associated with computer  12 , or by a combination of said computational modules  39  working in conjunction with scanning means  33 . Similarly, computer  10  can be fitted with special computational modules  38  suitable for use in the present invention, and/or scanning module  11  can be appropriately modified for use in the present invention. As a shorthand notation, whenever it is stated herein that computer  10  performs a certain action, it is meant that the action is performed by module  11  and/or modules  38 . Similarly, whenever it is stated herein that computer  12  performs a certain action, it is meant that said action is performed by scanning means  33  and/or modules  39 . All of the modules and means mentioned in this paragraph can be implemented in software, firmware, hardware, or any combination thereof. 
   A method embodiment of the present invention will now be described in conjunction with  FIG. 2 . The method starts at optional authentication step  20 , which will be described below. At step  21 , computer  12  detects that computer  10  seeks to initiate a test open of file  14 , i.e. the test open illustrated as step  41  in  FIG. 4 . 
   One technique by which computer  12  can detect such a test open in step  21  is to observe that computer  10  is requesting to open a dummy file having a pathname consisting of the pathname of file  14 , plus a tag appended to said file  14  pathname. The tag may comprise a globally unique identifier (GUID) of computer  10  (useful to identify computer  10  when computer  10  is but one of n computers in an enterprise  1 ) and the date that malicious code definitions  32  associated with malicious code scanning module  11  were last updated. The GUID can be based on the MAC (Message Authentication Code) associated with computer  10 . In this embodiment, the presence of the tag creates a pathname for a dummy file that is not likely to exist within the purview of computer  12 . Thus, computer  12  should not be able to open such a file. If remote computer  12  is able to open such a file, it indicates that something is wrong: perhaps a malicious individual is spoofing the system, or the presence of the tag has accidentally resulted in a valid pathname for a file other than file  14 . Thus, if computer  12  opens a file during the test open, in one embodiment computer  10  retries the test open by changing the GUID portion of the tag so that the augmented pathname does not correspond to an actual file  14 . 
   An example of a pathname of file  14  is: 
   C:\roberta\jake\ 
   In this example, the pathname augmented with a tag having a GUID of computer  10  and the most recent definitions  32  update date might be: 
   C:\roberta\jake8163412aug2003 
   The contents of the tag are tailored to preselected acceptability criteria by which computer  10  determines, in response to feedback received from computer  12 , whether computer  12  has an acceptable malicious code scanning means  33  (step  42 ). “Acceptability” can be defined in a number of ways, and is pre-determined prior to operation of the present invention. For example, an “acceptable” malicious code scanning means  33  can be defined to be one which satisfies one or more of the following criteria: the scanning means  33  is present, active (switched on), capable of scanning file  14 , contains malicious code definitions  37  that are at least as current as definitions  32  associated with malicious code scanning module  11 , has an acceptable definition window, scans all appropriate file extensions, has a heuristic level set to at least a certain amount, has any other settings that the means  33  is capable of. An “acceptable definition window” can be a time window such as “malicious code definitions are not more than a week old”. 
   If computer  10  determines that computer  12  has acceptable malicious code scanning means  33 , computer  12  scans file  14  (step  49 ), then computer  10  issues a command to actually open file  14  (step  43 ), relying on said scan by computer  12 . The rationale for this reliance is that if computer  12  has an acceptable malicious code scanning means  33 , there is no need for computer  10  to perform a slow, cumbersome malicious code scan on file  14  over network  15 . 
   If, on the other hand, computer  12  does not have an acceptable malicious code scanning means  33  from the point of view of computer  10 , computer  10  scans file  14  over the network  15  (step  44 ), since computer  10  cannot rely on any scanning of file  14  by computer  12 . Then computer  10  inquires (step  45 ) as to whether the result of the scan indicates that malicious code may be present within file  14 . If not, computer  10  initiates a command to actually open file  14  as before (step  43 ). 
   If, on the other hand, the above inquiry indicates that malicious code may be present within file  14 , computer  10  performs (step  46 ) at least one defensive measure from the group of measures comprising: a false positive mitigation technique; a verification that malicious code is in fact present within file  14 ; an alert to a system administrator for enterprise  1 ; aborting the opening of file  14 ; quarantining file  14 ; sending file  14  to an antivirus research center such as Symantec Antivirus Research Center (SARC); setting a flag to preclude subsequent downloads of files from computer  12 ; initiating an investigation as to why computer  12  may have become infected with malicious code; any other measure that one of prudence and good judgment might take when informed that malicious code might be present. 
   As stated previously, the contents of the tag are tailored to the preselected acceptability criteria. For example, if one of the acceptability criteria is that scanning means  33  must have its heuristic level set to at least a certain amount, then this required heuristic level is part of the tag. It also may be desirable to affix the name of computer  10  and/or the IP (Internet Protocol) address of computer  10  as part of the tag. This enables tracing the origins of malicious code if the attempted open causes malicious code to enter computer  12 . Components of the tag are stored in a memory device associated with computer  12  prior to execution of step  22 . 
   In response to the test open, computer  12  sends to computer  10  (step  47 ) a message conveying information pertaining to malicious code scanning capabilities of computer  12 . In one embodiment, the message is sent over the same file open channel that is used for the opening of file  14  over network  15 . Using the same file open channel makes the query of computer  12  quick and simple, and piggybacks on the security of the file open channel itself. This simplicity is evident at both computer  12  and computer  10 . Computer  12  checks the end of the pathname for the tag, compares definition dates and file exclusions (if these are part of the acceptability criteria), and returns the message to computer  10 . Computer  10  manufactures a file open that is a simple modification of an existing open, and checks the message received from computer  12 . 
   In an alternative embodiment, the message from computer  12  to the local computer  12  is sent via a channel other than the file open channel. This can be done by opening a port and sending packets back and forth between the two computers  10 , 12  using TCP (Transport Control Protocol), UDP (Universal Datagram Protocol), ICMP (Internet Control Management Protocol), etc. Other possibilities are to use DCOM (Distributed Communications Object Method), WMI, SNMP (Simple Network Management Protocol), RPC (Remote Procedure Calls), SSL (Secure Socket Layers), TLS (Transport Layer Security), etc. 
   The message returned from computer  12  to computer  10  contains information pertinent to the pre-established acceptability criteria. In one embodiment, said message contains information as to whether computer  12  has malicious code scanning means  33 , and whether definitions  37  associated with said scanning means  33  are at least as new as the definitions  32  associated with the malicious code scanning module  11  of computer  10 . Computer  10  then decodes the message (step  42 ). When the message reveals that computer  12  has malicious code scanning means  33 , and the malicious code scanning means  33  has definitions  37  at least as new as the definitions  32  in the malicious code scanning module  11  associated with computer  10 , computer  12  scans file  14  (step  49 ), then computer  10  issues a command to actually open file  14  (step  43 ), relying on said scan by computer  12 . When these acceptability conditions are not satisfied, however, computer  10  does not rely on computer  12  to perform the scan, and instead computer  10  performs a malicious code scan of file  14  over the network  15  (step  44 ), slow and cumbersome as that might be. 
   The message returned from computer  12  to computer  10  can be a set of one or more error messages. For example, in a WIN32 operating system, the conventional 32 bit error code can be used. For example:
         The error message “file not found” can mean that there is no scanning means  33  associated with computer  12 ;   The error message “access denied” can mean that there is scanning means  33  associated with computer  12 ; and   The error message “error 18” can mean that there is scanning means  33  associated with computer  12  and it meets all the pre-established acceptability criteria.       

   In one embodiment, when computer  12  detects the test open that has been initiated by computer  10 , computer  12  asynchronously begins to scan file  14  using scanning means  33 . The rationale for this is that the presence of a test open indicates that there is a high probability that computer  12  will be called upon shortly to perform said scan, so it may as well start as soon as possible to save time. Such a scan may very well be completed before the “actual open” command is issued by computer  10 . The results of the scan by computer  12  are typically placed into scanned file cache  16 , which is typically set up as a LRU (Least Recently Used) cache, i.e., the most recent results are placed at the top of the cache. 
   Let us now return to a discussion of  FIG. 2 . At step  22 , computer  12 , using the information from the tag that it had stored previously in step  21 , determines whether the test open is followed (say, within a preselected period of time) by a command emanating from the same computer  10  to actually open the same file  14  that was the subject of the test open detected in step  21 . When this condition is satisfied, the method proceeds to step  23 , where computer  12  allows the actual open of file  14  to proceed. In other words, computer  12  determines that it is safe to communicate with computer  10 , because computer  12  has determined that computer  10  is equipped with the clever means described above for determining that computer  12  has an acceptable malicious code scanning means  33 . 
   If, on the other hand, the condition tested in step  22  is not satisfied, the method proceeds to step  24 , where computer  12  determines that it is not altogether safe to communicate with computer  10 , and thus computer  12  limits subsequent communications with computer  10 . Such a limitation may comprise refusing to communicate at all with computer  10 , refusing to share files such as file  14  with computer  10 , allowing computer  10  to read from file  14  but not to write to file  14 , or any other limitation that computer  12  wishes to impose. The limitation may be a function of the type of file  14 . For example, if file  14  comprises executable code, computer  12  may impose more severe limitations than if file  14  does not contain executable code. 
   In order to provide additional protection to computer  12  before computer  12  communicates with computer  10 , optional authentication step  20  can be performed. 
   One way of performing step  20  is to use public key cryptography, in which the two computers  10 , 12  exchange digitally signed mutual authentication packets. This requires that the private keys of the computers  10 , 12  be hidden from malicious persons. Otherwise, malicious code could be written to spoof the authentication. 
   Another way to provide the authentication of step  20  is for the two computers  10 , 12  to trade a malicious code fragment for a unique malicious code identifier. The malicious code identifier is a unique number associated with that malicious code. Just a fragment, rather than the entire malicious code, is sent, because sending the entire malicious code would take too much time. The trade can be in either direction. In one direction, computer  10  sends the malicious code fragment to computer  12 , and computer  12  sends the malicious code identifier to computer  10 . In the other direction, computer  10  sends the malicious code identifier to computer  12 , and computer  12  sends the malicious code fragment to computer  10 . The rationale for this technique is that one computer requests from the other computer knowledge that only the other computer has, in this case the knowledge of identifying malicious code. So, for example, the authentication message can contain an obfuscated fragment of malicious code extracted from the definitions ( 32  or  37 ) associated with the challenging computer ( 10  or  12 ). This code may look very little like real malicious code, and cannot execute because is just a fragment. 
   An acceptable response to the authentication message must include the unique malicious code identifier. This can be done in two ways. In one way, the malicious code fragment is augmented by a standard husk and subjected to a malicious code scan (by scanning means  33  or scanning module  11 ). As used herein, “husk” is code that wraps around and encapsulates another piece of code or data. A husk is sometimes referred to as a “wrapper” or “container” or “security envelope”. In the other way, scanning means  33  or scanning module  11  is pre-fitted with a scan interface  34  that converts malicious code fragments into unique malicious code identifiers, e.g., by using a lookup table. In either way, it is desirable that the challenge message sent between each pair of computers  10 , 12  is different each time such a message is sent, and does not follow a predictable pattern or start at a predictable location in the list of definitions ( 32  or  37 ). A computer  10 , 12  that sends the same challenge pattern or response each time should be flagged as suspicious by the other computer  12 , 10 . This minimizes the possibility of replay attacks, i.e., attacks premised upon sending a known response to a known challenge based upon having intercepted a communication showing the challenge/response. To further minimize replay attacks, challenges should be composed from relatively new definitions in the set of definitions ( 32  or  37 ). 
   It is not necessary to perform this authentication procedure every time a file  14  is opened. A user of computer  10 , 12  can turn the authentication on or off at will, the authentication can be performed every so many file  14  opens, etc. The important thing is for the link between computers  10 , 12  to be authenticated prior to the first time these two computers  10 , 12  share a file  14 . 
   The above description is included to illustrate the operation of the preferred embodiments and is not meant to limit the scope of the invention. The scope of the invention is to be limited only by the following claims. From the above discussion, many variations will be apparent to one skilled in the art that would yet be encompassed by the spirit and scope of the present invention.