Research

Publication Date: 23 February 2009 ID Number: G00165026

Security Considerations and Best Practices for Securing

SharePoint
Neil MacDonald, Adam Hils

Microsoft SharePoint is widely deployed as an enterprise collaboration and productivity

tool, yet many deployments lack a formal SharePoint security strategy. This document
provides specific recommendations for deploying SharePoint to minimize security risk.
Any organization deploying SharePoint should be aware of potential SharePoint security
issues and recommendations to address them to prevent the exposure of sensitive
information assets.

Key Findings
Properly securing SharePoint requires an information-centric (not device- or network-
centric) mind-set for protecting content throughout its life cycle.

Microsoft's SharePoint security mechanisms are flexible, but with this flexibility comes
complexity and an increased chance for misconfiguration.

SharePoint is often deployed to store and share information copied from production
systems (such as enterprise resource planning [ERP]), but the access controls are not
carried over, leaving sensitive information exposed.

SharePoint is widely deployed to collaborate with external partners without adequately

considering how these users will be managed, as well as the placement and protection
of SharePoint servers.

Recommendations
For information security professionals:

If an initial SharePoint project is planned for your organization in 2009, get involved now
in SharePoint configuration, planning and implementation discussions, and use the
guidelines in this research to proactively address potential security issues before
deployment.

If SharePoint is already deployed, use this research as a framework to assess the more
serious security issues we have seen in the production deployments of our clients.

In all cases, security configuration guidelines and policies for SharePoint should be
established, and adherence to policy regularly confirmed.

For larger deployments with multiple usage patterns, develop a set of SharePoint use
cases that include appropriate security configuration and policy.
For operations teams responsible for SharePoint:

2009 Gartner, Inc. and/or its Affiliates. All Rights Reserved. Reproduction and distribution of this publication in any form
without prior written permission is forbidden. The information contained herein has been obtained from sources believed to
be reliable. Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such information. Although
Gartner's research may discuss legal issues related to the information technology business, Gartner does not provide legal
advice or services and its research should not be construed or used as such. Gartner shall have no liability for errors,
omissions or inadequacies in the information contained herein or for interpretations thereof. The opinions expressed herein
are subject to change without notice.
 Involve your information security team in the planning phases and use the best practices
outlined in this research as a way to frame the discussion of securing SharePoint.

In some cases, changes to processes and tools may be required.

Publication Date: 23 February 2009/ID Number: G00165026 Page 2 of 20

2009 Gartner, Inc. and/or its Affiliates. All Rights Reserved.
TABLE OF CONTENTS

Analysis ............................................................................................................................................. 4
1.0 Basic SharePoint Physical and Logical Architecture..................................................... 4
2.0 Security Policy and Governance Issues......................................................................... 6
3.0 SharePoint Access Control Issues ................................................................................. 7
4.0 SharePoint Information Protection Issues .................................................................... 11
5.0 SharePoint Network and Server Protection Issues ...................................................... 15
Recommended Reading.................................................................................................................. 18

LIST OF FIGURES

Figure 1. The Multitiered Architecture of SharePoint ........................................................................ 5

Figure 2. SharePoint Hierarchy ......................................................................................................... 6
Figure 3. Pros and Cons of Alternatives to Data Encryption in SharePoint .................................... 14

Publication Date: 23 February 2009/ID Number: G00165026 Page 3 of 20

2009 Gartner, Inc. and/or its Affiliates. All Rights Reserved.
ANALYSIS

SharePoint serves a very important business need to provide a collaboration infrastructure for
people to share information internally and externally. However, many SharePoint deployments
have been set up without fully considering the security implications of their deployment, or, in
other cases, only basic, insufficient guidelines were followed.

1.0 Basic SharePoint Physical and Logical Architecture

This research is not a tutorial on SharePoint. Multiple sources provide a number of detailed
SharePoint configuration and security resources on the Internet, including Microsoft (see Note 1).
A brief review of SharePoint concepts may be needed to facilitate understanding the security
issues in SharePoint deployments and our recommendations for addressing them. From a
networked application perspective, SharePoint is a multitier enterprise application composed of a
Windows Internet Information Server (IIS) Web front end, various ASP.NET Web applications that
run within IIS Web servers and back-end SQL Server databases used to store the SharePoint
configuration and access control database and SharePoint content (see Figure 1). All of this
could be run on a single server, but is typically broken out across several servers, configured as a
server farm.

Publication Date: 23 February 2009/ID Number: G00165026 Page 4 of 20

2009 Gartner, Inc. and/or its Affiliates. All Rights Reserved.
Figure 1. The Multitiered Architecture of SharePoint

Users

Tier 1:
IIS Web Front-End
Servers

Tier 2: Index
Web Application
Servers Query (Search)
Single Sign-on
Excel Calculation Services
Office Project Server

Tier 3:
Content Database
Shared SQL
Database Server s Configuration Database
Dat abases
Admin Content Database
Source: Gartner (February 2009)

From a logical perspective, SharePoint's content hierarchy is object-oriented and organized in a

straightforward structure. Delegated administration is typically used across three levels, with the
most powerful administrators at the server farm level (see Figure 2)

Publication Date: 23 February 2009/ID Number: G00165026 Page 5 of 20

