At EIC 2008 I’ve presented our view on the relationship of GRC and IAM as well as our definition of the GRC market, the core results of our GRC market report 2008. Basically, the generic GRC tools we see emerging in the market are becoming more and more the business layer above the classical core IAM tools, e.g. provisioning, self service and some other feature areas.

I’ve been talking with a lot of users within the last few weeks. And what I’ve learned has proven that statement. The most important driver for IAM projects today is the need for defined, auditable processes around user and authorization lifecycle management. And that is about Governance, Risk Management, and Compliance.

To fulfill these requirements, you need a strong IAM foundation. But without a level above for a business-controlled authorization management, for layered attestation from the system up to the business level, for the management of business roles and for a business-centric auditing that won’t fulfill the needs.

Given this it is no surprise that several vendors either integrate more and more of these features in their IAM products, some of them on a high level (Völcker), while others have acquired specialized vendors in both areas (Oracle, SAP, Sun).

Today it is not necessary to buy the IAM and the GRC products from the same vendor, especially because the GRC solutions are in their early stage. And due to the fact that IAM tools always will focus more on the IT level whilst GRC focuses on the business level I’m not sure whether they shall be really integrated. But one thing is sure: You will need both levels of tools to fully support the business requirements which are driving IAM today.

Key Risk Indicators (KRIs) are metrics for Risk. Most of the metrics discussed today focus on either pure business aspects or, with IT and Identity Risk Management, on technical aspects. How long does it take to provision accounts in different systems? How many orphaned accounts do you have in different directories? …

But: There is another layer of KRIs which has to be monitored. For example: How long does it take until an organizational change is known to the provisioning system? The provisioning process might be extremly fast - if it isn’t started, it is still far too slow.

Thus, I propose to define four layers of KRIs:

• Business KRIs
• Business-IT KRIs which measure the interaction of Business and IT
• High level IT KRIs like the orphaned accounts or the performance of provisioning processes
• System level IT KRIs for specific aspects of the single systems

That maps perfectly to my three layer view of Identity Management, with the GRC layer (Business to IT), the provisioning layer (High level IT), and the system level. KRIs on different levels can be combined for a complete view on risks. That is inevitable because, like mentioned above, there might be a low risk on one level but the overall risk might be still high.

In general, using KRIs is an interesting approach not only to know about risks but to measure and improve your organization - and not only IT.

For some time I planned to write a report on the segmentation of the role management market. There are many different offerings for role management which all use the same buzzwords but provide pretty different solutions. But I decided not to write this report - just because there is no role management market. It might appear that such a market segment exists. But in fact it is just a part of a larger market segment, the GRC (Governance, Risk Management, Compliance) market.

The GRC market, on the other hand, appears today as a very fragmented market, with a broad range of solutions and tools. Without telling on everything my upcoming report on the structuring of the GRC market will include, there are at least two levels of distinction between the offerings in the market. The first is around the general level, where you find methodologies, pre-defined solutions (for example rule sets for specific applications and compliance regulations which can’t be applied easily to other threats) and tools.

Within the tools, there appear, amongst others, the vendors of role management solutions. I personally define five core functionalities for GRC tools:

• Analysis of entitlements and Reporting
• Attestation - should, by the way, be multi-layered
• Authorization Management, including SoDs (Segregation of Duties) and, in general a policy/rule definition and enforcement for entitlements 
• Risk Management, including Risk Modeling and Analytics
• Role Management

Within these functionalities, the management of roles is the centre, because the other features rely on this. Workflow features - best solved with the choice between internal and external workflows - are mandatory.

Currently there is no vendor who provides the entire big picture on a high level. But it is obvious that many vendors are working on this picture and are delivering more and more parts of the puzzle.

By the way - based on these tools there probably will be a solution market again which provides pre-defined implementations for specific industries or regulations.

This view gives as well an answer to the question whether GRC shall be limited to IAM. No, it is a broader market. IAM delivers to GRC solutions. But GRC is sort of a bracket across the entire IT infrastructure, building a bridge between IT and business. Thus GRC is going well beyond IAM, even while many of today’s IAM solutions can (help to) solve GRC threats and even while there won’t be a successful enterprise GRC implementation without a strong IAM foundation.

