Why is IBM TIM 5.1 just a minor release?

24.06.2009 by Martin Kuppinger

IBM yesterday has announced its Tivoli Identity Manager 5.1. If you read the list of new features you might end up with the same question like me: Why is it only version 5.1, e.g. a minor (.1) release instead of TIM 6? Amongst the new features are fundamental things like Role Management, SoD support, attestation and, last not least, support for some Privileged Account Management (or Privileged Identity Management, the term IBM is using). With other words: IBM has significantly expanded the feature set of its product, mainly adding a lot of IAM-GRC features to what TIM delivers. Given that they have some other interesting solutions in the GRC space, especially for analytics and dashboards, IBM definitely improves its positioning in that emerging market segment.

So the GRC stuff is one of the new areas in TIM 5.1. That’s nice, but we have seen that before. Many vendors have either added such features to their products or have released separate GRC platforms – with advantages and disadvantages in both approaches. IBM in fact has tied in that area.

Much more interesting is the addition of PIM capabilities to a provisioning solution. Even while not every aspect of PIM will be solved by what TIM 5.1 delivers, that fulfills my expectations of PIM becoming more and more part of provisioning tools – which is just logical, given that it is about managing accounts. IBM is the first vendor in the market who delivers an integration in that area. Novell might become a close follower given that they have recently acquired a PIM vendor.

With these additions, IBM would have gould reasons to name the release of TIM as version 6.0 instead of 5.1. But understanding the reasons for version numbers is definitely amongst the hardest things in IT.

However, IBM shows that they are intensively acting to improve their positioning in the IAM and GRC market space. Being one of the first big companies which had entered that market, there hasn’t been that much evolution for some time. But now IBM is definitely back and moving forward significantly, acting as a strong competitor for the other players in the market. And once they deliver on full GRC solutions, beyond IAM-GRC and access controls (and IBM is amongst the ones who might deliver on that given their strengths in areas like SIEM, ITSM, and others…) IBM might even further improve its positioning.


Getting Attestation Right

04.03.2009 by Martin Kuppinger

In a webinar this Thursay (March 5th) I’ll talk about my thoughts about attestation, with focus on approaches that as well provide quick wins as are valid from a long-term perspective. What I currently observe is that attestation is sold as sort of panacea for all GRC issues. What is true is that attestation is important. But some approaches might only provide a positive feeling without much real impact. I frequently miss the support of multi-layered attestation which really covers all levels of IT security. I also frequently wonder about what happens after attestation. It is fine to do attestation – but

  1. the results should lead to actions
  2. these actions should be automated whereever appropriate
  3. attestation shouldn’t be a singular event but has to be part of a concept which ensures a continuous high level of proven entitlements

Attestation is a part of an overall GRC strategy and attestation has to be integrated into a risk management strategy.

It is important to have a clear view on the limitations and the prospects of attestation – to invest in the right tools and to build the right concepts. Participate in the webinar or listen to the recording we will publish close to the webinar! And, by the way: Our European Identity Conference will as well provide a lot of information on attestation and GRC in general – not only on IAM.


Posted in Attestation, GRC | Comments Off

Going beyond attestation: Authorization Management is key

03.02.2009 by Martin Kuppinger

There is no doubt that the attestation capabilities which can be found in many of today’s IAM-GRC platforms (e.g. GRC platforms with focus on Identity and especially Access Management aspects) are important and helpful. Attestation provides a capability to go through existing entitlements and, in some cases, changes and confirm or revoke them. But: Attestation is mainly sort of a detective approach. There are two other aspects which have to be addressed as well:

  • Preemptive controls which avoid that there is any access right granted which later on has to be revoked
  • Controls in the sense of really managing and not just auditing

That is where active Authorization Management comes into play. In my definition, Authorization Management defines the approaches to centrally manage authorizations in underlying systems. In best case it ends up with the management of specific entitlements (that would really be “Entitlement Management”), in most cases it is only the capability to map users (using roles and so on) to system-level roles or groups or profiles. Better than nothing… In fact, most GRC solutions are limited because the provisioning solutions used are limited as well. There are only few products which can granulary manage entitlements at least for a few target systems.

