mapresto/powerstigscan

Audit utility for STIG compliance utilizing PowerSTIG DSC

PowerStigScan

Release History

1.0.0.0 - Released February 8, 2019
1.0.0.2 - Released Feburary 25, 2019
1.1.0.0 - Released March 1, 2019
2.0.0.0 - Released June 17, 2019
2.0.1.0 - Released July 8, 2019

What's New!

Support for PowerStig 3.2.0

SCAP Integration

With 2.0.0.0 we have introduced integration with the DISA SCAP Compliance Checker (SCC) tool. This is not a requirement to run but it will allow you to use SCAP as an authoritative source for rules that it does cover. SCC does not have a lot of overlap with this module, mostly on the OS checklists, but it is seen as an authoritative source in many DoD organizations. If, between SCAP and PowerStigScan, there is a conflict between the two sources, the SCAP result will take precedence and will be annotated on the checklist.

Database Requirement Changes

Similarly, for those that are unable to use a SQL database in their environment, the requirement for a database has been lowered. You would still see many benefits in using a database such as reporting and archiving of results but now you can have basic functionality for CKL generation regardless of a database being present.

Organizational Settings Support

We now support custom org settings with PowerStigScan in a more consistent manner. First and foremost, you can store the org settings in the database for dynamic creation when a scan is triggered. Also, you can store your Org Settings XMLs in the .\PSOrgSettings\ path of your configured log path (default is C:\Temp\PowerStig).

How It Works

PowerStigScan is used to automate STIG auditing and checklist generation through the use of the PowerSTIG module. PowerStig uses DSC to configure an environment to be compliant with DISA STIGs using an automated process to convert the xccdf to a parsable xml file that is consumed by the module to generate the composite DSC resources.

PowerStigScan uses that engine with the declarative nature of DSC to test your environment against the compiled MOFs. This module is made to be used with the companion Database, whose build script is in the SQL folder. The database holds historical findings that can be used to compile the DISA CKL (Checklist) files that are consumable by the DISA STIGViewer tool.

How to Install

Database Install

Minimum Requirement - SQL Server Express 2016

Using the PowerSTIG_DBobjectDeploy_#.sql script in the ..\SQL folder, modify the following lines:

• :setvar MAIL_PROFILE "MailProfile"
• :setvar MAIL_RECIPIENTS "[email protected]"
• :setvar CMS_SERVER "STIG"
• :setvar CMS_DATABASE "PowerStigScan1234"
• :setvar CKL_OUTPUT "C:\Temp\PowerStig\CKL"
• :setvar CKL_ARCHIVE "C:\Temp\PowerStig\CKL\Archive"
• :setvar ORG_SETTING_XML "C:\Program Files\WindowsPowerShell\Modules\PowerSTIG\3.1.0\StigData\Processed"
• :setvar CREATE_JOB "Y"

The Server and Database should be the database location that you intend to install the database into. The MAIL_PROFILE is used to email reports from the database. CREATE_JOB will create a SQL agent job that can be used to automate scans on a predetermined basis. The CKL_OUTPUT and CKL_ARCHIVE are used during the batch scanning function and are paths relative to the server or computer that is scanning (i.e. if there is a SQL01 and MS01, the database is on SQL01 and you are scanning from MS01, the path C:\TEMP will be determined by the scanning server, in this case C:\TEMP on MS01).

Module Install

Using your preferred method to install this module you still need to configure a few settings to get started. First, using Get-PowerStigConfig, you can view the settings that are located in the config.ini that is located in the .\common directory of the module.These settings allow for simple and repeatable results in your environment. The primary settings to be concerned with will be the SQL server and database that you will be connecting to. You can use Set-PowerStigConfig to modify these settings.

Adding Target Computers

In order to use the SQL Batch functionality, the target servers must exist in the SQL database prior to attempting to running Invoke-PowerStigScan with the -SqlBatch switch. You can add servers to the database with the Add-PowerStigComputer cmdlet with the -ServerName parameter.

BugFixes

2.0.1.0

Added detection for PowerShell 5.1
Fixed issues preventing .Net SCAP scan from proceding
Added support to automatically set Non-Applicable rules for 2016 STIG to NA

Supported STIGs

PowerStig and SCAP comparisons

(Can run in PowerStig only or PowerStig + SCAP modes)

Windows Server 2016 Member Server - 1.7
Windows Server 2016 Domain Controller -1.7
Windows Server 2012R2 Member Server - 2.15
Windows Server 2012R2 Domain Controller - 2.16
Windows 10 Client - 1.16
Internet Explorer 11 - 1.16
Windows Firewall - 1.7
Windows Defender - 1.4 Mozilla Firefox - 4.25

