Simon Thorpe

I haven't had much time to update the blog recently, but just time to post before going on holiday. Over recent weeks there have been numerous stories relating to document theft – the Pentagon commentary on systematic theft of thousands of documents from defense contractors, the reports of journalists hacking into not just phones but the email systems of public and private citizens, the smug announcements by “cyber terrorists” that they’ve stolen files from various organisations.

The relevance of IRM is clear. Protect your perimeter, your applications, your file systems and repositories, of course, but protect your sensitive documents too. In the end, there are so many ways to gain digital possession of documents – but only one way to actually make use of them if they are protected by IRM. Anyone stealing a sealed document by whatever means has another substantial line of defense to overcome.

And that line of defense is designed to audit and authenticate access attempts as well as consider a number of other risk factors. It can also be rapidly reconfigured to deny access completely in the event of calamity – a single rule change can prevent all access from compromised user accounts or for whole classifications of information. The audit trail can also provide valuable clues as to the source of the attack.

In a cloudy world, where perimeters are of diminishing relevance, you need to apply controls to the assets themselves. And the scalable, manageable, intuitive way to achieve that control is Oracle IRM.

Another update of the IRM Hotfolder tool was announced a few days ago - 3.2.0.

The main enhancement this time is to preserve timestamps, ownership and file system permissions during the automated sealing process. Earlier versions would create sealed files with timestamps reflecting the time of sealing, and ownership attributed to the wrapper utility, etc. This version lets you preserve the properties of the file prior to sealing. 

The documentation has also been updated to clarify the permissions needed to use the utility.

For those who aren't familiar with the IRM Hotfolder, it is a simple utility that uses IRM APIs to seal and unseal files automatically by monitoring file system folders, WebDAV folders, SharePoint folders, application output folders, and so on.

In a recent report, security professionals reported two leading fears relating to cloud services:

"Exposure of confidential or sensitive information to unauthorised systems or personnel"

"Confidential or sensitive data loss or leakage"

 

These fears are compounded by the fact that business users frequently sign themselves up to cloud services independently of whatever arrangements are made by corporate IT. Users are making personal choices to use the cloud as a convenient place to store and share files - and they are doing this for business information as well as personal files. In my own role, I was recently invited by a partner to review a sensitive business document using Googledocs. I just checked, and the file is still there weeks after the end of that particular project - because users don't often tidy up after themselves.

So, the cloud gives us new, seductively simple ways to scatter information around, and our choices are governed by convenience rather than compliance. And not all cloud services are equal when it comes to protecting data. Only a few weeks ago, it was reported that one popular service had amended its privacy assurance from "Nobody can see your private files..." to "Other [service] users cannot...", and that administrators were "prohibited" from accessing files - rather than "prevented". This story demonstrates that security pros are right to worry about exposure to unauthorised systems and personnel.

Added to this, the recent Sony incident highlights how lazy we are when picking passwords, and that services do not always protect passwords anything like as well as they should. Reportedly millions of passwords were stored as plain text, and analysis shows that users favoured very simple passwords, and used the same password for multiple services. No great surprise, but worrying to a security professional who knows that users are just as inconsiderate when using the cloud for collaboration.

No wonder then that security professionals put the loss or exposure of sensitive information firmly at the top of their list of concerns. They are faced with a triple-whammy - distribution without control, administration with inadequate safeguards, and authentication with weak password policy. A compliance nightmare.

So why not block users from using such services? Well, you can try, but from the users' perspective convenience out-trumps compliance and where there's a will there's a way. Blocking technologies find it really difficult to cover all the options, and users can be very inventive at bypassing blocks. In any case, users are making these choices because it makes them more productive, so the real goal, arguably, is to find a safe way to let people make these choices rather than maintain the pretence that you can stop them.

The relevance of IRM is clear. Users might adopt such services, but sealed files remain encrypted no matter where they are stored and no matter what mechanism is used to upload and download them. Cloud administrators have no more access to them than if they found them on a lost USB device. Further, a hacker might steal or crack your cloud passwords, but that has no bearing on your IRM service password, which is firmly under the control of corporate policy. And if policy changes such that the users no longer have rights to the files they uploaded, those files become inaccessible to them regardless of location.  You can tidy up even if users do not.