Recently I complained about the insufficient use of existing technologies. But there are some out there who do a better job. Sailpoint is one of these vendors. They are, together with some few others like Aveksa, in the process of establishing the new market segment of “Identity Risk Management”. That is a discipline within GRC which deals specifically with risks which are in some way or another identity-related - which are most of the risks, by the way. It’s about answering questions like “who is allowed to do what”, but in detail and not only high-level. And with a high degree of automation.

And they do it by using Business Intelligence and Data Warehouse technologies.  Thus, they don’t reinvent something on a lower level but make use of existing technologies. The result is an appealing application which obviously is build on some strong kernel of technology.

Another interesting thing about Sailpoint is that there are several well-known guys from the IAM market - some of the founders and early employees of Waveset are no part of Sailpoint. That obviously means that they understand a lot about Identity Management and that they also understand what the customers need beyond provisioning.

Thus, having a look at companies like Sailpoint and Aveksa and the entire new descipline of Identity Risk Management is a must. And, no surprise: Identity Risk Management will be an important topic at our European Identity Conference 2008.

The topic I discuss probably most often as well with vendors and system integrators as with end users is how to sell IAM. The problem behind this is that IAM is mainly seen as an infrastructure element (which IAM is). The potential business value is often quite unclear, as well as many people just don’t know that they need IAM even because they are using different terms. The CRM don’t see their system in the context of IAM even while it’s the biggest identity store in most companies – just an example.

One thing I’m intensively working on is a business-related argumentation which starts with the business problem and ends with IAM – and not the other way round, like it is done in most cases. The other aspect which came into my mind is to sharpen the relationship between IAM and the CIO’s agenda. The first step in this is to have a look on the CIO agenda – what shall be on that agenda (which are not necessarily the same issues that are on the agenda today).

Read the rest of this entry »

This afternoon I had an analyst briefing with one of the vendors which offspring the market segment formerly known as system management which is usually defined today as client or system lifecycle management. This change has been definitely necessary because system management covered a very broad range of different technologies.

But the system lifecycle management segment, which exists for a while, is as well pretty heterogeneous. There are vendors which still mainly support software distribution, OS installation, patch management, and some other administrative functionalities. There are vendors which are moving towards the security market, like LANdesk with their NAC products or Symantec. Many vendors are adding license management capabilities and move towards the ITSM (IT Service management market) or at least to some part of this market - Enteo/Frontrange as one example -  whereas others set their focus on compliance and related topics. The borderlines aren’t always clear. There are many vendors which claim to support license compliance. But there are few which really cover all the details of licenses and which integrate their license compliance tools as well with asset management and automated inventory services as with contract management. In this area you’ll find Managesoft as well as Brainware.

But even for these vendors, there’s the question about how long the niche will exist. The approach of ManageSoft is pretty interesting. They are providing a strong technical integration with the inventory and asset management as well as a dashboard for the business user and IT management. Thus, they might move towards more controls they support in this “compliance dashboard”, they might add risk management functionality or they might do both.

But ManageSoft, like every other vendor who has successfully done the step beyond the administration-focused system lifecycle management, will always have to find new niches fast - because other companies will enter interesting market segments and because the big BSM players always will try to position their solution as the “swiss army knife” you can use for everything.

My observations of the vendors in the system management space over the last years are, that there are some vendors which are able to reinvent themselves. There are vendors who try to grow through acquisitions - not always successful. There are the big ones which sometimes struggle when it comes to the details and still need support of smaller specialists who are able to fulfil the customer’s demand in the context of an enterprise framework. And there are many companies which are neither able to reinvent themselves (at least not fast and innovative enough) nor to grow through acquisitions. In a market segment like system lifecycle management with more than 20 active competitors in Europe - not counted the ones in other areas - the ability to move forward is one of the most important aspects for product decisions. It is because the ones who aren’t innovative are the ones who will in the best case become acquisition targets and in the worst case just will disappear.

Thus, it isn’t done with re-positioning in a newly “invented” market segment which is just a new name for something existing. It is about re-inventing the market segment.

These days I have written a report on the relationship between IAM (Identity and Access Management) and SOA (Service oriented Architecture/Applications). One major aspect of this relationship is around end-to-end-security, e.g. securing the interaction of a user with an application (and the application which implements a business process) up to the backend systems like databases.

