WO2009058571A1 - A model for defining device posture and a corresponding security policy - Google Patents

A model for defining device posture and a corresponding security policy Download PDF

Info

Publication number
WO2009058571A1
WO2009058571A1 PCT/US2008/080074 US2008080074W WO2009058571A1 WO 2009058571 A1 WO2009058571 A1 WO 2009058571A1 US 2008080074 W US2008080074 W US 2008080074W WO 2009058571 A1 WO2009058571 A1 WO 2009058571A1
Authority
WO
WIPO (PCT)
Prior art keywords
client device
attribute
server
network
specific
Prior art date
Application number
PCT/US2008/080074
Other languages
French (fr)
Inventor
Sandilya Garimella
John D. Bruner
Venu M. Chukkapalli
Original Assignee
Motorola, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Motorola, Inc. filed Critical Motorola, Inc.
Publication of WO2009058571A1 publication Critical patent/WO2009058571A1/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/20Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0876Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/10Network architectures or network communication protocols for network security for controlling access to devices or network resources

Definitions

  • the present invention relates generally to the field of networks.
  • the present invention further relates specifically to conforming integrity of a client device in a network.
  • a system may comprise an internet protocol (IP) network and a non-internet protocol system portion (which could be a non-IP network).
  • IP internet protocol
  • a non-internet protocol system portion which could be a non-IP network.
  • IP internet protocol
  • 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.
  • 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.
  • LAN local area network
  • WAN wide area network
  • WLAN wireless local area network
  • VLAN virtual local area network
  • IP networks IP networks.
  • 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.
  • 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).
  • 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.
  • 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.”
  • the client device may report a set of integrity measurements that describe the current statuses 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.
  • 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.
  • a method, apparatus, and electronic device for device management of mobile telecommunication devices are disclosed.
  • a network interface may connect to a plurality of client devices in a telecommunications network.
  • a memory may store an attribute mapping table mapping a generic attribute of the plurality of client devices to a specific attribute of a member client device type of the plurality of client devices.
  • a processor may build a device-specific security posture for device management of a member client device of the member client device type in the telecommunications network based on the mapping.
  • Figure 1 illustrates one embodiment of a communication system.
  • Figure 2 illustrates in a block diagram one embodiment of the client device.
  • Figure 3 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.
  • Figure 4 illustrates in a block diagram one embodiment of a policy cache.
  • Figure 5 illustrates one embodiment of a communication system for conforming integrity of the client device.
  • Figure 6 illustrates in a flowchart one embodiment of a method for an access server to conform integrity of the client device.
  • Figure 7 illustrates in a flowchart one embodiment of a method for a client device to conform its integrity.
  • Figure 8 illustrates in a flowchart one embodiment of a method for an access server to conform integrity of the client device.
  • Figure 9 illustrates in a flowchart one embodiment of a method for a compliance server to conform integrity of the client device.
  • Figure 10 illustrates a possible configuration of a computing system to act as a server to execute the present invention.
  • Figure 11 illustrates in a block diagram one embodiment of an attribute-mapping table.
  • Figure 12 illustrates in a block flow diagram one embodiment of a method 1200 for creating a security posture mapping.
  • Figure 13 illustrates in a flowchart one embodiment of a method for security posture mapping.
  • Figure 14 illustrates in a flowchart one embodiment of a method 1400 for updating the security posture.
  • 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 device management of mobile telecommunication devices are disclosed.
  • a network interface may connect to a plurality of client devices in a telecommunications network.
  • a memory may store an attribute mapping table mapping a generic attribute of the plurality of client devices to a specific attribute of a member client device type of the plurality of client devices.
  • a processor may build a device-specific security posture for device management of a member client device of the member client device type in the telecommunications network based on the mapping.
  • the embodiments described herein include methods for network access control suitable for devices with the characteristics of mobile handsets.
  • 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.
  • the client device may report this certificate of health.
  • the certificate of health is determined to be valid, the client device may be granted full access to the network.
  • 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.
  • 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.
  • a method for a server to conform integrity of a client device 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.
  • the remediation process may include determining a set of updates from the subset of integrity measurements.
  • the remediation process may include pushing the set of updates to the client device.
  • 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.
  • 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.
  • Figure 1 illustrates one embodiment of a communication system 100.
  • the communication system 100 may include a network 102 and a client device 106. Further, the network 102 may include a network access server 104.
  • Various communication devices may exchange data or information through the network 102.
  • the network 102 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.
  • IP internet protocol
  • a network administrator of the network 102 may implement various security policies on the network 102. 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 102.
  • the network access server 104 may be capable of verifying compliance of the client device 106 with the security policies of the network 102, when the client device 106 tries to access the network 102.
  • the network access server 104 may ensure that the identity and security policies of the client device 106 (and possibly also the identity of the person using the device) are verified before providing access to the network 102.
  • the network access server 104 may be a distributed set of servers in the network.
  • the client device 106 may be one of several types of handheld devices, such as, a mobile phone, a laptop, or a personal digital assistant (PDA).
  • the client device 106 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.
  • GPRS general packet radio service
  • EDGE enhanced data rates for global evolution
  • UMTS universal mobile telecommunications system
  • EvDO evolution data optimized
  • the client device 106 may connect to the network 102 via a wireline or virtual private network (VPN) access.
  • the WiFi capable device may be used to access the network 102 for data or by voice using voice over Internet protocol (VOIP) .
  • VOIP voice over Internet protocol
  • FIG. 2 illustrates in a block diagram one embodiment of the client device 106.
  • the client device 106 may be capable of accessing the information or data stored in the network 102.
  • the client device 106 may also support one or more applications for performing various communications with the network 102.
  • the client device 106 may be a handheld device, such as, a mobile phone, a laptop, or a personal digital assistant (PDA).
  • PDA personal digital assistant
  • the client device 106 may be WiFi capable device, which may be used to access the network 102 for data or by voice using VOIP.
  • the client device 106 may be a wireless device and may receive or transmit a certificate of health wirelessly.
  • the client device 106 may include a transceiver 202, which is capable of sending and receiving data over the network 102.
  • the client device 106 may include a processor 204 that executes stored programs.
  • the client device 106 may also include a volatile memory 206 and a non-volatile memory 208 which are used by the processor 204.
  • the client device 106 may include a user input interface 210 that may comprise elements such as a keypad, display, touch screen, and the like.
  • the client device 106 may also include a user output device that may comprise a display screen and an audio interface 212 that may comprise elements such as a microphone, earphone, and speaker.
  • the client device 106 also may include a component interface 214 to which additional elements may be attached, for example, a universal serial bus (USB) interface.
  • the client device 106 may include a power supply 216.
  • FIG. 3 illustrates in a block diagram one embodiment of a certificate of health 300, or trusted token, that may identify an integrity state of the client device 106.
  • the certificate of health 300 may be received by the transceiver 204.
  • the integrity state may be a configuration of the client device 106 that may be altered by downloading information to the client device 106.
  • the certificate of health 300 may include a first value, the policy identifier 302, for identifying a set of integrity measurements.
  • the set of integrity measurements may include one or more of identification parameters for identifying versions of software, versions of data files, configuration parameters, and blowable fuse settings.
  • the certificate of health may include a device type identifier 304, for identifying a predefined class of client devices; a time stamp 306; and an identifier 308 of the client device 106.
  • the device type identifier 304 may be used to identify a class of wireless communication device, which may include mobile phones and personal digital assistants (PDA).
  • the predefined class of client devices may include the client device 106.
  • the time stamp 306 may be used to identify the date of issuance of the certificate of health by the network.
  • the certificate of health 300 may include an encoded number 308 identifying the client device to bind the certificate of health 300 to the mobile device, identifying the certificate of health as belonging to that device and that device alone.
  • the integrity of the certificate of health may be protected by encryption, for example, by using a signed cryptographic hash, or an authentication check 310.
  • the non- volatile memory module 206 may store the certificate of health for later use when the client device 106 has to access the network 102. Further, when the client device 106 accesses the network 102, the transceiver 202 may transmit the certificate of health 300 to the access server 104.
  • FIG 4 illustrates in a block diagram one embodiment of a policy cache 400 that the access server 104 may use to determine whether a certificate of health 300 represents a valid integrity state.
  • the policy cache 400 may be an associative table of ordered pairs. Each entry in the table may comprise a device type identifier 402 and a current policy identifier 404.
  • the certificate of health 300 may represent a valid integrity state when a row in the table for which the certificate of health's device type identifier 304 appears has an associated policy identifier 302.
  • a certificate of health for which the device type identifier 304 is "B" and the policy identifier 302 is " ⁇ " represents a valid integrity state because policy table 400 contains a row (B, ⁇ ).
  • FIG. 5 illustrates one embodiment of a communication system 500 for conforming integrity of the client device 106.
  • the system may include the network 102, which may include a quarantine network 502; the access server 104; the client device 106; an access router 504; a compliance server 506; and other network servers 508.
  • the access server 104 and compliance server 506 may both have access to a policy table 400.
  • the access server 104 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 106 may interact with the access router 504 to access the network 102.
  • RADIUS remote authentication dial-in user server
  • TACACS+ terminal access controller access-control system
  • the access router 504 may initiate an extensible authentication protocol (EAP) session to begin the process of authentication and verification of compliance to policies of the network 102 by the client device 106.
  • EAP extensible authentication protocol
  • the access router 504 may initiate EAP through a virtual private network (VPN) gateway, an intranet wired access-point, or an intranet wireless access- point.
  • VPN virtual private network
  • 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.
  • IEEE Institute of Electrical and Electronic Engineers
  • the client device 106 may send the client and user authentication information, along with the certificate of health to the intranet wireless access router 504 in a sequence of EAP messages.
  • the access router 504 may send an access request, such as a RADIUS access request, along with that EAP response to the access server 104.
  • the access server 104 may authenticate the client device 106.
  • the client device 106 need not be provided access to the network 102 if the authentication fails.
  • the authentication may fail when the access server 104 does not recognize the client device 106.
  • 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 104 may contain a policy table 400 that defines the current policy for each device type.
  • the access server 104 may determine the integrity state of the client device 106 by searching the policy table 400 for an entry that matches the device type identifier 304 and policy identifier 302 in the certificate of health. If a matching entry is found, the integrity state of the client device 106 may be deemed current. Based on the integrity state of the certificate of health (current or not current), the client device 106 may be granted access either to the main network 102 or only the quarantine network 502 by the access router 504. The access router 504 may be directed to provide appropriate access to the client device 106 by the access server 104.
  • the access of the client device 106 may thus be restricted to the quarantine network 502, for the purpose of attempting to update the client device 106 and the certificate of health 300, when the certificate of health 300 of the client device 106 is not current.
  • the access server 104 may send a success response, such as a RADIUS access- accept response, to the access router 504, with an attribute stating that the client device 106 may be provided access to the main network 102 and the client device 106 may be considered to be operating in the full-access network 512.
  • the access server 104 sends a success response to the access router 504, with an attribute stating that the client device 106 may be provided access only to the quarantine network 502. While restricted to accessing the quarantine network 502, the client device 106 may access only the compliance server 506, whereas when the client is operating in the full- access network 512, the client device may access database server and electronic-mail and other web applications server of the network 102.
  • the access server 104 When the access server 104 authenticates the client device 106, but the access server 104 determines that the integrity state represented by the certificate of health 300 is not current, a further process may be initiated to verify the integrity state of the client device 106, apply updates to bring it into policy compliance, and update the certificate of health 300.
  • the client device 106 may be provided access to the quarantine network 502 as stated above.
  • the quarantine network 502 may include a compliance server 506.
  • the compliance server 506 may be used to request and receive integrity measurements from the client device 106 and to verify those measurements against the current policy for that type of device. Further, the compliance server 506 may determine a set of updates that are required to bring the client device 106 back into compliance with policy.
  • the compliance server 506 may be used for updating the certificate of health.
  • the compliance server 506 may construct a new certificate of health 300, which is updated and current.
  • the updated certificate of health 300 may be sent to the client device 106.
  • the client device 106 may use the updated certificate of health for accessing the network 102.
  • communication with the client device 106 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.
  • OMA open mobile alliance
  • MSP mobility service platform
  • SOTI® SOTI
  • FIG. 6 illustrates in a flowchart one embodiment of a method 600 for an access server to conform integrity of the client device 106.
  • the access server 104 may authenticate the device and user (Block 602). In an exemplary implementation, this authentication may occur using an EAP authentication exchange. When authentication fails, the access server 104 may deny network access to the client device 106 (Block 604). The client device 106 may try to authenticate again later. When authentication succeeds, the access server 104 may direct the client device 106 to examine its non-volatile memory 208 to determine if there is a certificate of health (COH) 300 stored there (Block 606). If there is a COH 300, the access server 104 may receive the COH 300 from the client device 106 (Block 608).
  • COH certificate of health
  • this access server may receive the COH 300 using EAP.
  • the access server 104 may transmit the authentication status to the client device 106 (Block 610).
  • 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 104 may further examine the authentication status to determine whether the device is to be quarantined (Block 612). If the device is to be quarantined, the access server 104 may grant the client device 106 access to the quarantine network 502 (Block 614).
  • the access server may initiate the extended remediation process, as part of a compliance process (Block 616).
  • FIG. 7 illustrates in a flowchart one embodiment of a method 616 for a client device 106 to conform its integrity.
  • the client device 106 may receive a list of integrity measurement requests from the compliance server 506 (Block 702).
  • 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.
  • 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 506 to the client device 106.
  • the client device 106 may examine the list of measurement requests to determine whether it is empty (Block 704). If the list of measurement requests is not empty (Block 704), the client device 106 may take at least one of the requested measurements (Block 706) and send them to the compliance server 506 (Block 708). For one embodiment, the device management protocol may be used to transfer the measurements to the compliance server 506. The cycle may repeat until the list of measurement requests from the compliance server 506 is empty. If the list of measurement requests is empty (Block 704), the client device 106 may receive and process a set of updates from the compliance server 506 (Block 710).
  • 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 106 may process these updates as according to their kind (Block 710). For example, new or updated configuration files may be written, and configuration parameters may be altered to new values, respectively.
  • the device management protocol may be used to transfer the updates to the client device 106 and cause them to be processed.
  • the client device 106 may receive and store a new COH 300 from the compliance server 506 (Block 712). This COH 300 may represent the new integrity state of the client device as established by the updates.
  • FIG. 8 illustrates in a flowchart one embodiment of a method for an access server 104 to conform integrity of the client device 106.
  • the access server 104 may receive a COH 300 from the client device 106 (Block 802). If the client device 106 does not currently possess a COH 300, an indication of a missing COH 300 may be sent. When present, the COH 300 may identify an integrity state of the client device 106. The access server 104 may determine if the COH 300 is present (Block 804). If so, a policy table, such as policy table 400, may be examined to determine whether the COH 300 represents a valid integrity state (i.e., is current), as previously described (Block 806).
  • a policy table such as policy table 400
  • the COH 300 may be deemed current (Block 808). If the COH 300 is current (Block 808), then the integrity of the client device 106 may be confirmed. If the COH 300 is not current (Block 808), the access server 104 may perform an extended remediation process (Block 810).
  • Figure 9 illustrates in a flowchart one embodiment of a method 810 for an extended remediation process for a compliance server 506 to conform integrity of the client device 106.
  • the compliance server 506 may examine the COH 300 to determine the current integrity state of the client device 106 (Block 902).
  • the integrity state may include a policy identifier 302 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 300 does not represent a current integrity state, a subset of the integrity measurements represented by the COH 300 may be no longer current.
  • the compliance server 506 may determine the subset of integrity measurements that is not current by comparing the set of integrity measurements represented by the policy identifier 302 with the current set of integrity measurements for the predefined class of client devices.
  • the compliance server 506 may request the set of integrity measurements that are not current from the client device 106 (Block 904).
  • a device management protocol may be used for requesting the client device 106 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 506 may determine a set of updates (Block 906). The set of updates may be determined from the subset of integrity measurements.
  • the compliance server 506 may push the set of updates to the client device (Block 908).
  • the set of updates may be an updating of the version of software and data files stored on the client device 106, configuration parameters, and blowable fuse settings.
  • a device management protocol may be used to push the updates.
  • the compliance server 506 may create a new COH 300 representing the new integrity state of the client device 106 and push the new COH to the client device 106 (Block 910). Upon completion of this remediation process, the client device 106 may be granted full access to the main network 102.
  • 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. Ix. 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 308, a valid COH on one device may not be transferable to another.
  • Figure 10 illustrates a possible configuration of a computing system 1000 to act as a mobile telecommunications server, such as an access server 104 or a compliance server 506, or electronic device to execute the present invention.
  • the computer system 1000 may include a controller/processor 1010, a memory 1020, a policy cache 1030 (described above), a compliance server interface 1040, input/output device interface 1050, and a network interface 1060, connected through bus 1070.
  • the computer system 1000 may implement any operating system, such as Windows 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 controller/processor 1010 may be any programmed processor known to one of skill in the art.
  • 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.
  • 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 1020 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.
  • RAM random access memory
  • the memory may have a cache to speed access to specific data.
  • the memory 1020 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.
  • CD-ROM compact disc — read only memory
  • DVD-ROM digital video disc — read only memory
  • DVD-ROM digital video disc — read only memory
  • the Input/Output interface 1050 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 1050 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 1060 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 1060 may be used to connect a client device a network or a quarantine network.
  • the compliance server interface 1040 may be implemented as software on top of the network interface 1060.
  • the components of the computer system 1000 may be connected via an electrical bus 1070, for example, or linked wirelessly.
  • Client software and databases may be accessed by the controller/processor 1010 from memory 1020, 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 1000 may implement any operating system, such as Windows 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 compliance server 506 may create a security policy for the client devices 106 of the mobile telecommunications network 102.
  • the policy may have a set of rules, with each rule expressing the relations between a security attribute and a reference value of that attribute.
  • the attribute may be a configuration parameter, such as a firewall setting; a status indicator, such as a logic value indicating whether a hardware or software capability is available; a version number, such as a software program versions; or other type of logical, numerical, or textual value.
  • the rule may state a mandatory relationship between that attribute and a corresponding reference value specified within the rule.
  • the compliance server 506 may use the security policy to perform an assessment of a device- specific security posture.
  • the compliance server 506 may retrieve the named attribute for each rule from the client device and evaluate whether the retrieved value satisfies the relationship with the reference value that is stated by the rule.
  • the location and form of a particular security attribute may vary from device to device. For example, the same attribute may have a different name on mobile telephones from different manufacturers. For example, the current version of a particular anti -virus database may be represented differently on Motorola® and Nokia® handsets, although the version number of the database may have the same meaning for all handsets. Creating a set of rules for each specific representation of the attribute may be cumbersome, requiring updating all of the rules when the reference value associated with that rule was changed (for example, if a new version of the anti- virus database became available).
  • the security posture assessment may be streamlined by incorporating an attribute mapping table.
  • FIG 11 illustrates in a block diagram one embodiment of an attribute mapping table 1100.
  • the attribute mapping table 1100 may be a table stored in a server for mapping a generic attribute across a plurality of client device types in a mobile telecommunication network.
  • the attribute mapping table 1100 may contain an entry for a generic attribute 1102.
  • the generic attribute may be a software attribute, such as an aspect of a security policy (i.e. anti-virus software, version 2) or a telecommunications protocol to allow the plurality of client devices to communicate with each other.
  • the attribute mapping table 1100 may associate these generic attributes 1102 with a generic reference value 1104 as determined by a policy, such as a security policy.
  • Each client device in the mobile telecommunications network may be assigned to a specific device type.
  • the device type may be based on the manufacturer, the hardware model, the software model, or other factors.
  • One or more client devices in the mobile telecommunications network may be assigned that device type.
  • the attribute mapping table 1100 may also map each generic attribute 1102 to a specific device- type attribute identifier 1106 representing the specific attribute for each device type in the plurality of client devices.
  • the specific device-type attribute identifier 1106 may describe a specific configuration for that generic attribute as it applies to the specific device type. For example, an anti-virus software may be stored in one location in device 1 and in a different location in device 2. While two specific device-type attribute identifiers 1106 are shown in the current embodiment, any number of specific device-type attribute identifiers 1106 may be mapped to the generic attribute 1102.
  • FIG. 12 illustrates in a block flow diagram one embodiment of a method 1200 for creating a device-specific security posture mapping.
  • a compliance server 506, or policy server may define a set of generic posture attributes (Block 1202).
  • the compliance server 506 may map generic posture attributes to specific device type attribute identifiers for member client device Q (Block 1204).
  • the compliance server 506 may build a device-specific security posture, representing the set of measurements required to determine compliance to policy for member client device Q based upon the mapping (Block 1206).
  • the compliance server 506 may map generic posture attributes to specific device type attribute identifiers for member client device V3 (Block 1208).
  • the compliance server 506 may build a device-specific security posture, representing the set of measurements required to determine compliance to policy, for member client device V3 based upon the mapping (Block 1210). The compliance server 506 may then verify the posture for a client device 106. For example, the compliance server 506 may verify the compliance to policy of member client device Q by requesting that the device 106 perform these specific measurements. In an alternate example, the compliance server 506 may execute a remediation process based on the specific attribute. [0052]
  • Figure 13 illustrates in a flowchart one embodiment of a method 1300 for device-specific security posture mapping.
  • the compliance server 506 may define a general policy rule, such as a security policy (Block 1302).
  • a general policy rule may relate a generic attribute 1102 of a plurality of client devices in a mobile telecommunications network to a reference value 1104.
  • the compliance server 506 may store the generic attribute 1102 and the reference value 1104 (Block 1304).
  • the compliance server 506 may select a device type from the plurality of device types available for the network 102 (Block 1306).
  • the compliance server 506 may map the generic attribute 1102 to a specific device-type attribute identifier 1106 of a member client device type of the plurality of client devices (Block 1308).
  • the compliance server 506 may derive a specific policy rule for the member client device type based upon the specific device-type attribute identifier 1106 (Block 1310).
  • the compliance server 506 may repeat the process for each available device type until all available device types have been processed (Block 1312).
  • Updates to policy rules that comprise a security posture may be pre-calculated at the time of an update to a reference value or performed on an on-demand basis.
  • Figure 14 illustrates in a flowchart one embodiment of a method 1400 for updating the security posture on-demand.
  • the compliance server 506 may execute a general update of the reference value 1104 (Block 1402).
  • the general update may be initiated by a network administrator or may be generated automatically by outside stimuli, such as a notification from a manufacturer of an update to a core software code or a new version.
  • the compliance server 506 may note the next time a client device 106 attempts to access the network (Block 1404).
  • the compliance server 506 may quarantine the client device 106, beginning the remediation process (Block 1406).
  • the compliance server 506 may identify the device type of the client device 106, such as by reading the device type identifier 304 in the COH 300 (Block 1408). The compliance server 506 may then map the updated generic attribute to the specific device-type attribute (Block 1410). The compliance server 506 may then generate a set of integrity measurement requests based upon the specific device-type attribute (Block 1412). The compliance server 506 may then transmit the set of integrity measurement requests to the client device 106 to initiate the measurement of the integrity of the client device 106 (Block 1414). The compliance server 506 may compare the measurement of the specific attribute received from the client device 106 against the reference value 1104 to determine whether the specific device is compliant to the general policy rule (Block 1416).
  • program modules include routine programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types.
  • program modules include routine programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types.
  • program modules include routine programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types.
  • program modules include routine programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types.
  • network computing environments 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.
  • 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.
  • a network or another communications connection either hardwired, wireless, or combination thereof
  • 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.
  • 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.

