General

Bolting the Back Door with NAC
Part 3: Comparing the alternatives — page five

by Lisa Phifer VP Core Competence, Inc. [June 22, 2007]

IETF Network Endpoint Assessment
TCG isn't the only organization working on interoperability. The IETF is defining the NEA framework to let network operators evaluate the security posture of a system when access is requested or anytime thereafter.

According to the latest draft, "Architectures similar to NEA have existed for some time and are present in shipping products, but do not offer interoperability...because they are implemented using primarily non-standards based technologies. The NEA working group is defining standard protocols so as to enable interoperability between devices from different vendors allowing network owners to deploy truly heterogeneous solutions." It is clear why proprietary CNAC and NAP protocols do not currently satisfy NEA goals, but to understand how TNC and NEA differ, we must dig further.

NEA focuses on posture assessment when the endpoint and network are owned by the same entity. It will not try to address cases where the user has not agreed to expose posture data or conform to a network's policies (e.g., public Internet access). Moreover, NEA deals exclusively with posture assessment; related actions like decision enforcement and endpoint remediation are beyond NEA scope. Finally, unlike TNC, NEA will not specify local component interfaces (APIs) or mechanisms to stop lying endpoints.

The latest NEA draft framework enumerates requirements for the following protocols:

• The Posture Attribute (PA) protocol will be a thin wrapper around sets of posture attributes exchanged between multiple Posture Collectors and Validators.
  
  
• The Posture Broker (PB) protocol will be a lightweight batching protocol used to multiplex PA messages onto a single Posture Broker Client/Server dialog.
  
  
• One or more Posture Transport (PT) protocols will provide for reliable PB delivery, mutual authentication and cryptographic protection, at connection request time and/or after connectivity has been established. PT protocols will themselves be carried by standard lower layer protocols like 802.1X, RADIUS, TLS, or IKE.
  
  
• A common set of generally-useful Attributes to be supported by all Posture Collectors. Vendor-specific attributes may also be conveyed over the PA protocol.

According to the group's charter, "Since there are already several non-standard [PA and PB] protocols, the NEA working group will consider existing protocols as candidates for the standard protocols. [The NEA] requirements document will be used as a basis for evaluating the candidate protocols. The working group may decide to standardize one of the candidate protocols, use one of them as a basis for a new or revised protocol, or decide that a new protocol is needed."

In other words, NEA is where comparable CNAC, NAP, and TNC protocols will compete until one standard emerges...eventually.

NAC-in-a-Box
No matter which architecture you choose, baking NAC into your network can reduce misuse and attack. But a recent Network Computing survey indicated that 60 percent of those who had deployed NAC took at least 7 months to do so. Cost and complexity were by far the most common barriers.

If you're not yet ready to invest in NAC network upgrades, consider a proprietary overlay appliance that provides some of NAC's benefits while assuming most of the burden. Infonetics Research reports that in-line NAC appliances accounted for more than half of worldwide NAC enforcement device revenue in 2006. Appliances are now available from many vendors, including Bradford Networks, Caymas, Cisco (Perfigo), ConSentry, FireEye, ForeScout, Lockdown, Mirage, Nevis, StillSecure, Symantec, and Vernier.

Overlay NAC appliances are inserted between endpoints and protected network resources—for example, in-line between access and distribution switches, or connected to a mirror port out-of-band. Products vary, but most try to minimize external dependencies by avoiding installed clients, intercepting existing traffic flows, and consolidating all NAC policy decision tasks—and even enforcement tasks—on the appliance itself.

Appliances simplify deployment, but the shortcuts that make them attractive can also limit network topology, security functionality, and long-term extensibility. In the long run, most analysts expect NAC enforcement to be embedded into existing network devices (switches, APs, routers, firewalls, gateways) a la CNAC, NAP, or TNC. In the meantime, NAC appliances represent a viable alternative to combat immediate network endpoint threats without waiting for network upgrades.

Conclusion
Now that we have compared NAC architectures, it is time to show NAC in action. In part 2, we decided to focus our test drive on a common case: controlling staff access to network resources, based on identity and compliance. We also hoped to deploy restricted customer access to colo servers and guest internet access. To do so, we decided to test Juniper Network's Unified Access Control (UAC 2.0).

Although CNAC and NAP are of significant interest to many readers, we wanted to illustrate NAC using heterogeneous network devices and clients. Specifically, we intended to combine the tested product with switches, APs, and clients that happened to already be in our lab, because most of us must deal with the network we have rather than the one we wish we had. An overlay NAC appliance could have done the trick, but we chose TNC to illustrate a standard network architecture, and that led us to Juniper.

In part 4, we'll share our lab experiences with Juniper's TNC-based client, server, and firewall products.

—End