National Cyber Security

Trust, but Verify

Recently, Tenable added audit files for Nessus ProfessionalFeed users allowing them to audit Microsoft SharePoint server configurations. The audit policy uses both operating system and database information from a SharePoint server farm and compares it against the settings specified in the DISA STIG guide for Microsoft SharePoint 2010 servers. This blog entry discusses some of the Nessus functionality that was used to create the audit file.

Poll the typical office about what functionality SharePoint delivers, and the responses tend to be quite varied. Often, SharePoint first appears in an environment as a feature-rich version of the venerable file share. Beyond storing, tracking, and securing documents, more recent versions have added and expanded the suite of collaboration and socialization tools. Many locations have begun to take advantage of the built-in discussion forums, knowledge base, and team or personal blogs. The net result is that more and more of an organization’s institutional knowledge and workflow can be routed or accessed through web interfaces or the SharePoint integration found in most Microsoft Office tools.

Additions to SharePoint 2010

SharePoint 2010 was a major upgrade over the previous 2007 version. Without a doubt, the biggest addition was the integration of PowerShell support and “Cmdlets” specific to SharePoint. Cmdlets offer powerful one-line commands that can be used by themselves or combined to accomplish very complex tasks. While the familiar STSADM.exe tools are still available, the power of running a quick one-liner on the command line or building out a complex script to fully automate an entire farm installation using PowerShell is quite compelling. Very little, if any, of the day-to-day administration of SharePoint isn’t possible completely through PowerShell. Microsoft’s TechNet provides several example PowerShell scripts (even if your PowerShell skills are limited, you can likely find a complete solution, or at worst a starting point for your own modifications).

Nessus provides a robust PowerShell audit check that was discussed here. Anyone not familiar with PowerShell in Nessus should review that post to get a basic understanding of how the fundamentals work. A PowerShell check in Nessus using the standard built-in Cmdlets will generally look similar to this example which checks to see if a Hotfix is installed on the target:

&ltcustom_item&gt
Type : AUDIT_POWERSHELL
Description : "Show Installed Hotfix"
value_type : POLICY_TEXT
value_data : ""
powershell_args: "Get-Hotfix | Where-Object {$_.Description –ne ''} | Select HotFixID | Format-List"
only_show_cmd_output: YES severity : LOW
&lt/custom_item&gt

The Get-Hotfix, Where-Object, Select, and Format-List items are standard Cmdlets available simply by having PowerShell installed. One of the first things you’ll notice is that the check format returns an error if you attempt to use any of the specific SharePoint Cmdlets. In order to get to the Cmdlets we’re interested in we need to point the check at the SharePoint console file so Nessus can take advantage of the extended Cmdlets. As a result, a typical SharePoint check adds an additional parameter called powershell_console_file. This additional parameter is also used for most of the PowerShell checks in the Exchange Server audit.

A SharePoint (or Exchange Server) PowerShell check will look something like this:

&ltcustom_item&gt
Type : AUDIT_POWERSHELL
Description : "Verify Site Collection Administrators'" value_type : POLICY_TEXT
powershell_console_file: "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\CONFIG\POWERSHELL\Registration \psconsole.psc1"
powershell_args : "Get-SPSite | select RootWeb,Url,Owner | Format-List" value_data : ""
only_show_cmd_output: YES
&lt/custom_item&gt

SharePoint’s Default Ports

During installation, SharePoint chooses a random port and establishes that for the Central Administration link. While this does provide a small level of security by avoiding a known port for automated tools to target, it also makes it more difficult for crafting firewall or IDS rules to limit access to the Central Administration link. Nessus can query SharePoint servers and return the current Central Administration port. This allows administrators to document a known port for limiting access and validate that this configuration is maintained:

&ltcustom_item&gt
Type : AUDIT_POWERSHELL
Description : " Central Administration port “
value_type : POLICY_TEXT
powershell_console_file: "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\CONFIG\POWERSHELL\Registration\psconsole.psc1"
powershell_args: 'Get-SPWebApplication -includecentraladministration | where {$_.IsAdministrationWebApplication} | Get-SPSite -identity {$_.Url} | select Port | Format-List'
value_data : "" only_show_cmd_output: YES &lt/custom_item&gt

This check can be used as-is to return the current port into the Nessus results. If a particular port value is documented and expected to be in use, the value_data could be modified to validate that specific custom value.

