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:

http://www.microsoft.com/downloads/details.aspx?familyid=A154648C-881A-41DA-8455-042D7033372B&displaylang=en

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.

Share

SharePoint Password Policy Template

Introduction – SharePoint Portal Password Policy SharePoint user authentication is a means to control who has access to the SharePoint environment. SharePoint access gained by a non-authorized entity can cause loss of information confidentiality, integrity and availability that may result in loss of revenue, liability, loss of trust, or embarrassment to [Organization].
Purpose The purpose of the [Organization] SharePoint Password Policy is to establish the rules for the creation, distribution, safeguarding, termination, and reclamation of the [Organization] user authentication mechanisms.
Audience The [Organization] SharePoint Password Policy applies equally to all individuals who use any [Organization] SharePoint resource.
SharePoint Portal Password Policy All SharePoint user passwords, including initial passwords, must be constructed and implemented according to the following [Organization] rules:

  • it must be routinely changed
  • it must adhere to a minimum length as established by [Organization]
  • it must be a combination of alpha and numeric characters it must not be anything that can easily tied back to the account owner such as: user name, social security number, nickname, relative’s names, birth date, etc.
  • it must not be dictionary words or acronyms password history must be kept to prevent the reuse of a password Stored passwords must be encrypted, including maintaining encryption standards on the SharePoint SSO database.
  • SharePoint user account passwords must not be divulged to anyone.
  • SharePoint Portal Owning Organization] contractors will not ask for user account passwords.

Security tokens (i.e. Smartcard) must be returned on demand or upon termination of the relationship with [Organization].

If the security of a password is in doubt, the password must be changed immediately.

Administrators must not circumvent the Password Policy for the sake of ease of use.

Users cannot circumvent SharePoint password entry with auto logon, application remembering, embedded scripts or hardcoded passwords in client software. Exceptions may be made for specific SharePoint applications (like automated backup or SSO) with the approval of the [Organization]. In order for an exception to be approved there must be a procedure to change the passwords.

SharePoint aware devices must not be left unattended without enabling a password protected screensaver or logging off of the device.

SharePoint password change procedures:

  • authenticate the user to the [Organization] helpdesk before changing password
  • change to a strong password
  • the user must change password at first login

In the event SharePoint passwords are found or discovered, the following steps must be taken:

  • Report the discovery to the [Organization] Help Desk
  • Take control of the passwords and protect them
  • Transfer the passwords to an authorized person as directed by the [Organization]
