JP2008522292A - Method for controlling access between multiple network endpoints based on trust score calculated from information system component analysis - Google Patents

Abstract

Signatures are generated for a plurality of modules in the computer system. This signature is compiled into an integrity log. This signature is compared to the signature in the integrity validator database. As soon as the signature is validated or invalidated, a trust score is generated. Using this trust score, the computer system can use a policy to determine whether access to the resource should be granted.
[Selection] Figure 1

Description

Field of Invention

  The present invention relates to computer module verification and, more particularly, to determining the integrity of a computer prior to granting the computer permission to access network resources.

Background of the Invention

  In the past, computer networks were unusual, but computer networks are now commonplace. Most companies use computers that are networked together. A large company may use hundreds or even thousands of computers that are networked together. Computer networks are also penetrating homes. Since the whole family wants to have their own computers, it is necessary to network them to share resources (eg, connection to the Internet). Companies that manufacture devices that support computer network connections, such as routers, are addressing this trend by creating devices that can be easily installed and used. Users often have to do a little more complicated work. For example, you need to connect a computer to a router or turn on the router, but the computer is reliable enough that users don't need to do anything.

  However, making the network settings the same simple procedure increased the vulnerability of the computer. Viruses, worms, Trojans and logic bombs are being created at an unprecedented pace. And as such networks are connected to the Internet, the spread of such crises has become easier and more frequent with the Internet.

  It is at least annoying for users to be infected with viruses and the like. At best, the user needs to identify which computers in his personal network are infected with the virus and take the time necessary to quarantine the infected computers. In the worst case, if you get a virus, you may need to erase your hard drive and restore the software from scratch. As a result, the user may lose all data stored on the infected computer.

  For individual users, data stored on their computers (eg family photos and personal documents) is irreplaceable and irreplaceable. Still life will continue. However, at work, such data loss will be fatal. Even if you implement an appropriate archiving policy, the time it takes to repair a computer system and a business network will include both the revenue you did not get in the meantime and the cost of actually repairing the computer and network. Together, it will be worth over $ 1000. In addition, you may lose credibility while you are unable to do business while repairing your computer and network.

  Therefore, to address these issues, there remains a need for means to identify computers that are potentially in an inappropriate state before they are granted access to network resources.

  The present invention includes a method and apparatus for building a database of valid module signatures, validating modules, and further verifying a computer. In order to verify the computer, the device receives signatures generated for a plurality of modules in the computer. These signatures are assembled into an integrity log. The device attempts to verify that each signature is correct by comparing these signatures with the signatures in the database. After these signatures are enabled or disabled, the device generates a trust score based on which signatures received from the computer are enabled.

  The foregoing features, objects, and advantages of the present invention, as well as other features, objects, and advantages will become apparent from the following detailed description, taken in conjunction with the accompanying drawings.

