Method of optimizing policy conformance check for a device with a large set of posture attribute combinations

1. FIELD OF THE INVENTION

The present invention relates generally to the field of networks. The present invention further relates specifically to conforming the integrity of a client device in a network.

2. INTRODUCTION

Electronics devices such as personal computers, laptops, mobile phones, and personal digital assistants (PDAs) may be used to exchange data within a system. A system may comprise an internet protocol (IP) network and a non-internet protocol system portion (which could be a non-IP network). For example, the portion of a cellular telephone system that includes the telephones and cell site transceivers may be typically a non-IP portion of the system, whereas a gateway device in the system may be a bridge between an IP network of the system and a non-IP portion of the system. Further, other network devices may be wholly within an IP network that forms a fixed portion of the cellular telephone system. A network may be a local area network (LAN), a wide area network (WAN), a wireless local area network (WLAN), or a virtual local area network (VLAN). These may be typically IP networks. Unfortunately, the effective operation of a network and the devices attached to it may be threatened by cyber attacks. Some attacks may come directly in the form of hostile Internet traffic, while others may come in the form of “malware” such as viruses, spyware, rootkits, etc. In the past, defending a network at its perimeter was possible, but as the sophistication of the attacks has grown, the defense of a network need encompass not only the network infrastructure itself (routers, switches, load balances, etc.) but also the devices attached to it. This in turn may require that these devices implement particular security configurations and security software (such as anti-virus software). In addition, because security compromises often begin by exploiting known flaws in software, the software packages on these devices should be continually kept up to date. This required configuration may be expressed in a set of security policies for network devices. The electronic devices inside the network should comply with these policies to access the data or information stored in the network.

Furthermore, an electronic device, which is not an element of the network, may need to join the network. Such an electronic device may be known as a client device. In order to ensure safety and integrity of the network, a client device should be given access to the network only when the client device is compliant to the network security policy. In the event that the device is not compliant, the client device should not be given access until it has been remediated, or brought into compliance with policy. This process may be known as “network access control.”

Several methods for network access control are known in the art. In one such method, the client device may report a set of integrity measurements that describe the current status of elements of the client device such as the software, data, and configuration parameters. The report may occur during an access attempt, such as when the device first connects to the network and the identity of the device and its user is established, or authenticated. If the device and user are not successfully authenticated, the device may be denied access to the network. If the device and user are successfully authenticated, the integrity measurements are examined, and the integrity measurements indicate compliance with the security policy, the device may be granted full network access. If the device and user are successfully authenticated but the integrity measurements indicate some variance from the network security policy, the device may be granted limited access so that the device may retrieve software patches and other configuration information to bring itself into compliance.

However, the method just described may be processor intensive and may be employed only on client devices having high bandwidth connections and reasonable tolerance to connectivity latency. Further, the collection of measurement data on the device typically may require that the client device contain some set of software components, or agents, that collect and report the measurement data. This approach may be suitable for devices such as laptops, personal computers, etc. which have large memories, fast processors, and high-bandwidth connections. However, this approach may not scale well to small devices, such as mobile phones, which exhibit more stringent constraints upon processor speed, memory, and communications bandwidth. Further, a fairly small number of variations may exist between types of PCs, laptops, etc., typically a few configurations for, e.g., Windows XP, Windows 2000, MacOS, Linux, etc. By contrast, mobile phones may have much greater diversity, with multiple manufacturers and multiple product lines per manufacturer.

BRIEF DESCRIPTION OF THE DRAWINGS

Understanding that these drawings depict only typical embodiments of the invention and are not therefore to be considered to be limiting of its scope, the invention will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:

<figref idrefs="DRAWINGS">FIG. 1</figref> illustrates one embodiment of a communication system.

<figref idrefs="DRAWINGS">FIG. 2</figref> illustrates in a block diagram one embodiment of the client device.

<figref idrefs="DRAWINGS">FIG. 3</figref> illustrates in a block diagram one embodiment of a certificate of health, or trusted token, that may identify an integrity state of the client device.

<figref idrefs="DRAWINGS">FIG. 4</figref> illustrates in a block diagram one embodiment of a policy cache.

<figref idrefs="DRAWINGS">FIG. 5</figref> illustrates one embodiment of a communication system for conforming integrity of the client device.

<figref idrefs="DRAWINGS">FIG. 6</figref> illustrates in a flowchart one embodiment of a method for an access server to conform integrity of the client device.

<figref idrefs="DRAWINGS">FIG. 7</figref> illustrates in a flowchart one embodiment of a method for a client device to conform its integrity.

<figref idrefs="DRAWINGS">FIG. 8</figref> illustrates in a flowchart one embodiment of a method for an access server to conform integrity of the client device.

<figref idrefs="DRAWINGS">FIG. 9</figref> illustrates in a flowchart one embodiment of a method for a compliance server to conform integrity of the client device.

<figref idrefs="DRAWINGS">FIG. 10</figref> illustrates a possible configuration of a computing system to act as a server to execute the present invention.

