In a recent briefing with CrossIdeas, the MBO of the former Engiweb, an Italian software manufacturer in the area of Access Governance and Dynamic Authorization Management, they demonstrated an interesting feature: Doing recertifications based on relevance. Recertification of access rights is a key element of regulatory compliance. This is done frequently on a pretty standardized schedule. Doing this once or twice a year is the typical approach. For some specific systems or groups of users, we frequently see that the intervals are shorter, e.g. some risk-oriented approach is not uncommon. However, cynics might say that the main purpose still is to make the auditors happy.

CrossIdeas now has implemented an approach they name “relevance”. Based on several criteria like the number of SoD violations, the system identifies the most relevant users for recertification. Currently it supports six different parameters. The weight of these parameters can be easily changed using sliders. The least relevant users then can be removed – again using a slider – from the result set (a relevance map), leaving only the relevant ones in there. Then recertification can focus specifically on them.

This feature isn’t a full replacement for standard, regular recertification campaigns (which are supported by CrossIdeas IDEAS – the latter the name of their product) as well. Relevance is, from my perspective, a nice concept which brings value to customers because they can easily implement focused recertification campaigns for the most relevant users in addition to standard recertification. That then not only makes the auditor happy, but helps in better mitigating access risks. Not that standard recertification doesn’t help – but there is room for improvement and CrossIdeas has demonstrated an approach to do that which will be available in the new release due later this year.

Trust is a fundamental concept of today’s IT. Security is based on trust.

We have (or better: had, after DigiNotar?) trust that a web server which has a valid SSL certificate is the server it claims to be.

We had trust that RSA SecurID tokens are secure (whích they still are to some degree, but a lower than before).

We have trust that our authentication in the Active Directory is done in a secure way.

We trust the identity provider when using identity federation.

However, especially the first two examples raise the question whether the concept of trust still is a foundation to build on. On the other hand: Are there any alternatives?

I think we will further need to build on trust as a concept. There is no real alternative. However, we need to be much more careful regarding this concept and add to other approaches:

• Mistrust
• Risk

Mistrust means that we shouldn’t take things for granted. We might challenge “facts” – e.g. authentication decisions and so on. In fact, mistrust is not really new. We might check the URLs behind links which are suspicious – are they really pointing to eBay, PayPal or whomever they claim to do? We add additional tiers of authentication or stronger authentication mechanisms for sensitive interactions and transactions. But in the light of what happens these days, with more cyber-attacks and even the well-secured, experienced ones like RSA becoming victims of successful attacks, mistrust becomes more important.

That is related to the concept of risk. Risk relates to

• interactions and transactions performed and the information assets affected
• the level of mistrust and the “objective”, factual security risks

This relation is fundamental. We need to understand what could happen to our information assets (and the real assets behind them). And we need to understand how much mistrust we need. Based on that we can define what we need beyond the trust we might have today.

Technically, this leads to the need for flexibility and versatility. It’s not about a specific type of solution, it is about the ability to combine multiple technologies (for authentication, fraud detection,…) depending on the risks and the level of mistrust. The bad news however is: Mistrust will increase, trust will decrease, which will make it more complex to achieve an acceptable level of security for specific risks. And some of the concepts – like SSL – are obviously not sufficient by themselves to address today’s and the future’s security challenge. However: SSL++, e.g. SSL plus other approaches, might suit our needs. And approaches like the ones of convergence.io might help us as well in better rating the risks and applying the concept not only of trust but as well of mistrust. And, despite the mistrust we might feel for rating agencies in the finance world, having rating agencies for organizations like CAs we have to trust might be another approach.

Today, the next story about banks failing in managing trading risks hit the news. It remains unclear what allowed the trader to execute unauthorized (and thus most likely illegal) transactions which lead to that loss. However, the Risk Management of UBS obviously failed. By the way: UBS had to annouce that just the day the swiss parlament started a debate about new regulations for the finance industry.

It will be interesting to hear about why that could happen. Did some people co-operate? Did the risk management system specifically for that types of transactions fail? Or has it been an Access Management problem like at SocGen some time ago, where the trader was able to control himself? Whatever the reason is, the incident proves that there is still a long way to go in Risk Management and overall GRC – not only in the finance industry.

GRC is a key task for the C-level management. It needs sufficient funding. It needs support for the organizational changes, to build an organization with a high degree of process maturity and the understanding of the GRC requirements. It needs a strategic approach to integrate Business and IT to optimally support GRC, given that most business relies on IT systems and fraud in these systems causes the most severe harm. It needs an organizational and an IT-architectural approach to be able to manage different regulations and all types of risks in a structured and efficient way.

For the ones thinking about how to move forward in GRC, today’s KuppingerCole webinar might be worth to attend. It won’t answer all questions, but it will provide some valuable hints for moving forward in GRC. For sure, this is a long journey. But I strongly believe that it is feasible to avoid incidents like the one which happened now at UBS – and to mitigate the overall risks for organizations by a strategic GRC initiative (instead of point solutions).

Some days ago, a vendor talked at an analyst meeting about the relationship between virtualization and security. The argument was: At the hypervisor you can combine network security management, server security management and some other aspects of security management – I can’t remember everything. Thus virtualization increases security, because you have one point of control.

Right – as long as you can control what administrators and operators are doing. Unfortunately, that’s not the case in typical virtualization environments. There is no PxM (Privileged Access, Account, Identity, User) Management at all. And in that case, combining everything is a problem, a nightmare from a compliance point-of-view. For sure there is a value in having a single point-of-control, but only if you are able to adequatly control use of this.

