The Identity Management Norm and the Challenge We Face.

Network Access of Old

I remember back in the days when I worked at the phone company.  We had a security desk right inside the door and at the counter was a desktop that had the company directory on it.  What didn’t make a lot of sense to me was that the Ethernet port was on the front of the wall, not behind the counter.  Anyone could walk into the office and unplug the corporate directory PC and plug their own in.  DHCP would give them an address and they were on the LAN.  Sad thing is that people did.  I would come walking in from lunch and often see some random guy copping a squat on the floor with his laptop connected.  Back they we really didn’t have a clear way of preventing access to the network.

What We Used to Do

Prior to 802.1X we did have a few solutions but they had their limitations.  One way we could control things was by using a VLAN Membership Policy Server (VMPS).  With a VMPS the MAC address would dictate which VLAN you were assigned to.  If you were not listed in our database you would not get a VLAN assignment on the LAN.  The drawback here was that you had to manage the MAC database.  If an employee had a NIC failure and the NIC were replaced, we would have to remember to update the database.  This happened a lot back when the laptops had a PCMCIA NIC with the flimsy dongle.

Another way we would control network access was with Port Security.  This of course only worked if your switch supported the feature.  If it did you had a few ways to handle business.  You could enter the MAC that should be connected to each port and then limit the number of MAC addresses to 1.  This didn’t scale well either.  We could sticky learn the MAC which helped, but again, scalability issues.  So even though we had a few solutions, nothing was really a great fit.  Fast forward to today and 802.1X is the clear fit.  While we had 802.1X back then, or at least we started to see it, client support was limited.

Network Access Today

Today we still don’t have all the answers.  We primarily use 802.1X and EAP to authenticate and authorize a user on a switch port or on a wireless SSID.  This method of controlling access works well because we have much better support for EAP in our native supplicants today.  For some of the more advanced EAP methods we have clients like Cisco Anyconnect.  Using 802.1X and an external authentication server scales better than the previous solutions discussed in this article.  Along with the scalability comes a great deal of context data that’s useful in determining who is connecting, where they are connecting, how they are connecting and so on.  From a policy perspective this is fantastic.  We have a level of visibility today that we didn’t have back in my early days.  Still, the solution isn’t perfect and there are still some things we need to address, like all that log data.

Where Do the Logs Go?

Your identity management solution is but one source of log information that you’re receiving.  You have the logs from the switches, APs, and Firewalls where your VPN is terminating.  There’s a handful of logging solutions out there that can handle the volume we see on most networks today.  The key to consuming log data is not just being able to store it and handle the shear amount of data being received, but its also being able to use the data in a meaningful way.  So what are some of the things you’d need to identify?  A good solution would help identify users on the network that are doing things that aren’t exactly normal.  When you consider the prevalence of  Bontnets and DDoS attacks it would be advantageous to implement a solution that would identify if your assets are participating in these types of attacks.

The attacks here are just a few examples.  There are many more.  But I’ll leave this post with two questions:

1. What are you implementing as your Identity Management Solution?
2. How are you using the log data from that solution and other network devices to mitigate attacks and minimize unauthorized activity on your network?