PowerStig Only

Excel 2013 - 1.7
PowerPoint 2013 - 1.6
Word 2013 - 1.6
Outlook 2013 - 1.13
Windows Server 2012R2 DNS Server - 1.11

SCAP Only (Versions listed are for manual checklists)

Adobe Acrobat Reader DC Classic - 1.4
Adobe Acrobat Reader DC Continuous - 1.5
Google Chrome - 1.15
.Net Framework - 1.7

Known Issues

IIS, JRE, and SQL scans are not complete. We need to determine the information dynamically as storing static information will be too burdensome for most administrators.

powerstigscan's Issues

Add Oracle JRE to supported technologies

Is your feature request related to a problem? Please describe.
Oracle Java Runtime 8 is currently supported in PowerStig but not PowerStigScan

Describe the solution you'd like
Build the logic necessary for JRE to be supported by PowerStigScan.

Update CKL shells for new supported STIGs (PowerSTIG 2.4.0.0)

Describe the solution you'd like
New PowerSTIG release on 2/7. CKL shells must be updated to match supported STIG list.

Add SkipRule support to the database

Describe the solution you'd like
Allow the use of the skip rule functionality within PowerStigScan for rules that are broken or otherwise not applicable to the environment that is being tested.

The solution should have a means to pull the rule ID's by a per server and per role means. A description field should be added so that the reasons can be reviewed and the CKL file can be updated accordingly during a scan.

Manage XCCDF data in Database for archived CKL generation

Is your feature request related to a problem? Please describe.
In order to hold a single source of truth, maintaining the STIG information in the Database based on the PowerSTIG xmls, we would be able to generate the eventual CKL files with the same data used to run the test, removing the chance of a mixture of data across the scan

Describe the solution you'd like
New table that can track STIG rules information per STIG type (IE, Member Server, Domain Controller, etc.) that can be updated when a change is noticed in the PowerSTIG StigData folder.

Describe alternatives you've considered
Currently prestaging the empty ckl files prior to release. This can lead to inconsistent results vs written requirements if the CKL versions are not matched to PowerSTIG.

Windows Defender Support

Is your feature request related to a problem? Please describe.
Windows Defender is supported by PowerStig but not PowerStigScan

Describe the solution you'd like
Add Windows Defender support in PowerStigScan

Additional context
Solution must test if Defender is installed and/or Active. WMI, under the Antivirus class of the \root\SecurityCenter2 namespace can assist in this detection.

Move mof creation to parallel processing.

Is your feature request related to a problem? Please describe.
The mof generation portion of the script currently takes an excessive amount of time at scale, roughly 30-60 seconds per computer target. Moving this to a parallel process would be a massive improvement in runtime.

Describe the solution you'd like
Create a holder function that can be ran in a job to create the mofs necessary for each server.

Compress DSC scripts to single file

Is your feature request related to a problem? Please describe.
The current format for the DSC script is convoluted and messy. Different scans requires different files which makes allowing for multiple roles more difficult.

Describe the solution you'd like
Compress the DSC calling files to a single file so that it would be easier to process through on multiple roles. Most of the current scripts rely on the same parameters.

Additional context
SQL must be able to determine role type from the output of the scan data. As long as this still returns in a predicted way, we would be able to handle all of the mofs and dsc scripts being ran at once per server.

PowerStig version is hard coded

Describe the bug
When importing PowerStigScan and when importing the PowerStig DSCResource (DSCCall.ps1 line 64) the module version of PowerStig is hard coded for 3.2.0

To Reproduce
Steps to reproduce the behavior:

1. Import-Module -Name PowerStigScan
2. Invoke-PowerStigScan

Expected behavior
PowerStigScan should import the installed version of PowerStig

Modify OrgSettings within SQL

Is your feature request related to a problem? Please describe.
Org Settings are stored in SQL for a sql batch run. The org settings currently cannot be modified without creating a custom query in SQL.

Describe the solution you'd like
Create a stored procedure and wrapper function to allow modification and creation of new org settings

Update for PowerStig 3.2

Update support for PowerStig 3.2 release.

Path name formatting

Describe the bug
Several path names are joined through String joins. This can leave a path that looks like C:\Temp\PowerStig\CKL\20190517\server1DC.ckl

To Reproduce
Steps to reproduce the behavior:
Run a scan with -DebugScript on and review the variable declarations

