In a previous post, we discussed identifying and selecting all appropriate STIGs and/or SRGs. The next task is to apply appropriate STIG(s) or SRG(s) to each component. This can be a difficult and complex task to complete, especially in environments with multiple operating systems (OS), applications, and hardware.
*STIG stands for Security Technical Implementation Guide while SRG stands for Security Requirements Guide.
This technical guidance will walk through the following steps to ensure a repeatable and consistent process:
- Documenting
- Reviewing and filtering individual STIG/SRG checks*
- Identifying programmatic vs manual checks
- Selecting and configuring implementation options
- Testing and validating checks
- Performing regular scans and remediation
*STIG/SRG checks are the individual line items found within each STIG/SRG. These are identifiable by the Vulnerability ID (Vul-ID).
1. Documenting
Documenting is an important part of the any configuration baselining effort and should be conducted throughout the lifecycle of implementing STIGs/SRGs. Failure to document from the beginning can lead to inadvertent omissions or errors, which will result in additional findings during an assessment. The most important portion of documentation is the determinations conducted during step 2 below. For each component, the following should be easily identifiable:
- Applicable STIGs or SRGs, including name and version
- Determination of STIG/SRG check applicability
- Justifications for any N/A or modified checks
Learn more about how to select a security technical implementation guide here.
2. Reviewing and Filtering Individual STIG/SRG Checks
For this step, each applicable STIG should be reviewed by the implementer to filter out any checks that are not applicable to the target system component(s) and to ensure that individual checks will not disrupt the functionality of the system. STIGs and SRGs are created and managed by DISA, which means that they contain some checks that are specific to a DoD environment and may not be applicable to environments that are not supporting DoD.
Not Applicable checks
An easy example of a check that is not applicable is the requirement to install DoD Root CA certificates on all OS endpoints. (Windows 10 check shown):
This type of check can easily be documented as Not Applicable and can be ignored for application to target components. A justification will need to be generated by the implementer and reviewed and approved by the 3PAO during the assessment. For FedRAMP packages specifically, this will not be included as a POA&M if approved.
Applicable with modification checks
Another type of check that should be identified is one that should be applied but will require some modification to meet the organization’s specific requirements. An example of this is the requirement to apply the DoD Warning Banner on all endpoints. (Windows 10 check shown):
This type of check should be applied; however, the actual verbiage of the warning banner/legal notice should be altered to the organization’s version of the software. This check would be documented as applicable with modifications, and the modifications (verbiage change) should be documented as well.
Checks that may risk breaking the system component
There are checks included in STIGs that may break the component due to the unique configuration(s) that the organization’s software requires. These types of checks should be reviewed with system administrators and/or developers to verify and validate that the check is required and that a justification has been documented. These checks must be included as a POA&M along with the justification in the Operational Requirement column.
3. Identifying Programmatic vs. Manual Checks
After filtering all applicable STIG/SRG checks, the checks should be categorized as either a programmatic or manual implementation. This step is the most time-consuming task; however, it sets the organization up to reduce future workloads via automation. Administrators and/or developers should be included in any determination to ensure the categorization is accurate.
Programmatic checks
Programmatic checks are simply those checks that can be applied by an automated means, either with existing tools or custom scripts.
For organizations utilizing Windows-based operating systems, checks can be quickly categorized as programmatic if they include a “Check Text” or “Fix Text” with references to Registry, PowerShell, or Group Policy. In the example below, the Check Text references a Registry value, while the Fix Text references Group Policy. (Windows 10 check shown):
For organizations utilizing Linux/Unix based operating systems, checks can be quickly categorized as programmatic if they include a “Check Text” or “Fix Text” with commands that can be entered in a terminal. In the example below, both the Check Text and the Fix Text have a sudo command to verify and validate the setting is configured correctly. (RHEL 8 check shown):
Manual checks
Manual checks are those checks that require outside interaction to apply and validate. These can include checks with references to procedures or checks that are outside of what automation tools can accomplish. In the example below, the categorization of an information system is not something that can be checked via automation and the creation of additional domain controllers may be a manual procedure. (AD Domain check shown):
4. Selecting and Configuring Implementation Options
Once all STIG/SRG checks have been categorized, the next step is to select how checks will be implemented within the environment. The major options here are to implement everything manually, which is not viable in an environment with a variety of endpoint types, or to select automation tooling. The selection of automation tools should be determined by the implementors, as they will be responsible for configuring the tools.
Manual implementation
Manual implementation of checks is fairly simple, in that the instructions are included in the checks themselves. As shown in the examples above for Programmatic Checks, the “Fix Text” shows the implementor where to navigate within the GUI or terminal to implement the check requirement. However, the drawback of this style of implementation is the actual number of checks that must be implemented per OS, application, or device. Using the example of a single IIS web server, see below for the number of checks required:
| # of checks | STIG Title |
| 273 | MS Windows Server 2022 STIG |
| 41 | MS Defender Antivirus STIG |
| 21 | MS Windows Firewall STIG and Advanced Security STIG |
| 16 | Microsoft .Net Framework 4.0 STIG |
| 45 | Microsoft IIS 10.0 Server STIG |
| 44 | Microsoft IIS 10.0 Site STIG1 |
| 286 | Application Security and Development STIG2 (optional) |
| 124 | Application Server SRG3 (optional) |
| 850 | Total number of checks |
1This is duplicated for each site hosted on the server.
2This is duplicated for each application on the server not covered by an application specific STIG or SRG.
3This is duplicated for each application on the server not covered by an application specific STIG or SRG.
Automated implementation
The alternative to manual implementation is to leverage automation to alleviate workloads on the implementors. Automation comes in many different flavors, and in some cases, may only require a few tweaks from the organization to meet their particular requirements and level of implementation. Usage of automation allows the organization to easily meet CM-6(1) by continuously enforcing, reviewing, and validating that the appropriate STIGs are applied to all endpoints, and meet CM-6(2) by providing notifications and logging of unauthorized changes. Additionally, automation allows for faster deployment of any updates required by regulatory bodies, as the changes can be made within the tool once and deployed accordingly.
Listed below are different options that can be utilized for automation. Each tool has its own pros and cons, and it is up to the organization and implementors to select the tool that best fits their requirements and available resources. No endorsement is implied by the identification of these possible solutions, and no disparagement is implied by the omission of other solutions.
- Ansible – free to use, however support options are available for purchase
- PowerShell Desired State Configuration (DSC) – limited in scope for applicability
- SCAP Compliance Checker (SCC) – limited in scope for applicability
- PowerStig – limited in scope for applicability
- Chef
- Puppet
An additional option for a Windows environment that is semi-automated would be the use of Group Policy Objects (GPO), where STIGs can be applied wholistically to the entire domain. The DISA STIG site has several pre-configured GPOs in a zip file that can be reviewed and deployed.
Alternate Implementations
Another option for implementing STIGs is a hybrid approach, such as where manual software implementation is utilized to build out images, and then the images are pushed out in an automated fashion. The drawback for this option is that the image must be updated on a regular basis to ensure compliance with any changes to STIGs as released by DISA. An example procedure would look like this:
- Install Windows Server 2022.
- Install base applications (e.g., Defender AV, MS Firewall, Advanced Security).
- Apply STIGs for Server, Defender AV, MS Firewall, and Advanced Security.
- Via automation, package and deploy the image as required.
- Perform a post deployment process that includes installation of applications and services required for each server type.
- Apply additional STIGs applicable to each server type.
5. Testing and Validating Checks
After selection and configuration of the implementation solution, implementors should apply and test the solution in a controlled environment to ensure that it does not disrupt system functionality. Some items to look for in testing include client/server communication and output of information. Audit logs and any associated monitoring tooling are essential here, as issues may not be readily apparent by navigating through the endpoint.
In addition to testing for functionality, implementors should perform an initial validation of the applied configurations. A scan conducted using a Security Content Automation Protocol (SCAP) validated product is strongly recommended here, as this will ensure that the scanner is capable of detecting and correctly displaying any missed STIG checks. As with all scanning tools available, each tool has its own pros and cons, and may not be fully compatible with the organization’s selected OS, applications, or hardware.
6. Performing Regular Scans for Vulnerabilities and Remediation
Once STIGs have been applied to the production environment, the operation moves into the Continuous Monitoring realm. When conducting required monthly vulnerability scans, the organization can configure SCAP validated scanners to check the compliance levels of each scanned endpoint. Once scan results are generated, the organization should include remediation of any compliance issues in their normal patching cycle. Any compliance issues should be notated in the POA&M, in the same manner as any un-remediated vulnerabilities.
Avoid Common FedRAMP Mistakes with 38North
To efficiently navigate the application of STIGs/SRGs to your environment on your path toward becoming a FedRAMP-authorized cloud service offering, having an effective roadmap is critical. It is easy to say, “I’ll STIG it”, but a complex task to accomplish. Working with a compliance consultant can make a world of difference.
At 38North Security, our experienced FedRAMP advisors have helped hundreds of companies achieve authority to operate. We’ll provide the guidance and support you need to avoid these common mistakes and more.
