Three Characteristics of a Mature Identity and Access Management Program

/in , , , , , , , , , , , , , /by

Identity and Access Management (“IAM”) as an industry started gaining significant recognition and momentum around 2003. During these last 12 years, we’ve seen product vendors come and go, we’ve seen industry consolidation, and we’ve seen important product innovation driven by real business need.

While all this has been going on, many companies have leveraged IAM products to achieve important and significant gains in security, efficiency and compliance enforcement. On the other hand, some companies have tried and tried to establish effective IAM programs only to fail in their attempts to affect real change.

What makes one company succeed and another one fail while attempting to leverage the same products and technologies? What are the characteristics of a truly mature IAM program?

Over the next few weeks, I will attempt to address these questions. I also hope to create an important dialogue among those of you who have “been at it” for the last 5-10 years and have seen and been part of great successes and colossal failures. Although I have been part of hundreds of IAM projects, and will lend my experience to the discussion, you, as the readers and contributors, may have much more to contribute to make this topic come alive. Will you help?

Let’s get started with three important characteristics of a mature IAM program. This list is not exhaustive but these capabilities are common among organizations that have made IAM a strategic part of the IT infrastructure.

#1 – User Identity Integration

Pieces and parts of a user’s identity can exist across many different systems in an enterprise. HR systems are an obvious source along with IT systems like Active Directory. Then there is the badge or physical access system, the phone system, and various business applications that become critical for a user to perform their role. Before long, keeping up with all these disparate systems and keeping user attributes current becomes unmanageable. Most organizations recognize the problem and also recognize the need for a consolidated view of a user’s identity. It seems simple enough, but it takes planning, time and good processes to move an organization down the road to centralizing processes, automating synchronization, and removing redundant identity attributes from across the enterprise.

#2 – Account Provisioning

Creating an account on an appropriate system with the correct permissions is a straightforward task when you’ve been given the right information and you have the time to get it done. When a company grows to around 3,000 employees, the enterprise reaches a tipping point where going about this using people and manual effort becomes untenable. Too many requests for new accounts, or too many changes to existing accounts, or repeated requests to remove accounts for terminated employees all begin to pile up. This creates a backlog delaying new workers from getting started, hampering productivity, or creating security exposures where accounts of terminated employees remain active far too long.   Centralizing and/or standardizing the process can help but adding technology that provides automation will speed up the process along with enforcing identity standards, access entitlements, and important policies and standards. Automatic account removal of terminated employees is also a significant gain. All accounts on key systems can also be tied back to a central, validated user account eliminating unknown, orphaned user ids from across the enterprise.

#3 – Password Management

Password management activities face a similar challenge as an organization grows and adds more and more people, systems and applications. Initial steps should be to provide tools to help desk personnel centralize and automate this activity. Ultimately an organization needs to move this function away from the help desk and enable the end user to manage his own passwords on key systems, including resetting their own Active Directory password. This is another step that seems simple on the surface but can actually take a significant amount of planning and coordination to get it right and keep it running smoothly. Organizations that make a misstep on their first attempt find it difficult to gain user adoption the second (or third) time around. Eventually, standardized help desk procedures can assist the user community in adopting the self-service approach to managing passwords.

 

Identity integration, provisioning and password management are three essential building blocks, but there are another 8 – 10 key capabilities we could discuss that should be considered when talking about IAM maturity. What other capabilities would you consider to be essential building blocks? Please contribute to the discussion.

Up next, let’s talk about the essentials for planning a long-term, mature IAM program. If you’re just getting started or have been struggling to make progress, what are some of the keys to putting plans in place that can be effectively executed?

3 Benefits of Abstracting Web-Based API with a Dedicated Gateway Layer

/in , /by
Right now, the solution du jour in the IAM space seems to be focused around enabling mobile and cloud based services for the enterprise. Organizations’ IT departments around the world are being tasked with providing the business with services to allow access and visibility of services to more platforms and providers than have ever been previously required. Mobile platforms, BYOD and SaaS provider requirements , along with new classes of threats against web based API’s, have given rise to the need to secure these services to in order to protect the organization from new security risks.
Building  an abstraction layer between internal services and external mobile or SaaS platform providers makes sense for a number of reasons from a strict security focused point of view, however there are also a number of benefits to utilizing this approach that may not be immediately apparent that can help to justify the adoption of these solutions.
1) Rapid enablement of mobile and cloud services: Most organizations these days have already invested significantly in developing services that enable their business. It makes sense to leverage these existing services, but with the adoption of Mobile and Cloud based service requirements (such as REST, OAUTH, etc) the choice to re-tool can be a costly one. Products like Oracle API Gateway can be used to translate these types of requests into formats expected by your existing services catalog. This can significantly cut down the time required to enable access to these solutions from these new services.
API1_JPG
2) Abstraction of external identities integrated with existing services: Often times, existing services that are deployed within the organization were not initially envisioned to be consumed by users or entities outside of the organization. Many organizations, in order to leverage existing investments in development assets, want to do so but are concerned with the lack of security controls that may not have been built into existing services infrastructures. An API Gateway is an excellent place to implement such controls when introducing these services to new user constituencies. By integrating a new or existing Identity and Access Management infrastructure with your Gateway, you can introduce controls such as strong authentication, certificate requirements or even a security token services to protect access to these services while minimizing redevelopment of these assets.
API2_JPG
3) Centralization of Cloud Service API Key usage: The traditional approach to securing our organizations has been a perimeter focused exercise where the concern has been to protect the organization from external threats intruding into corporate networks. As mobile and clouds services blur the lines of our borders, it is important to consider those assets which may grant user access to information that may be stored within a cloud service provider. Many providers allow organizations to interact with their hosted data in a programatic fashion. Often, providers authenticate these types of request using ‘API Keys’ that are issued to customer organizations and users. One core tenant of a strong IAM posture is that no credential should ever be shared between two parties consuming the same service. This creates a management headache when dealing with externally hosted cloud service providers that issue such API ‘access keys’. Issuing individual keys to each developer may not only be impractical, but also represents certain security and operational management concerns. By routing internal requests to external service providers through a gateway, there is an opportunity to provide common access control based on a pre-exiting internal credential, certificate, etc. Once the request is authenticated and authorized, the API Key for the given service can be applied to the request at the gateway layer. In this way, management of such functionality is centralized and protected using trusted standards.
API3_JPG
There are many obvious benefits to protecting service based requests coming into and going out of your organization’s infrastructure, but some are not quite as plain to see. Clearly, mobile and social technologies present great potential benefits, but come with a new set of risk. It is important to make sure we are leveraging all of the tools available to us in order to ensure these services are delivered with minimal risk of exposure to the enterprise.