Oh great…

This won’t help me sleep any better. Ira Winkler and his team apparently cut through a power company’s security like a hot knife through butter:

We had to shut down within hours,” Winkler says, “because it was working too well. We more than proved that they were royally screwed.” In addition to consulting, Winkler is author of the books Spies Among Us and Zen and the Art of Information Security.

The problem is pervasive across the power industry, he says, because of how power company networks evolved. Initially their supervisory, control and data acquisition (SCADA) networks were built as closed systems, but over time intranets and Internet access have been added to the SCADA networks. Individual desktops have Internet access and access to business servers as well as the SCADA network, making the control systems subject to Internet threats. “These networks aren’t enclosed anymore. They’ve been open for more than a decade,” Winkler says.

Permimeter security kills.  Fortunately in FL we have to prepare for extended power outages anyway.

The elephant in the room

In the latest installment of the Great Meta-Virtual-Directory-Identity-2.0-Bus-Hub Debate, Dave Kearns is groping elephants. Dave allows that we are all really talking about the same Meta-Virtual-Directory-Identity-2.0-Bus-Hub, but like the three blind men and the elephant, we just can’t agree we are all groping the same animal.

Kim Cameron elaborates what features needed for the Meta-Virtual-Directory-Identity-2.0-Bus-Hub. Kim’s requirements:

• By “next generation application” I mean applications based on web service protocols.  Our directories need to integrate completely into the web services fabric, and application developers must to be able to interact with them without knowing LDAP. 
• Developers and users need places they can go to query for “core attributes”.  They must be able to use those attributes to “locate” object metadata.  Having done so, applications need to be able to understand what the known information content of the object is, and how they can reach it.
• Applications need to be able to register the information fields they can serve up. 

Today’s virtual directories just don’t do this any better or any worse than metadirectories do.  Virtual directories expose some of the fabric, just as today’s metadirectories do, but they don’t get at the big prize.  It’s what I have called the unified field of information.  Back in the 90’s more than one analyst friend made fun of me for thinking this was possible.  But today it is not only possible, it is necessary.

Phil Hunt throws in his requirements Meta-Virtual-Directory-Identity-2.0-Bus-Hub:

• There should be a new generation of APIs that de-couple developers from dependence on particular vendor implementations, protocols, and potentially even data schemas when it comes to accessing identity information. Applications should be able to define their requirements for data and simply let the infrastructure deal with how to deliver it.
• Instead of thinking of core attributes as those attributes that are used in common (e.g. such as surname is likely the same everywhere). I would like to propose we alter the definition slightly in terms of “authoritativeness”. Application developers should think about what data is core to their application. What data is the application authoritative for? If an application isn’t authoritative over an attribute, it probably shouldn’t be storing or managing that attribute. Instead, this “non-core” attribute should be obtained from the “identity network” (or metaverse as Kim calls it). An application’s “core” data should only be the data for which the application is authoritative. In that sense, I guess I may be saying the opposite of Kim. But the idea is the same, an application should have a sense of what is core and not core.
• Applications need to register the identity data they consume, use, and update. Additionally, applications need to register the transactions they intend to perform with that data. This enables identity services to be built around an application that can be performant to the application’s requirements.

Since Dave first brought up elephants, let me point out the elephant in the room no one is talking about; AD. For the vast majority of enterprises AD plus other identity services already serves the role of the identity hub. It is your company’s identity store, authentication service, authorization service, and attribute service. It is used to identity enable your remote access gateways and your email servers. If you are using a Virtual Directory, chances are AD is at least one of the stores behind it. Other companies such as Quest and Centrify have developed products to extend AD authentication to wide range of heterogeneous OSs.

Vendors have created products for provisioning from AD out to disparate systems. When I started at Access360 AD didn’t exist yet and our strategy was to get the buy-in from HR up front because the HR system was the source of all identity information. By the time I started doing provisioning at OpenNetwork Technologies, we assumed that customer already had an HR feed into AD.

While I like both Kim and Phil’s vision of what a Meta-Virtual-Directory-Identity-2.0-Bus-Hub should be, the big question customers are going to ask is why? Companies have spent an incredible amount of money building out AD as their identity hub. What specific cost saving or new capabilities will they achieve by implementing this vision?

Kim thinks web services are the answer. But what specific web services and what specific advantages do they offer? Will they be easier to adopt than LDAP? If we think LDAP hard for developers, wait till we try explaining WS-CombinatorialExpansion. 

Phil thinks a key requirement is to abstract the protocols and schemas. Is that really an important requirement given the near ubiquity of AD?

I know this isn’t pleasant to hear, but AD is the incumbent. It’s nearly everywhere. It’s scalable to millions of users. The LDAP protocol is efficient and mature. It’s supported by countless applications. Before a customer considers displacing or adding another identity layer on top of AD they are going to need real cost savings or additional capabilities and order of magnitude over what they have now.

That’s not to say LDAP is the perfect solution or even the best solution. But if we are going to propose a better one we have to say specifically why it’s better. With real examples that customers can relate to. With cost savings and capabilities they can’t reach today with AD.