<figref idrefs="DRAWINGS">FIG. 11</figref> illustrates in a block diagram one embodiment of a policy database that may be stored in a compliance server.

<figref idrefs="DRAWINGS">FIG. 12</figref> illustrates in a flowchart one embodiment of a method of granting access to the network based on a comparison of the tags.

DETAILED DESCRIPTION OF THE INVENTION

Additional features and advantages of the invention will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. The features and advantages of the invention may be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims. These and other features of the present invention will become more fully apparent from the following description and appended claims, or may be learned by the practice of the invention as set forth herein.

Various embodiments of the invention are discussed in detail below. While specific implementations are discussed, it should be understood that this is done for illustration purposes only. A person skilled in the relevant art will recognize that other components and configurations may be used without parting from the spirit and scope of the invention.

The present invention comprises a variety of embodiments, such as a method, an apparatus, and an electronic device, and other embodiments that relate to the basic concepts of the invention. The electronic device may be any manner of computer, mobile device, or wireless communication device.

A method, apparatus, and electronic device for conforming integrity of a client device are disclosed. An access server may organize a group of policies into sub-groups. The access server may associate each sub-group with a policy tag. The access server may associate each policy tag with a tag timestamp. The access server may extract from a certificate of health a certificate timestamp and a policy tag. The access server may execute a comparison of the certificate timestamp with the tag timestamp. The access server may receive the certificate of health from the client device. The access server may grant access to a network based in part upon the comparison.

The embodiments described herein include methods for network access control suitable for devices with the characteristics of mobile handsets. In particular, rather than the client sending a complete set of integrity measurements, these embodiments define a certificate of health, or trusted token, stored on the client, to bypass the need for communicating the complete set of measurements, wherein the certificate of health may verify that the client device had a qualified set of integrity measurements at a specific time. When seeking access to the network, rather than exchanging the entire set of integrity measurements, the client device may report this certificate of health. When the certificate of health is determined to be valid, the client device may be granted full access to the network. When the certificate of health is determined not to be valid, the client device may be granted only limited access. Further, in the case where the certificate of health is determined not to be valid, the client device may enter a remediation process. The network may identify those integrity measurements that establish a need for updating elements of the client's device, and the client device may pull the necessary updates (or the network may push them) and the client may update those elements.

Various embodiments of the present invention provide a method for a client device to have its integrity conformed. The client device may transmit a certificate of health during a network access attempt. The certificate of health may identify an integrity state of the client device. Further, the client device may enter a remediation process. The remediation process may include receiving a list of required integrity measurements, obtaining these measurements, transmitting those measurements, receiving a set of updates, processing these updates, receiving a new certificate of health, and storing the new certificate of health.

For an embodiment of the present invention, a method for a server to conform integrity of a client device is provided. The server may receive from a client device a certificate of health. The certificate of health may identify an integrity state of the client device. Further, the server may determine whether the integrity state of the client device is current. Furthermore, in the case in which the integrity state of the device is not current, the server may enter a remediation process. The remediation process may include requesting a subset of integrity measurements from the client device that are not current. Moreover, the remediation process may include determining a set of updates from the subset of integrity measurements. Furthermore, the remediation process may include pushing the set of updates to the client device. Finally, the remediation process may include sending a new certificate of health to the client device. The new certificate of health may identify the current integrity state of the client device.

Various embodiments of the present invention describe a client device. The client device may have a transceiver for receiving a certificate of health. The certificate of health may identify an integrity state of the client device. Further, the client device may have a memory module for storing the certificate of health. The transceiver may also transmit the certificate of health during a network access attempt.

<figref idrefs="DRAWINGS">FIG. 1</figref> illustrates one embodiment of a communication system <b>100</b>. The communication system <b>100</b> may include a network <b>102</b> and a client device <b>106</b>. Further, the network <b>102</b> may include a network access server <b>104</b>. Various communication devices may exchange data or information through the network <b>102</b>. The network <b>102</b> may be an internet protocol (IP) network such as a local area network (LAN), a wide area network (WAN), a wireless local area network (WLAN), or it could be any other type of network. Further, a network administrator of the network <b>102</b> may implement various security policies on the network <b>102</b>. Examples of such policies may include versions of software, versions of the data files, versions of antivirus software, configuration parameters, and so forth. These policies may ensure safety and integrity of data or information stored in the network <b>102</b>. The network access server <b>104</b> may be capable of verifying compliance of the client device <b>106</b> with the security policies of the network <b>102</b>, when the client device <b>106</b> tries to access the network <b>102</b>. The network access server <b>104</b> may ensure that the identity and security policies of the client device <b>106</b> (and possibly also the identity of the person using the device) are verified before providing access to the network <b>102</b>. For one embodiment, the network access server <b>104</b> may be a distributed set of servers in the network. The client device <b>106</b> may be one of several types of handheld devices, such as, a mobile phone, a laptop, or a personal digital assistant (PDA). For one embodiment, the client device <b>106</b> may be a WiFi® capable device, a WiMax® capable device, or other wireless devices. The wireless devices may transmit data using cellular packet data formats such as general packet radio service (GPRS), enhanced data rates for global evolution (EDGE), universal mobile telecommunications system (UMTS), evolution data optimized (EvDO) format, or other cellular packet data formats. In one embodiment, the client device <b>106</b> may connect to the network <b>102</b> via a wireline or virtual private network (VPN) access. The WiFi® capable device may be used to access the network <b>102</b> for data or by voice using voice over Internet protocol (VOIP).

