12.5. Working with the TNC Architecture
In the TNC architecture, the TNC Client (TNCC) gathers the collected information about an endpoint device's security, integrity, and posture state from the various Integrity Measurement Collectors (IMCs) which monitor specific applications, products, and services on the endpoint device. The TNCC transmits this captured data via the 802.1X client or supplicant, VPN client, Web browser that initiates an SSL connection, or other method that serves as the Network Access Requestor (NAR).
The NAR communicates the data — usually through a tunneled EAP type — to the switch, wireless access point, firewall, or other access device that serves as the Policy Enforcement Point (PEP). Then — and again, typically through a tunneled EAP type — the PEP communicates the collected data on the endpoint's security state and integrity to the server-side Network Access Authority (NAA).
The NAA passes the captured state and integrity data through the TNC Server (TNCS) to the Integrity Measurement Verifiers (IMVs), which check and verify the integrity and state information provided against the policies for a specific application, service, or product, as determined by the organization. Based on these checks, the IMV formulates an action recommendation, which it communicates to the TNCS. The TNCS takes the received IMV action recommendations and, based on the organization's pre-defined baseline security and access control policies (defined in the TNCS), combines the IMV action recommendations with its own action recommendations, thus creating the TNCS action recommendation. It communicates its TNCS action recommendation to the NAA. The NAA determines whether it can admit the endpoint device to the network based on the information and recommendations that it receives from the TNCS, as well as the policies provided by the organization. For example, your organization may decide to limit network access based on certain state or integrity criteria, and deny network access completely based on other criteria.
The NAA makes the determination and communicates the final action recommendation — whether it should grant the endpoint device network access — to the switch, wireless access point, firewall, or other device that acts as the PEP for enforcement.
12.5.1. Extensibility and architectural options
Although the TNC architecture defines a published, open standard for NAC, in 2008, the TCG added two new optional architectural components, as well as an associated optional protocol interface that extends the existing TNC architecture to encourage and support in-depth, interoperable, coordinated network defense leveraging heterogeneous, vendor-agnostic environments. Many network security components — such as firewalls, intrusion detection systems (IDSs), intrusion prevention systems (IPSs), data leakage prevention (DLP), and so on — don't interface with one another. They're independent systems, limited in their ability to share information for network or traffic visibility and monitoring. These TNC extensions deliver a standards-based method of addressing real-time network protection. For example, they can use devices that change security state post-admission or endpoint devices that your organization doesn't manage (such as endpoint devices from guest users, contractors, partners, or others).
The optional, standard interface — the Interface for Metadata Access Point (IF-MAP) — is a client-server protocol that defines access to an optional, new component called a Metadata Access Point (MAP). Metadata is real-time information about network devices, policies, status, states, behavior, and relationships between network devices and systems (including security events, network identity, network location, and so on) that it can share. The optional MAP stores the metadata information, and the optional IF-MAP standard protocol provides identifiers and data types for the metadata, as well as defining the processes by which it may publish or search the stored metadata. Systems and services that monitor the network, behavior, or traffic (such as IDS or DLP) may serve as MAP clients, using IF-MAP to report strange or dubious behavior to the MAP. The MAP alerts the PDP to implement appropriate enforcement actions, in conjunction with the PEP. Some MAP clients may even be able to parse and interpret information from IF-MAP, fine-tuning their own detection rules. IF-MAP aids network security by enabling security devices to share identity information.
Therefore, your organization can leverage your existing network investment in AAA; NAC solutions; IDS/IPS; DLP; firewalls; and other security, authentication, access, and other network devices — not to mention endpoint security systems — so that those investments focus on securing and protecting your network through a coordinated, vendor-agnostic security response across heterogeneous network deployments that involve multiple products and product types. Your organization can also use better reporting and more easily integrate data — regardless of device or vendor — into logging and reporting systems, such as security event management (SEM) and security information and event management (SIEM) systems.
The TNC architecture also broadens the scope of components and entities that can supply information to an Access Requestor or request access on their own. Another TCG standard, the Trusted Platform Module (TPM), can interface with the TNC architecture as an added factor in the access control decision process. The TPM (a microcontroller that stores keys, passwords, and digital certificates) attaches to the motherboard of most new notebook and desktop computing systems, and you can find TPMs in other endpoint devices, as well. Information stored on a TPM is secure from software attack or theft. Use of a TPM in the TNC architecture is optional; a TPM isn't a required component of the TNC architecture. But, if your organization takes advantage of the security and protection that a TPM's keys, passwords, and certificates provide, you can easily accommodate this process and involve it in your endpoint-device integrity and posture checks, and access control decisions. It provides a hardware root of trust from the endpoint device into the network. It also addresses the hairy problem of rootkits. When it uses TPM and TNC together, it forms a solution to a critical NAC problem — the lying endpoint. A lying endpoint is a corrupted endpoint device that sends all-clear messages from various security and malware applications when, in reality, device security has been compromised and malware is running rampant on the endpoint device. By incorporating the TPMs in computers and many other devices into an adopted TNC architectural process, you can have a secure method of ensuring that endpoint devices are trustworthy and delivering actual, true security and access control measurements in the access control decision-making process.