Information Security Policies for SharePoint Products and Technologies

Article
02/20/2014

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Published: June 9, 2004

This is a sample chapter from the Microsoft SharePoint Products and Technologies Resource Kit. You can obtain the complete resource kit (ISBN 0-7356-1881-X), which includes a companion CD-ROM, from Microsoft Press.

In today’s world, you cannot really secure a network without having information security policies in place. Such policies are really business rules—rules that define acceptable and sometimes required behavior regarding your company’s information. Information security policies continue to become more complex because the technologies that host an organization’s mission-critical information are also becoming more complex every year, if not every month. From cell phones to laptops, from PDAs to servers, the access vectors and potential security holes are increasing as the technology complexity increases. Information security policies are one method of plugging many security holes by prescribing acceptable behavior as information is developed and stored.

The more an organization follows information security policies, the more dependent an organization becomes on these rules in a host of situations, such as guiding a manager on acceptable behavior about how information is accessed, informing a legal team as to whether a manager has performed due diligence, or acting as reference documents for internal security audits.

Some will say that the problem with information security policies is that the rules are only as effective as the people who obey them. But the presence of information security policies in an organization is fast becoming a legal assumption: those companies that operate without information security policies (hereafter referred to simply as policies) might be subject to the charge that reasonable care for an organization’s information was not executed. Regardless of an organization’s size, purpose, or location, effective information security is vital, so we are covering it in this resource kit.

The purpose of this chapter is to outline those types of policies that should be considered when implementing either Microsoft Windows SharePoint Services or Microsoft Office SharePoint Portal Server 2003. Our purpose is not to write the policies for you or even to give you a sample set of policies from which to work, but rather to highlight the types of policies that will be affected when implementing SharePoint Products and Technologies.

Password Policies

Because SharePoint Products and Technologies require domain services for authentication, it is wise to have password policies in place for your network. In all likelihood, if you have any policies in place in your organization, chances are good that you already have policies that address the issues listed in this section. However, the implementation of SharePoint Products and Technologies is an appropriate time to review those policies because most of the information held in SharePoint Products and Technologies can be compromised by obtaining a SharePoint-pervasive username and password combination.

Like most policy domain areas, there are sub-areas that should be addressed as the policies are written. Password policies are no exception. The following are some of the issues to be considered when developing your password policies:

Minimum password length
Password complexity and strength
Prohibition of reusing old passwords
Prohibition of written storage of passwords
Prohibition against printing or displaying passwords
Periodic forced change in passwords
Method to manage expired passwords
Authorized means to transmit new passwords to remote users
Limits on consecutive attempts to enter a password
Acceptance or prohibition of single sign-on services
Prohibition of passwords sent through e-mail
Requirement for encrypted storage of passwords
Reliance on domain services for authentication
Requirement for non-anonymous authentication before access to information is allowed
Use of duress passwords (Duress passwords trigger scripts during a duress situation—that is, if a gun is pointed at your head and you are asked to log on to the server, a duress password would log you on, but because of the password entered, a script would be triggered to delete all predetermined sensitive data.)
Requirement to change all administrative passwords if any have been compromised
Password sharing prohibition
User responsibility for all actions taken with his username and password combination
Security notice in logon system banner
Prohibition against leaving systems without logging off or locking the system
Use of biometric devices required for logon to portal
Use of smartcard devices required for logon to portal system

Throughout this chapter, we will introduce issues that should be considered when writing your policies. Each issue introduced might or might not apply to your environment. For example, some organizations might have a strong password complexity policy while another environment might not due to culture, industry, or other factors. We are not recommending that each issue be implemented as presented here, only that each issue should be considered as the policies are written.

Most of these issues relating to password policies should be covered in your network policy, but one that directly affects SharePoint Products and Technologies is the single sign-on policy. If your organization prohibits single sign-on capabilities, meaning that users must log on to each application that requires unique authentication, you will be unable to use the single sign-on feature in SharePoint Portal Server 2003.

Also, the Active Directory Mode feature of Windows SharePoint Services needs to be considered in a Windows SharePoint Services–only installation. Given that this feature allows site administrators the ability to create new user accounts in Active Directory, if you are going to use this feature, you should have policies surrounding who can be a site administrator and under what circumstances a new user account can be created in Active Directory from a Windows SharePoint Services site.

In addition, if you are going to use SharePoint Products and Technologies in an extranet environment—especially for its customer relationship features—in which users outside your company will be authenticating in your domain to access their portion of the portal site, implementation of a policy specifying how you will securely transmit passwords to those users and whether or not e-mail may be used will have paramount importance.

Moreover, in situations in which you will be sharing sensitive information with other companies (maybe even competitors), you will probably want a robust set of password policies to be required by all parties to the agreement, necessitating the development of such policies before the project can begin.

As we mentioned previously, much of the information in SharePoint Products and Technologies is secured only through username and password combinations. The compromise of passwords in your environment could lead to sensitive information being exposed to the wrong people and this, in most cases, would be disastrous.