<figref idrefs="DRAWINGS">FIG. 2</figref> illustrates in a block diagram one embodiment of the client device <b>106</b>. The client device <b>106</b> may be capable of accessing the information or data stored in the network <b>102</b>. For some embodiments of the present invention, the client device <b>106</b> may also support one or more applications for performing various communications with the network <b>102</b>. The client device <b>106</b> may be a handheld device, such as, a mobile phone, a laptop, or a personal digital assistant (PDA). For some embodiments of the present invention, the client device <b>106</b> may be WiFi® capable device, which may be used to access the network <b>102</b> for data or by voice using VOIP. The client device <b>106</b> may be a wireless device and may receive or transmit a certificate of health wirelessly. The client device <b>106</b> may include a transceiver <b>202</b>, which is capable of sending and receiving data over the network <b>102</b>. The client device <b>106</b> may include a processor <b>204</b> that executes stored programs. The client device <b>106</b> may also include a volatile memory <b>206</b> and a non-volatile memory <b>208</b> which are used by the processor <b>204</b>. The client device <b>106</b> may include a user input interface <b>210</b> that may comprise elements such as a keypad, display, touch screen, and the like. The client device <b>106</b> may also include a user output device that may comprise a display screen and an audio interface <b>212</b> that may comprise elements such as a microphone, earphone, and speaker. The client device <b>106</b> also may include a component interface <b>214</b> to which additional elements may be attached, for example, a universal serial bus (USB) interface. Finally, the client device <b>106</b> may include a power supply <b>216</b>.

<figref idrefs="DRAWINGS">FIG. 3</figref> illustrates in a block diagram one embodiment of a certificate of health <b>300</b>, or trusted token, that may identify an integrity state of the client device <b>106</b>. The certificate of health <b>300</b> may be received by the transceiver <b>202</b>. The integrity state may be a configuration of the client device <b>106</b> that may be altered by downloading information to the client device <b>106</b>. A set of policies, or integrity measurements, may be used to determine the integrity state of the client device <b>106</b>. The policies may include one or more identification parameters for identifying versions of software, versions of data files, configuration parameters, and blowable fuse settings. The certificate of health <b>300</b> may include a certificate timestamp <b>302</b> to identify the date of issuance of the certificate of health by the network. The certificate of health <b>300</b> may include a set of policy tags <b>304</b> corresponding to a sub-group of a group of policies. This set of policy tags <b>304</b> may include one or more combo-tags, a type of policy tag that represents a combination of policy tags.

The certificate of health <b>300</b> may include a client device identifier <b>306</b> to bind the certificate of health <b>300</b> to the mobile device, identifying the certificate of health as belonging to that device and that device alone. Further, the integrity of the certificate of health may be protected by encryption, for example, by using a signed cryptographic hash, or an authentication check <b>308</b>. The non-volatile memory module <b>208</b> may store the certificate of health for later use when the client device <b>106</b> has to access the network <b>102</b>. Further, when the client device <b>106</b> accesses the network <b>102</b>, the transceiver <b>202</b> may transmit the certificate of health <b>300</b> to the access server <b>104</b>.

The access server <b>104</b> may use a group of policies to determine whether a certificate of health <b>300</b> represents a valid integrity state. <figref idrefs="DRAWINGS">FIG. 4</figref> illustrates in a block diagram one embodiment of a policy cache <b>400</b> to store the group of policies. The policy cache <b>400</b> may have a threshold timestamp (THTS) <b>402</b>. The THTS <b>402</b>, when set, may be used to reset all the client devices <b>106</b> with a certificate of health timestamp <b>302</b> prior to the THTS <b>402</b>.

The policy cache <b>400</b> may store a policy tag <b>404</b> that is associated with a subgroup of the group of policies. The policy tag <b>404</b> may represent a characteristic of a client device <b>106</b>, such as client device brand (i.e. Motorola®, Nokia®, Samsung®), network provider (i.e. Verizon®, Sprint®, AT&amp;T®), hardware platform, operating system, role of the user, or other characteristics. The subgroup of policies associated with the policy tag <b>404</b> may relate to the associated characteristic. The policy cache <b>400</b> may associate the policy tag <b>404</b> with one or more tag timestamps. The policy cache <b>400</b> may associate the policy tag <b>404</b> with a critical timestamp (CTS) <b>406</b>. The CTS <b>406</b> may represent the most recent update to a policy associated with the policy tag <b>404</b> that requires an update to the client device <b>106</b> before the client device <b>106</b> is permitted access to the network <b>102</b>. The policy cache <b>400</b> may associate the policy tag <b>404</b> with a non-critical timestamp (NTS) <b>408</b>. The NTS <b>408</b> may represent the most recent update to a policy associated with the policy tag <b>404</b> that does not require an update to the client device <b>106</b> before the client device <b>106</b> is permitted access to the network <b>102</b>. If a certificate of health timestamp <b>302</b> predates the CTS <b>406</b>, the NTS <b>408</b> need not be checked for that policy tag <b>402</b>. Further, the NTS <b>408</b> may be updated when the CTS <b>406</b> is updated.

