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.

I think that is an interesting question. Compliance is a key topic for every organization, with many facets. Currently we have an intense debate about the Deutsche Bahn (railway) and other organizations which have for example compared the bank accounts of their employees with the ones of suppliers. The target is to avoid corruption. From a Corporate Governance perspective and from a compliance perspective (mitigating risks of compliance and so on) that is a valid approach. From the data protection law perspective, it isn’t that easy. There are obvious conflicts between different regulations.

What has this to do with the costs of compliance?

There is a solution to the conflict above which as well addresses the increasing costs for compliance (or, correctly, Governance, Risk Management, and Compliance). What has happened over the course of the years? Companies introduced platforms which help to address GRC requirements not only for a specific regulation but in a more standardized way. Even today, most of these GRC platforms aren’t complete. Some focus only on Risk Management (and within that, only on IT Risk Management or Enterprise Risk Management). Others support only specific system platforms, like ERP systems. Some support mainly attestation, but don’t focus on the counterpart, e.g. authorization management. But, anyhow, all these approaches try to consolidate GRC efforts.

The key value proposition of these platforms are reduced implementation costs, lower costs for fulfilling compliance regulations, and a consistent view on different regulations and their fulfilment. Reducing the costs of compliance is one of the main reasons for the success of these tools. On the other hand, the view on different regulations is what we need for the problem I’ve talked about at the beginning. If there are conflicts between regulations, they have to become visible. Then organizations can decide about the conflict. GRC platform approaches – at least the ones which really allow describing regulations and the resulting tasks and business rules – thus can help not only to reduce the costs of compliance but as well to deal in a structured way with conflicts between different regulations.

Currently, most of the GRC tools lack a good support for describing regulations, the associated policies and breaking this down to business rules and IT rules. But I’m convinced that we will see as well an increasing number of standards for such policies as an improved tool support within the next two or three years. That helps to deal with all the different regulations and at least to keep compliance costs under control despite a growing number of regulations.

We will have two Kuppinger Cole webinars this week which are related to the question above. One is on Thursday, 5pm CET, and has the title “Reducing Compliance Costs through Risk-Based Segregation of Duties Management“. The other is on Friday at 3pm CET, in german language, and has the title “Zehn Gründe, warum Sie gerade jetzt in IAM und GRC investieren sollten.” (Ten reasons to invest in IAM and GRC especially in these days). Both deliver some answers to the question I’ve started this blog entry with. More discussions around this topic will take place at European Identity Conference 2009.

There is no doubt: We are in economic turmoils. And no one really knows when things will become better again. It is definitely interesting to observe what is happening from a risk management perspective (Why didn’t governments have pre-defined actions prepared? Why didn’t financial institutions understand the risks or, if they understood them, why were they willing to take them? What happened with all the positive cash-flow of many organizations which are now in trouble – too much dividends?). But that isn’t my topic here. The topic is why organizations should invest in IAM and GRC – especially in these days. From my perspective, there are good reasons. And, from what I hear from vendors, especially the GRC market is still very strong, as well as at least many segments of the IAM market.

From an enterprise perspective, investments in these days should be even more focused on business value than in good days – maybe a little bit more on short-term values than before. Regarding IAM and GRC, there are – for sure – the negative inhibitors. Auditors might mandate some investments especially for SoD management, PAM (Privileged Account Management), and defined, auditable Identity/Access/Role Lifecycle Management.

But there are as well positive aspects. To name just a few:

• Using clearly defined role concepts reduces the amount of single entitlements which have to be managed, thus reducing the overall administrative workload.
• Management by risk is sort of “management by exceptions”, focusing on the aspects which are really at risk. That’s more efficient, for sure.
• Any initiative in the area of IT risks supports Operational Risk Management. Any IT risk is, in fact, tied to an operational risk. On the other hand, virtually any operational risk is related to IT risks because IT systems are used to run the business. Very easy: Why do we talk about SoDs? Because of IT? No – because of business.
• IAM and GRC are key to the flexibility of IT and to support changing business requirements, especially in industries which have to react fast on changing customer demands (and who hasn’t)? Changing business processes requires a flexible security and identity infrastructures as well as flexible controls – that’s what IAM and GRC are providing. Some BPM and non-IAM-aware SOA approaches aren’t sufficient.

I’ve blogged also several times about the CIO agenda. It is obvious that from the things which are top at the CIO agenda, many are tightly related to IAM and GRC. Any initiative towards cloud computing requires a strong IAM and GRC backing, because IAM and GRC will become much more complex when using as well internal services as cloud services.