Finally, the IRM audit trail can give insights into the locations where files are being stored.

So, IRM provides an effective safety net for your sensitive corporate information - an enabler that mitigates risks that are otherwise really hard to deal with.

The International Information Systems Security Certification Consortium, Inc., (ISC)²®, has just published a report conducted on its behalf by Frost & Sullivan.

The report highlights three growing trends that security professionals are, or should be, worried about - mobile device proliferation, cloud computing, and social media.

Mobile devices are highlighted because survey respondents ranked them second in terms of threat (behind application vulnerabilities). Frost & Sullivan comment that "With so many mobile devices in the enterprise, defending corporate data from leaks either intentionally or via loss or theft of a device is challenging.". Most respondents reported that they have policies and technologies in place, with rights management being reported as part of the technology mix.

Cloud computing was ranked considerably lower by respondents, but Frost & Sullivan highlighted it as a growing concern for which the security professionals consistently cited the need for more training and awareness.

The security professionals also reported that their two most feared cloud-related threats are:

• "Exposure of confidential or sensitive information to unauthorised systems or personnel"
• "Confidential or sensitive data loss or leakage"

These two concerns were ranked head and shoulders above access controls, cyber attacks, and disruptions to operation, and concerns about compliance audits and forensic reporting.

Rather contrarily, the third trend is highlighted because respondents reported that it is not a major concern. Frost & Sullivan observe that many security professionals appear to be under-estimating the risks of social computing, with 28% of respondents saying that they impose no restrictions at all on the use of social media, and most imposing few restrictions.

So, interesting reading although no great surprises - and reason enough for me to write three pieces on what Oracle IRM brings to the party for each of these three challenging trends.

A comment on mobile device proliferation is already available here.

A comment on cloud adoption is available here

The demo server has recently been retired after many years of faithful service. Please contact your local Oracle representative if you would like a demo, or see the demos on the Oracle IRM YouTube channel.

In a recent post, I discussed the value of item codes for enabling document-specific policies. As a rule, we recommend avoiding document-specific policies because of the governance and usability issues that tends to raise, but there are numerous scenarios where it is the right approach for some types of communication.

A colleague who is responsible for such a scenario within Oracle asked me for some tips on how to find the item code, so this post provides a few simple suggestions.

Firstly, you can usually see a document's item code simply by selecting it in Windows Explorer and hovering the mouse pointer over the document. On most operating systems, the tooltip provided by Explorer is modified to include a few pieces of IRM metadata, including the item code.

If you prefer, you can select a file and access its Properties dialog. The IRM Desktop adds an Oracle IRM tab to the dialog on most OSs and exposes further metadata including the item code. This approach has the additional advantage that you can copy the metadata to the clipboard - so you can cut and paste the item code if you need to specify it when setting up item specific policy.

Another method is to access the control panel from the IRM toolbar or menu when you are actually using a document. This gives you access to the metadata as well as a tab that tells you what rights you have, when the rights are due for refresh or expiry, a link to reset your password (presuming you are not using single sign on), and IRM Desktop version information.

There are other ways to get at the item code and other metadata - including programmatic methods that you might use during automated workflows that need to make decisions based on the item code or other factors - but these are the three most obvious ways for users to get at the item code if the scenario requires it. Of course, most users never need to know or care about such things.

The following pages provide a step-by-step guide to setting up an 11g IRM system, covering everything from downloading the software through to creating your first sealed documents, and then provides some guidance on classification design and some examples of how you might use classifications to meet the needs of some typical workflows.

• Server installation
• Server configuration
• Configuring SSL
• Creating your first sealed document
• Classification design
• Sample use cases

