The NAC Snack

This Musing continues the discussion of Cisco’s Self Defending Network Initiative (SDN), particularly as related to Network Access Control (NAC), to create a baseline for discussions next year about the pros and cons of a wide range of emerging approaches to solve LAN security problems. Phase 1 of SDN – Host Protection via Cisco’s Secure agent (CSA) -- was discussed in the last Musing. This Musing picks up with Phase 2. 

Phase 2 of Cisco’s SDN is Network Access Control (NAC).  NAC is an industry initiative sponsored by Cisco, using the network infrastructure to enforce security policy compliance on all devices seeking access to the network.  Cisco launched NAC in June 2004. 

In NAC, all devices are required to “log in” to the network before access is allowed.  This is a concept that has been mainstream in wireless LANs for some years, but is now being extended more generically to all network connection points – wired, wireless, and remote access. 

Via software on the end station (host), NAC generates an additional piece of information that is used by the Authentication Server to determine whether to allow a user to connect to the endpoint, and/or what resources to allow it access to when it does connect.  This information, combined with their credentials, will determine the access permission decision.   Right now the focus is on the security posture of the end system.  The theory is, if you can ensure that every connected device has the right anti-virus software with the latest .DAT files, the right OS patches, and anything else an enterprise might establish as policy for their client-side security software configuration (such as personal firewalls or host-based IDS such as Cisco’s CSA), then you will have greatly reduced the probability of attack and damage from viruses and worms. 

NAC itself is broken down into Phases.  NAC Phase 1 was delivered in the summer of 2004 and is focused on the access of remote and branch office users to corporate resources.  NAC Phase 2, the target timing of which has not yet been clearly established by Cisco (but I suspect the 1^st half of 2005), will extend the capability to LAN-connected users using 802.1x as the access protocol.   NAC Phase 2 is actually much more interesting to me than NAC Phase 1 because the problem of protecting the LAN is the extreme pain point that Tom Garland and I observed this past year.  Also, viewing every Ethernet and wireless client as a potential source of infection is a much bigger problem than perimeter security is and requires a much more expansive approach. 

But by examining NAC Phase 1, we can get some clues as to how NAC Phase 2 will work.  The diagram below was taken from some Cisco literature:

NAC Solution Architecture (Phase 1)

For Cisco, a key element of NAC is the Cisco Trust Agent (CTA) which is presently supported on NT, Windows 2000, and XP server and desktop platforms.  The CTA is free from Cisco and is also being provided to 3^rd party partners for free.  The CTA communicates internally with other co-resident agents, such as Cisco’s CSA and/or 3^rd party vendor’s software like McAfee VirusScan (AV), Symantec SAV and SCS (AV), TrendMicro Office Scan (AV), and Tivoli agent (application and software status).   

The CTA then provides the following functions:

• ·         Network communications (presently EAPoUDP)

• ·         Application communications (EAP/TLV broker)

• ·         Authenticate ACS and encrypt communications

The CTA initiates an EAP-start message.  A network device supporting NAC (a NAD, which is functionality supported on a subset of Cisco routers in NAC Phase 1) sends back an EAP-request identity message.  The CTA responds with an EAP-identity response that includes the credentials of the host/user as well as information about the security and configuration management posture of the host, as reported by all of the agents on the host that the CTA is providing a service for.   This information is forwarded from the router to the Cisco Secure Access Control Server (ACS) via RADIUS.  The ACS looks at the parts of the identity it is familiar with (password or certificate, CSA status) and passes additional information on to other back-end servers (e.g. MacAfee, Symantec, Trend Micro, Tivoli) that know how to interpret such information, and waits for a “go, no-go” indication from them, using HCAP.  The ACS then muxes up all of this information and responds back to the router whether to allow the host to access the network, and provides a downloadable ACL (or HTTP re-direct information) for the router to use to regulate on-going traffic to-from the host consistent with it’s authorized policy.  

If the security or software configuration posture of the host does not pass muster, then the downloaded ACL is formed such that a connection is allowed only to the remediation server(s) required to download the patches, AV files, or whatever is required to bring it up to policy.  Once that is achieved, the host will reboot (to enable the new software) and the process will begin again.

In NAC Phase 2, Cisco will support NAC on a subset of their LAN switches.  EAP will then be supported over 802.1x.  The switches will connect non-compliant devices to a quarantine LAN where remediation servers will reside to bring the client up to policy.

There is also a whole phased roadmap for CTA environment support: 3^rd party host software partners (including additional security software such as personal firewalls, and application software such as MS Office), additional policies (like no Kazaa, Grokster, Mozilla, or IM allowed), 3^rd party back-end partners, CTA bundling, API licensing, and no back-end services for non-responsive devices (with CTA) and CTA-less devices.  So, NAC deployment is really in its very earliest stages.  There is a lot more to come. 

All-in-all, NAC is a huge program with-in Cisco because it touches so many things – switches and routers as NADs, ACS as an essential system component, host software support across a broad range of environments, a rapidly growing list of 3^rd party ecosystem partners, and management capabilities out the gazoo to visualize, monitor, configure, troubleshoot, etc., etc. 

But still, NAC only executes access permissions based on the software configuration of the host at the time of network login.  NAC in and of itself doesn’t protect networks from worms and infections that occur in spite of the endpoint security posture, hosts that aren’t or can’t be configured with CTA, or the malicious behavior of credentialed and uninfected users.

It looks like, in the future, Cisco’s approach will be to detect reconnaissance, infected behaviors, malformed data, etc., via a variety of sensors with-in the network, including (I would presume) IDS built into switches and routers. The system will then set ACLs, probably at the ingress switch port, to isolate the host, isolate selected logical ports/applications on the port, filter content from the host, re-route the host (to remediation servers), rate shape specific traffic types, etc.  Cisco calls this set of capability Network Infection Containment (NIC) and defines it as SDN Phase 3.  Cisco hasn’t really specified a target time period for Phase 3 yet.