GRC platforms – more than IAM

15.12.2008 by Martin Kuppinger

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“…

Posted in BSM market, CIO agenda, GRC, IAM market, Risk Management | Comments Off

IT organizations have to change – for economic reasons!

10.12.2008 by Martin Kuppinger

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 »

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.

There is no need for IT Risk Management

01.12.2008 by Martin Kuppinger

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.

© 2015 Martin Kuppinger, KuppingerCole