Abstract

A method, apparatus, and electronic device for device management of telecommunication devices 106 are disclosed. A network interface 1060 may connect to a plurality of client devices 106 in a telecommunications network 102. A memory 1020 may store an attribute mapping table 1100 mapping a generic attribute 1102 of the plurality of client devices 106 to a specific attribute 1106 of a member client device type of the plurality of client devices 106. A processor 1010 may build a device-specific security posture for device management of a member client device 106 of the member client device type in the telecommunications network 102 based on the mapping.

Description

A MODEL FOR DEFINING DEVICE POSTURE AND A CORRESPONDING SECURITY POLICY
BACKGROUND
1. Field of the Invention
[0001] The present invention relates generally to the field of networks. The present invention further relates specifically to conforming integrity of a client device in a network.
2. Introduction
[0002] 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.
[0003] 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."
[0004] 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 statuses 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.
[0005] 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.
SUMMARY OF THE INVENTION
[0006] A method, apparatus, and electronic device for device management of mobile telecommunication devices are disclosed. A network interface may connect to a plurality of client devices in a telecommunications network. A memory may store an attribute mapping table mapping a generic attribute of the plurality of client devices to a specific attribute of a member client device type of the plurality of client devices. A processor may build a device-specific security posture for device management of a member client device of the member client device type in the telecommunications network based on the mapping.
BRIEF DESCRIPTION OF THE DRAWINGS
[0007] In order to describe the manner in which the above-recited and other advantages and features of the invention can be obtained, a more particular description of the invention briefly described above will be rendered by reference to specific embodiments thereof which are illustrated in the appended 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:
[0008] Figure 1 illustrates one embodiment of a communication system.
[0009] Figure 2 illustrates in a block diagram one embodiment of the client device.
[0010] Figure 3 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.
[0011] Figure 4 illustrates in a block diagram one embodiment of a policy cache.
[0012] Figure 5 illustrates one embodiment of a communication system for conforming integrity of the client device.
[0013] Figure 6 illustrates in a flowchart one embodiment of a method for an access server to conform integrity of the client device.
[0014] Figure 7 illustrates in a flowchart one embodiment of a method for a client device to conform its integrity.
[0015] Figure 8 illustrates in a flowchart one embodiment of a method for an access server to conform integrity of the client device.
[0016] Figure 9 illustrates in a flowchart one embodiment of a method for a compliance server to conform integrity of the client device.
[0017] Figure 10 illustrates a possible configuration of a computing system to act as a server to execute the present invention. [0018] Figure 11 illustrates in a block diagram one embodiment of an attribute-mapping table.
[0019] Figure 12 illustrates in a block flow diagram one embodiment of a method 1200 for creating a security posture mapping.
[0020] Figure 13 illustrates in a flowchart one embodiment of a method for security posture mapping.
[0021] Figure 14 illustrates in a flowchart one embodiment of a method 1400 for updating the security posture.
DETAILED DESCRIPTION OF THE INVENTION
[0022] 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. [0023] 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.
[0024] 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.
[0025] A method, apparatus, and electronic device for device management of mobile telecommunication devices are disclosed. A network interface may connect to a plurality of client devices in a telecommunications network. A memory may store an attribute mapping table mapping a generic attribute of the plurality of client devices to a specific attribute of a member client device type of the plurality of client devices. A processor may build a device-specific security posture for device management of a member client device of the member client device type in the telecommunications network based on the mapping. [0026] 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. [0027] 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.
[0028] 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. [0029] 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. [0030] Figure 1 illustrates one embodiment of a communication system 100. The communication system 100 may include a network 102 and a client device 106. Further, the network 102 may include a network access server 104. Various communication devices may exchange data or information through the network 102. The network 102 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 102 may implement various security policies on the network 102. 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 102. The network access server 104 may be capable of verifying compliance of the client device 106 with the security policies of the network 102, when the client device 106 tries to access the network 102. The network access server 104 may ensure that the identity and security policies of the client device 106 (and possibly also the identity of the person using the device) are verified before providing access to the network 102. For one embodiment, the network access server 104 may be a distributed set of servers in the network. The client device 106 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 106 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 106 may connect to the network 102 via a wireline or virtual private network (VPN) access. The WiFi capable device may be used to access the network 102 for data or by voice using voice over Internet protocol (VOIP) .
[0031] Figure 2 illustrates in a block diagram one embodiment of the client device 106. The client device 106 may be capable of accessing the information or data stored in the network 102. For some embodiments of the present invention, the client device 106 may also support one or more applications for performing various communications with the network 102. The client device 106 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 106 may be WiFi capable device, which may be used to access the network 102 for data or by voice using VOIP. The client device 106 may be a wireless device and may receive or transmit a certificate of health wirelessly. The client device 106 may include a transceiver 202, which is capable of sending and receiving data over the network 102. The client device 106 may include a processor 204 that executes stored programs. The client device 106 may also include a volatile memory 206 and a non-volatile memory 208 which are used by the processor 204. The client device 106 may include a user input interface 210 that may comprise elements such as a keypad, display, touch screen, and the like. The client device 106 may also include a user output device that may comprise a display screen and an audio interface 212 that may comprise elements such as a microphone, earphone, and speaker. The client device 106 also may include a component interface 214 to which additional elements may be attached, for example, a universal serial bus (USB) interface. Finally, the client device 106 may include a power supply 216.
[0032] Figure 3 illustrates in a block diagram one embodiment of a certificate of health 300, or trusted token, that may identify an integrity state of the client device 106. The certificate of health 300 may be received by the transceiver 204. The integrity state may be a configuration of the client device 106 that may be altered by downloading information to the client device 106. The certificate of health 300 may include a first value, the policy identifier 302, for identifying a set of integrity measurements. The set of integrity measurements may include one or more of identification parameters for identifying versions of software, versions of data files, configuration parameters, and blowable fuse settings. Further, the certificate of health may include a device type identifier 304, for identifying a predefined class of client devices; a time stamp 306; and an identifier 308 of the client device 106. The device type identifier 304 may be used to identify a class of wireless communication device, which may include mobile phones and personal digital assistants (PDA). The predefined class of client devices may include the client device 106. The time stamp 306 may be used to identify the date of issuance of the certificate of health by the network. The certificate of health 300 may include an encoded number 308 identifying the client device to bind the certificate of health 300 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 310. The non- volatile memory module 206 may store the certificate of health for later use when the client device 106 has to access the network 102. Further, when the client device 106 accesses the network 102, the transceiver 202 may transmit the certificate of health 300 to the access server 104.
[0033] Figure 4 illustrates in a block diagram one embodiment of a policy cache 400 that the access server 104 may use to determine whether a certificate of health 300 represents a valid integrity state. The policy cache 400 may be an associative table of ordered pairs. Each entry in the table may comprise a device type identifier 402 and a current policy identifier 404. In some embodiments, the certificate of health 300 may represent a valid integrity state when a row in the table for which the certificate of health's device type identifier 304 appears has an associated policy identifier 302. For example, as depicted in Figure 4, a certificate of health for which the device type identifier 304 is "B" and the policy identifier 302 is "β" represents a valid integrity state because policy table 400 contains a row (B,β).
[0034] Figure 5 illustrates one embodiment of a communication system 500 for conforming integrity of the client device 106. The system may include the network 102, which may include a quarantine network 502; the access server 104; the client device 106; an access router 504; a compliance server 506; and other network servers 508. The access server 104 and compliance server 506 may both have access to a policy table 400. For one embodiment, the access server 104 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 106 may interact with the access router 504 to access the network 102. In one embodiment, the access router 504 may initiate an extensible authentication protocol (EAP) session to begin the process of authentication and verification of compliance to policies of the network 102 by the client device 106. In a preferred embodiment, the access router 504 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 106 may send the client and user authentication information, along with the certificate of health to the intranet wireless access router 504 in a sequence of EAP messages. On receiving each EAP response from the client device 106, the access router 504 may send an access request, such as a RADIUS access request, along with that EAP response to the access server 104. In one embodiment, the access server 104 may authenticate the client device 106. The client device 106 need not be provided access to the network 102 if the authentication fails. The authentication may fail when the access server 104 does not recognize the client device 106. 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 104 may contain a policy table 400 that defines the current policy for each device type. Upon receipt of the certificate of health, the access server 104 may determine the integrity state of the client device 106 by searching the policy table 400 for an entry that matches the device type identifier 304 and policy identifier 302 in the certificate of health. If a matching entry is found, the integrity state of the client device 106 may be deemed current. Based on the integrity state of the certificate of health (current or not current), the client device 106 may be granted access either to the main network 102 or only the quarantine network 502 by the access router 504. The access router 504 may be directed to provide appropriate access to the client device 106 by the access server 104. The access of the client device 106 may thus be restricted to the quarantine network 502, for the purpose of attempting to update the client device 106 and the certificate of health 300, when the certificate of health 300 of the client device 106 is not current. When the certificate of health 300 of the client device 106 is current, the access server 104 may send a success response, such as a RADIUS access- accept response, to the access router 504, with an attribute stating that the client device 106 may be provided access to the main network 102 and the client device 106 may be considered to be operating in the full-access network 512. When the certificate of health 300 of the client device 106 is not current, the access server 104 sends a success response to the access router 504, with an attribute stating that the client device 106 may be provided access only to the quarantine network 502. While restricted to accessing the quarantine network 502, the client device 106 may access only the compliance server 506, whereas when the client is operating in the full- access network 512, the client device may access database server and electronic-mail and other web applications server of the network 102.
[0035] When the access server 104 authenticates the client device 106, but the access server 104 determines that the integrity state represented by the certificate of health 300 is not current, a further process may be initiated to verify the integrity state of the client device 106, apply updates to bring it into policy compliance, and update the certificate of health 300. For this process, the client device 106 may be provided access to the quarantine network 502 as stated above. The quarantine network 502 may include a compliance server 506. The compliance server 506 may be used to request and receive integrity measurements from the client device 106 and to verify those measurements against the current policy for that type of device. Further, the compliance server 506 may determine a set of updates that are required to bring the client device 106 back into compliance with policy. Further, the compliance server 506 may be used for updating the certificate of health. The compliance server 506 may construct a new certificate of health 300, which is updated and current. The updated certificate of health 300 may be sent to the client device 106. Further, the client device 106 may use the updated certificate of health for accessing the network 102. For one embodiment, communication with the client device 106 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.
[0036] Figure 6 illustrates in a flowchart one embodiment of a method 600 for an access server to conform integrity of the client device 106. The access server 104 may authenticate the device and user (Block 602). In an exemplary implementation, this authentication may occur using an EAP authentication exchange. When authentication fails, the access server 104 may deny network access to the client device 106 (Block 604). The client device 106 may try to authenticate again later. When authentication succeeds, the access server 104 may direct the client device 106 to examine its non-volatile memory 208 to determine if there is a certificate of health (COH) 300 stored there (Block 606). If there is a COH 300, the access server 104 may receive the COH 300 from the client device 106 (Block 608). In an exemplary implementation, this access server may receive the COH 300 using EAP. The access server 104 may transmit the authentication status to the client device 106 (Block 610). 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 104 may further examine the authentication status to determine whether the device is to be quarantined (Block 612). If the device is to be quarantined, the access server 104 may grant the client device 106 access to the quarantine network 502 (Block 614). The access server may initiate the extended remediation process, as part of a compliance process (Block 616). If the device is not quarantined (Block 612), the access server 104 may grant the client device 106 full access to the network (Block 618). [0037] Figure 7 illustrates in a flowchart one embodiment of a method 616 for a client device 106 to conform its integrity. The client device 106 may receive a list of integrity measurement requests from the compliance server 506 (Block 702). 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 506 to the client device 106. The client device 106 may examine the list of measurement requests to determine whether it is empty (Block 704). If the list of measurement requests is not empty (Block 704), the client device 106 may take at least one of the requested measurements (Block 706) and send them to the compliance server 506 (Block 708). For one embodiment, the device management protocol may be used to transfer the measurements to the compliance server 506. The cycle may repeat until the list of measurement requests from the compliance server 506 is empty. If the list of measurement requests is empty (Block 704), the client device 106 may receive and process a set of updates from the compliance server 506 (Block 710). 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 106 may process these updates as according to their kind (Block 710). 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 106 and cause them to be processed. When the updates are complete, the client device 106 may receive and store a new COH 300 from the compliance server 506 (Block 712). This COH 300 may represent the new integrity state of the client device as established by the updates.
[0038] Figure 8 illustrates in a flowchart one embodiment of a method for an access server 104 to conform integrity of the client device 106. The access server 104 may receive a COH 300 from the client device 106 (Block 802). If the client device 106 does not currently possess a COH 300, an indication of a missing COH 300 may be sent. When present, the COH 300 may identify an integrity state of the client device 106. The access server 104 may determine if the COH 300 is present (Block 804). If so, a policy table, such as policy table 400, may be examined to determine whether the COH 300 represents a valid integrity state (i.e., is current), as previously described (Block 806). If the policy table 400 contains an entry that matches the device type and current policy for contained in the COH 300, then the COH 300 may be deemed current (Block 808). If the COH 300 is current (Block 808), then the integrity of the client device 106 may be confirmed. If the COH 300 is not current (Block 808), the access server 104 may perform an extended remediation process (Block 810).
[0039] Figure 9 illustrates in a flowchart one embodiment of a method 810 for an extended remediation process for a compliance server 506 to conform integrity of the client device 106. The compliance server 506 may examine the COH 300 to determine the current integrity state of the client device 106 (Block 902). The integrity state may include a policy identifier 302 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 300 does not represent a current integrity state, a subset of the integrity measurements represented by the COH 300 may be no longer current. The compliance server 506 may determine the subset of integrity measurements that is not current by comparing the set of integrity measurements represented by the policy identifier 302 with the current set of integrity measurements for the predefined class of client devices. The compliance server 506 may request the set of integrity measurements that are not current from the client device 106 (Block 904). For one embodiment of the present invention, a device management protocol may be used for requesting the client device 106 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 506 may determine a set of updates (Block 906). The set of updates may be determined from the subset of integrity measurements. The compliance server 506 may push the set of updates to the client device (Block 908). The set of updates may be an updating of the version of software and data files stored on the client device 106, 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 506 may create a new COH 300 representing the new integrity state of the client device 106 and push the new COH to the client device 106 (Block 910). Upon completion of this remediation process, the client device 106 may be granted full access to the main network 102. [0040] 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. Ix. 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 308, a valid COH on one device may not be transferable to another. [0041] Figure 10 illustrates a possible configuration of a computing system 1000 to act as a mobile telecommunications server, such as an access server 104 or a compliance server 506, or electronic device to execute the present invention. The computer system 1000 may include a controller/processor 1010, a memory 1020, a policy cache 1030 (described above), a compliance server interface 1040, input/output device interface 1050, and a network interface 1060, connected through bus 1070. The computer system 1000 may implement any operating system, such as Windows 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.
[0042] The controller/processor 1010 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.
[0043] The memory 1020 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 1020 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.
[0044] The Input/Output interface 1050 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 1050 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. [0045] The network interface 1060 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 1060 may be used to connect a client device a network or a quarantine network. The compliance server interface 1040 may be implemented as software on top of the network interface 1060. The components of the computer system 1000 may be connected via an electrical bus 1070, for example, or linked wirelessly.
[0046] Client software and databases may be accessed by the controller/processor 1010 from memory 1020, 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 1000 may implement any operating system, such as Windows 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.
[0047] The compliance server 506 may create a security policy for the client devices 106 of the mobile telecommunications network 102. The policy may have a set of rules, with each rule expressing the relations between a security attribute and a reference value of that attribute. The attribute may be a configuration parameter, such as a firewall setting; a status indicator, such as a logic value indicating whether a hardware or software capability is available; a version number, such as a software program versions; or other type of logical, numerical, or textual value. The rule may state a mandatory relationship between that attribute and a corresponding reference value specified within the rule. The compliance server 506 may use the security policy to perform an assessment of a device- specific security posture. In the posture assessment, the compliance server 506 may retrieve the named attribute for each rule from the client device and evaluate whether the retrieved value satisfies the relationship with the reference value that is stated by the rule. [0048] The location and form of a particular security attribute may vary from device to device. For example, the same attribute may have a different name on mobile telephones from different manufacturers. For example, the current version of a particular anti -virus database may be represented differently on Motorola® and Nokia® handsets, although the version number of the database may have the same meaning for all handsets. Creating a set of rules for each specific representation of the attribute may be cumbersome, requiring updating all of the rules when the reference value associated with that rule was changed (for example, if a new version of the anti- virus database became available). The security posture assessment may be streamlined by incorporating an attribute mapping table.
[0049] Figure 11 illustrates in a block diagram one embodiment of an attribute mapping table 1100. The attribute mapping table 1100 may be a table stored in a server for mapping a generic attribute across a plurality of client device types in a mobile telecommunication network. The attribute mapping table 1100 may contain an entry for a generic attribute 1102. The generic attribute may be a software attribute, such as an aspect of a security policy (i.e. anti-virus software, version 2) or a telecommunications protocol to allow the plurality of client devices to communicate with each other. The attribute mapping table 1100 may associate these generic attributes 1102 with a generic reference value 1104 as determined by a policy, such as a security policy. [0050] Each client device in the mobile telecommunications network may be assigned to a specific device type. The device type may be based on the manufacturer, the hardware model, the software model, or other factors. One or more client devices in the mobile telecommunications network may be assigned that device type. The attribute mapping table 1100 may also map each generic attribute 1102 to a specific device- type attribute identifier 1106 representing the specific attribute for each device type in the plurality of client devices. The specific device-type attribute identifier 1106 may describe a specific configuration for that generic attribute as it applies to the specific device type. For example, an anti-virus software may be stored in one location in device 1 and in a different location in device 2. While two specific device-type attribute identifiers 1106 are shown in the current embodiment, any number of specific device-type attribute identifiers 1106 may be mapped to the generic attribute 1102.
[0051] Figure 12 illustrates in a block flow diagram one embodiment of a method 1200 for creating a device-specific security posture mapping. A compliance server 506, or policy server, may define a set of generic posture attributes (Block 1202). The compliance server 506 may map generic posture attributes to specific device type attribute identifiers for member client device Q (Block 1204). The compliance server 506 may build a device-specific security posture, representing the set of measurements required to determine compliance to policy for member client device Q based upon the mapping (Block 1206). In a like manner, the compliance server 506 may map generic posture attributes to specific device type attribute identifiers for member client device V3 (Block 1208). The compliance server 506 may build a device-specific security posture, representing the set of measurements required to determine compliance to policy, for member client device V3 based upon the mapping (Block 1210). The compliance server 506 may then verify the posture for a client device 106. For example, the compliance server 506 may verify the compliance to policy of member client device Q by requesting that the device 106 perform these specific measurements. In an alternate example, the compliance server 506 may execute a remediation process based on the specific attribute. [0052] Figure 13 illustrates in a flowchart one embodiment of a method 1300 for device-specific security posture mapping. The compliance server 506 may define a general policy rule, such as a security policy (Block 1302). A general policy rule may relate a generic attribute 1102 of a plurality of client devices in a mobile telecommunications network to a reference value 1104. The compliance server 506 may store the generic attribute 1102 and the reference value 1104 (Block 1304). The compliance server 506 may select a device type from the plurality of device types available for the network 102 (Block 1306). The compliance server 506 may map the generic attribute 1102 to a specific device-type attribute identifier 1106 of a member client device type of the plurality of client devices (Block 1308). The compliance server 506 may derive a specific policy rule for the member client device type based upon the specific device-type attribute identifier 1106 (Block 1310). The compliance server 506 may repeat the process for each available device type until all available device types have been processed (Block 1312).
[0053] Updates to policy rules that comprise a security posture may be pre-calculated at the time of an update to a reference value or performed on an on-demand basis. Figure 14 illustrates in a flowchart one embodiment of a method 1400 for updating the security posture on-demand. The compliance server 506 may execute a general update of the reference value 1104 (Block 1402). The general update may be initiated by a network administrator or may be generated automatically by outside stimuli, such as a notification from a manufacturer of an update to a core software code or a new version. The compliance server 506 may note the next time a client device 106 attempts to access the network (Block 1404). The compliance server 506 may quarantine the client device 106, beginning the remediation process (Block 1406). The compliance server 506 may identify the device type of the client device 106, such as by reading the device type identifier 304 in the COH 300 (Block 1408). The compliance server 506 may then map the updated generic attribute to the specific device-type attribute (Block 1410). The compliance server 506 may then generate a set of integrity measurement requests based upon the specific device-type attribute (Block 1412). The compliance server 506 may then transmit the set of integrity measurement requests to the client device 106 to initiate the measurement of the integrity of the client device 106 (Block 1414). The compliance server 506 may compare the measurement of the specific attribute received from the client device 106 against the reference value 1104 to determine whether the specific device is compliant to the general policy rule (Block 1416).
[0054] 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.
[0055] 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.
[0056] 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.
[0057] 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. [0058] 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.