2009 Gartner, Inc. and/or its Affiliates. All Rights Reserved.
Figure 2. SharePoint Hierarchy

SharePoint Object Hierarchy SharePoint Administrative Hierarchy

Central Administration:
Site col lection admin istrators
Ser ver farm administra tion
SharePoint Server Farm Authentication
Most secu rity policies
Web front end , SQL
We b Applica tion Sha red Services Admin istration:
S ite Collection Sear ch, SSO, e tc.

Subsite s
Site

Site Administrati on: Ser ver Admin istration:

List/Lib rary Site col lection admin istrator Start services
Site own er In stall new a pplications
Subfold ers Site settings
Fo lder Site permissi ons
Aud iting and expira tion
Policies and IRM
Items
Source: Gartner (February 2009)

In many deployments, information security wasn't involved in the planning and deployment of
SharePoint beyond basic security hardening, network placement and integration with Active
Directory. Other SharePoint deployments have been made directly by user departments without
centralized IT involvement or security involvement. Even when basic SharePoint security
guidelines are followed (see Note 2), clients continue to have problems in several areas. Security
issues in SharePoint deployments fall into several broad groups: policy and governance, access
control, information protection and network/server protection. In the following sections, we explore
issues and offer recommendations in each area.

2.0 Security Policy and Governance Issues

Issue: Most organizations lack SharePoint-specific security configuration guidelines. If guidelines
are in place, they are not monitored for compliance.
SharePoint should be treated as an enterprise application (much like ERP or CRM) and should
have its own strategy and policy for how it will be configured. Such a strategy/plan should consist
of use cases in which SharePoint is acceptable, along with associated protection profiles
(low/medium/high, for example). These guidelines should make it easy for people to know when
SharePoint usage is and is not acceptable, how it is to be appropriately used, and how it is to be
appropriately configured. SharePoint security strategy should not be formulated in a silo. Ideally,
an overall SharePoint governance plan would be put in place addressing operational concerns
(see "Q&A for SharePoint Governance") for all SharePoint sites, including those outside the
control of IT.

Publication Date: 23 February 2009/ID Number: G00165026 Page 6 of 20

2009 Gartner, Inc. and/or its Affiliates. All Rights Reserved.
SharePoint policies must strike a balance. SharePoint adoption has exploded precisely because it
allowed users to collaborate in ways that they define and that were not easily possible before. If
IT controls too tightly and makes collaboration more difficult, it will encourage individuals and
business units to consider off-premises, cloud-based collaboration solutions (including hosted
SharePoint) where IT's ability to maintain security policy will be even more difficult.
Recommendations:

If you don't already have a SharePoint governance model in place, start now. Formulate
this in conjunction with the business stakeholders.

For larger enterprises with multiple usage patterns of SharePoint, develop a set of
SharePoint use cases that include appropriate security configuration and policy.

Establish policies and guidelines for all SharePoint servers and regularly scan to see
these are enforced where possible.

Don't control too tightly. Focus on the minimum policies necessary to enable secure
collaboration and protect the organization's most sensitive information assets.
Issue: Unmanaged, "rogue" SharePoint installations in the organization aren't visible and aren't
being secured according to policy.
You can't secure what you don't know about and can't see. We estimate that 30% of SharePoint
servers are deployed outside the management of the IT department. The issue is not that rogue
SharePoint sites are bad per se. The issue is that the ad hoc configuration may not conform to
enterprise security policy for configuration, authentication, authorization and so on. While many
unmanaged sites have followed basic SharePoint security guidelines (see Note 2), the
information they store, its sensitivity and proper protection is often overlooked. The information
being shared may or may not be appropriate or may not be appropriately protected. Once servers
are discovered, the information stored on them as well as access control policies should be
enumerated and checked for policy compliance.
Recommendations:

For visibility into unmanaged SharePoint deployments, regularly scan for unmanaged
SharePoint installations. Microsoft provides a free tool to do this at
http://technet.microsoft.com/library/cc295797.aspx . Quest Software also offers a free
tool for this purpose: http://www.quest.com/discovery-wizard-for-sharepoint .

Ideally, a separate scanning tool wouldn't be needed. Require your organization's

standard network and systems scanning tools to identify SharePoint servers, including
those that are hosted on virtual machines. Regularly scan for unmanaged SharePoint
installations.

Establish standard security configuration guidelines for SharePoint servers and regularly
scan to ensure that these are enforced. Require the organization's standard
configuration monitoring tools to explicitly support SharePoint.

3.0 SharePoint Access Control Issues

Issue: Authentication integration with Active Directory doesn't work for all external users.
Issue: The ongoing responsibility and process for administering access controls for external users
haven't been clearly defined.

Publication Date: 23 February 2009/ID Number: G00165026 Page 7 of 20

