MOSS 2007’s Security Features

Executive Summary:

More and more companies are using Web sites as internal collaboration tools, making it easy for employees to exchange information through documents and spreadsheets, and to host information or calendars. The data stored on these Web sites is often considered to be sensitive information, including salary information or even business secrets (e.g., new product launch plans). Many security administrators are now faced with the headache of trying to ensure the confidentiality, integrity, and availability of data on these collaboration Web sites.

Microsoft Office SharePoint Server (MOSS) 2007 includes a slew of features designed to secure collaboration Web sites that are built using it. Let’s explore how you can leverage these security features to secure your MOSS 2007 collaboration Web sites. For the purposes of this article, I'll assume that you understand MOSS 2007 and the concepts of Web application pools and Web site collections. Also, I'll focus on MOSS 2007 intranet collaboration Web sites and assume that Windows authentication is used.

Creating Secure Collaboration Web Sites
The earliest opportunity you have to influence the security of a MOSS 2007 collaboration Web site is when you create or extend a Web application through MOSS 2007’s Central Administration tool, which is located on the Application Management tab. Individual SharePoint Web sites that users browse to and interact with are created in Web applications. During the process of creating or extending a Web application, you’re prompted to configure MOSS 2007’s Security Configuration settings, as shown in Figure 1.

The first setting you have to configure when creating a new Web application is the authentication provider. Two authentication options are available: Kerberos and NT LAN Manager (NTLM). Although Kerberos is considered to be more secure than NTLM and is recommended by Microsoft, it requires the administrator to take additional steps to successfully configure MOSS 2007. See the “Configuring a Web Application to Use Kerberos” sidebar for more details. NTLM, the default option, is the easier of the two options to implement. However, it’s not considered as secure as Kerberos because when using it to authenticate to MOSS 2007, the client can't be sure of the server’s identity, which opens the door for man-in-the-middle (MITM) attacks. I recommend that you use Kerberos for Web applications with SharePoint Web sites that contain the organization’s most sensitive information.

However, choosing an authentication provider for a Web application is a somewhat moot point if you let anonymous users connect to sites in the Web application. You can configure the Allow Anonymous setting in the Security Configuration section of the Create New Web Application tab. The default option is No. This setting shouldn't be changed for two reasons. First, if someone has the ability to connect a laptop to your corporate network and you haven’t taken steps to restrict access to only domain-joined workstations, people outside your organization will be able to access your SharePoint sites. Second, if you let users access your SharePoint sites without authenticating, you’ll be unable to use MOSS 2007’s audit trails to track who accessed which sites and when they accessed those sites.

The last setting in the Security Configuration section that you’ll want to configure is whether to use Secure Sockets Layer (SSL) to encrypt communications between clients and MOSS 2007 sites. The default option is No. Without SSL, a malicious user with a network monitor might be able to capture traffic sent between a browser or other Web-enabled application and your SharePoint sites. To make use of SSL, you need to obtain and install SSL or Web certificates. You can obtain these certificates from a third-party Certificate Authority (CA) or install Microsoft Certificate Services. (Generating self-signed certificates isn't really an option because although they provide encryption, they don't prevent hackers from easily launching an MITM attack.) I recommend that you use SSL to secure traffic to and from Web applications that contain SharePoint sites with your most secure data.

There are other Web application settings on the Create New Web Application tab that have security implications, especially the Application Pool settings. You should create a new application pool for each Web application because Web applications and sites that share an application pool are vulnerable to information disclosure (or worse) if that pool crashes or is compromised. Also, each application pool should be configured to run using credentials that belong to a domain account that’s created specifically for that purpose. The domain account needs no special privileges. You should never use the Network Service special account for the application pool identity, especially in Web farms (where more than one server hosts a Web application) because of the security implications. When configuring database authentication, you should use Windows authentication, which is the default option.

After you’ve created your Web application, you can begin to populate it with sites. When creating a site collection, the principal security settings are those for the primary and secondary site collection administrators. The primary and secondary site collection administrators have the ability to manage site settings, including permissions and other security-related options. These administrator accounts should be dedicated accounts that are used only for configuring the site and not for day-to-day business operations, such as word processing, Web browsing, and application development.