Expected behavior
Clean formatted path names. This can be done by using Join-Path instead of the current method to ensure that the path is correct and can be used by various applications correctly.

Fix IIS scans

Is your feature request related to a problem? Please describe.
IIS is current unavailable for scanning targets even though it is supported in PowerStig

Describe the solution you'd like
IIS requires App Pool and Website relationships to generate the MOFs. This would need to be able to be grabbed dynamically for each server and website.

Generate CKL from PowerStig StigData

Is your feature request related to a problem? Please describe.
Using a single source of truth, we can ensure that the data that is returned is relevant to the user of the module

Describe the solution you'd like
If the STIG data is stored in SQL from the PowerStig xml files, we should be able to call that to build the CKL files at the end of the scan. This would ensure that both the scan that is being processed, and the CKL that is produced, is generated from the same data source.

Use Dynamic Parameters for Roles

Is your feature request related to a problem? Please describe.
There are multiple functions that reuses the same validateset for parameters. A dynamic parameter can allow for a single source of updating for this.

Describe the solution you'd like
Something close to below:

DynamicParam {
                # Set the dynamic parameters' name
                $ParameterName = "Role"

                # Create the dictionary 
                $RuntimeParameterDictionary = New-Object System.Management.Automation.RuntimeDefinedParameterDictionary

                # Create the collection of attributes
                $AttributeCollection = New-Object System.Collections.ObjectModel.Collection[System.Attribute]
            
                # Create and set the parameters' attributes
                $ParameterAttribute = New-Object System.Management.Automation.ParameterAttribute
                $ParameterAttribute.Mandatory = $true

                # Add the attributes to the attributes collection
                $AttributeCollection.Add($ParameterAttribute)

                # Generate and set the ValidateSet 
                $roleSet = Import-CSV C:\Users\mapresto\desktop\DynamicParamTest\Roles.csv -Header Role | Select -ExpandProperty Role
                $ValidateSetAttribute = New-Object System.Management.Automation.ValidateSetAttribute($roleSet)

                # Add the ValidateSet to the attributes collection
                $AttributeCollection.Add($ValidateSetAttribute)

                # Create and return the dynamic parameter
                $RuntimeParameter = New-Object System.Management.Automation.RuntimeDefinedParameter($ParameterName, [string], $AttributeCollection)
                $RuntimeParameterDictionary.Add($ParameterName, $RuntimeParameter)
                return $RuntimeParameterDictionary
        }

        Begin
        {
            $Role = $PSBoundParameters[$ParameterName]
        }

        Process {}

2.0.0.0 - Scans fail when "localhost" is used as computer target

2.0.0.0 only

Describe the bug
Using localhost as the target of the scan will cause SCAP/PowerStig comparisons to fail

To Reproduce
Steps to reproduce the behavior:
Invoke-PowerStigScan -ServerName localhost -RunScap

CKL's will be generated for "localhost" but any role that is shared between PowerStig and SCAP will fail to populate results. SCAP only roles (DotNet) and PowerStig only roles (Office, DNS) will populate correctly. SCAP only roles will use the server name of the local host while powerstig will use localhost as the servername

Expected behavior
All CKL's will be generated with the proper naming standard.

Additional context
Add any other context about the problem here.

Automatically Determine RoleSets for each server

Is your feature request related to a problem? Please describe.
Right now, we are using a compliance mapping in SQL to map servers to the roles that are being scanned against. Using PowerShell logic in either Invoke-PowerStigScan or Invoke-PowerStigBatch, we should determine if the relevant roles/applications are installed and use that to scan against.

Describe the solution you'd like
Test against WMI/Registry/WindowsFeature to determine what is installed out of the supported kit and dynamically assign those roles to be scanned on the server. This should be able to be compared at the end to ensure that a new mof and/or ckl is created for each role determined.

Older versions of FireFox do not scan

Describe the bug
Running Invoke-PowerStigScan with FireFox as a role may fail to find the install directory because the current version key does not exist.

Expected behavior
The key location for the install directory is dependent on version number. The current version key exists at the "HKLM:\Software\Mozilla\Mozilla Firefox" path in newer versions that could be used to predict the location of the needed key for the install directory. Older versions do not have this and requires additional logic to find the current version and install directory.

Add OrgSettings support to the database

Describe the solution you'd like
Using the database, custom org settings should be maintained byRole and byServer in order to generate a dynamic Org Settings xml to be used in the scan. For example, a Table has a list of VulnIDs for the STIGs that have org settings, for each ID there is a value and description. The description can be used to describe the purpose of the org setting or justification and this can be used to fill in the CKL file during the scan.