ian glazer's tuesdaynight

Our marketing team recently completed a survey of IT types at banks and credit unions, asking about data breaches, identity theft, information security costs and risks. The survey uncovered some interesting results, especially regarding how they regard insider threats (very seriously) and the estimated organizational costs of a major data breach (more than you’d think). With most of the security discussion focused on consumer banking (phishing, stronger auth of retail online banking), we were also intrigued by feedback about business banking customers. The majority of respondents agree that business customers demand greater security for Web and electronic banking services. They also agreed that business customers would be willing to limit access to certain services for specific users connecting from specific computers. This is a departure from thinking on the consumer side — banks just can’t force individual users to log in from only one machine. (Even if logging in from another machine requires you to take and extra step, like answering a secret question.) Getting consumers to work with anything other than username and password is going to be challenging; this is one reason why I have so much hope for CardSpace. (I am tempted to refer to consumers as lazy but a) that’s not really accurate and b) they have been trained into their malaise.) It may not fit for consumers, computer-based access control makes perfect sense for a lot of business banking services. As a business owner, I would probably only want authorized users from my accounting team to have access to payroll or wire transfer services, and only from known computers in the office. Or I would only want known POS systems connecting with my bank’s remote deposit capture servers. We will be sharing the complete results of the survey on a Webcast October 10 and 1 p.m. EST, sharing the virtual dais with Tripp Johnson of Cornerstone Advisors (the guys behind the very amusing www.gonzobanker.com). More details and registration information here: http://www.trustednetworktech.com/webinar_banksurvey.asp.

In prepping for the panel he is leading (and I am speaking on), Eric Norlin has been reading through the mire that is NAC literature. I’ve talked about how Network Access Control (NAC) is a thorny term that is misunderstood, misused, and a bit misleading: here and here. Eric recently called for TNT, among others, to rebrand/rename the entire market space to something more clear than NAC. He suggested Network Identity Management or N-IdM. He suggested that N-IdM would be distinguished from Application Identity Management (A-IdM) - what we think of as traditional identity management. Let’s look at the typical services that A-IdM and N-IdM offer. Under the A-IdM umbrella:

Another level-headed anaylsis of current events and responses.

Before the 4h, I posted on the access control-side of NAC. I compared it with web access control and examined some similarities. This week, I want to look at the other side of NAC: admission control. NAC as Network Admission Control Treating NAC as admission control is more of a network/threat-centric approach. There are some basic characteristics of NAC as admissions control: • Health and configuration validation and remediation • Machine authentication to the network infrastructure • Assignment of IP address Health checking is a common NAC function. This is just good house keeping and it is something that every organization, big or small, needs to do. There are a variety of ways to check the health state of a connecting end-point and most are fairly simple to do. The challenge is managing the remediation of a sick end-point. This is where the real skill of NAC vendors (and a lot of time - their partners) comes into play. How do you quarantine? What configuration management and software distribution tools are used to remediate the problems? How do you orchestrate all of these pieces working together? This is non-trivial work and there are a lot of vendors out there doing really great stuff. The next two items are not truly mandatory functions for admission control, but they are important nonetheless. Some form of machine authentication is lumped in here: RADIUS, 802.1x, EAP. This is one approach to ensure that only organization-owned laptops are on the network. What concerns me is the conflation of me for my laptop. In order to truly understand what is going on inside the network, user and machine identity have to be treated separately. I am not my laptop and my laptop is not I. Last, getting an IP address is the last aspect of admission. Some NAC vendors integrate with DHCP services to orchestrate all the necessary steps for admission including address assignment. I’m not saying that DHCP services need to be embedded into the same product that does health analysis, but it is the last step to network admission and should be treated with importance. Will the real NAC please stand up? In conversations, blog entries, analyst papers, which NAC is being discussed? I feel that both are necessary to have a complete story, but each side has a different heritage and mindset. Using NAC as an abbreviation blurs the distinction between what is required for admission versus access control. We can do better. Anyone up for renaming this market Network Admission and Access Control – NAAC?