Detailed Description of the Preferred Embodiment

  FIG. 1 shows a system having an integrity validator for performing computer verification. In FIG. 1, the computer system 105 is connected to an external network 110. The computer system 105 is shown as including a computer 115, a monitor 120, a keyboard 125, and a mouse 130. However, those skilled in the art will appreciate that the computer system 105 may have other components (eg, other input devices and output devices such as printers). Also, FIG. 1 does not show some conventional internal components of the computer system 105 (for example, a central processing unit, a memory, etc.). Furthermore, the computer system 105 can be replaced by other machines such as a notebook personal computer, a dedicated terminal device, and a personal digital assistant (PDA).

  The external network 110 is a network outside the mechanism (organization) as the name indicates. On the other hand, the internal network 135 is an internal network of the mechanism. The integrity validator 140 is located between the external network 110 and the internal network 135 and verifies computers requesting access to resources inside the mechanism, such as resource 145, on computers outside the mechanism. To do. The resource 145 may be any kind of resource (for example, a network drive, a directory, a file, a web page, etc., to name a few examples). In order to support such verification, the computer system 105 includes an integrity log generator 150. The integrity log generator 150 collects integrity logs for the computer system. The integrity validator 140 then verifies the computer system 105 using this integrity log.

  The integrity log is a set of signatures corresponding to various modules in the computer system 105. In one embodiment, these signatures are various module hashes and can be generated using a hash function 155 such as MD5, SHA-1, or SHA-256. In one embodiment, the integrity log generator 150 may be a device driver that is loaded early in the system startup sequence (preferably before any other drivers are loaded). The integrity log generator 150 can then identify each module that is accessed or loaded during the startup sequence of the system and generate a signature for these modules. In another embodiment, the integrity log generator 150 may be an executable that can perform a full system scan for all possible modules. Those skilled in the art will recognize other ways in which the integrity log generator 150 can operate.

  In one embodiment, integrity log generator 150 generates signatures only for actually loaded modules such as device drivers and executable modules. In another embodiment, the integrity log generator 150 generates signatures for modules as described above and all support modules (eg, dynamic link libraries (DLLs)). Those skilled in the art will recognize other modules with which the integrity log generator 150 can generate signatures and other ways in which the integrity log generator 150 can operate.

  From the above description, it will be apparent that the integrity log generator 150 can only operate on software modules. Typically, software modules consist of a number of modules for which the integrity log generator 150 generates signatures, but those skilled in the art will also recognize the integrity log generator 150 for hardware modules as well. You will see that you can. For example, the integrity log generator 150 can generate a signature for firmware and hardware modules used in a basic input / output system (BIOS) of a computer system. These firmware and hardware modules are, for example, flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), and electrically erasable It may be stored in a programmable read-only memory (EEPROM), a ferroelectric random access memory (FRAM), a magnetoresistive random access memory (MRAM), or the like.

  Once the signatures are generated, the integrity log generator 150 bundles those signatures into an integrity log. This integrity log may include an identifier for the module for which the signature was generated.

