So one of the most common question I get going to ISSA events, or any Security Conference is
What is the biggest security vulnerability of SharePoint?
The answer is simple YOU.
When organizations deploy SharePoint they normally use a OOB form of Security. Many times relying on SharePoint Security Groups created at the time the sites are partitioned. I am not picking on the SharePoint security model, in fact I enjoy the ease of use, and ability to delegate the security to the site owners. The issue is what security model did we choose, and can I use it after we deployed it.
I like to quote Neil MacDonald:
To be clear, it’s not that SharePoint is insecure, it’s that it frequently is deployed insecurely.
So that is the problem, how to fix it…….hmmmm this is a book size topic so lets look at these top level things to get you thinking about SharePoint and Security.
Authentication and Encryption
The first building block on a great SharePoint installation and deployment is Authentication and Encryption, and there is no shortage of choices for both with SharePoint 2007 and 2010. "Out of the box", SharePoint 2010 supports three authentication methods.
Windows
Forms-based Authentication
SAML token-based AuthenticationWhere I would like to go into a diatribe about Authentication, please just reference this TechNet support item for more info.Â
I will say that you are normally going to use NTLM for 90% of your portals, and the implementation of Forms, Claims, SAML, or even Anonymous activation will be based on the services offered and the audience you are asking to interact with your portal. Keep in mind Anonymous is just dangerous…..don’t use it unless you must (internet sites), I will try and write up a posting about about those dangers later.
My other Buyer Beware point is Forms-Claims authentication. This is not as baked as we all hoped by simply checking the box as you see below you do not have a working claims model. You have a lot of pre-work.
I will write up a post on deploying claims authentication in the weeks ahead.
Least-privileged Model not a best practice
Most organizations try and follow the least-privileged model:
The concept of least-privileged administration assigns users the minimum permissions that are required for users to complete authorized tasks. The goal of least-privileged administration is to configure and help maintain secure control of an environment. The result is that each service is granted access to only the resources that are absolutely necessary. Implementing least-privileged administration can result in increased operational costs because additional resources might be required to maintain this level of administration. Moreover, the ability to troubleshoot security problems can also be diminished.
Organizations implement least-privileged administration to achieve better security than would be typically recommended. Only a small percentage of organizations require this heightened level of security because of the resource costs of maintaining least-privileged administration. However, some deployments that might require this heightened level of security include governmental agencies, security organizations, and organizations in the financial services industry.
The implementation of a least-privileged environment should not be confused with best practices. In a least-privileged environment, administrators implement best practices together with additional heightened levels of security is performed.
Security Groups and AD
Many organizations use AD or Kerberos as the primary method to manage user accounts. The users are applied to a role or group structure….lets leverage that infrastructure.
So two ways IT likes to manage this approach.Â
AD groups in SharePoint Security Groups
Benefits of this is the AD admin can control who is added to top level groups, and thus a security structure once deployed in SharePoint is pretty bulletproof. Users are not added in SharePoint directly, but go thru a Request Process to get added to a site for the requested Permission and Role.
Disadvantage, one is visibility, you cannot see from SharePoint who is in what group. So for a site admin you have to put in requests to know who is using your site. Second is the Request Process, while supporting a great governance, it can be slow and sometimes be an added burden on IT.Consider this option for Top Level or High Risk areas. I like to weight the risk with the benefits on this one. Keep in mind that for top level or even tier 2 sites this model can be effective to cut down maintenance and continually adding new hires and contract staff.
User added directly to SharePoint Security Groups
Benefit for this is very transparent on project sites, team sites, workspaces, and sites that have a limited size team, and have a short life span. This approach is used for sites usually at the 3rd tier, or in specialized Web Applications (Extranet Project Portals for example). Agility is the game here, but with that you get risk.
Risk you take the administration out of security. Allowing site admins, list admins, content owners the ability to restrict, or open data to folks you orginally not intended. The other issue is Audit, how do you the Global God of SharePoint figure out who can see or touch what. That usually drives us to the next topic.
Tools
So as we all know you can go to Bing or Google and type SharePoint, and the first page is full of tool vendors selling a solution that can fix your Administration pains. I will not go into Tool justification mode, but Shop Around and ask your fellow SharePoint Guru’s there impression of the tools, good, bad and ugly. Don’t go spend 25K for a tool that does not justify a cost of return. I have listed a few of the tool vendors here that have Security or Admin control solutions.
Axceler
AvePoint
CA
DeliverPoint
Idera
Nintex
Quest Software
If you want my opinion of tools I am planning on a rant blog just for that reason.
Policy or Governance
This drives me to the next point…….Governance Baby….we all know it, we all think we have the best one ever. Well not all of us.Â
You can drive a better experience for your users if you give them a clear understanding of the security model, and the way to request support or users management. I have talked about this for years. Do not give your administrators the tool without a clear policy for them to enforce. Keep in mind you may also want to delegate a Security Administrator to take on that Role…..the Darth Vader of SharePoint in your office.Â
List/Library/Item level security
So you fell in love with the idea of "fine grained permissions". Are you sure…
Use case, Joe goes and uploads the latest specifications of the new company prototype. He is told, to just go upload it in the project site we all use for this project. OK. He does, but he was not aware that the site has inherited a larger audience….say the company (NT Authenticated Users). Now the specs are visible, downloadable, emailable to outside folks.
Another case could be folks hiding in plan site data, by restricting users to a few folks and thus trying to mask bad deeds.
How about cranking on Read access to a site by accident and now giving a Searcher access to confidential materials due to a odd search term.
I know these are extremes, but guess what, they happen every day in most organizations. While trying to control SharePoint sounds reminiscent of controlling a File Share they do work on a similar level. Controls or ownership of the containers need to be given to TRUSTED authorities. So do consider limiting Owner of Full Control to people that are willing to sign a policy, or managers that understand that is part of their role.
Soap Box
OK so I will step off my soap box now, and say, just Keep It Simple S… is a best practice. A SharePoint deployment can be a challenge, and managing it after can be a career don’t make it a pain. Consider coming into it with tighter controls, and roles, and then give more access and controls to the users as they show skills and knowledge.
When looking at SharePoint I always consider Kranzberg’s six laws of technology state:
Technology is neither good nor bad; nor is it neutral.
Invention is the mother of necessity.
Technology comes in packages, big and small.
Although technology might be a prime element in many public issues, nontechnical factors take precedence in technology-policy decisions.
All history is relevant, but the history of technology is the most relevant.
Technology is a very human activity – and so is the history of technology.So why you ask the six laws, because I hate to hear people blame a technology for a lack of understanding of the platform, not understanding how they company history impacts the solution, and a lack of policy/governance/training that MUST accompany any SharePoint deployment big or small.