Last week I had a discussion with Seclore, a software company based in Mumbai, India. They are focusing on the area of Information Rights Management (IRM), one of my favourite research areas. I’m interested in this topic mainly for two reasons:

1. Information Rights Management is one of the IT topics with the closest relation to the core business topic of Information Security/Protection (including Intellectual Property Rights, IPRs).
2. Information Rights Management is the approach which allows the ongoing protection of information at rest, in move and in use – compared to many other approaches which cover only one of these phases.

Most solutions in that market are based on plug-ins into existing applications which enforce the IRM policies. The policies are managed centrally, information (documents) are protected by encryption.

Seclore’s approach is different in that they not mandatorily rely on such plug-ins but mainly act “below” the application. The client component (which is required to access protected, e.g. encrypted, documents) tries to analyze the activities off the application like access to the file system. One impact of that approach is that a document might be opened with different applications supporting the specific document format.

Even while I personally believe that implementing IRM functionality within the applications (the more common approach of vendors like Microsoft, Adobe and Oracle) allows a tighter control about the actions of a user and application on a document, the Seclore approach has some appeal. It is lightweight and works well today with different applications and in different environments, beyond the enterprise. As long as there is no common standard for the interactions of applications (the policy enforcement points) and the IRM backend systems across different vendors, this is a workaround. And once there is such a standard, Seclore is very likely to support it. Thus, not only looking at the big vendors but as well at Seclore makes sense in these early days of Information Rights Management.

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.

Information Rights Management (IRM) is one of these technologies which isn’t really successful until now, even while it is discussed and available for a pretty long time. IRM is about protecting the information directly, through signatures, encryption and a direct assignment of rights. These rights describe who is allowed to do what with that piece of information.

There are some reasons why IRM isn’t adopted widespread today. One is the complexity of the concepts. Without understanding PKIs and Public Key encryption it is impossible to really understand IRM. Another reason are the somewhat limited implementations. Most of them are fine for a limited set of applications and environments. Microsoft’s Windows Rights Management Services are great for Windows and Office. They even work in a B2B environment with some trust between the partners. But they are mainly for Microsoft apps. How about CAD and blueprints? How about the other office apps? And all the other types of documents, starting from XML documents, which are sent and stored? There are some other solutions, but most of them are either from pretty small vendors or very limited in scope.

But the most important reason is, in my opinion, that the relevance of Information Rights Management isn’t fully understood. Even when I talk with IAM responsible, IRM seems to be amongst the best hidden secrets. But access control which is limited to data in a silo like a file server or a document management system isn’t sufficient. Data is read and used by users, attached to mails, transferred via FTP – the perfect way to bypass most security concepts [I had a very interesting conversation with Taher Elgamal from Tumbleweed some days ago – Taher has been responsible for “inventing” SSL at Netscape, and it is definitely worth to have a look at Tumbleweed’s approaches to minimize FTP risk] and so on.

But if you look on it the other way round, everything is fine. IRM works as well for data which is stored in silos. With other words: If you use IRM for any type of information there is no necessity anymore for the classical access control approaches. The best way to protect information is to do it directly at the level of the information – and not at the level of one of these many systems which might change, transport or store the information. Given that, it is really time for an industry-wide initiative for IRM standards which work on every platform and with every type of information and every application.

I’ve observed an increase in discussion around data leakage prevention – finally. This discussion is overdue, given the fact that data leaks are common in most corporations. Internal documents, eMails, blueprints aren’t under control in most cases.

The need for data leakage prevention automatically leads to two topics: Information Rights Management (IRM) and Identity and Access Management (IAM). Both are tightly coupled. Identity Management is about managing the identities. Access Management is about controlling access, but mainly to defined “information silos”. Information Rights Management is about controlling access to information in the flow. But, in fact, IRM is nothing else than a specific for of Access Management – isn’t it?

If you look at Microsoft’s advances in IRM with Windows Server 2008, the central role Identity Management has for IRM becomes obvious. The most important improvement is the integration of Identity Federation and IRM, with the result of Federated Rights Management Services. This isn’t surprising, because IRM requires the knowledge of the users, groups, and roles which shall have access to information. That is easy within an enterprise, but it becomes a quite complex issue in the communication with more or less tightly coupled business partners. Federation is the obvious answer to this.

Thus, IAM and IRM will grow together over time, with IRM as a specific application of IAM. Companies which face the data leakage problem – virtually every company – have to define their strategy for IRM in the context of IAM. This context is necessary because IRM requires reliable identity information and because IRM is just another form of Access Management. And a major topic at our European Identity Conference.

The good news is that this dependency is seen by some vendors as well. The bad news for Data Leakage Prevention is that there are neither standards nor implementation which will cover the entire breadth of (electronic) corporate information, e.g. from Microsoft Word to CATIA to Lotus Notes. But the growing demand for solutions might change this over the next two or three years.