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.

Another acquisition in the IAM and GRC has been announced that weekend. CA decided to buy Eurekify, a role management specialist with specific strengths in role mining, based in Israel. That adds to the recent acquisitions in that field, like Sun with Vaau or Oracle with Bridgestream. The CA/Eurekify deal is somewhat special because Eurekify has been more focused on pure role management than Vaau or Bridgestream. Thus, there won’t be much overlap to CAs current portfolio.

The acquisition proves that CA is willing to invest in the IAM and GRC markets. There has been some time after the acquistion of Netegrity where we hadn’t heard that much from CA - but with the R12 release of their Identity Manager, with focus on integration of own and acquired technologies, and now the acquisition of Eurekify, CA is definitely back in the game.

From a market perspective, the acquisition is pretty interesting. First of all, the opportunities for other players in the market to become acquired are less than before. On the other hand there are still some few big players which might to invest in role management and GRC specialists.

On the other hand, there are some new options for companies which are strong in role mining - like the swiss IPG AG or the italian Engiweb. Eurekify had many partnerships with Identity Management vendors. I don’t expect other vendors to stay with Eurekify now that it is CA. Thus, some vendors will have to choose new partners in the not that long list of Role Mining and Role Management specialists (or, in the case of Engiweb, vendors that support Role Mining/Management amongst other functionalities).

Within the last days I tested several solutions for backup and storage in the so called “cloud”, e.g. by service providers in the Internet. I learned some interesting things:

• Backup in the cloud is amongst the most mature cloud services
• At least in some cases
• There are still some weaknesses, including performance, platform support, and costs
• And few vendors provide a strong ITIL and SLA support
• And, like with all other cloud services, backup in the cloud requires a clear “cloud strategy”

If tested solutions of different vendors, as well local players in Germany and Switzerland as international vendors like Mozy. The best one I’ve tested was a local supplier in Switzerland, with a very detailed description of its service, comprehensive forms for SLAs and so on. And with a strong technical foundation, supporting virtually any type of operating system.

But, in general, most service providers I’ve tested delivered a reasonable solution for backup and restore, with easy to use software and very simple setups. These were sufficient for the home user and may be for small business. But at the level of medium-sized businesses, many of these solutions aren’t sufficient. No support for a central management of multiple servers is one of the typical shortcomings.

One of the issues is performance. With ADSL, backup always is relatively slow - at least compared with disk-to-disk backups. Compared with tapes, it isn’t that bad… A bigger issue was, in many cases, the platform support. Some solutions were Windows only, other didn’t support 64-bit versions of Windows Server. That is one of the aspects which always should be evaluated. Another aspect is the pricing. Some solutions started very low but backing up a few 100 GB - not uncommon today - was pretty expensive. Thus, prices should be calculated for expected amounts of backup data to compare different license models.

The documentation of services was often pretty weak - which is an issue if backup in the cloud becomes a vital part of the business continuity concept of IT. It is worth to talk with the vendors about this. For sure you can argue that you could just use two different providers for “failover” - but even then you should ensure that both provide a high quality of service.

Finally, backup in the cloud requires trust to the vendor. You should think about that. Whom do you really trust?

Besides this, backup is only one element of cloud strategies. The more services you use from the cloud, the less you have to care about backup, because that should be part of what the service provider delivers. Thus, long-term contracts might be a lock-in when more services are sourced from the cloud. In general, I strongly recommend to first define a cloud and virtualization strategy and than to start even with basic services like backup in the cloud. Even while backup is easy to implement, you should have a defined list of requirements for your cloud service providers.

This morning, I had two conversations on the question about who should be in charge of IAM in an organization. Afterwards, I run through my records and did some analysis. The main question: Which role do the IAM and GRC responsibles have in their organizations? I for sure only did a sample and asked myself the question how I’d rate what they were doing.

First of all: There are many good IAM implementations driven by IT administration or IT infrastructure. But, interestingly, the most advanced implementations, with a scope beyond administrative IAM, are usually driven by others - Compliance officers and GRC departments, CIO offices, CISOs, and others. Anyhow, an administrative project might have as well a strong strategic background if done correctly.

What is much more important is that there are approaches which are likely to lead to solutions with a too limited scope, especially in these days of increasing GRC requirements. Amongst these are

• Projects with a strong IT service focus: IAM and GRC go well beyond IT operations and the automation of service desk requests. Business control, the implementation of business roles and rules, and new business models which integrate external users and make use for example out of the technologies of user-centric Identity Management might not be considered in a sufficient way. Not to talk about application security concepts.
• Projects with a strong security focus: Yes, IAM and GRC can improve security. But they are not only about security, but as well about business control and, in general, Business/IT alignment.

My expectation is that GRC platforms will become the business control layer for IAM, like mentioned in our new reports “IAM and GRC roadmap 2009″ and “Trend report IAM & GRC 2009″, both available at http://www.kuppingercole.com/reports.

In that context, the responsibility for at least the IAM strategy has to be at a level with a holistic view, e.g. the GRC responsibles like a Chief Risk/Compliance Officer or the CIO. The execution of different parts, in alignment with that overall strategy, will than be for example at the IT operations department. But, if the question is “who should be in charge of IAM?”, the answer clearly is that it has to be someone who has a broader view on IT. IAM is tightly connected to BSM. It is tightly coupled to GRC. And there are no secure applications and business processes if the relation between application architectures and IAM isn’t fully understood.

