Methods, apparatus and articles of manufacture for computer file integrity and baseline maintenance

[0001] The present invention relates to computer file integrity and baseline maintenance. More particularly, the present invention relates to computer file integrity and baseline maintenance in a networked environment.

[0002] Ensuring the integrity of files and maintaining a baseline file system on a computer are constant problems. Attacks by malicious code, as well as inadvertent corruption by operating systems, other files, etc. provide a less than ideal environment for maintaining file integrity and maintaining a baseline system. Attacks by malicious users, such as hackers, as well as authorized changes by authorized users, e.g. disgruntled employees, may also violate file integrity and the system baseline. Moreover, maintaining appropriate updates of computer files leaves yet another area of file integrity and baseline maintenance for the user. For example, various iterations of Microsoft Windows contain a registry necessary to properly operate a computer system, yet updates may corrupt the registry when not properly integrated in the registry after installation.

[0003] Mechanisms do exist in the art for attempting to ensure file (file as used hereinafter generally includes files, data, code and microcode, e.g. firmware and the like) integrity and baseline maintenance for a system. For example, antivirus or other similar packages attempt to protect the system or network from hostile, malicious, predetermined and/or proscribed code (generally referred to hereinafter as proscribed code.) VFIND, from CyberSoft, Inc., is one such product that protects systems and networks from proscribed code. Any stand alone antivirus programs, such as VFIND, usually need to be run by the user, however, and run frequently, otherwise the protections offered by the programs are lost. Also, these programs do not generally intercept proscribed code as the code is transferred from machine to machine, nor do these programs protect against hostile or unauthorized access to a machine or network.

[0004] Similarly, updating programs attempt to ensure the integrity of files on computer systems. The difficulties with updating systems arise, however, because updating systems are often program specific, and must be run for each program the user wants to update. This is a cumbersome task that may be put off by the user. Those updating programs that are not program specific, i.e. that purport to provide updating to the files on the user's system, may also have difficulties, because general updating programs are often restricted to a specific database of programs, and if any program is not present on the database, it will not be updated.

[0005] Accordingly, it is an object of the present invention to provide apparatus, methods and articles of manufacture for computer file integrity and baseline maintenance in a networked environment.

[0006] The present invention comprises apparatus, methods and articles of manufacture for file integrity and baseline maintenance on a computer system or systems. In the preferred embodiments, an MD5 hash is constructed of each file that the user desires to maintain.

[0007] Additionally, other hashes as known in the art may be used, such as MD4 or SHA1 as well as a CRC or combinations of hashes. The construction of the hash may be on a predetermined basis, such as scheduling, on a real time basis, or may be initiated by an antivirus or baseline program. In some embodiments, it should be noted, a predetermined hash may be provided.

[0008] The hash is stored in a secure area, which may or may not be on the user system. Periodically, or when desired, a new hash of the maintained file is generated and compared to the stored hash. If the comparison is true, that is, if the hashes are equal, the result is noted in a log and no further action is taken. If the comparison is false, that is, if the hashes are not equal, the comparison program notifies an alarm component.

[0009] The alarm component sends, across a network, and/or to a file server, notification that it is seeking a replacement for the file, along with a hash code identifying the file. This notification may be delayed, such as when the system is unable to access the network. When the alarm is picked up by one or more machines on the network, those machines respond by first, determining from their own database of hashed files if they have the file, and next, responding with the appropriate file.

[0010] When the file is received by the requesting system, the system hashes the file, check the hash against its original stored hash, and proceeds to install the file if the hash comparison is true. In the especially preferred embodiments, this is done in a secure area on the system. If the hash comparison does not prove true, then the cycle of alarm and response may be repeated.

[0011] In such a manner, the preferred embodiments may use an unknown and/or untrusted source to furnish a trusted result. However, if desired, certain sources may be preferred, or become identified as preferred, through a log, and so those sources would be checked for the file first. A results log may also be maintained, which includes successful maintenance attempts.