SharePoint Portal Password Policy
  • Passwords must be changed at least every 60 days.
  • Passwords must have a minimum length of 8 alphanumeric characters.
  • Passwords must contain a mix of upper and lower case characters and have at least 2 numeric characters.The numeric characters must not be at the beginning or the end of the password. Special characters should be included in the password where the computing system permits. The special characters are (!@#$%^&*_+=?/~`;:,<>|).
  • Passwords must not be easy to guess
  • Passwords must not be your employee number
  • Passwords must not be your name
  • Passwords must not be family member names
  • Passwords must not be your nickname
  • Passwords must not be your social security number
  • Passwords must not be your birthday
  • Passwords must not be your license plate number
  • Passwords must not be your pet’s name
  • Passwords must not be your address
  • Passwords must not be your phone number
  • Passwords must not be the name of your town or city
  • Passwords must not be the name of your department
  • Passwords must not be street names
  • Passwords must not be makes or models of vehicles
  • Passwords must not be slang words
  • Passwords must not be obscenities
  • Passwords must not be technical terms
  • Passwords must not be school names, school mascote, or school slogans
  • Passwords must not be any information about you that is known or is easy to learn
  • Passwords must not be any popular acronyms
  • Passwords must not be words that appear in a dictionary
  • Passwords must not be reused for a period of one year
  • Passwords must not be shared with anyone
  • Passwords must be treated as confidential information
SharePoint Portal Password Policy Supporting Information
  • Any and all [Organization] SharePoint security controls must not be bypassed or disabled.
  • SharePoint Security awareness by [Organization] personnel must be continually emphasized, reinforced, updated and validated.
  • All [Organization] SharePoint users are responsible for managing their use of SharePoint and are accountable for their actions relating to SharePoint security. Users are also equally responsible for reporting any suspected or confirmed violations of this policy to the appropriate management responsible for SharePoint security incident handling.
  • User SharePoint account passwords shall be protected by the individual user from use by, or disclosure to, any other individual or organization. All security violations shall be reported to respectful SharePoint security incident handling management.
  • Access to, change to, and use of SharePoint Account Managmenet Policy must be strictly secured. SharePoint information access authority for each user must be reviewed on a regular basis, as well as each job status change such as: a transfer, promotion, demotion, or termination of service.
  • On termination of the relationship with the Sharepoint user all security policies for [Organization] apply and remain in force surviving the terminated relationship.
  • [Organization] server custodian departments must provide adequate access controls in order to monitor SharePoint systems to protect business data and associated programs from misuse in accordance with the needs defined by owner departments. All SharePoint access must be properly documented, authorized and controlled, following [Organization] standardized processes.
Disciplinary Actions Violation of this policy may result in disciplinary action which may include termination for employees and temporaries; a termination of employment relations in the case of contractors or consultants; dismissal for interns and volunteers; or suspension or expulsion in the case of a student. Additionally, individuals are subject to loss of [Organization] SharePoint access privileges, civil, and criminal prosecution.
Compliance / Regulation Contributed to by this Policy
  • Copyright Act of 1976
  • Foreign Corrupt Practices Act of 1977
  • Computer Fraud and Abuse Act of 1986
  • Computer Security Act of 1987
  • The Health Insurance Portability and Accountability Act of 1996 (HIPAA)
Share

What is Disaster Recovery in Relation To SharePoint?

* This article was written in the context of System Center Data Protection Manager 2006 (SCDPM), a technology now considered deprecated with the introduction of System Center Data Protection Manager 2007. Variations may exist. *

What is Disaster Recovery in Relation To SharePoint?
Disaster recovery in relation to SharePoint can mean many things, depending on the organization. Different enterprises use SharePoint for different purposes, ranging from implementing it solely for collaborating and communicating within virtual teams to using it solely for hooks into other server systems such as Team Foundation Server or Project Server. For whatever reason a company uses SharePoint, it is clear that there needs to be policies in place that will facilitate disaster recovery in the event that something may cause massive data loss for your portal. In essence, DR in relation to SharePoint can generally be thought of as processes, mechanisms, and policies that if data loss does occur for whatever reason that disrupts the portal to an irretrievable state it can quickly be returned to operational efficiency with little effort.
 
Why Should I Be Concerned With Disaster Recovery?
Disaster recovery can be an issue at many levels. Damage could inflict SharePoint file stores, custom development (ASP.NET 2.0 WebParts, SharePoint WebParts, or Framed Applications), design / branding efforts (master pages, manual modifications), and most importantly your stored business data. Without a disaster recovery policy and DR tools, your SharePoint environment can quickly become a central portion of business processes within an enterprise to a useless system leaving a bad taste in user’s mouth bringing SharePoint adoption to a standstill.
 
What Can I Do To Prepare for Proper Disaster Recovery?
There are several mechanisms that should be implemented in order to prepare for a disaster recovery situation. Some of which deal with implementing a proper disaster recovery policy, others are for implementing various types of software that will help to facilitate bringing your portal backup to speed if there is an event of large data loss.
 
What Types of Disaster Recovery Software Are Available?
There are several types of disaster recovery software that are based on varying types of software theories. In relation to the actually physical archiving of backup data, the three most popular are:
  1. Disk-to-Tape (DtT)
  2. Disk-to-Disk (DtD)
  3. Disk-to-Disk-to-Tape (DtDtT) 
Three of the most popular types of software are:
  1. RTR (Real Time Replication)
  2. CDP (Continuous Data Protection)
  3. DPM (Data Protection Manager)
How do I Choose the Appropriate Software for Disaster Recovery?
The software that you choose for your disaster recovery policy varies heavily on your organization. Some of the decision factors will be based on company cultural, some on functionality that you desire out of your DR bundles. As an example of cultural decisions, some shops will only implement Microsoft-centric software since it will generally build on and into other server packages and client software (as is the case with the Microsoft Operations Framework, since DPM will tie into Microsoft Operations Manager for management and reporting purposes), and is typically part of their Microsoft enterprise agreement(s). Some organizations are indifferent to the vendor, and are more concerned with varying functionality. When looking at replication or disaster recovery solutions, quick decisions are never the best ones. You have to examine each package in relation to your SharePoint environment, and possibly other systems that might be sheltered by the same solution.
 
Why is SharePoint a Difficult Product to Implement Disaster Recovery for?
SharePoint as a platform is subject to constant change, users uploading, modifying, and deleting documentation and other relevant portal assets, customizations being made to different site collections, and new portions of the portal being extended and de-extending everyday at every hour. Implementing disaster recovery for an environment that requires such an extent of synchronous backups during such intensive intervals during normal user hours is incredibly difficult. Ensuring that data is constantly intact in such a largely user adopted platform can also be problematic since the platform is almost constantly in use.
 
Is the Disaster Recovery Process a Task of a SharePoint Administrator, Network Administrator, or Users?
Protecting the assets of the portal is the responsibility of all of the above parties, and doesn’t all solely on the shoulders of just one position or person. The SharePoint administrator is typically most familiar with the status of the database and overall environment, the network administrator knows bandwidth usage and disk allocation within the network, and the users of the portal are typically the most familiar regarding specific assets within arbitrary site collections. The restore process depending on what has been lost can be the responsibility of either of the parties as well, as long as the process as it is tripped is documented, and doesn’t interfere with other SharePoint user activities.
 
What Does a Disaster Recover Policy Consistent of for SharePoint?
Here is a sample disaster recovery policy for SharePoint. It might have to be tailored to your environment more depending on what your corporate standards are, but will still be a good start. It is free to use with no copyright restrictions.
 
Is There Specific Disaster Recovery Software Exclusive To SharePoint?
There is no disaster recovery software made explicitly for SharePoint. However, such packages as Data Protection Manager are easily tailored to implement disaster recovery for a SharePoint environment, and can shelter other systems as well.
 
What Are the Prices of Disaster Recovery Software?
Disaster Recovery software can range from relatively cheap to exceedingly expensive and can depend on certain agreements with certain vendors (such as having enterprise agreements within Microsoft). It depends on what level of functionality you are seeking from the software. With real-time-replication, you can recover data within minutes of a disaster, but is not cost effective for small-to-medium (SMS&P) businesses, whereas DPM will be an hourly solution, but several thousands of dollars less and is relatively inexpensive to extend (buy more agents for) and maintain.
Share