Re: Revisiting wireless NAC

[Jeff Kell <jeff-kell () UTC EDU>]

Touching on a few points in this thread... responses inline

On 1/4/2013 2:43 PM, David Curry wrote:
> Back when we first implemented NAC (this is the second product),
> requiring antivirus software was a major factor in keeping malware out
> of our network. But as we all know, it's not that simple anymore--just
> having antivirus isn't enough to keep the malware out

We also started with a "heavy handed, gatekeeper" NAC deployment.  The
gatekeeper aspect is what results in the most negative user reaction,
and it just gets worse when you periodically re-evaluate and force
remediation/quarantine on policy violations.  Over the years we have
downplayed the remediation aspect, but we do insist on the initial
registration and agent.  This firmly associates the user with the
host/device in question, and the agent registers all of the network
interfaces (wired/wireless/etc). 

> Why don't we get rid of the NAC all together? And instead, we'll just
> let any device connect to the network (provided the user
> authenticates), and let it do whatever it wants, right up until the
> point at which it misbehaves.

Yes, and the "misbehavior" is typically identified only by IP address
(by your IDS/IPS/firewall/SIEM/etc).  Now you need to associate that
back to the user.  If you now quarantine the device, you have to insure
that you quarantine the WHOLE device (wired and wireless connections). 

> Instead of running the NAC system, we'll run some kind
> of intrusion detection system that's looking for malicious traffic. If
> it sees some, it will block the traffic from that device, and move the
> device into a "quarantine" or "remediation" VLAN where the user can be
> informed

This is essentially what we are doing, although there is not that much
"automated" quarantine action directly from the findings.  We evaluate
the IDS/IPS/etc information and have a manual process to perform the
quarantine action, and it also has a side database to track the reasons
(and device/user history).  It could be scripted to a greater degree of
automation for "highly reliable" indications of compromise, but we're
not there yet.  The Helpdesks (campus and student/resnet) have Senior
Techs that have access to clear the quarantine status after they are
addressed.

We would like some sort of "self-service, 3-strike" self-remediation
available, but again, we're not there yet.  If I had more programming
staff and hours available I'd love to address that, but we're a skeleton
crew with more than enough irons on the fire already.

> So finally, my question: Has anybody implemented something like this?
> If so, would you be willing to share how you did it?

It's based on Bradford, and works across our wired (Cisco, Procurve,
Brocade) and wireless (Aruba) networks, and we cover both Resnet and
campus.  We have been running with "remediation" disabled for the last
few years, but employ their "quarantine" (dead-end) for the cases such
as above.  We also tweaked the quarantine vlan to allow continued access
to our web site, helpdesk, email, so as not to completely cutoff the
victim user.

The "quarantine" however trumps everything else... you can quarantine an
unregistered MAC address... regardless of where they connect.  It's not
dependent upon registration or having an installed agent to handle the
magic. 

On 1/4/2013 4:04 PM, Mark Monroe wrote:
> What is the best way people have found to do this without letting
> ipads or tablets or personal laptops getting on that wireless network?

We allow pretty flexible BYOD at this point, and tweaked the NAC
registration to support the wider variety of devices.  Most anything
that has a browser can be registered quickly, and we don't push any
agents to wireless devices.  We just authenticate and register the
device to the user. 

> Institution owned devices such as laptops or PCs are able to get on
> the same as your wired clients (eg. Internal Network)
 
We do role-based security that is assigned by device (initially
inherited from the user, but devices can be individually changed). 
Phones/PDAs/etc get their own default role... but currently we don't
really have any restrictions different from default campus network
access.  The role-based security translates to a vlan on the wired
network, or a role at the Aruba controller.

On 1/5/2013 1:31 PM, John Kaftan wrote:
> I have been thinking about the same thing.  For us registration takes
> 10 + min the first time because they have to register, get scanned,
> load the agent, get scanned again and then go through our network use
> agreement etc.  It is very heavy on the front end, i.e. guilty until
> proven innocent.  I'd rather let them on and then just spank them if
> they are doing something bad.  

There is the initial "pain" here as well, but we have minimized much of
it (the somewhat kludgy captive registration portal) by pushing new
devices into our "setup" wireless SSID.  This leverages XpressConnect to
configure the device for our wireless (wpa2/enterprise), and as a bonus
will install the NAC agent if it isn't already present.  This
essentially bypasses the registration portal, the agent pops up for
authentication credentials, does a scan, and registers the device.

> The other thing we are missing is that we are not catching other
> questionable behavior such as folks trying to hack our network.  With
> this system we could quarantine someone if they did a Netscan or hit
> the admin account on our DCs or anything that we don't like.  It would
> be amazingly powerful and secure and cool. 

As noted above, the "quarantine" trumps everything.  If we can get a MAC
address, we can quarantine it.  Our NAC tracks MAC/IP/switchport
connections for even unregistered (rogue) devices so this is fairly easy
to do.

Jeff