mitre / oracle-database-12c-stig-baseline

InSpec profile for the Oracle Database 12c DISA STIG

oracle-database-12c-stig-baseline

InSpec profile to validate the secure configuration of Oracle 12c, against DISA's Oracle Database 12c Security Technical Implementation Guide (STIG) Version 1, Release 12.

Container-Ready: Profile updated to adapt checks when the running against a containerized instance of Oracle 12c, based on reference container: (docker pull tekintian/oracle12c)

Getting Started

For the best security of the runner, always install on the runner the latest version of InSpec and supporting Ruby language components.

Latest versions and installation options are available at the InSpec site.

Tailoring to Your Environment

The following inputs must be configured in an inputs file for the profile to run correctly. More information about InSpec inputs can be found in the InSpec Profile Documentation.

# description: Username Oracle DB (e.g., 'system')
user: ''

# description: Password Oracle DB (e.g., 'xvIA7zonxGM=1')
password: ''

# description: Hostname Oracle DB (e.g., 'localhost')
host: ''

# description: Service name Oracle DB (e.g., 'ORCLCDB')
service: ''

# description: Location of sqlplus tool (e.g., '/opt/oracle/product/12.2.0.1/dbhome_1/bin/sqlplus')
sqlplus_bin: ''

# description: Set to true if standard auditing is used
standard_auditing_used: false 

# description: Set to true if unified auditing is used
unified_auditing_used: false

# description: List of allowed database links
allowed_db_links: []

# description: List of allowed database admins
allowed_dbadmin_users: []

# description: List of users allowed access to PUBLIC
users_allowed_access_to_public: []

# description: List of users allowed the dba role
allowed_users_dba_role: []

# description: List of users allowed the system tablespace
allowed_users_system_tablespace: []

# description: List of application owners
allowed_application_owners: []

# description: List of allowed unlocked Oracle db accounts
allowed_unlocked_oracledb_accounts: []

# description: List of users allowed access to the dictionary table
users_allowed_access_to_dictionary_table: []

# description: List of users allowed admin privileges
allowed_users_with_admin_privs: []

# description: List of users allowed audit access
allowed_audit_users: []

# description: List of allowed dba object owners
allowed_dbaobject_owners: []

# description: List of allowed Oracle db components
allowed_oracledb_components: []

# description: List of Oracle db components allowed to be intregrated into the dbms
allowed_oracledb_components_integrated_into_dbms: []

# description: List of allowed Oracle dba's
oracle_dbas: []

Running This Profile

Using winrm

inspec exec https://github.com/mitre/oracle-database-12c-stig-baseline/archive/master.tar.gz -t winrm://<hostip> --user '<admin-account>' --password=<password> --input-file <path_to_your_input_file/name_of_your_input_file.yml> --reporter cli json:<filename>.json

Runs this profile over winrm to the host at IP address as a privileged user account (i.e., an account with administrative privileges), reporting results to both the command line interface (cli) and to a machine-readable JSON file.

The following is an example of using this command.

inspec exec https://github.com/mitre/oracle-database-12c-stig-baseline/archive/master.tar.gz -t winrm://$winhostip --user '<admin-account>' --password=<password> --input-file oracle-database-input-file.yml --reporter cli json:oracle-database-12c-stig-baseline-results.json

Using SSH

inspec exec https://github.com/mitre/oracle-database-12c-stig-baseline/archive/master.tar.gz -t ssh://<hostip> --user '<admin-account>' --password=<password> --input-file <path_to_your_input_file/name_of_your_input_file.yml> --reporter cli json:<filename>.json

Runs this profile over ssh to the host at IP address as a privileged user account (i.e., an account with administrative privileges), reporting results to both the command line interface (cli) and to a machine-readable JSON file.

The following is an example of using this command.

inspec exec https://github.com/mitre/oracle-database-12c-stig-baseline/archive/master.tar.gz -t ssh://$hostip --user '<admin-account>' --password=<password> --input-file oracle-database-input-file.yml --reporter cli json:oracle-database-12c-stig-baseline-results.json

Using Docker

inspec exec https://github.com/mitre/oracle-database-12c-stig-baseline/archive/master.tar.gz -t docker://<containerid> --input-file <path_to_your_input_file/name_of_your_input_file.yml> --reporter cli json:<filename>.json

Runs this profile over docker transport to the container ID , reporting results to both the command line interface (cli) and to a machine-readable JSON file.

The following is an example of using this command.

inspec exec https://github.com/mitre/oracle-database-12c-stig-baseline/archive/master.tar.gz -t docker://<containerid> --input-file oracle-database-input-file.yml --reporter cli json:oracle-database-12c-stig-baseline-results.json

Different Run Options

Full exec options

Running This Baseline from a local Archive copy