<figref idrefs="DRAWINGS">FIG. 5</figref> illustrates one embodiment of a communication system <b>500</b> for conforming integrity of the client device <b>106</b>. The system may include the network <b>102</b>, which may include a quarantine network <b>502</b>; the access server <b>104</b>; the client device <b>106</b>; an access router <b>504</b>; a compliance server <b>506</b>; and other network servers <b>508</b>. The access server <b>104</b> and compliance server <b>506</b> may both have access to a policy table <b>400</b>. For one embodiment, the access server <b>104</b> may be integrated with an authentication server, for example, a remote authentication dial-in user server (RADIUS), a Diameter server, terminal access controller access-control system (TACACS+), or other type of authentication server. The client device <b>106</b> may interact with the access router <b>504</b> to access the network <b>102</b>. In one embodiment, the access router <b>504</b> may initiate an extensible authentication protocol (EAP) session to begin the process of authentication and verification of compliance to policies of the network <b>102</b> by the client device <b>106</b>. In a preferred embodiment, the access router <b>504</b> may initiate EAP through a virtual private network (VPN) gateway, an intranet wired access-point, or an intranet wireless access-point. For example, the EAP exchange may occur over a wireless LAN interface compliant with one of the standards promulgated by the Institute of Electrical and Electronic Engineers (IEEE) known as 802.11. As part of the EAP authentication exchange, the client device <b>106</b> may send the client and user authentication information, along with the certificate of health to the intranet wireless access router <b>504</b> in a sequence of EAP messages. On receiving each EAP response from the client device <b>106</b>, the access router <b>504</b> may send an access request, such as a RADIUS access request, along with that EAP response to the access server <b>104</b>. In one embodiment, the access server <b>104</b> may authenticate the client device <b>106</b>. The client device <b>106</b> need not be provided access to the network <b>102</b> if the authentication fails. The authentication may fail when the access server <b>104</b> does not recognize the client device <b>106</b>. If the authentication succeeds, the authentication server may request the certificate of health by sending an appropriate EAP request, and a subsequent EAP response may contain the certificate of health. The access server <b>104</b> may contain a policy table <b>400</b> that contains a tag timestamp for each policy tag <b>304</b>. Upon receipt of the certificate of health, the access server <b>104</b> may determine the integrity state of the client device <b>106</b> by searching the policy table <b>400</b> for entries that match the policy tags <b>304</b> listed in the certificate of health <b>300</b>. If all matching entries have a tag timestamp that predates the certificate timestamp <b>302</b>, the integrity state of the client device <b>106</b> may be deemed current. Based on the integrity state of the certificate of health (current or not current), the client device <b>106</b> may be granted access either to the main network <b>102</b> or only the quarantine network <b>502</b> by the access router <b>504</b>. The access router <b>504</b> may be directed to provide appropriate access to the client device <b>106</b> by the access server <b>104</b>. The access of the client device <b>106</b> may thus be restricted to the quarantine network <b>502</b>, for the purpose of attempting to update the client device <b>106</b> and the certificate of health <b>300</b>, when the certificate of health <b>300</b> of the client device <b>106</b> is not current. When the certificate of health <b>300</b> of the client device <b>106</b> is current, the access server <b>104</b> may send a success response, such as a RADIUS access-accept response, to the access router <b>504</b>, with an attribute stating that the client device <b>106</b> may be provided access to the main network <b>102</b> and the client device <b>106</b> may be considered to be operating in the full-access network <b>512</b>. When the certificate of health <b>300</b> of the client device <b>106</b> is not current, the access server <b>104</b> sends a success response to the access router <b>504</b>, with an attribute stating that the client device <b>106</b> may be provided access only to the quarantine network <b>502</b>. When restricted to accessing the quarantine network <b>502</b>, the client device <b>106</b> may access only the compliance server <b>506</b>, whereas when the client is operating in the full-access network <b>512</b>, the client device may access database server and electronic-mail and other web applications server of the network <b>102</b>.

