I was asked to travel to the 2013 InfoSec security conference in Europe this year, and speak about the trends I am seeing in the identity networking game, and possibly speculate on the future of identity in networking as I see it. So I thought to myself: “what a great blog post this could make."
The Phases of Identity Networking (as seen by an overworked identity nut like me):
Phase 1: [Circa late 1990’s] Identity networking stems from the age-old question: “How do I Control Who Gains Access to the Network?” Along comes IEEE 802.1X! 802.1X provides Extensible Authentication Protocol (EAP) over Local Area Network (LAN) capabilities, to allow a client to transmit their identity credential into the network before gaining access.
802.1X[/caption]
- 802.1X Provides the User or Device Credential
- User allowed to Connect to Network
- Enforcement may be VLAN or ACL
802.1X is now providing “WHO” (e.g.: Employee, Contractor, Guest, etc.).
Phase 2: [Circa 2004] “What happens in Vegas, stays in Vegas.. Unless you pick up a Virus.” We ran through a major growth period in the computer security industry due to the spread of destructive malware, which also led us to try and extend the “WHO” that 802.1X provides to include even more information. Knowing that you are a valid employee was not enough, because even valid employees may have picked up a virus somewhere.
Before allowing you to have normal access to our network, we need to examine the device you are using and look for updated patches, Anti-Virus software installations, and so forth.
"But my desktop management team told me that’s what our Anti-Virus Management servers and patching systems like Microsoft’s SMS/SCCM will handle, so we are protected, right?” WRONG.
I lost track of the number of audits I’ve seen companies fail where their Anti-Virus management, or patch system was not working, due to any slew of reasons; usually the reason was some variant of a PUSH mechanism from the server, instead of a PULL mechanism from the client. Somewhere along the line, the server was unsuccessful in pushing the update.
Regardless of the reason why it failed, the fact is: the company failed audit. So they were looking to enforce the update before providing network access. Enter Network Access Control (NAC) also called Network Admission Control.
The idea behind NAC is to ensure patches & Anti-Virus are all up to date, and the system is compliant with the company’s security policy (known as posture assessment) BEFORE allowing them to access the network. If any part of the posture assessment fails, the user/device is put into a Quarantine state (usually a VLAN assignment or special ACL) where the machine is remediated (the items that failed the posture assessment are fixed). After remediation, the user/machine is moved back into a normal full access mode. Image 3 shows this concept from an image I grabbed out of one of the original Cisco Network Admission Control (NAC) Framework slide decks from years long past.
- 802.1X Provides the User or Device Credential
- Resident Agent Typically Provides the Posture Data
- User is Quarantined Until Remediated
- Enforcement may be VLAN or ACL
So now 802.1X provided the “WHO”, while NAC is providing the “WHAT” (posture assessment of patches and installed/running applications, etc...)
Phase 3: [Circa 2007] “What kind of device is that??” Posture assessment (read: traditional NAC) was humming along nicely. We saw very active growth in the NAC market space, and identity networking continued to grow at a nice leisurely pace.
Then something happened that started to change the game a bit. Mobile phones got one very cool addition, Wi-Fi. With the addition of Wi-Fi to smart phones, we started seeing an influx of devices that were trying to join corporate wireless networks, but didn’t support Posture Assessments (NAC). This was really just an interesting uptick in a networking trend, but nothing too pressing at the time. Then along comes one more advancement that changed everything forever: the iPhone (followed by the iPad)!
It is undeniable that the iPhone changed everything for this industry. Now, we had to allow certain executives to access the corporate network with their iPhones/Androids/etc, but not everyone. This allowed us to extend and improve an existing technology – endpoint Profiling.
Originally, endpoint profiling was developed as a tool to aid in 802.1X deployments. The original concept was to help identify devices that could not authenticate with 802.1X; endpoints like printers, badge-readers, camera’s, IP-Phones, and many more. Once these devices were identified, their mac-addresses (hardware address burned into the network interface card) were added to a list of devices allowed to bypass the 802.1X authentication and gain access.
Now with the extensive proliferation of these mobile devices that are Wi-Fi enabled, along with concepts such as Bring Your Own Device (BYOD) and Choose Your Own Device (CYOD), we were advancing endpoint profiling to be used with 802.1X. The ability to tie an authentication policy to the device type became commonplace and paramount.
A common policy could be: Employee’s 802.1X authentication on the corporate wireless network with a workstation whose posture was compliant = Full Access. Same Employee’s 802.1X authentication on the same corporate wireless network with an iPad = Internet Only Access.
- 802.1X Provides the User or Device Credential
- Endpoint Profiling is Used to Determine Device Type
- Workstations are Quarantined Until Remediated (NAC)
- Mobile Devices are Provided Internet-Only Access
- Enforcement may be VLAN or ACL
At this stage we are still looking at “WHAT”, but it’s a different “WHAT”. Instead of security policy compliance (posture), it is looking for device types using endpoint profiling.
One important note: it’s predicted that over 15 billion devices will be network connected by the year 2015. That is only 2 years away from the writing on this blog post!
Phase 4: [Circa 2012] “I don’t do ‘OR’! ‘OR’ makes you choose!” 802.1X is a fantastic technology. It uses Extensible Authentication Protocol (EAP) to provide an identity to an authenticating device. Let’s state that again, but focus on the key word: “It uses EAP to provide AN identity to an authenticating device”. That’s right; EAP is only carrying a single credential per transaction. So an Enterprise that is using Microsoft’s Active Directory to manage their Windows workstations have two options per workstation to authenticate to the network: Machine-Auth *OR* User-Auth.
Why are there two auth options for Windows? Back in the late 1990’s when 802.1X was starting to pick up adoption, Microsoft came to an important realization: If no network connectivity is provided until a user logs into the Windows box, then the connectivity between Active Directory and the workstation will be broken! In a brilliant move, they created a concept of a Machine-State and a User-State for their supplicant (the software ‘driver’ that speaks 802.1X). So, when a user is not logged into a Windows box, the machine itself may be logged into the network using either the machine account and password created when the machine joined AD; or it may even use an Active-Directory issued certificate. Then, once the user types CTRL-ALT-DEL & logs into the workstation, the endpoint will start a new EAP session that will use the User Credentials instead of the machine’s credentials.
Much like Dr. Ken Jeong in the Coke Zero Commercial, we don’t want “OR”, we want “AND”. Immediately, administrators were trying to find ways to tie together the machine authentication and the user authentication, to be part of a single Authorization. This way an organization can be assured that it is a valid corporate asset and a valid user. Cisco created a concept of Machine Access Restrictions (MAR) – which maintained a cache of mac-addresses that passed machine authentication. Then when a user authentication comes into the RADIUS server, it looks at the cache to see if a machine has already authenticated from that mac-address & if so, access would be allowed. There’s more to it than just that, but we are not focusing on MAR – as there are limitations. I want AND. AND means that I don’t want limitations, I want it to work no matter what!
Enter EAP Chaining! EAP Chaining is an enhancement that allows for multiple EAP credentials to be transmitted in a single transaction. Created by Cisco as part of EAP-FASTv2, it was adopted by the IETF for the upcoming Tunnel EAP (TEAP) standard. I could write an entire blog on EAP Chaining (and probably will), but let’s just explain that in a single transaction we are able to combine Machine and User Authentications and authorize based on that combo. The mix can be any combo of certificates or names & passwords, which is a fantastic and long needed enhancement for 802.1X and EAP.
- 802.1X Provides the User AND Device Credential
- May Continue to use NAC/Posture where workstations are Quarantined Until Remediated
- EAP Chaining is not dependent on infrastructure, since EAP does not terminate there, it terminates at the Policy Server.
- Only Cisco AnyConnect and Cisco ISE support EAP Chaining at date of Blog Posting
- Enforcement may be VLAN or ACL
At this stage we are still looking at “WHO” and “WHAT”. We are using 802.1X to provide both, and it can be combined with Profiling and Posture.
Phase 5: [Circa 2013] “Mobile Device Management” Providing Internet-Only access to mobile devices may be a workable policy for some, but certainly not all. These mobile devices are continuing to grow in adoption and proliferation at very exciting rates. As these are becoming more important for conducting business transactions every day, it also becomes important to manage these devices. I find this trend to be truly intriguing because companies like RIM had this down to a Science – no, not science – RIM made managing Blackberry’s an Art Form! It was absolutely beautiful, and still is as a matter of opinion.
However, the BlackBerry mobile devices were not what the end-user wanted. The end-user wants to use whatever endpoint they will be most productive with. If I find my productivity is increased by using an iPhone or an Android device, then by golly – let me use an iPhone or Android device! Enter Mobile Device Management companies such as: AirWatch, ZenPrise (acquired by Citrix), Mobile Iron, Good Technologies, SAP Afaria, and others including Blackberry Enterprise Service 10 which will manage iOS and Android now, too.
While this blog is not focused on MDM, it was necessary to discuss these briefly, because they provide a level of posture capability for mobile devices! Specifically, your policy server may need to have knowledge of an endpoint being managed by an MDM or owned by the company versus one that an employee just purchased off the shelf of his favorite neighborhood electronics store.
With MDM integration to your policy server you are able to establish a new type of posture, looking to see device ownership, if the device has been jail broken/rooted, if the device has encryption enabled, if the pin lock is enabled, etc. This adds even more to our identity decision, and we can provide different levels of access for devices based on these attributes.
- 802.1X Provides the User or Device Credential
- Mobile Devices are profiled as they access the network.
- Policy Server is able to query the MDM, looking for “posture”
- Enforcement may be VLAN or ACL
At this stage we are still looking at “WHAT”, which is being provided by the MDM service.
Phase 6: [~2013] “Location, Location, Location” Another factor that is commonly asked for / looked at. There is the ability to look at the source Network Access Device to determine if it was wired, wireless, or VPN as well as where that device is in the network – or even to integrate with location services within the wireless infrastructure, or what about Geo Location w/ the GPS units that are enabled on all these mobile devices. Now, lets look at physical security controls: badging systems, etc. Should a user be allowed to log into a network if they have not badged into that building? Should they be allowed to login if there is currently a fire-alarm in that building? The limits are endless!
- Using the location of an endpoint as part of the policy decision
- Identity to include location in campus, branch
- Type of Access is Wired, Wireless, or VPN
- Attributes could even include Geo Location
- Physical Security controls could be included as part of the conglomeration of attributes, such as badged in or state of the fire alarm.
- Was the authentication attempted during normal business hours or was it while the location should be closed?
At this stage we are examining “WHERE”, "WHEN" and "HOW" which is beginning to round out our identity conglomerate or “context."
Leading us down a path to a Contextual Identity
As you start to put all these phases together, you realize that an identity is growing way beyond just the username credential – it is leading us down a path of an identity including the: WHO, WHAT, WHERE, WHEN, AND HOW; which I like to call a “Contextual Identity."
That Contextual Identity will be used in-place of the traditional use of a single credential. Now we will gain the ability to construct business relevant policies that take the entire context of the user access into consideration, providing granular levels of access or even bulk access.