That is inevitable because using a service in the context of an user identity or an user role is the only way for consistent, externalized security instead of coded security where some return of a service is filtered by the application depending on the user’s role. Coded security is contradictory to compliance, obviously. It’s expensive in terms of coding and auditing. Thus, it doesn’t make sense.

On the other the most common approaches for web service security are constructed the same way as web access management solutions: Building a layer in front of the services which uses policies to decide how services are used. That includes some part of authorization and sometimes authentication. The problem is: Using such an approach means that there is definitely no end-to-end-security. From my point of view, there is no alternative to federation to transport claims down to the service level. That is the only approach for real end-to-end-security and thus for applications which are architected to fulfill the increasing compliance requirements.

One of the emerging topics in the broader IAM space integrates GRC and Identity Management: Identity Risk Management, including aspects like Identity Risk Metrics. Identity Risk Metrics are used to measure specific aspects of Identity Management. These metrics can be mapped to risks and thus serve as a means to detect and, in the next step, reduce risks. Such metrics can be defined in many areas.

May be the most interesting are Application Risk Metrics – in the context of digital identities. Elements of this category are things like

• Usage of central identity stores (instead of application specific identity stores)
• Sensitive attributes in decentralized identity stores
• Sensitivity of the application and its data
• Supported authentication mechanisms and their strength
• Number of user accounts
• Encrypted storage of passwords
• and many others…

The analysis of these Metrics automatically leads to a clear view on the level of centralization of Identity Management and, combined with the risk view, to a clear rating of risks which exist due to decentralized user management on the application level and the lack of an application security infrastructure.

Measuring these Metrics can clearly lead in more management support for building application security infrastructures and changing the way security is implemented in applications. It is not very difficult to do this sort of analysis. It doesn’t need a specific Risk Management software, it is just about identifying the applications (which is the hardest part) and counting – and may be some analysis in Excel. And it is about mapping the result to defined risks and to provide an answer on the question of “how to reduce  the risk”. The answer is quite obvious – it is the approach of application security infrastructures.

And that is just one example of what you can do with Identity Risk Metrics.

There are plenty of GRC solutions out there. Products for one specific regulations, industry-specific solutions, and more and more solutions which claim to address the entire GRC problem. The level ranges from paper-based methodologies to more or less complex Excel sheets and complex frameworks.

I’m mainly interested in the generic solutions which try to address the entire problem. Many solutions address some part of the problem, but you will need dozens of different products to solve your GRC requirements. That leads to a complex, expensive infrastructure. Thus, a strategy for a generic approach for GRC which can cover all regulations is inevitable. That’s about compliance automation or governance automation, a topic I have published on our website some time ago.

Read the rest of this entry »

Our upcoming Identity Management market report 2007/2008 shows some interesting results. Not to surprising, at least most of them, but nevertheless pretty interesting. One important information is where the money will be spent next year. For sure there is Identity Provisioning. And, as expected, Role Management is a very important area. Besides these both areas there is Single Sign-On as the third topic on which a lot of money will be spent within the next 12 months. More than 30% of the survey participants will implement SSO, will enhance their implementations significantly or will replace the technology which they use today. Another roundabout 30% will optimize their existing implementations. Less than 30% of the companies won’t spend money on SSO.

The question behind is for the reason why. There are some aspects. SSO helps the users. It eases their lifes with less user names and passwords. SSO makes the user the admin’s friend. Another aspect is compliance. SSO might help in achieving some of the targets of compliance, at least in (the strongly recommended) combination with strong authentication.

It is easier to audit who is allowed to access which applications, who actively uses accounts in which system and who has accessed which system when. Upcoming trends like the integration with events from phyiscal access systems, thus doing the step towards context-based authentication and authorization, enhance the support for compliance requirements.

From my perspective, these two aspects - user friendliness and compliance support - are the most important driving factors for the success of SSO. Besides, SSO is pretty mature, at least the Enterprise SSO solutions which are most common today. But also token-based approaches like the use of Smartcards with certificates and other credentials stored on the tokens shows an increasing maturity, lower costs and a broader availabilty of devices.

Thus, if you haven’t solved your SSO issues until know, start thinking about. But when you think about, don’t remain with an internal solution like Enterprise SSO but think about the future. SSO for your customers through support of OpenID, CardSpace and other technologies shall as well be part of your SSO strategy (look at some of our downloads…) as the role identity federation will play in the next years.