If you have existing Web applications and sites that weren’t configured with security in mind, you can make changes to them using the stsadm.exe tool. A word of caution—this tool isn’t exactly user friendly. To learn more about how to use stsadm.exe, see the Windows IT Pro article “Stsadm: Taking Control of SharePoint Administration,” November 2007, http://www.windowsitpro.com/article/articleid/97107/stsadm-taking-control-of-sharepoint-administration.html.

Configuring Site and Document Library Security
After you've created a site, you can navigate to it using a browser when logged in as the primary or secondary site collection administrator. You can configure permissions and other security settings by clicking the Site Actions drop-down list and selecting Site Settings. Settings on the Site Settings page are grouped into five sections: Users and Permissions, Look and Feel, Galleries, Site Administration, and Site Collection Administration.

Settings in the Users and Permissions section are used to not only grant users access to the collaboration Web site and define the permissions that they have, but also to identify site administrators. Clicking People and Groups takes you to the People and Groups: Site Members page where you can add, change, or delete users and the permissions they have to the site. A Web form displays users and groups and their permissions. To add users and groups from Active Directory (AD), select New or click the drop-down box next to New and select Add Users, which takes you to the Add Users page that Figure 2 shows. You can click Add all authenticated users to add all authenticated users (i.e., anyone with an account in AD) to the site. Also, you can choose whether to add the users to a SharePoint group, which is the default option, or to define permissions explicitly.

When you create a site, several SharePoint groups are created that are granted View, Read, Contribute, and Full Control rights. You can add new SharePoint groups by clicking People and Groups, New, New Group. This functionality is extremely useful when setting permissions on libraries, which I'll describe later. I recommend that you use SharePoint groups rather than individual permissions because it’s easier to track permissions when you use groups. When you select People and Groups or Advanced permissions, the SharePoint groups are listed on the left of the page. When you select a group, the members of that group are listed for easy viewing and maintenance.

There’s a subtle difference between the View and Read permissions. Users with Read access can read all the content on the site (unless more restrictive permissions are in place), whereas users with View access can view only content that can be rendered in the Web browser. If a user attempts to open a document that can’t be displayed as HTML or converted by MOSS 2007 to HTML, he or she will be unable to view that document. Figure 2 shows all authenticated users being granted Contribute access to a site. To remove users or groups from a site, simply select the group they belong to from People and Groups, select the users’ names, click the Actions drop-down list, and select Remove Users from Group.

Libraries on a collaboration site can have security settings independent of the site itself. To set permissions for a library, browse to the library, then click the Settings drop-down list and select Document Library Settings. The settings are categorized into four sections: General Settings, Permissions and Management, Communications, and Columns. In the Permissions and Management section, you’ll find the Permissions for this library link. If you click Permissions for this library, you’ll see that permissions are inherited from the site the library is in, and there’s a warning bar across the top of the Web page to this effect. If you want to change a library’s permissions, you must click the Actions drop-down list and select Edit Permissions. When you edit permissions, a dialog box warns you that permissions from the parent will no longer be inherited by the library. Note that once you edit a library’s permissions, changes made to the parent site’s permissions won’t be reflected in the library, including the additions of new SharePoint groups. If you intend to use your own SharePoint groups at the library level for permissions, you’ll need to create them at the site level first, before editing a library’s permissions. You’ll also need to grant the SharePoint group rights to the site. The rights granted to a SharePoint group at the site level can be independent from the rights granted to the same group at the library level. You can also grant permissions to users or groups from AD to a library directly by clicking New, entering the names of users and group, and selecting the permissions that they have.

It’s also possible to configure security settings on individual documents in a document library. You can do so by selecting an item in a library, then selecting Manage Permissions from the item’s drop-down menu. By default, items inherit their permissions from the libraries that they’re stored in. You can override the permissions by copying the library’s permissions (select Edit Permissions from the Actions menu on the Permissions page) and editing them.

