mapresto/powerstigscan

Audit utility for STIG compliance utilizing PowerSTIG DSC

powerstigscan's Issues

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 {}

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.

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

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.