MOSS 2007: meeting DOD DISA STIG compliance

Posted: March 16, 2009 in MOSS 2007

MOSS 2007: Meeting DOD DISA STIG restrictions with your farm

 

                Throughout my experiences with MOSS, I have done more architectures, configurations, installations, than I can count. I have had many challenges in farm configuration but none of these come close to the challenge of meeting DOD DISA STIG restrictions (listing: http://iase.disa.mil/stigs/stig/index.html)  for a MOSS farm. There were many challenges, some technical some organic in nature. I am going to attempt here to give you a strategy for approaching this task, some lessons learned, and where possible some areas you need to be careful of.  Anyone who has gone through this and would like to share, PLEASE DO. This can be quite a challenge.

                First off, when it comes to STIGs. If you have looked at the list, they are not a “Change setting A at registry point A” type of listing. In many cases, there are different ways to achieve compliance with a particular item. A good example, had a client who needed to correct an issue with the VB Scripting engine on the OS. The way MS recommends doing this, is to restrict security (ACLs) on the dll. The client’s methodology was to unregister the dll. This caused serious issues for MOSS when it came to configuration and patching as this dll was accessed by the configuration manager.

                Adding to this, currently Microsoft does not provide any official guidance on implementing the STIGs set. So most companies to not have that guidance on how to implement these without disabling operating system components.

Preparation

                When you start down this road, do not assume that just because in one house you ran through compliance with no issue, that you will have no problem at another one. First recommendation here, from the onset, get a virtualized environment that matches the production environment as much as possible. It MUST at least have the same operating system version and patch level.  Get this designed up from and in place ASAP. Your life will be much easier if you sort the STIG issues out up front for the particular environment than on the end of it.  It is likely, if you are in the DISA STIG environment you will have some firewall restrictions as well. It is really best if you also configure your test environment to match the same firewall restrictions you will have in production.

                Second recommendation, patch your MOSS environment (OS and applications) up to the latest  service pack and cumulative update. There are some restrictions (such as disabling SSL v2.0) which are much easier to correct when your OS is fully patched.

                Before we move on to planning your process keep this is mind, MOSS needs more permissions during the installation, and configuration process than it does during normal operation. The configuration wizard will utilize ports and OS components that you may not use otherwise. For this reason you need to be sure your restrictions are tested against the MOSS configuration wizard, SSP configuration, Web Application configuration, etc as well as just a normally operating MOSS environment.

 

Process

                Third recommendation, plan out your process for reaching compliance before you start.  You will need to plan on getting time from the networking, platform (OS), AD, and application security staff during this process. This may be 1 person or a dozen people depending on the size of your organization.

                As for the process, one method which worked for us on a previous engagement. Apply the full set of STIGs for the company to your environment prior to installing MOSS. Once this is done, attempt to install and configure your application/Index server. Chances are this will fail in some manner. 

                Assuming it does fail, the next step, break the STIGS up first by severity level (High, Medium, Low, Informational). For each of these groups, break the STIG up further into groups of 20-30. Try to group them into functional areas (i.e. File ACLs, IE settings, service permissions, etc). If a particular group holds lower risk of causing issues you can group more than 20-30. A good example of this. We had 80 IE settings that posed an extremely low risk of causing MOSS issues, we grouped all together.

                For each grouping, first apply the full group, and test the config/install you tried with the full set. If no issues occur, snapshot your VM, and move on to the next group. If the group causes an issue, roll back and move through the group 1 by 1 till you locate the setting that causes the issue.  Depending on staff availability, the manner in which certain STIGs are applied, and farm architecture, it can take between 1 to 4 weeks to run through 700 settings in this manner. 

                Keep in mind, the vast majority of settings will not impact MOSS. In the last project we worked through out of 600+ settings 10 caused issues. You will need to refine your process to find issues like this on an ongoing basis as STIGs are periodically updated and you will find the need to continually test these new restrictions. Although, the updates will come in much smaller chunks than the initial implementation (maybe average 6-20 additional settings every quarter).

                One other note, reboot at least once after EACH group is applied. Some of these restrictions will not be implemented fully until you reboot. You absolutely need to reboot after each set of restrictions are thrown on the system.

 

Areas of concern

                While the implementation of STIGs are to an extent unique to the site. There are some areas of concern that have been encountered clients sites that I can provide a heads up on that may allow you to head off some issues:

1.       File ACL’s – This is one of the biggest areas of concern. Many of MOSS’ issues here are the same for any ASP.Net based applications. Of particular concern  are the folders used for the ASP.Net JIT compiler and .Net framework assemblies. Many of these are located in c:windows subfolders and are accessed with user accounts that are NOT in the administrators group. It is HIGHLY recommended you do not just throw all MOSS service accounts into the administrators group. This is in violation of security best practices for MOSS and can lead to other problems. In addition to the c:windows there is also another important folder at: C:Program FilesMicrosoft Office Servers12.0. Under this folder, you have the office server web services, on query servers you also have file shares (by default) than contain your search indexes, as well as other resources your farm will need. See references for technet article on MOSS File permissions.

2.        Component Services/DTS – You will have a hard time finding anyone at MS (even the product team) to tell you any more than “I don’t know” about whether component services and DTS are necessary for MOSS to function. After much debugging and sleepless nights, I can say without it functional, your MOSS farm will not function properly. Whether it is component services or an underlying component,  when this goes down particularly Search begin to malfunction. This also seems to impact the Adobe Ifilters as well. Generally, registry or file ACLs are the culprits for bringing this service down.

3.       Local Security Policies

a.       Log in as a service – Some MOSS service accounts (depending on configuration) need to be able to log in as a service (i.e. web app pool accounts, search service accounts, excel services, etc). When these right are revoked, MOSS services will fail to start on reboot.

b.      FIPS – FIPS is a requirement by many government agencies. However, it is not a throw the setting and life is good with MOSS. You will need to make adjustments to your servers, web apps, and moss configuration to implement it. See the FIPS references to get started on this.

4.       Registry ACL’s – Registry ACLs can cause issue across the board to just about any component in the operating system or MOSS. You need to carefully inspect any registry ACL’s that are being applied. References for technet article on MOSS registry permissions

 

Summary

                Hopefully, this will give you a good start on implementing the DISA STIGs on your environment and help you avoid some pain. Please feel free to post any comments/links, etc from your own experience. This can be a daunting challenge and until we have good guidance from MS on securing the platform for these, any community assistance is greatly appreciated.

Reference

1.     MOSS File/Registry permissions: http://technet.microsoft.com/en-us/library/cc721638.aspx

2.     Firewall rules: http://blogs.msdn.com/joelo/archive/2007/02/13/protocols-ports-and-firewall-rules.aspx

3.     FIPS References: http://support.microsoft.com/kb/935434, http://support.microsoft.com/kb/811833

Advertisements
Comments
  1. Scott says:

    I appreciate the article. I’ll let you know how it turns out when we are done.

  2. Brian says:

    Great stuff Mike.. STIGs are particularly challenging for MOSS due to the breadth of most implementations (ISA, .NET, SQL Svr, SAN-compliance, etc).

  3. Michael says:

    That and from what I saw there is a wide lattitude in HOW they are met. We had MCS and Premier support involved at one site and the STIG implementation did so much damage to Windows Server, even Premier support could not find a fix. Their only solution was to completely reinstall the OS. In which case the only way to find out the cause was to simply roll them back 1 by 1 until we found the one (or last domino) that started issues. Usually it was a combination of them which caused a failure. Definitely the best way to go is a good methodology around testing them in a virtualized environment and finding a solution that secures your environment with a minimal amount of STIG exemptions, while allowing it to actually work as intended.

  4. Johnf416 says:

    Oh my goodness! an amazing article dude. Thanks Nonetheless I am experiencing issue with ur rss . Dont know why Unable to subscribe to it. Is there anybody getting similar rss drawback? Anybody who is aware of kindly respond. Thnkx cedcedfbaeek

  5. Johng557 says:

    I’m glad that it turned out so effectively and I hope it will continue in the future because it is so worthwhile and meaningful to the community. cddeabfdkfae

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s