Abstract: An enterprise network can have sanctioned and unsanctioned servers on it. Sanctioned servers are approved by an administrator and perform tasks such as web page serving and mail routing. Unsanctioned servers are not approved by the administrator and represent possible security risks. A service monitor accesses one or more metadata sources having information describing the enterprise network, such as domain name system (DNS) records on the Internet. The service monitor analyzes the metadata and creates a security profile for the enterprise network. The security profile identifies the sanctioned servers. The service monitor monitors network traffic for compliance with the security profile, and detects unsanctioned servers on the network. The service monitor reports violations of the profile and informs the administrator of the unsanctioned servers.

Abstract: A reputation server is coupled to multiple clients via a network. Each client has a security module that detect malware at the client. The security module computes a hygiene score based on detected malware and provides it to the reputation server. The security module monitors client encounters with entities such as files, programs, and websites. When a client encounters an entity, the security module obtains a reputation score for the entity from the reputation server. The security module evaluates the reputation score and optionally cancels an activity involving the entity. The reputation server computes reputation scores for the entities based on the clients' hygiene scores and operations performed in response to the evaluations. The reputation server prioritizes malware submissions from the client security modules based on the reputation scores.

Abstract: Certain events, such as data input operating system calls, are likely to initiate a buffer overflow attack. A timing module generates timestamps that indicate when such possible initiating events occur. The timestamp is associated with a particular process and/or thread executing on the computer. If subsequent evidence of a buffer overflow attack is detected on the computer, the timestamps are consulted to determine if a possible initiating event occurred recently. If there is a recent initiating event, a buffer overflow attack is declared. Evidence of a buffer overflow attack can include receiving a signal from the processor indicating that the processor was asked to execute an instruction residing in non-executable memory. Evidence of a buffer overflow attack can also include detecting an action on the computer that malicious software is likely to perform, such as opening a file or network connection, being performed by an instruction residing in non-executable memory.

Abstract: A worm detection module (WDM) (212) stops worms and other malicious software from spreading among computer systems (100) on a network (210) via open drive shares. The WDM (212) monitors (310) a storage device (108) for activity (314, 316) directed to executable files by remote processes. The WDM (212) flags (318) files (216) that are the target of such activity. If a flagged file (216) attempts to create an executable file (218) on a networked computer system (100B), the WDM (212) detects (322) that the flagged file (216) is a worm. In response, the WDM (212) blocks the write to the networked computer system (100B) and thereby prevents the worm from propagating.

Abstract: An access control system (200) enables a computer network (1) to prevent execution of computer code that may contain computer viruses. An access control console (201) generates an access control message (260) including control parameters such as a time limit (255). Said time limit (255) is disseminated to computers (2, 3) on the network (1). Said computers (2, 3) use the time limit (255) to determine the executability of computer code. Access control system (200) also enables blocking data communications with suspicious or susceptible programs in network (1) during virus outbreaks.

Abstract: A database server receives an incoming query and converts the query into its canonical form. The database server compares the canonical incoming query with stored template queries. If the incoming query matches one of the stored template queries, then the query is legitimate and the query is executed on the database. If the canonical incoming query does not match one of the stored template queries, then the database server determines whether the incoming query is malicious or anomalous. The database server identifies tokens in the incoming query that are not present in a similar template query. If the tokens have meaning in the language utilized to express the query, the database server declares the query malicious. Otherwise, the database server declares the query anomalous.

Abstract: Virus detection modules (120) execute virus detection techniques on clients (110) to check for the presence of computer viruses in data and also communicate with a software server (116). A constraints module (320) specifies constraints on the application of certain virus detection techniques. An administrator uses the software server (116) to release (514) a virus detection technique and an associated constraint to the clients (110). The clients (110) execute the technique subject to the constraint, and report the results to the software server (116). The administrator uses the constraint and reported results to determine (518) whether the technique is causing false positive virus detections. If necessary, the administrator modifies (520) the technique to reduce the false positives and/or modifies (524) the constraint to cause the technique to execute more frequently. The constraints allow the administrator to detect false positives without inconveniencing most clients (110).

Abstract: Methods, systems, and computer readable media for managing transmission of a requested computer file (140) from a remote host compute (125) to a client computer (120). A proxy server computer (110) receives a first chunk (315) of the requested computer file (140). The proxy server (120) generates a hash of the chunk (315) and compares the hash to a hash of a chunk of previously downloaded file. If the two hashes are identical, the chunk (315) of the requested computer file (140) is passed to the client computer (120).

Abstract: A virus detection system (VDS) (400) uses a histogram to detect the presence of a computer virus in a computer file. The VDS (400) has a P-code data (410) for holding P-code, a virus definition file (VDF) (412) for holding signature of known viruses, and an engine (414) for controlling the VDS. The engine (414) contains a P-code interpreter (418) for interpreting the P-code, a scanning module (424) for scanning regions of the file (100) for the virus signatures in the VDF (412), and an emulating module (426) for emulating instructions in the file. The emulating module (426) contains a histogram generation module (HGM) (436) for generating a histogram of characteristics of instructions emulated by the emulating module (426) and a histogram definition module (HDF) (438) for specifying the characteristics to be included in the generated histogram. The emulating module (426) uses the generated histogram (500) to determine how many of the instructions of the computer file (100) to emulate.