I’ve asked the speaker about the solutions around PxM offered by that vendor – there weren’t any.

Without specific virtualization security solutions, PxM being one very important amongst them, there is a virtualization security risk. There is a potential of increasing security by using adequate technology, which is provided by several vendors. But claiming that there is a value of combining a lot of highly elevated administrative actions without being able to manage them doesn’t make any sense.

For a comprehensive overview on what customers expect around virtualization security just have a look at that survey.

And don’t forget to register for EIC 2011 and Cloud 2011.

There has been a lot of discussion around Wikileaks publishing an incredible amount of data which has been classified as confidential by the US Government. I don’t want to discuss this from specifically – many people have done this before, with fundamentally different conclusions. More interesting is what this means for private organizations, especially enterprises. Wikileaks has threatened some of them: The russian oligopolies, the finance industry in general. That comes to no surprise. Wikileaks founder Assange rates them as “bad”,e.g. his enemies. Given that Wikileaks isn’t alone out there, there is an obvious threat to any enterprise. Some might think that construction plans of the defense industry should be published. Others might think that should be done with blueprints from the automotive industry after claimed incidents. Or with the cost accounting of the utilities if power or gas appears to be too expensive. I don’t want to judge about the reasons – I have my personal opinion on this but that’s out of the scope of this post.

Looking at that situation from an enterprise perspective, it becomes obvious that information security has to move to the top of the CIO agenda (and the CEO agenda!) if it isn’t yet there (and given that the enterprise isn’t willing to share everything with the public – blueprints, calculations, whatever,…). That requires approaches which are somewhat more fine-grain than the once which obviously have been in place in the US government, allowing a private (or something like that, I’n not that familiar with the ranks in the US military) to access masses of documents. It also requires to efficiently protect the information itself instead of the information system only. Information tends to flow and once it is out of the system the system-level security doesn’t grip anymore.

That leads inevitably to the topic of Information Rights Management (IRM) which is a frequent topic in the blogs of Sachar Paulus and me – just have a look at our blogs. However, implementing IRM the typical way in organizations requires using centralized policies, classifications, and so on. And classification obviously failed in the last Wikileaks incident. Thus, I’d like to bring in an idea Baber Amin recently brought up in a discussion during a KuppingerCole webinar. He talked about “identity-based encryption” which in fact means encrypting it in a way which is controlled by the single user. That leads to an IRM where the single user controls who is allowed to use information he creates or owns. It is not (mainly) the organization.

But: Will that work? Some arguments and counter arguments:

1. Information is not accessible once the user leaves the organization: Not correct, there might be an additional “master” key to allow recovery and so on. Many lessons could be learned from Lotus Notes in that area, to name an example.
2. There are no corporate policies: Not correct, these could be understood as a second level of protection, adding to the first level managed by the user. E.g. classical IRM and personalized IRM could be combined.
3. It won’t work because the user doesn’t understand what to do: Not correct. Just look at how users are dealing with information security in their daily live. For sure some things are going wrong and lessons have to be learned (not to appear drunken on a photo in Facebook, for example), but overall that works pretty well. Combined with the corporate policies, that should turn out to be much better than corporate policies only. Trust the employee and the wisdom of crowds.

Simply spoken: Think about doing it different than before. It is not about adding new tools at the (perforated) perimeter and all these point solutions. It is about building few consistent lines of defense, including and especially the next-generation IRM. For sure there is some way to go and tools aren’t there yet. But when thinking about how to protect your intellectual properties and the secrets your organizations wants to have (for whatever reason – I don’t judge here…), you should definitely think beyond the traditional approaches of IT security – look especially at Information Security instead of Technology Security, e.g. the I and not the T in IT.

When you think that this topic is worth to think about, you shouldn’t miss EIC 2011 - the conference on IAM, GRC, Cloud Security and thus also about things discussed in this post. And don’t hesitate to ask for our advisory services

It is always nice when trends an analyst has predicted become reality. I’ve been talking and blogging a pretty long time about the need for an integrated GRC approach, especially beyond the isolated “Enterprise GRC” with little automation. Yesterday, IBM announced that they agreed to acquire OpenPages, one of the most prominent vendors in the Enterprise GRC space. That isn’t really a surprise, given that IBM is investing in the GRC market for quite a while. The really interesting parts in the presentation given by IBM on this acquisition yesterday are the parts where the Enterprise GRC layer of OpenPages becomes integrated with the IT GRC tools of IBM, as well Business Analytics as many Tivoli tools. With other words: It is about integrating different layers of GRC to provide a more complete and current (through automation) view on the controls.

That fits well into our expectations as well as to the KuppingerCole GRC Reference Architecture. Successful GRC is based on a mix of manual and automated controls. I remember a conversation with the OpenPages executives where they in fact denied the need for such an integration. Right now, becoming a part of IBM, that seems to change fundamental, because the IBM strategy is about this integration, with a strong layer on top for the executive view.

While some vendors like MetricStream are pushing this approach and others like RSA/EMC with their Archer acquisition in January 2010 have the same potential, it will be very interesting to observe how other “Enterprise GRC” vendors (I still believe that this is an arrogant term as long as these solutions ignore most parts of the enterprise and are mainly a high-level solution focused on manual controls with little integration into the different other GRC layers) will react. With the IBM acquisition of OpenPages, the time where a vendor can ignore the integration of GRC at all levels are past. Thus, this acquisition will heavily influence the overall GRC market and some of the more prominent “Enterprise GRC” players might end up at the loser’s streak.

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.