Quick product update – the IRM Desktop now formally supports 64 bit Windows. Oracle has just released Oracle Fusion Middleware 11g R1 PS4 (11.1.1.5.0), which includes a fresh IRM build. Some of our customers have been using earlier IRM Desktops on 64 bit systems for various reasons, but there were some known restrictions. The PS5 release gives us a build that is formally certified for 64 bit. The new kit is available from the Oracle Tech Network and elsewhere.

 

Someone just posted a question to the IRM wall on facebook regarding screen protection. Here is some commentary on the subject based on a blog entry from way back in 2008.

Oracle IRM lets you define policy for screen grabbing as part of user roles. Users with the Screen Capture right assigned as part of their role will be able to take screen shots in the usual ways, but users without that right will find that IRM can mask out sensitive windows.

This immediately illustrates a difference between Oracle IRM and most other solutions, because most solutions attempt to completely disable screen grabbing whenever a protected file is open – even if minimised. To illustrate what I mean, here is a typical example of what you would see if taking a screen shot when there is a sealed document open on the screen and you do not have the Screen Capture right.

You can see that a portion of the screen has been protected, but the capture was not completely prevented. If we completely blocked screen capture, the user would be forced to close all protected documents before repeating their screen capture attempt. This might be pretty inconvenient and frustrating, for example, if the purpose of taking the screen shot is to insert it into the sealed doc you are currently editing, or you have several sealed docs open and you are not sure which is preventing the screen shot, so you need to close them all.

To be clear, we do not claim that Oracle IRM guards against all methods of screen capture – there are so many to consider, and in any case it is always possible to use a camera or to take notes with a pencil and paper if you are determined to copy the information. The fundamental control always remains the control on whether you can open the document in the first place.

Nevertheless, there is real value in the layer of screen protection we provide. Security is all about layers of protection, but nothing is 100% secure unless it is 100% unusable.

Our solution is also a very good way to remind an end user that content is protected, or to protect content that happens to be open when a user makes a legitimate attempt to take a screen shot of something else. On seeing the area that the IRM Desktop has masked out, the usual reaction is surprise that such protection is possible, and appreciation that the solution is only affecting the content that needs to be protected. Customers agree that this approach is a valuable way to remind user communities that they are dealing with sensitive information, and need to adjust their behaviour accordingly – but at the same time, the inconvenience is limited to the content that needs to be protected, so the solution is balancing protection and productivity.

As always with Oracle IRM, the right to screen capture is defined as part of a role, so it can be assigned to the right users for the right classifications of users as a matter of policy. One of the main reasons to assign the right is to enable authorised users to use sealed documents during web conferences. Web conferencing tools often work by taking a series of screen shots and passing them back and forth.

 

 

A colleague recently asked how you can control the periodic synchronization of rights and audit data in IRM 11g – and what are the defaults? What factors should you consider when deciding whether the default synch schedule is right for your organisation, and how does synching impact the performance of the client and the server in large deployments? What exactly is synchronized on each occasion?

By default, synchronization occurs Monday to Friday between the hours of 9am and 5.30pm. The admin UI for the synch schedule is pretty self-explanatory…

Each IRM Desktop evaluates that time window according to its local time zone, so if you have users scattered around the world, they will each synch during their respective working days. You’ll note that the time window is quite large – a full working day. This ensures that the server is not hit by large peaks of requests in large deployments. There is usually no great urgency to get the synch done at a particular time, so we set a broad window.

Each IRM Desktop will pick a random time during each time window – again so that they don’t all try at once – and automatically tries again at intervals in the event of failure. If the network is disconnected at the time, the IRM Desktop will watch for the next connection and try again. All of this is transparent to the user.

What exactly gets synchronized? Synchronization is a two-way activity. The server provides the client with a fresh statement of the user’s rights and resets the offline periods so that the user rarely, if ever, hits the expiry time. In most configurations, this provides the user with a cached copy of ALL of their rights. Our classification model makes this viable even at large scale – there might be thousands or millions of documents, but they are usually organised for policy purposes into a few classifications, and each user has rights to a few classifications. So, each IRM Desktop only needs to receive a small amount of policy information in order for the user to have access to thousands of documents. There is no need for a user to be sent any information about classifications that they do not have any right to use, so the set of information sent to each user is usually quite small.

