My colleague Jörg Resch blogged today about the ignorance regarding layered security approaches. Yes, there is no absolute security. Security is something which is tightly related to risk. Given that we can’t have the perfect security, especially not with people using systems, it’s always about the balance between the security-imposed risk and the cost of risk mitigation.

That’s a very simple balance: The higher the risks are the more you can and should spend on risk mitigation – as long as risk mitigation is feasible (which is not always the case – a life insurance doesn’t help you mitigating the risk of dying…). I thoughtfully used the term “security-imposed risk”. It is NOT about security risks, but about the consequences of security-related incidents. Stolen data and their abuse, illegal transactions, customer loss due to a decrease in credibility,… – that’s what it is about.

But that doesn’t change the fundamental: When thinking about security we have to think about risks. I’ve blogged about Risk Management before. What we have to understand is that there is not THE information or system which has to be protected. We have different types of systems, information, and transactions which are at different risk. And we have to apply security (technology and organization) according to the risk associated with these different systems, information, and transactions.

There is not THE level of security you need. You need appropriate security for different types of transactions and interaction (and the related systems). Using risk as the main criteria in decisions about security investments helps to optimize what is done in IT security. And focusing on few consistent approaches at different levels (for example few different types of authentication with step-up features and so on, based on a versatile authentication platform; for example a consistent authorization strategy with few consistent levels of management and protection) will be much cheaper than spending too much money for point solutions like many (not all) of the DLP tools out there.

Understanding that different types of interactions and transactions have to be protected differently is the key to succesful IT security concepts. Risk is the core criteria to do that. Interestingly, that is not really new. What governmental and military organizations are doing in “information classification” (having started long before the invention of the computer) is nothing else than using risk as a criteria and definining different levels of protection for different interactions and transactions. Such concepts don’t have to be extremly complex. But a differentiated view has to be the guideline for everything which is done in IT security.

To learn more about this and to discuss this with your peers, have a look at our upcoming virtual conferences and our European Identity Conference 2010.

There is a constant pressure not only on IT but all areas of organizations to reduce costs. However, that frequently ends up with higher risks and potentially higher costs due to these risks. The problem is: Most organizations, especially in controlling and management, think much more about cost than risk. But cost savings (which are not necessarily negative) without a risk view are a risk – somewhat of a tautology, I know…

That is why Risk Management should be a standard and central element in management, as well for business as IT.

Read the rest of this entry »

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

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.

Today I’ve seen a blog entry which claimed that GRC is dead. That reminded me about the closing keynote of our European Identity Conference 2009 where I had a discussion with Paul Heiden of BHOLD Company about GRC. Paul claimed that GRC is just dealing with FUD (fear, uncertainty, doubt) and that there is no real business value in this.

So – is the market for GRC solutions (Governance, Risk Management, Compliance) dead before it really blossomed?

Yes, if GRC is limited to auditing, with focus on some dashboards and some information extraction for auditors.

No, if GRC is understood as something which goes well beyond this and isn’t limited to a narrow one-way-road. And that is how we understand the GRC market and how we have defined this market segment in our GRC Market Report 2008.

There are some real value propositions for GRC solutions, beyond “avoiding penalties” as the classical negative inhibitor:

• On the lowest level, one standardized approach to GRC issues tends to be more efficient than many point solutions.
• Much more important is the ability to not only audit but control – Enterprise Authorization Management (or Entitlement Management) is one of the key elements of GRC solutions, providing business control for the access to IT resources.
• This is, by the way, much more efficient than the granular, isolated management of access controls on lower levels. A relatively small number of business roles and rules usually covers a significant part of all access controls on lower levels in the infrastructure, down to the system level. These lower level controls can be derived, with some added exceptions.
• The probably most important aspect is that GRC done right enables a more efficient management, focused on exceptions. Defining and measuring risks provides this ability.

From our view, GRC has to be understood as an initiative which is at the core of Business-IT alignment. GRC has the potential to fulfill these (today in most cases unfulfilled) promises of building a link between business and IT.

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.