Getting Started With Information Rights Management (IRM) Integration With SharePoint

What is the purpose of Information Rights Management Marriage With SharePoint
Distributing local information through unwanted channels is one of the largest problems that exist within a SharePoint environment. Because SharePoint is meant to provide users with large facilities in order to share and work with arbitrary business data, this can sometimes lead to users sharing information that should otherwise not be shared.

A major method to procure added assurance that will help to eliminate intentional and/or accidental redistribution of sensitive or classified business information is to persistently protect the the business data under multiple circumstances, across multiple environments.

A common incident is when someone sends a piece of confidential information to the wrong person, through a mistake of choosing out of an address book or something similar. These situations are commonplace within an environment that builds out virtual teams focused on collaboration, when sensitive information in business information stored in such mediums such as Microsoft Office documents is easily shared accidentally or intentionally for whatever reason.

These types of information leaks can be costly because of:

  • loss of revenue
  • competitive advantage
  • customer confidence

MOSS is tailored to controls access to various documentation, following usage once the document has been downloaded. For an organization that has to adhere to certain legal / business requirements, this can be an invaluable piece of functionality.

What is Information Rights Management and What Can It Protect?

Information Rights Management (IRM) is a component of the Microsoft Office SharePoint Server and Microsoft Office product suite. Although its base technology derives from Windows Right Management, it has heavy ties into the Microsoft Office product suite, and has direct hooks into the Microsoft Office SharePoint Server system.
IRM allows document authors to specify who can read their document, what they are able to do with the document, and when they are able to do it. IRM can be applied to Outlook e-mails, Word documents, Excel spreadsheets, and PowerPoint presentations (along with others which implement a customized “protector”). While the Microsoft Office SharePoint Server environment is meant to promote collobration of documents between virtual teams, IRM will provide offline methods of working with the arbitrary office documents.
Some of the key features that one should look to implement in an offline protection implementation is:

  • Implement A Protection Scheme That Travels With An Arbitrary File
    • Protection that exists at the file level
    • Protection that will bind and travel with the file, wherever the file goes
  • Controls Access To The Document, and How the Document Can be Used
    • Leverages encryption methods that controls usage
    • Implements usage policies bound to the document that translate to the native client application
    • Expire relevant content when it is deemed no longer necessary
  • The Protection System Should Be Easy For End Users
    • Easy for clients to implement protection for business data
    • Tightly integrated with Microsoft Office clients that in turn are relevant to SharePoint
  • Policies That Are Managed By The Enterprise

    • Permission Policies that are organizational consistent
    • One organizational owns overall access

In a typical SharePoint environment, documents are controlled at a very granular level when stored at the web level, however once a client gets the chance to download the arbitrary document, the overall permission levels are lost. MOSS and IRM work together in order to translate roles on the SharePoint server, to permission levels as they are specified within IRM.

If a SharePoint environment if there is no IRM functionality implemented, documents circulated electronically are uncontrolled and can be printed, copied, and forwarded feasibly to anyone. Transmission of e-mails and documents over secure networks may protect the information in transit, but offer no control over what the recipients do with the information. Password security protection for documents can easily be circumvented if the password is also provided.

IRM can be used to prevent the printing or forwarding of e-mails and to make them inaccessible to the recipient after a specified expiry date. IRM can make documents unreadable by anyone other than the specified recipients.

Deploying Information Rights Management and IRM Requirements
Deployment of Information Rights Management is performed across an organization typically by the server/SharePoint administrator. In addition to installing the Microsoft Office 2003/2007 client software (since these are the default protectors that are provided by IRM), there are some other services and software that need to be installed and configured to support the IRM infrastructure:

  • Microsoft Windows Server 2003 Enterprise Edition (prerequisites for SharePoint)
  • Microsoft Windows Rights Management Server for Windows Server 2003
  • Microsoft Active Directory Services
  • Microsoft Internet Information Services
  • Microsoft SQL Server 2000/2005
  • Microsoft Windows Right Management Client software to be installed on all WFE’s

