Patent Publication Number: US-2011060806-A1

Title: Using in-the-cloud storage for computer health data

Description:
CROSS-REFERENCE TO RELATED APPLICATION(S) 
     This application claims priority to and incorporates by reference in its entirety U.S. Provisional Patent Application No. 61/165,445, entitled USING IN-THE-CLOUD STORAGE FOR COMPUTER HEALTH DATA, filed on Mar. 31, 2009. 
    
    
     BACKGROUND 
     A network access control (NAC) device is used to limit a computer&#39;s access to a network in accordance with one or more administrator-defined policies. These policies may include, for example, limiting the types of protocols, network services, servers, or other network devices that a connected computer is permitted to access. 
     A conventional NAC device determines whether and how to enforce network access control based on information provided to the NAC device by connected computers. An example of such network access control is user-based authentication—the NAC device may only allow full network access if a user of a connecting device has authenticated to the network and has the appropriate access privileges. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a block diagram of an environment in which aspects of the described technology may operate. 
         FIG. 2  is a flow diagram of a process for storing device health data in local persistent memory and on an online service. 
         FIG. 3  is a block diagram of a snapshot data structure for storing device health data. 
         FIG. 4  is a flow diagram of a process for initializing a policy enforcement point. 
     
    
    
     DETAILED DESCRIPTION 
     In most networks, several different components work together to determine the level of access that should be granted to a computer. A wired (e.g., Ethernet) switch or wireless access point typically provides a bridge between the computer and these components, providing or denying access to the computer. These access points generally operate in an unsophisticated manner, simply enforcing access permissions provided by a policy server, by either using access control lists (ACLs) or assigning computers to certain virtual local area networks (VLANs). Access points generally have a limited amount of persistent storage, usually in the form of slower flash memories. Most access points do not have hard disk memory. Accordingly, methods and systems for controlling access to a network without relying exclusively on the persistent storage capabilities of access points are desired. 
     To address these and other drawbacks in existing networks, methods and systems for using inthe-cloud storage for computer health data are described herein. A policy enforcement point (PEP) controls access to a network in accordance with one or more policy statements that specify conditions for compliant devices. When a device attempts to gain access to a network controlled by the PEP, the PEP interrogates the device to obtain current health data. This health data may include an anti-virus protection level, system update version, and/or configuration. In some cases, software running on the device performs the interrogation and provides health data to the PEP. If the current health data complies with the policy statements, the device is permitted to access the network. Otherwise, the device is denied access to the network, or permitted only limited access to the network in order to resolve its compliance issues. For example, the out-of-compliance device may be permitted to access a certain set of network servers in order to resolve its compliance issues. Once the device is in compliance with the policy statements, it is permitted to access the network. 
     When the PEP receives current health data from a device, the PEP stores this health data in local volatile memory. The PEP uses the data stored in local volatile memory to control access to the network in accordance with the policy statements. However, because information stored in volatile memory is lost when power to the memory is lost, the PEP occasionally stores the health data in local persistent memory. In addition, to reduce the number of times the PEP must write to local persistent memory while nonetheless preserving the consistency of information against an unplanned reboot, the PEP stores the collected health data on an online service (OLS). During reboot, the PEP accesses the OLS to confirm that it has the most recent health data. If more recent health data is available from the OLS, the OLS provides this more recent data to the PEP. 
     Various embodiments of the technology will now be described. The following description provides specific details for a thorough understanding and an enabling description of these embodiments. One skilled in the art will understand, however, that the described technology may be practiced without many of these details. Additionally, some well-known structures or functions may not be shown or described in detail, so as to avoid unnecessarily obscuring the relevant description of the various embodiments. The terminology used in the description presented below is intended to be interpreted in its broadest reasonable manner, even though it is being used in conjunction with a detailed description of certain specific embodiments of the technology. 
       FIG. 1  is a block diagram of an environment  100  in which aspects of the technology described herein may operate. A policy enforcement point (PEP)  105  controls access to a network comprising one or more network servers  125 , one or more compliance servers  120 , and one or more devices  110   a - 110   n . The PEP  105  is a health-specific appliance, a generalized network access control (NAC) appliance, or other networking element that includes health NAC functionality, such as a network switch or proxy server. In some embodiments, the PEP  105  comprises both volatile and persistent memory. Volatile memory may include any type of tangible computer-readable media, including static or dynamic random access memory (SRAM or DRAM) and/or other types of volatile computer-readable media. Persistent memory may include any type of tangible computer-readable media, including flash memory, read-only memory (ROM), magnetic computer storage devices (e.g., hard disks), optical discs, and/or other types of persistent computer-readable media. 
     The PEP  105  receives policy data from a policy server  115 . Policy data comprises one or more administrator-defined policy statements that specify conditions with which a device must comply in order to gain access to the network controlled by the PEP  105 . For example, a policy statement may specify an anti-virus protection level, a system update version, a device configuration, and/or other parameter associated with a device. If a device does not comply with the policy statements associated with the network, the device is denied access to the network, or permitted only limited access to the network in order to resolve its compliance issues. Once the device is in compliance with the policy statements, it is permitted to access the network. 
     The PEP  105  is coupled to devices  110   a - n  seeking to access the network. In some embodiments, a device  110  is a computer system comprising a processor and memory. In some embodiments, this computer system is a network host that is coupled to one or more additional computer systems seeking to access the network. Although not required, aspects of the technology may be described herein in the general context of computer-executable instructions, such as routines executed by a general or special purpose data processing device (e.g., a server or client computer). Those skilled in the art will appreciate that the described technology can be practiced with other computer system configurations, including mobile devices, Internet appliances, multi-processor systems, mainframe computers, and/or other computer system configurations. Alternatively or additionally, the described technology can be embodied in a special purpose computer or data processor that is specifically programmed, configured, and/or constructed to perform one or more of the computer-executable instructions described herein. 
     Alternatively or additionally, computer implemented instructions, data structures and other data related to the technology may be distributed over the Internet or other network, on a propagated signal on a propagation medium (e.g., an electromagnetic wave(s), a sound wave, etc.) over a period of time. In some implementations, the data may be provided on any analog or digital network (e.g., a packet switched, circuit switched, or other network scheme) and its contingent components, such as routers, switches, radio or optical transceivers or receivers, etc. 
     The described technology can also be practiced in distributed computing environments, where tasks or modules are performed by remote processing devices, which are linked through a communications network, such as a LAN, WAN, the Internet, or other communications network. In a distributed computing environment, program modules or sub-routines may be located in both local and remote memory storage devices. In addition, those skilled in the art will recognize that portions of the described technology may reside on a server computer, while corresponding portions reside on a client computer. 
     Returning to  FIG. 1 , the PEP  105  receives current health data from the devices  110  seeking to access the network. Health data may include an anti-virus protection level, a system update version, a device configuration, and/or other parameter associated with the device  110 . Devices  110  may include diagnosed devices  110   a ,  110   b , and  110   n  for which the PEP  105  has determined network access levels, and undiagnosed devices  110   b  for which the PEP has not determined network access levels. 
     If the current health data submitted by a device  110  complies with the policy data defined by the policy server  115 , the device  110  is permitted to access the network controlled by the PEP  105 . In some embodiments, device  110  is permitted to access the entire network controlled by the PEP  105 , while in other embodiments, the device is permitted to access only a certain portion of the network. For example, based on a particular device  110  parameter (e.g., anti-virus protection level), the device may be permitted to access certain network servers  125  and/or other devices  110 , while it is denied access to certain other network servers and/or other devices. 
     If the current health data submitted by the device  110  does not comply with the policy statements defined by the policy server  115 , the device may be denied access to the network controlled by the PEP  105 . Alternatively, the device  110  may be permitted to access one or more compliance servers  120  in order to resolve its compliance issues. For example, a compliance server  120  may provide the device  110  with an anti-virus update, system update, and/or other component required to comply with the policy statements defined by the policy server  115 . Once the device  110  is in compliance, it is permitted to access the network controlled by the PEP  105 . 
     The PEP  105  provides the policy and health data it collects to an online service (OLS)  135  via an Internet gateway  130  coupled to the Internet  140 . While the Internet  140  is depicted in the illustrated embodiment, one skilled in the art will appreciate that a variety of other networks may be used, including a wide area network (WAN) or a local area network (LAN). The OLS  135  groups and persistently stores the policy and health data provided by the PEP  105 . 
     In some embodiments, a device  110  may provide its current health data directly to the OLS  135 . For example, if the device&#39;s  110  connection to the PEP  105  is disabled, but the device is still connected to the Internet, the device  110  may directly communicate with the OLS  135 . For instance, if a user takes his or her laptop computer to an Internet café, the computer may provide current health data to the OLS  135  via a cell network card coupled to the computer. When the device  110  is reconnected to the PEP  105 , the PEP may permit or deny the device access to the network based on the health data received by the OLS  135 . 
     As described above, the PEP  105  receives current health data from one or more devices  110 . When the current health data is received, the PEP stores this data in local volatile memory. The PEP  105  uses the data stored in local volatile memory to control access to the network in accordance with the policy data received from the policy server. However, information stored in volatile memory is lost when power to the memory is lost. Accordingly, the PEP  105  occasionally stores the health data in local persistent memory, which retains stored information even when power to the memory is lost. This pattern of data storage is well suited for flash-based persistent memory, where the number of available write cycles is limited. In addition, because the persistent memory capabilities of the PEP  105  may be limited, the PEP also stores the health data on the OLS  135 . Such storage of health data allows the PEP  105  to maintain a consistent policy application after the PEP is rebooted. 
       FIG. 2  is a flow diagram of a process  200  by which the PEP  105  stores health data on local persistent memory and the OLS  135  in accordance with embodiments of the described technology. At a block  205 , the PEP  105  writes the health data stored in local volatile memory to local persistent memory. In some embodiments, the PEP  105  writes this health data to local persistent memory on a periodic basis, such as once per given time period (e.g., number of days or hours). Alternatively or additionally, the PEP  105  writes the health data to local persistent memory upon a planned shutdown or reboot of the PEP, along with the timestamp of the most recent health data received from the OLS  135 , as described in additional detail herein. 
     As described above, in some embodiments, the PEP  105  uses flash-based persistent memory. Flash-based persistent memory can only be written a finite number of times before it ceases to function. Accordingly, in such embodiments, the PEP  105  may write the health data to its persistent memory in a manner that preserves the ability to use the persistent memory for the operational lifetime of the PEP, such as once per day or other time period. 
     At a block  210 , the PEP  105  collates the received health data in local persistent memory to generate a snapshot.  FIG. 3  is a block diagram of a suitable snapshot data structure  300 . The data structure  300  includes a device identifier (ID) column  305  comprising indications of devices for which current health data have been received. In some embodiments, the device ID is a unique alphanumeric string that identifies the associated device. The data structure  300  also includes columns  310 - 320  corresponding to device health data parameters  1 - m . For example, column  310  may correspond to an anti-virus protection level; column  315  to a system update version; and column  320  to a device operating system. These parameters are provided for illustrative purposes only, and are not intended to limit the described technology. Records  325 - 340  are generated for each device for which the PEP  105  has received current health data. 
     Returning to  FIG. 2 , at a block  215 , the PEP  105  compresses the generated snapshot according to at least one well known compression and/or encryption algorithm. At a block  220 , the PEP  105  transmits the compressed snapshot to the OLS  135  via a reliable Internet or other network protocol. In some embodiments, the PEP  105  transmits the snapshot to the OLS  135  on a periodic basis, such as once per given time period (e.g., number of days or hours). Alternatively or additionally, each time the health data received from a device  110  changes, the PEP  105  sends an indication of this change to the OLS  135 . 
     When the snapshot is received by the OLS, it sends a confirmation message to the PEP  105  indicating that the transmission was received successfully. At a block  225 , the PEP  105  determines whether it has received confirmation from the OLS  135 . If so, the process  200  ends. Otherwise, the process  200  returns to block  220 , where the PEP  105  retransmits the snapshot until a transmission confirmation is received from the OLS  135 . 
     As described above, when the PEP  105  undergoes a planned shutdown or reboot, the PEP writes the current health data stored in local volatile memory to local persistent memory. A planned reboot is performed in accordance with a normal operating process of the PEP  105 . However, the PEP  105  may also be shut down or rebooted in an unplanned manner. An unplanned reboot may be caused by a power failure, software bug, and/or other event outside of the normal operating process of the PEP. In order to preserve the consistency of information against an unplanned reboot, while reducing the number of times the PEP  105  must write to local persistent memory, among other benefits, the PEP stores the collected health data on the OLS  135 , as described above. 
       FIG. 4  is a flow diagram of a process by which the PEP  105  initializes after a planned or unplanned reboot in accordance with some embodiments of the described technology. At a block  405 , the PEP  105  attempts to contact the OLS  135 . In various embodiments, the PEP  105  automatically contacting the OLS  135 , or presents an administrator with an option to contact the OLS to download the most recent snapshot from the OLS. 
     At a decision block  410 , the PEP  105  determines whether contact is made with the OLS  135 . If so, at a block  415  the PEP  105  sends a request to the OLS  135  along with the timestamp of the most recent health data received from the OLS. The OLS  135  compares the received timestamp with a timestamp associated with the most recent health data stored by the OLS. If the OLS  135  contains more recent health data, it sends this more recent data to the PEP  105 . 
     At a block  420 , the PEP  105  determines whether more recent health data was received from the OLS  135 . If more recent health data was received, at a block  425 , the PEP  105  initializes with this more recent data. Otherwise, at a block  430 , the PEP  105  initializes using the most recent information stored in local persistent memory. Initialization comprises storing the most recent health data in local persistent memory and local volatile memory. The PEP  105  is then operated in accordance with the data stored in local volatile memory. 
     If at decision block  410  contact was not made with the OLS  135 , at a block  435 , the PEP  105  initializes using the most recent information stored in local persistent memory. Because contact was not made with the OLS  135 , the PEP  105  is not able to confirm that it has the most recent health data. Accordingly, at a decision block  440 , the PEP  105  determines whether the PEP was shut down gracefully (i.e., in a planned manner) prior to the reboot, and thus stored the current health data according to normal operating procedure. For example, a stored flag may indicate whether the PEP  105  was shut down gracefully. If the PEP  105  was not shut down gracefully, at a block  445 , the PEP  105  informs an administrator that the health data may be out of date. 
     In addition to requesting the most recent health data from the OLS  135  at initialization, in some embodiments the PEP  105  requests the most recent health data from the OLS during operation. At a block  450 , the PEP  105  periodically sends a request to the OLS  135  for the most recent health data. The OLS  135  sends the most recent health data to the PEP  105  along with a timestamp associated with that version of the health data. Among other benefits, requesting the most recent health data from the OLS  135  during operation allows the PEP  105  to ensure it is operating with the most recent data, especially if the PEP was unable to make contact with the OLS during initialization. In addition, the PEP  105  ensures that it has the most recent data for a device that is connected to the PEP after being connected to the OLS  135  directly via the internet or via another PEP. Moreover, in some embodiments, if a device cannot and/or does not communicate its current health data to the PEP  105  upon connection to the PEP, the PEP uses the most recent heath data provided to the OLS  135  directly via the Internet or via another PEP. 
     From the foregoing, it will be appreciated that specific embodiments of the technology have been described herein for purposes of illustration, but that various modifications may be made without deviating from the spirit and scope of the technology. For example, while  FIG. 3  depicts a table whose contents and organization are designed to make them more comprehensible by a human reader, those skilled in the art will appreciate that the actual data structure(s) used by the system to store this information may differ from the table shown, in that they, for example, may be organized in a different manner, may contain more or less information than shown, may be compressed and/or encrypted, and may be optimized in a variety of ways. Those skilled in the art will further appreciate that the depicted flow charts may be altered in a variety of ways. For example, the order of the steps may be rearranged, steps may be performed in parallel, steps may be omitted, or other steps may be included. Accordingly, the described technology is not limited except as by the appended claims.