Patent Application
20060095961
Embodiments of the invention relate to network security and specifically to assigning network access to a network node according to a level of security of the network node.
A large number of vulnerabilities in software and machines are detected every day and these vulnerabilities pose a huge threat to an enterprise. There is traditionally a time lag between the detection of vulnerabilities and availability of fixes. Sometimes, even when a fix is available, administrators are not able to deploy the fix immediately due to time constraints or lack of adequate testing of the fix on their specific systems. It is during this time lag that most attacks are successful. Currently, anomalous and attack traffic flows throughout traditional networks affecting any vulnerable machines they can discover. The administrator may employ an intrusion detection system (IDS) in a De-Militarized Zone (DMZ) of their network (e.g., an area of restricted access to buffer a network from anomalous traffic) to look at traffic only as it enters and leaves the network. Mobile internal nodes may also leave the network and come back into the network in an infected state. Internal nodes may not be patched with the latest updates in time, which may cause the machine to both be vulnerable when outside the network, and cause potential harm when the machine returns back inside. Guest mobile nodes visiting networks are generally not under the administrative control of the visited networks administrators who traditionally have control over only their network infrastructure devices. All of the above scenarios pose considerable risks to the corporate environment that cause harm not addressed by current solutions, especially the threat of undetected internal anomalous traffic.
The description of embodiments of the invention includes various illustrations by way of example, and not by way of limitation in the figures and accompanying drawings.
A secure subnet partition and associated control functions may provide a mechanism to efficiently detect and quarantine vulnerable systems in a network. For example, some or all network traffic of a potentially vulnerable system may be diverted through a secure zone. In a virtual network sense, the system may be considered to be placed in a quarantine area. A quarantine area may be a virtual network partition isolated from other nodes in the network. In one embodiment the network partition, or subnet, may be isolated in that other nodes in the network may not have direct access to the subnet and/or traffic in the subnet.
Isolation of vulnerable or possibly vulnerable systems/machines/nodes enables an administrator to closely observe vulnerable systems in the quarantine area and deploy patches/updates/upgrades at the convenience of the administrator. The administration associated with diverting the machine and/or performing the updates may be facilitated with an out-of-band (OOB) communication mechanism. The entire process may occur via mechanisms transparent to the user and/or to a platform of the user's system. Thus, the users of the machines may be unaware of the diversion and be allowed normal access to resources. The administrator may thus more closely observe traffic from these potentially vulnerable machines and concentrate intrusion detection efforts in an isolated network. This may enable the administrator to detect and contain attacks more effectively.
In one embodiment anomalous and attack traffic may be identified through host/platform intrusion detection/tolerant systems. Identified anomalous traffic may be routed to an Intrusion Detection System (IDS) in an isolated subnet to analyze the traffic in that subnet. Traffic in the subnet may be prevented from reaching other machines in the network. In one embodiment traffic may be routed to machines in the network that are not within the isolated subnet, under close observation of the traffic at the quarantine subnet. Traffic may thus be filtered from the quarantine area to other nodes in the network. In one embodiment mobile internal node that leaves the network and comes back into the network may have its traffic automatically redirected through the quarantine area until a platform of the node undergoes a check for infection stage and/or a Minimum Security Specification (MSS) verification. Information related to detecting that a node leaves the network may be gather as discussed herein.
Traffic associated with/generated by a machine considered a low risk of vulnerability may be considered to be directed or “corralled” to an “OK corral,” referring to a VLAN identified by a VLAN identifier (ID) the machine may be assigned to use for network access. Traffic associated with/generated by a machine considered to be a higher risk of vulnerability may be considered to be directed or corralled to a “NOT OK corral,” referring to a VLAN identified by a VLAN ID of a quarantine area. In one embodiment machines with unverified/non-immunized platforms are initially assigned to a NOT-OK Corral VLAN. Likewise, in one embodiment mobile machines re-connecting to the network after connecting to some outside network are reset to not-verified, allowing the machine to be tested for vulnerability and verified prior to allowing normal access to the machine. This may be accomplished with an out-of-band platform management service to set some properties on a network interface, or network interface card (NIC) of the machine. An OOB platform management service and/or OOB communication mechanism/channel may refer to the use of a communication channel/signaling mechanism that may be transparent and/or agnostic to an operating system (OS) and/or application running on a platform of the machine. Thus, the communication may be inaccessible to elements of the machine that are traditionally susceptible to compromise by malware and/or attack/hacking (e.g., OS, application, basic input/output system (BIOS), software firewall, etc.) The OOB management service may include hardware on the platform with management software controlled by a network administrator.
In one embodiment a machine in the network includes one or more of the following capabilities: be programmable to store, for example for authentication, a home network address range (e.g., an Internet Protocol (IP) Range) and/or a switch port MAC address; be able to filter and monitor DHCP (Dynamic Host Configuration Protocol) traffic state to extract leased IP address; be able to save state in a case where an IP address assignment received is not in home range and/or authentication with a stored/preconfigured/default/expected switch port did not complete successfully (e.g., authentication may be completed with another switch port). In one embodiment OS dependent functionality may also be used. For example, installing new software and/or modifying already installed software may cause or result in an enterprise owned platform setting a flag. A flag may be one or a series of bits, digital and/or binary values, etc., which may be understood by a querying device to indicate a state or condition, or other information. For example, the flag set when software is installed and/or modified may indicate a potential taint in the machine. A system with a platform having a taint flag may be placed in triage mode, for example, until verification of the system integrity is completed.
In one embodiment partitioning the network and corralling network nodes may be accomplished through the use of VLAN tags/IDs. For example, one VLAN tag may represent the OK corral, and another VLAN tag may represent the NOT-OK corral. Additional VLAN tags may be used to represent differing levels of security within the OK corral and NOT-OK corral. In this manner multiple VLAN tags may be used to provide multiple levels of access security. An entire network (e.g., a campus environment, an enterprise network) may be virtually partitioned into VLANs, and each node within the network assigned to one of the VLANs. A guest node may be present in the network, which may not have knowledge of the VLAN tags/IDs employed by the network. In one embodiment a single port switched VLAN is used in the network, and a node using no VLAN tags (e.g., a guest) is treated as the most vulnerable.
A guest node (i.e., a platform not owned by the enterprise) may attempt to enter the network. Because the guest node is not owned by the enterprise, it may not have knowledge of what VLAN tags to use. Such a node may be treated as most vulnerable, and so be allowed network access only through triage subnet. Such a node may also not have some of the security functionality employed by nodes owned by the enterprise, for example, platform configuration monitoring. One functionality the node may not support is the above-mentioned setting a taint flag; thus, in one embodiment a system with a non-enterprise owned platform may always be placed in the NOT-OK corral, unless a mechanism may exist for enterprise management to monitor and/or verify the platform software configuration.
A rogue/attacker node may potentially sniff and get the VLAN tags in use by the network. The dirty rogue may attempt to run attack traffic with various sniffed VLAN tags to discover if one is not being monitored, which could then be exploited to infiltrate the network with attack traffic. In one embodiment such an attack may be anticipated, and mechanisms may be put in place to infer such malicious activity and/or automatically remedy the activity and/or indicate malicious activity to an administrator. For example, the use of invalid VLAN tags on a single port (or VLAN scanning) may trigger an alert to a management station, which may temporarily disable the port. In another approach, a network administrator may use different OK and NOT-OK VLAN tags for each or multiple subnets, with correct mapping for traffic crossing the subnets across the trunks. The network administrator may provide correct VLAN mappings from a central console for switches. Because the mapping may be performed at the switches, the attacker would potentially have to sniff traffic on all subnets to cover the entire network.
Mobile stations/nodes may also present another potential network vulnerability. Being mobile, a user of the station may remove the node from the network and access another network of unknown and/or distrusted security (e.g., at an airport, at a coffee shop/food establishment, at a sales location, etc.). In one embodiment the potential vulnerability of mobile stations may be addressed by having the platform save the state of its configuration when the mobile node leaves the network. Upon return to the network, the platform may analyze system characteristics/configuration and send the information to a vulnerability database cross check component on the network (e.g., as a separate node, as part of a management node, etc.). The mobile node may automatically use and/or be assigned a VLAN ID that maps to a NOT-OK corral VLAN until it receives a security indication (e.g., an MSS (minimum security specification), a security policy compliance confirmation, etc.) from the administrator. Once the administrator determines that the node meets the MSS or other policy, it may begin accessing the network using the OK corral VLAN ID. A desktop node may similarly send system specifications periodically to the vulnerability database checker to determine if there is an exploitable vulnerability in any of the applications on the node. If it is determined to be potentially vulnerable, the node may be configured to use the NOT-OK corral VLAN ID for all its traffic. The node may be changed back to begin sending traffic through the OK corral VLAN ID once the node conforms to a security specification (e.g., through installing a patch, running an update, etc.).
Various references herein to an “embodiment” are to be understood as describing a particular feature, structure, or characteristic included in at least one embodiment of the invention. Thus, the appearance of phrases such as “in one embodiment,” or “in alternate an embodiment” may describe various embodiments of the invention, and may not necessarily all refer to the same embodiment.
In one embodiment the network is subdivided/segmented/partitioned into multiple separate virtual segments/subnets. For example, a network administrator can partition the network into different VLANs via network infrastructure devices/tools that support this capability. For purposes of illustration, and not by way of limitation,
In one embodiment VLANY 100 represents a VLAN of systems considered to be safe, or free from vulnerabilities. Integrity of the systems may provide for network management to exercise less stringent monitoring of traffic from these systems. In one embodiment VLANX 110 represents a VLAN of systems considered to be potential vulnerability threats. Thus, traffic through VLANX 110 may be closely monitored, as contrasted to, or in comparison to, traffic associated with nodes of VLANY 100. For example, VLANX 110 may include one or more components to execute intrusion detection. Network intrusion detection system (NIDS) 111 represents the one or more components for detecting intrusion/protecting against intrusion. NIDS 111 may monitor traffic packets, identify users and/or targets, and signal breaches and/or potential breaches.
VLANX 110 may have a VLAN access point 120, which may represent a secure gateway, switch, router, and/or server, and may include a firewall. VLAN access 120 may provide additional security to prevent attack against or from a node in the network. Furthermore, VLAN access 120 may provide a mechanism for isolating VLANX 110 from VLANY 100. For example, traffic through (transmit and/or receive) VLAN access 120 may be restricted to prevent attack traffic from reaching nodes of VLANY 100. Nodes in VLANY 100 may also be prevented direct and/or indirect access to VLANX 110 and nodes within it. VLANX 100 may be considered a remedial subnet, a NOT-OK corral, a restricted area, etc.
Clients 101 and 102 may represent a variety of electronic systems, devices, machines, or apparatuses. For example, clients 101 and 102 may include a personal computer (desktop, laptop, palmtop), a server, a handheld computing device, personal digital assistant (PDA), wireless computing device, cellular phone, game console, set-top box, etc. The access of clients 101 and 102 may include wired and/or wireless connections with a routing/switching/access point on the network. Clients 101 and 102 may be a terminating or user devices of a network. Clients 101 and 102, as well as other clients that may be part of the network, may include a host platform, described in more detail below. The platform may include hardware and/or software to perform operations on the clients, e.g., to “run” clients 101 and 102. The platform may be monitored/queried to determine a state of the platform and/or a configuration of the platform to determine a level of vulnerability of the machine.
At a platform level of clients 101 and 102, the systems may include the ability to detect system characteristics like device information, operating system version, applied patches, details of applications installed on the machine, etc. One example includes using hooks into the OS to obtain this information. Alternatively, or in addition, a BIOS may be accessed/queried for information. This information may be stored in a location that is not directly under the control of the operating system and/or is in a secure portion of the system that is accessible only to authorized and authenticated entities. Isolation of the information may prevent a virus or worm from compromising the system and changing the secure data stored in this location. Periodically, this saved information may be transmitted to a known location in a secure manner, as discussed below. Also, in a mobile node the system information may be recalculated and transmitted when the node leaves and/or rejoins the network.
For purposes of example, client 101 will be described as a mobile (e.g., portable, a laptop, configurable to be easily removable from the network) node, and client 102 will represent a stationary (e.g., not easily removable, a desktop) node. Clients 101 and 102 may be nodes that will interact (e.g., transmit/receive/exchange traffic) over the network and/or with devices outside the network with one or more of various supported communication protocols. In one embodiment clients 101 and 102 include platforms owned by the enterprise associated with the network. The network may include a network policy, which is applied to each node desiring access to its resources. The network policy may include specifications for access, restrictions and/or limitations on use of the network, etc.
In one embodiment client 101 is introduced into the network. For example, client 101 may be connected for a first time, or client 101 may have left the network and later returned to it. As client 101 attempts to connect to the network, it may at first be considered a potentially vulnerable system because its platform is unverified. In the case of a new network entity, a state of the platform may be determined and the information sent to network management 150. In one embodiment client 101 employs a VLAN ID associated with VLANX 110. This may be through default configuration, automatic selection, assignment on startup (e.g., from network management 150), or any other mechanism. In the case of client 101 leaving the network and then returning, the state of the machine may be stored by the platform, and at connection (e.g., during authentication) the configuration of the machine may be tested. If the machine has fallen out of compliance, or in one embodiment, the mere fact that the machine accessed an unknown and/or non-secure network may cause the machine to be flagged for access through the remedial subnet. Access of client 101 of the network through the remedial subnet may continue in either case until the security of a platform of client 101 can be determined. For example, network management 150 may compare the state/configuration of client 101 against a database and/or a network policy. Client 101 may be determined to match the policy (be in compliance) or may be determined to require one or more components to come into compliance. Compliance may involve installing upgrades, patches, etc., on client 101. Thus, either as a new client, or as a returning client, client 101 may then be granted access to VLANY 100.
Another approach to follow when client 101 rejoins the network may be to simply not allow the system to access the network until a basic system validation check is completed, rather than redirecting its traffic over a separate VLAN. For example, the platform (e.g., via a microcontroller on a NIC) could be responsible for keeping track when the host leaves and reenters a network. Upon return, only management traffic may be allowed and the microcontroller may relay to management what has changed. The microcontroller may detect system configuration changes by maintaining the time when the system information was last queried and determining what was added or removed since then. If the changes meet the specifications for the network, the system may be allowed onto the network.
In one embodiment client 102 represents a stationary client. While the condition that client 102 accessed another network may be unusual or unlikely, other factors may cause client 102 to be considered a potentially vulnerable node. In the case of either client 101 or client 102, if a new security patch has been announced, if the client does not have the latest security patch, the client could be considered potentially vulnerable. Thus, client 102 and client 101 may periodically query and/or be queried by network management 150 to determine compliance with a security policy. This may occur over a communication link 103. In one embodiment link 103 is an out-of-band (OOB) communication link. An OOB link may be inaccessible to the OS and/or other applications on the clients, and thus be less susceptible to compromise. The clients and network management 150 may engage in secure communication over links 103 to exchange state information, transfer management data and/or commands, etc.
In one embodiment all machines that are part of the network include a link 103, a separate OOB management interface. This interface can be a component that resides on an Ethernet controller or a component that is on the chipset of the system. Using this interface and certain capabilities on an Ethernet controller and/or network interface access circuit (e.g., a NIC (network interface card)), the administrator can configure the machine to send all its traffic to a particular VLAN. For example, if client 101 is known to have a critical vulnerability, it can be configured via this OOB interface to send its traffic through the VLAN responsible to check for critical vulnerabilities. The security devices on this VLAN can then perform extensive checks on the traffic flowing within and out of that particular network. The network administrator can closely watch and eliminate attacks. Similar VLAN support may be used to make sure that traffic from visiting guest nodes that are not under administrative control of the network goes through extensive checks and network security devices of the visited network.
In one embodiment network management 150 represents one or more management elements on the network. This may include as one element, or as part of an element, a vulnerability database cross indexer/security database/policy decision point. A network administrator may maintain a database of known vulnerabilities of different applications and operating systems. For example, this information is typically available on various websites, and can be generally easily obtained. The vulnerability database and/or a function of network management 150 may be to cross-index the information with the machine characteristics sent by the machines currently on the network. A list of vulnerable machines and level of the threat can be determined and used to isolate these machines in VLANX 110.
Platform 210 may provide instructions and/or perform operations that access and/or control components of a graphics and memory controller hub (GMCH) 220 or equivalent. GMCH 220 may represent hardware, software, firmware or some combination of these. These may be embodied in discrete components as well as included in chipsets. In one embodiment GMCH 220 includes manageability engine (ME) 221, which represents hardware, firmware and/or a combination and/or functions of hardware/firmware on components of GMCH 220. Manageability engine 221 may include security functions/agents to perform security monitoring and/or updating on platform 210. Manageability engine 221 may include a secure memory to store information relating to a security function. For example, manageability engine 221 may generate/obtain a configuration state that is stored in a secure storage inaccessible to components of client 200, except properly authorized/authenticated components.
Client 200 may also include an interface controller hub (ICH) 230 or equivalent. ICH 230 may include input/output (I/O) controllers and/or interfaces. Platform 210 may provide instructions, data, and or control to ICH 230 and/or perform operations that access/control components of ICH 230. ICH 230 may include a network interface 232. Network interface 232 may include a network interface card, a network interface circuit built onto a computing platform, a wireless or wireline communication transceiver, etc. Network interface 232 may support multiple mechanisms that provide interface to the network, including multiple ports, various protocols (e.g., Internet protocol (IP), Internet control message protocol (ICMP), transmission control protocol (TCP), user datagram protocol (UDP), simple network management protocol (SNMP), Telnet, file transfer protocol (FTP), hypertext transfer protocol (HTTP), etc.), and may include various open connections. Traffic transmitted, received, and/or exchanged may be considered to go through, or pass through network interface 232 to client 200.
In one embodiment ICH 230 includes filter 231, which represents one or more components/mechanisms to provide traffic filtering/grooming/manipulation/monitoring. Filter 231 may refer to control functions and/or hardware to perform various operations on traffic to or from network interface 232 and/or may refer to the operations themselves. In one embodiment filter 231 includes various registers at a medium access and/or physical interface to provide configurable network access to client 200. Filter 231 may be inaccessible directly by platform 210, rendering filter 231 secure and agnostic to the configuration and/or state of platform 210. In one embodiment network interface 232 includes a secure OOB link to provide a state setting for filter 231. Through setting filter 231, a network manager can, for example, assign a VLAN access that is applied at filter 231, potentially independently of platform 210, to direct client 200 to access the network through an assigned VLAN (e.g., NOT-OK corral, OK-corral).
Connection parameter 240 represents access to one of various possible connections: VLAN 242, VLAN 243, and console 241. In one embodiment connection parameter 240 may be understood as a connection decision resulting from the settings of filter 231, rather than as a separate physical entity. Connection parameter represents that a connection may be made at the lower layers of client 200, based on settings indicated by an administrator. Console 241 may represent a management node, for example, a vulnerability database and/or checker. VLANs 242-243 may represent one or more VLANs into which the network is partitioned, to which client 200 may be assigned. The may include various levels of potential vulnerability and associated monitoring.
Verification and/or determination of the security of client 310 may occur through security server 320, which may represent a minimum security specification (MSS) server. In one embodiment client 310 includes an OOB communication channel with security server 320 and/or management server 340, one or both of which may in one embodiment obtain information regarding the configuration/platform state of client 310. If management server 340 receives the information, it may notify security server 320 of the potential vulnerability of client 310, for example, through a list of potentially vulnerable machines in network 300. Security server 320 may cross index/check a state of client 310 against a vulnerability database 321 located internal to security server 320 and/or a vulnerability database 322 located externally from security server 320, to which security server 320 has access. Vulnerability databases 321 and 322 may be implemented as data stored on a non-volatile storage medium (e.g., harddrive, Flash, etc.).
Management server 340 and security server 320 may be implemented with firmware, software, or a combination of firmware and software, or in hardware and/or a combination of hardware and software and/or firmware. The software and/or firmware content may provide instructions to cause executing hardware to perform various operations, including some or all of the functions/features described above. Instructions to cause a machine/electronic device/hardware to perform the operations may be received via an article of manufacture. An article of manufacture may include a machine accessible medium having content to provide the instructions, including a machine preloaded/preconfigured with software, and/or content available for access to download via a propagated carrier wave/signal. A machine accessible medium includes any mechanism that provides (i.e., stores and/or transmits) information in a form accessible by a machine (e.g., computing device, electronic device, electronic system/subsystem, etc.). For example, a machine accessible medium includes recordable/non-recordable media (e.g., read only memory (ROM), random access memory (RAM), magnetic disk storage media, optical storage media, flash memory devices, etc.), as well as electrical, optical, acoustical or other form of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.), etc.
Secure information agent 420 may include a secure memory, for example a Trusted Platform Module (TPM). Secure information agent 420 may include a non-volatile memory in which to store state information. The information may be determined by querying the platform and/or components of platform 410. Alternatively, platform 410 may be configured to pass the information to secure information agent 420. Secure information agent 420 may include logic, hardware, firmware, processing capabilities to perform secure storage and/or gathering functions. In one embodiment secure information agent 420 exists as a module in client 400. Alternatively, secure information agent 420 may be included as part of platform 410, assuming the security of the information may be preserved even if platform 410 were to be compromised.
Security agent 430 may operate in conjunction with secure information agent 420. In one embodiment the agents are separate entities/modules/units. Alternatively, agents 420 and 430 may be functions/parts of a single entity that acts as a double agent, providing the functions of both secure information agent 420 and security agent 430. Security agent 430 may include as a module and/or in functionality manageability engine 431. In one embodiment security agent 430 and/or secure information agent 420 represent a manageability engine of client 400. In one embodiment security information agent 420 and/or security agent 430 represent microcontroller circuits, for example on network interface 440.
Platform 410 and programs running on platform 410 may access network 460 through network interface 440. Network interface 440 may include one or more packet filters to provide traffic management. Network 460 may be partitioned as described herein. In one embodiment network interface includes OOB interface 441, which may represent a secure channel of communication. OOB interface 441 may be unavailable to platform 410, and may not be visible to platform 410. Secure information agent 420 and security agent 430 may access management services 450 through OOB interface 441. Management services 450 may include a vulnerability database cross indexer, a management server, a security server, a policy server, etc. In one embodiment management services 450 include multiple network nodes. In one embodiment management services 450 is within network 460. Management services 450 may be responsible for partitioning and maintaining network 460.
Client 400 may be a mobile node that leaves network 460 and later returns. Secure information agent 420 may store this information. In one embodiment security agent 430 determines that client 400 has left from secure information agent 420 and informs management services 450. Security agent 430 may then, either by configuration or by command from management services 450, prevent all traffic from client 400. Alternatively, security agent 430 may configure client 400 with a remedial VLAN ID, and access network 460 through a NOT-OK corral.
In one embodiment agents 420 and 430 are implemented with firmware, software, or a combination of firmware and software. Agents 420 and 430 may be implemented in hardware and/or a combination of hardware and software and/or firmware. The software and/or firmware content may provide instructions to cause executing hardware to perform various operations, including some or all of the functions/features described above. Instructions to cause a machine/electronic device/hardware to perform the operations may be received via an article of manufacture. An article of manufacture may include a machine accessible medium having content to provide the instructions. A machine accessible medium includes any mechanism that provides (i.e., stores and/or transmits) information in a form accessible by a machine (e.g., computing device, electronic device, electronic system/subsystem, etc.). For example, a machine accessible medium includes recordable/non-recordable media (e.g., read only memory (ROM), random access memory (RAM), magnetic disk storage media, optical storage media, flash memory devices, etc.), as well as electrical, optical, acoustical or other form of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.), etc.
The client may receive a VLAN ID to apply, 506. This assignment may be received via the OOB channel. The VLAN ID may include an assignment to an OK corral VLAN, or a VLAN with increased security to isolate the VLAN. Applying the VLAN ID may involve setting filter parameters in a network interface filter. Thus, the client may modify network interface parameters to use the VLAN tag, 508. The client may also modify network interface parameters to filter for the VLAN tag, 510. These modifications may include the settings of hardware registers in the network interface.
The management node in one embodiment receives the system state of an active node, 606. This may include a configuration of the platform of the node and/or other information to indicate whether the node is compliant with a security policy. If the node is secure, 610, the node may be assigned to an OK corral VLAN as partitioned in the network, 612. If the node is determined not secure, the node may be indicated to a network security node, 614. This may include the management node generating a list of nodes determined not secure. The node may then be assigned to a NOT-OK corral VLAN, 616, and have its traffic monitored with intrusion detection/tolerant systems and/or have its network access restricted. If there are more active nodes in the network that have not received an access assignment, the management node may receive the system information of the next node, and proceed with the process for each node to be considered.
The client's platform configuration may be received directly from the client at the security node via a secure connection, e.g., an OOB channel, 704. The configuration may be received in response to a query by the security node. If the client is owned by the enterprise, it may be configured with the OOB channel interface and respond with the necessary information. If the client is not owned by the enterprise, or is corrupted, it may not be able to respond. Thus, it is determined if the configuration is received for the client, 710. If no configuration is received, the client may be determined to be a potentially vulnerable machine or is a guest (and thus potentially not secure), and is assigned to the NOT-OK corral, at least until the client can be made compliant, 724. If the configuration is received, the configuration is compared to a vulnerability database, 712. If the client is compliant with the specified state in the vulnerability database, the client is assigned to the OK corral VLAN. If the client is not compliant, it may be assigned to a remedial VLAN, 724. If there are more nodes in a suspect client list, and/or if there are more nodes to verify on the network, the security node may determine the next client's configuration and proceed in a similar manner.
Besides what is described herein, it will be appreciated that various modifications may be made to embodiments of the invention without departing from their scope. Therefore, the illustrations and examples herein should be construed in an illustrative, and not a restrictive sense. The scope of the invention should be measured solely by reference to the claims that follow.