These are just some few reasons. IAM and GRC are an important foundation for any enterprise IT. And you shouldn’t build your IT on sand.

We will have some webinars around these topics. The first one will be in German language, naming 10 good reasons to invest in IAM and GRC. You can register now. We will do the same webinar in English some weeks later and additional webinars on how to do lean, focused IAM and GRC projekts as well. Another interesting place to learn about these topics is, for sure, the 3rd European Identity Conference held in Munich May 5th to 8th. The place to be!

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.

These days, we’ve been mentioned by Marcus Lasance, an independent IAM consultant who formerly managed MaxWare U.K., in his blog. Dave Kearns commented on this today in his Network World newsletter. Both, Marcus’ blog and Daves newsletter were about IAM in Europe – and the fact that there are many more vendors and integrators out there than are visible at first glance. And yes, Kuppinger Cole as an analyst company covers them, but isn’t limited to them – for sure we are in touch with the US vendors and companies from other countries (for example Brazil, Australia,…) as well.

My personal opinion is that there are two really important aspects in choosing a vendor: He must be able to deliver to the customer. That might be a limitation – as well for US vendors in Europe as vice versa (and for any other regions). And his product must fit the requirements of the customer. That might favor local vendors which support local regulations, local languages, or just are in sync with concepts and methodologies which are used in specific regions. But there are as well European vendors acting successful on a global basis as (more frequently) US vendors being successful in Europe.

Overall, I fully agree with Marcus and Dave that it is important to consider all choices. Big vendors can be the perfect choice – as well as smaller local vendors. But you will only know when you consider all choices. By the way: There are as well European vendors which don’t fully convice me – and no one provides a solution that fits to any use case, for sure. To support the decision, we’re constantly providing reports for vendors from all over the world. There will be, by the way, several new and updated reports about European vendors within the next three weeks, including companies like Beta Systems, BHOLD, Engiweb, Evidian, G+D, Omada, SAP, and Siemens, to name just a few – complementing the available series of reports which as well covers companies like IPG and Völcker.

GRC (Governance, Risk Management, Compliance) is frequently reduced to IAM (Identity and Access Management) or, in best case, to a more business-centric layer on top of IAM infrastructures. In our research and publications around GRC we’ve pointed out that GRC platforms will have to go well beyond IAM – SIEM, BSM (with aspects like business continuity), and other areas will have to be covered.

If you ask the question the other way round, that becomes more obvious: What are the controls that business requires from IT?

That question is, from my perspective, the core question for the selection as well as the conception of any GRC platform. There are GRC aspects outside of IT but even these have to be managed in a consistent way, thus such a platform has to support them. Within these controls, risk controls are amongst the most important ones. I’ve recently blogged about the need for an integrated Risk Management. Risk controls cover many aspects, including the fulfillment of compliance regulations and business continuity.

The breadth of a GRC platform becomes visible if you take (still IT-driven) for example ISO 27001. ISO 27001 includes a huge number of controls, with many which are neither IAM-related nor can any IT system automatically provide the status information. Even more, to provide the current status for these controls, many different IT systems have to deliver – IAM, SIEM, and many more. GRC platforms will have to support any type of control. They will have to support the ability to report manually as well as automated. And they will have to support interfaces to many lower-level systems.

The controls, on the other hand, will have to be multi-layered, supporting at least a business view (“Are the core security requirements met?”) as an IT view (“Are we in compliance with all the controls described in ISO 27001?”). The business layer is sort of an abstraction of the IT view.

There are several lessons we should learn about GRC platforms:

• We should understand them as the overall interface for business control (thus being bi-directional) of IT
• We should position them in that way, looking at them from the business perspective and the questions business likes to get answered
• We should understand that this includes many different technologies, well beyond IAM (but with IAM and the “access control” part of it being highly important)
• We should work on standards which support the interaction with existing and new IT systems

It is still a long way from today’s different approaches in the field of GRC to such GRC platforms. But the outline for the future of these platforms is set – and it will be filled more and more. By the way: When we add the accounting capabilities to this picture, we end up with the “ERP for IT“…

During the last month’s research I frequently ended up with thinking about IT organizations – as well the organization of IT itself as the IT as part of the overall organizational structure, including the role of the CIO. There is, from my perspective, no doubt that fundamental changes are required.

Let’s start with the IT organization. Early in 2008, we’ve done a survey and report on the topic of “SOA Governance” together with Ernst & Young (the German subsidiary) which we first time presented at EIC 2008 (by the way: EIC 2009 will be again in Munich, May 2009 5th to 8th, hope to meet you there). The most important result was that the main problem of SOA Governance and, as part of it, SOA Security are the missing application security infrastructures, e.g. standardized approaches for securing applications. The reason for that is as well very obvious: Siloed IT organizations. Read the rest of this entry »

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.

