Hardening a database when no vendor STIG exists

An accreditation package needs database security controls evidenced. You go looking for the STIG covering your platform and it does not exist.

DISA publishes vendor-specific Security Technical Implementation Guides for many products, but managed cloud databases have largely outpaced that catalogue. There is no Aurora PostgreSQL STIG. For a number of managed engines there is nothing platform-specific at all.

This is a solved problem, and the solution is documented, but it is not obvious the first time.

The Database SRG is the proxy

Where no vendor STIG exists, the Database Security Requirements Guide serves as the assessment baseline. It is the technology-agnostic layer the vendor STIGs are derived from, and it is accepted as the proxy in exactly this situation.

Recent revisions run to roughly 142 controls. Tracked in STIG Viewer like any other assessment, and reported the same way.

Interpretation is the actual work

Because the SRG is technology-agnostic, many controls are written for a database you administer at the operating system level. On a managed service you do not have that access, and you do not need it, because the provider satisfies the control in a way the wording does not anticipate.

Three categories emerge quickly:

• Directly applicable. Audit logging, role-based access control, encryption at rest and in transit, password and authentication policy. Configure and evidence normally.
• Satisfied by the platform. Physical and certain host-level controls the managed service inherits. Document the inheritance and cite the provider’s compliance artefacts rather than claiming the control yourself.
• Not applicable as written. Controls referring to capabilities the managed engine does not expose. Mark them and write the justification. This category is larger than expected and the justifications are the part an assessor actually reads.

Writing those justifications properly is most of the effort. It is also what makes the package defensible.

Remediate as code, not in the console

The single decision that determines whether this holds up over time.

Console changes are invisible, unattributable, and gone the next time infrastructure is reapplied. They also cannot be evidenced except by screenshot, which ages badly.

Remediation delivered through the infrastructure code and applied by the pipeline gives you four things at once:

• Every change reviewed before it lands
• Every change attributable to a person and a commit
• Configuration drift visible rather than silent
• An evidence trail that is generated rather than assembled

That last point is the one that pays back. Re-accreditation is a diff instead of an archaeology project.

Two practical notes

Static parameters need a restart, and that needs planning

Some hardening settings load at engine start rather than on demand. Audit extensions in particular are frequently preload-only. Group the static changes so the estate takes one restart rather than several.

Expect a first-apply race

Where hardening adds an instance and modifies an existing one in the same run, the cluster can be briefly unavailable while the new instance settles, and the modification fails with an invalid state error. It is a one-time condition on initial apply, and re-running once the cluster returns to available completes cleanly because the apply is idempotent.

Worth knowing so that it is recognised as expected rather than investigated as a fault. Not worth engineering around for a one-time event.

Why this is worth doing well

Database controls are frequently the weakest section of an accreditation package, because they sit between the platform team and the application team and belong clearly to neither.

Done as code, they become the strongest section: repeatable, reviewable, and evidenced automatically. That is a better position to be in than most programs manage, and it is available to anyone willing to do the interpretation work once.