The additional layers include Access Control Lists or Information Rights Management in C#.NET

Recognizer Data Matrix in C#.NET The additional layers include Access Control Lists or Information Rights Management

Besides securing your content in a repository and sealing it with IRM, there are a handful of other layers that you can apply Most of the following can work in combination

Access Control Lists (ACLs)

An Access Control List (ACL) is a list of individual people who can access a content item, along with their access rights For example, an ACL in UCM would allow a content creator to directly specify which users have access and what kind of access read, write, or delete Then the content server controls access to that content item based on the list provided Access Control Lists are very convenient for project spaces Sometimes people have initial draft versions of content, notes, memos, and documentation that help create content items None of these draft documents are relevant to most people, and the authors would feel better

6:

about keeping them away from others until they are completed Access Control Lists give the content contributor total control over who gets to see their content The downside to access control lists is that they add significantly to the complexity of your security model, making the system slower and more difficult to audit In general, you should try to keep the security model simple and use mainly roles and accounts This is because, typically, it is someone s role that gives them access to content As roles changes and users join or leave the organization, access to documents will need to be updated If your security model is based on the assignment of roles and the classification of content, the appropriate access to content will automatically be granted or removed when users roles are changed in the user management system If, however, you have utilized ACLs, your security model is based on the explicit granting of permissions to individual users When roles change you will need to update the individual content items to reflect this new access model This can create large security holes as users permissions are not regularly removed from documents to update changes in organizational structures

Most desktop applications store hidden content in your documents without your knowledge, such as your name, your company, and in some cases, all previous edits you made of the document Just because you don t see it, doesn t mean your content is safe This hidden content can take even more forms Most Microsoft Office documents support a feature called Track Changes, which stores all changes to the document: insertions, deletions, rewording, and who made those changes In other words, your Microsoft Word documents might contain all the previous iterations

According to a 2005 study by the security firm Workshare, on an average, 30 percent of all business documents contained sensitive information that they would not want exposed Unfortunately, 90 percent of companies had no idea that their confidential information was leaking This is because a great deal of this sensitive information took the form of text that the users thought they deleted

Transforming Infoglut!

Perhaps you took an important document, and deleted a section that would be considered confidential, then e-mailed it to a business partner If that person knew what they were doing, they could uncover the deleted section and view the confidential information you thought you destroyed Oracle provides content cleansing filters that strip out this hidden content on the fly This means you can remove unnecessary information from your documents when they are put into a repository or when downloaded from your site Cleansing is an important part of the content life cycle, and is a vital part of a pragmatic security policy

Some companies also deploy special hardware to do something similar to content cleansing: a content firewall Instead of stripping out hidden metadata, these systems inspect documents for keywords before they leave your domain Whether the documents are sent in an e-mail or uploaded as a file attachment to a Web site, a content firewall can be amazingly helpful at preventing accidental disclosure of information Imagine you re involved in a highly sensitive merger You decided to secure the content correctly: first by cleansing documents of all hidden content, then by sealing them with IRM You then place them into a secure repository, awaiting review by your team Your digital files are perfectly safe, but the information is still vulnerable Why Because your secure data also exists in the minds of your team, who are like everybody else prone to mistakes Imagine that one team member is sending a quick update about the merger to the rest of the team He makes a simple plain text e-mail and types in the addresses of the rest of the team Unfortunately, he is using an e-mail system that uses an auto-complete feature When he begins typing an e-mail address, the auto-complete feature suggests an e-mail address for him that is similar to the address of somebody on his team Without noticing, he accepts the auto-completed e-mail address, which is unfortunately not somebody on the team Now somebody outside of your organization has this vital information This was not malice in any way it was a simple mistake Unfortunately, it occurs with extreme regularity If you had a content firewall, you would be able to scan all outgoing e-mail and block those that contain certain keywords, such as merger Together, content cleansing and content firewalls can protect the wrong element from seeing your information, whether or not you use IRM

6: