Microsoft has introduced the concept of claims-based securitywith it’s “Geneva” project. Claims are sort of attributes which are provided by identity providers in the form of tokens and consumed by applications. In fact they are one way to make federation easier and more user centric. “Geneva” provides the tools at all levels to work with claims. The concept of claims is used by some other groups at Microsoft and we probably will see several Microsoft applications with support for claims within the next months.

However, the biggest impact might be on the Windows operating system itself. Claims could make that much more flexible from a security management perspective than today’s mainly ACL-based security model. ACLs are too static and too complex in management to really fulfill the customer needs today. Not only in Windows, but in other operating systems as well. If you think about an operating system which consists of services (Service Providers, Relying Parties) and relies on Identity Providers to provide claims, the entire Security Management can become much more efficient. Based on Policies, using dynamically provided claims. Authorization might be done by the services based on policies and claims or by specialized authorization engines within the operating systems on behalf of the services (the latter not yet being part of “Geneva”).

It is, without any doubt, not that easy to perform such a fundamental change. ACLs are at least somewhat understood, claims are new. There has to be a migration path and compatibility. But if we look at all the options we have, claims appear to be the most promising concept for the future security at the operating system level. One interesting side effect is that the same policies might be applied to other elements in the security infrastructure as well – external access management tools and so on.

Meet me at European Identity Conference 2010 and Cloud 2010 Conference, Munich, May 4th to 7th.

Authorization management is becoming increasingly popular. But there are, in fact, two very different approaches:

• Static authorization management, where changes are provisioned to the target systems.
• Dynamic authorization management, where authorization decisions are externalized to authorization engines at runtime.

The latter require changes to the applications, but they lead to the externalization of authentication and authorization (and hopefully as well auditing) from applications. Everything can be easily managed from outside of the applications.

Whilst static authorization management is provided by provisioning systems (at the more technical level) and by several GRC vendors (from a business control perspective), vendors of solutions for dynamic authorization management are still relatively rare and, besides this, in most cases relatively small. Besides Oracle with their Entitlements Server and, to some degree, CA with their Embedded Entitlements Manager, vendors include companies like Bitkoo or Engiweb, to name some of the two which are particularly interesting. And, for sure, Microsoft’s approach for claims leads in that direction – but at least in the current approach, authorization decisions aren’t externalized yet.

From my perspective, externalizing these decisions from applications definitely makes sense. Policies can be managed centrally, changes are effective immediately, and application developers don’t have to think much about security. They just rely on external decisions. In fact, things are moved from coding not only to deployment, but to runtime.

There are three challenges:

• The authorization engines have to be fast
• They have to be integratable with other IAM/GRC tools for a consistent management
• The applications have to be adopted to a specific solution

The first part is just an architecture and engineering task which has been solved by several vendors. The second requires, from my perspective, standards for the description and exchange of policies which are still widely missing. The third part could also be addressed by standards. That would give customers the choice between different authorization engines. As long as these standards are missing, customers should, with respect to the last bullet point, focus on implementations which require few changes in applications to minimize the risks of vendor lock-in. On the other hand, the advantages of such approaches are significant – and vendors like Bitkoo and Engiweb are succesful because of that fact.

From my perspective, companies should start looking at these approaches today and really start externalizing security out of the code.

By the way: We’ve given our European Identity Award in the category best innovation in 2008 to some of the vendors mentioned above. Attend European Identity Conference 2009 and learn, amongst many other things, who will be awarded as innovator this year.

The need for standards

Yesterday, news spread about the theft of millions of credit card dates at the US company Heartland Payment Systems, based in Princeton, New Jersey. Even while that might be one of the largest cases of data theft in the credit card industry, it wouldn’t be that interesting that I’d blog about. The – from my perspective – really interesting point is, from what I’ve read in the news, the way the attack has been performed.

The information sent is encrypted but has to be decrypted to work with it. The attackers grabbed the then unencrypted information. Surprise? Not really. The problem with security is that virtually any approach is incomplete – and thus inherently insecure. Examples?

• Passwords are frequently encrypted via SSL when sent to a eCommerce website but then decrypted and compared – and often they are even stored unencrypted and sent back in case of a lost password. I’ve just seen this again recently, when I received my password in cleartext via eMail.
• Data is encrypted on a specific type of device using some DLP (Data Loss Prevention) technology. Once delivered, it is decrypted – and might be mailed as an attachment.
• Access Control Lists are enforced to provide security for data at file servers – but they are sent to the client unencrypted and the user might store an unshielded copy (or mail it or do something else).