The relevant server and clients that will be accessing the IRM enabled document repositories need to be loaded with the Rights Management Update for Windows. For the encryption service to function correctly, public and private keys for creators and readers are created when the users enroll to use the Rights Management Service (RMS). Microsoft Office is required to create rights protected documents, or through the MOSS interface, but they can be viewed with other editions of Microsoft Office, or with the IRM add-on for Microsoft Internet Explorer.

By default, when Microsoft Office is installed, IRM is not enabled. Without the additional software listed above, end users will not be able to create rights-protected material even though it is enabled on the MOSS server.

IRM Protection Policies
The policies that RMS will leverage are formulated, enforced and populated by SharePoint or network administrators. After the policy has been established, the client still has to apply the appropriate policy to the document they are sending, by pressing a button and specifying rights that are available for this document. MOSS will translate roles from the site if here is no direct rights bound to the arbitrary piece of documentation.

What are some of the benefits of IRM?
There are several benefits of using IRM for various environments.

  • Documents created with MS Office with IRM are encrypted using Windows RMS (Rights Management Services). Restrictions can then be set to limit recipients’ rights to view, copy, print, and distribute MS Office 2003 documents, including Outlook e-mail messages, and to set a time limit on the readability of the document.
  • Appropriate use of this technology restricts access to records, either by internal or external organizations interacting with a third party, may prevent various organizations from creating, maintaining, and disposing of electronic records in a legal and proper fashion. Furthermore, use of this technology may prevent agencies from producing such records to competent external authorities, such as in response to arbitrary legal requests.
  • An organization can create and enforce a policy to deal with the receipt of MS Office IRM-restricted files sent by internal and external organizational users, in order to ensure such files comply with the accessibility requirements of an arbitrary organization.

Getting Started With the IRM
The reason that most people have trouble with IRM is because the requirements for MOSS can be somewhat rather confusing, however if you make sure, and inventory, all the portions that are required, and ensure that they are properly implemented within your environment, it is a relatively painless procedure. The important portion to gather out of the first steps needed to properly implement IRM is ensure that you meet all of the requirements. The actual process of getting IRM going is relatively painless and you can up in running in about 30 minutes (depending on whether you need to write / implement any custom protectors [the methods by which IRM can actually implement its protection policies]). Obviously, we are not talking about client based rights management, the IRM that we are going to be enabling exists on the server, although will provide hooks into the client portions of IRM.

The first requirement for IRM is you must have a server with IRM enabled, by this I mean a Windows 2003 Server with SP1 or later running Windows Rights Management Services since it provider the backbone framework for the IRM services. Next, since IRM has to somehow be enabled on all of the FWE’s through the web farm, it can be downloaded from here:

This is how your MOSS services will hook into the main IRM server, it provides the functionality that is needed in order for the document libraries that you are using, in essence, to become IRM enabled. As well, for your users to work with the IRM features that are available in an off-line format (those features after a document is downloaded from a document library and is placed in native encrypted format) will need to have the client installed.

Once the prerequisites are defined, and appropriately enabled on all of your servers, you can begin the actual implementation of the service.


Formal Access Control Methodologies and SharePoint

Formal Access Control Methodologies for Microsoft Office Server System

There are a variety of access control methodologies that one can implement within a SharePoint environment. The type of access control that an organization will implement will greatly depend on the business structure, industry, and regulatory compliance considerations that have to be instigated. It is usually helpful however to start the access control process by creating an access control matrix. This matrix will have subjects (users) on one end of the grid (typically on the row) and objects (things a user will access) on the other axis of the grid (typically the column). This will create T diagrams of access, which will help you define exactly how to assimilate the arbitrary access control methodology that your organization chooses.

Mandatory Access Control (MAC) Orange Book B Level