I really like the current capabilities and promise of NAC. I do, however, have a problem with the abbreviation, specifically, the “A” in NAC. Which do people mean when they say NAC: “network admission control” or “network access control”? To me, there are big differences between the two. NAC as Network Access Control If you have an identity background, when you hear NAC, you think, “Oh, this is web access control for the network.” If that’s the case, then NAC needs to have some features that mirror WAC. For example: • Identifying the user is key. • There needs to be a centralized policy store that describes access control. • There needs to be a fine level of granularity of those policies. • There needs to be some modicum of single sign-on. • There’s going to be some form of the proxy versus plug-in fight. User authentication has always been a part of web access control, and network access control should be no different. WAC vendors have all sorts of mechanisms to authenticate the user either directly or through other authentication providers. NAC vendors do, but, I conjecture, not in the same way. There are two flavors here: explicit and implicit. Explicit NAC authentication involves the end-user in an authentication event. Forcing the user to authenticate to RADIUS is a form of this. Implicit authentication uses authenticated credentials from something higher in the stack (like the operating system) and not involving the end-user in an extra authentication event. Centralized policy store — yes, they exist. The market has no problem building policy stores. In fact, as I have mentioned before, there are too many policy stores out there today, with little integration and hierarchy to them. Can I use a single policy tool for all of my identity-based access control? Nope, not yet. I have heard from numerous people: “I already use vendor X’s web access control tool. Can I use it to describe policies for network access control?” The funny thing is this existed nearly 10 years ago. DASCOM’s IntraVerse had both a web component (WebSeal, part of IBM Tivoli’s Access Manager for e-business) and a network component (NetSeal, which lived about as long as a drummer for Spinal Tap.) What’s old is what’s new, and I guarantee that in the next couple of years we’ll see a return of this model for a variety of reasons. Fine-grained policies — can I describe a network access policy down to the object level: file, row, transaction, etc.? Kinda, sorta, maybe. There are vendors that do this, but they are typically application specific. There is a gap between that level of control that various products provide and more general network access control. Part of the issue is that getting a NAC product deep enough into an application to get that level of granularity isn’t easy and requires modifying and/or distrupting the application. Further, as anyone who has ever tried to maintain group permission information knows, the more objects you want to tie to group permissions the harder it gets to work with. (This is why user-provisioning tools have shied away from group management at any deep level.) WAC products had basic single sign-on, at least for the applications they protected. If NAC is really an offshoot of WAC, you’d expect the same. Does this mean that Imprivata and Passlogix and the like are NAC vendors? I think that’s a bit of a stretch. Will NAC vendors grow PAM modules? Someday, but not any time soon. Back in the day Netegrity and IBM fought it out over the best architecture for web access control. Was it better to deploy proxy servers to control access or plug-ins to application servers? At the end of the day, the answer was: it depends. Both vendors supported both. Will this architecture difference arise in NAC-land? I wouldn’t be surprised if it did. We already see SSL VPN vendors acting as a form of proxy server. Could we see a rise in plug-ins to applications running on the network to provide extended NAC services? Maybe, but I think we’ll see SPMLv2 adoption before we see NAC plug-ins for applications… either way — don’t hold your breath. After the 4th, I’ll be back to examine the other “A” in NAC – admission. Ian

That question was asked by a guard at Department of Homeland Security’s headquarters. Bruce DeCell, a retired New York City police officer, presented identification. What he actually presented and was accepted as valid ID is quite amazing. You have to read this Washington Times article to believe it. Clearly, Mr. DeCell’s name was matched against the list of vetted guests for the day. Other than his name, clearly no other component of his ID was even remotely examined. This isn’t much different than the “check the name game” that the TSA has us go through at airports. It seems pretty simple to me, if you are going to ask for identification, at the very least you ought to examine the entire piece of identification: not just the name, not just the picture. Further, if people are checking credentials, they need trustworthy systems to validate those credentials. At least DHS did one thing well, after (poorly) being authenticated, Mr. DeCell was escorted constantly. You can come in, but I am going to watch every move you make.

Phil has released his fourth Identity Fallacy - Identity is Monolithic. After reading it, I could almost hear the choir of meta and virtual directory companies rise up in praise. This what they have been really been talking about all these years, but often times lacked the distance from the problem to express it out so clearly. To continue his train of thought, if I may, although identity is not monolithic, our perception is our identity is monolithic. There is one me. I may have many contexts in which I work, live, play, and shop, but at the bottom of it, that is still me. This mindset is getting people out there in trouble. You keep track of your various bits out there. You do not have all that data on your computer or phone, but you have a bunch of it. Applications like Keychain on the Mac help aid your memory by providing pointers to other bits of you. You keep track of things that aren’t immediately recognizable as you, such as your characters in MMORPGs and your alter ego on MySpace where profess to be a lot more interesting than you really are. (See Mark’s musings on that one.) Essentially, you act as a powerful virtual directory for things that you perceive as owning. You own your account on your home computer. You own your wallet with your driver’s license in it. These are all pieces of your “monolithic” facade of identity. By definition, your identity cannot be monolithic as it is comprised of all these little bits that you are tracking. But, we still like to think of the notion of the singular me. (What could be interesting to research is if people with a polytheistic set of beliefs hold the same notion of singular self as those with a monotheistic set.) In fact, the belief that you own the various components of your overall identity edifice is what gets people in trouble. You think you own your account on the corporate email system, and thus you track it in your virtual directory. If you haven’t realized by now, you do not own that identity. VPN account. No. RACF id. Absolutely not. Though you don’t own these things, you still track them as if they were really part of you. Seems fair - you do use them frequently. You typically use them in a work environment and people, to varying degrees, associate work and self. Keep in mind those are not things that you own, merely things you use. It gets worse. Much worse. There is a whole category of things out there that you don’t, and often times cannot, track: data about you. Credit records. Insurance information. This is all the good stuff that gets copied and reused; the activities that fall under the header of identity theft. (I wince when I hear people talk about having your identity stolen. The metaphysical implications are staggering.) There is so much out there that you and I don’t track; it is truly astonishing. No one would confuse my identity for a record in a police database saying that my car was parked on Main St at 10:05 AM last Tuesday, but these days, the two are more and more equivalent. Revel in the fact that you are such a good virtual directory. Okay, you may not blow the doors of a benchmark, but you hang with the best of them. Just keep reminding yourself that a) you may not own as much of “you” as you think and b) your identity isn’t monolithic. I’m off to Catalyst; see you there.