Claims

CLAIMSWe claim:
1. A method for device management, comprising: creating a generic attribute of a plurality of client devices in a telecommunications network; mapping the generic attribute to a specific attribute of a member client device type of the plurality of client devices; and building a device-specific security posture for device management of a member client device of the member client device type in the telecommunications network based on the mapping.
2. The method of claim 1, wherein the specific attribute is one of a configuration parameter, a status indicator, or a version number.
3. The method of claim 1, wherein the member client device type is based on at least one of manufacturer, hardware model, or software model.
4. The method of claim 1, further comprising: defining a general policy rule expressing a relationship between the generic attribute and a reference value; and deriving a specific policy rule for the member client device type based upon the specific attribute.
5. The method of claim 4, further comprising: executing a general update of the reference value; and generating a set of integrity measurement requests based upon the general update.
6. The method of claim 5, further comprising: mapping the general update to the specific attribute on an on-demand basis.
7. The method of claim 1, further comprising: executing a remediation process based on the specific attribute.
8. A server for device management of telecommunication devices, comprising: a network interface that connects to a plurality of client devices in a telecommunications network; a memory that stores an attribute mapping table mapping a generic attribute of the plurality of client devices to a specific attribute of a member client device type of the plurality of client devices; and a processor that builds a device-specific security posture for device management of a member client device of the member client device type in the telecommunications network based on the mapping.
9. The server of claim 8, wherein the specific attribute is one of a configuration parameter, a status indicator, or a version number.
10. The server of claim 8, wherein the member client device type is based on at least one of manufacturer, hardware model, or software model.
11. The server of claim 8, wherein the processor defines a general policy rule relating the generic attribute to a reference value and derives a specific policy rule for the member client device type based upon the specific attribute.
12. The server of claim 11, wherein the processor executes a general update of the reference value and generates a set of integrity measurement requests based upon the general update.
13. The server of claim 12, wherein the processor maps the general update to the specific attribute on an on-demand basis.
14. The server of claim 8, wherein the processor executes a remediation process based on the specific attribute.
15. An electronic device for device management, comprising: a network interface that connects to a plurality of client devices in a telecommunications network; a memory that stores an attribute mapping table mapping a generic attribute of the plurality of client devices to a specific attribute of a member client device type of the plurality of client devices; and a processor that builds a device-specific security posture for device management of a member client device of the member client device type in the telecommunications network based on the mapping.
16. The electronic device of claim 15, wherein the specific attribute is one of a configuration parameter, a status indicator, or a version number.
17. The electronic device of claim 15, wherein the member client device type is based on at least one of manufacturer, hardware model, or software model.
18. The electronic device of claim 15, wherein the processor defines a general policy rule relating the generic attribute to a reference value and derives a specific policy rule for the member client device type based upon the specific attribute.
19. The electronic device of claim 19, wherein the processor executes a general update of the reference value and generates a set of integrity measurement requests based upon the general update.
20. The electronic device of claim 20, wherein the processor maps the general update to the specific attribute on an on-demand basis.
PCT/US2008/080074 2007-11-01 2008-10-16 A model for defining device posture and a corresponding security policy WO2009058571A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
IN2282/DEL/2007 2007-11-01
IN2282DE2007 2007-11-01