OK, that sounds a little provocative. And it should. But in essence, it is true, at least as there is no need for a IT-only Risk Management. What we need is an integrated Risk Management, which covers “enterprise” risks and IT risks. Why?

Let’s start with the types of risks. Risks might be divided in three categories:

• Strategic risks, e.g. the risks of wrong (strategic) decisions, like entering a market with products no one wants to buy, changes in the market themselves and so on.
• Operational risks. That is what the vendors of ERM tools (Enterprise Risk Management) usually name “enterprise” risks, to distinguish from the (from their perspective) low-level IT risks. Operational risks are the risks in day-to-day operations, from trading with stocks and derivatives to guarantee risks when producing goods.
• IT risks. These are risks from the perspective of IT systems, e.g. from non-working IT systems to missing access controls and Segregation of Duties.

But if you analyze IT risks, you will always end up with operational risks. IT risks are a part of operational risks. On the other hand, virtually any operational risk is tied to an IT risk, because most operations in organizations heavily build on IT and IT can help in managing, measuring, and mitigating operational risks – like it is frequently done with approaches like attestation and SoD controls.

That leads to the question why we should buy IT Risk Management solutions – and, the other way round, why we should buy Enterprise Risk Management solutions that doesn’t cover IT risks. And, unfortunately, there are several vendors out there which sell (sometimes pretty expensive) solutions for Enterprise Risk Management which aren’t (at least not without intensive use of professional services for custom interfaces) able to manage IT risks as well because they don’t enforce policies on the IT system level and because they don’t consume status information for current Key Risk Indicators. IT Risk Management, on the other hand, often doesn’t sufficiently support the business view on risks (e.g. the “operational risk” perspective).

There is some reason for all these tools: They are better than nothing. And even better than just using spreadsheets. But, overall, they don’t really solve the problem. And, even worse, the customers might think that they’ve done their job while still being at risk.

What we need is an approach for integrated Risk Management, adding an enterprise perspective to IT Risk Management or vice versa. Given that there is only an artificial distinction between IT risks and operational risks and, in reality, we are dealing with one type of risks, we can’t rely on tools which try to dfferentiate between these risks. You might argue that Enterprise Risk Management is for business users whilst IT Risk Management is for IT. But that isn’t a valid argument. You still need consistent policies and it are still the same risks. There might be tools at both levels with tight integration, but to claim that you can solve your Risk Management threats with either one of the levels isn’t true.

I’m convinced that the market for Risk Management will change, providing much more integration, with IT Risk Management vendors moving to the business level and Enterprise Risk Management vendors, probably through acquisitions and partnerships, will provide integrated support for IT Risk Management.

Until then, you should carefully review the vendor’s promises. Do they really solve the problem or do they just give you a better feeling? And, in case you decide for one of today’s incomplete offerings, you should be aware of this and understand this as just a step towards Integrated Risk Management.

I had a very interesting briefing with one of the vendors for Privileged Account Management today. Like in most briefings, we also touched the current economic turmoil. The discussion we had convinced the expectations I have for the GRC and IAM markets: They probably will not be that heavily affected by the economic crisis than other IT market segments. The reason is simple – companies have learned that risk management is mandatory and the pressure on implementing a high level of GRC controls is increasing. Companies have to invest whether they like or not.

But in the discussion we came to the point that there is another relationship: The companies that have invested in Risk Management and related technologies, down to Privileged Account Management, are not that much affected by the crisis than the ones who hesitated to invest money in GRC.

My opinion is that the reason for this for sure isn’t that for example Privileged Account Management or even the more advanced generic IT GRC solutions prevent companies (like financial institutions) from going bankrupt. But companies that invest in these technologies have understood the need for Risk Management. And they are likely to have a strong, reliable Risk Management as well for operational risks. They decided to invest in IT GRC, Risk Management, and other technologies because they were risk-aware. The ones who didn’t invest were probably more sort of risk-agnostic.

For sure there are examples of companies in trouble, even with a strong IT Risk Management – and there are companies without Risk Management which still aren’t affected that much by the economic crisis. But most companies have understood the message: They need Risk Management, for operational risks as well as IT risks. That is the reason why there will be significant investments in these market segments. Either companies have to act because they are blamed for their faults in Risk Management – or they don’t want to become blamed.

By the way, for the ones of you capable of reading germans – today I read an article about a survey that found an inability of brokers to think logically. No surprise in these days, isn’t it?