The server can also take the opportunity to inform the client of a change to the synch schedule, and to remind the client of the correct time from the server’s perspective.

In return, the client provides the server with the audit trail generated by its user since the previous synch event. This means that the server gets regular updates about offline usage of sensitive information. Some solutions only provide audit trail for events that involve contacting the server – so offline use is often invisible.

So why might you change the defaults? The most common reason is simply that your working week might not be Monday to Friday. If you have users in the Middle East, for example, you might configure the schedule accordingly. Alternatively, if you have a service in which rights rarely change, or you are not particularly worried about how quickly policy changes propagate out to users, you might reduce to a weekly schedule rather than daily – but the amount of traffic generated by synching is pretty modest so most customers stick with the defaults.

Another reason would be if you are not using the out-of-the-box classification model. If you are managing rights file-by-file or using some other model that involves a lot of policy configuration, then there might be a lot of information to synch to each user.

Another might be that it is REALLY important that policy changes be propagated rapidly or that audit trail be collected more frequently – so you might configure a lot of smaller windows during each day. Or you might modify some or all roles to achieve similar effects. You increase the traffic, but gain greater control and visibility.

Also, if appropriate, you can configure some or all roles to disable offline auditing. This reduces the amount of data that the client needs to send to the server. This might be useful if users are using a lot of sealed content and you are not too interested in the audit trail. Again, you choose which roles to exempt from auditing.

Thus, out-of-the-box we provide a powerful mechanism for ensuring timely propagation of policy changes and frequent upload of offline audit data – but we also give you a variety of controls to play with if needed.

 

 

Did you know that you can customise the pages that users see, for example, when they are denied access to a document - what we call Status Pages? Simon blogged about this nearly two years ago, during the days of IRM 10g. The capability is, of course, still very much part of IRM 11g, but the mechanism has changed, so this is a brief update. The details are in the IRM docs here.

Out of the box, IRM 11g provides a page that will look a lot like this....

As you can see, this is very much an Oracle branded page.

You can see in the above example that the status page shows some information about the file that is being accessed - the file name, the date it was sealed, and the name of the context it is sealed to. These details are provided by the IRM Desktop as query strings that it appends to the URL of the status page. The server interprets the query strings so that it can construct a context sensitive status page. In many cases, calls to the Help Desk are forestalled because the status page makes it self-evident that the user was denied access for very good reason.

Useful as the default page is, many customers like to redirect to custom pages. In so doing, they can apply their own corporate branding to make it clear whose policy is being enforced. They can also add further information to the status page as appropriate to their own needs. For example, they might provide links to corporate classification policy or links to an account provisioning system or contact details of the people responsible for managing this particular classification of information.

The custom status pages can still take advantage of the query strings provided by the IRM Desktop, and the customer can add further parameters that are specific to their deployment.

For further information, refer to the IRM 11g Developer's Guide, which explains the various options and parameters that you can exploit in your custom pages.

 

 

Hi, just a brief note to mention that we released an IRM Desktop last week to provide compatibility with IE9. The new IRM Desktop is compatible with 10g and 11g IRM Servers, and is available via our patch delivery mechanism in the Oracle Support site. Customers can download it from their and distribute it to their users as and when required.

To recap, the latest IRM Desktop supports Microsoft Office from 2000 through 2010 for Office formats and RTF and text, Outlook likewise for sealed email, Adobe 9 and X for PDF, MS IE 7 through 9 for HTML, XML and some image formats, and MS SharePoint 2007 and 2010.

For searching encrypted content, it also supports Windows Explorer Search from XP through Windows 7, Windows Indexing Service on XP and 2003, and SharePoint Indexing Service 2003 and 2008.

UPDATE: A number of people have contacted me to ask how to get hold of the patch kit. If you are an Oracle customer, you can go to support.oracle.com and log in using your customer service id to access patches and knowledge base articles and much more. The IRM patch for IE9 should be found by searching for 10410462. If you use IRM as part of a service run by one of our customers, then the service provider should be making the patch available to you.

 

 