Mandatory Access Control is one of the most restricting types of access control mechanisms from a user standpoint that you can implement with SharePoint. The overlying principle of mandatory access control is that the user is segregated from the access control decision. For each object that gets stored within SharePoint, it is given a sensitivity label. Users are associated with the labels, and whenever access is attempted, the users associated access levels are posted to the sensitivity labels to control access to the object. The users have to be of a certain level in order to access objects of certain sensitivity labels. MAC promotes an overlying control that is not bound to an exact identity, but instead shares a set of rules (Ruled Based Access Controls Lists [RBACL]), which are the methods which define what users can access exactly what SharePoint objects. This is an extremely popular control mechanism for the federal sector since it allows a true segregation for classifications of data across a collaboration environment. Within the federal sector there is typically:

  • Public
  • Secret
  • Top-Secret

An object within SharePoint can be assigned the level of public (the sensitivity label). Users are associated with a sensitivity label, so that certain users are given one of the three levels, whether it is public, secret, or top-secret. Therefore groups of people can access the document as long as the rules are satisfied.

Although MAC is a difficult system to implement, it is considered one of the most secure types of access control systems and for companies with regulatory compliance concerns a very practical implementation.

Discretionary Access Control (DAC) Orange Book C Level

Discretionary Access Control is one of the most common access control implementations that exists within SharePoint. DAC allows content managers to define the management of SharePoint objects as well as actions (such as information policy management and versioning configurations) related to SharePoint objects.

Since there is, within a typical SharePoint implementation, usually a site collection administrator along with related site owners, going down to any arbitrary Secured Object level security. In this, there is typically self service management of access control over various SharePoint objects, so the user is given discretion, which can be given from any number of users. Since with most secured objects in SharePoint, there is always one person with full control over that object, that person will be given the options of specifying the other users that can access the object and how the other users can interact with those objects. Out of the box, SharePoint is an object-to-identity based system, and therefore when setting up a plain vanilla SharePoint site where you will be directly binding identities to objects regardless of membership and role providers, you will be implementing Discretionary Access Control.

Lattice Based Access Control (LBAC) No Orange Book Level Association

LBAC is a concept that involves ordered sets and related subsets.  Within LBAC, there are always two certainties, each which span a finite space:

  • There is always one Least Upper Boundary (LUB)
  • There is always one Greatest Lower Boundary (GLB)

Applying the above two as constraints as finite boundaries, the parameters of the LBAC are the subject and the object being secured. For each object, a user will have a LUB and the GLB in regards to access rights to the object.  Using LBAC, it is possible to maintain the lattice between security objects by allowing a combination to exist through the merging of rules and related classification assignment. In short, for each object that can be accessed, there can be an upper and lower limit for what a user can do.

Rule Based Access Control (RuleBAC) No Orange Book Level Association

RuleBAC is a child of the concept of Mandatory Access Control, since it inherits out of the concept out of an Access Control List. The access to objects however is controlled by rules that can be shared globally across an enterprise. This is heavily tied to the concept of grouping and role basing in SharePoint, where one might define a set of rules that are associated with a group of people that share the same type of access needs and object interactions.

Role Based Access Control (RBAC) No Orange Book Level Association

Role based access controls are becoming extremely popular because of their ease in adding users to federated corporate systems, and there bulk management options. They are incredibly pertinent in SharePoint when exploiting the options available with the ASP.NET role provider models. As opposed to rigid access models that have been presented thus far, RBAC allows a user to be added to a role group that will define the objects that they have permission to as well as legal actions that the user can have with that object. RBAC is used on the Windows Server itself, where there are certain permission groups that a user can be added to, such as Local Administrators or Power users (actions performed through the Computer Management MMC snap-in). The concept of RBAC is the backbone of implementing a Limited User Access (LUA) environment where one can determine the exact amount of access that a user needs in order to finish their job with no unused or extravagant permissions.


Hybrid SharePoint With SElinux Theory of Operation

Multi-Level Security Domain SharePoint

