Pre-Admission NAC

I thought this might be a good time to revisit the often controversial topic of pre-admission NAC policy.  While every enviornment is different, I think there are two basic goals any pre-admission policy, including initial installations, should look to accomplish.

1.  Course-grained classification at entry

We tend to think about network devices in three broad classifications:  Managed (general purpose computing devices owned by the organization), Unmanaged (general purpose computing devices not owned by the organization), and Unmanageable (special-purpose computing devices).  Additional, finer-grained classifications exist to be sure; however, the minimal goal should be to put every entering device into one of these three broad buckets. 

MAC address lists seem to be the most common way to do this, though lists of MAC addresses are cumbersome, especially at scale.  Technologies such as Active Directory integration (watching the machine get a Kerberos ticket, for example), 802.1x and clientless OS detection can help fill out this model in a way that is less cumbersome to configure and maintain over time.

The end result should be broad classes of endpoint descriptors that help inform what assessment information is gathered next and what the ultimate entry success criteria is.  Think of it as a (hopefully better managed) TSA line.  Some endpoints get the blue carpet; some get the stall for additional screening; and others come in the "normal" flow.

2.  Eliminate on-going risks first

Much of the debate over pre-admission assessment has been around what you check (OS patch, FW status, A/V currency, etc.), and whether you should restrict users based on the data, rather than why you want to check it.  The primary focus, at least at initial deployment, should be the elimination of systemic, on-going risks.  Many policy statement examples exist; here are a few:

• OS Update Agent (WUA, SMS, whatever) must be active and configured properly
• Antivirus Agent must have valid license and show successful scan within last 30 days
• Desktop computers must not be mail servers
• No general purpose computing devices in Voice VLANs

You get the idea.  All of these are examples of onging, systemic risks that extend beyond a device's specific session on the network.  Fix those first.

You can always get fancier, as you move the deployment along, but these two steps should be your first two.

Comments

[Gr33n Data]

It's really good for NAC solution to be able to scan unmanageably devices and detect what they really are and what services they are allowed to and what kind of traffic they are not supposed to send.
But let me add something here. Don't you think that an emerging standard such as IF-MAP can solve such issue? In such, Security Scanners will do their periodic scans and profile the various devices in the network and send such information in a centralized database (Meta-Data Access Point), and NAC (Policy Decision Points) can easily access such data and customize their policies based on the profiling data delivered by the IF-MAP. Also security devices in the network can make use of such data to deliver custom policies based on the devices profile, so a printer will only be allowed to send and receive traffic related to printing services and IP-Phones will only be allowed to send VoIP traffic, etc.

[Grant Hartline]

Yeah; I intentionally focused on the "what" and left out the "how." IF-MAP has a great deal of promise, but in my view is ultimately only as useful as the presence of a standards-based framework for enforcing the policy decision that's made (multiple rants at http://www.mirageblog.com/cto/2008/04/ticking-away-th.html and http://www.mirageblog.com/cto/2008/07/the-arp-lowdown.html.)