The recent release of the Benedict Cumberbatch film “The Fifth Estate” has brought renewed attention Wikileaks and the security breaches that culminated in Julian Assange’s publication of classified US security documents and his subsequent “exile” in a London embassy.
The Tower of London, safely guarding the Crown Jewels for centuries © 2013 Christopher F. McNulty
What happens when SharePoint security is “breached”? Obviously, there’s a broad range of impact – from international news and diplomatic scandals down through corporate liability, reputation damage on to minor personal embarrassment.
SharePoint is used in many large government agencies and enterprises, some of which have been in the forefront of security news in the past year. But it’s probably worth noting in most cases, SharePoint itself wasn’t “hacked” or “broken”. Rather, the system worked exactly as it was designed and configured, allowing a single user great latitude to access, move or copy information. Users were properly authenticated and authorized by the system.
The question to ask? Why was SharePoint configured that way in the first place? Beats me. But a few best practices could have reduced or eliminated many of these gaps.
- Review the security design. On a regular basis, you should review the access rights configured across your enterprise. It’s worth paying special attention to any areas where large content pools, sites, or libraries have access given to all Authenticated Users, Everyone, or All Domain Users. If practical, you can implement technical policies to block the ability to assign such widespread access rights. Dell’s Site Administrator gives you visibility to generate maps of your as-implemented site security and find areas left wide open.
- Maintain the security design. Just because an account requires permission today doesn’t mean they need it tomorrow. In a mature information governance practice, content owners are asked to reaffirm, or attest, at least quarterly, that the user rights for their content are “correct”, or to identify obsolete permissions that can be suspended or eliminated. Asking users to click yes on an “all permissions are correct” checkbox isn’t fair either – how do they know?
Again, Site Administrator can be run in delegated mode. Site-level owners can have rights to look at content security for their site and only their site, in a web dashboard that’s faster and more intuitive than hunting for user permissions in native SharePoint. Additionally, “Quest One Identity Manager” can be used to orchestrate the entire attestation process. Automated workflows can distribute review requests automatically to the right stakeholders and use workflow tools to respond to request to renew or eliminate old permissions.
Also, old or obsolete data is not just a legal liability but a technical one. Old information doesn’t necessarily become less sensitive because it’s older. It’s a good practice to migrate content at end-of-active-life to an archive. It’s an even better one to restrict access to these archives to approved admins and records managers.
- Be vigilant. Review the ongoing activity logs. A single user accessing a single document doesn’t usually warrant attention in a log. But accessing hundreds or thousands of document sin a day is a reasonable clue to malware or malfeasance. If possible, you can use Site Administrator ARP and/or ChangeAuditor for SharePoint to automate the alerting and notification process.
No technology is completely foolproof. There are many system level steps to “harden” SharePoint security for public facing sites. [For more, see SharePoint MVP Liam Cleary’s excellent post on “Hacking SharePoint”] But in most cases, misconfiguration and social engineering are a more pervasive threat to SharePoint and Office 365 than hacking. Limit your risks early.