Thursday May 26, 2011

IRM Item Codes: How to Find Them


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.

IRM tooltip

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.

IRM properties tab in Explorer

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.

IRM Desktop control panel

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.

Saturday May 07, 2011

IRM Desktop for 64-bit Systems

Quick product update – the IRM Desktop now formally supports 64 bit Windows. Oracle has just released Oracle Fusion Middleware 11g R1 PS4 (, 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.

Saturday Apr 02, 2011

Customising Status Pages in Oracle IRM 11g


status page default

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....

status page default

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.


Monday Mar 28, 2011

Information Rights Management supports IE9


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 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.


Friday Mar 11, 2011

IRM Item Codes – what are they for?



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.

tooltip 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.


Wednesday Jan 05, 2011

IRM and Consumerization

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.

Thursday Dec 23, 2010

Oracle IRM Desktop update



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.

Thursday Dec 09, 2010

Setting Up IRM Test Content

A feature of the 11g IRM Server that sometimes gets overlooked is the ability to set up some test content that any IRM user can access to verify that their IRM Desktop can reach the server, authenticate successfully, and render protected content successfully. Such test content is useful for new users, and in troubleshooting scenarios.

Here's how to set up some test content...

In the management console, go to IRM - Administration - Test Content, as shown.


The console will display a list of test content - initially an empty list.

Use the Add option to specify the URL of a document or image, and define one or more labels for the test content in whichever languages your users favour.


Note that you do not need to seal the image or document in order to use it as test content. Nor do you need to set up any rights for the test content. The IRM Server will handle the sealing and rights assignment automatically such that all authenticated users are authorised to view the test content.

Repeat this process for as many different types of content as you would like to offer for test purposes - perhaps a Word document, a PDF document, and an image.

To keep things simple the first time I did this, I used the URL of one of the images in the IRM Server's UI - so there was no problem with the IRM Server being able to reach that image. Whatever content you want to use, the IRM Server needs to be able to reach it at the URL you specify.

Using Test Content

Open a browser and browse to the URL that the IRM Desktop normally uses to access the IRM Server, for example:

If you are not sure, you can find this URL in the Servers tab of the IRM Options dialog.

Go to the Test tab, and you will see your test content listed. By opening one of the items, you can verify that your IRM Desktop is healthy and that you can authenticate to the IRM Server.


Tuesday Nov 02, 2010

Oracle IRM and Device Control

Another question from a colleague - what controls and options does Oracle IRM provide over the use of multiple devices? What happens if a user has a laptop and a PC and wants to use sealed content on both?

The Default Configuration

By default, each user can use one device at a time. The IRM Desktop provides the server with some information to uniquely identify the user's device. If the user connects from a different device, the server informs the user that their rights are already in use and declines to issue rights to the second device. Simple.

The Rationale

This device control helps prevent credential sharing. If the user gives their credentials to another user, or is the victim of key-logging or some other exposure of their credentials, the other user cannot simply contact the IRM Server and gain the benefit of the first user's rights.

This is an important control in many deployments, including publishing deployments where users might try to avoid paying for content individually.

Any attempt to share credentials in this way will show up in the audit trail. Some customers tell me that this constraint and auditability for multi-device usage is a key reason for choosing Oracle IRM.

So, Oracle IRM defaults to the most secure configuration - limiting each user to one device at a time.

The Catch with the Default

In many organisations, it is standard to have a desktop PC and a laptop. Users also need to be able to switch devices when, for example, they buy a new laptop.

The default configuration is good for security, but not always so good in usability terms. As always, our goal is to give you options that let you choose the right balance of security, usability, and manageability for your organisation.

Using Multiple Devices Despite the Default Configuration

Before discussing non-default options, what choices do you have with the default state?


  • Wait for the offline period to expire on your first device. The server can issue rights to your second device as soon as the cached rights have expired on the first.


    This is not ideal. In most deployments, the first device is constantly refreshing its offline period by synching regularly with the server. Even where this is not true, you might have to wait a couple of days or more for the offline period to expire.

  • Manually check in your rights from the first device and then use the second device.


    Checking in is easy enough, but it is preferable to avoid users needing to understand such details of the solution.

  • Ask the administrator to check in your rights at the server end.


    This caters for situations where, for example, you have lost your laptop and therefore cannot check the rights in from the desktop end. However, it adds to the management burden.


In all cases, these options enable you to switch from one device to another in a controlled, audited way, but the user is limited to one device at a time. Depending on your deployment, the default configuration could be undesirable, although it does help defend against password theft or sharing.

The Configurable Option

The Device Count parameter enables you, as a matter of service policy, to define how many devices users can use.


The server will issue rights to the specified number of devices per user, such that the above check-in options are rarely necessary - but there is still a limit.

The Benefit

The Device Count parameter enables a customer to define their own balance of security, usability, and manageability. By setting a limit of two or three, you enable legitimate usage of multiple devices and reduce the management burden. There is a slightly increased risk of account sharing, but it is defined by your policy and backed up by the audit trail. As a simple example, the following image shows that the user "mabrahams" is consistently using a device with an obviously corresponding name.


If you see evidence that "mabrahams" is using several different devices - some apparently belonging to other users - you might want to investigate. It would be pretty simple to write a report to flag up such evidence.

By contrast, some solutions offer no device control, or enforce a large, hard-coded device limit such as 25. Either way, you don't get to choose your own level of risk. In addition, audit facilities are sometimes very technical in content, requiring considerable expertise to identify potential abuse.

Thursday Oct 14, 2010

Auditing IRM Protected Content - updated

[Read More]

Wednesday Sep 01, 2010

How the IRM Desktop Handles Multiple Servers

Another question from a colleague - suppose a user receives documents from two or more IRM services - how does the user switch between documents? Does the user need to manually log out of one service and log in to another so that the correct rights and restrictions apply? Do you need to clear your rights cache out to make way for the second service's rights, and repeat this process each time you want to switch back and forth between services?

Not at all.

Oracle IRM seamlessly supports multiple IRM services - even to the extent of allowing documents from different services to be opened and edited simultaneously, allowing the clipboard to be used to move information around, yet ensuring that information cannot be copied from one service's documents to another.

Every sealed document has a metadata header that identifies which IRM server manages its policy. The IRM Desktop automatically manages the communication and authentication with each server as required, and partitions its local database so that information relating to each server - rights, keys, credentials, and audit data - is managed separately.

To illustrate this, take a look at the Servers tab of my own IRM Desktop...


You can see that my IRM Desktop is enabling me to work with three IRM servers at the moment. My credentials for all three are cached, so I am never prompted to login in manually - the IRM Desktop simply authenticates me transparently to each server as required.

Also, all three servers have a tick in the "Update Rights" field, meaning that the IRM Desktop automatically synchronises rights with the servers according to a schedule defined by each server. This requires no manual intervention, and ensures that I always have a complete and fresh set of rights for all three servers.

More than that, the IRM Desktop automatically manages my audit logs so that the correct audits are uploaded to the three servers with no potential for the wrong information going to the wrong server.

When I want to seal a document, the IRM Desktop provides me with a complete list of all classifications that I am authorised to seal to for all three servers. I simply pick the right classification, and the IRM Desktop does the correct authentication and applies the correct metadata and keys etc to the new document.

For example, a portion of my list is shown below, with classifications from all three servers:


So, the IRM Desktop automatically manages my interactions with as many servers as I need to work with.

From a security perspective, the IRM Desktop ensures that the three sets of keys and rights and audit data are partitioned so that the three servers do not compromise each other's security.

Finally, our advanced clipboard control means that a user will be prevented from pasting information between documents sealed to different servers. So, if you receive documents from companies A and B, the IRM Desktop will can ensure that company A information stays in company A documents, and company B information stays in company B documents - even if both companies allow the use of the clipboard. Most IRM solutions could only provide such a safeguard by disabling the clipboard completely - which is a real blow to usability. Besides, company A and company B would typically be completely unaware that the user is receiving documents from two different services.


Tuesday Aug 31, 2010

Auditing IRM Protected Documents

[Read More]

Tuesday Jun 08, 2010

Granular and Secure Clipboard Control in Oracle IRM

One of the main leak prevention controls that customers are looking for is clipboard control. After all, there is little point in controlling access to a document if authorised users can simply make unprotected copies by use of the cut and paste mechanism.

Oddly, for such a fundamental requirement, many solutions only offer very simplistic clipboard control - and require the customer to make an awkward choice between usability and security.

In many cases, clipboard control is simply an ON-OFF option.


  • By turning the clipboard OFF, you disable one of the most valuable edit functions known to man. Try working for any length of time without copying and pasting, and you'll soon appreciate how valuable that function is.

    Worse, some solutions disable the clipboard completely - not just for the protected document but for all of the various applications you have open at the time. Normal service is only resumed when you close the protected document. In this way, policy enforcement bleeds out of the particular assets you need to protect and interferes with the entire user experience.

  • On the other hand, turning the clipboard ON satisfies a fundamental usability requirement - but also makes it really easy for users to create unprotected copies of sensitive information, maliciously or otherwise. All they need to do is paste into another document.

    If creating unprotected copies is this simple, you have to question how much you are really gaining by applying protection at all. You may not be allowed to edit, forward, or print the protected asset, but all you need to do is create a copy and work with that instead. And that activity would not be tracked in any way.


So, a simple ON-OFF control creates a real tension between usability and security. If you are only using IRM on a small scale, perhaps security can outweigh usability - the business can put up with the restriction if it only applies to a handful of important documents. But try extending protection to large numbers of documents and large user communities, and the restriction rapidly becomes really unwelcome.

I am aware of one solution that takes a different tack. Rather than disable the clipboard, pasting is always permitted, but protection is automatically applied to any document that you paste into.

At first glance, this sounds great - protection travels with the content. However, at any scale this model may not be so appealing once you've had to deal with support calls from users who have accidentally applied protection to documents that really don't need it - which would be all too easily done. This may help control leakage, but it also pollutes the system with documents that have policies applied with no obvious rhyme or reason, and it can seriously inconvenience the business by making non-sensitive documents difficult to access. And what policy applies if you paste some protected content into an already protected document? Which policy applies?

There are no prizes for guessing that Oracle IRM takes a rather different approach.


Oracle IRM balances usability and security for clipboard control


Oracle IRM offers a spectrum of clipboard controls between the extremes of ON and OFF, and it leverages the classification-based rights model to give granular control that satisfies both security and usability needs.

Firstly, we take it for granted that if you have EDIT rights, of course you can use the clipboard within a given document. Why would we force you to retype a piece of content that you want to move from HERE...

to HERE...?

If the pasted content remains in the same document, it is equally well protected whether it be at the beginning, middle, or end - or all three. You can see this in action in the middle of our video demonstration.

So, the first point is that Oracle IRM always enables the clipboard if you have the right to edit the file.

Secondly, whether we enable or disable the clipboard, we only affect the protected document. That is, you can continue to use the clipboard in the usual way for unprotected documents and applications regardless of whether the clipboard is enabled or disabled for the protected document(s). And if you have multiple protected documents open, each may have the clipboard enabled or disabled independently, according to whether you have Edit rights for each.

So, even for the simplest cases - the ON-OFF cases - Oracle IRM adds value by containing the effect to the protected documents rather than to the whole desktop environment.

Now to the granular options between ON and OFF.

Thanks to our classification model, we can define rights that enable pasting between documents in the same classification - ie. between documents that are protected by the same policy. So, if you are working on this month's financial report and you want to pull some data from last month's report, you can simply cut and paste between the two documents. The two documents are classified the same way, subject to the same policy, so the content is equally safe in both documents. However, if you try to paste the same data into an unprotected document or a document in a different classification, you can be prevented.

Thus, the control balances legitimate user requirements to allow pasting with legitimate information security concerns to keep data protected.

We can take this further. You may have the right to paste between related classifications of document. So, the CFO might want to copy some financial data into a board document, where the two documents are sealed to different classifications. The CFO's rights may well allow this, as it is a reasonable thing for a CFO to want to do. But policy might prevent the CFO from copying the same data into a classification that is accessible to external parties.

The above option, to copy between classifications, may be for specific classifications or open-ended. That is, your rights might enable you to go from A to B but not to C, or you might be allowed to paste to any classification subject to your EDIT rights.

As for so many features of Oracle IRM, our classification-based rights model makes this type of granular control really easy to manage - you simply define that pasting is permitted between classifications A and B, but omit C. Or you might define that pasting is permitted between all classifications, but not to unprotected locations. The classification model enables millions of documents to be controlled by a few such rules.

Finally, you MIGHT have the option to paste anywhere - such that unprotected copies may be created. This is rare, but a legitimate configuration for some users, some use cases, and some classifications - but not something that you have to permit simply because the alternative is too restrictive.

As always, these rights are defined in user roles - so different users are subject to different clipboard controls as required in different classifications.

So, where most solutions offer just two clipboard options - ON-OFF or ON-but-encrypt-everything-you-touch - Oracle IRM offers real granularity that leverages our classification model. Indeed, I believe it is the lack of a classification model that makes such granularity impractical for other IRM solutions, because the matrix of rules for controlling pasting would be impossible to manage - there are so many documents to consider, and more are being created all the time.


Wednesday May 05, 2010

Extensible Metadata in Oracle IRM 11g

Another significant change in Oracle IRM 11g is that we now use XML to create the tamperproof header for each sealed document. This article explains what this means, and what benefit it offers.

So, every sealed file has a metadata header that contains information about the document - its classification, its format, the user who sealed it, the name and URL of the IRM Server, and much more.

The IRM Desktop and other IRM applications use this information to formulate the request for rights, as well as to enhance the user experience by exposing some of the metadata in the user interface. For example, in Windows explorer you can see some metadata exposed as properties of a sealed file and in the mouse-over tooltip.


The following image shows 10g and 11g metadata side by side.


As you can see, the 11g metadata is written as XML as opposed to the simple delimited text format used in 10g.

So why does this matter?

The key benefit of using XML is that it creates the opportunity for sealing applications to use custom metadata. This in turn creates the opportunity for custom classification models to be defined and enforced.

Out of the box, the solution uses the context classification model, in which two particular pieces of metadata form the basis of rights evaluation - the context name and the document's item code. But a custom sealing application could use some other model entirely, enabling rights decisions to be evaluated on some other basis.

The integration with Oracle Beehive is a great example of this. When a user adds a document to a Beehive workspace, that document can be automatically sealed with metadata that represents the Beehive security model rather than the context model. As a consequence, IRM can enforce the Beehive security model precisely and all rights configuration can actually be managed through the Beehive UI rather than the IRM UI. In this scenario, IRM simply supports the Beehive application, seamlessly extending Beehive security to all copies of workspace documents without any additional administration.

Finally, I mentioned that the metadata header is tamperproof. This is obviously to stop a rogue user modifying the metadata with a view to gaining unauthorised access - reclassifying a board document to a less sensitive classifcation, for example. To prevent this, the header is digitally signed and can only be manipulated by a suitably authorised sealing application.


Oracle IRM protects and tracks your sensitive information no matter where it goes. It combines business friendly encryption with role based usage rights and auditing.

11g quick guide


« August 2016