Patent Application
20090158302
Aspects and features described herein relate to a system and method for translation of an application program interface (API) for communicating with a network access control (NAC) software agent.
The industrialized world is becoming increasingly dependent on computers and networks. While computing devices and data communications networks help make businesses and people more efficient by enabling users to obtain, process, and share information, our increasing dependency on them can also present special security challenges.
One of these challenges is ensuring the availability of computing devices and networks, and the data which is entered into, accessed from, stored on, or moved between different computing devices over the network.
Another security goal for computers and networks is ensuring the integrity of these computing devices and networks and all the details and data relating to the transaction, including the identity of the originator, the intended destination (person, process and/or computing device), date, and time of the transaction and transaction-specific information such as credit card number, item ordered, and mailing address.
Another security goal for computers and networks is ensuring confidentiality relating to computing devices and networks and the data relating to or stored on these computing devices and networks, such as online bank account balances, account numbers, login IDs, and passwords.
As described above, people and organizations frequently have a need or desire to ensure confidentiality, availability and/or integrity of computing devices, data networking devices, and/or the data stored on those devices. Unfortunately, people and organizations exist that have an explicit goal of accessing and examining confidential information, disrupting availability of computing or networking devices, performing unauthorized modifications to legitimate electronic transactions and/or electronically stored data, and/or creating illegitimate electronic transactions and/or electronically stored data. Such activities are collectively referred to as “computer attacks,” “network attacks” or simply “attacks” hereafter. An attack may target the availability, integrity and/or confidentiality of computing systems, network devices, and/or data.
One particular security attack scenario that has caused widespread concern is one where an end point becomes infected with malware at a given location and the end point is subsequently brought to a different location where the end point is then connected to the network. Once connected to the network, the infected end point could then attack or spread its malware to computing devices or networking devices directly or indirectly reachable over the network.
For this reason, individuals and organizations often install and operate computer and network security products designed specifically to protect computers, network devices or data from attackers and from attacks. Large organizations often spend considerable amounts of money to purchase commercial end point and network security products and invest considerable amounts of manpower to keep security agents and security hardware configured correctly, kept up to date, perform continuous monitoring, etc. These may be specialized hardware devices such as a firewall or secure email gateway, or alternatively may be specialized computer programs that run on general purpose operating systems such as Microsoft® DOS, Microsoft Windows®, PalmOS®, Microsoft WindowsCE®, Symbian®, Linux®, Unix®, BSD®, etc.
Security applications are typically explicitly designed by the product designer to run either on an end user's personal computing device, e.g. laptop computer, smartphone, PDA, etc. These computing devices will hereinafter collectively and generically be referred to as “end point computing devices,” “end points,” “personal computers,” or “personal computing devices.” Special purpose computer security programs designed to run on an end point computing device will hereinafter collectively and generically be referred to as “security agents” or “agents.” Security applications may alternatively be specifically designed and intended to run on a server computer accessed or used by multiple users, e.g. a mail server, web server, network print server, network file server, etc. The goal of all these security applications is to protect end point computing devices and servers from attacks.
Generally, the security agents installed on end points work as advertised and provide the expected level of protection. However, there are many situations in which a group of seemingly well-protected end points, servers and networking device, either in a standalone or interconnected mode, may not provide adequate protection. For example, a visitor or member of the organization may need to plug their personal computing device into the organization's wired or wireless network, but the visitor's computer does not have appropriate security agents installed or they are out-of-date, disabled, or misconfigured. Alternatively, a visitor or member of the organization may have accidentally or intentionally changed a configuration setting on a security agent, causing it to no longer provide certain types of protection, or may even have accidentally or intentionally removed or otherwise disables an installed security agent, causing it to no longer provide any protection. Another vulnerability can arise if a conflict between the security agent and the operating system or the security agent and another computer program installed on the end point results in the security agent not functioning completely, properly or causing it to be completely inoperable.
In all of these cases, the end point security agent does not provide the level of protection needed or expected by the organization, and the end point is therefore vulnerable to attacks or may already have been attacked. No matter how they are accomplished, such malware attacks can have considerable operational and financial consequences to an organization, including the costs to remove the malware from all impacted end points, servers and networking devices, the costs of data loss or data recovery, lost business due to unavailability of critical computers or data, disruption to normal business operations while cleanup operations are underway, etc.
For this reason, in addition to the use of security agents, there have been many different creative solutions to the problem of network protection. One approach that is rapidly becoming mainstream is a concept generically referred to in the industry as “network access control” or NAC. Note that this is also a proprietary trade name for similar security features, capabilities and products offered by Cisco Systems, Inc. under the term Network Admission Control. The term is however also generically used to refer to a security concept to be described shortly. Hereinafter, the term “network access control” or “NAC” will refer to the generic security concept whereas “Cisco Network Admission Control” or “CNAC” will refer to Cisco-specific products and capabilities.
NAC is a security concept specifically designed to protect the network and computing devices on the network from an infected or vulnerable end point. This is accomplished by essentially isolating any end point when it first connects to the network. If the end point is considered vulnerable or infected and is a potential threat to the network, it is said to be “out of compliance” or “noncompliant” or, alternatively, there is said to be a “compliance violation.” If the end point is considered safe and not a threat to begin with, it is said to be “compliant” or “in compliance” with the specified security goals of the organization and the network.
For example, before connecting to the network's resources, the end point can directly or indirectly connect to some type of networking device such as a Layer 2 Ethernet switch, Layer 3 router, wireless access point, wireless controller, wireless switch, etc., which has a capability to inspect end point data frames or packets and make a forward/filter (i.e. block) decision on the basis of that end point's current network access permissions. While the end point is so isolated, no network traffic other than data related to end point authentication, user authentication and/or inspection results can reach the end point and no network traffic from the end point can propagate onto the network. The end point thus remains isolated until an inspection of the end point has been performed, the inspection results examined and the network achieves a level of comfort that the end point poses no risk.
If malware is found on the end point or if the end point is missing an important security agent, has a misconfigured security agent, or has an out-of-date security agent, appropriate remediation actions may be necessary before the end point is permitted to transmit general traffic onto the network or receive general traffic from the network. Once the end point is remediated, where the remediation details are situation-specific, the network restriction is lifted by a network device, and the end point is granted unrestricted ability to send general data traffic onto the network or receive general data traffic from the network.
Such inspection and remediation can be accomplished by means of an “NAC solution” comprising a combination of computing devices, networking devices, data communications protocols, administration/management applications, user interfaces, directories or databases of data and/or software applications specifically designed to perform the collective activities described above or that support in some way those collective activities. These activities may be performed on separate computing or networking devices, combined onto the same computing device, or partially combined in a number of different possible combinations of integrated and standalone functionality.
An NAC solution typically includes the following logical components:
End Point: A computing device, e.g. a laptop computer, desktop computer, PDA, smartphone, server, etc. The end point might be on the same network as the NAC enforcement point, e.g. a laptop on the office LAN connected to an Ethernet switch in the nearest wiring closet or connected to a wireless access point. Alternatively, the end point may be remote from the NAC enforcement point, e.g. a user working from home or a hotel and connecting to an NAC enforcement point over an intermediate public or private network, e.g. the Internet or the PSTN.
End Point NAC Inspection Agent: A computer program that either persistently resides on the end point or is dynamically sent to the end point over the network at the time the network connection is established and inspects the end point for compliance with the network's security policies.
Enforcement Point: Network edge device that controls the end point's access rights on the network. All network traffic originating from the end point or destined for the end point flows through this point.
Authentication Server: Services authentication requests by comparing credentials presented in an authentication request to credentials stored in the user directory ad forwards end point security posture information for authenticated users to the policy server in the form of a compliance assessment request.
User Directory: A data repository containing user information such as a user ID, password, digital certificate information etc.
NAC Policy Server: Receives compliance assessment requests containing end point security posture information from the authentication server. Performs posture-to-policy comparison and determines access permissions. Returns an access control list to the authentication server.
As will be described in more detail below, the NAC inspection agent may perform different types of end point inspections, including directly querying other software programs running on the end point or receiving asynchronous notification messages from other software programs running on the end point. Hereinafter, the end point NAC inspection agent is also referred to simply as an “NAC agent.”
There are several commercially available NAC solutions utilizing NAC agents on the market. All major networking equipment vendors have embraced the concept of Network Access Control and are aggressively extending the functionality of existing network devices, including Cisco® Network Access Control (CNAC), Microsoft® Network Access Protection (NAP), and Juniper Networks® Endpoint Defense Initiative (JEDI). There are also numerous point solution vendors pushing dedicated NAC appliances, for example, Lockdown® Networks, Consentry Networks®, InfoExpress, and Vernier Networks®. Some vendors, e.g. Cisco® Systems, may offer more than one kind of NAC products, each having different feature sets. Major security-centric vendors, e.g. Symantec® and McAfee®, also offer NAC solutions.
While there are a number of NAC options available, many vendors have created a proprietary, vendor-specific method that often is not interoperable with other vendor-specific methods. This is not surprising as different vendors often produce dissimilar solutions to similar problems. If interoperability is not a specific design goal and there is no integration requirements defined during an engineering or software development project, then interoperability with other technologies and products will not occur.
There are also open-source NAC solutions under development, such as PacketFence, Rings, NetReg®, FreeNAC®, HUPnet, Ungolant. These open-source products are meant to give organizations an ability to procure a zero-cost NAC solution. If the features and capabilities do not fully address of the organization's needs, the organization has access to the source code and can create incremental code or modify existing code to tailor the feature set as needed. However, because each of these projects is independently developed, it is unlikely that there will be any interoperability among these projects or interoperability with any of the commercial, vendor-specific NAC solutions or NAC standards previously described.
To address this issue of interoperability, there are some industry-wide, standards-based NAC solutions under development. These include the Trusted Computing Group's (TCG™) Trusted Network Connect (TNC) initiative and the Internet Engineering Task Force's (IETF) Network Endpoint Assessment (NEA) initiative. These standards are meant to give network vendors, software developers and organizations a common framework, set of data communications protocols and set of standardized application programming interfaces (APIs). The intent is that if different companies design their products to a consistent set of interfaces and standards, it should be possible for different NAC components from different vendors to interoperate. However because there are two different standards, interoperability between NAC solutions still remains problematic.
In addition to these standards, other standards in the networking world provide extensibility features that allow different vendors and different user organizations to add additional features on top of the standard. These proprietary extensions require additional custom software to be written to support the transmission or receipt of the additional features. It is also important to note that even though standards may exist, vendors may continue to offer, promote and indeed extend their own proprietary offering if the standard does not meet the vendor's needs.
Application programming interfaces (APIs) are commonly used in software development, including the development of software for security agents used with NAC solutions. An API is a defined messaging interface into and/or out of a software component to provide an interface through which two software components can communicate. Depending on how the API is implemented, multiple applications may simultaneously be able to use or communicate with the same API. However, the communication capabilities supported (e.g. the types of information that can be forwarded or received) as well as the mechanical details of how the communications occur (e.g. what language is used, the structure of messages, command syntax, how to reference data objects, programming language used, etc.) still can be defined by the author of that software component.
Applying this concept to NAC agents, the designer and/or vendor of each NAC product or standard that includes an NAC agent as part of its solution can determine whether or not an API for the purpose of inspecting other applications configurations and/or status (hereinafter an “inspection API”) is offered. The NAC agent designer/vendor also can determine the programming language used, the services offered by the API, the services required by the API, and the minute structured details of each message supported across the API's messaging interface. In addition, the details of these APIs can vary widely across available NAC solutions.
Given that there are numerous NAC solutions available and anticipated to become available over the next few years, it is difficult and costly for a software development organization to support each available NAC solution, NAC agent, and particular NAC API. For example, as standards and vendor-specific solutions evolve, the API capabilities and design details are highly likely to evolve as well, requiring renewed, repeated integration efforts to support the new NAC agent API version 2, version 3, version 4, etc., which can require significant labor costs, overhead costs, and opportunity costs.
Given these costs, a developer or organization that author and maintain a given application must decide how many NAC solutions, NAC agents and NAC agent APIs they will support, and if less than 100% of the solutions available today and in the future, which ones will be supported, when will that support be added, and in what order (i.e. relatively priorities of each NAC agent API). Most application developers and organizations are likely to only invest time, effort and money to support a very small number of NAC agent APIs. This creates a “solutions gap” when there is demand for a specific application (and by implication the owning developer and/or organization) to support a new, additional API not currently supported. No matter how legitimate the needs of one customer or application user, the direct costs, indirect costs, and opportunity costs of writing code to that additional API will weigh down on the developer and development organization and continue to create a constraint around which NAC agent APIs to support and integrate with.
Ideally, a developer or development organization could write an application according to one API that could interface with any application or equipment regardless of the API.
This summary is intended to introduce, in simplified form, a selection of concepts that are further described in the Detailed Description. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.
Embodiments in accordance with aspects and features described herein provide methods and systems for a Network Access Control Application Programming Interface Translation Agent (hereinafter referred to as an “NAC API Translation Agent”). An NAC API Translation Agent can translate messages written for one NAC agent API into a format suitable for use with a different NAC agent API. Multiple NAC agent APIs can be thus supported, and multiple NAC agent APIs can be used simultaneously.
One benefit of an NAC API Translation Agent in accordance with aspects and features described herein is that it can decouple a software application that needs to support a particular NAC agent API from that NAC agent, and enable it to be used for any NAC agent. This makes it possible for organizations that use NAC solutions and that want to develop or use NAC-integration-capable software applications to select and use the NAC agent of their choice without affecting the software application. Conversely, it makes it possible for organizations to select and use the software application of their choice, knowing that via the NAC API Translation Agent they can use the software application with any NAC solution, NAC agent and NAC agent API.
One embodiment of an NAC API Translation Agent in accordance with one or more aspects described herein can act as a translator for a software application that has been integrated with one specific NAC agent API and thus supports a specific NAC agent API to permit it to communicate with a different NAC agent API that is not directly supported by the application. Another embodiment of an NAC API Translation Agent in accordance with one or more aspects described herein can simultaneously support two or more software applications that each support a different NAC agent API and allow the applications to support an altogether different NAC agent API that neither software applications natively supports. Other embodiments of an NAC API Translation Agent in accordance with one or more aspects described herein can be used in cases where an organization upgrades their NAC solution and NAC agent to a new version or replaces their NAC solution vendor, and can allow existing applications that do not natively support the new NAC agent version or vendor to communicate with such newer or different NAC agent vendors or versions. Additional embodiments of an NAC API Translation Agent in accordance with aspects herein can be used in cases where an organization upgrades or replaces a software application from one that supports the API used by the organization's NAC solution to one that does not, and can allow such new software applications to communicate with the existing NAC agent without having to replace the NAC agent or its associated NAC equipment. Still other embodiments can be used in the case where an organization uses many different software applications on the end point computing device, some of which support the desired NAC agent API, and some of which do not, and an NAC API Translation Agent in accordance with one or more aspects herein can be used for those software applications that do not support the desired NAC agent API so that they can operate alongside those applications that do support the desired NAC agent API.
Thus, an NAC API Translation Agent in accordance with one or more aspects and features described herein can enable organizations to choose the combination of NAC agents and software solutions that best suit their needs. In addition, organizations can upgrade or change the equipment used for their NAC solutions and upgrade or change the associated NAC agent without having to make corresponding changes to other software that might wish to communicate with the organization's network. Moreover, developers of software solutions will not have to write separate software methods to address each NAC agent's API but can write one software method and be able to interface with any NAC agent, thus enabling software vendors to offer more streamlined software at a lower cost.
The aspects summarized above can be embodied in various forms. The following description shows, by way of illustration, combinations and configurations in which the aspects can be practiced. It is understood that the described aspects and/or embodiments are merely examples. It is also understood that one skilled in the art may utilize other aspects and/or embodiments or make structural and functional modifications without departing from the scope of the present disclosure.
In particular, aspects and features of an NAC API Translation Agent may at times be described herein in the context of particular NAC solutions or NAC equipment vendors such as those provided by Cisco Systems, Inc., Juniper Networks, or Microsoft®, or in the context of particular software applications such as Symantec Norton Antivirus®, Symantec Endpoint Protection®, McAfee VirusScan®, Trend Micro AntiVirus®, but it should be noted that these particular solutions, vendors, and applications are merely exemplary, and that aspects and features described herein can be applied equally as well to other solutions, vendors, and applications.
In addition, although aspects of an API Translation Agent are described herein in the context of Network Access Security, network security equipment and security applications on a network or on an end point computing device, API translation methods and systems described herein can be equally applicable to any procedures used by a network to check an end point computing device for compliance with network policies or configurations. For example, if an enterprise uses Cisco equipment for its authentication or policy servers, an API translation method and system in accordance with aspects described herein can be used to allow the network equipment to interface with any software residing on the end point computing device to check whether the device has the proper software or proper versions of software loaded and ready so that the device is compatible with the requirements of the network.
As previously described, people and organizations frequently have desire to ensure confidentiality, availability and/or integrity of computing devices, data networking devices, and/or the data stored on those devices.
Network Access Control (NAC) is a security concept specifically designed to provide these types of protection. A “NAC solution” can include computing devices, networking devices, data communications protocols, administration/management applications, user interfaces, user directories, data repositories, and/or software applications specifically designed to work to protect a network and/or computing devices from security vulnerabilities.
For example, when an end point first connects to the network, the end point can directly or indirectly connect to a networking device such as a Layer 2 Ethernet switch, Layer 3 router, 802.11 access point, or wireless switch which inspects end point data frames or packets and makes a forward/filter (i.e. block) decision on the basis of that end point's current network access permissions. Initially the end point is isolated, such that the end point is unable to transmit or receive any network traffic other than data specifically related to end point device authentication, user authentication and/or end point inspection results. The end point thus remains isolated until an inspection of the end point has been performed, the inspection results examined and the network achieves a level of comfort that the end point poses no risk. At this point, a series of commands can be sent to various network devices that cause the end point to have more liberal and possibly unrestricted network access privileges.
An NAC solution must collect end point security status information in order to determine whether the end point is in compliance or out of compliance with organizational security policies. Focal points for end point inspections performed by an NAC agent can include the operating system running on the computing device and security agents running on the computing device.
Different NAC solutions offer different capabilities, have different limitations, and have different purchasing, installation and ongoing support costs. Different solutions may be more or less optimal for different user groups and network.
The following is a high level description of the logical components typically included in an NAC solution:
End Point: A computing device, e.g. a laptop computer, desktop computer, PDA, smartphone, server, etc. whose security status is in question and must be assessed.
End Point NAC Inspection Agent or “NAC Agent”: A computer program that can either persistently reside on the end point or be dynamically sent to the end point over the network at the time the network connection is established. Can directly inspect the end point and/or query other applications (via an API) residing on the end point to collect a specified list of end point security parameters (collectively known as the end point security state or security posture). An NAC Agent also can create an aggregated list of security parameters and their current values (hereinafter “inspection results”) and forward the aggregated inspection results to the enforcement point in a separate security status message or as additional data attributes appended to a different type of message, e.g. authentication. Inspection results reported by the NAC Agent can be presented to the enforcement point so that the network can determine appropriate network access privileges.
Enforcement Point: A network edge device to which the end point is directly or indirectly connected. The enforcement point receives inspection results from an end point and forwards them to an appropriate device (e.g. authentication server or assessment server). The device returns an access control list (ACL) of some type (e.g. VLAN, SSID, MAC Address filtering, IP address filtering, etc.) to the enforcement point. The device applies the ACL which then controls the end point's network access privileges, permitting, restricting or totally blocking traffic to and from a particular end point based on its current end point state.
Authentication Server: Services authentication requests by comparing credentials presented in an authentication request to credentials stored in the user directory. The authentication server can relay end point inspection results between an enforcement point and an assessment or policy server.
User Directory: A data repository containing user information such as full name, user ID, password, department, organization role(s), and/or policy information (e.g. policy group(s), required antivirus program, required firewall vendor and version, etc.).
NAC Policy Server: Receives inspection results (e.g. from enforcement point or authentication server). Compares inspection results to required end point status and determines network privileges. Generates an ACL which is transmitted to an enforcement point or authentication server.
In accordance with one or more aspects described herein, and NAC agent can directly inspect the end point to collect security state information. Direct inspections are typically queries directed at the operating system about installed applications, running applications, and the operating system itself, for example, determining whether a specific process is resident in memory, searching the file system for the presence of specific folders/directories and/or files, or searching for the presence of a configuration setting on the end point.
Alternatively, an NAC agent can inspect specific applications running on the end point through the use of an Application Programming Interface (API). An API is a defined messaging interface that initiates and/or receives requests, initiates and/or receives notifications and/or initiates and/or receives status messages to/from specific applications running on the end point.
An NAC agent API may simultaneously support communications with one or more applications running on the end point. Note that communication capabilities (e.g. the services offered and the types of information that can be provided or received) as well as the mechanical details of how the communications occur (e.g. what programming language is used, the structure of messages, command syntax, how to reference data objects, etc.) are completely defined by the API designer. One skilled in the art can appreciate that there can be many differences among the different APIs that work with different NAC agents. In fact, there are currently many types of available NAC solutions available today; each having a different API. If an application does not support that API, communication with the NAC agent via the API is not possible.
An exemplary configuration of a network NAC solution is shown in
As shown in
Using the network solution elements shown in
The NAC agent, for example, residing on campus desktop computer 101, can inspect the end point for specific conditions at time of authentication. Depending on implementation details, the NAC agent may also inspect the end point periodically for the remainder of the network connection. The NAC agent can marshal and aggregate the end point inspection results and transmit them to the network connectivity device, for example, Ethernet LAN switch 103. Authentication credentials may accompany or immediately precede the end point inspection results, depending on implementation details. Ethernet LAN switch 103 can then forward the inspection results (and if applicable the authentication credentials) to authentication server 121. This may occur as part of an authentication transaction and/or may occur some time subsequent to an authentication transaction.
Authentication server 121 can authenticate the user of campus desktop computer 101 by comparing the presented authentication with credentials stored in an authentication database or user directory 119. If the inspection results are associated with an end point that has already been authenticated, this step may be skipped.
If the user or end point successfully authenticates, authentication server 121 can send a request containing the end point inspection results to the NAC policy server 125 so that compliance assessment of desktop computer 101 can be performed. NAC policy server 125 can compare the just received end point inspection results with administratively defined end point policies stored in an NAC policy database 123 for that particular user, that particular end point or the particular group or role that the user or end point belongs to. This comparison process is commonly referred to as a “compliance assessment.”
Depending on whether or not end point is compliant and the particular compliance exceptions or violations that may exist, the NAC policy server 125 can create an access control list (ACL) appropriate for that end point and that end point's current compliance status. NAC policy server 125 can then return a compliance status response message and the ACL to authentication server 121, and authentication server 121 can return an authentication status response message and the ACL to the network connectivity device, e.g., Ethernet LAN switch 103. Ethernet LAN switch 103 can then send a status message to desktop 101 and applies the ACL using a traffic filtering process.
In accordance with aspects described herein, desktop 101 can receive a status message indicating whether or not network connectivity has been granted. The end point may also receive a status message indicating whether or not any compliance violations were detected, indicating whether or not any network access restrictions are currently being applied, indicating whether or not any remediation is required, indicating what remediation steps the user must perform and/or indicating that full network access has been granted.
Desktop 101 may also display a status message to a user, automatically initialize a software application (e.g. a web browser), start to transmit data to accessible servers on the network, and/or transition to an idle-but-connected state and wait for user commands. Desktop 101 and the end user of desktop 101 now have authorization to utilize computing resources from corporate application server 115 across the network 117, for example, email, documents, or other resources.
As described above, an NAC agent can be a software application that either resides on the end point device or that is dynamically sent to the end point over the network at the time the network connection is established and inspects the end point for compliance with the network's security policies. A logical configuration of an exemplary NAC agent on an end point computing device is shown in
As shown in
As noted above, end point inspection logical component 207 can collect information regarding end point security parameters from end point computing device 201 via an API. It should be noted that the particular collection method utilized by any specific NAC agent can vary depending on how the software for the NAC agent it written, and thus may be vendor-specific or application-specific.
NAC agent processing logic 209 is the core logical component of the NAC agent. It is responsible for executing business logic and for controlling all processing and communication activities performed by the NAC agent, including managing all end point inspections and API message exchanges via the NAC agent end point inspection logical component. Processing logic 209 can also direct inspection component 207 to inspect end point computing device 201 via the API on the basis of an elapsed time interval, a directive received from a network device, in response to a system event or in response to a message received via an inspection component API. Combinations of these triggering events are also possible.
Processing logic 209 can also manage communications with the network via NAC agent network communications input/output messaging component 211. Processing logic 209 can proactively communicate status information or end point inspection results to the network device, can communicate the same in direct response to a directive or request from the network device, can receive configuration settings from the network device and reconfigure itself accordingly, and/or receive configuration settings and persist them to a local configuration settings data repository.
NAC agent network communications input/output messaging component 211, sometimes called simply “NAC agent network interface.” This component of an NAC agent in an end point computing device can receive commands, software updates and/or status messages from one or more network devices; transmit end point inspection results, status messages and/or security alerts to one or more network devices, and communicate with NAC agent processing logic 209 via an inter-process communications method. Various methods for communicating with network devices exist in the art and are not described herein.
NAC agent configuration settings 213 include data values, rules, etc. that the NAC agent uses to drive certain behaviors. There could be any number of configuration values, and the values may be mandatory or optional, single value or multi-value.
Examples of configuration settings that an NAC agent may use include IP address of a remote server the NAC agent needs to send information to; inspection interval, i.e., interval in minutes or seconds between period inspections the end point security parameters; text of status messages to display to a user of the end point computing device in certain situations; and list of applications or security agents to be detecting during polling of the end point computing device. These or other configuration settings used by the NAC agent can be transmitted to the NAC agent during routine communications with a network device, may be included as part of the NAC agent installation package, or a combination of those two approaches.
NAC agent User Interface (UI) component 205 is a logical component that may or may not be part of an NAC agent, depending on the NAC solution used. The UI component provides a method by which the NAC agent can display status information to the user of the end point computing device. For example, it may be necessary to inform a user of situations such as need for or initiation of an end point inspection, discovery of one or more security or compliance issues during inspection, or the need for remediation activities in order for the user and the end point computing device to obtain unrestricted network access. The nature of information displayed on NAC agent UI 205 can vary depending on the NAC solution used.
UI component 205 can also provide one or more user controls that an end user can use to control or influence the NAC agent's behavior and functionality. For example, the NAC agent may provide user controls that allow a user to open or close the UI, manually initiate an end point inspection or manually initiate one or more remediation activities. As with the type of information displayed, the user controls provided on NAC agent UI 205 can vary depending on the NAC solution used.
As shown in
The remaining components shown in
As described above, an API is a messaging interface authored and designed to allow one software component (component A) to communicate with other software components (B, C, D, etc.). Once software component A's API is designed, it is these other software components (B, C, D, etc.) that must be explicitly modified, extended or enhanced in order to be able to support component A's API and thereby be able to receive and pass messages to/from component A via the API.
An NAC-specific example will illustrate this point. Cisco Systems, Inc. (hereinafter “Cisco”) has an NAC solution (“Cisco® NAC” or “CNAC”) that includes an NAC agent product called the Cisco® Trust Agent (“Cisco® CTA” or “CTA”). The CTA has an API that provides a messaging interface to communicate with other applications, e.g. a security agent such as an antivirus security agent. Symantec®, Trend Micro®, and McAfee® are examples of vendors with commercially available and widely used antivirus security agents. If these or other antivirus vendors, security application vendors, vendors of other types of applications, or organizations with applications they developed or use internally want to have the ability to pass application configuration, current status, and historical event information to the CTA via the CTA API, they must design, code, test and verify software code written expressly for this purpose, and written exactly as specified and documented in the NAC agent API design specification.
When NAC agent API integration does not exist, it creates a potential security vulnerability even when an NAC solution and NAC agent are deployed. This is because in the absence of NAC agent integration, there is a limited amount of information the NAC agent can collect about the application. It is entirely possible that a security vulnerability exists on the end point or indeed the end point is already compromised, yet because there is no API integration with the NAC agent, the NAC agent is unable to collect information that would expose this security risk.
A similar risk exists if the organization selects NAC solution X, resulting in NAC agent X and NAC agent API X, and a particular application only supports NAC solution Y, NAC agent Y and NAC agent API Y. Even if the particular application supports NAC agent and NAC agent API Y and W, the fact that it does not support NAC agent API X and the corresponding NAC solution used or desired to be used by the organization creates a security risk.
While NAC agent API support and existing API integrations can be one evaluation criterion for choosing a particular NAC solution, an organization should not have to choose a suboptimal NAC solution just because that particular NAC agent has already been integrated with the applications of interest to the organization. Conversely, an organization that has selected the NAC solution that best meets their needs should not have to still be exposed to security risks because the organization has applications that are not integrated with the NAC agent. Ideally an end user organization should be able to pick any application and have it easily integrate with any NAC agent, regardless of the API differences among NAC agents.
An NAC API Translation Agent in accordance with aspects described herein can resolve many of these problems of integrating NAC solutions with NAC agents and software applications. As shown in
A first logical component comprises a set of multiple NAC API Translation Agent NAC API software modules or functionality “blades” 409a, 409b, 409c . . . 409n. Each software module or blade is a clone, replica or emulation of a single, specific NAC agent API, including vendor specific versions (Cisco, Juniper, Microsoft, etc.), vendor-version versions (CTA v1.0, CTA v2.0, CTA v3.0, etc.), standards-based APIs (IETF NEA, TCG™ TNC, etc.) or open-source NAC agent APIs (FreeNAC®, NetReg®, etc.). Each software blade can emulate a specific NAC agent API and can be a vehicle through which software application 403 reports end point inspection results and receives end point inspection commands. When software application 403 is communicating with one of software modules 409a . . . 409n, the software application 403 believes it is communicating directly with the actual NAC agent 405. A blade 409a . . . 409n and the NAC API Translation Agent 407 can thus service or provide services via an API to a software application 403 by emulating an NAC Inspection Agent 407 and in particular by emulating an NAC Inspection agent API 415a.
A second component is NAC protocol translation and routing business logic 411. This logical component can consist of custom software code and configuration rules necessary to know which blades 409a . . . 409n to use to communicate with software applications 403 (by emulating an NAC Inspection agent 405) and which blades 413a . . . 413n can use to communicate with an actual NAC Inspection agent 405 by emulating a software application 403 and perform the necessary message translations.
A third logical component is an NAC API Translation Agent NAC API Client, which comprises a series of software modules or functionality “blades” 413a, 413b, 413c . . . 413n. Each software module or blade can be written to fully support a specific NAC agent API 415a, including vendor specific versions (Cisco, Juniper, Microsoft, etc.), vendor-version versions (CTA v1.0, CTA v2.0, CTA v3.0, etc.), standards based APIs (IETF NEA, TCG™ TNC, etc.) or open source NAC agent APIs (FreeNAC®, NetReg®, etc.). Each software blade 413a, 413b, 413c . . . 413n can communicate end point inspection results from software applications 403 and can support bidirectional status messages and notifications in accordance with the design requirements of a specific NAC agent API 415a and NAC inspection agent 405. Each software blade 413a, 413b, 413c . . . 413n also can communicate directly to the actual NAC Inspection agent 405 using the real NAC agent's API 415a. In accordance with one or more aspects described herein, when NAC API Translation Agent 407 communicates with NAC Inspection agent 405 via NAC agent API 415a, NAC Inspection agent 405 believes it is communicating directly with the actual software application 403.
This capability of the NAC API Translation Agent has considerable value in that it effectively “decouples” the NAC Inspection Agent API support built into the software application (in which the software application only supports NAC Agent API X) from the NAC Inspection Agent API support built into the NAC Inspection Agent (which only supports NAC agent API Y). This decoupling provides freedom of software application selection without concern for what NAC Agent API(s) the software application supports or what NAC Agent API exists in the preferred NAC solution and NAC agent. This decoupling further provides freedom of NAC solution and NAC agent selection without concern for what NAC agent API is supported by the preferred software applications. By eliminating this interoperability constraint, software applications and NAC solutions/NAC agents can be independently evaluated and selected based on their other capabilities and merits, knowing that connectivity between the preferred software application(s) and the preferred NAC solution/NAC agent can easily be achieved by leveraging the capabilities of the NAC API Translation Agent.
Some exemplary practical embodiments of an NAC API Translation Agent in accordance with aspects and features described herein are discussed below.
One exemplary embodiment of an NAC API Translation Agent in accordance with aspects and features described herein is shown in
As shown in
In accordance with aspects described in more detail below, an NAC API Translation Agent 505 can emulate a specific NAC agent API to permit a software application 503 to interface with the NAC Agent API used on the end point computing device 501. For example, in the exemplary embodiment shown in
This capability can allow an organization to select the best software application for its needs regardless of which NAC agent API the software application supports. This capability also can allow an organization to select the best NAC solution and NAC agent for its needs regardless of whether or not all existing software applications support that particular NAC agent's API.
In the example shown in
In accordance with aspects described in more detail below, an NAC API Translation Agent can simultaneously emulate multiple different specific NAC agent APIs. In the exemplary embodiment shown in
This capability allows an organization to simultaneously use different software applications that support different NAC agent APIs while only requiring one NAC agent to be installed on the end point. This capability also allows an organization to select the best NAC solution and NAC agent for its needs regardless of whether or not all existing software applications support that particular NAC agent's API.
In another embodiment, for example, as shown in
Rather than force the organization to also replace the software application with a newer version or one from a different vendor that supports the new NAC agent API, an NAC API Translation Agent can be used to solve the problem. The NAC API Translation Agent can allow a software application to continue to integrate with the same NAC agent API that the software application originally integrated with, for example, Cisco® CTA API while also allowing the application to communicate with the newer, different NAC agent vendor or version. This can save the organization money because the software application will not need to be upgraded or replaced with an application that can communicate with a new NAC agent API. It also can ensure that the software application can continue to report end point inspection results to the network so that only properly protected end points are able to connect to the network.
In the exemplary embodiment of such a scenario shown in
Software application migration is the opposite of NAC agent migration. In this scenario, the organization needs to or elects to replace a software application. The old software application did support the NAC agent API and was successfully integrated, however the new software application does not. The following hypothetical example illustrates the point: Assume the organization was using the Symantec Antivirus agent which supports the Cisco® Trust (NAC) Agent API. The organization is also using the Cisco® Trust Agent. The organization wants to replace the Symantec® Antivirus agent with the McAfee® Antivirus agent. The McAfee® agent supports the Juniper® NAC agent API, but not the Cisco® Trust Agent API. The organization must find some way to get the McAfee® agent to communicate with the Cisco® Trust Agent using the Cisco® Trust Agent API. An NAC API Translation Agent in accordance with one or more aspects and features described herein can bridge this gap, translating messages to/from the McAfee® Antivirus agent that are formatted in accordance with the Juniper® NAC agent API requirements to messages formatted in accordance with the Cisco® Trust Agent API, and then relaying messages to/from the Cisco® Trust Agent via the Cisco® Trust Agent API.
Alternatively, when there are multiple software applications on the end point computing device, some of which support the desired NAC agent API, and some of which do not, an NAC API Translation Agent can be used for those software applications that do not natively support the desired NAC agent API, and can operate alongside those applications that do natively support the desired NAC agent API.
An NAC API Translation Agent in accordance with one or more aspects described herein can comprise three main components and two data repositories:
A plurality of NAC Interface Emulator Modules;
A single Protocol Translation and Routing Module; and
A plurality of NAC Inspection Agent Interface Modules
A single data repository that contains Configuration Settings and NAC Protocol/NAC API Translation Tables.
A single data repository that contains Diagnostic Logging Events of interest.
The operation of these components will be described in more detail below.
An exemplary embodiment of an NAC API Translation Agent showing these Components and Modules is shown in
Alternatively, Antivirus Application 903b may be compatible with the Juniper® NAC Agent API but wishes to report end point inspection results such as ANTIVIRUS_VENDOR=Symantec®, ANTIVIRUS_VERSION=10.5.0.1, ANTIVIRUS_RUNNING_STATE=active, ANTIVIRUS_LAST_UPDATE=20071129, or ANTIVIRUS_FILE_SYSTEM_PROTECTION_STATE=1 to a Cisco® CTA Client Version 2 API 907a. Using Firewall Application 903a as exemplary, communication between the application and the NAC agent residing on the end point computing device can be accomplished as follows. A message from Firewall Application 903a which is formatted according to a Cisco® NAC Agent API, for example, identifying the personal firewall vendor, version, running state and last update date, can be routed through Cisco® Trust Agent Emulator module 909a to NAC Protocol Translation and Routing Module 911. Using one or more of Policy Configuration and Translation Tables in memory 920, NAC Protocol Translation and Routing Module 911 can translate the message to a message formatted according to the API used by the NAC client installed on the end point computing device, for example, the Microsoft® NAP Client 907c. The translated message can be routed to the appropriate NAC Inspection Interface Module 913, in this example, to Microsoft® NAP Plugin 913c, which can then forward the message from Firewall Application 903a to Microsoft® NAP Client 907c, which can successfully process the message containing end point inspection results because it has been translated by the NAC Protocol Translation and Routing Module 911 to the proper syntax and format as required by the Microsoft® NAC API.
In an alternative embodiment, if two or more software applications, e.g., a Personal Firewall Agent 903a and an Antivirus Agent 903b, require NAC API translation support by the NAC API Translation Agent, the NAC API Translation Agent can load two or more instances, or “threads,” of a particular NAC Interface Emulator Module (e.g. two instances of an emulated Cisco® NAC Posture Plugin application 909a). Each such Module can interface with a specific software application, e.g. the Personal Firewall Agent 903a or Antivirus Agent 903b mentioned above, so that Translation and Routing Module 911 can provide registration and translation services on behalf of those two or more software applications.
The modular design of an NAC API Translation Agent in accordance with one or more aspects described herein provides can have many benefits. For example, it can provide a flexible framework to easily add and support additional NAC agents and particular NAC agent APIs. In addition, the modules can be implemented as libraries that can be updated independently, both of other modules and of the main application. The modular design also enables additional interfaces to be supported or new versions of already supported interfaces to be added without having to upgrade the entire application. This also enables unneeded libraries to be removed, reducing the overall size of the NAC API Translation Agent and thus improving performance. In addition, the modular design of NAC API Translation Agent 905 enables programming errors or bugs in one module to be fixed and updated without having to update the entire NAC translation agent application 905.
A second benefit of an NAC API Translation Agent in accordance with one or more aspects and features described herein is that behaviors and capabilities can be driven by easily configurable and easily extensible configuration policy settings and translation tables 920. As further described below, a policy-driven configuration provides the ability to easily and dynamically add and subtract support for new NAC agents and NAC agent APIs as applications are added or changed on the end point device. Along with a policy base configuration, the translation mapping between vendor interfaces can be table-driven. As described in more detail below, translation tables can also be easily and dynamically updated as new interface modules are added without having to upgrade the entire application.
In an exemplary embodiment, an NAC API Translation Agent in accordance with one or more aspects and features described herein can be implemented as a system service, or “daemon,” that runs in the background from the time the device is started and until it is shutdown. In alternative embodiments, it also could be implemented as an application that starts on demand from a user, an application that is automatically started when another application is started, or an application that is automatically started in response to a particular system event.
When an NAC API Translation Agent in accordance with one or more aspects herein is started, the main software program executable can load into memory and begin executing a series of programmatically defined initialization tasks, including loading the NAC Protocol Translation and Routing Module, querying the Policy Configuration and Translation Tables to determine which NAC Interface Emulator Module(s) to load into memory (or alternatively simply loading every NAC Interface Emulator Module), querying the Policy Configuration and Translation Tables to determine which NAC Inspection Interface Module(s) to load into memory (or alternatively simply loading every NAC Inspection Interface Module), and executing any NAC agent specific registration tasks necessary to make the NAC agent(s) installed on the end point aware that the NAC API Translation Agent is a software application wishing to communicate with and report end point inspection results to the NAC agent(s).
Other programmatically defined initialization tasks can also be performed during the startup process as, appropriate or necessary for the situation. Individual NAC Interface Emulator Modules and/or individual NAC Inspection Interface Modules can initiate their own series of programmatically defined tasks, including but not limited to querying the Policy Configuration and Translation Tables for configuration information and then acting on that information as appropriate. One task performed by NAC Interface Emulator modules is determining what software applications installed on the end point computing device have registered to report end point inspection results to an NAC agent. That information, along with information regarding the currently installed NAC Agent(s) on the end point computing device can be used by the NAC API Translation Agent to perform registration tasks on the software application's behalf so that an NAC Agent not natively supported by the software application can be made aware of the software application's presence and its interest in reporting end point inspection results to the NAC Agent.
The discussion below provides a more detailed description of some exemplary embodiments of components and modules that can be used in an NAC API Translation Agent in accordance with one or more aspects and features herein. To illustrate aspects of the an API translation system and method as described herein, detailed examples are discussed in the context of two representative NAC agents (Cisco and Juniper®) and NAC agent APIs (Cisco® and TNC). Note that as previously described above, the Juniper® NAC agent recently adopted support for the TCG™ TNC IF-IMC API as its NAC Agent API, therefore the terms “Juniper® NAC Agent API” and “TCG™ TNC NAC Agent IF-IMC API” (hereinafter “TNC API”) are considered identical, and as illustrated and described herein refer to the Juniper® NAC agent API whose message syntax and content is as defined by the TCG™ TNC IF-IMC Interface Specification, a publicly available document. Those skilled in the art will readily observe that the NAC API Translation Agent discussed below can be equally capable of supporting additional NAC agents and translating between additional NAC agent APIs and is not limited to the specific examples described herein.
The Cisco® NAC agent API and the TNC API are a series of vendor-specific software modules developed according to specifications and requirements of the vendor or standards developer, as the case may be. For example, the Cisco® NAC agent API is developed according to specifications and requirements relating to Cisco's NAC equipment and software, whereas the TNC API is developed according to specifications and requirements intended to provide an industry standard, but will interface only with equipment that also use that standard. In either case, these APIs can be used to directly interface to a specific vendor's NAC client to receive one or more different types of NAC request messages and then provide one or more different types of NAC response messages including but not limited to end point inspection results.
By industry convention, it is assumed by the NAC agent vendor that the NAC agent is directly communicating with the end point security agent (or another user application for which NAC integration is of interest). However, by using an NAC API Translation Agent in accordance with aspects and features described herein, the NAC agent can communicate with the NAC API translation agent, which can then translate and route messages between the NAC agent using one NAC agent API and the end point security agent (or another user application) using a different NAC agent API.
It can be understood by persons skilled in the art that terminology can vary based on the vendor or standard used. For example, Cisco Systems® refers to the software application (e.g. Personal Firewall Agent, Antivirus Agent) with which the Cisco® Trust Agent is communicating as a “Cisco NAC Posture Plugin” or simply a “posture plug-in” that returns end point inspection results in the form of “posture credentials” over the “posture agent API” to the “posture agent” (i.e. the Cisco® Trust Agent). As another example, the Trusted Computing Group (TCG™) refers to the software application (e.g. Personal Firewall Agent, Antivirus Agent) as an “end point Integrity Measurement Collector (IMC)” that communicates end point inspection results in the form of “end point posture integrity measurements” over the “IMC Interface (IF-IMC)” API to the “Trusted Network Connect (TNC) Client”, which is any NAC agent implementing an NAC Agent API which conforms to the TCG™ TNC IF-IMC Interface Specification. In accordance with conventions in the art, vendors can often supply Software Development Kits (SDKs) and sample code to aid software developers in writing code that is compatible with their specific equipment or software. Such software development kits can also be used by practitioners in implementing an NAC API Translation Agent in accordance with one or more aspects and features described herein.
As shown in
In accordance with aspects herein, an NAC Inspection Interface Module 913 can be implemented as a multi-threaded process. For example, one thread can be waiting on NAC input requests from the vendor NAC agent (for example, Cisco® Trust Agent 907a shown in
To accomplish the goals of an NAC API Translation Agent in accordance with one or more aspects and features described herein, the individual NAC Inspection Interface Modules 913a . . . 913n can perform the following functions:
Initialize with NAC Protocol Translation and Routing Module 911 and register with the specific vendor interface, for example, the Cisco® Trust Agent Posture Plugin API;
Process NAC requests, responses, and notifications from the NAC Agent, e.g. 907a, 907b . . . 907n, end point security or other applications, e.g. 903a, 903b . . . 903n, and the end point computing device operating system; and
On shutdown, cleanly disconnect in an orderly fashion from the NAC Agent interface.
In accordance with aspects described herein, each of these tasks can be implemented as an abstract interface, or façade, supported by all NAC Inspection Interfaces 913a, 913b . . . 913n.
Exemplary NAC API Translation Agent software methods (also known as software functions or software calls) in an NAC Inspection Interface Module are shown in
The NAC_Init API 1001a shown in
One or more of the tasks undertaken to register with the vendor's NAC Agent can be vendor specific and can be defined by the NAC agent vendor's API. For example, a Cisco® Trust Agent (CTA) on a Windows platform can create an INF configuration file and can place the posture plug-in DLL and configuration file in the Cisco-defined “posture plug-in directory”, a common, shared folder used by all software applications that communicate directly to the CTA via the CTA API, and thus used by the NAC API Translation Agent. For TCG™ TNC-compliant NAC systems on a Windows platform, a registry key can be created that points to an Integrity Measurement Collector (IMC) stub Dynamic Link Library (DLL), and in such a case, the registry key can be located in a specific file, for example, in a file having a file address “HKLM\Software\Trusted Computing Group\TNC\IMCs hive,” a registration method used by all software applications that communicate directly to the TCG™ TNC NAC Agent via the IF-IMC API, and thus used by the NAC API Translation Agent.
As noted above, an NAC Inspection Interface Module 913 can be implemented as a multi-threaded process. An input thread can implement the vendor specific API to receive NAC requests. Contents of the request can be buffered and passed to NAC Protocol Translation and Routing Module 911. Some examples of these requests formatted according to a specific API include processPostureRequest for Cisco® Trust Agent and TNC_IMC_Beginhandshake for TNC compliant agents.
The output thread can interface to NAC Protocol Translation and Routing Module 911 via the NAC_Response 1001b and NAC_Notification 1001c APIs shown in
The NAC_Shutdown API 1001d can be called when the NAC Translation Agent is closing down. In accordance with processing protocols used in the art, an NAC Inspection Interface module 1001 should notify its respective vendor agent, for example, Cisco® Trust Agent 907a, Juniper® UAC client 907c, etc. shown in
To accomplish the goals of an NAC API Translation Agent in accordance with one or more aspects and features described herein, the individual NAC Interface Emulator Modules 909a . . . 909n can perform the following functions:
Initialize with the configured applications;
Forward NAC Requests to the application;
Return NAC Responses and Notifications received from the end point applications to the NAC Protocol Translation and Routing Module; and
On shutdown, cleanly disconnect with the application interface.
In accordance with aspects described herein, each of these tasks can be implemented as an abstract interface or façade supported by each of NAC Interface Emulators 909a, 909b . . . 909n.
Exemplary NAC API Translation Agent software methods (also known as software functions or software calls) in an NAC Interface Emulator Module 1003 are shown in
In accordance with aspects herein, Emulator_Init API 1003a can be called after an NAC Interface Emulator library is loaded as part of the startup process previously described. This software module can receive specific policy configuration information at this time.
During initialization of the NAC API Translation Agent, all initialization tasks of individual applications can also be performed. In accordance with protocols known in the art, the tasks necessary to initialize with a configured software application wishing to communicate to a specific NAC Agent are vendor- and application-specific. For example, for a Cisco® Trust Agent 907a acting on a Windows® platform and a software application such as an antivirus application wishing to communicate with that Cisco® Trust Agent, in accordance with procedures known in the art, the software application such as an antivirus application (known as a “posture plug-in application” in Cisco parlance) creates INF configuration files and places posture plug-in DLLs and the INF configuration files in the Cisco® Trust Agent posture plug-in directory on the end point computing device. The Cisco® Trust Agent NAC Agent only looks in the posture plug-in directory to learn about what software applications are on the end point computing device that want to communicate with the Cisco® Trust Agent. As part of NAC API Translation Agent initialization, Cisco® Trust Agent Emulator 909a can search the end point computing device folder structure for these particular files, and from their presence learn of the particular type and properties of the software application wishing to communicate with and supporting API integration with a Cisco® Trust Agent. Based on the specific NAC Agent currently running on the end point computing device or in accordance with a policy-based configuration setting stored in the Policy Configuration and Translation Tables 920, the NAC API Translation Agent 905 thus performs, on behalf of a software application such as an antivirus application wishing to communicate with a Cisco® Trust Agent, the vendor- and application-specific tasks necessary to initialize the software application in accordance with the initialization method required by the actual NAC Agent 405 in use or planned to be used on the end point computing device, for example a Juniper® Networks NAC Agent 907b using the TCG™ TNC IF-IMC NAC Agent API.
Similarly, the NAC API Translation Agent 905 can load instances of the Cisco® NAC Posture Plugin 913a into the Cisco® posture plugin directory, where each instance represents or emulates a single particular software application such as a personal firewall agent 903a or an antivirus agent 903b. This load process will enable the Cisco® Trust Agent to discover the software applications wishing to communicate with it.
As a second example, an end point computing device may have a TCG™ TNC-based NAC Agent such as Juniper® UAC Client 907b acting on a Windows platform and a software application such as a personal firewall (known in TCG™ parlance as an “integrity measurement collector” or “IMC”) wishing to communicate with that TCG™ TNC-based NAC Agent. In accordance with procedures known in the art, the software application installs an IMC stub DLL in a directory of the software application's choosing when the software application is installed on the device. The software application must also create a Windows registry key that specifies the file name and directory path where the IMC stub DLL is located. The TCG™ TNC-compliant NAC Agent, e.g. the Juniper® UAC Client 907b only examines this registry key to learn about what software applications are on the end point computing device that want to communicate with the TCG™ TNC-compliant NAC Agent.
As part of the NAC API Translation Agent initialization, Juniper® UAC Emulator 909b can search the Windows registry for these particular keys, and from their presence learn of the particular type and properties of the software application wishing to communicate with and supporting API integration with the TCG™ TNC-compliant NAC Agent. Based on the specific NAC Agent currently running on the end point computing device or in accordance with a policy-based configuration setting stored in the Policy Configuration and Translation Tables 920, the NAC API Translation Agent 905 thus performs, on behalf of a software application such as a personal firewall application wishing to communicate with a TCG™ TNC-compliant NAC Agent, the vendor- and application-specific tasks necessary to initialize the software application in accordance with the initialization method required by the actual NAC Agent 405 in use or planned to be used on the end point computing device, for example a Cisco® Trust Agent 907a using the Posture Plugin API.
Similarly, the NAC API Translation Agent 905 can load instances of the Juniper® UAC NAC Interface 913b into a system folder and create a Windows registry key specifying the name and system path for each instance, where each instance represents or emulates a single particular software application such as a personal firewall agent 903a or an antivirus agent 903b. This load process will enable the TCG™ TNC-compliant NAC Agent such as the Juniper® UAC Client to discover the software applications wishing to communicate with it.
In accordance with one or more aspects and features described herein, NAC Interface Emulator Modules 909 can thus determine what installed software applications have registered to report end point inspection results using the process defined by and used by the specific NAC agent. Furthermore, the NAC API Translation Agent 905 can thus perform, in accordance with one or more aspects described herein, a NAC Agent-specific registration action on a software application's behalf so that the NAC Agent currently installed on the end point knows to query and expect end point inspection results from the software application using the software application detection method specific to and unique to that NAC Agent, the appropriate registration action required for that NAC agent not supported by or performed by a software application because the software application supports a different NAC agent and performs a different registration action specific to the different NAC Agent.
In accordance with some aspects and features described herein, this registration action can be performed by NAC Protocol Translation and Routing Module 911, though it is contemplated and within the scope of the present disclosure that any of the components of the NAC API Translation Agent 905 can perform this registration action.
As previously described, the specific registration actions vary widely and are unique for each vendor NAC solution. The NAC API Translation Agent 905 is similarly able to perform many other types of NAC Agent-specific registration actions for each NAC Agent it supports on behalf of each software application.
Like NAC Inspection Interface 909, NAC Interface Emulator 913 can be implemented as a multi-threaded process. One thread can be waiting on requests from NAC Protocol Translation and Routing Module 911 to initiate a posture request to the end point software application, while the other thread waits for the software application response(s) and notifications. This multi-threaded design can allow NAC Interface Emulator 909 to always be available to process incoming events. In accordance with one or more aspects described herein, NAC Protocol Translation and Routing Module 911 can simultaneously support multiple end point applications, using either the same NAC Interface Emulator for all or different NAC Interface Emulators for one or more applications. This is true both for the NAC Interface Emulator Modules 909 side as well as the NAC Inspection Interface Modules 913 side.
The input thread can interface to NAC Protocol Translation and Routing Module 909 via an Emulator_Request API 1003b shown in
The output thread can implement a vendor-specific API to receive NAC responses and notifications from an end point security application written in accordance with that specific API. Contents of the responses, for example, responses from Firewall Application 903a using a Cisco® API or Antivirus Application 903b using a Juniper® API are buffered and then passed to Protocol Translation and Routing Module 909 by using either the Emulator_Response 1001b or Emulator_Notification 1001c API. As noted above, some examples of these messages include processPostureRequest message formatted according to the Cisco® Trust Agent and a TNC_TNCC_SendMessage for TNC-compliant agents.
The Emulator_Shutdown API 1003c shown in
Read the policy-based configuration information;
Initialize both the Inspection Interface modules and the NAC Interface Emulator modules;
Route NAC information requests and responses between vendor specific modules;
Translate data between vendor specific interface modules;
Register software applications for required NAC Agents on behalf of installed software applications wishing to report end point inspection results and already registered to use one specific NAC Agent;
On shutdown, terminate all vendor-specific modules; and
Update policy configuration and translation mapping tables.
In accordance with one or more aspects and features described herein, when NAC API Translation Agent 905 is initiated, it can read the policy configuration files and translation mapping tables into memory classes. Based on this configuration it can load any NAC Inspection and NAC Interface Emulator libraries needed to support the range of installed software applications and the range of NAC agents the software applications support, as well as to support the installed NAC Agent. Running an NAC API Translation Agent in this manner can provide the ability to customize and optimize the NAC APIs that are actively running at any given time and is can thus aid in streamlining and improving performance. An alternative embodiment is to simply load all libraries for all of the supported NAC APIs, both on the NAC Inspection Emulator side as well as the NAC Interface side, at initialization.
Once the module libraries are loaded, the NAC_Init 1105a and Emulator_Init 1101a APIs can be called. Upon successful initialization, NAC Interface Emulator Module 1101 can be ready to receive notifications or service requests from a software application (e.g. a Personal Firewall Agent or Antivirus Agent) and can similarly be ready to receive notifications from NAC Protocol Routing and Translator Module 1103. Upon successful initialization, NAC Inspection Interface Module 1105 can be ready to receive notifications or service requests from an NAC Agent (e.g. the Cisco® Trust Agent or Juniper® NAC Client) and can also similarly be ready to receive notifications from NAC Protocol Translation and Routing Module 1103. If a module fails to initialize due to missing libraries, bad or missing configuration entries, applications not registered on the device, unrecognized NAC Agent type, etc., an NAC API Translation Agent in accordance with aspects described herein can attempt to return an error message to the vendor's NAC system and can log diagnostics information specifying the point of failure.
As with the NAC Interface Emulator module 1101 and NAC Inspection Interface module 1105 described above, NAC Protocol Translation and Routing Module 1103 shown in
Two exemplary information processing flows in accordance with one or more aspects and features described herein are shown in
The sequence shown in
As shown in
In accordance with one or more aspects and features described herein, a destination end point security application can be identified by Vendor ID and Application Type. An Attribute Value Pair (AVP) data format used by the Cisco® Posture Agent API can be translated to the appropriate format for that end point security application using a table-driven mapping function using mapping data stored in the Policy Configuration and Translation Tables 920. For example, as shown in
The translated message can then be routed to the Emulator_Request API 1201a in an NAC Interface Emulator Module, which is in this example is a Juniper® UAC Client NAC Interface Emulator Module. This can cause the Juniper® UAC NAC client NAC Interface Emulator module to create, send, and expect to receive message(s) necessary to communicate the need for an inspection request to the software application (e.g. a Personal Firewall Agent) using message types and message syntax as defined in the TCG™ TNC IF-IMC API Interface Specification. For example, using TNC messaging TNC_IMC_NotifyConnectionCharge 1201b and TNC_IMC_Beginhandshake 1201c, the Juniper® UAC Client NAC Interface Emulator Module 1201 can initiate communication with the security application requesting information regarding the security posture of the device and then await end point inspection results from the software application via a TMC-TNCC_SendMessage 1201d.
When the end point inspection results are received from the software application by way of TNC_TNCC_SendMessage 1201d, the Juniper® UAC Client NAC Interface Emulator Module 1201 can return the data values to the NAC Protocol Translation and Routing Module 1203 using Emulator_Response API 1203c. The posture attributes can then be translated to the Cisco® Trust Agent Attribute Value Pair (AVP) format using a table-driven mapping function by a command Translate TNC to CTA 1203d and the translated information resulting in attributes identified and encapsulated in accordance with the Cisco® Trust Agent Posture Attribute API. The data can then be returned to Cisco® NAC Posture Plug-in 1205 using NAC_Response API 1205b.
The processPostureRequest call can now be completed with posture attributes and a result code indicating success.
The posture change notification sequence shown in
As shown in
The message can then be translated to the appropriate message format for the destination NAC agent by the process TranslateTNCtoCTA 1303b shown in
The NAC_Notification API 1305a can then be called, and the Cisco® NAC plug-in can set a notification flag to true. When the Cisco® Trust Agent NAC agent performs its next queryPostureStatusChange periodic poll 1305b, a non-zero value can be returned, which can indicate an end point security posture attribute has changed since the last end point security posture request initiated by the NAC Agent. The NAC Agent can then upload this information to the network or alternatively create a posture validation request and transmit the message to the end point software application in order to obtain more detailed information about the security event.
Once all of the authentication information from the end point computing device is processed, the end point computing device 801 can connect to the network and either obtain full network access if it is in compliance or restricted network access if it must be remediated to be in compliance with the network's policies.
When the end point computing device 801 is being shut down, a notification message is typically broadcast by the operating system. The NAC API Translation Agent 905 can monitor for system shutdown notifications, and upon detection of such notification, shut itself down in an orderly fashion. This includes but is not limited to terminating all active NAC Interface Emulator Module threads 909, terminating all NAC Inspection Interface Module threads 913, logging any session information of interest to the diagnostics logging facility 615 and releasing any memory buffers being held.
As noted above, an NAC API Translation agent can perform translation of messages formatted according to one NAC Agent API into messages formatted according to another, different NAC Agent API by using translation and mapping tables. In accordance with aspects herein an NAC API Translation Agent can be configured to download one or more policy configuration files and translation mapping tables from, for example, an HTTP download site. A configuration parameter stored in a policy configuration settings data store located on the end point computing device can define a URL corresponding to a DNS hostname or IP address of a computing device able to receive update requests from the NAC API Translation Agent and return new configuration settings, an updated translation mapping table, and/or NAC API libraries as needed. Configuration parameters also can exist for time of day to perform the download, retry frequency in case the site is initially unreachable and alternate download sites in case the primary site is unreachable.
An Inspection Interface to NAC Interface Emulator combination can use mapping tables to translate NAC attributes between interfaces. The Input table can map an Inspection Interface attribute to an NAC Interface Emulator attribute and an Output table can map an NAC Interface Emulator attribute back to the Inspection Interface attributes. Both tables can have the format shown below.
These table attributes are described below. In accordance with one or more aspects, any of the contents of this table can be added, removed, or modified as needed using the update process described above i.e. from an HTTP download site having a policy-defined DNS hostname or IP address.
Attribute Code: A code that is unique per Vendor-ID and Application-Type.
Attribute Length: The maximum length, in bytes, of the attribute value.
Attribute Type: The basic data type of the attribute. Types include String, Integer32, Unsigned32, Octet Array, Time, Version, IPv4Address, and IPv6Address.
In addition, an application that is being serviced by an NAC API Translation Agent can have a configuration entry having the following parameters:
It can be seen from the above description of end point applications and NAC agents that software applications often support only one or two NAC Agent APIs, yet several may exist. A developer or author of a software program that wants to support a broader set of NAC Agent APIs, including different vendors and/or different versions, must undergo the hardship of designing, coding, testing and distributing a new version of their software application that supports the new NAC Agent API of interest, including NAC Agent-specific registration procedures, if any. This hardship must be repeated for every software application wishing to communicate to a new NAC Agent via a new NAC Agent API. Software developers would benefit from having a specialized NAC API Translation Agent as any software application could automatically support a new NAC Agent API by having the NAC API Translation Agent perform the necessary message translation and registration process on the software application's behalf.
The NAC API Translation Agent can emulate any number of NAC Agent APIs by creating a vendor-specific or standard-specific and version-specific NAC Interface Emulator Module by creating message handlers that emulate the NAC Agent API functionality described and documented in publicly available NAC Agent API programmer reference guides or interface specifications. Similarly, the NAC API Translation Agent can act as a fully NAC Agent API-compliant software application for any number of NAC Agent APIs by creating a NAC Inspection Interface Module that responds to NAC Agent commands and provides notifications to the NAC Agent using message types and message syntax as documented in publicly available NAC Agent API programmer reference guides or interface specifications.
The NAC API Translation Agent can also emulate any number of software applications and communicate with any number of NAC Agents on their behalf by performing any necessary registration actions on each software application's behalf and by emulating or purporting to be a specific software application (e.g. a Personal Firewall Agent, Antivirus Agent, etc.) when exchanging information between a NAC Inspection Interface Module and the actual NAC Agent. The necessary message routing between a given NAC Interface Emulator Module and the appropriate NAC Inspection Interface Module is performed by the NAC Protocol Translation and Routing Module, which also performs the necessary registration actions on each software application's behalf, performs message translation using hard-coded and/or lookup-table driven translations, configures its behavior automatically using policy configuration values obtained from a policy data repository, obtains software, modules and data updates from a download server on a periodic basis and logs diagnostic and Agent events to a Diagnostic Logging data repository.
Although particular embodiments, aspects, and features have been described and illustrated, it should be noted that the invention described herein is not limited to only those embodiments, aspects, and features. It should be readily appreciated that modifications may be made by persons skilled in the art, and the present application contemplates any and all modifications within the spirit and scope of the underlying invention described and claimed herein. Such embodiments are also contemplated to be within the scope and spirit of the present disclosure.