2009 Gartner, Inc. and/or its Affiliates. All Rights Reserved.
SharePoint provides multiple alternatives for authentication that fall into three broad categories:
Windows-integrated authentication, ASP.NET forms and Web single sign-on (SSO). For
organizations already using Active Directory (AD) for user accounts, SharePoint integration with
AD using integrated authentication makes the most sense and leverages a managed
authentication infrastructure already in place (see "Microsoft Office SharePoint Server
2007/Active Directory FAQ"). AD integration is also useful of the organization has strong
authentication policies (for example, the use of smart cards) already in place for Windows
authentication.
However, using AD and Windows-integrated authentication is difficult for authenticating external
users who are outside the enterprise domain structure. There are several alternatives to address
this. If the external user's organization is also using AD, a form of federation using an explicit AD
trust relationship could be established. However, this won't work for linking to organizations that
don't use AD.
A more general form of federation could be used (see "Frequently Asked Questions About
Federated Identity") with SharePoint's Web SSO support to enable external SharePoint access.
However, this requires contractual and technical agreements (see "Take the Best, Leave the Rest
for Identity Federation Governance and Controls") between the organizations that take time to
establish and where many organizations haven't yet developed a consistent process for
establishing new federation relationships.
With federation, the ongoing administration efforts of adding users for authentication purposes
are handled by the external partner. However, there is still the significant and sensitive issue of
who administers authorization for these users within SharePoint itself. This task often falls to the
business-unit site administrators, who are not staffed or trained for the ongoing administrative
requirements of SharePoint.
Most commonly, external users are defined and authenticated within SharePoint, using its
ASP.NET forms integration to a local repository for where external user accounts are maintained.
SharePoint's ASP.NET provider gives multiple options for building this repository. One alternative
is to use the LDAP membership provider (included with SharePoint Server 2007) and link to an
existing external LDAP-enabled directory (such as Novell's NDS). Typically, the enterprise has
already built this for external user access (for example, for supporting Web Access Management)
and may be leveraged using LDAP or using SharePoint's Web SSO support. If an LDAP-enabled
repository isn't readily available, organizations typically use forms-based authentication against
an SQL database for example, Microsoft ships a SQL Server provider for SharePoint. As an
alternative for consumer-facing sites where authentication is desired, Microsoft ships a
community-supported Live ID Web authentication provider with SharePoint
Most organizations will have both internally-based AD users and external users in a separate
repository, so multiple authentication providers must be specified for example, to enable
intranet access by using Windows authentication and external access by using forms-based
authentication using LDAP. Within SharePoint itself, the use of up to five multiple authentication
providers is supported and requires the use of multiple Web applications, where each Web
application is assigned a zone (a URL pointing to the same content) and a single authentication
provider.
In all cases, someone will be responsible for the addition and deletion of external users to
SharePoint as well as managing their entitlements within SharePoint. Central IT is not best-suited
for understanding business- and process-level requirements for external access, and this is
typically delegated to business information owners. For most organizations, this is not a new
problem we already have external users accessing our systems and enterprise identity, and
access management processes have been modified to enable this. In these cases, extend these
processes to SharePoint. Access of all types should be regularly audited and a process should be

Publication Date: 23 February 2009/ID Number: G00165026 Page 8 of 20

2009 Gartner, Inc. and/or its Affiliates. All Rights Reserved.
put in place for managing this, which addresses account creation, deletion, periodic reapproval of
access, inactivity locks and so on.
Recommendations

For internal users, use Windows-integrated authentication and synchronize accounts

from AD, if you are already using AD.

For external organizations, where you trust their ability to manage and authenticate
users correctly, consider a federation relationship either via an explicit trust
relationship, if they use AD, or by more-generic federation, if they don't. In either case,
this configuration reduces the amount of administration required on your site.

For external users that don't use AD and where federation is not possible, use an LDAP-
enabled repository, if you already have one. Look for explicit certification of support from
the LDAP provider for SharePoint integration.

For external, non-AD users where you don't have an existing LDAP-enabled repository
to leverage, use the built-in SQL authentication capabilities of SharePoint or, for
authenticating consumers, consider LiveID.

Regularly scan all SharePoint site collections for inactive IDs that may still have access
to content (note that the SharePoint configuration database alone does not provide this
information).

Depending on the purpose of the SharePoint site and the type of information being
stored, consider if anonymous access may be appropriate for some sites (for example,
consumer-facing marketing and public relations materials).

Log all failed login attempts whether to the underlying Windows OS, AD, SharePoint,
LDAP or the underlying SQL database.

Determine who will manage and support external users and their access controls, and
put formal processes in place to ensure that this is carefully managed.

Extend existing identity and access management processes to address SharePoint

users and entitlements (internal and external).
Issue: Active Directory structures don't reflect information-sharing requirements.
Many organizations want to use AD to control all SharePoint access. In addition to synching
identities for authentication, AD groups can be used directly within SharePoint groups, leveraging
existing group structures to reduce the number of points of administration.
This is a best practice; however, rarely can AD be used for all SharePoint authorization purposes.
Only AD's access control lists are used in SharePoint (not AD's structure). Exchange's e-mail
distribution groups can't be used. Further, if the organization isn't using AD or where SharePoint
is used by external users, AD groups won't easily work (see Note 3).
More importantly, AD structures (rooted in device and network topology) rarely reflect information
architecture how information will be created, shared and ultimately retired. Further, the
updating of AD groups and group memberships is often tightly controlled and not suitable for
delegated administration of SharePoint sites.
Recommendations:

Publication Date: 23 February 2009/ID Number: G00165026 Page 9 of 20

2009 Gartner, Inc. and/or its Affiliates. All Rights Reserved.
 If you are already using AD, require the use of established AD groups within SharePoint
groups wherever possible to minimize SharePoint administrative overhead.

Use the built-in groups within SharePoint for access control assignments where
possible.

Use groups wherever possible for administering SharePoint sites. Apply access rights
as high as possible in the SharePoint object hierarchy and avoid per-user and per-item-
level access to avoid complexity (which increases the change for misadministration) and
potential technical constraints on access control lists.

Don't expect AD to meet all SharePoint access control needs.

Issue: Authorization policies for SharePoint are defined per site, but organizations want
enterprisewide visibility and control of SharePoint entitlements for compliance purposes.
SharePoint uses its own proprietary authorization model stored in an SQL server database within
every SharePoint installation. Entitlements are defined per SharePoint site and it is difficult to get
a comprehensive view of SharePoint access rights across all SharePoint servers. There are
several ways this problem can be simplified and addressed.
One alternative is to manually extract all the entitlement reports from each SharePoint site and
create a consolidated report. Alternatively, third-party vendors, such as AvePoint, CA,
DeliverPoint, Idera, Nintex, and Quest Software provide tools that provide enterprisewide visibility
and reporting.
Another approach is to externalize SharePoint authorization requests to a centrally managed
service. SharePoint is .NET framework-based application and takes advantage of the .NET role
provider interface enabling external-based authorizations solutions to be used in replacement of
(or in conjunction with) SharePoint's internal authorization. Multiple third parties provide solutions
here (see Note 3) and constitute a subset of authorization management solutions (see "Tear
Down Application Authorization Silos With Authorization Management Solutions"). These
solutions act as "authorization brokers" that may then be integrated with AD, LDAP and other
policy information stores. This approach has several advantages including:

Providing consistent policy-based access across all SharePoint sites

Extending entitlement management to systems other than SharePoint

Reducing the number of points of administration

Providing full visibility and audit of all access activities

Consolidating entitlement reporting across all SharePoint sites

Incorporating additional context (such as the time of day), which can be incorporated
into real-time at the time the access is requested, providing more-adaptive security
infrastructure (see "Achieving Agility: Building Blocks for a Policy-Driven, Agile Security
Services Infrastructure")
Once in place, the authorization infrastructure can be leveraged by other application authorization
silos, including internally developed applications. However, the benefits of an externalized
authorization management solution for SharePoint must be evaluated against the additional cost.
Recommendations:

Publication Date: 23 February 2009/ID Number: G00165026 Page 10 of 20

2009 Gartner, Inc. and/or its Affiliates. All Rights Reserved.
 Consolidate all SharePoint servers under as few sites as possible for simplified visibility
of SharePoint entitlements.

For larger deployments, use third-party tools for compliance and entitlement reporting.

Consider external authorization management solutions that support SharePoint as a

way to manage entitlements consistently across multiple SharePoint sites and internal
and external users, as well as to leverage existing policy information stores.

4.0 SharePoint Information Protection Issues

Issue: The SQL Server database at the heart of SharePoint isn't properly secured.
SharePoint relies on Microsoft's SQL Server as its core content and configuration repository. The
database itself is extremely sensitive and will be subject to attack from outside the SharePoint
environment. However, SharePoint administrators aren't typically experienced database
administrators and lack database security expertise.
Unmanaged SharePoint installations may not have properly secured the database. Further, in
some installations, the embedded SQL Server Express Edition is used "under the covers" and
isn't thought of as a traditional database deployment. It isn't implemented according to the
organization's best practices and guidelines for securing SQL databases. Finally, whoever holds
the system administrator rights to the underlying SQL database has full access to all SharePoint
content, including its access control database, including information that may be protected using
SQL server encryption and SharePoint's integrated RMS option.
Recommendations:

Apply the organization's established configuration guidelines for configuring and

protecting SQL Server as well as protecting sensitive database access to the
SharePoint SQL Server database.

Tightly control SQL system administrator access to SharePoint's databases and fully
audit all SQL Server administrative activities.

Require the organization to baseline all Windows and SQL server deployments against
the organizations' own guidelines or Microsoft's best practices. For example, Microsoft
provides its baseline security analyzer, which scans Windows and SQL
http://technet.microsoft.com/en-us/security/cc184924.aspx .

Consider SAPM tools (see "Toolkit: Password Management Tools for Shared Accounts
and Service Accounts") for controlling all SharePoint administrative accounts, including
SQL server administrative accounts.

Require the use of Microsoft's SQL Server 2005 or higher, which provides stronger out-
of-the-box security capabilities than previous versions.
Issue: SharePoint is used to store and share sensitive information copied by users from
production systems, but without proper access controls.
Much of SharePoint's appeal is that it enables users to bypass the explicit and organizational and
process barriers of the organization. SharePoint is often used to host data that end users have
unofficially copied or extracted from official "production" systems, such as ERP systems, that are
then subsequently used in ad hoc processes and collaboration. However, in most cases, the data
is moved into SharePoint but without the protection capabilities and policies of the production
systems they displace.

Publication Date: 23 February 2009/ID Number: G00165026 Page 11 of 20

2009 Gartner, Inc. and/or its Affiliates. All Rights Reserved.
The ideal solution would be to use SharePoint's integrated SSO capabilities to integrate directly
to back-end production systems such as Siebel, SAP and Microsoft's CRM. In this way, the
access controls of the back-end production systems are respected and reflected in how users are
able to access content via SharePoint.
Even in the ideal case where SharePoint's SSO is used, users may place sensitive data into
SharePoint (for example, using cut-and-paste or unrestricted database extracts), bypassing the
controls of production systems. The solution would be to regularly scan SharePoint repositories
for sensitive data and apply appropriate controls. But this is complicated by the distributed nature
of SharePoint servers in most organizations (and the aforementioned rogue SharePoint
deployment problem) and the fact that most organizations don't define and enforce a formal data
classification. Data leakage prevention and content monitoring and filtering solutions (see "Magic
Quadrant for Content Monitoring and Filtering and Data Loss Prevention") support this scanning
function. In Microsoft's recent partnership with EMC's RSA security unit and its content monitoring
and filtering (CMF) engine (see "Microsoft/RSA Alliance to Have Long-Term Impact on DLP
Market"), both vendors explicitly called out the scanning of SharePoint content repositories as an
area that would be addressed in future releases.
Recommendations:

Develop policies for the types of information that can be shared within SharePoint.
Ideally, an enterprisewide strategy for data classification would be used and policies
defined for SharePoint (see "A Simple Method for Expressing Information Criticality and
Classification").

Where access to production systems and data is needed, link SharePoint directly, using
native SSO capabilities that preserve the access control definitions of the production
systems.

Develop strategy for data loss prevention that includes SharePoint (see "Develop an
Enterprise Strategy for Content Monitoring and Filtering/Data Loss Prevention"). At a
minimum, explicit SharePoint-specific policies should be designed and monitored for the
most sensitive information (such as customer data, sales figures, personally identifiable
information and HR data).

Regularly crawl all SharePoint sites for sensitive data and ensure that unauthorized
persons cannot access sensitive data.

Don't purchase a CMF/data loss prevention (DLP) solution that doesn't natively support
SharePoint.
Issue: Sensitive information, even if protected within SharePoint, is left unprotected if the
information is taken offline, e-mailed or copied.
This is an issue with any IT system, not just SharePoint. SharePoint protects the information it
controls, but these controls are lost if the information is taken offline, e-mailed or copied. One
solution is to enable SharePoint access via a terminal services session and use its ability to
restrict session activity. This is useful for controlling information remotely accessed by partners
and employees, but it doesn't support working offline.
Another approach is to scan for sensitive data as data is moved from SharePoint sites and block
this. The CMF/DLP solutions mentioned above can perform this. Some SharePoint malware
filtering solutions, such as McAfee's PortalShield, can scan content for patterns that might be
indicative of sensitive content being moved from SharePoint (for example, patient record
numbers) and block this.

Publication Date: 23 February 2009/ID Number: G00165026 Page 12 of 20

2009 Gartner, Inc. and/or its Affiliates. All Rights Reserved.
The ideal solution to protect SharePoint information would protect data automatically if the data
leaves the SharePoint server, but still preserve indexing and search. SharePoint-aware and
integrated rights management solutions can provide this by leaving information stored
unencrypted in SharePoint folders, and automatically applying rights management policy as
content is added, accessed or moved from SharePoint.
For example, Microsoft has integrated its Rights Management Service (RMS) solution into
SharePoint 2007 and higher. Further, since the RMS client enforcement capability is built into
Office and Vista, rights management policy is enforced when the content is moved to the client
and manipulated in Office.
Third-party products can provide similar capabilities. NextLabs' SharePoint Entitlement Client
performs a similar function without requiring a full digital resource management (DRM) solution by
integrating with the SharePoint entitlements management solution. The NextLabs client runs
locally on each desktop and enforces policy after the data is downloaded or exported from the
server. A comprehensive solution should be able to enforce policy locally at the client device
including device control, cut and paste, and copy to USB even when offline.
These solutions require administrators to make correct decisions on applying appropriate policy
to SharePoint objects. As discussed, administrators don't always know that sensitive data is
being stored on SharePoint. There is also the chance of misadministration or malicious intent.
Longer term, sensitive content could be automatically identified and rights management policies
applied via SharePoint integration with CMF/DLP tools discussed previously.
Recommendations:

Consider terminal services-based access as a way to control what remote users are
able to do with content when accessing via SharePoint.

Protect sensitive data stored in SharePoint with DRM. However, solutions that encrypt
the data before storing it in SharePoint interfere with the correct indexing and searching
of content discussed above.

Require DRM solutions to directly integrate with SharePoint, so that information rights
management policy may be applied automatically as content is moved to and from a
SharePoint folder.
Issue: Information encrypted in SharePoint isn't properly indexed.
As discussed above, SharePoint-integrated DRM solutions provide protection from information as
it moves to and from the SharePoint server, but this doesn't protect against information theft by
rogue administrators. Some organizations choose to encrypt sensitive data when it is stored on
SharePoint to protect data from exposure to theft by a rogue administrator or external attack.
However, encrypted data stored in SharePoint can't be properly indexed by SharePoint and
cannot be searched or easily shared.
SharePoint doesn't have a native encryption solution; however, there are multiple alternatives for
protecting SharePoint information using encryption (see Figure 3). Each alternative has pros and
cons.

Publication Date: 23 February 2009/ID Number: G00165026 Page 13 of 20

2009 Gartner, Inc. and/or its Affiliates. All Rights Reserved.
Figure 3. Pros and Cons of Alternatives to Data Encryption in SharePoint

Protects data
F rom
W indows OS
or SharePoint From SQL
appli cation Serv er
breach or applicati on Onc e content Doe snt
rogue breac h or is m oved from Enable s require the
Encryption From disk SharePoint rogue SQL SharePoint indexing end user to
applied theft adminis trator administrator s ever and se arch think

Full-drive
encry ption

End-us er encrypts
or applies DRM to
content before
storing

SQL dat abase

encry ption

SharePoint auto-
applies DRM when
content is m oved

Both SQL
encry ption and
SharePoint-applied
DRM
Source: Gartner (February 2009)

Because SharePoint is an application running on top of SQL Server, the built-in encryption
capabilities of SQL Server may be used to protect sensitive data in such a way that indexing
works correctly while still providing a level of protection against most unauthorized data access.
Organizations may be tempted to encrypt everything stored by SharePoint in SQL; however,
there is a cost of approximately 3% to 5%, in terms of processing power. The impact on server
processing may be reduced with SQL Server 2008, which supports the hardware-based offload of
encryption.
A combination of SQL encryption and a SharePoint-integrated DRM solution provides the most
protection, but organizations must weigh the additional cost and processing requirements of such
a solution against the benefits. Even in this case, information is at risk from a SQL-level attack
and, thus, our recommendations previously in this research to treat the SQL server as the most-
sensitive element when developing a SharePoint security strategy.
Recommendations:

Use the built-in SQL server encryption capabilities wherever possible. This preserves
indexing and search results and provides an additional layer of protection to protect
sensitive data from external breaches (for example, from a rogue SharePoint system
administrator or from most external attacks).

Publication Date: 23 February 2009/ID Number: G00165026 Page 14 of 20

2009 Gartner, Inc. and/or its Affiliates. All Rights Reserved.
 Additional encryption of SharePoint content may be used directly by end users;
however, this interferes with the indexing, search and sharing of content.

As discussed previously, the SQL server in SharePoint is the single-most-important

element to protect. Follow the recommendations listed above for protection of the SQL
Server.
Issue: The indexing and search of SharePoint-hosted data may inadvertently expose sensitive
data to unauthorized users.
Many organizations overlook the issue that indexing and search pose to sensitive data. Only
people entitled to see the data should be able to see it in a search result and SharePoint's
integrated authorization ensures that access controls are incorporated as content as indexed so
that only people entitled to see data see the relevant search items. However, data is often placed
in SharePoint without proper controls, and is then indexed and exposed with SharePoint's search
capabilities.
There is also the slight risk that a user who had access rights at the time the content was indexed
will continue to see search results that indicate that content is available, even after access rights
have been revoked. Thus, it is possible that the small amount of information shown as a result of
the search discloses something sensitive after access has been revoked. SharePoint
automatically builds its indexes based on access controls at the time of indexing. Search results
may be further trimmed at the time of query to reduce the risk of showing an index to content that
a user may no longer access.
Another area of risk is SharePoint content access accounts. These empowered accounts are
used by SharePoint to crawl and index SharePoint content. A single account could be used to
index all data (sensitive and nonsensitive). However, if data is stored unencrypted, sensitive data
should be indexed using separate content access accounts to reduce risk.
Recommendations:

Use the built-in authorization isolation capabilities of SharePoint to isolate access to

content. Use scopes and audiences to further control access and to limit visibility of
sensitive data.

For highly sensitive content, set SharePoint policy so that search results are
automatically trimmed at the time of query to reduce the risk of showing an index to
content for which the user no longer has access.

Tightly control all SharePoint system administrative access, including service-level

accounts used for indexing.

For crawling and indexing highly sensitive data, use a separate content access account.

Separate SharePoint sites should be used to strongly isolate sensitive data and access.

5.0 SharePoint Network and Server Protection Issues

Issue: Inadequate network security controls for SP servers
A company setting up its SharePoint deployment must do so with established logical security
design principles in mind. A SharePoint deployment is a multitier enterprise application (see
Figure 1) and should be secured with the same type of approach that is used to secure other
multitier enterprise applications. In a SharePoint server farm environment, individual servers play
specific roles. Security hardening recommendations for these servers depend on the role each

Publication Date: 23 February 2009/ID Number: G00165026 Page 15 of 20

2009 Gartner, Inc. and/or its Affiliates. All Rights Reserved.
plays. In most deployments, the IIS Web server and the associated SharePoint Web applications
represent one tier, and the SQL Server database represents another. In larger deployments, the
individual Web applications in SharePoint may be broken out onto dedicated application servers
for example, the search application may be placed on one server, InfoPath services on
another and Excel services on another.
The most at-risk server is the SQL Server, and this should always be broken out and protected by
a firewall whether it is placed internally or in a separate trust zone in the DMZ. By default,
SharePoint users don't directly connect to the SQL Server. They communicate with the
SharePoint Web application, which, in turn, connects to the SQL Server, using TCP port 1433. If
this communication is unsuccessful, then the SQL Server Resolution Service is queried on UDP
port 1434 to determine on which port the database instance is listening. These ports are well-
known, and the SQL Server Resolution Service has been the subject of numerous buffer overflow
and DOS attacks. The ability to control which ports are open or blocked, and to change them, are
critical to securing a SharePoint deployment. For additional protection of the SQL Server,
network- or host-based intrusion prevention systems may be used to detect and prevent attacks.
In an extranet collaborative environment, communication between client computers and the front-
end tier of servers is necessary, and such communication must be protected. Microsoft's ISA
server, or another reverse proxy, is recommended when the same SharePoint site must face both
internally and externally to an extranet or the Internet. In such a case, two servers share the
same content, and the reverse proxy applies only to the externally facing server. The internally
facing server is directly accessible by HTTP; the externally facing server can be reached only by
a Secure Sockets Layer (SSL) request to the reverse proxy server. For more-granular security
controls on server-to-server traffic, consider the use of IPsec.
Recommendations:

Wherever content is made externally accessible, deploy with an explicit multitier

architecture. At a minimum, break out the IIS Web server and the SharePoint application
server from the SQL database back end. Ideally, break out the application servers from
the IIS Web front end as well.

Set network security controls and policy wherever possible so that the back-end SQL
database is never directly accessible directly to end users.

Place a firewall between front-end Web servers and database servers, which (unless
access is for external users only) should always be hosted internally, not directly in the
demilitarized zone (DMZ).

Application servers should be placed behind the firewall that protects the database
servers, or, for more security, can be placed behind an additional firewall separating it
from the outward-facing Web server.

Harden each type of server to the level appropriate to each server role and use case.
Use Microsoft's hardening guidelines and tools to perform this.

To prevent malicious attacks from accessing the SQL Server Resolution Service, assign
obfuscated static port numbers to named instances of SQL Server and then disable the
service.

Use a reverse proxy where possible to increase the security of external collaboration.

In an external anonymous access environment, disable Simple Mail Transfer Protocol

(SMTP) services.

Publication Date: 23 February 2009/ID Number: G00165026 Page 16 of 20

2009 Gartner, Inc. and/or its Affiliates. All Rights Reserved.
Issue: Deployments of SharePoint in DMZ configurations for access by external users aren't
adequately secured.
Most organizations mistakenly believe SharePoint will be used only for internal access and don't
plan for the fact that most SharePoint servers will be accessed by external users for access by
employees working remotely and, in most cases, also by external partners. Here, an enterprise
can use established security design principles to enable secure access for remote employees,
partner employees and customers.
The hardening requirements are clear for an extranet environment in which an Office SharePoint
Server 2007 server farm is placed inside the DMZ perimeter and content is available from the
Internet or from the corporate network. In this common scenario, we recommend separating the
SharePoint server farm into three tiers (front-end Web, Web application and database). To
achieve even baseline security, the SQL repositories and the application servers must be behind
a firewall.
For optimal security, these tiers should be separated by routers or firewalls at each boundary.
VLANs alone do not provide sufficient separation (see "Findings From the 'Client Inquiry': VLAN
Separation Is Not Security Separation"). In any case, only the front-end Web server should be
exposed to external users. Further, the central administration site should never be hosted on a
front-end Web server, and should be configured using SSL, to ensure that communication from
the internal network to the central administration site is secured.
For remote access by employees, access is typically enabled using a VPN connection. However,
this doesn't work for access from clients without the VPN client. In these cases, a third-party
application gateway such as Microsoft's Intelligent Application Gateway may be used to enable
non-VPN access and to enable alternative forms of authentication such as smart card-based
public key infrastructure (PKI) or mobile authentication using ID and PIN.
Recommendations:

Even in initial deployments, design your SharePoint server farm into "front-end" Web
(Internet-facing) and "behind the firewall" (application and database servers). This will
make extending internal deployments securely to the extranet much easier.

Ensure that the central administration site is not hosted on an external-facing a Web
server.

Any information flow between the IIS Web front end and other tiers should be encrypted
(VPN or IPsec).

VLANs alone are not sufficient for effective separation of computing tiers in the DMZ.
Use firewalls or routers, and consider physical network separation.
Issue: Running server-based antivirus (AV) on the SharePoint Server doesn't detect malware
stored in SharePoint's SQL repository.
The content stored in SharePoint's SQL server isn't scanned by most Windows file system-based
AV solutions; thus, malware in SharePoint's content database is not detected. Collaborative
workspaces provide an easy mechanism for file and content sharing, which also facilitates
malware propagation. This is a significant concern if content originates from outside the
organization from unmanaged machines (for example, enabling consumers to post resumes on a
SharePoint-based human resources site, or enabling customers to post attachments on a
SharePoint-based blog).

Publication Date: 23 February 2009/ID Number: G00165026 Page 17 of 20

2009 Gartner, Inc. and/or its Affiliates. All Rights Reserved.
Multiple vendors provide solutions that plug directly into SharePoint's AV APIs that can scan the
SQL content database for malicious content. Further, many of the anti-malware products, such as
McAfee's PortalShield and Microsofts Forefront Security for SharePoint, will also scan incoming
and outgoing content for keywords (such as profanity) and some will perform general pattern
matching to help identity sensitive content. Externally posted content should be scanned before it
is posted to SharePoint, either with an integrated SharePoint anti-malware solution or using a
Web security gateway (see "Magic Quadrant for Secure Web Gateway")
Recommendations:

Treat all content attachment uploads from all external sources (ideally all content) as
potentially hostile and scan all content, regardless of extension, with an anti-malware
scanning solution integrated into SharePoint or by routing all SharePoint traffic through a
SharePoint-aware Web security gateway. At a minimum, scan all uploaded content from
external sources. Ideally, all uploaded and downloaded content would be scanned.

Scanning of the entire SharePoint content database should be carefully considered.

Unless the SharePoint installation is small, the AV scan runs on a SharePoint Web
application server that is separate from the SQL server content database. For on-
demand scanning of the entire database, network traffic and performance must be
considered.

SharePoint anti-malware signature databases should include signatures for Windows,

Linux, Mac and any other potential endpoint that may post content. In a mixed
environment, a Windows-only signature set is insufficient.

Favor anti-malware engines that supplement signature-based scanning with multiple

engines and malware detection capabilities, such as reputation services, heuristics,
content inspection and proactive behavioral modeling.

RECOMMENDED READING

"Key Issues for SharePoint in a Distributed Environment Project"

"SharePoint for Content Management Revisited"
"Q&A for SharePoint Governance"
"Magic Quadrant for Enterprise Content Management"
"Magic Quadrant for Secure Web Gateway"

Note 1
SharePoint Resources
http://office.microsoft.com/download/afile.aspx?AssetID=AM102570981033
http://technet.microsoft.com/en-us/library/cc262619.aspx
http://technet.microsoft.com/en-us/library/cc262350.aspx

Note 2
Basic SharePoint Security Guidelines
Server security:

Publication Date: 23 February 2009/ID Number: G00165026 Page 18 of 20

2009 Gartner, Inc. and/or its Affiliates. All Rights Reserved.
 Locate the SharePoint servers in a secure location with restricted and audited physical
access.
Windows OS and SharePoint application security:

Restrict operating system (OS) administrative account access to local login.

Turn on auditing for all server events and monitored.

Use NTFS security for the SharePoint application and its file system as well as all
indexed content.

Extend the organization's patch management processes to incorporate the entire

SharePoint application stack Windows, SharePoint applications and SQL.

Harden the SharePoint servers Windows OS, SharePoint and SQL application, using
Microsoft's guidelines and tools to remove unnecessary files and services removed.
SharePoint administrative access:

Use multiple service accounts, one specific for each task and configured via principle of
least privilege

Reduce the number of "farm-level" administrators. Use the built-in delegated

administration capabilities of SharePoint with reduced scope of administration,
configured via principle of least privilege

Set strong password policies on all accounts user, administrator and service
accounts with regular changes of all passwords. Use automated tools for the resetting of
service accounts if necessary.

Control and log all administrative access to the OS, SharePoint and SQL
High availability:

Architect for resiliency. Ensure business continuity and disaster recovery plans
developed and tested.

Use SQL Server high availability options (for example, clustering) as necessary.

Note 3
AD Groups for External Users
If federation is used (ADFS or otherwise), external users may be mapped to AD groups, which
may then be used as security identifiers within SharePoint. To do this, the customer maps
incoming claims to AD groups, see http://technet.microsoft.com/es-es/library/cc772094.aspx and
http://technet.microsoft.com/zh-tw/library/cc753670.aspx . The mapping can map individual
remote users to an AD group, or map remote groups to an AD group. This method works even if
the remote federation server is not AD FS.

Note 4
Example Authorization Management Solutions With SharePoint-Specific
Capabilities
BiTKOO

Publication Date: 23 February 2009/ID Number: G00165026 Page 19 of 20

2009 Gartner, Inc. and/or its Affiliates. All Rights Reserved.
 Cisco (acquired Securent)

NextLabs

Rohati Systems (network-based solution)

The Dot Net Factory

REGIONAL HEADQUARTERS

Corporate Headquarters
56 Top Gallant Road
Stamford, CT 06902-7700
U.S.A.
+1 203 964 0096

European Headquarters
Tamesis
The Glanty
Egham
Surrey, TW20 9AW
UNITED KINGDOM
+44 1784 431611

Asia/Pacific Headquarters
Gartner Australasia Pty. Ltd.
Level 9, 141 Walker Street
North Sydney
New South Wales 2060
AUSTRALIA
+61 2 9459 4600

Japan Headquarters
Gartner Japan Ltd.
Aobadai Hills, 6F
7-7, Aobadai, 4-chome
Meguro-ku, Tokyo 153-0042
JAPAN
+81 3 3481 3670

Latin America Headquarters

Gartner do Brazil
Av. das Naes Unidas, 12551
9 andarWorld Trade Center
04578-903So Paulo SP
BRAZIL
+55 11 3443 1509

Publication Date: 23 February 2009/ID Number: G00165026 Page 20 of 20

2009 Gartner, Inc. and/or its Affiliates. All Rights Reserved.