&ltcustom_item&gt
Type : AUDIT_POWERSHELL Description : " Central Administration port “ value_type : POLICY_TEXT
powershell_console_file: "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\CONFIG\POWERSHELL\Registration \psconsole.psc1"
?powershell_args : 'Get-SPWebApplication -includecentraladministration | where {$_.IsAdministrationWebApplication} | Get-SPSite -identity {$_.Url} | select Port | Format-List'
value_data : "" &lt/custom_item&gt

SharePoint and Anti-malware

Since file storage and sharing are so fundamental to SharePoint, making sure that files are clean entering and leaving SharePoint helps to protect any clients whose local anti-virus facilities aren’t up to date or functioning properly. Several products exist in the market specifically targeted at supporting anti-malware scanning on a SharePoint farm. Regardless of the specific product deployed, validating that SharePoint is actually scanning can be determined for both uploads and downloads.

Checking for scanning enabled on upload takes a slightly different path as it begins by leveraging a class directly rather than a Cmdlet:

&ltcustom_item&gt
Type : AUDIT_POWERSHELL
Description : "'Scan Documents on Upload is enabled"
value_type : POLICY_TEXT
powershell_console_file: "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\CONFIG\POWERSHELL\Registration\psconsole.psc1"
powershell_args: '[Microsoft.SharePoint.Administration.SPWebService]::ContentService
?
| select -ExpandProperty AntivirusSettings | Where-Object {$_.UploadScanEnabled -ne 1} | Format-List'
value_data : ""
powershell_option: CAN_BE_NULL &lt/custom_item&gt

SharePoint Web Applications

Tailoring SharePoint web applications and their application pools allow you to more efficiently utilize system memory. Running unnecessary application pools could result in significant overhead as each pool uses, at minimum, 100MB of memory even before it starts any caching. However, keeping internal and external or authenticated vs. anonymous content separated is a very basic security practice. Tracking the current allocation of web applications to application pools becomes a very simple check using the PowerShell Cmdlets.

&ltcustom_item&gt
Type : AUDIT_POWERSHELL
description : "Show App Pool Assigned to Web Application"
value_type : POLICY_TEXT
powershell_console_file: "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\CONFIG\POWERSHELL\Registration\psconsole.psc1"
powershell_args: 'Get-SPWebApplication | select ApplicationPool | Format- List'
value_data : "" only_show_cmd_output: YES &lt/custom_item&gt

This check could also be refined to directly return the application pool used by a specific web application like Central Administration:

&ltcustom_item&gt
Type : AUDIT_POWERSHELL
description : "Show App Pool Assigned to Central Administration"
value_type : POLICY_TEXT
powershell_console_file: "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\CONFIG\POWERSHELL\Registration\psconsole.psc1"
powershell_args: 'Get-SPWebApplication |
Where-Object {$_.ApplicationPool -eq $(Get-
SPWebApplication –IncludeCentralAdministration |
Where-Object {$_.IsAdministrationWebApplication} | select ApplicationPool).ApplicationPool} | select DisplayName,ApplicationPool | Format-List'
value_data : "" only_show_cmd_output: YES &lt/custom_item&gt

In addition, a final refinement of this check could be used to validate that the Central Administration site is using the specific application pool defined by local security policy:

&ltcustom_item&gt
Type : AUDIT_POWERSHELL
description : "Show App Pool Assigned to Central Administration" value_type : POLICY_TEXT
powershell_console_file: "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\CONFIG\POWERSHELL\Registration\psconsole.psc1"
powershell_args: 'Get-SPWebApplication |
Where-Object {$_.ApplicationPool -eq $(Get- SPWebApplication –IncludeCentralAdministration |
Where-Object {$_.IsAdministrationWebApplication} | select ApplicationPool).ApplicationPool} | select ApplicationPool | Format-List'
value_data : "" &lt/custom_item&gt

General SharePoint Auditing Features

In addition to the examples above, this audit file contains more than 70 checks to validate a host for common configuration details including many of the most frequent pitfalls.

• Session timeouts
• Security attributes
• IRM settings
• Access and authorization
• SharePoint services
• Auditing

Many of the checks in the audits are specifically written with local customizations in mind so that values for users, groups, and remote services can be easily integrated into the audit allowing customized results. This audit can be used as is or as a basis for further customization based on the specific needs of the organization.

Further Reading

If you want to dig deeper into the benefits and value of configuration auditing, please refer to our interview with Gene Kim. We discuss with Gene what makes a great IT organization and how configuration auditing can be used effectively.

*Originally written by Justin Brown, Tenable Compliance Auditor