Sean Convery

Apologies for the sensationalist title, I couldn’t help myself. I’m writing this blog post using voice recognition software as my left arm is broken. I broke it snowboarding in a half-pipe at Squaw Valley this past weekend. Given my day job, there was only one bone in my arm that I could have possibly broken–that’s right, my radius. Feel free to insert your own joke about the robustness, scalability, and reliability of radius. I, for one, have a new-found respect for the importance your radius plays in daily life.

One of the more exciting aspects of authenticated networks is that once you do it, role-based access control becomes possible. Today–as I’ve said before–authentication for wireless, VPN, and dial-up connections has the principle goal of proving that you should be treated like you were in the building. Wired access typically has no authentication. However, if you authenticate your wired access as well, now every access method is authenticated and the game changes. With the user’s identity validated at every point of access, now we can ask what the user should be allowed to do.

At this point vendors and customers can get overly excited and start talking about dozens of roles based on the different areas of the organization. The problem is many larger organizations have no idea what specific authorizations each role needs. Instead of jumping to the end game, organizations should instead look to a smaller number of roles. A good place to start is simply to differentiate between a guest, a contractor, and a permanent user. Guests typically need access only to the Internet. Contractor’s needs vary widely but generally need access to a subset of internal resources. Locking down contractors will still require some homework for a network IT staff but it is a far more tractable problem than figuring out all employee entitlements. Lastly the permanent user role gets access to everything, as normal.

From these meager beginnings, you can begin to extend your role-based access control. The next logical step for many organizations is a “privileged” role which could be granted to finance, HR, and executive staff which grants access to the servers which house very sensitive data. It is important to remember that even with just three roles though, you’ve significantly extended the functionality the network provides over what it did before authenticated networks.

Technorati Tags: 802.1X, NAC

It is always interesting to see the entire security vendor community come together and parade their wares at RSA each year. If I put myself in the role of a potential customer, this week saw a dizzying array of vendors, many of whom were chasing the same industry buzzwords. The buzzwords of this conference, just based on my own observations, were:

• NAC - NAC continues to be a term lacking a comprehensive and agreed-upon definition. As a result, many vendors were claiming NAC support–often with a specific spin based on the capabilities of their company.
• Data Leakage - Companies attempting to protect data from being inadvertently disclosed were on the rise. It seems nearly impossible to prevent a dedicated adversary from disclosing data she has access to, but simple tagging mechanisms to prevent the accidental “reply-to-all” may be useful.
• Compliance - The Infosec equivalent of a trump card when it comes to purchasing decisions, it seemed almost every vendor touted help with regulatory compliance as a feature of their products.
• Policy - Another overused word (without qualifiers) many companies touted policy features.

I suppose this list of buzzwords means a single new startup, focused on all four areas, could probably get a nice batch of seed money from an unsuspecting venture capitalist. I can imagine the pitch now… “Our intuitive UI lets you craft complex policies to define data leakage protections correlated with the NAC status of an endpoint, all with rich ties to compliance reporting for export to an auditor.” I’m sure Vijay, the world’s most desperate venture capitalist, would jump on board.

Technorati Tags: RSA Conference

Just a quick note to remind folks that next week is the RSA Conference in San Francisco. I’ll be up in the city much of the week and would love to chat with anyone who reads this blog. My company is in booth 430 and I’ll be around there much of the time. If you’d like to chat, drop me a line or swing by the booth.

On another note, sorry about the lack of posts of late. I was working against a publishing deadline which I’ve now met. I’m sure RSA will provide plenty of fodder for future posts. Last year’s RSA was all about NAC, this year it will be interesting to see what the buzz-leader is.

Technorati Tags: RSA Conference

Though I’ve been too busy at work to read through this, the first draft of requirements for the IETF’s NAC is now out. It was written by a small subset of the working group and is just starting to get comments. If you are interested in checking out how the requirements are being presented, take a look.

Technorati Tags: NAC, NEA

Happy New Year everyone! I hope that folks had a great holiday. I thought I’d start off 2007 with a bit of an off-topic post.

Back in 2004 Darrin Miller and I did some work looking into IPv6 security. The major result was a paper describing the various security considerations in IPv6, setting aside IPsec. At the time, the majority of the research we saw was looking at IPsec as the principle means of securing IPv6. Since IPsec support is a “standard” feature of IPv6, this was a reasonable assumption. As it turns out, for various reasons outlined in the paper, this wasn’t such a good idea. The paper was well received and even found its way into some US-CERT recommendations, and was largely reused as chapter nine of Deploying IPv6 Networks.