These are just three examples – of hundreds or thousands. Another was discussed in a Kuppinger Cole Webinar yesterday, where we talked about “service oriented security”, e.g. application security infrastructures, SOA security, and so on. The question was about the security between the applications and the security systems (and eventually the security systems themselves). That is a good question. Often there are security holes somewhere at the center of the security system. SSL itself isn’t the answer. In that case it is about a consistent security approach. Unfortunately, even many IAM and GRC applications don’t provide a really sophisticated security model.

Another interesting point is that there are always other potential security holes. Trojans which grab keystrokes are one example, the man behind you reading the information at your screen is another one. Some of these problems can be adressed, for example with external keyboards for entering sensitive information in eBanking. Others will be always there.

There is no easy solution to these issues. Information Rights Management will help to address many of these problems – I’ve blogged about the need for IRM some time ago. But IRM won’t solve everything. Information has to be processed, thus the systems which process data are extremly sensitive (like in the case I’ve started with). And a business document in an ERP system is, finally, stored in fragments within a database.

From my perspective, the most important point is to work on an authorization strategy (or access strategy) which covers all aspects. Any investment in DLP is at risk as long as it isn’t part of the bigger picture. Point solutions are perfect for masquerading the real security problems, but they don’t really solve them. An overall strategy which identifies the security holes and which tries to use a limited number of well linked technologies is mandatory to minimize security risks. That strategy has to include everything, from the firewall and SSL-secured connections to IRM and the security of backend systems. That is no easy task, especially because there are frequently many different parties involved which all claim that they have found the holy grail for enforcing security. But it can be done – and it will save you a lot of money by avoiding investments in security technology which don’t really solve your problems.

For the ones of you capable of reading German: Please participate in this survey. That fits well to the topic of this blog post.

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.

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!?

Some weeks ago Evidian, one of the European vendors in the Identity Management market, has announced that they are in the lead of an European research program for multi-domain policy management. The program called MULTIPOL is part of ITEA 2 (Information Technology for European Advancement), a set of EU-sponsored initiatives in the IT space.

The focus of MULTIPOL is mainly around multi-domain authorization, e.g. controlling access according to different security policies from different domains. The reason why: There is no internal network with a strong perimeter any more. Networks are becoming increasingly open. While authentication has been solved by approaches like Federation, the handling of policies for access control and thus authorization is still an issue.

We will observe this initiative, with Evidian as lead and ten other major European IT companies as participants. Policy Management beyond the border of one system is still amongst the things which have to be solved.

Some years ago I’ve written an article on policy management, stating that companies aren’t solving the problem but just are moving it to the next level. That was when more and more vendors told me the stories about their policy management capabilities they had built into their products. Usually they’ve built one policy management per product. So, instead of 100 products without policies there were 100 with policies. Different, incompatible ones.

The approach of Evidian is one interesting approach besides others like the idea of claims-based authentication and authorization Microsoft/Kim Cameron have published. Given that Evidian has a long experience especially around managing access, there might be some valuable outcome from this project – despite the fact that it is a EU-sponsored project.

Context-based authentication and authorization is one of the topics which have the potenzial to become the next hype. I’ve posted twice on this subject, here and here and we had, led by Dave Kearns, a lot of discussions around this at our EIC 2008. I’m convinced that the topic will become even more important at next year’s EIC.

Besides the ones which are obvious players in that future market segment like the risk-based authentication vendors (Arcot, Entrust, Oracle, RSA and some others) there are some other categories of vendors which offer even today at least some context-based authentication and authorization. One of them is Citrix. Given the number of installations of the Citrix Access Gateway they might even be sort of the leader in that market.

You might argue: A SSL Gateway is not a solution for context-based authentication and authorization. Yes – and no. No because a SSL Gateway without additional components is just a SSL Gateway. Yes, if you combine a Citrix Access Gateway with other things. At an Citrix Analyst Briefing yesterday, a Swiss bank talked about their approach for controlling access of remote workers. They use the Citrix Access Gateway together with many other Citrix technologies and with a NAP (Network Access Protection) tool from EPA factory.

Read the rest of this entry »