CTO Chronicles

New Cliches for Shimmy

The man with the longest domain name ever (compensating for something?) has decided to pick on last week's blog post.  His main point seems to be our "lack" (perhaps he missed my truth meter) of pre-admission compliance checks, but in it, he uses his favorite hammer-nail turn of phrase.  Now, we all have our favorite cliches, and it has to be especially tough for Alan given how prolific his entries are.  So, in the interest of helping out a fellow blogger, I have a few suggestions:

When you're a cat, everything looks like a canary

When you're a dog, everything looks like a hydrant

When you're Ted Stevens, everything looks like an earmark

When you're the Church Lady, everything looks like Satan (this one's my favorite; who wouldn't want to be compared to the Church Lady?)

Now, then, here's my three-point rebuttal to Alan's post:

1.  What part of "you can always get fancier" was unclear?  My post was not at all intended to represent the sum total of admission checks we can perform.  It was simply to advocate that IT and Security staff take the low hanging fruit first, then move up the tree (see how I did that?  A brand new cliche).

2.  Setting up and configuring a NAC solution should not involved rocket science.  Presenting NAC administrators with a laundry list of 1800+ pre-admission checks is, at least to me, not a benefit.  Solving 80% of the problem out of the box, then providing enough flexibility (via additional pre-admission checks, behavioral controls and a web services API that integrates other security tools) strikes me as a better approach.  Granted, StillSecure is more VA focused than we are, but that makes sense, given their product suite.  After all, when you're a VA company, everything looks ... Never mind.

3.  I continue to wait for a post from Alan, or anyone over at StillSecure, on how DHCP based "quarantine" (StillSecure's primary methodology) is so much more secure than ARP based quarantine.  See here for an example of what I mean.  And have I mentioned that if the switch vendors would get off their collective keisters and implement RFC 3576 we could leave this particular argument behind and fight about other things?

In addition to wishing everyone (yes, even Alan) a happy Thanksgiving, I'll leave you with these parting thoughts.

I'm just glad to be here, and hope I can help the ball club

You have to play them one game at a time, and the good Lord willing, things will work out.

Sometimes you win.  Sometimes you lose.  Sometimes it rains.

Think about that for a while.

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.

The Devil Inside

Last month brought a data leak survey from Compuware, sampling 1,112 IT professionals.  The report is covered by ars technica and has some interesting data points.  I agree with the ars technica article that the "79% of organizations experienced a data leak" is not really a fair headline, though admittedly it's a tempting one for organizations like Mirage.  The two really interesting data elements out of the report are that (a) 56% of IT organizations surveyed are nervous (at best) about their ability to detect a data leak; and (b) 75% of respondents identified "Negligent Insiders" as the most likely vector for a data leak.

The bottom line seems to be that the need for governing what employees can access, as well as what employees do with the information once they have it, is not going away.  Call it Network Access Control; call it Controlling Network Access; call it a lunar landing if you want.  It's not going away anytime soon.

Managed Resnet & NAC

I've written about the link between NAC and MSP before, and the success of NAC in the higher education market is certainly no secret.  More and more of our higher ed customers have been talking lately about outsourcing their residential networks.  This seems to make sense on a number of levels, provided that the schools can work out a structure for the support as well as engineering and maintenance of the residential network.  Certainly, it makes sense to have NAC as an integral part of the managed resnet service, but it also has the potential to go much farther than that, including services like voice and on-demand video in addition to data.  Network Vigilance, a company based in San Diego, CA, provides managed NAC services today.  Another company based here in Austin, Apogee has managed residential services as their primary business function and seems to be making a go of it (except for the domain name, seriously..).

Despite the macro economic conditions (and perhaps because of them), I think this has real growth potential.  Having what amounts to a specialized MSP provided authenticated, well-governed network access to residential halls, freeing on-campus network staff to focus more on backbone services, and providing school administrators with a predictable cost structure that can be baked into the cost of the dorm room seems to make sense for everyone.  Just don't forget the "authenticated, well-governed" part.