This InSpec Profile was created to facilitate testing and auditing of MS SQL Server 2014 Database
infrastructure and applications when validating compliancy with Department of Defense (DoD) STIG
requirements
- Profile Version: 1.7.0
- STIG Date: 24 Jul 2024
- STIG Version: Version 1 Release 7 (V1R7)
This profile was developed to reduce the time it takes to perform a security checks based upon the STIG Guidance from the Defense Information Systems Agency (DISA) in partnership between the DISA Services Directorate (SD) and the DISA Risk Management Executive (RME) office.
The results of a profile run will provide information needed to support an Authority to Operate (ATO) decision for the applicable technology.
The MS SQL Server 2014 Database STIG Profile uses the InSpec open-source compliance validation language to support automation of the required compliance, security and policy testing for Assessment and Authorization (A&A) and Authority to Operate (ATO) decisions and Continuous Authority to Operate (cATO) processes.
The DISA RME and DISA SD Office, along with their vendor partners, create and maintain a set of Security Technical Implementation Guides for applications, computer systems and networks connected to the Department of Defense (DoD). These guidelines are the primary security standards used by the DoD agencies. In addition to defining security guidelines, the STIGs also stipulate how security training should proceed and when security checks should occur. Organizations must stay compliant with these guidelines or they risk having their access to the DoD terminated.
Requirements associated with the MS SQL Server 2014 Database STIG are derived from the Security Requirements Guides and align to the National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53 Security Controls, DoD Control Correlation Identifier and related standards.
The MS SQL Server 2014 Database STIG profile checks were developed to provide technical implementation validation to the defined DoD requirements, the guidance can provide insight for any organizations wishing to enhance their security posture and can be tailored easily for use in your organization.
It is intended and recommended that InSpec run this profile from a "runner" host (such as a DevOps orchestration server, an administrative management system, or a developer's workstation/laptop) against the target remotely over winrm.
For the best security of the runner, always install the latest version of InSpec on the runner and supporting Ruby language components.
The latest versions and installation options are available at the InSpec site.
-
The latest
releasedversion of the profile is intended for use in A&A testing, as well as providing formal results to Authorizing Officials and Identity and Access Management (IAM)s. Please use thereleasedversions of the profile in these types of workflows. -
The
mainbranch is a development branch that will become the next release of the profile. Themainbranch is intended for use in developing and testing merge requests for the next release of the profile, and is not intended be used for formal and ongoing testing on systems.
The inspec.yml file contains metadata that describes the profile.
[Update the inspec.yml file parameter inputs with a list of inputs appropriate
for the profile and specific environment. Also update the inspec_version to the required version]
Chef InSpec Resources:
Note
Inputs are variables that can be referenced by any control in the profile, and are defined
and given a default value in the inspec.yml file.
Below is an example how the inputs are defined in the inspec.yml:
inputs:
# Skip controls that take a long time to test
- name: disable_slow_controls
description: Controls that are known to consistently have long run times can be disabled with this attribute
type: Boolean
value: false
# List of configuration files for the specific system
- name: logging_conf_files
description: Configuration files for the logging service
type: Array
value:
- <dir-path-1>/*.conf
- <dir-path-2>/*.conf
The Gemfile provided contains all necessary ruby dependencies for checking the profile controls.
All action are conducted using ruby (gemstone/programming language). Currently inspec
commands have been tested with ruby version 3.1.2. A higher version of ruby is not guaranteed to
provide the expected results. Any modern distribution of Ruby comes with Bundler preinstalled by default.
Install ruby based on the OS being used, see Installing Ruby
After installing ruby install the necessary dependencies by invoking the bundler command
(must be in the same directory where the Gemfile is located):
bundle install
Ensure the controls are chef-style formatted:
bundle exec cookstyle -a ./controls
Linting and validating controls:
bundle exec rake inspec:check # validate the inspec profile
bundle exec rake lint # Run RuboCop
bundle exec rake lint:autocorrect # Autocorrect RuboCop offenses (only when it's safe)
bundle exec rake lint:autocorrect_all # Autocorrect RuboCop offenses (safe and unsafe)
bundle exec rake pre_commit_checks # pre-commit checks
Ensure the controls are ready to be committed into the repo:
bundle exec rake pre_commit_checks
This options is best used when network connectivity is available and policies permit access to the hosting repository.
# Using `ssh` transport
bundle exec inspec exec https://github.com/mitre/MS SQL Server 2014 Database Security Technical Implementation Guide/archive/main.tar.gz --input-file=<your_inputs_file.yml> -t ssh://<hostname>:<port> --sudo --reporter=cli json:<your_results_file.json>
# Using `winrm` transport
bundle exec inspec exec https://github.com/mitre/MS SQL Server 2014 Database Security Technical Implementation Guide/archive/master.tar.gz --target winrm://<hostip> --user '<admin-account>' --password=<password> --input-file=<path_to_your_inputs_file/name_of_your_inputs_file.yml> --reporter=cli json:<path_to_your_output_file/name_of_your_output_file.json>
If your runner is not always expected to have direct access to the profile's hosted location, use the following steps to create an archive bundle of this overlay and all of its dependent tests:
(Git is required to clone the InSpec profile using the instructions below. Git can be downloaded from the Git site.)
When the "runner" host uses this profile overlay for the first time, follow these steps:
mkdir profiles
cd profiles
git clone https://github.com/mitre/MS SQL Server 2014 Database Security Technical Implementation Guide.git
bundle exec inspec archive MS SQL Server 2014 Database Security Technical Implementation Guide
# Using `ssh` transport
bundle exec inspec exec <name of generated archive> --input-file=<your_inputs_file.yml> -t ssh://<hostname>:<port> --sudo --reporter=cli json:<your_results_file.json>
# Using `winrm` transport
bundle exec inspec exec <name of generated archive> --target winrm://<hostip> --user '<admin-account>' --password=<password> --input-file=<path_to_your_inputs_file/name_of_your_inputs_file.yml> --reporter=cli json:<path_to_your_output_file/name_of_your_output_file.json>
For every successive run, follow these steps to always have the latest version of this profile baseline:
cd MS SQL Server 2014 Database Security Technical Implementation Guide
git pull
cd ..
bundle exec inspec archive MS SQL Server 2014 Database Security Technical Implementation Guide --overwrite
# Using `ssh` transport
bundle exec inspec exec <name of generated archive> --input-file=<your_inputs_file.yml> -t ssh://<hostname>:<port> --sudo --reporter=cli json:<your_results_file.json>
# Using `winrm` transport
bundle exec inspec exec <name of generated archive> --target winrm://<hostip> --user '<admin-account>' --password=<password> --input-file=<path_to_your_inputs_file/name_of_your_inputs_file.yml> --reporter=cli json:<path_to_your_output_file/name_of_your_output_file.json>
The JSON results output file can be loaded into Heimdall-Lite or Heimdall-Server for a user-interactive, graphical view of the profile scan results.
Heimdall-Lite is a browser only viewer that allows you to easily view your results directly and locally rendered in your browser.
Heimdall-Server is configured with a data-services backend allowing for data persistency to a database (PostgreSQL).
For more detail on feature capabilities see Heimdall Features
Heimdall can export your results into a DISA Checklist (CKL) file for easily uploading into eMass using the Heimdall Export function.
Depending on your environment restrictions, the SAF CLI can be used to run a local docker instance
of Heimdall-Lite via the saf view:heimdall command.
Additionally both Heimdall applications can be deployed via docker, kurbernetes, or the installation packages.
Defense Information Systems Agency (DISA) https://www.disa.mil/
STIG support by DISA Risk Management Team and Cyber Exchange https://public.cyber.mil/
MITRE Security Automation Framework Team https://saf.mitre.org
DISA STIGs are published by DISA IASE, see: https://iase.disa.mil/Pages/privacy_policy.aspx