Fast-forward almost three years from then and some things have changed and many others haven’t. The IETF v6ops working group is still churning out some new docs on the subject which is great. However, just like in 2004, the market seems to be ignoring IPv6. Not even a federal mandate to deploy v6 in the government by 2008 is enough to get things going. GCN recently reported as much, highlighting agency concern that security vendors aren’t migrating their products to IPv6 quick enough.

I’ve not done a lot of poking around in IPv6 security lately. In preparing for this blog post I went through and updated my IPv6 security links page to tag any additional dead links and add a few new ones. The fact that this links page–largely untouched since 2004–returns in the top five results of a google search for “IPv6 security” says more about the attention paid to the subject than a lengthly blog post ever could have. The top result is a presentation (from a former colleague at Cisco) that Darrin and I expanded on in our work. Eric did a great job with that presentation but given the governement’s focus on IPv6, I would have guessed research from 2003 would not be so well ranked.

Technorati Tags: ipv6, security

Since so many other bloggers are having fun sticking their necks on the line with New Year’s predictions, how can I resist? There’s something about appearing sage–while knowing you can’t get called on your mistakes for 12 months–that is fundamentally appealing. Here are my predictions for 2007. Some of them are somewhat difficult to measure so I’m hoping to get some help from my readers this time next year on how I did. I’d love to see your own predictions as well in the comments to this post.

1. NAC as a term will grow out of favor as NAC teeters on the brink of Gartner’s “Trough of Disillusionment.” This one seems quite likely given that we have already seen a bit of NAC backlash. I can see this going a couple ways. First, rather than the NAC term completely going away I can see it surviving with qualifiers such as “Identity-based NAC.” Another option is that the term itself is completely replaced with something either more generic, or more specific such as network identity management or role-based access control.
2. One of today’s NAC vendors will go under. I don’t see how the market can sustain so many players, especially given that some have seen many rounds of funding and have already retooled their products once to chase the NAC wave. I won’t list all the NAC vendors here but there are easily 15 or more.
3. So that I’m not all doom and gloom, one of today’s NAC vendors will get acquired by a larger firm. Whether the NAC term survives or not, the functionality of NAC–in its broadest definition–is useful to organizations. There are plenty of players who need that functionality in their product portfolio. My guess is a networking player will do the buying. I won’t get into whether the acquisition will be from a position of strength or as a result of the NAC vendor running out of cash, but it is fair to say that both appear feasible.
4. An open-source 802.1X supplicant will emerge as a viable alternative to commercial and OS-native supplicants. So that I don’t give myself any wiggle room here, this doesn’t mean that one is available to download, but rather that organizations are deploying it at scale. I think the market can’t help but make this happen since the OS supplicants are lacking and the commercial supplicants are simply too expensive. Think of the market forces that created Firefox when Internet Explorer wasn’t getting the job done; I think we’ll see something similar here.
5. 2007 is the year wired 802.1X turns the corner from rare occurrence to early-adopter chic. While it won’t be mainstream by any means (that label will belong to wireless 802.1X) it will see substantially more deployment than in 2006.

Technorati Tags: 802.1X, NAC, Supplicant

Back in June I wrote about a new draft in the IETF RADEXT working group concerning access control lists (ACLs). The draft specified a way to generically format and transmit IP ACLs using RADIUS. The draft is now in its sixth revision and left the working group headed towards a proposed standard in the IETF. If approved, we will finally have a common technique for passing ACLs to a network enforcement device from a AAA server. The approach taken in this draft is to reuse the filter format defined within Diameter (scroll down to page 44 to see the format). To date, enforcement vendors have either relied on proprietary techniques for formatting these ACLs or have simply not supported them. It is very common today to see no support for the specific ACL but a more general support for the RADIUS Filter-Id attribute (attribute 11, page 35). The Filter-Id attribute is nice but it only allows the AAA server to point to a pre-existing filter on the enforcement device, not to create one on the AAA server.

