For those of you having your first experience with DISA STIGS and SharePoint I am sure you are finding that it is a bit convoluted, confusing, and there is little to no guidance published from Microsoft on this topic. I have been involved with a large SharePoint 2010/2013 implementation and migration project with one of our customers who happens to be in the Health Care industry and has to maintain compliance to these STIGS and other security measures on their systems.
It has been very interesting and frustrating since SharePoint is such a complex product and relies so heavily on other systems and applications. Unfortunately I cannot cover all the pitfalls and issues that were encountered through this deployment, but I can hopefully at least provide some of my experiences and what to watch out for.
The interesting thing about STIG compliance and SharePoint is that it is not just SharePoint that is involved in this lock down process. The other systems/applications that SharePoint interacts with and depends upon are also subject to STIG lock downs which causes some interesting issues as your are building and configuring your farm.
SharePoint and these other applications all have their own set of compliance configuration that must be performed. This makes it even more challenging as the configuration performed in these other systems does not take into account the requirements of SharePoint. So there were areas that when locked down would break OOTB SharePoint functionality.
The main systems we have had to deal with have been:
- SQL Server 2008 R2 / SQL Server 2012
- SQL Reporting Services 2008 R2 / 2012
- IIS 7.0
- Windows Server 2008
- SharePoint 2010 / 2013
Out of all the systems mentioned above the one that has caused us more issue and pain by far is the SQL server. The configuration that gets done on the SQL servers for the security lock down essentially renders SQL unusable to SharePoint. The problems begin as soon as you try to create a configuration database to build the farm and don't stop there. As you progress through the build process you find problem after problem that requires custom roles being created in SQL to remedy the issues encountered. In our case it would come down to watching ULS logs and running SQL traces as we were performing the various configuration tasks that are required to build out and fully configure a farm.
Once I was able to get through the installation items I thought I was in good shape and that the rest of the deployment should smooth out and become more standard. How wrong I was about that. After the farm had been built we then started testing the various functionality the client was using. I quickly found that there was still a good bit of work ahead of me. In this particular environment SQL Reporting Services reports were used very heavily and I found out quickly that there were a number of issues with these and the SQL lock down.
I was able to work with the DBA team to get all the required roles and permissions configured so that all required functionality was working as expected.
Below are some of the resources I found useful when wading through the convoluted waters of compliance
STIG Viewer - Useful site that allows you to quickly find information on the various STIG's
http://www.stigviewer.com/
http://www.stigviewer.com/
National Vulnerability Database
http://web.nvd.nist.gov/view/ncp/repository/checklistDetail?id=411
http://web.nvd.nist.gov/view/ncp/repository/checklistDetail?id=411
IASE STIG Information
http://iase.disa.mil/stigs/
http://iase.disa.mil/stigs/
SharePoint and compliance can be a very confusing, difficult, and extremely time consuming to get implemented if you are unfamiliar with what all is required and how all of this impacts your SharePoint deployment.