As expected for quite a while, emails purporting to reveal alleged naughtiness at a major bank have been released today. A bank spokesman says "We are confident that his extravagant assertions are untrue".

The BBC report concludes...  "Firms are increasingly concerned about the prospect of disgruntled staff taking caches of sensitive e-mails with them when they leave, said Rami Habal, of security firm Proofpoint.

"You can't do anything about people copying the content," he said.

But firms can put measures in place, such as revoking encryption keys, which means stolen e-mails become unreadable, he added."

Actually, there is something you can do to guard against copying. While traditional encryption lets authorised recipients make unprotected copies long before you revoke the keys, Oracle IRM provides encryption AND guards against unprotected copies being made. Recipients can be authorised to save protected copies, and cut-and-paste within the scope of a protected workflow or email thread - but can be prevented from saving unprotected copies or pasting to unprotected files and emails. 

The IRM audit trail would also help track down attempts to open the protected emails and documents by unauthorised individuals within or beyond your perimeter.

 

 

A number of colleagues have been asking about IRM item codes recently - what are they for, when are they useful, how can you control them to meet some customer requirements? This is quite a big topic, but this article provides a few answers.

An item code is part of the metadata of every sealed document - unless you define a custom metadata model. The item code is defined when a file is sealed, and usually defaults to a timestamp/filename combination.

This time/name combo tends to make item codes unique for each new document, but actually item codes are not necessarily unique, as will become clear shortly.

In most scenarios, item codes are not relevant to the evaluation of a user's rights - the context name is the critical piece of metadata, as a user typically has a role that grants access to an entire classification of information regardless of item code. This is key to the simplicity and manageability of the Oracle IRM solution.

Item codes are occasionally exposed to users in the UI, but most users probably never notice and never care. Nevertheless, here is one example of where you can see an item code - when you hover the mouse pointer over a sealed file.

As you see, the item code for this freshly created file combines a timestamp with the file name.

But what are item codes for?

The first benefit of item codes is that they enable you to manage exceptions to the policy defined for a context. Thus, I might have access to all oracle - internal files - except for 2011_03_11 13:33:29 Board Minutes.sdocx.

This simple mechanism enables Oracle IRM to provide file-by-file control where appropriate, whilst offering the scalability and manageability of classification-based control for the majority of users and content. You really don't want to be managing each file individually, but never say never.

Item codes can also be used for the opposite effect - to include a file in a user's rights when their role would ordinarily deny access. So, you can assign a role that allows access only to specified item codes. For example, my role might say that I have access to precisely one file - the one shown above.

So how are item codes set?

In the vast majority of scenarios, item codes are set automatically as part of the sealing process. The sealing API uses the timestamp and filename as shown, and the user need not even realise that this has happened. This automatically creates item codes that are for all practical purposes unique - and that are also intelligible to users who might want to refer to them when viewing or assigning rights in the management UI.

It is also possible for suitably authorised users and applications to set the item code manually or programmatically if required.

Setting the item code manually using the IRM Desktop

The manual process is a simple extension of the sealing task. An authorised user can select the Advanced... sealing option, and will see a dialog that offers the option to specify the item code.

 

To see this option, the user's role needs the Set Item Code right - you don't want most users to give any thought at all to item codes, so by default the option is hidden.

Setting the item code programmatically

A more common scenario is that an application controls the item code programmatically. For example, a document management system that seals documents as part of a workflow might set the item code to match the document's unique identifier in its repository. This offers the option to tie IRM rights evaluation directly to the security model defined in the document management system. Again, the sealing application needs to be authorised to Set Item Code.

The Payslip Scenario

To give a concrete example of how item codes might be used in a real world scenario, consider a Human Resources workflow such as a payslips. The goal might be to allow the HR team to have access to all payslips, but each employee to have access only to their own payslips.