If you’ve configured MOSS 2007 to make use of Rights Management Services (RMS), you’ll also find Information Rights Management (IRM) options for a library under the Permissions and Management section. If you configure IRM for a library, content downloaded from the library will be encrypted; only users with access to the library will have access to the content with the same rights that they have to the library. For example, users with Read access to a document library with IRM properly configured will have only Read rights to a document that they download, meaning they won’t be able to modify it, even though it’s outside the library. For more information about MOSS 2007 and RMS integration, see “Microsoft Office SharePoint Server 2007 and RMS,” July 2007, http://www.windowsitpro.com/article/articleid/96138/microsoft-office-sharepoint-server-2007-and-rms.html.

Auditing Site and Library Access
In MOSS 2007, primary and secondary site collection administrators can configure site and library auditing. To configure auditing for the entire site, including all the libraries under the site, select Site Settings from the Site Actions drop-down menu, then select Site collection audit settings under the Site Collection Administration category. Next, select which events you want to audit in the Document and Items section and the Lists, Libraries and Sites section (shown in Figure 3), and click OK.

If you want to audit events on a library-by-library basis, you can do so by creating a site collection policy with auditing events. To create a policy, click Site collection policies under Site Collection Administration, then click Create. You’ll need to specify a policy name and have the option to enter a description and policy statement, as shown in Figure 4. If you’ve configured auditing for the entire site, you’ll see a caution message displayed under the Enable Auditing check box. Select the Enable Auditing check box and the check boxes next to the events you want to audit, and click OK. After you've created a site collection policy, you can apply it to a library by entering the library’s settings, clicking Information management policy settings under the Permissions and Management section, clicking the Use a site collection policy radio button, and selecting the policy from the drop-down list of policies.

You can view audit reports by clicking Audit log reports in the site’s Site Collection Administration section. Several predefined reports are available, or you can create a custom report. When you select a report, an XML file is generated and rendered on the client in Microsoft Excel by default. Figure 5 shows an audit report. The audit report is displayed on two tabs: The Audit Data – Table tab shows a summary of the report, and the Report Data 1 tab shows the raw data. Note that reports have a lot of extraneous data, so you might have to spend some time going through them looking for audited events of potential interest.

Site Collection Policies and Document Hygiene
As I already outlined, site collection policies can be used to configure auditing on a per-library basis. In addition to auditing, you can configure a site collection policy to enforce the addition of labels and barcodes to Office 2007 documents saved to or printed from a library. Labels and barcodes are useful for controlling the distribution and tracking of printed documents. Users are less likely to print and distribute a sensitive document if there’s an onscreen reminder of a policy and if the printed document contains visual clues or statements as to its sensitivity.

Labels are images created from text strings you define in the policy. Labels can include variables whose values are drawn from the document’s properties. To insert a label in a document, select the Enable Labels check box and the Prompt users to insert a label before saving or printing check box. When a user attempts to save or print a document in a library that doesn’t already have a label, the user is prompted to insert the label into the document. Labels are inserted into the headers of documents by default. If the Prevent changes to labels after they are added check box has been selected, the user can’t remove a label from the document. If you select the Enable Barcodes check box, users are forced to insert a barcode into a document if the document doesn’t already have one when saving or printing the document. Barcodes are also stored in the document’s properties and can be viewed in the document library when viewing the document’s properties. Figure 6 shows a document that includes both a label and a barcode. Note that in Word 2007, the site collection policy is displayed as a visual cue to users.

However, for labels and barcodes to work, you need to create the library with a supported Office 2007 default document, and the policy needs to be applied to the library before any documents are placed into it. If a new or updated policy is applied to a document library, existing documents and documents created and edited by applications other than Office 2007 won’t have the policy applied to them.

Many administrators are aware of the potential for malware to spread through email systems but aren’t as aware of the potential for collaboration Web sites to facilitate the distribution of malware. MOSS 2007 addresses this concern by exposing an interface and APIs for Microsoft and third-party anti-malware products to integrate and ensure document hygiene.

MOSS 2007’s major security features can be leveraged when building internal collaboration Web sites to ensure their security and to provide an audit trail showing user access to hosted content. For more information about MOSS 2007’s security features, go to http://www.microsoft.com/sharepoint.