Who are you? How do I identify you? Do you have multiple identities? How many systems do you access that require a unique identity?
Identity management has been an issue in IT for years. Identity management becomes a Unified Communications issue as enterprises integrate multiple systems and products where each has its own identity-determining methods.
Identity management (IdM) is more than user IDs and passwords. Identity management is the administrative area that is tasked with identifying individuals in a system or systems and controlling the access to the system resources by placing restrictions on the established identities. There are many identity management techniques and products.
IdM covers a range of dimensions, dealing with technical, legal (data protection) compliance regulations, police (identity theft), security, privacy and enterprise organization structures.
From the user perspective, users have to remember or write multiple IDs and passwords. Even if the enterprise has created a single sign-on method, the user still has to contend with public and other enterprises' identity methods. What is needed is a way that all the systems a user encounters can be federated and interoperable.
A good introductory article is "Identity Management" by Jill R. Aitoro, and Oracle has published a white paper, "Identity Compliance Reference Model" that provides further details of the issues, problems, structure and implementation of an IdM system.
UC Federation
In UC, the enterprise will probably have non-interoperable systems for identity management. According to Andy Zmolek of www.ucfederate.info:
UC federation is the technology that enables one or more organizations to transparently integrate communications and collaboration systems across administrative boundaries without loss of identity context or local administrative controls.
UC federation involves more than routing or directory services for voice, video, IM and presence (although it requires identity for each participant). Without controls for trust and identity, few participants would federate, so both sides of a federation relationship need to be able to apply [acceptable] policy rules.
UC federation involves more than routing or directory services for voice, video, IM and presence (although it requires identity for each participant). Without controls for trust and identity, few participants would federate, so both sides of a federation relationship need to be able to apply [acceptable] policy rules.
Andy Zmolek was most recently a senior manager in Avaya's Unified Communications Division, driving security and identity planning and strategy across the Avaya product line, focusing primarily on applications and next-generation platforms. He was also a co-author and technical editor for the book, "Practical VoIP Security," published in April 2006 by Syngress.
According to Andy, any real UC federation requires the following:
a) Use of a [email protected] construct for communicating and operating on identities, where the identity itself is defined and validated for the user on the left-hand side of the @ sign, within the domain specified by the right-hand side.
b) Establishment of a trust relationship between the domain-specific identity provider for a given @domain and services in any foreign domain that federate with it.
c) Authentication (but not necessarily authorization) of that [email protected] directly by the identity provider for that given domain.
Note that a third party can proxy b) and c) and there can still be federation, but only if the given domain is still authoritative for all its users. If that third party instead becomes authoritative for other domains, you've substituted a central authority for federation, which by definition distributes authority to each domain that creates and authenticates user identities. This weakens the central control.
b) Establishment of a trust relationship between the domain-specific identity provider for a given @domain and services in any foreign domain that federate with it.
c) Authentication (but not necessarily authorization) of that [email protected] directly by the identity provider for that given domain.
Note that a third party can proxy b) and c) and there can still be federation, but only if the given domain is still authoritative for all its users. If that third party instead becomes authoritative for other domains, you've substituted a central authority for federation, which by definition distributes authority to each domain that creates and authenticates user identities. This weakens the central control.
The Issues
Identity Management (IdM) is a necessary form of information protection, and IdM should be implemented with the same emphasis as security. The IdM problem continues to expand as the problems of identity theft and outsiders gaining access to an organization’s resources have moved from the domain of the hacker to that of the cyber criminal.
The problems facing identity management are multifold.
The User
They start with the new employee. The new employee will not be fully productive until they have their user account completed and set up. Existing employees may be restricted until updates or changes have been made to their accounts.
Once users are authorized, they require access to many systems including the network, e-mail, intranet, Internet, ERP, mainframe and many more. The administrator for each system, private or public, needs to perform essentially the same tasks. These require the creation, change and termination of the user accounts.
Different systems will probably have contradictory or only partial information about the user. This makes it difficult to provide services and to ensure secure operations, especially for financial transactions. This is highly redundant and inefficient. It leads to inconsistencies and extra costs. There can also be delays when employees leave the enterprise, which creates another security problem until the access and privileges are terminated. The ex-users may abuse or misuse the access. All of these issues can also appear when contractors are enabled for data and application access.
Administration
If the administrator has created accounts that are not used, then an attack can occur without being noticed as quickly. If new accounts are set up with easy-to-guess passwords or the default password is never changed, then this opens access to vulnerabilities. If users are allowed to continue their access privileges after they change job responsibilities, the user will have more privileges than they should have for their job. If the account information is not configured correctly, users may have privileges that are beyond their job function.
Compliance and Regulation
This is an ongoing problem. Not only are regulations being added by the federal and state governments, the courts may change the regulations’ interpretation. Most regulations also require that the enterprise has the ability to track users and their access to systems and data. The regulations cover customer privacy, business practices and corporate governance. The regulations affect healthcare, financial institutions, retailers, pharmaceutical companies and publicly traded companies. It is common that the organization will have to contend with multiple regulations. Regulations typically require the enterprise to be able to:
* Authenticate the user in a secure manner
* Control user access, especially to sensitive systems
* Ensure data access is appropriately granted to the user
* Prove, measure and report on the three points above
All of these requirements must be consistent, secure, auditable and accurately reported.
Implementation
Implementing an identity management system will not be easy. It is a complicated process. The typical organization needs to determine and inventory what is presently stored, where it is stored and how access is assigned to each application. If there are multiple systems, some of them on proprietary legacy platforms, others using commercial tools or services, then some reprogramming may be required to allow the multiple systems to interact.
Organizations need to create a central database and manage the user access rights. A centralized secure IdM system is the best approach. Users and contractors must be properly trained on security procedures. Constant and consistent monitoring of how applications and data are accessed by users and contractors will help to reduce the IdM issues. The most important aspect is to define and police the policies for the database.
Standards and Collaboration Efforts
The InterNational Committee for Information Technology Standards (INCITS) Cyber Security group 1 (CS1) was formed in 2005 to operate as the US TAG (Technical Advisory Group) for ISO/IEC JTC 1/SC 27 and all SC 27 Working Groups. The INCITS/CS1 area of work includes standardization in the following areas including IdM:
* Management of information security and systems
* Management of third party information security service providers
* Intrusion detection
* Network security
* Incident handling
* IT Security evaluation and assurance
* Security assessment of operational systems
* Security requirements for cryptographic modules
* Protection profiles
* Security checklists
* Security metrics
* Cryptographic and non-crytographic techniques and mechanisms
* Future service and applications standards supporting the implementation of control objectives and controls as defined in IS 27001
* Identity management
* Privacy technologies
The JTC 1/SC 27/WG 5 working group 5 specifically focuses on identity management and privacy policies. The Identity Management Community hosts a centralized forum for sharing code, discussing open source development, and interoperability among different components/systems. Their site provides this description of their effort.
The Identity Management Forum focuses on promoting effective, open standards-based identity management, which allows the right information on identity to reach the right people. The authentication of identities are essential requirements in information security solutions, and the efficient and secure management of identity information is a critical pre-requisite to enabling today's business demands for effective access control and provision management in their IT systems. In today's business operations, best practice on identity management is an expectation that is enforced by increasingly strong legal and regulatory requirements backed by IT audit, where penalties for non-compliance are severe.
As part of this article, I asked Andy Zmolek to respond to eight questions about IdM and VoIP/IP/UC environments. Here are his responses:
1. You have raised the issue of identifying endpoint origination points in VoIP/IPT/UC. What do you think are the security issues of identity assurance/management?
Historically, the notion of identity within telecommunications has been closely tied to either the device directly or indirectly through some kind of address or extension (the latter being the closest analogue we have to user identity). The need to tie those limited scope trust mechanisms with others that can ultimately validate the identity of the individuals or organizations using them forces us to recognize that Identity comprises a chain or even a web of transitive relationships among many different groups that aren't necessarily accustomed to cooperating.
As an individual, my identity is associated with a number of communications devices served through various carriers or my employer's infrastructure (and sometimes both). Those devices connect as endpoints in public and private communications systems. That system exchanges information that contains clues about my identity with other systems via a range of communications and networking subsystems, leveraging both IP and PSTN protocols in the process.
The transitive trust that exists between such systems creates opportunities to exploit differences in trust models from one system to another, leading to an overall weakness in the shared identity model. Enforcing a centralized trust model that overcomes the weaknesses of transitive trust among all these systems isn't something that can happen overnight. It requires close alignment amongst standards, product and service design, operating models. To some degree, even business models cross a diverse set of participants that in many cases aren't accustomed to working together. VoIP/IPT is by no means unique to this situation, but to realize the full promise of UC, we'll have to work out reasonable approaches to identity assurance that translate well across trust boundaries.
2. Are there related security/identification issues?
The biggest challenge is enabling authentication and authorization to take place in a way that doesn't interrupt the flow of the user's communication experience, such as forcing interactive authentication with every intermediate communications and networking system during each and every call. This usually requires defining domains of trust and deploying credentialing schemes that work with minimal user interruption. For example, in SIP, the PAI (P-Asserted-Identity) can be used within a domain or even within an enterprise to indicate that a user has authenticated an endpoint to a trusted server, so there is no requirement to challenge that authentication again.
Single-sign-on is another example of a solution to this problem, for example the Security Assertion Markup Language (SAML) or Kerberos provide services that allow a user or endpoint to authenticate once. Thereafter their identity is known and trusted by virtue of trusting the identity provider itself. Public Key Infrastructure (PKI) with digital certificates can also be used to establish trust domains and validate identity end-to-end.
In each of these examples there are protocols and interfaces that must be supported by all parties that need to establish and validate the identity of the individuals and organizations seeking not only to communicate but also to transact business through those channels on the basis of that identity.
3. Are there differences between internal (to the enterprise) vs. external identity assurance?
We often take for granted in the enterprise, the level of trust that exists from service to service within the IT infrastructure. It is rare for intra-enterprise identity assurance to be deployed with the rigor we expect for external identity assurance, which comes in several flavors. Federation is a way of allowing each organization to offer identity assurance services for their members in a way that may tie back to a common directory. Third parties can separately offer various forms of identity assurance, some of which may not involve federation at all.
There are not only technical but also operational, legal, and logistical challenges in play. An intra-enterprise identity might relate back to an entry in a corporate Lightweight Directory Access Protocol (LDAP) directory without making use of a separate identity provider. Multiple competing solutions to define identity exist, ranging from OpenID for logging into websites, de facto identities such as a Google or Twitter account, identities based on subscriber/provider relationships for telecom services and corporate identities within LDAP and/or Active Directory. In some ways, the enterprise may know less about an arbitrary person on the Internet in terms of personal identity or reputation despite having the more formalized approach to identity management.
4. What problems will exist when enterprises federate their VoIP/IPT/UC networks?
The main issue boils down to trust--assuming you can get everyone to agree on a set of protocols. If you trust the system(s) you federate with, then you assume that they have already authenticated the endpoint and that it does indeed correspond to the communications address that is presented. Adding transitive trust exposes you to the possibility that someone you trust may choose to trust someone you would otherwise not trust (and may not even realize you're trusting).
Mix in different protocols and you add to that challenge by having to map the foreign communications address and associated identity to one that makes sense within the protocol(s) your enterprise is using. Even something as simple as converting Automatic Number Identification (ANI) from an ISDN trunk in the PSTN to a meaningful SIP identity is fraught with hidden identity consequences.
5. What is the state of the standards for identity assurance?
There are more standards for identity assurance than ever and they're still evolving. There are multiple competing standards within a given realm, each with its own supporters, advantages and drawbacks. There is no single standard for identity that traverses all the protocol realms for which identity assurance is required. Take SAML for instance. Although it's dominant in the federated Web Single Sign On (WebSSO) space, it's not meaningfully mapped into SIP for authentication. We have all seen Microsoft attempt to define a single-vendor solution with Passport and of course Active Directory, but we also have standards like Liberty and OpenID that are specifically addressing identity. There are large cloud-based services like Google and Facebook who are defining de facto (though popular) identity services. We haven't even scratched the surface yet on protocols that will give us the electronic equivalent of government-issued identity services like birth certificates, driver’s licenses, passports, and the like. It shouldn't be surprising that a bit of work remains in the UC space around identity assurance.
6. What can we expect in standards in the next 2 to 3 years?
There is a need for more universal identity standards than those which are currently being defined across dozens of existing standards bodies ranging from the Internet Engineering Task Force (IETF) to industry consortia, open-source-style bodies, and even UN-governed organizations like the International Telecommunication Union (ITU). We should expect to see attempts from each of these groups to bridge what they see as the most accessible gaps in the near term. Picking an ultimate winner at this point requires making a lot of assumptions that may or may not hold. Clearly there's a lot of momentum behind SAML right now. Government regulations are the wild card. No single standards body covers enough of the UC space to drive identity standards single-handedly, so even within UC there are a lot of possibilities in play.
A new entrant in the UC federation space is the Unified Communications Interoperability Forum (UCIF). The UCIF mission is to enable interoperability of UC products across all organizations including enterprises, service providers and cloud services. The UCIF will accomplish this mission by:
* Publishing specifications and guidelines
* Defining test methodologies
* Interfacing with other standards groups
* Working with regulatory governmental organizations responsible for UC
What makes the UCIF different is that it is focused on multiple boundaries of interoperability, not a single protocol. The UCIF wants to build upon existing standards, not compete with them.
7. Can we rely on the VoIP/IPT/UC carriers to deliver the identity security?
Carriers aren't even in a position to make ANI and Caller-ID reliable identity mechanisms for the classic PSTN. What makes us think they're any more likely to be effective as identity providers in VoIP/IPT? Whether consciously or not, all enterprises rely on carriers for some level of identity services. Enterprise customers demand security today. That expectation will help drive federation with other enterprises as cloud-based communication services and UC federation opens up new possibilities. UC equipment vendors will be under just as much pressure (if not more) to deliver the identity assurance mechanisms to enterprise customers.
8. Why has this issue been so quiet for the past few years?
I suppose that depends on your point of view. The Identity and Access Management industry has been growing by leaps and bounds, but one could argue it hasn't crossed paths in a meaningful way with UC at this point. In some ways, our industry is still absorbing the convergence of so many other technologies that identity discussions have tended to take a back seat to other considerations within the enterprise. Many enterprises have started to recognize the need to merge their own identity strategy more meaningfully with their UC strategy.
We'll inevitably get there. It's really just a matter of understanding what UC really means when you get beyond all the competing markets. If you can't tie every form of communications back to the identity of those communicating, then you can't unify the rest of your business processes that depend on that identity information to be both known and reliable. Simply put, unlocking the full potential of UC requires identity assurance as a foundation. It's a good measure for those deploying UC on the maturity of their vision. If you haven't bumped into these identity and federation issues yet, you're either not very far along in your UC plans or you're aiming way too low