To promote apposite security implementation of security centric SharePoint environments (those which are focused on sheltered implementations) it is necessary to build an environment that implements multi-security domain access along with diverse security mechanisms that will provide a basis to procure the concepts provided in the CIA triad. Like researched in previous articles, there is an overall concept in computing security architecture known as the CIA triad which procures the subjects of Confidentiality, Integrity, and Availability (CIA) which afford the underlying basis for security conceptualization. Within an environment that promotes multi-level security domain access, there are other minor objectives that are introduced to build the aggregate CIA concepts since the environment becomes more finely tuned and the overall level of security system awareness becomes more robust and detailed. Throughout this article, I will present the Theory of Operation of building a such environment, and the considerations and implementation concerns that are presented with such a solution.

Introduction to the Theory of Operation

The Theory of Operation behind a Hybrid SELinux / SharePoint scheme provides the basis for procuring a proper implementation that conforms to the CIA triad while providing the mechanisms that are necessary for data carry over, while maintaining globally maintainable security policies that conform to a classification (an environment that inherits sensitivity labels) based environmental standards. This initial introduction to the Theory of Operation presents solely the basis for developing the environment, and in subsequent sections the exact compilation and deployment will be presented and examined. Several portions of the Theory of Operation may prove theoretical and touch on concepts not immediately available within an arbitrary technology; however the aggregate presentation will procure a concrete, usable solution.

Introduction to Machine Virtualization, and the need for Machine Virtualization

Virtual machines are increasingly common throughout enterprise environments for obvious hardware consolidation benefits; however, one of the most overlooked benefits that virtual machines can provide is that of security considerations. The Hybrid environment presented is excursively based on such a concept, since virtualization will build the option to use Windows Server 2003 on SElinux hooked Redhat / Fedora Core 3 kernel.

The most obvious benefit that is received when implementing virtual machines is that of complete data isolation, since, in essence, all data stored within an arbitrary virtual machine is considered to be segregated from the other environmental assets unless otherwise bound. The isolation also extends out to services and processes on the machine, in that there can be specified running of the services that are contained, in which services can be manipulated at runtime without affecting other various services.

Whereas the most secure environments are those whose domains are segregated because of the physical separation of machines, these are also the most difficult to transverse data through. In essence, when separating the machines physically, we are establishing multiple security zones within an environment. In order to achieve this otherwise, it would require separate processing mechanisms for each domain. Using virtual machines however, a SharePoint administrator can instead setup various security zones based on requirements that exist on the same hardware, whereas various domain security zones can exist in complete isolation, although procured on the same physical machine. For each security zone that is implemented, a separate security policy can and should be implemented which provides overall control in relation to the security domain. The security policies that are implemented are structured around the concept of Mandatory Access Control principles, so that they are not only applied for the objects that exist on a specific virtual machine, but the processes that exist within a specific virtual machine. By implementing this concept of MAC, one can be assured that between two various SharePoint environments, data cannot be transverse between the two, unless stated within the MAC based global security policy.

Although this all sounds great for federal and highly regulated enterprise environments, a rather rudimentary, be at although important, question remains. The concept of MAC was invented a very long time ago, why hasn’t it been implemented in rudimentary Windows based environment previously? There are two major answers to this question. The first is that direct hooks that would otherwise override the DAC controls that predominantly dominate the Windows security architecture are forbidden and would be a legal problem (discussed more exhaustively in a subsequent section), and secondly, MAC can become increasingly difficult to implement and maintain, and security policies tend to can be complex for an administrator to understand with granular training in such.

SELinux, although considered somewhat complicated, can alleviate a majority of these issues, particularly with the use of virtual technology. This is the reason for this particular choice of technology. In a separate article, I will detail how another technology, AppArmor, can be used for somewhat of the same purpose.

Carrying Over the CIA Triad Concepts

The three subjects from the CIA triad are carried over when leveraging a MAC worthy technology such as SELinux. These are availability, where the SharePoint assets are accessible to the requesting parties in a timely manner, confidentiality where the information that is stored in SharePoint is available only to the properly authenticated SharePoint users, and integrity where SharePoint information can only be modified or altered by entities that are authorized are all still relevant goals to achieve. However within a multi-security environment a few more minor security concepts introduced, namely the following three, which although relate to the CIA triad, deserve individual mention:

Authentication ensuring that subjects are appropriately identified by the collaboration system and that their passed identity is not a fictious one

Authorization ensuring that subjects are authorized to perform their relevant requested actions on the system and that they have proper access rights to do so

Domain Separation For proper SharePoint information assurance, it is necessary to package SharePoint data into various domains that procure specific levels of security and assurance. Preventing leaking of information across these security domains is a very important concept to ensure, and all information that transverses between domains be scrubbed by appropriate mechanisms.

What Types of Exploitations Can Be Mitigated?

There are several types of exploitations that can be mitigated when implementing a multi-level domain access architecture. The first of these is a global privilege escalation, by which a user will execute an application that will run under privileges that it normally wouldn’t have the option of running under. The second is the Assumption of Atomicity, in which a security check is basically bypassed. Typically this is during a sliding window when the check is executed, when the exploit is called directly during that sliding window down time which would otherwise cause that check to detect the user interaction. Programs can also be trusting of the execution environment, so that all children application of a parent application will immediately inherit the permissions of their parent. These programs could also be accessing resources that are leveraging shared libraries which could in turn infect users across a variety of parent applications.

As stated in several other articles, the main purpose in a multi-level security environment is to procure an environment where there can be properly structured Mandatory Access Control.

Why Mandatory Access Control and The Mandatory Access Control Theory of Operation

The entire theory of operation for using a hybrid environment of SharePoint and SELinux is based upon the concept of procuring an environment that allows the birthing of Mandatory Access Control. The reason that Mandatory Access Control is at the heart of the theory of operation for the SELinux / SharePoint architecture is that conventional methods of DAC have proved to provide lower levels of unusable levels of object security. For a collaborative environment to be truly secure, it is necessary for it instead to have the option of not binding an identity to a system object but in effect provide segregation of various pieces of information in order to highlight the Confidentiality present within the CIA triad. This in turn would al the birthing of more effective measures that would promote the concept of integrity of the overall, aggregate system. The failure in DAC that ensues is due to the fact that DAC allows system decisions to be executed with the presence of simply an identity of a user, as well as the ownership of arbitrary files and objects that exist within the system. The concept of DAC is easily built up conceptually within the Windows Server architecture, the root account, typically a system account which has in essence the permissions that are granted to the local administrators security group, owns the system, whereas there are subsequent child users that can mimic this role, as well as sub users that are assigned arbitrarily to other roles within the server system. This is a faulty concept in that it allows various users to execute an N number of arbitrary programs and applications that might prove malicious to the collaboration environment, as well as it empowers various users (which can become somewhat impossible to track the granted permissions) power to give an N number of users access to the environment, and in this access to the objects and files that are housed within that system and all subsequent chains. Beyond this, there can always exist a power user, or a malicious root user, whom may corrupt a system needlessly for whatever intents and purposes. The concept of CAS (Code Access Security) also begins to take a small role because in code access security where are examining what foreign assemblies a specific binary may touch during run time execution, and within a DAC sponsored environment it is typical that the execution of relevant processes will simply inherit the permissions that are sponsored by the user (or, in effect, how the arbitrary process is tripped). This leads to inherit flaws within the environment since once the malicious process is tripped it can manipulate other objects permissions, its own permissions, or other subjects within the system’s permissions. This can easily lead to corruption of permissions within the environment, and in effect circumvent the granular permissions that are typically set within a network regarding the user of processes and objects. The inherent flow of DAC is that because of the sponsorship that is given to users they are allowed free reign within the enforcement of a possible corporate policy (not taking into consideration DRM such as IRM which can enforce somewhat global policy enforcement through a system but typically targeted for offline client access).

The largest goal that we seek to implement with a MAC based system is an overall security policy implementation that will enforce global rules across an environment. By using a detailed security policy that conforms to corporate goals and security requirements that assimilate regulatory and legal compliance requirements, we can ensure:

  • Secured Applications Are Protected
  • Separation of Privileges That Promote Sandboxed, Untrusted Application Execution
  • Vital and Essential Processes Are Assured Processing Space
  • Partitioning of Permissions Between Various Applications
  • Controlling Processing Limits
  • Control Privileges and Prevent Various Types of Privileges Escalation