When the access server <b>104</b> authenticates the client device <b>106</b>, but the access server <b>104</b> determines that the integrity state represented by the certificate of health <b>300</b> is not current, a further process may be initiated to verify the integrity state of the client device <b>106</b>, apply updates to bring it into policy compliance, and update the certificate of health <b>300</b>. For this process, the client device <b>106</b> may be provided access to the quarantine network <b>502</b> as stated above. The quarantine network <b>502</b> may include a compliance server <b>506</b>. The compliance server <b>506</b> may be used to request and receive integrity measurements from the client device <b>106</b> and to verify those measurements against the current policy for that type of device. Further, the compliance server <b>506</b> may determine a set of updates that are required to bring the client device <b>106</b> back into compliance with policy. Further, the compliance server <b>506</b> may be used for updating the certificate of health. The compliance server <b>506</b> may construct a new certificate of health <b>300</b>, which is updated and current. The updated certificate of health <b>300</b> may be sent to the client device <b>106</b>. Further, the client device <b>106</b> may use the updated certificate of health for accessing the network <b>102</b>. For one embodiment, communication with the client device <b>106</b> for configuration management and certificate of health provisioning may be realized using a device management protocol, such as open mobile alliance (OMA) device management (DM) protocol, mobility service platform (MSP)®, SOTI®, or others.

<figref idrefs="DRAWINGS">FIG. 6</figref> illustrates in a flowchart one embodiment of a method <b>600</b> for an access server to conform integrity of the client device <b>106</b>. The access server <b>104</b> may authenticate the device and user (Block <b>602</b>). In an exemplary implementation, this authentication may occur using an EAP authentication exchange. When authentication fails, the access server <b>104</b> may deny network access to the client device <b>106</b> (Block <b>604</b>). The client device <b>106</b> may try to authenticate again later. When authentication succeeds, the access server <b>104</b> may direct the client device <b>106</b> to examine its non-volatile memory <b>208</b> to determine if a certificate of health (COH) <b>300</b> is stored there (Block <b>606</b>). If the client device <b>106</b> has a COH <b>300</b>, the access server <b>104</b> may receive the COH <b>300</b> from the client device <b>106</b> (Block <b>608</b>). In an exemplary implementation, this access server may receive the COH <b>300</b> using EAP. The access server <b>104</b> may transmit the authentication status to the client device <b>106</b> (Block <b>610</b>). In an exemplary implementation, this authentication status may be represented as an EAP message, such as an EAP-success if full access or quarantine access is granted or an EAP-failure if the authentication fails. The access server <b>104</b> may further examine the authentication status to determine whether the device is to be quarantined (Block <b>612</b>). If the device is to be quarantined, the access server <b>104</b> may grant the client device <b>106</b> access to the quarantine network <b>502</b> (Block <b>614</b>). The access server may initiate the extended remediation process, as part of a compliance process (Block <b>616</b>). If the device is not quarantined (Block <b>612</b>), the access server <b>104</b> may grant the client device <b>106</b> full access to the network (Block <b>618</b>).

<figref idrefs="DRAWINGS">FIG. 7</figref> illustrates in a flowchart one embodiment of a method <b>616</b> for a client device <b>106</b> to conform its integrity. The client device <b>106</b> may receive a list of integrity measurement requests from the compliance server <b>506</b> (Block <b>702</b>). The list of integrity measurement requests may include parameters for identifying versions of software, versions of data files, configuration parameters, blowable fuse settings, and other parameters. For one embodiment of the present invention, a device management protocol, such as OMA DM protocol, MSP®, SOTI®, and other device management protocols, may be used to transfer this list of measurement requests from the compliance server <b>506</b> to the client device <b>106</b>. The client device <b>106</b> may examine the list of measurement requests to determine whether it is empty (Block <b>704</b>). If the list of measurement requests is not empty (Block <b>704</b>), the client device <b>106</b> may take at least one of the requested measurements (Block <b>706</b>) and send them to the compliance server <b>506</b> (Block <b>708</b>). For one embodiment, the device management protocol may be used to transfer the measurements to the compliance server <b>506</b>. The cycle may repeat until the list of measurement requests from the compliance server <b>506</b> is empty. If the list of measurement requests is empty (Block <b>704</b>), the client device <b>106</b> may receive and process a set of updates from the compliance server <b>506</b> (Block <b>710</b>). For example, these updates may include new software packages, new versions of existing software packages, new or updated configuration files or databases (such as a new virus signature database), updated configuration parameters, and other updates. The client device <b>106</b> may process these updates as according to their kind (Block <b>710</b>). For example, new or updated configuration files may be written, and configuration parameters may be altered to new values, respectively. For one embodiment, the device management protocol may be used to transfer the updates to the client device <b>106</b> and cause them to be processed. When the updates are complete, the client device <b>106</b> may receive and store a new COH <b>300</b> from the compliance server <b>506</b> (Block <b>712</b>). This COH <b>300</b> may represent the new integrity state of the client device as established by the updates.