To enable this, you might have an IRM classification called Payslips. The HR team have a role in the normal way that allows access to all payslips. However, each employee would have an Item Reader role that only allows them to access files that have a particular item code - and that item code might match the employee's payroll number. So, employee number 123123123 would have access to items with that code. This shows why item codes are not necessarily unique - you can deliberately set the same code on many files for ease of administration.

The employees might have the right to unseal or print their payslip, so the solution acts as a secure delivery mechanism that allows payslips to be distributed via corporate email without any fear that they might be accessed by IT administrators, or forwarded accidentally to anyone other than the intended recipient.

All that remains is to ensure that as each user's payslip is sealed, it is assigned the correct item code - something that is easily managed by a simple IRM sealing application. Each month, an employee's payslip is sealed with the same item code, so you do not need to keep amending the list of items that the user has access to - they have access to all documents that carry their employee code.

 

 

As an illustration of the potential cost of accidental breaches, the US Dept of Health and Human Services recently fined a hospital $1m for losing documents relating to some of its patients. Allegedly, the documents were left on the subway by a hospital employee.

For incidents in the UK, several local government bodies have been fined between £60k and £100k. Evidently, the watchdogs are taking an increasingly firm position.

 

Numerous multinational energy companies have been targeted by hackers who have been focusing on financial documents related to oil and gas field exploration, bidding contracts, and drilling rights, as well as proprietary industrial process documents, according to a new McAfee report.

"It ... speaks to quite a sad state of our critical infrastructure security. These were not sophisticated attacks ... yet they were very successful in achieving their goals," said Dmitri Alperovitch, McAfee's vice president for threat research.

Apparently, the attacks can be traced back over several years, creating a sustained security compromise that has provided access to highly sensitive information that is of huge financial value to competitors.

The value of IRM as an additional layer of protection is clear. Whether your infrastructure security is in a sad state or is state of the art, breaches are always a possibility - and in any case, a lot of sensitive information is shared with third parties whose infrastructure security might not be as good as yours. IRM protects the individual information assets directly so that, even if infrastructure security is compromised, your critical information is enrypted and trackable and only accessible to authenticated, authorised, audited users.

The full McAfee report is available here.

 

 

Last year we saw news of both General Motors and Ford losing a significant amount of valuable information to competitors overseas. Within weeks of the turn of 2011 we see the European car manufacturer, Renault, also suffering. In a recent news report, French Industry Minister Eric Besson warned the country was facing "economic war" and referenced a serious case of espionage which concerns information pertaining to the development of electric cars.

Renault senior vice president Christian Husson told the AFP news agency that the people concerned were in a "particularly strategic position" in the company. An investigation had uncovered a "body of evidence which shows that the actions of these three colleagues were contrary to the ethics of Renault and knowingly and deliberately placed at risk the company's assets", Mr Husson said.

A source told Reuters on Wednesday the company is worried its flagship electric vehicle program, in which Renault with its partner Nissan is investing 4 billion euros ($5.3 billion), might be threatened. This casts a shadow over the estimated losses of Ford ($50 million) and General Motors ($40 million).

One executive in the corporate intelligence-gathering industry, who spoke on condition of anonymity, said: "It's really difficult to say it's a case of corporate espionage ... It can be carelessness." He cited a hypothetical example of an enthusiastic employee giving away too much information about his job on an online forum.

While information has always been passed and leaked, inadvertently or on purpose, the rise of the Internet and social media means corporate spies or careless employees are now more likely to be found out, he added.

We are seeing more and more examples of where companies like these need to invest in technologies such as Oracle IRM to ensure such important information can be kept under control. It isn't just the recent release of information into the public domain via the Wikileaks website that is of concern, but also the increasing threats of industrial espionage in cases such as these. Information rights management doesn't totally remove the threat, but abilities to control documents no matter where they exist certainly increases the capabilities significantly. Every single time someone opens a sealed document the IRM system audits the activity. This makes identifying a potential source for a leak much easier when you have an absolute record of every person who's had access to the documents.

