Compliance Auditing with Microsoft Powershell

Compliance Auditing with PowerShell

Microsoft’s PowerShell framework has been part of their product line for quite some time. In recent years, it has played a major role in new operating system versions (such as Window 7 and Windows Server 2008) thanks to its inclusion in common engineering criteria. All future Microsoft server products will have PowerShell support integrated in them by default. This means Microsoft products will benefit from a single management interface, rather than a mixed usage of the registry, WMI, or other system files/utilities.

For those unfamiliar with PowerShell, it’s a command-line shell meant to perform administrative tasks using cmdlets. Cmdlets are purpose-built commands designed to accomplish specific tasks for reading registry keys, files, wmi-objects, starting and stopping Windows services, and a host of other tasks. A wide range of cmdlets and their usage are documented on Microsoft’s website.

The ability to run PowerShell cmdlets remotely opens up interesting possibilities from a compliance perspective. For example, it’s now possible to read a file, apply several different filters, and determine compliance. You can also run a cmdlet and let the user review the output, then tailor the output as needed. Tenable recently added an AUDIT_POWERSHELL check to Windows compliance checks which allows users to do just that, right from an .audit file. Below is the basic syntax:

Users can opt to audit a specific value or have the check report the entire output of the cmdlet being run. When reporting the output of the cmdlet, users have the option to set the severity of the result using the ‘severity’ tag.

Powershell Auditing Examples

1. Review security patches

   type: AUDIT_POWERSHELL
   description: "Show Installed Hotfix"
   value_type: POLICY_TEXT
   value_data: ""
   powershell_args  : "get-hotfix | Where-Object {$_.Description -ne ''} | select Description,HotFixID,InstalledBy | format-list"
   only_show_cmd_output : YES
  severity : LOW

2. Audit a specific value

   type: AUDIT_POWERSHELL
   description: "Audit Service Status"
   value_type: POLICY_TEXT
   value_data: "Running"
   powershell_args  : "Get-Service | Where-Object {$_.name -eq 'browser'} | select status"
   check_type : CHECK_REGEX

3. Review system log

   type: AUDIT_POWERSHELL
   description: "Review System Log files "
   value_type: POLICY_TEXT
   value_data: ""
   powershell_args  : 'get-eventlog -newest 5 -logname system | format-list'
   only_show_cmd_output : YES

4. Show power settings

   type: AUDIT_POWERSHELL
   description: "Show Power settings"
   value_type: POLICY_TEXT
   value_data: ""
   powershell_args  : 'get-wmiobject -namespace rootcimv2power -class Win32_powerplan | select Description,IsActive | format-list'
   only_show_cmd_output : YES

5. Run a WMI method

   type: AUDIT_POWERSHELL
   description: "Run WMI method ListWebServiceExtensions() on IIsWebService object"
   value_type: POLICY_TEXT
   value_data: ""
   powershell_args  : '(get-WmiObject -namespace rootMicrosoftIISv2 -Class IIsWebService).ListWebServiceExtensions().Extensions'
   only_show_cmd_output : YES

6. Get a list of files in a directory

   type: AUDIT_POWERSHELL
   description: "Get list of all files within a directory"
   value_type: POLICY_TEXT
   value_data: ""
   powershell_args  : 'Get-ChildItem "C:Program FilesCommon Files'
   only_show_cmd_output : YES

7. Review contents of a file

type : AUDIT_POWERSHELL
description : “Review contents of a file”
value_type : POLICY_TEXT
value_data : “”
powershell_option : CAN_BE_NULL
powershell_args : “get-content ‘D:Apache2.2confhttpd.conf’ |
select-string -pattern ‘^ *<Directory' -context 0,10"
severity : MEDIUM
only_show_cmd_output : YES

The listed examples leverage cmdlets typically found in Windows operating systems which supports PowerShell. But, what if we need to audit a product which has its own set of PowerShell cmdlets (e.g., Exchange 2007 or SharePoint 2010)? For such products we need to specify Windows PowerShell Console Files located on the target system. A PowerShell Console File contains properties and registered snap-ins that extend PowerShell’s ability or features. Many of these files also add cmdlets for administering software installed on the system.

An example PowerShell snap-in is Microsoft.Exchange.Management.PowerShell.Admin provided by Microsoft Exchange 2007, which provides useful commands for administering Exchange via PowerShell. By adding support for Powershell Console Files to AUDIT_POWERSHELL, the Windows Compliance Checks plugin can now audit software products like Exchange 2007, SharePoint, and others. The “powershell_console_file” keyword can now be used with the AUDIT_POWERSHELL to call a specific PowerShell Console File located on the target system to run various get-* cmdlets, which allows a user to audit the target for compliance.

Exchange Configuration Audit Example #1 – Report Exchange 2007 Server Role:

            Windows Compliance Checks, version 2.0.28

Which file contains your security policy : powershell_test.audit
SMB login : administrator
SMB password : ********
SMB domain (optional) : testdomain
"Disable Unnecessary Exchange Services and Roles": [INFO]

Review the server's roles and ensure only necessary services are listed.

Requirements

• PowerShell must be installed on the target (older OSes do not have it installed by default).
• WMI must be enabled on the target.
• Firewall setting “Windows Firewall: Allow inbound remote administration exception” must be enabled.
• Note: At this time, only get-* cmdlets can be run. Cmdlet aliases (e.g., gwmi) are not supported.

Conclusion

Several compliance audit policies distributed by Tenable are already using the PowerShell functionality described above. For more information, and to download the policies themselves, log in to the Tenable Support Portal and go to the downloads area.