But at least using higher level policies (and thus rules) and business roles to manage authorizations, e.g. in most cases controlling provisioning systems, is a huge step forward – even more if the GRC system can use the reconciliation capabilities of provisioning solutions to detect issues on the fly and not some weeks or months later when next time going through the attestation process (that might be too late – the money might be at some strange caribeean island at that point of time).

Anyhow, the big gap of provisioning still remains. Provisioning (or GRC) are in control down to the assignment of users to groups/roles/profiles in the target systems. But what these group, roles or profiles are allowed to do is managed by someone else – the operator/administrator of these target systems. You should always keep that in mind, because it is the reason why we will need not only one level of attestation but a multi-layered attestation, starting with the sysadmin who confirms that groups, roles, or profiles still have correct access rights at that level.

There is another interesting aspect of Authorization Management: Dynamic Authorization Management. Most of today’s approaches are static, e.g. they use provisioning tools or own interfaces to statically change mappings of users to groups, profiles, or roles in target systems. But there are many business rules which can’t be enforced statically. Someone might be allowed to do things up to a defined limit. Some data – for example some financial reports – have access restrictions during a quiet period. And so on. That requires authorization engines which are used as part of an externalization strategy (externalizing authentication, authorization, auditing and so on from applications) which provide the results of a dynamic authorization decision, according to defined rules, on the fly.

Today, in most cases companies rely on a single-layer attestation – which isn’t sufficient. They have to move to multi-layered attestation, to static authorization management and to dynamic authorization management. And vendors will have to enhance their products significantly to support every aspect. There is still a long way to go for IAM-GRC vendors, not even talking about extending GRC platforms to SIEM, BSM, and other aspects.


The need for multi-layered attestation…

05.12.2008 by Martin Kuppinger

One of the issues I discuss most frequently in these days is attestation. I talk with vendors, with integrators, with auditors, and with end-users. Especially when talking with vendors, it appears to me that – again (I’ll talk about that later) – frequently a light-weight solution is sold as the biggest thing since the invention of the wheel.

Why light-weight? Many of the offerings for attestation support only one level of attestation. That’s not enough (see below).

Why again? That directly leads to the problems of many of today’s attestation solutions. It is about the (often concealed) biggest shortcoming of most of today’s provisioning solutions: They only provision partially. If a person “Martin Kuppinger” is new, there will be a identity for him. And there will be accounts like “MartinK” in the Active Directory. And “MartinK” might be assigned to the group “Finance”. Done. At least for the provisioning system. And that system can even reconcile that “MartinK” isn’t a member of “Finance” any more.

But: What is the group “Finance” allowed to do? That is defined by someone else. The administrator of the Windows environment – and sometimes several admins, because AD and different file servers are managed independently. What happens if some access control entries for “Finance” are changed? Some admins will know about that. But the guys responsible for the provisioning system? They will learn about that only if some well-organized manual processes are set up (or a system which tracks these changes). But at least the provisioning system won’t know anything about that change.

With other words: There is a predetermined breaking point between the provisioning system and the system level. Interestingly, by far most of the end-users I’ve spoken with about that within the last few years haven’t ever heard about that – neither from vendors nor from integrators.

You can complain that it isn’t that easy to manage ACLs. Agreed. But then you have to address this issue in another way (by the way: The problem affects auditing as well – but it is easier to read all the details from the provisioned systems than to control them).

The way to address this is multi-layered attestation: The system administrators have to attest their systems. The “identity manager” have to attest what they are doing at the provisioning level. At the departmental level, there has to be an attestation of the correct assignment of business roles and so on. There might be more levels – but there will always be more than one level. Also the linkage between the layers has to be attested. Thus, attestation is far more complex than it is told today by some people.

For sure you can start at some level. But you should always be aware of the shortcomings – the most important one being that as long as you haven’t implemented a consistent attestation approach from the business level down to the system level, you’ll never know about potential access control problems in your systems.


© 2015 Martin Kuppinger, KuppingerCole