Oracle IRM can also help with accidental or careless loss. Often people use very sensitive information all the time and forget the importance of handling it correctly. With the ability to protect the information from screen shots and prevent people copy and pasting document information into social networks and other, unsecured documents, Oracle IRM brings a totally new level of information security that would have a significant impact on reducing the risk these organizations face of losing their most valuable information.

As the season of rampant consumerism draws to its official close on 12th Night, it seems a fitting time to discuss consumerization - whereby technologies from the consumer market, such as the Android and iPad, are adopted by business organizations.

I expect many of you will have received a shiny new mobile gadget for Christmas - and will be expecting to use it for work as well as leisure in 2011. In my case, I'm just getting to grips with my first Android phone.

This trend developed so much during 2010 that a number of my customers have officially changed their stance on consumer devices - accepting consumerization as something to embrace rather than resist.

Clearly, consumerization has significant implications for information control, as corporate data is distributed to consumer devices whether the organization is aware of it or not. I daresay that some DLP solutions can limit distribution to some extent, but this creates a conflict between accepting consumerization and frustrating it.

So what does Oracle IRM have to offer the consumerized enterprise?

First and foremost, consumerization does not automatically represent great additional risk - if an enterprise seals its sensitive information. Sealed files are encrypted, and that fundamental protection is not affected by copying files to consumer devices. A device might be lost or stolen, and the user might not think to report the loss of a personally owned device, but the data and the enterprise that owns it are protected.

Indeed, the consumerization trend is another strong reason for enterprises to deploy IRM - to protect against this expansion of channels by which data might be accidentally exposed. It also enables encryption requirements to be met even though the enterprise does not own the device and cannot enforce device encryption.

Moving on to the usage of sealed content on such devices, some of our customers are using virtual desktop solutions such that, in truth, the sealed content is being opened and used on a PC in the normal way, and the user is simply using their device for display purposes. This has several advantages:

• The sensitive documents are not actually on the devices, so device loss and theft are even less of a worry
• The enterprise has another layer of control over how and where content is used, as access to the virtual solution involves another layer of authentication and authorization - defence in depth
• It is a generic solution that means the enterprise does not need to actively support the ever expanding variety of consumer devices - the enterprise just manages some virtual access to traditional systems using something like Oracle Secure Global Desktop  or Citrix or Remote Desktop.
• It is a tried and tested way of accessing sealed documents. People have being using Oracle IRM in conjunction with virtual desktops for several years.

For some scenarios, we also have the "IRM wrapper" option that provides a simple app for sealing and unsealing content on a range of operating systems.

We are busy working on other ways to support the explosion of consumer devices, but this blog is not a proper forum for talking about them at this time. If you are an Oracle IRM customer, we will be pleased to discuss our plans and your requirements with you directly on request. You can be sure that the blog will cover the new capabilities as soon as possible.

 

Just in time for Christmas, we have made a fresh IRM Desktop build available with a number of valuable enhancements:

 

• Office 2010 support
  
• Adobe Reader X support
  
• Enhanced compatibility with SharePoint
  
• Ability to enable the Sealed Email for Lotus Notes integration during IRM Desktop installation
  

 

The kit is currently available as a patch that you can access by logging in to My Oracle Support and looking for patch 9165540. The patch enables you to download a package containing all 27 language variants of the IRM Desktop. We will be making the kit available from OTN as soon as possible, at which time you will be able to pick a particular language if preferred.

I've been asked many times over the past month about how IRM could help with the saga playing out in the news regarding Julian Assange and Wikileaks. There must be a lot going in within certain US government agencies right now as the backlash of the constant release of information not only causes pain for US security departments, but also across the globe as the cables detail all sorts of sensitive and embarrassing information.

I won't go into the question of why this was possible in the first place, why so much information could be extracted en mass, but I will comment on how IRM could play a part in a solution to prevent something like this in the future.