<figref idrefs="DRAWINGS">FIG. 8</figref> illustrates in a flowchart one embodiment of a method for an access server <b>104</b> to conform integrity of the client device <b>106</b>. The access server <b>104</b> may receive a COH <b>300</b> from the client device <b>106</b> (Block <b>802</b>). If the client device <b>106</b> does not currently possess a COH <b>300</b>, an indication of a missing COH <b>300</b> may be sent. When present, the COH <b>300</b> may identify an integrity state of the client device <b>106</b>. The access server <b>104</b> may determine if the COH <b>300</b> is present (Block <b>804</b>). If so, a policy table, such as policy table <b>400</b>, may be examined to determine whether the COH <b>300</b> represents a valid integrity state (i.e., is current), as previously described (Block <b>806</b>). If, for each of the policy tags <b>304</b> in the COH <b>300</b>, the policy table <b>400</b> contains an entry with a timestamp that predates the certificate timestamp <b>302</b>, then the COH <b>300</b> may be deemed current (Block <b>808</b>). If the COH <b>300</b> is current (Block <b>808</b>), then the integrity of the client device <b>106</b> may be confirmed. If the COH <b>300</b> is not current (Block <b>808</b>), the access server <b>104</b> may perform an extended remediation process (Block <b>810</b>).

<figref idrefs="DRAWINGS">FIG. 9</figref> illustrates in a flowchart one embodiment of a method <b>810</b> for an extended remediation process for a compliance server <b>506</b> to conform integrity of the client device <b>106</b>. The compliance server <b>506</b> may examine the COH <b>300</b> to determine the current integrity state of the client device <b>106</b> (Block <b>902</b>). The integrity state may include a policy that represents a set of integrity measurements. The set of integrity measurements may include parameters for identifying versions of software, versions of data files, configuration parameters, blowable fuse settings, and parameters. Because the COH <b>300</b> does not represent a current integrity state, a subset of the integrity measurements represented by the COH <b>300</b> may be no longer current. The compliance server <b>506</b> may determine the subset of integrity measurements that is not current by comparing the set of integrity measurements represented by the policy tags <b>304</b> with the current set of integrity measurements for the predefined class of client devices. The compliance server <b>506</b> may request the set of integrity measurements that are not current from the client device <b>106</b> (Block <b>904</b>). For one embodiment of the present invention, a device management protocol may be used for requesting the client device <b>106</b> for a subset of integrity measurements that are not current. The device management protocol may be OMA DM protocol, MSP®, SOTI®, or other device management protocols. The compliance server <b>506</b> may determine a set of updates (Block <b>906</b>). The set of updates may be determined from the subset of integrity measurements. The compliance server <b>506</b> may push the set of updates to the client device (Block <b>908</b>). The set of updates may be an updating of the version of software and data files stored on the client device <b>106</b>, configuration parameters, and blowable fuse settings. For one embodiment of the present invention, a device management protocol may be used to push the updates. The compliance server <b>506</b> may create a new COH <b>300</b> representing the new integrity state of the client device <b>106</b> and push the new COH to the client device <b>106</b> (Block <b>910</b>). Upon completion of this remediation process, the client device <b>106</b> may be granted full access to the main network <b>102</b>.

The method and system described herein may be used for conforming integrity of lightweight client devices, such as, mobile phones and other handheld devices. A preferred embodiment of the present invention may use the framework defined by the extensible authentication protocol and IEEE 802.1x. Further, the present invention may shift the majority of processor intensive task from the client device to a fixed-end server. The client device may need to store only a COH created by the server. Further, the integrity of the COH may be protected using binding techniques, such as signed cryptographic hashes. The creation of a valid COH may be limited to the server in possession of the private key. Because the COH may contain a client device identifier <b>306</b>, a valid COH on one device may not be transferable to another.

<figref idrefs="DRAWINGS">FIG. 10</figref> illustrates a possible configuration of a computing system <b>1000</b> to act as a server to execute the present invention. The computer system <b>1000</b> may include a controller/processor <b>1010</b>, a memory <b>1020</b>, a policy cache <b>1030</b> (described above as policy cache <b>400</b>), a compliance server interface <b>1040</b>, input/output device interface <b>1050</b>, and a network interface <b>1060</b>, connected through bus <b>1070</b>. The computer system <b>1000</b> may implement any operating system, such as Microsoft Windows®, UNIX, or LINUX, for example. Client and server software may be written in any programming language, such as C, C++, Java or Visual Basic, for example. The server software may run on an application framework, such as, for example, a Java® server or .NET® framework

The controller/processor <b>1010</b> may be any programmed processor known to one of skill in the art. However, the decision support method can also be implemented on a general-purpose or a special purpose computer, a programmed microprocessor or microcontroller, peripheral integrated circuit elements, an application-specific integrated circuit or other integrated circuits, hardware/electronic logic circuits, such as a discrete element circuit, a programmable logic device, such as a programmable logic array, field programmable gate-array, or the like. In general, any device or devices capable of implementing the decision support method as described herein can be used to implement the decision support system functions of this invention.

The memory <b>1020</b> may include volatile and nonvolatile data storage, including one or more electrical, magnetic or optical memories such as a random access memory (RAM), cache, hard drive, or other memory device. The memory may have a cache to speed access to specific data. The memory <b>1020</b> may also be connected to a compact disc-read only memory (CD-ROM), digital video disc-read only memory (DVD-ROM), DVD read write input, tape drive or other removable memory device that allows media content to be directly uploaded into the system.