Abstract: A virus detection system (VDS) (400) operates under the control of P-code to detect the presence of a virus in a file (100) having multiple entry points. P-code is an intermediate instruction format that uses primitives to perform certain functions related to the file (100). The VDS (400) executes the P-code, which provides Turing-equivalent capability to the VDS. The VDS (400) has a P-code data file (410) for holding the P-code, a virus definition file (VDF) (412) for holding signatures of known viruses, and an engine (414) for controlling the VDS. The engine (414) contains a P-code interpreter (418) for interpreting the P-code, a scanning module (424) for scanning regions of the file (100) for the virus signatures in the VDF (412), and an emulating module (426) for emulating entry points of the file. When executed, the P-code examines the file (100), posts (514) regions that may be infected by a virus for scanning, and posts (518) entry points that may be infected by a virus for emulating.

Abstract: Methods, systems, and computer readable media for managing transmission of a requested computer file (140) from a remote host compute (125) to a client computer (120). A proxy server computer (110) receives a first chunk (315) of the requested computer file (140). The proxy server (120) generates a hash of the chunk (315) and compares the hash to a hash of a chunk of previously downloaded file. If the two hashes are identical, the chunk (315) of the requested computer file (140) is passed to the client computer (120).

Abstract: Potentially malicious software is detected and prevented from installing and/or executing on client devices (122). A software developer sends software to a certifying authority (114) in order to obtain (710) a certification for the software. The certification uniquely identifies the software and allows any tampering to be detected. The software developer distributes (712) the software to the client devices (122). A client device (122) asks an execution authority (118) whether the software is malicious. The execution authority (118) maintains a database (514) specifying the status of certain software. If the status of the software at the client device (122) is in the database, the execution authority (118) reports it to the client device. The execution authority (118) can also analyze (716) the frequency of software execution requests from client devices (122) to determine whether the software is malicious.

Abstract: A software development system (SDS) (228) digitally signs software (230) developed on the system. The SDS (228) executes on a computer system (112) having a trusted computing platform. The platform includes protected areas (220, 226) that store data and cannot be accessed by unauthorized modules. A code signing module (232) executing in a protected area (226) obtains a private/public key pair and a corresponding digital certificate. The SDS (228) is configured to automatically and transparently utilize the code signing module (232) to sign software (230) produced by the system. End-user systems (114) receive the certificate with the software and can use it to verify the signature. This verification will fail if a parasitic virus or other malicious code has altered the software (230). Accordingly, the SDS (228) greatly reduces the risk of malicious code executing on the end-user computer system (114).

Abstract: An access control system (200) enables a computer network (1) to prevent execution of computer code that may contain computer viruses. An access control console (201) generates an access control message (260) including control parameters such as a time limit (255). Said time limit (255) is disseminated to computers (2, 3) on the network (1). Said computers (2, 3) use the time limit (255) to determine the executability of computer code. Access control system (200) also enables blocking data communications with suspicious or susceptible programs in network (1) during virus outbreaks.

Abstract: A method for detecting computer viruses comprising three phases: a decryption phase, an exploration phase, and an evaluation phase. A purpose of the decryption phase is to emulate a sufficient number of instructions to allow an encrypted virus to decrypt its viral body. A purpose of the exploration phase is to emulate at least once all sections of code within a region deemed likely to contain any virus present in the target program. A purpose of the evaluation phase is to analyze any suspicious behavior observed during the decryption and exploration phases to determine whether the target appears to be infected.

Abstract: A computer readable file of a first state (3.0) is updated to a second state (3.2) through the use of an incremental update (112) which provides the information necessary to construct the file of the second version (3.2) from a file of the first version (3.2). In order to allow for future access to the first version (3.0), without maintaining a copy of the file of the first version (3.0), a back-update file (206) is created. The back-update file (206) provides the information necessary to construct a file of the first state (3.0) from a file of the second state (3.2).

Abstract: A computer readable file of an original state is updated to a final state. The original state and the final state are both states within a sequence (100) of states, which sequence (100) includes at least one hub state and one non-hub state. A first hub version, which corresponds to a hub state which is at least as early in the sequence as the original state, is stored locally. A hub incremental update (110) is retrieved (314) and used to update (316) the hub version to a second hub version, which second hub version corresponds to a hub state which is at least as early in the sequence (100) as the final state. A final incremental update (112) is retrieved (320) and used with the file of the final hub version to produce (322) a file of the final state. The files corresponding to both the second hub state and the final state are retained (324).

Abstract: A computer-implemented method for executing a computer file in a CPU emulator (154) to detect a computer virus. The method includes simulating (302) the execution of a predetermined number of instructions of the computer file in the CPU emulator (154), suspending (303) the execution, constructing (304) a state record, temporarily storing (305) the state record in memory, comparing (306) the constructed state record to state records stored in a state cache (158), and indicating (308) that the file is virus free when the constructed state record matches one of the stored state records.

Abstract: A computer-implemented apparatus and method for countering attempts of polymorphic viruses to evade detection by emulation-based scanners. Such attempts try to exploit differences between the real and virtual execution of instructions. The invention includes a fault manager (158) integrated into the CPU emulator (154) of a virus scanner software product. Before each instruction is emulated by the CPU emulator (154), the fault manager (158) examines the opcode of the instruction to determine (310) whether a "fault" is triggered. If a fault is triggered, the fault manager (158) saves (314) a state record on a fault stack (162), then interrupts (316) to a corresponding fault handler routine (160). The criteria for triggering a fault and the corresponding fault handler routine (160) may be obtained from an updatable data file (164).

Abstract: A computer-implemented method for executing a computer file in a CPU emulator (154) to detect a computer virus. The method includes simulating (302) the execution of a predetermined number of instructions of the computer file in the CPU emulator (154), suspending (303) the execution, constructing (304) a state record, temporarily storing (305) the state record in memory, comparing (306) the constructed state record to state records stored in a state cache (158), and indicating (308) that the file is virus free when the constructed state record matches one of the stored state records.