Once it's out, it's out...One thing the release of this information is demonstrating, is as soon as you've lost control of information, it's gone. Once those cables existed as clear text on a website, they were quickly copied, distributed via Torrent networks and mirrored at a rate that it is now impossible to destroy all evidence of these files. This is a problem with a lot of security technologies today, they focus either on the location, the network or a gateway to define access to information. If that information leaves these protected areas, then it can travel very quickly and multiply at an amazing rate.

 

This is the real value of IRM over hard disk encryption, DLP, PGP etc. Most security technologies that use encryption only do so whilst the information is at rest or in transit. Then typically an access control mechanism defines who has the ability to access and decrypt that information. PGP for files is the best example. Say you secure a document with PGP. It wraps the file up with encryption, you can then safely store this file anywhere, on a USB key, on a hard disk or website. You may then want to share the encrypted file with a trusted person via email, you then have to give them the ability to decrypt it. It is at this point where the real threat begins. PGP decrypts the file back to the user and they can then store the unprotected file where they like. Sure DLP can detect this and try and block it, but this becomes impractical when the user NEEDS to decrypt and open the file, or when you are sharing the information with a supplier who can't install your DLP agents.

 

IRM provides persistent protection, it's never in the clearIRM makes sure the information is ALWAYS protected, even when in use. I'm not familiar with the system that contained the information Wikileaks is exposing, but most likely this was some custom application storing the data in a secure database. The application probably has some secure access control mechanism in place to ensure only authorized users can login to the application and see classified information at their security level. But the application ultimately delivers the information in a format that is easily copied. In fact the masses of information Wikileaks has acquired implies the application which stored it had easy ways to access data en mass. An RSS feed? It would be trivial, for an authorized user, to export masses of information from an RSS feed into another format and ship this over to Julian and his crew.

 

 

What specifically does IRM do to keep control over information?IRM on the other hand would never have allowed the information to be exported into an insecure location. IRM provides the following such features to defend against this type of risk.

• Most importantly every IRM secured document or email requires authentication every time you open it. Even if you do copy thousands of IRM secured documents to your local computer, you need to authenticate every time you open them.
  
• If you have the ability to open an IRM document, you cannot use the clipboard to cut and paste the information into another unsecure environment. IRM ensures that information STAYS inside the secured document. Even if you try to use a programmatic approach and access the information via the application document object model, IRM protects and defeats that as well.
  
• You can't easily take screen shots of the information either, IRM protects against that. Sure there are ways to get around this (take a photograph of your computer screen), but Wikileaks is stating to have 251,287 documents. I wonder how long it would take to photograph every one?
  
• You can place dynamic watermarks in IRM secured content. So even if you DID take 250,000 photographs, your login id, computer name, time/date is going to appear in them all. Good luck sitting down in Photoshop editing out the watermarks for 250,000 digital photos.
  
• Every time you open an IRM protected document it generates an audit. So if someone with the authority to open lots of secured content starts opening thousands of files, the activity is going to be very visible. Want to know who spent all their spare time taking pictures of his monitor, editing all the images in photoshop and passing them to an illegitimate source? Just run one audit report.
  
• IRM rights to secured content can be removed at any time. So if your audit report starts to show mass opening of content, you can detect this and revoke that persons access very quickly.
  

 

 

Could Oracle IRM have been used?Absolutely. IRM supports HTML, TXT, CSV, DOC, and other popular formats. The application could have delivered the classified information via an RSS feed. Users would be authenticated when they access each piece of information and they can also take copies to store where they like. Centrally the department would have complete visibility of who is accessing what. Different classifications of information (secret, confidential) can be enforced even when someone takes a file and forwards it via email onto someone else. Most importantly of all, if someone were to copy 250,000 IRM protected documents, zip them up and stick them on a BitTorrent network... the information is still safe.

 

The Oracle IRM server also has a very extensive set of APIs with a plug in architecture that can support any classification model you want. This means the integration of the technology with a secured application is possible and sustainable.

I'm sure we are going to see an increase in the use of IRM technologies over the coming months as the questions over how Cablegate was possible trickle through the information security departments of governments and other organizations. If you'd like to know more about how this technology can help your organization, please contact us and we can go into detail.