[0012] In the especially preferred embodiments, the user request is anonymous, so that the requesting machine is not readily identifiable.

[0013] The present invention comprises apparatus, methods and articles of manufacture for maintaining computer file integrity and baseline maintenance in a networked environment. Although the present invention can be implemented on any platform known in the art, the preferred embodiments are used in Unix and various Windows environments, such as XP, NT, 2000, 95, 98 and Me, as well as other Unix and Unix-like platforms, including System V, Sun Solaris, IBM AIX, HP-UX, Linux and its variants, as well as other operating system platforms including but not limited to IBM OS/390, MacOS, VxWorks and others. Moreover, those skilled in the art will appreciate that the invention may be practiced with other electronic device and computer system configurations, including hand-held devices, cell phones and other wired and wireless communication devices, digital audio and video devices, distributed computing environments, multi-processor systems, and microprocessor-based or programmable consumer electronics, such as smart printers, network PCs, minicomputers, mainframe computers, and the like.

[0014] In the preferred embodiments, a maintenance system is installed on a client. Here, the word client is used to define the system requesting the update. It should be noted that a system can be both a client and a server. The maintenance system is comprised of: a client maintainance_manager and one or more client maintenance_index file(s). (Of course, the file names may differ in different embodiments.)

[0015] The client maintenance_manager performs various functions as set forth below. The client maintenance_index file may be of variable size, and is comprised of one or more data information records of files on the system. The files included may be all files on the system files, or another desired set of files. Each record is comprised of, in the preferred embodiment, as:

[0016] file_name (which, for example, may be the same as a directory entry if one exists for the file, a program supplied name, e.g. when anonymity is desired, a derivative or meta file name, and/or other desired file identifiers. A file_name may also be a descriptor of a logical group of data such as when an area of RAM or other logical group of data has been isolated in order to be checked for file integrity,)

[0017] a hash or CRC of the file, which is, in the preferred embodiments, a MD5 hash, although other hashes as known in the art may be used, such as MD4 or SHA1 as well as a CRC or combination thereof. Also it should be noted that special cases can arise in which a file may have multiple valid hash codes. For example, if a logical group of data in RAM has been isolated in order to check for file integrity, it may have a number of discrete states, and therefore a multiple valid hash codes.

[0018] The records contain these fields in the following format:

[0019] file_name:hash.

[0020] Further description on these fields is presented below. There may be one or more of these maintenance_index files in various embodiments, and fields and order of fields may be changed from that described above as desired. For example, in the especially preferred embodiments, one maintenance_index file may contain information on all the products desired to be maintained, and the file is securely stored on the system, e.g. through encryption, hidden partitions, password protection, etc. In other embodiments, more than one maintenance_index files may be present on the user's and/or other machines, and cross checks done among the versions as desired to ensure that file integrity is maintained. In yet other embodiments, the maintenance_index may refer to other maintenance_index files. This referential maintenance_index file structure may provide a hierarchical tree structure and use a single maintenance_index file to define an entire set of files for updates.

[0021] The client maintenance_manager is initially responsible for constructing the maintenance_index file(s). In the preferred embodiments, this construction is only done when the client is in a secured state, that is, when the files are known. In other embodiments, the maintenance_index file may be presupplied, as is described in further detail below. In yet other embodiments, the initial client state is disregarded, and an initial security maintenance performed, as is described in further detail below.

[0022] The client maintenance_manager is also responsible for running file integrity checks on a desired basis. Each file integrity check constructs a record for a file on the system. It also should be noted that a file integrity check may be made of fewer than all the files on a system. Such as check may be made of files predetermined by the user and/or administrator or selected by another method.

[0023] The record resulting from the file integrity check is then compared against the maintenance_index record of the same file. A number of actions may be taken depending upon the result of the comparison:

[0024] If the file name and hash code are the same; the file is presumed secure and no further action is taken;

[0025] If the file name and hash code differ; the file is presumed insecure, and a retrieval module of the maintenance_manager is initiated.