The last of these are a significant security enhancement as opposed to DAC which is prime for an attack that would otherwise allow the concept of privilege escalation. DAC may immediately prove the first line of defense against attacks (in that objects and the system will still be bound to an identity.

This is not typically present within the OS’s that are provided by Microsoft since Windows Server is a closed kernel product, and to procure this type of security would require that there be direct hooks into the kernel, in effect negating the option for a developer to provide a hardened version of Windows that would otherwise be MAC compliant. Active support from the kernel is required at run-time for proper MAC to operate, since application layer mechanisms would could easily be circumvented because they are just that, assets that exist at the application level. However, by using Trusted Computing Mechanisms that are rather hooked into the hardware interface, one can provide the goals that we seek the building out a classified SharePoint environment, that of confidentiality most importantly, integrity of the data that is being stored within SharePoint, and the necessary separation of domains that will complete the CIA triad to provide assurance.

Transfer Data between SharePoint Security Domains

Within an arbitrary SELinux/SharePoint environment, there will eventually be the need for the option of traversing of data between various security domains, such as those that are classified and those that are unclassified. These is especially true when establishing an environment in SharePoint where a certain instance on a virtual machine that is deemed classified is transferring data to another that is deemed unclassified by definition. Since the overall Theory of Operation of a Hybrid SharePoint environment is that which utilizes various virtual machines in order to procure an environment that allows true classification of data, this is a present and substantial argument. This domain crossing can at times prove to be a hardware device, such as a perimeter based security device, perhaps something like a rudimentary firewall, however regardless of mechanisms of transfer, it is necessary to establish a data transfer functionality that will allow data to flow through defined, finely tuned, processing stages. This highly relates in the CIA triad to the concept of confidentiality, whereby the need for information to be secured throughout the entire information flow process is assured from start to finish. This is a built in concept within SELinux, which helps us to easily facilitate this.

Example of Security Based Enhancements Real World Application

A tangible example is often helpful when attempting to conceptualize the security benefits that SELinux provides. Assume that there is user A, which intends to trip a certain process, let’s assume a copy of a binary from unclassified SharePoint environment A to classified SharePoint environment B. The copy process, should, in essence, only have access to the specific binary it needs, not all binaries that exist within a computer, a typically problem that exists when leveraging a service account. In effect, the ownership of the assemblies should be properly separated, as opposed to universal access to what may be potentially unsafe information to share. By leveraging the concept of MAC, the copy process that is executed would provide a sandbox that allows the copy process to only touch and execute within its limits and permissions, it will only be allowed to perform the actions as defined with a security policy. Therefore, the copy process would become exploited by a malicious user, the only process that the malicious user could perform would be those that are deemed necessary be the service, regardless of the user account that the process is running under. This is regardless of as well if it is a service account that is offered root privileges on the environment. All objects are given a security policy defined sensitivity label that will determine how the process will interact with the system and the actions that are allowed on those arbitrary objects, allowing a tuned mechanism of control. The security context as presented with the copy argument can as well be presented to the networking concepts that may be related to a collaboration environment such as relevant ports, which can be bound to a security context as defined by a security policy. One of the largest reasons that an overall web server becomes compromised is that they are exploited initially through a port that is considered benign, whereas later the attacker once comprising the initial port will following open another port on the web server to execute further attacks on the SharePoint environment. In regards to the UNIX permissions that are existent within the SELinux environment, those permission still exist (the UNIX read/write, etc. permissions), however they are instead subject to the same security policies as discussed in the above section. The flow of access/denial is relatively straightforward and simple to follow the standard access / deny concepts exist. Since the deny UNIX will not allow any interaction, this does not require the consultation of the SELinux security policy, whatever it may be. However, if a successful access attempt is made, then the SELinux policy is consulted before access is granted.