The Input/Output interface <b>1050</b> may be connected to one or more input devices that may include a keyboard, mouse, pen-operated touch screen or monitor, voice-recognition device, or any other device that accepts input. The Input/Output interface <b>1050</b> may also be connected to one or more output devices, such as a monitor, printer, disk drive, speakers, or any other device provided to output data.

The network interface <b>1060</b> may be connected to a communication device, modem, network interface card, a transceiver, or any other device capable of transmitting and receiving signals over a network. The network interface <b>1060</b> may be used to connect a client device to a network or a quarantine network. The compliance server interface <b>1040</b> may be implemented as software on top of the network interface <b>1060</b> to interact with the compliance server <b>506</b>. The components of the computer system <b>1000</b> may be connected via an electrical bus <b>1070</b>, for example, or linked wirelessly.

Client software and databases may be accessed by the controller/processor <b>1010</b> from memory <b>1020</b>, and may include, for example, database applications, word processing applications, as well as components that embody the decision support functionality of the present invention. The computer system <b>1000</b> may implement any operating system, such as Microsoft Windows®, LINUX, or UNIX, for example. Client and server software may be written in any programming language, such as C, C++, Java or Visual Basic, for example.

The access server <b>504</b> may gather policies into a sub-group of the overall group of the policies stored in the policy cache and associate the sub-group with a policy tag <b>404</b>. The tag may be used to make a quicker determination as to which policies are out of date. The certificate of health <b>300</b> may include a list of all policy tags <b>304</b> that may be associated with the client device <b>106</b>. The policy tags <b>304</b> may also include a combo-tag, representing a group of tags. The combo-tags may be considered a subset of the policy tags <b>304</b>. Each policy tag or combo tag may be associated with a tag timestamp or combo tag time stamp, representing the last time a policy associated with that tag or combo tag has been updated. Further, the policy cache <b>400</b> may organize these policies in an order to facilitate searching based upon these tags.

<figref idrefs="DRAWINGS">FIG. 11</figref> illustrates in a block diagram one embodiment of a policy database <b>1100</b> that may be stored in a compliance server <b>506</b>. The policy database <b>1100</b> may store a group of policies <b>1102</b> for a network <b>102</b>. The policy database <b>1100</b> may be used to set up the policy cache <b>400</b>. Each policy <b>1102</b> may be associated with a set of combo-tags <b>1104</b> and policy tags <b>1106</b>. Each policy <b>1102</b> may be associated with multiple combo-tags <b>1106</b> or policy tags <b>1106</b>. Each policy tag <b>1106</b> may represent a specific characteristic of a client device <b>106</b>. Each combo-tag <b>1104</b> may represent a combination of specific characteristics for a client device <b>106</b>. For example, a first policy tag <b>1106</b> may be for a given network provider and a second policy tag <b>1106</b> may be for a given device manufacturer. A combo-tag may exist for a client device <b>106</b> that has both that network provider and device manufacturer.

The policy database <b>1100</b> may associate the policy <b>1102</b> with a policy critical timestamp (PCTS) <b>1108</b>. The PCTS <b>1108</b> may represent the most recent update to a policy that requires an update to the client device <b>106</b> before the client device <b>106</b> is permitted access to the network <b>102</b>. The policy database <b>1100</b> may associate the policy <b>1102</b> with a policy non-critical timestamp (PNTS) <b>1110</b>. The PNTS <b>1110</b> may represent the most recent update to a policy that does not require an update to the client device <b>106</b> before the client device <b>106</b> is permitted access to the network <b>102</b>.

The policy database <b>1100</b> may be associative, so that a policy <b>1102</b> may be looked up by policy <b>1102</b> or by policy tag <b>1106</b>. A lookup table <b>1112</b> may be used to organize items by policy tag <b>404</b>. The lookup table <b>1112</b> may connect each policy tag <b>404</b> with every policy <b>1102</b> associated with that policy tag <b>404</b>. The lookup table <b>1112</b> may associate each policy tag <b>404</b> with the most recent PCTS <b>1108</b> and the PNTS <b>1110</b>, storing each as the CTS <b>406</b> and the NTS <b>408</b>.

The policy database <b>1100</b> may maintain a device type table <b>1114</b> to associate a device type <b>1116</b>, representing a group of similar devices, with a set of policy tags <b>404</b> that constitute the complete set of policies for that device type. This set of policy tags <b>404</b> may be stored in a priority order to specify the policy tag <b>404</b> that controls if the policies designated by these tags ever conflict. The policy database <b>1100</b> may further maintain a device identifier table <b>1118</b> storing each unique device identifier <b>1120</b> of a client device <b>106</b> associated with the network <b>102</b>. The device identifier table <b>1118</b> may associate each device identifier <b>1120</b> with a device type <b>1116</b>. An access server <b>104</b> may use the device identifier table <b>1118</b> and the device type table <b>1114</b> when interacting with a client device <b>106</b> seeking to access the network <b>102</b> that lacks the COH <b>300</b>. The access server <b>104</b> may use the unique device identifier <b>1120</b> of the client device <b>106</b> to determine the necessary set of policies <b>1102</b> and thus the set of policy tags <b>304</b> to be included in a COH <b>300</b>. Alternative to the device identifier table <b>1118</b>, each client device <b>106</b> may store a device type <b>1114</b> and present the device type <b>1114</b> to the access server <b>104</b> upon the first access attempt.