The identifier may include the following elements:
The absolute path of the module and its file name. In other words, this identifier can identify the product or component to which the module is connected.
The version or path level of a module or product or component that contains a module so that different versions of the same module can be distinguished.
One skilled in the art will recognize that different types of identifiers can be used.

  In one embodiment, integrity validator 140 is used only to verify computer systems that are not directly connected to internal network 135. In one embodiment, there is also an implicit assumption that the computer system connected to the internal network 135 is known to be safe and effective. This is not necessarily an unreasonable assumption. This is because the computer system inside a mechanism is usually managed by that mechanism. In this way, the possibility of being infected with a virus or the like (a virus or the like) is lower than that of a computer system not managed by the mechanism. By making this assumption, it is not necessary to verify the computer system inside the mechanism, so that the computer system inside (managed) the mechanism can quickly access the requested resource.

  Nevertheless, in another embodiment, even a computer system connected directly to the internal network 135 (and thus not requesting a resource via the external network 110) may request access to the resource. Get verified. Although access to the requested resource may be slow, security is robust in that this verification can detect malicious agents even on the computer system inside the mechanism. It will be something.

  In the embodiment shown in FIG. 1, the integrity validator 140 is illustrated as being directly connected to the internal network 135. In this example, the computer system inside the organization contains a module that is not available to the public (eg, the module is a product under development or is classified (eg, by the government) ), Works well. This embodiment will work with mechanisms that use only commercially available modules, but this embodiment would require that the mechanism include an integrity validator 140 as part of the system. An alternative embodiment is also available when this mechanism uses only commercially available modules, in which case the integrity validator 140 is not a mechanism-specific integrity validator, but a publicly accessible integrity It may be a validator. Such an integrity validator will be connected to the external network 110 as an integrity validator 160. The integrity validator 160 operates in the same manner as the integrity validator 140 except that the integrity log is sent to the integrity validator 160 via the external network 110.

  As described above, in one embodiment, integrity validator 140 operates to verify network access to resources from within the mechanism. While it is possible for the integrity validator 140 to store signatures for all possible modules on a computer system, in another embodiment, the integrity validator 140 stores only the signatures for the modules associated with the mechanism. For standard modules (or other modules that are not justified by the integrity validator 140), the integrity validator 140 integrates their signatures (via the external network 110) for verification. Send to validator 160. In this manner, the integrity validator 160 can be responsible for verifying these modules, so that the integrity validator 140 does not need to be updated as new modules are introduced.

  If the computer system 105 is not directly connected to the internal network 135, the integrity validator 140 can operate whether the resource 145 is requested in either an encrypted form or an unencrypted form. Similarly, in this case, integrity validator 140 can operate whether resource 145 is requested using an encrypted channel or an unencrypted channel. For example, the resource 145 may be a password protected web page. Alternatively, resource 145 may be requested via a virtual private network (VPN) that is used to protect access to the resource. One skilled in the art will recognize alternative ways of managing access to resources 145.

  FIG. 2 illustrates further features of the integrity validator 140 of FIG. 1 used to perform computer verification. Although the integrity validator 140 is shown in greater detail in FIG. 2, those skilled in the art will appreciate that the detailed structure shown here can be applied to any integrity validator (eg, integrity validator 160). You will understand that. Those skilled in the art will also appreciate that FIG. 2 does not represent the data flow within the integrity validator 140.

  The integrity validator 140 has a database 205. Database 205 is shown in greater detail in FIG. Although FIG. 3 shows a database 205 represented as table 305, those skilled in the art will recognize other formats that database 205 can take. The table 305 has a large number of entries (inputs). However, the entries 310, 315, and 320 are shown here. Each entry contains a module and its corresponding signature. For example, entry 320 shows the signature for the virtual memory manager DLL of the Windows XP operating system (the signature shown for this entry 320 is not a real signature but a random number representing the signature). Although entries 310, 315, and 320 describe modules that are used in conjunction with multiple versions of Microsoft Corporation's Windows operating system, those skilled in the art will appreciate that other embodiments of the present invention can be used in other operating systems. It will be understood that the same can be applied to. Examples of such operating systems include, for example, multiple versions of the Linux operating system (Microsoft and Windows are registered trademarks of Microsoft Corporation in the United States and other countries, and Linux is a registered trademark of Linus Torvalds. is there).

  As described above, the entry of the table 305 has identifiers for various modules. By including the module identifier in table 305, the signature given for module verification can be compared with the expected signature for that module, thereby verifying that the module is properly verified. Can be confirmed. The table 305 is shown as having only one module identifier (the path and file name of the module), but those skilled in the art may use other module identifiers or any other module identifier. It will be appreciated that a combination of these can be used.

  In another embodiment, the table 305 holds only valid signatures that do not have a module identifier. In this case, the signature provided for module verification is compared with all signatures in the database 205 until a match is found. If a match is found somewhere in the database 205, the module is considered validated. Otherwise, the module is not considered valid. If the function chosen to calculate the signature (ie, the hash function) is not likely to collide, then the risk that the signature of the module that is not enabled matches the signature in the database is probably It's not enough. However, this risk can be effectively eliminated if the database 205 has a module identifier.

  Turning briefly back to FIG. 2, the integrity validator 140 comprises other components. The receiver 210 is provided for receiving information sent to the integrity validator 140. For example, the receiver 210 may have an integrity log from a computer system to be verified, a signature added to the database 205 in response to a newly valid module, or an old one corresponding to an existing module in the database 205. An exchange signature for exchanging the signature can be received. The transmitter 215 is provided for transmitting information from the integrity validator 140. For example, the transmitter 215 may send the trust score to the computer system or send these signatures to another integrity validator (if the integrity validator 140 cannot verify the module corresponding to the signature). it can.

  The validator 220 is provided for verifying the signature received by the integrity validator 140. The validator 220 receives one or more signatures, determines which signatures are valid, and sends back a representation of which signatures are valid and which signatures are not valid. Validator 220 can compare a received signature with a signature in database 205 and indicate whether the compared signature matches a signature in database 205 as easily as a comparator. The validator 220 can also perform more complex techniques for verifying signatures if desired.

  A trust score generator 225 is provided for generating a trust score for the computer system. The trust score indicates whether the computer system is reliable. Trust scores can be generated in a variety of different ways. In one embodiment, the trust score is the ratio of the number of enabled modules on the computer system to the total number of modules (including those that are enabled) on a computer system. In another example, the trust score can be a number between 0 and 1000. In this case, 0 represents a completely unreliable computer system and 1000 represents a fully trusted computer system. In another embodiment, a computer system that contains a large number of significant modules that have been validated is more highly rated than a computer system that has few significant modules that have been validated (even if the effectiveness of the latter computer system). Important modules are weighted more than other modules (so that the total number of modules taken is higher than the former computer system). The definition of “critical” does not mean a module that is absolutely necessary to the same extent as a module that is critical to a mechanism. Thus, one mechanism may state that the files associated with that operating system are “important”, and another mechanism may have a custom-developed module within it (whatever it was developed for) Maybe it is “important”.

  There are other ways in which the trust score generator 225 calculates the trust score. In another embodiment, the trust score generator can take into account the positions of various validated modules in the integrity log. For example, modules that are listed in the integrity log in advance are more important than modules that are added to the integrity log later. In another embodiment, the trust score generator 225 can take the module identifier into account when calculating the trust score. Modules manufactured by one manufacturer can be considered more important than modules manufactured by another manufacturer. For example, in the case of a module that operates in conjunction with an application, a module manufactured by a specific application manufacturing company can be given more importance than a module manufactured by a manufacturing company unrelated to the application.

  In another embodiment, the module version or patch level may be a factor in calculating the trust score. For example, assuming that a module has multiple versions, a newer version can be made more important than an older version. If a valid module is expired, its trust score will be lower than the trust score of the same computer system, except that it has a newer version of the same module.

  The integrity validator 140 can also have a policy 230. Policy 230 can indicate how and under what conditions the computer system is authorized to access a resource, such as resource 145 of FIG. In one embodiment, policy 230 has a threshold score 235. In order to be granted access to the resource, the computer system needs to have a trust score of at least a threshold score of 235 or higher. If the trust score for the computer system is below the threshold 235, the computer system is denied access to the resource.

  In another example, the policy 230 can have multiple threshold scores. For example, in FIG. 2, policy 230 is shown as having two threshold scores 235 and 240. If the trust score for the computer system is greater than or equal to the threshold score 235, the computer system is granted full access to the resource. If the trust score for this computer system is less than threshold score 235 and greater than or equal to threshold score 240, the computer system is allowed partial access to the resource. If the trust score for this computer system is less than the threshold score 240, then this computer system is denied access to that resource (in this case, this computer system redirects to a help resource and why this computer system's trust score To find out how low the price is).

  Policy 230 has been described in the above description for an example having one resource and two or less threshold scores, but those skilled in the art will recognize that policy 230 may be defined in other ways. Let's go. For example, the policy 230 can describe different policies for different resources on the same network. That is, the access permission for the resource is determined by a method other than the score comparison between the computer system trust score and one or more threshold scores. In addition, while the policy 230 is a policy for accessing a resource of a specific mechanism, the integrity validator 140 is actually used by multiple mechanisms (for example, the integrity validator 140 is used in the integrity validator 160). The integrity validator 140 can store policies for multiple mechanisms (organizations).

  In FIG. 2, the integrity validator 140 is shown as having both the functions used to generate the trust score and the policy 230, but those skilled in the art will recognize that the integrity validator 140 You will understand that you don't have to have all the functions. For example, the integrity validator 140 is only responsible for generating a trust score, and policy management (based on this generated trust score) can be performed elsewhere.

  FIG. 4 shows a flowchart of the procedure used by the integrity validator of FIG. 1 to build the database of FIG. In FIG. 4, in step 405, the module is identified. FIG. 4 relates to building a database that is used to validate a computer system. Module identification is probably done manually. For example, a module manufacturer can present a module for signature generation and addition of signatures to a database. However, those skilled in the art will appreciate that module identification can be automated. At step 410, a signature is generated for the identified module. At step 415, the signature is added to the database. Finally, at step 420, the identifier for the module can be added to the database, associated with the previous signature, and used for later module verification. As indicated by arrow 425, step 425 is optional and can be omitted.

  5A-5B show a flowchart of the procedure used by the integrity validator of FIG. 1 to verify individual module signatures. In FIG. 5A, at step 505, the integrity validator receives a signature (and possibly an identifier for the module) for the module. At step 510, this signature is compared to the database. If a module identifier is given, it can be used to reduce the database search area. At step 515, the integrity validator determines whether this signature is found in the database. If found, at step 520, the signature is validated.

  If the integrity validator fails to find this signature in the database, the integrity validator determines in step 525 whether there is another database (or integrity validator) that can validate this signature. . If no suitable database (or integrity validator) is found, at step 530, the signature is rejected as invalid and the process ends. If a suitable database (or integrity validator) is found (or otherwise), the integrity validator sends this signature to that other database (or integrity validator) at step 535. At step 540, the integrity validator determines whether the signature was found in that other database. If found, processing returns to step 520 and the signature is validated. If not, processing returns to step 525 where it is determined whether there is another database (or integrity validator) that can send this signature.

  FIG. 6 shows a flowchart of a procedure used by a computer, such as the computer shown in FIG. 1, to compile the integrity log using the integrity validator shown in FIG. 1 and validate the computer. . In step 605, the integrity log generator identifies modules on the computer system. In step 610, the integrity log generator generates signatures for these modules. Alternatively, the integrity log generator may combine these signatures into an integrity log at step 615. As indicated by arrow 620, step 615 can be omitted. That is, these signatures do not need to be collected into an integrity log. Finally, at step 625, the integrity log generator sends these signatures (and possibly also module identifiers) to the integrity validator for verification.

  7A-7B show a flowchart of the procedure used by the integrity validator shown in FIG. 1 to validate the computer. In FIG. 7A, at step 705, the integrity validator receives a signature (and possibly a module identifier in addition thereto) for verification. In step 710, the integrity validator selects a signature for verification. The selected signature may be the next signature in the sequence. Alternatively, the selected signature may be selected on another basis. The integrity validator attempts to verify the signature at step 715 as described above in connection with FIGS. 5A-5B.

  In step 720 (FIG. 7B), the integrity validator determines whether this signature is valid. If this signature is valid, at step 725, the integrity validator adds this signature to the set of signatures that are found in the database. If the signature is not valid, step 730 adds this signature to the set of signatures not found in the database. In either case, at step 735, the integrity validator checks to see if there are any signatures that have not been verified (should still be verified). If there is a signature that has not been verified, the process returns to step 710 in FIG. 7A. If no unverified signatures remain, at step 740, the integrity validator generates a trust score. As described above in connection with FIG. 2, this trust score can weight certain signatures higher than other signatures in generating the trust score.

  As mentioned above, step 715 is associated with FIGS. 5A-5B in how to verify the signature for the computer system. As described above, FIGS. 5A-5B illustrate the processing of a single signature and sending the signature to another integrity validator if the first integrity validator cannot verify the signature. . This approach works well for individual signatures of multiple signatures, such as those in the integrity log, but in another example, the first integrity validator is used to process as many signatures as possible. And send the signatures that were not validated as a group to the second integrity validator.

  FIG. 8 shows a flowchart of the procedure used by the integrity validator of FIG. 1 to allow or deny access to network resources to a computer such as the computer of FIG. In FIG. 8, as described above in connection with FIGS. 7A-7B, at step 805, the integrity validator generates a trust score for the computer system. At step 810, the integrity validator accesses a policy for the desired resource. In step 815, the integrity validator compares this policy with the trust score. Finally, at step 820, the integrity validator uses this policy to determine the appropriate level of access to the resource for the computer system.

  The following is a brief general description of a suitable machine that implements certain aspects of the invention. Typically, a machine is a system bus to which, for example, a processor, memory (eg, random access memory (RAM), read only memory (ROM), or other state storage medium), storage device, video interface, output / input interface port, etc. are mounted. including. The machine may be controlled, at least in part, by input from a conventional input device such as a keyboard, mouse, and instructions received from another machine, virtual reality (VR) environment, biofeedback, or information exchange with other input signals Is possible. As used herein, the term machine is intended to broadly encompass a single machine or a communication system combined with a machine or device that operates together. Typical machines include computer devices such as personal computers, workstations, servers, portable computers, mobile terminals, phones, tablets, as well as transportation means such as personal or public transportation such as cars, trains, taxis, etc. .

  The machine may also include a built-in controller such as a programmable or non-programmable logic device or array, an application specific integrated circuit (ASIC), a built-in computer, a smart card, or the like. The machine may also utilize one or more connections to one or more remote machines via a network interface, modem or other communication coupling. Further, the machines may be interconnected through physical and / or logical networks such as an intranet, the Internet, a local area network, a wide area network, etc. Those skilled in the art will recognize that network communications may include a variety of wired and / or wireless communication (RF), satellite, microwave oven, Institute of Electrical and Electronics Engineers (IEEE), 545.11, Bluetooth, optical, infrared cable, laser, etc It will be appreciated that wireless short range or long range carriers and protocols can be utilized.

  The present invention can be described with reference to or in conjunction with related data including functions, procedures, data structures, application programs, and the like. These related data, when accessed by a machine, will cause the machine to perform a task or define an abstract data type or low-level hardware context. Relevant data includes, for example, volatile and / or non-volatile memory such as RAM, ROM, or hard drives, floppy disks, optical storage devices, tapes, flash memory, memory sticks, digital video disks, biological storage devices, etc. Can be stored in other storage devices and their associated storage media. Related data is transmitted in the form of packets, serial data, parallel data, propagated signals, etc. in a transmission environment including physical and / or logical networks and can be used in a compressed or encrypted form. Also, relevant data can be used in a distributed environment and stored locally and / or remotely for machine access.

  Although the principles of the present invention have been described and illustrated based on the illustrated embodiments, the illustrated embodiments may be modified in construction and detail without departing from such principles and in any desired manner. It should be understood that these may be combined. And while the above description has focused on specific embodiments, other configurations are possible. In particular, the expression “according to one embodiment of the invention” or similar expression is used herein, but these terms generally mean that it can be a reference example, and the invention It is not intended to be limited to configuration. As used herein, these terms may represent the same or different embodiments that can be combined with other embodiments.

  In conclusion, the detailed description and the accompanying drawings are intended to be exemplary only and should not be construed as limiting the scope of the invention in light of the wide variety of possible substitutions to the embodiments described herein. Absent. Accordingly, all that is claimed by the present invention includes all modifications that do not depart from the scope and spirit of the claims and their equivalents.

Fig. 2 illustrates a system having an integrity validator for performing computer verification. FIG. 2 shows in more detail the integrity validator of FIG. 1 used to perform computer verification. Fig. 3 shows the database of Fig. 2 in more detail. 3 shows a flowchart of the procedure used by the integrity validator of FIG. 1 to build the database of FIG. Fig. 2 shows a flowchart of the procedure used by the integrity validator of Fig. 1 to verify individual module signatures. 1 shows a flowchart of a procedure used by a computer system such as the computer system of FIG. 1 to compile an integrity log using the integrity validator of FIG. 1 and verify the computer system. 2 shows a flowchart of the procedure used by the integrity validator of FIG. 1 to verify a computer system. FIG. 2 is a flowchart of a procedure used by the integrity validator of FIG. 1 to allow or deny access to network resources to a computer system such as the computer system of FIG.

Claims (20)

A database provided for storing a first plurality of signatures for the first plurality of modules;
A receiver for receiving a second plurality of signatures corresponding to the second plurality of modules;
Comparing at least one signature received from the second plurality of signatures with one or more signatures of the plurality of signatures in the database, wherein the corresponding signature is found in the database; A validator operable to identify a first subset of modules and identify a second subset of the second plurality of modules for which a corresponding signature is not found in the database;
Trust based on the first subset of the second plurality of modules for which a corresponding signature is found in the database and the second subset of the second plurality of modules for which a corresponding signature is not found in the database A trust score generator for generating scores;
Having a device.   The apparatus of claim 1, wherein the first plurality of signatures for the first plurality of modules includes a first plurality of hashes for the plurality of modules.   The apparatus further comprises a transmitter for sending a signature corresponding to the second subset of the second plurality of modules for which a corresponding signature is not found in the database to the second database, the receiver , Receiving a second trust score from the second database, wherein the trust score generator applies the first signature of the plurality of modules and the second trust score for which a corresponding signature is found in the database. The apparatus of claim 1, wherein the apparatus is adapted to generate the trust score based thereon.   The database is provided for storing a first plurality of identifiers for the first plurality of modules, and the receiver is operable to receive a second plurality of identifiers for the second plurality of modules. The validator operates to compare the second plurality of signatures with the plurality of signatures in the database using the second plurality of identifiers for the plurality of modules. The apparatus of claim 1.   The apparatus of claim 1, further comprising a policy for controlling access to a resource, wherein the policy includes a threshold score for qualification for full access to the resource.   6. The apparatus of claim 5, further comprising a second threshold score for the policy to qualify for partial access to the resource.   The apparatus of claim 1, wherein the receiver is operative to receive a module signature and add it to the database. Network,
Resources connected to the network;
A computer connected to the network having an integrity log generator for generating an integrity log that includes a first plurality of signatures for the first plurality of modules;
A device connected to the network, the device comprising:
A database provided for storing a second plurality of signatures for the second plurality of modules;
A receiver for receiving the integrity log from the computer;
A trust score generator for generating a trust score based on a comparison of the integrity log and the first plurality of signatures;
A policy for controlling access to the resource, wherein the policy includes a threshold score to qualify for full access to the resource, and the computer access to the resource is A system controlled by the policy.   The system further includes a second device, the second device having a second database provided for storing a third plurality of signatures for the third plurality of modules. And wherein the device comprises a transmitter for sending signatures corresponding to a subset of the first plurality of modules for which no corresponding signature is found in the database to the second device. The system described in.   The system according to claim 9, further comprising a second network, wherein the device and the second device are connected to the second network. Receiving a first plurality of signatures corresponding to a plurality of modules;
Comparing the first plurality of signatures for the plurality of modules with a second plurality of signatures in a database;
Identifying a first subset of the plurality of modules for which a corresponding signature is found in the database and a second subset of the plurality of modules for which a corresponding signature is not found in the database;
Generating a trust score based on the first subset of the plurality of modules for which a corresponding signature is found in the database and the second subset of the plurality of modules for which a corresponding signature is not found in the database; ,
Including methods.   The method of claim 11, further comprising controlling access to resources on the network based on the trust score.   Controlling access to a resource on a network based on the trust score, accessing a policy for access to the resource on the network; and using the policy to control access to the resource based on the trust score. 13. The method of claim 12, comprising the step of controlling.   14. Using the policy to control access to the resource based on the trust score includes allowing full access to the resource if the trust score exceeds a threshold score according to the policy. The method described in 1.   Using the policy to control access to the resource based on the trust score includes partial access to the resource if the trust score is less than a second threshold score and greater than a first threshold score according to the policy. 14. The method of claim 13, comprising the step of granting secure access.   The method of using the policy and controlling access to the resource based on the trust score includes denying access to the resource if the trust score is less than a threshold score according to the policy. The method described.   The method of claim 11, wherein generating the trust score comprises weighting at least a first module more than at least a second module in generating the trust score.   The method of claim 11, wherein receiving the first plurality of signatures includes receiving an integrity log that includes the first plurality of signatures corresponding to the plurality of modules. The method further comprises:
Sending the signature corresponding to the second subset of the plurality of modules for which a corresponding signature is not found in the database to a second database;
A third subset of the plurality of modules for which a corresponding signature is found in the second database and a fourth subset of the plurality of modules for which a corresponding signature is not found in the second database Receiving steps from
Including
The step of generating the trust score includes the first subset of the plurality of modules for which a corresponding signature is found in the database and the third of the plurality of modules for which a corresponding signature is found in the second database. The method of claim 11, comprising generating the trust score based on a subset. Receiving a first plurality of signatures corresponding to the plurality of modules includes receiving the first plurality of signatures and a plurality of identifiers for the plurality of modules;
Comparing the first plurality of signatures for the plurality of modules with a second plurality of signatures in a database comprises comparing the first plurality of signatures for the plurality of modules with the plurality of modules for the plurality of modules. The method of claim 11, comprising comparing with a second plurality of signatures in the database using an identifier.

Images