Publications (1)

Publication Number Publication Date
WO2009058571A1 true WO2009058571A1 (en) 2009-05-07

Family

ID=40254397

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2008/080074 WO2009058571A1 (en) 2007-11-01 2008-10-16 A model for defining device posture and a corresponding security policy

Country Status (1)

Country Link
WO (1) WO2009058571A1 (en)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030055994A1 (en) * 2001-07-06 2003-03-20 Zone Labs, Inc. System and methods providing anti-virus cooperative enforcement
US20050131997A1 (en) * 2003-12-16 2005-06-16 Microsoft Corporation System and methods for providing network quarantine
US20070234402A1 (en) * 2006-03-31 2007-10-04 Hormuzd Khosravi Hierarchical trust based posture reporting and policy enforcement
US20070239748A1 (en) * 2006-03-29 2007-10-11 Smith Ned M Management of reference data for platform verification
US20070240197A1 (en) * 2006-03-30 2007-10-11 Uri Blumenthal Platform posture and policy information exchange method and apparatus

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030055994A1 (en) * 2001-07-06 2003-03-20 Zone Labs, Inc. System and methods providing anti-virus cooperative enforcement
US20050131997A1 (en) * 2003-12-16 2005-06-16 Microsoft Corporation System and methods for providing network quarantine
US20070239748A1 (en) * 2006-03-29 2007-10-11 Smith Ned M Management of reference data for platform verification
US20070240197A1 (en) * 2006-03-30 2007-10-11 Uri Blumenthal Platform posture and policy information exchange method and apparatus
US20070234402A1 (en) * 2006-03-31 2007-10-04 Hormuzd Khosravi Hierarchical trust based posture reporting and policy enforcement

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
OPSWAT: "Endpoint Security Engine (ESE)", 12 June 2007 (2007-06-12), XP002511803, Retrieved from the Internet <URL:http://web.archive.org/web/20070612194515/http://www.opswat.com/vpnguard.shtml> [retrieved on 20090123] *