<figref idrefs="DRAWINGS">FIG. 12</figref> illustrates in a flowchart one embodiment of a method <b>1200</b> of granting access to the network <b>102</b> based on a comparison of a tag timestamp with a COH timestamp (COH TS) <b>302</b>. The access server <b>104</b> may use a “Quarantine” flag and a “Remediate” flag to indicate actions to be taken with a client device <b>106</b> seeking to access a network <b>102</b>. The access server <b>104</b> may set the “Quarantine” flag and the “Remediate” flag to “FALSE”, indicating these actions are not to be taken (Block <b>1202</b>). If the COH TS <b>302</b> does not postdate the THTS <b>402</b> (Block <b>1204</b>), the access server <b>104</b> may set the “Quarantine” flag and the “Remediate” flag to “TRUE”, indicating these actions are to be taken (Block <b>1206</b>). If the COH TS <b>302</b> postdates the THTS <b>402</b> (Block <b>1204</b>), the access server <b>104</b> may extract a policy tag list <b>304</b> from the COH <b>300</b> (Block <b>1208</b>). The access server <b>104</b> may select a policy tag <b>304</b> from the list (Block <b>1210</b>). The access server <b>104</b> may also derive a combo-tag representing a grouping of policy tags in the list <b>304</b>. The access server <b>104</b> may look up the policy tag <b>304</b> in the policy cache <b>400</b> (Block <b>1212</b>). If the COH TS <b>302</b> postdates the CTS <b>406</b> (Block <b>1214</b>) and the NTS <b>408</b> (Block <b>1216</b>) and not all the policy tags <b>304</b> have been looked up (Block <b>1218</b>), the access server <b>104</b> select a new policy tag <b>304</b> from the list (Block <b>1210</b>). If the COH TS <b>302</b> does not postdate the CTS <b>406</b> (Block <b>1214</b>), the access server <b>104</b> may set the “Quarantine” flag to “TRUE” (Block <b>1220</b>). If the COH TS <b>302</b> does not postdate the CTS <b>406</b> (Block <b>1214</b>) or the NTS <b>408</b> (Block <b>1216</b>), the access server <b>104</b> may set the “Remediate” flag to “TRUE” (Block <b>1222</b>).

Although not required, the invention is described, at least in part, in the general context of computer-executable instructions, such as program modules, being executed by the electronic device, such as a general purpose computer. Generally, program modules include routine programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Moreover, those skilled in the art will appreciate that other embodiments of the invention may be practiced in network computing environments with many types of computer system configurations, including personal computers, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like.

Embodiments may also be practiced in distributed computing environments where tasks are performed by local and remote processing devices that are linked (either by hardwired links, wireless links, or by a combination thereof) through a communications network.

Embodiments within the scope of the present invention may also include computer-readable media for carrying or having computer-executable instructions or data structures stored thereon. Such computer-readable media may be any available media that may be accessed by a general purpose or special purpose computer. By way of example, and not limitation, such computer-readable media may comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which may be used to carry or store desired program code means in the form of computer-executable instructions or data structures. When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or combination thereof) to a computer, the computer properly views the connection as a computer-readable medium. Thus, any such connection is properly termed a computer-readable medium. Combinations of the above should also be included within the scope of the computer-readable media.

Computer-executable instructions include, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. Computer-executable instructions also include program modules that are executed by computers in stand-alone or network environments. Generally, program modules include routines, programs, objects, components, and data structures, etc. that perform particular tasks or implement particular abstract data types. Computer-executable instructions, associated data structures, and program modules represent examples of the program code means for executing steps of the methods disclosed herein. The particular sequence of such executable instructions or associated data structures represents examples of corresponding acts for implementing the functions described in such steps.

By gathering a sub-group of the group of policies and associating the sub-group with a policy tag, the access server may validate the certificate of health quickly, minimizing the delays during network access. Further, the access server may minimize memory required to store the combinations of groups and their timestamps. The access server may also improve scalability of the policy management system.

Although the above description may contain specific details, they should not be construed as limiting the claims in any way. Other configurations of the described embodiments of the invention are part of the scope of this invention. For example, the principles of the invention may be applied to each individual user where each user may individually deploy such a system. This enables each user to utilize the benefits of the invention even if any one of the large number of possible applications do not need the functionality described herein. In other words, there may be multiple instances of the electronic devices each processing the content in various possible ways. It does not necessarily need to be one system used by all end users. Accordingly, the appended claims and their legal equivalents should only define the invention, rather than any specific examples given.