Quick guide to Oracle IRM 11g: Sample use cases
By Simon Thorpe on Oct 12, 2010
If you've been following this guide step by step, you'll now have a fully functional IRM service and a good understanding of how to start creating some contexts to match your business needs to secure content. The classification design article in the guide goes over some essential advice in creating your classification model in IRM and what follows is additional information in the form of common use cases that I see a lot in our customers. For each I'll walk through the important decisions made and resulting context design to help you understand how IRM is used in the real world.
- Work in progress - Example, protecting financial reports
- Using IRM with a classification model - Example, ISO 17799
- Periodic expiry & version control - Example, product roadmap presentations
|Financial Reports - Work In Progress (Standard template)|
|Role||Assigned Users & Groups|
|Reader - No Printfirstname.lastname@example.org|
|Financial Reports - Review (Standard template)|
|Contributor||david.lee (VP of Finance)
|Financial Reports - Published (Export template)|
|Contributor with export||alex.johnson (CFO)|
The first context secures work in progress content. Participants are identified as those who are involved in the creation and review of the information and are given contributor and reviewer roles respectively. Note that in this use case there is an attorney privy to the information who is external to the company. However due to the sensitive nature of the material, this external person has been given very restrictive rights, essentially they can only open the content, no printing, editing etc. The offline period for this role may be a matter of hours, allowing the revocation of access to the documents in a very timely manner.
After several iterations of the report have been created, it needs to be reviewed by a wider audience of executives. At this point David Lee (VP of finance) or Alex Johnson (CFO) have the authority to reseal the latest revision to the review context. Therefore there is a trust relationship between the WIP context and the Review context to allow this information to be reclassified. David and Alex are the only authorized users to be able to perform this task and therefore provide a control point for the reclassification of information. Note also that the external attorney now has the ability to review this reclassified document. The Reviewer role allows them to edit, print and use the clipboard within the bounds of the document. Their access to the previous, more sensitive versions remains unchanged.
One aspect of the reviewer role is that in Word change tracking is enforced. This means that every change made in the entire review process is tracked. Up until this enforcement with Oracle IRM, change tracking in Word was only useful if you trusted the end user to not switch it off. IRM brings security to this simple functionality and makes it a powerful tool for document review. Imagine if this was a contract negotiation process, you can be assured that every change to the contract has been recorded.
Finally, the last stage of the life cycle for this financial document is the approval of the report to be released to the investors, employees and the public at large. There is one more context which only the CFO has access to. This context allows for the export of the unprotected document so that it resides outside the realm of IRM security. Such a powerful role is only given to a highly trusted executive, in this example the VP. Again, IRM still protects all the previous versions of content that contain information not appropriate for public consumption.
All the steps in this use case are easy and familiar for the users. All they are doing is opening, editing and working with Word and Excel documents, activity they are used to performing. They may find a slight inconvenience if they are prevented from printing or cut and pasting content into a non-secure location, but overall they require little to no training on how to use IRM content.
Before we go into the detail of this, it is worth noting that in this use case we are manually recreating elements of an existing security policy inside IRM. There may well be a situation where another product contains all this logic and replicating the information inside IRM would be redundant and costly. For example the Oracle Beehive 2.0 platform is integrated with IRM and as such IRM doesn't use the built in context model but simply leverages the existing security model inside Beehive. So it is possible for Oracle IRM to externalize the entire classification system. This however requires consulting effort which may or may not be appropriate for the return in automation.
But back on topic, let's look at what a security classification model looks like. A common standard that people work to is the ISO 17799 guidelines which was the result of a group of organizations documenting their best practice for security classification. Below is an example of the sort of classification system ISO 17799 recommends.
|1||Top Secret||Highly sensitive information about strategies, plans, designs, mergers & acquisitions|
|2||Highly Confidential||Serious impact if shared internally or made public|
|3||Proprietary||Procedures, project plans, specifications and designs for use by authorized personnel|
|4||Controlled||For controlled use within the extended enterprise, but not approved for public circulation|
|5||Public||Information in the public domain|
There is an increase in sensitivity of information as you move from bottom to the top of this table. Inversely, the amount of information that is classified decreases as you increase the level of classification. This is important because as you wish to create a model for protecting top secret information, you need to have more control over who can open the documents and who has the power to assign new rights to people. This increases the administration of the solution because someone has to make these decisions. Luckily IRM places this control in the hands of the business users, so those managing top secret contexts are the people who are working with the top secret information. A good example is in Oracle we have a single classification across the entire company for controlled information. Everyone in Oracle has access to this and the provisioning of rights is automatic. However when IRM is used to protect mergers and acquisitions (M&A) documents in Oracle, very top secret information, a small group of users have access and only one or two people can administrate the context. These people however are the ones directly involved in the M&A activity.
PublicLooking at each of these we can determine how IRM might apply. For publicly classified content the response is immediate and quite obvious. You don't use IRM because the information has low to zero risk from a security perspective and therefore requires no controls. However there have been times where documents may be sealed to a public context simply to provide usage statistics.
ControlledFor controlled content there may be strong reasons to leverage IRM security. However the sensitivity of the information is such that the risks are relatively low. Therefore consider a single company, or at least department wide context. This is born from our best practice which leans towards a simple, wide context model which balances risk versus the usability and manageability of the technology. Essentially controlled information needs some level of security, but it isn't important enough to warrant a fine grained approach with a high cost of maintenance. Usually every professional member of staff is a contributor to the context which allows them to create new content, edit, print etc. This at a minimum provides security of content if it is accidentally lost, emailed to the wrong person outside the company and provides a clear indication that the information has some value and should be treated with due care and attention. Yes allowing everyone the ability to cut and paste information outside the IRM document exists, but disallowing this to a low level of classification may impact business productivity. If control of the information is that necessary, then it should result in a higher classification.
Business partners are given appropriate roles which allow them to open, print and interact with the content but not have the authority to create controlled information or copy and paste to other documents. For the rare exceptions where you wish to give access to un-trusted users you can create guest roles which are assigned as part of a work flow requesting for exceptions to the rule.
ProprietaryAs we move up through the classification policy we find an increase in the need for security from finer grained control. Proprietary information carries with it a greater risk if exposed outside the company. Therefore the balance of risk and usability requires a finer granularity of access than a single context. So now you have to decide at what level of granularity these contexts are created and this varies. There are however some good common rules. Avoid a general "proprietary" context, this would undermine the value of the classification. Follow a similar pattern to the work-in-progress use case defined above. Be careful to not be too generous about assigning the contributor role, restricting this group guarantee's document authenticity. Remember with IRM you can add/change access rights at any time in the future, so here is a chance to start out with a limited list and grow as the business requires.
Highly ConfidentialAs we get closer to your organizations most important information, we start to see an increase in the amount of contexts you need to provide adequate security. Highly confidential information requires a high level of security and as such the risk versus usability trade off favors a more granular approach. Here you are identifying explicit business owners of classifications instead of groups of users or using an automated system for unchecked provisioning of access. Training increases a little here as well because as you hand these classifications into the business, they need to know how to administrate the classification and understand the impact of their assignments of rights. The contexts also become very specific in their naming because instead of relating to wide groups of data, they now apply to very specific, high risk information. The right level of granularity and administration is hard to predict, therefore always start with a few contexts initially and pilot with a small number of business units with well defined use cases. You will learn as you go the right approach and more contexts will emerge over time.
Top SecretLast but most definitely not least, the Top Secret contexts. Sometimes these are the first to be created because they protect the most important documents in the company. These contexts are very controlled and tightly managed. Even the knowledge that these exist can be a security issue and as such the contexts are not visible to the support help desk. The number of top secret contexts is also typically very small due to the nature of the information. A company will only generate a small number of highly sensitive financial documents or a few critical documents which contain the secret sauce of the product your company creates. Top secret contexts also can have a short life span as they sometimes apply to a short lived, top secret project. Mergers and acquisitions is again another good example, these are often very top secret but also short lived. L1 classified contexts quite often contain external users, executives from a target acquisition or attorneys from your legal firm. But the sensitivity of the information means external users are closely monitored by the context managers.
Example context mapTypically to map a classification policy to IRM requires a business consulting project which asks each elements of the business how they use sensitive information, who should be able allowed to open and it and manage the access. At the end of this exercise you end up with a context map. This is a simple table which shows the IRM contexts and their relationship to the classification policy. Here is an example table from when we used the technology in SealedMedia before we were acquired by Oracle.
|Top Secret||Highly Confidential||Proprietary||Controlled|
|Board Communications||Executive WIP||Executive||Company|
|Security||Product Management WIP||Product Management|
|Professional Services WIP||Professional Services|
Note the use of the labels L1 through L4 to indicate level of sensitivity. This would be used as part of the actual context name, e.g. "L1 (Top Secret) Intellectual Property". This serves a few purposes, firstly if a user has access to many classifications, they will be listed in order or sensitivity with the most important at the top when users are making decisions about classification of documents. Also it makes it very clear how sensitive each classification is. If I attempt to open a document I do not have rights to, the IRM software redirects me to a web page informing me that I don't have access to "L1 (Top Secret) Security". Immediately I understand that I shouldn't be opening this top secret document because it is classified above my access level. Note that in the above map only ongoing contexts are documented. There may well be a context called "L1 (Top Secret) Smith versus Jones dispute" which would be used to secure the information about a highly confidential law suit. But this classification exists for only a short period of time and therefore is created as and when needed. The context map is designed to document classifications which will exist for ongoing future of the company.
|Context title||2010 L1 (Top Secret) Product Roadmap|
|Contributor||VP Product Management|
|Item Readers||Trusted users in the company who have been training on how to deliver product roadmap presentations and messaging|
|Context managers||VP of product development and those who approve and verify the training of trusted users|
This is a very simple definition of a context but a great demonstration of the powerful capabilities of Oracle IRM. The only person who can create product roadmap documents is the VP. This is because this person is the last point in the review and approval process and as such has the authority to reseal the final product roadmap document from the work in progress context to this published context. The Item Reader role by default gives no access to anything in the context. So as each person completes the product roadmap training, they are given the role Item Reader and at the same time you add the specific documents which they've been trained on. There is of course an administrative overhead here, if you have hundreds of users being trained a month, someone has to be administrating IRM. Using groups at this point does allow for the management to be simplified. You might have a group called "Trained 2010 product roadmap presentation field sales users" and this group has been given the Item Reader role with the document restriction of the current 2010 product roadmap presentation. Then the management of users who can access these documents is done in the user directory, such as managing group membership in Active Directory. A better solution for the management of this rights assignment would be to use a provisioning system such as the Oracle Identity Manager. Here you can centralize the workflow of users being trained and then not only give them access to the IRM context but also automate the provisioning to the location where the documents are stored.
Periodic expiryBecause the context name is prepended with the year it means that in 2011 the owner of this classification needs to review this classification. This review may decide that users with the "Item Reader" role can be trusted to print the content and that the 2 week offline period is too long and should be reduced to 1 week. The use case may also require that for each year users must be trained on the presentation of product roadmap information. So the creation of a new context, "2011 L1 (Top Secret) Product Roadmap" is created with a blank list of Item Readers, ready for new trained users to be given access to the new product roadmap. All Item Readers in the 2010 context are then removed and in one simple action you now ensure that nobody can access the old, out dated 2010 information. Because Oracle IRM separates out all the access rights from the documents themselves, there is nothing else to do. You remove access from the server, and as the offline periods to these documents expire, so does the access. The advantage for this retirement of access to old content, is that in the future if you ever need to be able to access a product roadmap document from 2010, the IRM administrator can simply go back to the old context and give access to a specific person.
Version controlWith the Item Reader role you are explicitly defining what documents users have access to. Whilst this might incur an administrative cost in maintaining this list, the value from a security perspective is very fine grained control and high visibility of who can access what. Another benefit of this is because Oracle IRM allows you to change your access rights at any time, you can update this list. So imagine that you have a group of trained users assigned with an Item Reader role that has version 1 of the product roadmap presentation listed. Then after a few months, the roadmap changes, as it often does and a new version 2 is created. After making this new version available somewhere you can now remove the groups access to version 1 and add version 2. What does this mean? Now everyone in that group trying to open version 1 is going to get an access denied message. But, this message is in the form of a web status page which you have full control over. You can now modify that status page to provide the link to the new version 2, which they do have the ability to open.
This is incredibly powerful. Not only is IRM providing the means to ensure only authorized users have access to your most sensitive information, but it is ensuring they can only access the latest versions of that information AND allowing you to easily communicate to them where to GET that latest version from.
These are just a few of the many uses for Oracle IRM, if you would like to discuss your own particular use cases and see how Oracle IRM can help, please contact us.