Have you ever heard about Rohati? You should have. They are definitely amongst my list of really interesting vendors in the Identity and Access Management market and the overall security market. And they are on the way to provide a real alternative to todays complex, cost-intensive and still error-prone approach for managing access controls at file servers. They don’t end there but provide as well interesting features for controlling the access to web applications - but the part I like most is the one around CIFS/SMB (Common Internet File System/Server Message Blocks) and access control for file systems.

Rohati is a start-up which provides appliances to enforce access controls (or authorizations) at the network level. They are one of the currently few vendors in the new segment of “network based authorization management” or “network based entilement management”. All the traffic is analyzed by their appliances. This analysis supports every layer up to layer 7, e.g. the application layer. The CIFS support will be ready soon, currently being in beta.

Enforcing access controls at that level provides several advantages:

• At that level, one consistent layer of policy definition and enforcement can be defined.
• Changes in policies are easy to implement. It is, for example, pretty easy to secure some shares with financial statements in lock-up periods. That is by far easier to implement and enforce with the Rohati policy-based approach than at the ACL level of Windows servers, where it would require two explicit changes of the ACLs at fixed dates.
• There is one point of control, instead of different ACLs at different servers.
• Windows and Samba servers can be managed together.

The Rohati appliance acts in the context of the user, e.g. it requires authentication. But Rohati supports for example Kerberos, thus the authentication in Windows environments works seamless in the background, transparent to the user.

Today, the management of ACLs as well at the file system level as at the share level often is a nightmare - for both administrators and auditors. Managing ACLs consistently, according to defined business rules, across many servers is pretty complex and definitely error-prone. With the Rohati approach, there could be a layer in front instead of the system-level management of ACLs.

For sure, the information still has to be shielded for the ones who access servers locally. But all network access could be controlled centrally.

Usually, I’m no friend of solutions which operate as an additional layer in front of existing systems. But in that case, I think it is really worth to have a look at. Whilst Rohati in enforcing authorizations for web applications is more or less competitive to existing software-based Web Access management solutions, the CIFS support provides entirely new options for authorization. That approach might take a lot of burden from system administrators and help to avoid errors in authorization management.

I even could imagine that such a policy-based, centralized model for authorization management might significantly influence what Microsoft is doing at the operating system level for a next-generation windows server and file system. There are some lessons Microsoft could learn from Rohati and adopt at the OS and software level.

Some few weeks ago, Quest announced the acquisition of NetPro. The product portfolios of both companies overlap in many areas. A few days ago, Quest presented the “product rationalization roadmap” which now explains how Quest will deal with the areas of similar functionalities.

There are many products which will be discontinued - from as well NetPro as Quest. Quest has thoroughly analyzed the overlaps in the now combined portfolio and consequently decided for the more advanced solutions. In consequence, several of the current Quest products will be discontinued.

From a customer perspective, the (consequent) decision for streamlining the product portfolio could impose the need for a migration to a new product. Even while this mainly affects administrative tools which are used by a relatively small number of relatively experienced users, that is an effort. At least the change will not require acquiring additional licenses despite the fact that Quest and NetPro had pretty different licensing models.

What might be a real problem is that Quest will discontinue the products by the end of 2009. That is a very short time frame even while only administrative tools are affected. I could imagine that customers will ask for a prolongation of that time frame.

Quest, by the way, benefits from providing a broad range of separate products instead of a tightly integrated suite of tools. They don’t need to adopt the architecture and user interfaces of all the NetPro products which are continued but they could just decide which of the current NetPro and Quest offerings provides the more advanced and mature functionality. In the (few) cases where both current products have specific strengths not supported by the other product they will have do implement that over time.

But, overall, there will be few situations where customers will have to migrate and will miss important functionalities. From that perspective, the roadmap is convincing. The roadmap as well proves that the acquisition was mainly a market share deal. The real issues are the need for customers to migrate and the short period of support for discontinued products. Besides this, customers might do a more detailed analysis for licensing schemes. The migration is free, but there might be some effects in maintenance fees which should be evaluated.

Recently, I had several discussions around terms like Access Management, Authorization, and Entitlements. And I thought about what is in the center – is it the identity or is it access management? Some weeks ago I mentioned in my blog that Hassan Maad, COO of Evidian, has stated that, from his experience, customers understand access while they have difficulties with the term identity. And when I go back some two years, there has been an intensive discussion of the so called “Identity Gang” about the term “identity”.

In fact, the management of access is the core business requirement. That is about authorizing access, it is about being entitled to do something. Thus, access management, authorization management, and entitlement management are terms which are used in the same context, with slight differences between them.

But: It is not only about allowing access, or authorization, or entitling. The questions are: WHO is granted access?  WHO is authorized to do something? WHO has which entitlements? There is always the “who”, the identity. With other words: These concepts are tightly coupled together. Authentication (proving the who) and Authorization (granting or denying access) can’t be separated. Which, by the way, becomes obvious when looking at the concept of federation.

And there are several other import aspects of the identity, including the approach of understanding core business objects as identities (and vice versa).

However, the concept of the identity is more theoretical and more complex than access, authorization, entitlements. Thus, it might be better to talk about “Identity and Access Management” instead of “Identity Management” – especially, because there are some technologies which are more related to identities and others more to access. At least until someone creates a better term which is understood by everyone and which replaces “Identity and Access Management”. GRC isn’t that term. But maybe someone has a good idea!?