Skip to content

Repository files navigation

cg-oracle-database-19c-stig-overlay

Out-of-band DISA Oracle Database 19c STIG hardening + assessment material for the STIG-hardened Oracle 19c offering brokered by cloud-gov/aws-broker (epic cloud-gov/aws-broker#519).

Status: work in progress — not a compliance attestation. This repo currently contains a draft control→layer map, a set of SQL hardening/assessment scripts, and an InSpec profile that requires all runnable controls from the baseline (see #3), and no STIG evidence has been generated against a live brokered instance. Do not read anything here as "STIG compliant."

Pre-production cleanup: much of the in-repo PR/issue references and development scaffolding will be removed before this repo goes to production, and the ADRs under docs/adr/ may be consolidated to drop decisions that are no longer relevant. Development-phase tracking links here are not intended to be permanent fixtures.

What this is (and is not)

The aws-broker provisions and configures a hardened Amazon RDS Oracle SE2 19c instance. This repo is the separate place where its database-layer STIG posture is meant to be hardened and validated — the broker deliberately never runs InSpec/CINC against itself (separation of duties).

Committed today:

  • control-layers.yml — a draft control→implementation-layer map.

  • hardening/sql/ — assessment-first, mostly-idempotent SQL for the database layer, plus rollback scripts.

  • An InSpec profile (inspec.yml + controls/) that depends on the cloud-gov fork of the MITRE baseline and include_controls all of its controls as defined there, to exercise the depends → overlay → SQL-verify path. The dependency approach is recorded in docs/adr/0001-consume-mitre-baseline-via-fork-depends.md.

Not yet committed (planned / tracked):

  • A consumer that reads control-layers.yml to classify a live run.
  • Any live-instance validation run (compliance evidence).

Layout

Path Purpose
control-layers.yml Draft control → implementation-layer map (set_by / verified_by). On managed RDS many controls are AWS-inherited, set by an RDS parameter/option group, or OS/listener-level (not applicable). This classifies controls so a future brokered-RDS run can report inherited / not-applicable / parameter-group controls correctly instead of failing them. Currently 14 explicitly-mapped controls plus 3 pattern-based default rules; status: draft and benchmark_version: unverified pending a cited DISA release. No consumer reads it yet.
hardening/sql/ Assessment-first, mostly-idempotent, non-SYS (RDS master-user model) SQL: connectivity, inventory, profile limits, sample-account lockout, unified audit policies, plus detect-first PUBLIC-grant and network assessments and a validation summary. Parameter-level controls (e.g. audit_trail) are set by the broker's RDS parameter group, not by these scripts (they remain SQL-verifiable). See hardening/sql/README.md for per-script scope and caveats.
hardening/sql/rollback/ Reversal for the reversible hardening scripts (10, 30; 20 is only partially reversible).
profile/ Placeholder for additional InSpec/CINC profile material — the runnable overlay controls are still being dispositioned (#3).
docs/adr/ Architecture Decision Records (MADR). See ADR-0001 for the baseline-dependency strategy.

Scope on managed RDS (honest limits)

  • SE2 offering. The brokered engine is Oracle Standard Edition 2 + License Included. SE2 lacks EE-only features (native TDE, Fine-Grained Auditing, VPD, Label Security, Partitioning). At-rest encryption is RDS-KMS (AES-256) and auditing is standard/unified — accepted as ISSO deviations with compensating controls, documented on the broker's Oracle feature branch (PR #537, docs/oracle19c/licensing.md; not yet on aws-broker main).
  • RDS master user, not SYS. All SQL assumes the RDS master (no SYS/SYSDBA); RDS-incompatible statements skip with a reason rather than error.
  • OS/listener/host controls are AWS-inherited or not applicable on managed RDS (no OS/listener/file access). control-layers.yml classifies these by pattern (e.g. tnslsnr, lsnrctl, /etc/oratab) so they are tagged, not failed. The exact count of affected controls will be known once the InSpec profile is committed and mapped (#3).
  • Local / offline runs are development signal only, never compliance evidence. Authoritative evidence requires a run against a real brokered GovCloud RDS instance (the WS15 live proof), which has not happened yet.

Related

About

Inspec Cinc-Auditor profile to validate Oracle 19c STIG conformance

Resources

Contributing

Security policy

Stars

0 stars

Watchers

0 watching

Forks

Releases

Used by

Contributors

Languages

Generated from cloud-gov/.github