To the surprise of no one who read the comments to my earlier post, it is now official that Nortel was the purchaser of Identity Engines’ IP assets. They updated the IDE homepage with a short message and contact info for more information. Given that they are inviting IDE customers to contact Nortel’s account teams, I’m hopeful that they’ll be providing some ongoing support options to existing IDE customers. Have any IDE customers contacted Nortel yet? What was the result?
Archive for the ‘Network Authentication’ Category
Just a quick 802.1X update that some folks may have missed. There is a new IOS release for the 6500: 12.2.33 SXI (gotta love our naming scheme). It provides some very nice improvements for wired 802.1X rollouts. Network World wrote up the basics and even provides some config examples; take a look. When this hits the other Cisco switch platforms I’ll be sure to provide another update.
A recent Network World article highlights a lengthy debate between Joel Snyder and Richard Stiennon on the merits of NAC. It is a good read overall and ANA even makes a brief appearance thanks to a mention by Joel (Thanks Joel!). Here’s the relevant exchange:
Joel_Snyder: I’ll jump in here too. Sean Convery just wrote a paper on NAC. (He doesn’t want to call it NAC, he calls it Authenticated Network Architecture — ANA). Anyway, the point he makes is that you don’t need to have super fine-grained ACLs to get a huge reduction in risk.
Richard_Stiennon: *My* point would be that you NEED to get to fine-grained access control to secure your enterprise.
Joel_Snyder: Fine-grained is a spectrum. Aren’t you the guy who just advocated VLANs? I’m saying that if you have coarse control, even go/no-go, that’s a reduction in risk.
Richard_Stiennon: We agree.
Joel brings out one of the central novel points of the paper. Here’s the relevant text (from section 7.3, page 14):
Organization architects that appreciate the capabilities that ANA provides often adopt a design that has many user roles. Larger organizations might have hundreds or thousands of groups in their user directory, and the natural conclusion is to define a network-access profile for each group. This approach, however, is very problematic, primarily because of the complexity involved in managing the large number of roles. In addition, the goal of ANA is not to supplant the application security infrastructure you have already built but rather to augment it. Instead of defining hundreds of roles for the network, a smaller number—likely much fewer than a dozen—can provide a huge boost in the sophistication of your network infrastructure, while remaining completely manageable.
If you think of your network now as essentially a network with one role (full access), then the rationale for adding more roles is to define the high-level separation of rights that provides the most significant security improvement at the most operationally insignificant cost. The roles most organizations should consider follow, beginning with the roles that should be created first. It is not important to deploy all the roles at once. Each additional role adds another layer of delineation to the existing definitions already deployed.
Standard access – This role is the default role that every user and device is currently a part of, whether through explicit authentication or implicit network connectivity. As you roll out ANA, you will gradually assign each user to a more specific role, with the goal of minimizing the number of users and devices that are a part of the standard access role.
Guest access – This role is the most significant role you can add, because it enables any sponsored visitor to connect to your network and gain authenticated access to the Internet at large. By providing easy-to-use guest access, you minimize occurrences of users trying to connect to your private internal network where they might have full access. Most individuals are just trying to get their work done, and if you give them an easy way to get to the Internet (and the network of their home location) everyone is better off. Section 11 details the specific design considerations and policy trade-offs of guest access.
Contractor access – Adding this role means that you no longer have to grant every contractor full access to your network. You can send contractors through a contractor VPN portal where they have access only to the specific systems that they need to fulfill their contract. This setup gives your organization the option to treat contractors more like guests and less like employees. You can grant specific access for only the defined duration of the contract. This solution also facilitates remote vendor troubleshooting or technical support in which an external support engineer needs, for example, 30 minutes of access to one specific system on your network.
Privileged access – When you introduce the privileged-access role, you curtail the rights of the standard-access role so that it no longer offers access to areas of the network deemed extremely sensitive, such as HR, finance, and R&D areas. Only the users who require access to such resources are placed in the privileged-access role.
In summary, with only four roles, you can significantly reduce unauthorized access to sensitive data. In most organizations, approximately 50% of the user base is part of the standard-access role, 10% has guest access, 20% has contractor access, and 20% has privileged access. With these four roles in place, sensitive systems remain exposed to a mere 20% of the user community.
The thing that often gets lost in these sorts of debates is that the network and the application security are cooperating to reduce risk. The network reduces the size of the funnel of potential attackers and attacks but the applications still provide their own–application specific–fine-grained access control. This isn’t an all or nothing proposition, defense-in-depth still applies.
I’m thrilled to announce that my company just launched the Authenticated Network Architecture (ANA). ANA is a vendor-neutral framework that leverages industry standards for the design of an identity-centric security system. ANA was conceived as the next logical step from my earlier work with the Cisco SAFE Blueprint and builds on my textbook “Network Security Architectures“. The ANA white paper goes into significant detail and breaks out deployment in five phases, each of which is incrementally beneficial and none of which requires a forklift upgrade (or any particular network vendor’s gear). I recommend you check out the overview first but feel free to download the complete white paper.
As anyone who’s familiar with my approach to white papers will know, the document does not pitch my company’s products at all, in fact they are not even mentioned. Also, one of the nice things about working at a small company is I can revise the document and publish an update fairly easily. I’d love feedback from the community on information you’d like to see added, any errors you found, or just general comments. Here’s the executive summary:
Network security has been evolving since its inception, sometimes slowly, sometimes in larger increments. As technology has shifted, best practices have slowly matured. What was a good idea two years ago is still likely a good idea today, with minor variations based on the evolving threats and business requirements. However, we are currently at an inï¬‚ection point in the use of network-based security controls. Whereas previous designs focused almost exclusively on static policies, ï¬lter rules, and enforcement controls, a newer approach has emerged that promises much more dynamic options to address the increased mobility and diversity of todayâ€™s network users.
This approach, called the Authenticated Network Architecture (ANA), is based on the notion of authentication of all users on a network and the association of each user with a particular set of network entitlements. For example, guests are granted access only to the Internet, contractors only to discrete network resources, employees only to the broader network as a whole, and privileged employees only to isolated enclaves of highly secured resources. Most of the capabilities described in the architecture have been available in shipping network infrastructure for many years. However, while the architecture itself does not mandate much in the way of equipment migration, it does require organizations to think differently with regard to their overall security framework. The cooperation of security and network architects with their more operationally inclined counterparts in IT is critical to ensure that the designs contained in this document evolve with the growing capabilities of your infrastructure.
This document outlines the ANA approach as a whole and describes how to migrate existing enterprise security designs to this more dynamic approach. In particular, it discusses the best practices that are emerging in ANA as well as the speciï¬c business requirements that influence deployment decisions.
Zeus Kerravala at Yankee has a nice column at Network World on the opportunity around network, identity, and policy integration. He writes:
Ultimately, getting policy to reside in a central location is the key. Rather than many disparate systems with policy information, enterprises need to have a single policy store, intimately tied to the identity store, where the network infrastructure can apply and enforce policy on all traffic. Having policy management in the core-with control at the edge-is the only scalable model for pulling together network, identity, and policy.
It is great to see more folks in the industry coalescing around this idea. The only thing I might take issue with is his goal of a single policy store. While that might be the best-case design ideal, I think the real world will require a much more collaborative approach. This is part of the reason my company writes all its policies using XACML. We’re expecting the need to share policy over time.
As frequent readers of this blog will no doubt expect, I was completely unsurprised by the shutdown of Lockdown Networks last week. Following the fire-sale of Caymas Systems and the announced restructuring of Vernier Networks as Autonomic Networks, it is natural that more NAC vendors would fall. Coincidentally, I was on the phone with a customer looking to swap out their Lockdown products for something more robust just before I heard the news.
For some analysis, take a look at the blog posts from Jon Oltsik and Eric Ogren, two former-colleagues of one another in the analyst community. The two take very different views with Jon pointing to Lockdown’s retooling of their product as a reason for their failure (but maintaining that the NAC market is healthy) while Eric blames the NAC market in general and the difficulty competing with Cisco and Microsoft.
I think Jon has things more on the money. The classic device-centric NAC market is crowded and with so many players it is awfully hard to reinvent yourself and still stay competitive. Part of me is surprised it has taken so long for another vendor to fail. After all, Cisco announced its intent to purchase Perfigo back in October of 2004. Perfigo’s product became Cisco Clean Access (the giant of the fledgling device NAC market). Lockdown’s technology seems almost identical to Perfigo’s but the market has moved on since then.
When I talk to customers I continue to hear the same themes as I did back in 2005 when I joined Identity Engines:
- Organizations want to use the network enforcement gear they already have
- No one wants to deploy a new inline device in their existing network (support and cost issues are cited)
- User identity is far more important than device health because it allows for far more fine-grained access decisions
- Guests and contractors is the area of greatest security concern
- Proprietary clients are a no-no
802.1X is the natural antidote to these desires and now that the deployments are getting larger and the technical objections are being removed through better solutions, I think we’ll be hearing a lot more about 802.1X this year. In fact, tying back to the Lockdown news you can see evidence of this in the market as a whole. Lockdown’s non-Cisco competitors are now talking a lot more about 802.1X and trying to bolt-on more of this type of functionality into their existing non-802.1X offerings. For a sense of this trend, look at the acquisitions in this space since Perfigo. We have Juniper acquiring Funk Software in November of 2005 and Cisco acquiring Meetinghouse Data Communications in July of 2006. The main technology asset of both companies was, you guessed it, 802.1X capabilities.
If you would have asked me two years ago if my company’s products would be broadly deployed by large universities, hospitals, and government I would have said yes. As expected, these types of customers have deployed our products and are starting to get quite sophisticated in their use of authenticated networks. However, if you would have suggested that community colleges would have found our offering compelling I might have though you a bit crazy. However, much to my surprise, community colleges are deploying Identity Engines’ products (and authenticated networks in general) regularly.
If you think about it for just a moment, it makes perfect sense. Community colleges have among the highest user turnover rates of any type of organization; thousands of users are often coming and going each semester. The faculty at these colleges is often a mix of full-time staff and part-time instructors with day jobs in the marketplace. Additionally, most community colleges have multiple campuses through a geographic area and need to coordinate access policies among them. Guest access is another key requirement as community colleges engage with the residents of their host city in a significant way.
Kevin Jones of Metropolitan Community College (MCC) and I recently gave a talk at the League of Innovations CIT 2007 conference. This is a conference focused on community colleges and their unique IT needs. We discussed MCC’s deployment of authenticated networks and delivered the presentation to a standing-room only crowd. So much for convention wisdom…
I recently had a short piece published in the Fall issue of the ACUTA Journal. It doesn’t look like they make the journal available to non-members but I got permission to share just the portion that I wrote. It is a high-level summary of role-based access control (RBAC) and how it relates to some of the emerging regulatory requirements for higher-education networks. Here’s the opening paragraph:
As recently as 10 years ago, we had it easy: Users stayed put at desktop machines, IP addresses never changed, and IT wasn’t on any lawmaker’s agenda. Solutions focused on the threats of the time, which, compared with today, weren’t many. But now technologies and threats are changing so fast that it’s hard to keep up. We can no longer count on a fixed IP address or even on a single device for a given user. We all want network access from the increasingly large pool of devices and access methods, and this has dramatically complicated the security task.
I’m pleased to relay the news that a development version of XSupplicant (an open source 802.1X supplicant) is now available for download. The OpenSEA alliance formed a while back and this is some of the initial results of the group (well really the talented developers of the Open1X project within OpenSEA). While this is most definitely a development release and should not be used in production, the developers are actively seeking feedback. So if you have the time and interest, they’d love any comments you may have.
John Roese, Nortel’s CTO, has a nice post on why he thinks we are almost at the point where enterprise network infrastructure can go wireless only. He’s careful not to say we’re exactly there now, but certainly sees Nortel as a leader in this space. He writes:
It is our position that, after a decade of evolution, both Wi-Fi and broadband wireless (4G) technologies are getting close enough to the expectations of the customer that we are becoming able to build the Unwired Enterprise from an access perspective.
I’m seeing this as well, though I think wired will be around for a long time to come. At Identity Engines, we have a prominent enterprise customer that finally decided to deploy wired at a new facility only because the VoIP quality wasn’t yet there for wireless. Furthermore, our experience in the education market shows that wireless only is already here in principle for many university students and staff; these university users frequently never connect to the wired network, even in their home location. The next several years will be interesting indeed, Roese thinks they might even shift the vendor landscape:
This is great for mobility and productivity from a customer view, but it is also an inflection point that can force a re-thinking of the enterprise LAN architecture. That is something that happens very rarely but, when it does, the market can be remade and the vendor landscape can be transformed.
I tend to agree but I think it might cause more of a trend towards commodity, standards-based, network infrastructure coupled closely with robust identity management for the network. Then again, I could be a bit biased in this regard…