The key, if approved, will be getting the enforcement vendors to support the new standard. Since HP authored the draft It seems quite likely that HP will support the capability. If Cisco and Juniper follow suit it would be great news for customers struggling with network level authorizations throughout a heterogeneous network. My guess is customer pressure will be instrumental in getting the big guys on board. Pairing this functionality with network-wide authentication and some basic NAC checks and you’ve suddenly got a heterogeneous solution which hangs together quite nicely. Heck, toss in RFC 3576 support and you’ll really be onto something.

Technorati Tags: 802.1X, NAC, RADIUS

Apologies for the TCP humor.

An interesting article at Network World points to an analyst report from TheInfoPro about NAC. The report, due out next month, shows that “of 126 network professionals, 37% say it is very likely or extremely likely they will decide to develop or implement a NAC policy initiative in the next 12 months, down 17% from earlier this year.” Reasons cited include a lack of standards, high cost, and the lack of a universal endpoint agent.

I always had a sense that NAC–as narrowly defined under the endpoint health banner–might find the “trough of disillusionment” (as Gartner describes it) earlier than expected. With so much hype, so little standards, and so many vendors piling on with solutions it seems almost inevitable. Much of my talks with customers, at conferences, and in posts on this blog have encouraged caution in approaching this problem space so quickly–and so narrowly focused on endpoint health.

Making user identity decisions at the time of network access is a much more proven technology since it has been used to augment the security of dial-up, VPN, and wireless networks at scale. Adding wired access to the authentication solution makes it possible to make access decisions for all forms of network access in a consistent way. Sure wired 802.1X is encountering its own growing pains, but vendors have responded by enabling simpler alternate mechanisms–such as web authentication–to bootstrap wired deployments until 802.1X is truly plug-and-play. It will be interesting to see how this plays out over time.

Technorati Tags: NAC

If you’ve been watching the NEA mailing list lately, you’ve probably seen a rather long thread discussing privacy concerns with NAC technology. While the thread had the usual IETF silliness–and I was unable to resist throwing my own thoughts in as well–it does raise some important points.

With NAC and a single policy domain you have no issues; both the network operator and the client machines themselves are owned by the same entity. So as an example, if FedEx wants to scan a FedEx asset before it connects to the FedEx network, we have no issues. Where the problem comes in is if the network and the machine are owned by different entities. This is common with contractors, vendors, and guests that have their own client machines but are connecting to a network which is controlled by another entity. With contractors this isn’t as big of an issue but for an unaffiliated guest (such as someone attending a training class) it is.

For an extreme example of this, imagine a FedEx machine connecting to the UPS network as a guest: perhaps FedEx is hosting some shipping-industry user-group onsite. The FedEx machine has sensitive FedEx data and configuration information and is controlled by policies defined by FedEx. When it connects to the NAC-enabled UPS network the FedEx machine will be asked to provide client security information to the UPS network. This client security information could include OS patch levels, AV signature levels, registry settings, or the presence or absence of specific data or applications. While this information is being used, in theory, for noble purposes (to evaluate the risk in letting the FedEx asset connect) the check itself is providing the same sort of information that a piece of spyware code might.

Since there are no widely deployed and standards-based NAC solutions, some organizations have deployed NAC interrogation software which relies on downloading a Java or ActiveX applet to the client machine which runs the scan. This could quite understandably violate the security policy of the client machine’s owner. Likewise, without the scan, the network operator’s own security policy may be violated because there is no visibility into the risk level of the connecting asset.

There are two elements in the solution to this problem. First is some ability for the client machine to understand what it is being asked to provide, and who it is being asked to provide it to. This could be done through authorizations in the OS configuration itself or through providing a pop-up to the user informing them that the network the are connecting to is requesting certain information. The key to this disclosure is that it be made by the client machine itself and not some downloadable applet which may not be trusted by the client machine’s owner.

This leads directly to the second element: standards. In order to facilitate this disclosure we need standards for how information is requested and authorized to be sent. NEA can hopefully help here and requirements around these disclosure authorizations are already being explored on the NEA mailing list.

In the meantime, I expect users to comply unknowingly to detailed scans of their systems and that those performing these scans will have good intentions. I don’t see it as unrealistic, though, to expect that malicious forms of this interrogation will be seen in the future. Another short-term option is to not perform client checks on guest systems at all but rather segment them to a partitioned VLAN within the network which runs their traffic through some sort of inline IPS solution. You could still check the guest’s identity at point of connect to enable the segmentation. Then the guest could establish a VPN link to their home network for confidentiality while remote.

Technorati Tags: NAC, privacy