Similar Documents

Publication Publication Date Title
US8539544B2 (en) Method of optimizing policy conformance check for a device with a large set of posture attribute combinations
US20220188425A1 (en) Quarantine of software by an evaluation server based on authenticity analysis of user device data
CN109417553B (en) Detecting attacks using leaked credentials via internal network monitoring
US11432150B2 (en) Method and apparatus for authenticating network access of terminal
CN102047262B (en) Authentication for distributed secure content management system
US8869252B2 (en) Methods, apparatuses, and computer program products for bootstrapping device and user authentication
US8671439B2 (en) Techniques for authenticated posture reporting and associated enforcement of network access
JP5522307B2 (en) System and method for remote maintenance of client systems in electronic networks using software testing with virtual machines
US8387131B2 (en) Enforcing secure internet connections for a mobile endpoint computing device
EP3651500B1 (en) Managing mobile device applications in a wireless network
EP2574089B1 (en) Authentication procedures for managing mobile device applications
CN101227468B (en) Method, device and system for authenticating user to network
US8381268B2 (en) Network authorization status notification
US20020120575A1 (en) Method of and apparatus for ascertaining the status of a data processing environment
US20080022354A1 (en) Roaming secure authenticated network access method and apparatus
CN102461265B (en) Location determined network access
WO2013044090A1 (en) Managing mobile device applications
WO2013044086A1 (en) Managing mobile device applications on a mobile device
KR100714367B1 (en) Network security system co-operated with an authentication server and method thereof
WO2010118610A1 (en) Method for establishing trusted network connect framework of tri-element peer authentication
CN103152350B (en) The trustable network cut-in method and system of a kind of protection terminal configuration privacy
WO2008027653A1 (en) Method and apparatus for conforming integrity of a client device
WO2009058571A1 (en) A model for defining device posture and a corresponding security policy
JPWO2010038783A1 (en) Access control system, access control method, and communication terminal
EP3163490B1 (en) Providing security assurance information

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08845164

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08845164

Country of ref document: EP

Kind code of ref document: A1