Yesterday it was announced that Service Provisioning Markup Language (SPML) version 2.0 was ratified by OASIS. This warms my heart for two reasons. First, it is great to see the work of so many people come to fruition. Gary, Jeff, and Gavenraj really drove things forward and put in an amazing amount of effort. (On a personal note, since this was the first standard I worked on, I get a kick out of seeing my name as a contributor.) Second, SPMLv2 brings user provisioning into line with access management, in terms of having standards to work with. This was a topic Phil and I discussed in our webinar. Now the provisioning market has a rich, usable standard to help drive implementations and integrations. SPMLv2 gives application vendors a way of making their applications easily provisioned. It gives provisioning vendors a way of quickly integrating and connecting to applications. Everyone wins. Are we there yet? Has the identity management arrived at its final destination? Nope, but we are getting closer. In order to realize its full potential, large application vendors have to adopt SPML. SAP and Citrix have done so. Oracle and Microsoft cannot, I hope, be far behind. By having SPML-based hooks in major applications a lot of the grunt work of connecting provisioning engines to target systems is removed. It decreases the time to value in user provisioning implementations. It allows project teams to focus on policy and process and not how to connect provisioning engines to systems. Assuming that large application vendors build SPML gateways in their applications, are we there yet? Still, the answer is no. There are a ton of older applications out there. Though I can see SPML gateways for RACF and ACF2, its harder to imagine development teams building SPML hooks for their bespoke applications. If database vendors built SPML parsers into their engines, then homegrown applications could be in better shape… but I don’t see that happening any time soon. In other news, Virsa was gobbled up by SAP. I don’t think this comes as a big shock to anyone in the industry. I wonder if it doesn’t mark the beginning of SAP’s entrance into the identity management market. First, major SPML support. Now, Virsa. What’s next for our friends at SAP… a provisioning system? They have got to be feeling pressure from OraclePeopleSoftJDEdwardsOblixThor. Tags: identity, IdM, identitymanagement, spml

Once our service provider worked out all the kinks, Phil Becker at Digital ID World and I finally got to record our chat about identity management as a project versus as a lifestyle. There were three major points I took from Phil. Managing the Project Phil and I both had agreed that managing your identity project, regardless of technology, is critical. This requires an understanding on all parts: vendor, implementer, and customer. Biting off less than you can chew is the way to go. Further, regardless of technology: access management, password management, user provisioning, etc., you can find quick wins that show real value. I know this sounds like basic project management, and it is, but it is vitally important in identity management. Policy Phil and I spent time talking about linking business and identity policy systems and integrating policy engines. Correlating business policy and procedure down to identity management systems is a tough job. Often, it is done by a few individuals who tackle it in their spare time. Tighter integration is needed. However, this requires system to system communication and policy interpretation and this is quite difficult. Furthermore, there has been little work in the vendor community to express policies in a neutral language let alone the transport and transformation of said policy. Standards As federation matures, I think we will see more intra-company federations (obviously) and more inter-company federations. Lines of business will wrestle back some freedoms lost in centralization. This will lead to richer policy and provisioning integrations that require richer languages. SPML version 2 is a much needed addition to the tools we have to work with, but its adoption is slow. XRI/XDI is another set of promising work. Final Thought By having frank and open discussion between vendors, customers, and implementers, we can chart the course of identity management. As customers deployments have matured, they have pulled vendors along with them. By working through real-world use cases we, as vendors, can truly tackle customer needs. Recommended Reading If you haven’t read any David Foster Wallace, check him out. If science fiction is not your speed, take a look at the book that inspired the title of this blog: A Supposedly Fun Thing I’ll Never Do Again. Here’s the link to the slides in pdf form… of course, you don’t get my and Phil’s witty banter. Here’s the recording of Phil and I talking… witty banter included. (Be forewarned our provider only supports IE.) Tags: identity, IdM, identitymanagement

I’ve been reading The Blue Cliff Record. Not an easy read, especially for a non-Ch’an Buddhist. Not an easy read for a Ch’an Buddhist. Just not easy. At any rate, I came across a great note that translators (Thomas Cleary and J.C. Cleary) added:

The image of a dog which, hit with a clod of dirt thrown by a man, ignores the man and chases the clod in anger, is found Kasyapa-parivata; it symbolizes those who are afraid of the delights of the senses and seek deliverance in solitude and quiet - they never really become free because they are dependent on solitude and quiet, becoming every bit as much, and even more, miserable and confused as before when they again come in contact with the hustle and bustle of ordinary life.