If your runner is not always expected to have direct access to GitHub, use the following steps to create an archive bundle of this baseline 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 baseline for the first time, follow these steps:

mkdir profiles
cd profiles
git clone https://github.com/mitre/oracle-database-12c-stig-baseline
inspec archive oracle-database-12c-stig-baseline
inspec exec <name of generated archive> -t ssh://$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 baseline:

cd oracle-database-12c-stig-baseline
git pull
cd ..
inspec archive oracle-database-12c-stig-baseline --overwrite
inspec exec <name of generated archive> -t ssh://$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>

Viewing the JSON Results

The JSON results output file can be loaded into heimdall-lite for a user-interactive, graphical view of the InSpec results.

The JSON InSpec results file may also be loaded into a full heimdall server, allowing for additional functionality such as to store and compare multiple profile runs.

Authors

• Alicia Sturtevant - asturtevant
• Krishna Kola, DIFZ

Special Thanks

• Mohamed El-Sharkawi - HackerShark
• Shivani Karikar - karikarshivani

Contributing and Getting Help

To report a bug or feature request, please open an issue.

NOTICE

© 2018-2020 The MITRE Corporation.

Approved for Public Release; Distribution Unlimited. Case Number 18-3678.

NOTICE

MITRE hereby grants express written permission to use, reproduce, distribute, modify, and otherwise leverage this software to the extent permitted by the licensed terms provided in the LICENSE.md file included with this project.

NOTICE

This software was produced for the U. S. Government under Contract Number HHSM-500-2012-00008I, and is subject to Federal Acquisition Regulation Clause 52.227-14, Rights in Data-General.

No other use other than that granted to the U. S. Government, or to those acting on behalf of the U. S. Government under that Clause is authorized without the express written permission of The MITRE Corporation.

For further information, please contact The MITRE Corporation, Contracts Management Office, 7515 Colshire Drive, McLean, VA 22102-7539, [phone].

NOTICE

DISA STIGs are published by DISA IASE, see: https://iase.disa.mil/Pages/privacy_policy.aspx

oracle-database-12c-stig-baseline's Issues

Attributes should be assigned inside control block

When the attribute is assigned outside of the code block and you run the profile as a whole you get a bit of slowdown and congestion since it tries to assign the attribute but finds that it's already been initialized. We came across this issue a lot in the old style of creating attributes in InSpec.

If the attributes are moved within the control block you will get a bit faster run time and remove the warning messages that pop up when running commands on the profile.

Example of what the issue looks like:

List of controls with attributes outside of control block:

• V-61415
• V-61433
• V-61437
• V-61439
• V-61445
• V-61451
• V-61459
• V-61461
• V-61467
• V-61507
• V-61589
• V-61599
• V-61653
• V-61655
• V-61657
• V-61659
• V-61661
• V-61663
• V-61669
• V-61673
• V-61679
• V-61681
• V-61683
• V-61869

Rubocop issues

The following rubocop issues were found:
rubocop.txt

General - correct logic on "no user profiles found"?

When/if we encounter this situation, is this the correct logic to implement?

if user_profiles.empty?
describe 'There are no oracle user profiles, therefore this control is N/A' do
skip 'There are no oracle user profiles, therefore this control is N/A'
end
end

"is not a finding" STIG-speak = Pass, not N/A

"is not a finding" STIG-speak = Pass, not N/A

Put profile name in the title of describe block for clarity

For controls:
61603
61605
61607

Emergency/Temp profile array for V-61561

V-61561 needs to allow the user to define their set of defined emergency and temporary account profiles to let the logic focus on only.

Fix V-61415

There are no NA cases in this control, just pass or fail and a skip.

Not a finding - means pass the test no NA

V-61541 - should it be a pass if empty?

https://github.com/mitre/oracle-database-12c-stig-baseline/blob/master/controls/V-61541.rb

InSpec Check warnings

The following warnings were shown by inspec check:

Sample Data

Unhardened data already exists, would also need hardened results in the profile.

Input variables for V-61605, V-61561 and V-61717

For overlays, need inputs to be able to adjust the:

• allowed failed logon attempts for V-61605
• password lifetime for a profile for V-61561, and
• the account inactivity age for V-61717.

Fix V-61411

The logic seems like it should be:

the describe blocks for both should always ensure that the result should_not be 0 - if the count is zero then this is a finding.

on the first query - if you have any results - the results should be saved and displayed and the second describe block should skip if > 0 and display the ask the DBA / ISSO if #{results} are acceptable.

Fix V-61419

https://github.com/mitre/oracle-database-12c-stig-baseline/blob/master/controls/V-61419.rb#L34

This means there needs to be another describe block and that there should be an attribute for the something_raid_not_used. If a raid is not used, then the value should_not be < 2 if a raid storage device is being used than it seems the value should be >= 1.