Personal Use of Sites

We would like to think there is no need to mention this, but it is possible that users will create their own websites, give only themselves permission to the site, and then use that site for private purposes. The authors of this resource kit know of multiple times when a company’s servers were used to set up Internet-based businesses without the knowledge of or the consent of the company’s owners.

Creating policies that prohibit personal use of company systems will help prevent this problem. Few things irritate system administrators more than the misuse of company systems for personal gain at the expense of system performance, storage space, and additional administrative effort.

Because it will be very easy—especially for the SharePoint Products and Technologies administrators—to set up personal websites (we are not referring to the My Site feature here, but rather to rogue Windows SharePoint Services sites) for personal gain (if you have enabled Self-Service Site creation or if the user is already a member of the Administrator site group in a site), a strict prohibition should be approved by your managers and then communicated to your users as part of their SharePoint Products and Technologies training.

The following issues should be addressed in this domain:

Use of SharePoint Products and Technologies sites for personal use is strictly prohibited.
Personal use of computers is prohibited.
Incidental personal use of business systems is permissible. (Consider this issue only if your users are allowed to use company systems for personal use.)
Storage of personal data is prohibited on company systems.

You might have noticed that the third bullet point contradicts the others. We include this point to emphasize that in certain situations, some personal use of computers and SharePoint Products and Technologies will be permissible. We can think of nonprofits who allow their employees to host in-kind websites to the organization’s mission after gaining approval. Again, this list is not meant to dictate what should and should not be in your policies, but rather to alert you to the issues that should be considered when writing these policies.

Information Storage Policies

Because more and more mobile devices, such as laptops, PDAs, and Tablet PCs (along with older technologies, such as floppy disks), will be connecting to your SharePoint sites, it is important to define what types of devices can permanently hold your mission-critical information. The last thing you want is a member of the Compensation Committee Site downloading sensitive information to an unsecured PDA and then leaving that device in an airport or hotel. It would be an understatement to say that this is an undesirable scenario for any organization.

Therefore, you should consider the following issues when it comes to how your mission-critical, private, secret, or sensitive information is stored:

Acceptable use of mobile devices.
No sensitive information on mobile devices.
Definition of what a mobile device is.
Mobile devices must store all information in encrypted form.
Mobile devices must be password-protected.
Default permissions for all files on the network.
No write-down permissions for company information.
Information ownership must be assigned.
Prohibition of taking ownership of information without authorization.

Administrative Policies

In many organizations, we often find that there is poor communication between the human resources department and the system administration people. Reasons for this vary from company to company, but it is common for the system administrators to be some of the last people to learn that a person has changed departments or has left the company.

In SharePoint Portal Server 2003, when a user account is deleted in Active Directory, that deletion is not implemented in the user profile database in SharePoint Portal Server 2003. Even though the account is marked for deletion in the user profile database, those accounts must still be deleted manually by a SharePoint administrator.

If you need to remove a user’s profile from the user profile database before it is removed through a full import, you will need to propagate policies to this effect. In this domain area, here are some issues to consider:

Worker status changes are sent to System Administrators in a timely fashion.
Users must inform System Administrators about changes in status.
Transfer of ownership of information after user leaves company.
Schedule of file deletion after user leaves company.
User notifications need to be cleaned up by the SharePoint Administrator.

Logging Events

One of the ways to troubleshoot any system is to have a robust logging system in place that can help you troubleshoot problems should they arise. One area to log for SharePoint Products and Technologies is the Internet Information Services (IIS) platform. Because all of the client calls will come through IIS to the Windows SharePoint Services filter, you can capture who is connecting, when they are connecting, and which pages they are requesting. In addition, you can purchase third-party software that will give you more vigorous reporting capabilities.

Logging is also a security concern because you can track attack vectors that hackers might use to compromise your system. A robust logging system is essential for good security, and those logging policies to be considered that relate to SharePoint Products and Technologies include the following:

Logs are required for all application systems that host sensitive information.
Logs must support auditing requirements.
Logs must provide accountability and traceability during an audit.
Content of SharePoint Products and Technologies logs must include specified information.
Required retention period for logs.
Information to capture when a compromise is suspected.
Logging required before a system can be placed in the production domain.
Clock synchronization on all SharePoint Products and Technologies servers with a master clock of all servers in production domain.
Persons authorized to view logs.
Logs must be reviewed on a regular basis by authorized personnel.

Authorized Web Parts and Applications

Because SharePoint Products and Technologies is designed with a distributed administrative architecture, it is important to remember that authorized users will be able to install Web Parts on a site. It would be very easy for authorized users to download Web Parts that have been created on the Internet and then install those parts on their sites. Remember that site and portal administrators delegate the right to add Web Parts to a Web Parts page, and there are protections in place for the administrator to control how much a Web Part can do. Liberal delegation of this right might lead to compromised security in your SharePoint implementation. Unsuspecting users could download an infected or a compromised Web Part, install it, and expose your critical information to hackers on the outside.