[0026] If a file is missing, then a client file check is performed. The client file check checks for the existence of a file with the same hash code as the missing file. If such a file is found, its existence is noted, and the user or other appropriate administrator is notified that the file name may have been inappropriately changed. If such a file is not found, the lack of a file with a hash code may lead to a user alert, and/or other actions may be taken.

[0027] Additionally, a report may be generated upon the internal comparison.

[0028] As had been noted above, in some embodiments, the maintenance_index file may be presupplied. Thus, lists of hash codes or preconfigured database(s) of hash codes for example could be provided as a convenient means to update, install or alter the system to a specific configuration.

[0029] The retrieval module of maintenance_manager broadcasts, over a network connection or connections, a signal indicating it needs the file or files that the maintenance_manager has presumed is insecure, and/or missing. Such a signal may be broadcast over a connection reserved for it in some embodiments, in other embodiments, the signal may be broadcast over a general use channel, e.g. the Internet. The retrieval module does not, in the especially preferred embodiments, direct its signal to any particular machine, aside from those that are running a receive signal module of the embodiment, which is further described below, although it may so direct if desired. It should be noted that it is possible in some embodiments that the signal be disguised, e.g. the server may not even know a client system is looking for a file or files.

[0030] The signal is received by one or more servers, which may be systems, file servers, network attached storage devices, storage applications, etc. It should be noted that the server may be of a different operating system type than the client machine. The server does not have to be preidentified as trusted, and may be in fact, entirely invisible to the client, as the client may be to the server. Indeed, in certain embodiments, a hash code and initial requesting signal may be the only transferred information. The preferred embodiments may use an unknown or untrusted source to furnish a trusted result. However, if desired, certain servers may be identified, or become identified as preferred, and so those servers would be desirable.

[0031] Once a server or servers receives the signal from the client, the systems respond by first, determining from their own database of hashed files if they have the file, and next, responding with the appropriate file. The server side database of hashed files may be predetermined, generated when desired, etc.

[0032] If a copy of the requested file is returned to the client from a server, the client hashes the file, and checks the hash against its stored hash database. If more than one copy is returned, the client will usually accept the first received and refuse the remainder. Alternatively, it may decide which to accept. If the hash comparison is true, the client will reinstall the file. In other embodiments, used in file installation and/or updating, a hash database may be supplied to or be present on the client that contains hashes of files to be installed and/or updated. Thus, any files obtained from a source would have their hash checked against that database in order to be installed and/or updated.

[0033] If the hash comparison does not prove true, then the cycle of alarm and response is repeated with another server, and the first server may be noted as providing an inappropriate file. A database of inaccurate servers as well as a database of accurate servers may be kept and used to refine further requests. Additionally, a log of successful installations may be maintained as well. Additionally, in some embodiments, the client hash database may be updated for new files installed on the system, or otherwise as desired. Thus, the client hash database does not have to be a static database in all embodiments.

[0034] If the requested file is not returned to the client within a number of broadcast/receipt cycles, or if only untrusted files have been returned within a number of cycles, then the system may utilize alternative means of obtaining the file such as a restore.

[0035] Additionally, the system may disinfect the original file using a tool such as MVFilter available from CyberSoft, Inc. The number of broadcast/receipt cycles may be predetermined by the user and/or administrator.

[0036] In some embodiments, the same system may act as both client and server. Thus, the system may refer to an internal file server, such as when a file name has been inappropriately changed, a file has been corrupted in a crash, etc. In a loopback type embodiment, for example, regular file integrity checks may be made of files in a system that are likely to be corrupted during system operation. If corrupted, the request would be then of the internal system server without the need to access a network.

[0037] The above description and the views and material depicted by the figures are for purposes of illustration only and are not intended to be, and should not be construed as, limitations on the invention.

[0038] Moreover, certain modifications or alternatives may suggest themselves to those skilled in the art upon reading of this specification, all of which are intended to be within the spirit and scope of the present invention as defined in the attached claims.