Sean Convery

Today I am thrilled that the formation of the OpenSEA Alliance has gone public. We’ve already had some nice press coverage. OpenSEA (Open Secure Edge Access) formed to promote the development of an enterprise-grade 802.1X supplicant. We’re basing our work on the existing XSupplicant. The founding companies are Extreme Networks, Identity Engines, Infoblox, Symantec Corporation, TippingPoint, Trapeze Networks and UKERNA. Jon Oltsik and I blogged about this a while back and this is the result of Jon’s efforts to corral the right industry players to make this happen. I’ll follow up with another post once I’ve had a chance to digest the industry reaction. For now, the FAQ has lots more information.

Technorati Tags: 802.1X, AAA, NAC, Supplicant

While normally I would shy away from mentioning Identity Engines’ online events here, I’ll make an exception this time. I’m presenting the IdM-N talk on May 10th at 11:00 AM PDT via the web. If you’d like to hear me talk through some of the concepts live and ask questions (though you’ve always got the comments field on this blog) feel free to register. I can’t guarantee one of our friendly sales guys won’t call you, so consider yourself warned. I’ve got a few slides at the end on what Identity Engines does but the bulk of the talk is vendor neutral. The talk will be nearly identical to what I delivered to Secure IT, NYMISSA, and the NAC so if you are familiar with the material in those presentations you can safely skip this one.

Technorati Tags: AAA, Identity Management

Eric Norlin responded to my Identity Management for Networks post with some thoughts of his own. It sounds like we are mostly on the same page (i.e. he agrees sticking the “N” or “A” at the end might help) however he did point out some real challenges to the merger of the two spaces:

Sean sees identity management becoming a “single entity.” I’m not as optimistic. There’s an awful lot of legacy to get through here — legacy of job titles, legacy of how software and networking companies are organized, just plain legacy. Will IdM-N and IdM-A products and suites have to learn how to be intertwined? Absolutely. Will they merge? That sounds like a ten year job to me.

I actually think we agree here more than we disagree. I absolutely agree that this will take a while, perhaps not 10 years, but certainly more than a couple. Eric’s post and my conversations at the recent NAC conference got me thinking about the phases of integration. This certainly isn’t a binary switch-over and I doubt we’ll want to get to one solution from a vendor that addresses all your identity needs. Hopefully Eric will chime in here as I’m guessing I’m missing some steps, but these are the big stages of integration that jump to mind.

1. Networks and applications use the same back end directory for user authentication. I think we’re mostly here now, or very close to it. Whether it be through a meta / virtual directory or direct to an AD or LDAP store, the customers that I’m engaged with either are already using a single directory infrastructure or are rapidly moving toward it. Of course bridging across multiple directories, groups, and attributes will remain critical, but this will be pain experienced equally by the applications and the network.
2. Networks and applications trigger authorization policy based on the same groups and attributes. This isn’t yet happening consistently within applications so it certainly isn’t happening consistently between networks and applications. Getting this to happen has a lot to do with step three, below.
3. HR user provisioning systems create one user record which automatically has associated application and networking rights. This is another place where we have work to do. Today an HR provisioning system from one large vendor might only deal with rights and authorizations for that large vendor’s applications and not the rest of the infrastructure’s needs. However, creating the right workflow so that, say, the HR system can define a user as an employee, privileged employee, or contractor would allow the network to inherit those authorizations and enforce them within the network context.
4. Network and application policy decision points (PDPs) share policies or audit information. This is another area that needs lots of work. Standards like XACML make this easier, but there still needs to be a defined schema for the attributes and an understanding of why the policies would be shared. Two easy examples would be one, allowing an application to query audit data within the network to see that a given user has a secure network connection before granting access to a sensitive area. The second is the application PDP informing the network of the systems the user has access to; the network could then prevent IP connectivity to disallowed applications. (Note: server virtualization will make this tricky.)
5. A single PDP brokers policy decisions for networks and applications. I doubt we’d ever get here for all network and application requests (nor would we likely want to) but it seems likely that subsets of applications and networks will share a common PDP. This PDP could then share policies with other PDPs inside or outside the organization.

So as I was saying earlier, this isn’t going to happen all at once. I’d also expect different organizations to go different lengths down this road based on their culture, politics, and business needs. In general based on my dealings with customers, there is a definite desire to make this happen primarily for business efficiency and compliance.

Technorati Tags: AAA, Identity Management

I presented Identity Management for Networks to the Network Applications Consortium (NAC) late last week. The presentation is very similar to others I’ve posted recently so no need to download it if you’ve looked at anything I’ve done recently. What is new is my answers to the presenter questions the NAC posed to everyone at the conference. As the questions are fairly interesting, here they are complete with my answers in italics.

1. Do you see any differences in how the authorization policies of networks vs. applications should be engineered, managed, and provisioned? Network policies are broader today due to limitations of the technology and understanding of the business roles. Eventually network policies will be merged with application policies.
2. Are there any advantages or drawbacks in the flow of the access request being sent to the PDP first or the PEP first? PDP first requires basic authorization to route the request from the network edge which may be suboptimal.
3. Do you see declarative authorization interpreting and enforcing more finely grained authorization policies than they support today? Yes though this is as much a challenge for enterprises to understand their roles as it is a technical challenge to support the fine-grained authorization.
4. Should SAML authorization assertions, and requests for authorization assertion, be used in the communication between PDPs and PEPs? If not, what should be used? For networks, SAML will be used in the future but perhaps more for PDP to PDP communication in a federated model than for PDP to PEP communication. In the network space RADIUS has traction simply because it is so ubiquitous.
5. How can we meet our need for flexibility to deploy centralized and/or de- centralized approaches within an enterprise and across enterprise customer, supplier, or channel partners using different platforms? Policy portability through XACML and authorization assertions through SAML can address much of this, challenges here are more at the organizational level.
6. Comment on the NAC’s best practice of locating the PEP as close to the resource as possible. For networks, it may make more sense to locate the PEP as close to the point of network access as possible to reduce exposure to threats. If you consider the network the resource then our best practices are aligned.
7. Comment on the NAC’s best practice of balancing between availability and performance when selecting the location of the PDP. This makes perfect sense, distribution of the PDP may be key depending on the application.
8. Comment on the NAC’s best practice of having platform agnostic PAPs and PDPs, loosely coupled with access management product offerings (e.g., WAM products). This allows for the independent evolution of PAP, PDP, and PEP technology, without disrupting the other components. This is the only way this can scale long term, particularly the vendor neutrality between the PDP and the PEP. Standards for access control formats need more attention.

Technorati Tags: AAA, Identity Management

Tim Greene has an article over at Network World on how a student at the University of Portland bypassed a Cisco Clean Access (CCA) NAC check to get on the network and got suspended as a result. Simple device software checks, such as those done by CCA were never meant to provide 100% security. Of course no security measure provides that level of protection. Device software checks were designed to prevent the inadvertent user with an out-of-date system from getting on the network. A user bent on introducing malicious code into your network isn’t going to be stopped easily. As I’ve wrote about endlessly, security is a system, not one product. One tenet of good security analysis is to assume that one layer of protection within your environment completely fails. How the rest of your security system picks up the slack is a very telling metric regarding the overall security of your network.

As NAC becomes more pervasive, so will the techniques to bypass its checks. The hope is that those individuals with the technical competence to bypass the checks are also competent enough not to have their machines compromised. How true this is remains to be seen.

Technorati Tags: NAC