Because of this potential vulnerability, you should seriously consider restricting which software can and cannot be installed in SharePoint Products and Technologies. Points to consider when creating policies in this area include the following:

Prohibition against downloading third-party software to your corporate systems.
Requirement to scan downloaded Web Parts before use in a production system.
Testing for viruses must be performed on a non-cabled, stand-alone server.
Multiple virus screenings must be performed on all downloaded software from the Internet to corporate systems.
Virus scanning software must be employed on all SharePoint Products and Technologies systems.
Requirement to run all third-party Web Parts in a test environment prior to deployment in a production environment.

Change Control

Because SharePoint Products and Technologies will be hosting some of your most mission- critical and sensitive information, it is best to ensure that you have a strong change control program in place for your servers. By controlling who can make administrative modifications to your system, you can maintain stability in your production environment and ensure that only authorized changes are made to your systems.

Pay attention to the Site Collection Use And Confirmation feature that allows SharePoint Products and Technologies to automatically delete a site collection if site use is not confirmed by the site owners after a specified number of days. In many environments, automatic deletion of entire site collections will be unacceptable. You will want to factor into your policies the exact settings you wish to have for this feature because an undesired configuration could result in the loss of a site collection.

This area actually touches a number of security policy areas, including backup and restore, information retention times, and change control. The topic is introduced here because the deletion of a site collection is significant, and the fact that this deletion can be automated makes this a more important consideration when you create your policies.

Considerations that will have particular interest to your SharePoint administrators include the following:

Formal change control procedure is required for all administrative changes.
System changes must be consistent with overall security architecture.
Training is required before authorization will be given to administrate a site, portal, or server.
Changes on supporting systems must be tested before introduction into production systems.
Automatic deletion of content is prohibited.
Automatic deletion of content is allowed only after content is backed up.

Information Privacy

While it might seem obvious, you should spell out in your policies who actually owns content that is developed in your SharePoint Products and Technologies systems and who owns the intellectual rights to that information.

In most organizations, this has already been explained in a policy. But best practice would say to include the SharePoint Products and Technologies systems in that policy. If you have not done so, here are some topics to consider for inclusion in information privacy policies:

Right of management to examine data on SharePoint Products and Technologies systems.
Company ownership of all content developed on company-owned systems.
Right of company, without notification, to add system administrators to sites as administrators.
Permissible information to collect on employees when creating a contacts list.
Permissible information to disclose on self in the My Site area.
Expressions of personal views in My Site.
Information about children of employees may not be collected.
Requirement of disclaimer when collecting information.
Existence of personnel records in SharePoint Products and Technologies prohibited without proper security.
Disclosure of worker change of status notification.
Marketing or promotion of employee-owned businesses prohibited on company systems.

Data Classification Schemes

Different firms have different levels of confidentiality, but it is certainly worth assigning a security level to every document in your organization so that workers know how to handle the data. As the document is developed in SharePoint Products and Technologies, the security level of the document can become a defining (and indexable) piece of metadata. Most classification schemes use one or more of the following document categories: public, confidential, secret, and private. Each organization will have its own scheme, and our point is not that you should copy what we have written here, but instead that you implement a classification scheme and then use that scheme as new information is developed. Because most content that is developed is automatically considered confidential, it might be important in your organization to spell that out to those content developers. Doing so will ensure that they do not disseminate confidential information.

Items to consider when developing this policy include the following:

Data classification scheme is required for all company data.
Labeling requirements for all company data.
Information is treated as confidential whenever the classification is unknown.
Departments may create additional classifications if authorized.
Content developers are responsible to assign data classification to all documents during development.
Owner of content must meet classification requirements.
Declassification of content must follow prescribed procedures.
Co-presenting of different classified content prohibited.
Classified content must be hosted in SharePoint Products and Technologies sites with required permissions.

Extranet Considerations

When users connect over the Internet, a whole new set of security issues is introduced. If you already have external connection security policies in place, chances are good that they will apply to SharePoint Products and Technologies and will cover a user’s connection to the portal site. Port 80 is the most often attacked port, and even with the use of Secure Sockets Layer (SSL), external connections offer an obvious attack vector to a would-be hacker. Creating policies that detail acceptable behavior for your users when they connect to the portal site will help ensure that their connection is done securely.

If you do not already have such policies in place, consider the following:

All Internet Web servers must be firewall protected.
SharePoint Products and Technologies servers must be in the perimeter network.
Internet portal servers must be placed on a separate subnet.
Connection to intranet portal servers from the Internet requires encryption and certificates.
Employee-owned computers must meet minimum software requirements.
Vendor connectivity to intranet from the Internet is prohibited.
Customer connectivity to customer sites from the Internet requires encryption and certificates.

Summary

In this chapter, we have discussed information security policy considerations as they relate to SharePoint Products and Technologies. It is important to remember that there is a host of other policies that should be written if you want to create an effective set of policies for your company. The introduction of SharePoint Products and Technologies into any environment presents some unique security challenges that should be considered before you deploy SharePoint Products and Technologies in your production environment.