29.04.2008 by Martin Kuppinger
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.
29.04.2008 by Martin Kuppinger
I have a personal history in the areas of personalization and profiling. And there might be some good chance for these ideas to become reality now – in the context of Infocards and to the sake of VRM (Vendor Relationship Management).
The threat in personalization and profiling is to know what the person really wants (personalization) or is/has (profiling). The one who knows best is the person itself.
(Managed) infocards can transport virtually everything. They might provide profile information for personalization. A trusted identity provider might offer a service which stores profile information it retrieves from the users and provides it in a controlled way (the basic idea of user-centrism) to web sites which shall provide a personalized experience to the user.
Bring in things like U-prove and that site doesn’t need to know the exact data but can “ask” the Identity Provider about relevant aspects and retrieve a yes/no decision. For sure the service provider/relying party in that equation will know some things but the amount of this knowledge can be limited – and thus privacy can be maximized.
I’m convinced that there is a business model for Identity Providers. Users might pay for a trustworthy handling of privacy information. Relying parties might pay for the ability to personalize information. There might also be approaches where the service is for free but the privacy is limited – the relying party might pay more if she learns more about the user. Both approaches might work.
VRM fits perfectly into this. It is the use of these approaches for vendor relationships, providing information for buying decisions via Infocards. For me, VRM, infocards and technologies like U-Prove are the pieces of a puzzle which, when ready, shows personalization and profiling as the picture.
29.04.2008 by Martin Kuppinger
One of the newer topics in Identity Management is the Enterprise Entitlement Management. This term describes approaches for a centralized management of the low-level entitlements (e.g. access controls) on system level from a central perspective.
That seems to be pretty complex. How shall you ever manage file server ACLs from a central tool in an efficient manner? Or other tools? Yes, it isn’t that easy to solve. But bring in services and you’re much closer to a solution – not only for entitlement management, by the way.
Think about abstracting file server resources as services (which is, by the way, not that different from shares in the Windows world). Users will understand services – a service provides the ability to store and retrieve their contracts or their personal files or their blueprints or their drafts of new marketing materials or… A service is simple to manage from a security standpoint: No access, read, write, do everything – or something like that are the relevant rights.
Services are easy to handle in accounting. Their might be restrictions like quotas applied on the service level. And managing entitlements on that level is not that complex – that can be mapped to concepts in the Enterprise Authorization Management pretty easy.
You might argue that the file system still has to be locked down. No problem – as long as you can access it only through services. There might be different overlapping services for the same resources. Administrative shares in Windows are one example for that. If that isn’t sufficient, you can still use ACLs – and the services might act as specific operating-system services which bypass that security level or (like today in Windows) combine their security settings with the operating-system level settings. The latter is pretty complicated and somewhat overengineered. From my perspective, a consequent service approach might be sufficient.
To add some web services for file system access might be helpful – but it isn’t mandatory. A service is not necessarily a web service. In fact, everything you need for such an approach is available. Some things might be improved. But with a service-focus for file server services, security is easier to manage and to audit.
29.04.2008 by Martin Kuppinger
One of the panels at the recent EIC 2008 on End-to-End Security for SOA applications there was a discussion about whether this target could really be achieved. One comment was that built-in federation awareness in every single web services won’t work with thousands of web services you might have today or in future. The handling of trusts would be too complex, was the argument.
Yes, if you handle every trust separately. No, if there is sort of a trust broker for at least most of the web services which provides a standard trust with no specific configuration per web service. In that case even that concept might work – and federation-enabling web services could be done by the application these services run on.
But it can be done easier, in the context of Web Service Security applications or other approaches. My position is that a web service has to run in the context of the user’s identity. Usually the context will be derived, e.g. a role, a group or something else. A layer like the Web Service Security should be able to work with such a context, which might be provided within a SAML token. But, in general, it might be any type of claim – Kim Cameron’s concept of claim-based security fits in pretty well here.
In fact, the issue can be solved very easy: Take the information in a claim or assertion, transform it to a parameter and invoke the web service based with this parameter. Then the web service can return exactly the information which is relevant (or allowed to see) to the identity the parameter has been derived from. The application infrastructure has just to work as a special type of STS (Security Token Service) which transforms security tokens into parameters for web services.
With this approach, it is as well possible to completely implement the idea of claims into SOA security. The accounting of web services works as well, because the platform from which web services are invoked knows about the identity (or something derived from), because it knows the claim or assertion. And the web service itself can be fully identity- and federation-ignorant.
In fact, there is no reason not to implement a real end-to-end security, either with Federation and an efficient trust handling or with a claims-/assertion-/parameter-based approach like described.
27.04.2008 by Martin Kuppinger
Yes, I know – it is a little redundant talking about “corporate” and “business” in the context of virtual cards. But it is one of the most obvious, interesting and feasible business cases around Identity 2.0.
What do I mean by that term? My idea is about applying the ideas of Identity 2.0 and especially of InfoCard to the business. Provide every employee with an InfoCard or even some of them and you are better suited to solve many of today’s open issues.
How to issue these cards
I have this in mind for a pretty long time. I remember that I had asked Don Schmidt from Microsoft about the interface between Active Directory and CardSpace some time before EIC 2007. Active Directory might be one source of these cards. Just provide an interface between AD and an Identity Provider for InfoCards and you are able to issue and manage these cards based on information which still exits in the Active Directory. For sure, any other corporate directory or meta directory might work as well.
Today these technical interfaces are still missing, at least in an easy-to-use implementations. But it won’t take that long until we will see them. Thus, it is time to start thinking about the use cases.
How to use these cards
There are at least three types of cards I have in mind:
- Virtual business cards: They are used when someone represents his company. How do you ensure today that every employee provides current and correct information when he registers with other web sites? How do you ensure that he acts in the web like you expect him to do? How do you ensure that he enters the correct title or the correct information about the size of your business when registering? InfoCards are the counterpart to your paper-based business cards today, but they can contain more information. And there might be different ones for different purposes.
- Virtual corporate cards: They are used for B2B transactions and interactions. Add information like business roles to the cards and you can provide all these claims or assertions which are required for B2B business. These cards can be an important element in Federation, providing current information on the role of an employee or other data required. For sure there can be as well several cards, depending on the details which are required for interaction with different types of business partners.
- Virtual employee cards: They are used internally, for example to identify users in business processes. Again, there might be a lot of information on them, like current business roles. You might use them as well to improve internal order processes, identifying the users who request new PCs, paper, or what ever else.
With these three types I might even have to extend the name for the cards, I assume. But I will stick with the term I have in the title of this post. The interesting aspect is the flexibility which (managed) InfoCards provide and the ability to manage them in context with a leading directory you have.
Due to the fact that you are the Identity Provider when applying these concepts you can ensure that no one uses these cards after leaving the company. You can ensure as well that the data is always up-to-date. That’s by far easier than with some of today’s equivalents for these future type of cards.
I will blog these days about two other ideas I have in mind in this context: The way the concept of claims Microsoft’s Kim Cameron is evangelizing will affect end-to-end security in business processes and SOA applications in general and the idea of using InfoCards for all these personalization and profiling ideas which have been discussed many years ago. I’m convinced that Identity 2.0 concepts like InfoCards and claims are a key element to solve these threats and bring these things to live.
There is a lot of business value in these concepts. And they will affect the way businesses cooperate, because they are much easier to implement and use than many other approaches.
10.04.2008 by Martin Kuppinger
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.