Three SharePoint 2010 Security Pitfalls

SharePoint sites are shooting up, often with little or no involvement from IT. The short-term benefits of flexibility and quick deployment can be quickly overshadowed by security and compliance risks as these organic SharePoint sites are embedded in critical business processes and become home to sensitive information. If you work with your Active Directory (AD) administrators to replace local groups with SharePoint groups, implement solid audit log management, and keep the number of administrators in check at each level of your SharePoint environment, you’ll be ahead of the curve. In this article, I’ll examine each of these three areas and give you pointers on how to avoid security risks.

 1. Local SharePoint Groups

Local SharePoint groups are convenient to use when you need to quickly create a new group to control access to a site or library. But as SharePoint site collections grow you end up creating the same group with the same members; redundant groups are always bad for security because of the likelihood of missing one of the groups when a user’s role changes and the user needs to be removed as a member.

Think ahead and do things the right way: use AD domain groups instead of local groups. When an organization consistently uses AD groups instead of local Windows or application groups to manage access to resources, then access control becomes much easier to maintain and verify. If all entitlements are defined within AD through group memberships, then access control becomes centralized and visible. When a user’s role changes, an admin can review all the AD groups to which the user belongs from one place—Active Directory Users and Computers—and compare the user’s current entitlements to his or her new role.

AD is designed to support delegated admin authority. AD admins can create an organizational unit for SharePoint groups and assign you the permissions necessary to create and manage groups.

 2. No audit trail

Since WSS 3.0 SharePoint has had an audit logging feature, but most organizations don’t turn it on. Sooner or later, however, something’s going to happen that requires an audit trail. For instance, if your regulators notice the growth and reliance on SharePoint in your company, they might come do an audit. One of their major findings would be lack of an audit trail, which invariably creates compliance problems. Here’s another scenario: You get a call from a panicked manager about a SharePoint site that’s been improperly modified or whose confidential data has been compromised. Now the pressure is on you to find out who did it and when. Without an audit trail you can’t go back in time to investigate.

Using the SharePoint audit log is more involved than flipping a switch. SharePoint audit logging is a critical foundation technology that requires third-party solutions to form an audit trail you can depend on. ISV solutions allow you to extract SharePoint audit data to a separate, secure log repository, provide easy-to-read reports where all codes and numbers have been translated, and generate alerts when suspicious events are logged.

 3. Too Many Administrators

I can count on my fingers the number of audits I’ve done where there was no finding for “excessive users assigned administrator authority.” This is because it’s quicker to make Bob a site collection administrator instead of carefully delegating the authority he needs over the just sites, subsites, lists, and libraries that he manages. This violation of the “least privilege” principle of information security is easier to fix before you get hit with an audit finding or, worse, suffer from a catastrophic security incident caused by someone having more authority than they deserve. Before this happens, reduce the number of site collection administrators to the handful of people who are responsible for your entire SharePoint infrastructure.

Remember that there are 3 more levels of admin authority that have just has much risk and potential for damage: Windows, SQL Server, and AD. SharePoint is only as secure as the OS on which it runs and the database where its data resides. Carefully review who is a member of the Administrators group of each Windows server being used as a front-end web server, application server or database server. Finally, review who has privileged access in SQL Server.