Sean Convery

Jon Oltsik on identity-based networking. As usual, he gets it right. No cringing from the long-time Cisco folks on the DEN reference later in the article. DEN was the right idea, just introduced way too early to survive.

Network access control (NAC) has certainly had a boisterous lifetime.

Cisco Systems first coined this term in 2005 when introducing an initiative to ensure that only “healthy” endpoints could access the network. In the intervening years, the NAC concept gained popularity, drove tremendous VC investment, and most recently came crashing down in a micro boom-to-bust cycle.

So what’s the future for NAC? Out of the ashes, NAC is slowly changing and moving in the right direction toward identity-based networking.

Technorati Tags: NAC, security

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.

Technorati Tags: NAC, security

A new research brief from Lawrence Orans and John Pescatore at Gartner claims 802.1X adoption is increasing:

A recent Gartner survey indicates that 50% of enterprises plan to implement 802.1X in their wired networks by 2011. Gartner believes that momentum will increase strongly, and that actual enterprise adoption will reach 70% by 2011.

I don’t have permission to share the document but if you are a Gartner client, be sure to check it out. My company is seeing a similar rise in interest as regular readers of this blog already know. The ANA framework represents a good starting point for organizations trying to plan a deployment.

Technorati Tags: 802.1X

This is just a quick test to try out the Wordpress application for iPhone. It seems to work pretty well.

UPDATE: Testing editing a post. The tags I selected didn’t show up, I wonder if there is a conflict with one of my add-ons.

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 inflection point in the use of network-based security controls. Whereas previous designs focused almost exclusively on static policies, filter 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 specific business requirements that influence deployment decisions.

Technorati Tags: 802.1X, identity, security

So I managed to resist the urge to buy the 3G iPhone but I was happy to try out the new 2.0 firmware, primarily for the Exchange support and of course, 802.1X. I was curious to see how many options the UI would expose to the user to configure supplicant settings. What EAP types would be supported? Would it care about inner and outer tunnel identity? The answer on the options front, in typical Apple style, is zero. That’s it. No options at all. It just works. Now how it works and how efficient it operates is an open question. I haven’t managed to break out a sniffer yet to see what it tries to do. I just tried a simple test, connecting to my 802.1X network at the office. We use PEAP/MSCHAPv2 against our Ignition Server going to an AD back-end. Previously I had to connect my iPhone to the guest network and use MAC authentication bypass to get basic Internet connectivity; not particularly secure or easy to use. I had to fire up the browser each time to get the session with the captive portal which wasn’t hard but was an extra step I’d rather avoid. Here’s what I did today:

1. Went into settings, WiFi, and chose the SSID of our WPA2 Enterprise deployment
2. I hunted around for options related to 802.1X and found none. Instead, all I was asked for is a username and a password.
3. I entered that information and clicked join and waited.
4. I waited
5. I waited some more…
6. Eventually I hit cancel, not sure what had happened
7. I then connected again, reentered my password, and was immediately taken to a certificate screen. It presented me with our server-side certificate, let me examine it if I wanted to, and then prompted me to accept it.
8. I clicked accept and then was on the network.

I’m eager to see what sort of experiences others are having with the 2.0 firmware and 802.1X. On the one hand, I’m incredibly excited that (glitch in the middle aside) I got on without needing to know anything about the nuances of 802.1X supplicant configuration. On the other hand I wonder if the lack of options will render certain types of 802.1X deployments non-functional.

Update: 7/11/08 - 8:38 PM

Wi-Fi Networking News has a post about Apple’s Enterprise phone management application that builds 802.1X packages for iPhone. It looks like Apple stuck all the options there for corporate IT managers looking to have tighter control over the 802.1X configs. From the post:

The utility serves two purposes: creating configuration profiles, including for multiple Wi-Fi networks and VPN connections; and allowing iPhones in an enterprise to run internally developed iPhone software. The Wi-Fi profiles allow you to create WEP or WPA/WPA2 802.1X configurations, and include support for choosing allowed EAP messaging types, configuring authentication elements associated with a given EAP type, and adding server certificates and names for better authentication control.

Once created, these profiles can be distributed throughout a company via email or as a direct download to the iPhone via an intranet Web server. Apple chose not to encrypt them, which means that certain information that’s not secured—such as the shared secret for certain VPN connections—could be disclosed to someone who had access to the profile or could download it off the local network.

Technorati Tags: 802.1X

Apologies for the long delay since the last post, things have been very busy at my company. One of the reasons is we’re seeing huge interest in 802.1X among large enterprises. Interestingly enough, much of that interest includes wired 802.1X, not just wireless. We’re having conversations with somewhat conservative companies about 50-100K node wired 802.1X rollouts. This made me curious if we’ve reached some sort of an inflection point around 802.1X adoption. If you have a moment, can you please take the time to reply to this post with your own organization’s wired 802.1X plans? I won’t make this formal, feel free to write as much or as little as you’d like. The things I’m curious about are:

When do you plan to roll-out wired 802.1X?

How many endpoints will that include?

What is the main reason for wired 802.1X deployment?

What has held you back from deploying thus far?

Technorati Tags: 802.1X

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.

Technorati Tags: identity, policy, security

I received a reader email asking if IPv6 is going to change the existing approach to security. He writes:

Do you believe that the transition to IPv6 will change the existing security architectures? I have heard from other professional architects, that there will be a transition from perimeter security to host-based security.

While the paper Darrin Miller and I wrote is the best place for a complete answer to that question, I can provide a quick summary and some clarification. Here’s the section on maintaining host and application security from the bottom of page 23:

Although timely patching and host lockdown are critical elements in IPv4, they are even more critical during the early stages of IPv6 because many host protections (firewalls, IDSs, and so on) do not yet broadly support IPv6. Additionally, it is highly likely (though testing is necessary; refer to Appendix A) that the initial introduction of IPv6 into networks will result in some hosts not being properly secured. It is necessary to focus on maintaining host security to ensure that hosts that are compromised will not become stepping stones to compromise other end hosts.

There’s also some information in my book on IPv6. It starts on page 668, which is available on books.google.com.

I actually think the move toward identity-based controls (whether IPv6 or IPv4) will have more of an impact on security architecture than the transition to IPv6 will. The network will remain important as a security control–as will the endpoint–but the shift will be towards more dynamic authorizations based on the the identity of the individual. IPv6 leads to subtle changes in the security architecture and I agree that endpoint controls will increase in importance; I don’t think that network controls will go away though. Security has always been about defense-in-depth and relying only on the host for security puts all your security eggs in one basket.

Technorati Tags: IPv6, security

Continuing the 802.1X conversation, Network World recently put out test results for 10G access switches and included a whole section on 802.1X functionality. The article does a pretty good job running through many common 802.1X scenarios and highlights the breadth of functionality most modern switches have. While I’m not sure 10G to the desktop is necessary for all but the most demanding environments, most of the 802.1X functionality described here is available on much lower speed (and more affordable) switches from the same manufacturers. Wired 802.1X has seen quite a surge of interest of late as this article corroborates.

Technorati Tags: 802.1X