NIST SP 800-30 Database Hardening & Quantitative Risk Assessment
Quantitative risk assessment applying the NIST SP 800-30 methodology to a production MySQL tier, pairing probability-weighted likelihood/impact scoring with concrete hardening controls.
A production MySQL cluster was assessed using the NIST SP 800-30 Guide for Conducting Risk Assessments, replacing the client's prior qualitative High/Medium/Low labeling with a quantitative scale — probability of threat-event initiation multiplied by probability of success, scored against defined confidentiality/integrity/availability loss magnitudes. The assessment identified over-privileged service accounts, unencrypted client transport, and disabled at-rest encryption on PII-bearing tables as the highest-value residual risks. Hardening controls were applied directly during the engagement and residual risk was recalculated against the same quantitative scale to demonstrate measurable reduction.
- Production MySQL 8.0 cluster (primary + 2 replicas)
- Database administrative access controls and privilege grants
- Backup and replication transport pipeline
The assessment applied the NIST SP 800-30 four-step risk assessment process — prepare, conduct, communicate, maintain — to a database tier handling customer PII, scoring each identified risk quantitatively rather than qualitatively so remediation could be prioritized by measurable expected loss.
- Apply the NIST SP 800-30 risk assessment methodology to the database tier
- Quantify likelihood and impact using a defined probability/loss scale rather than qualitative labels
- Harden database configuration against identified threat sources
- Recalculate residual risk after remediation to demonstrate measurable reduction
- 1Threat source and threat event identification (NIST SP 800-30 Table D-2)
- 2Vulnerability identification via configuration review and CVE cross-reference
- 3Quantitative likelihood scoring (probability of initiation x probability of success)
- 4Impact quantification against confidentiality/integrity/availability loss magnitude
- 5Hardening implementation and residual risk recalculation
# Enumerate over-privileged accounts
$ SELECT user, host, Grant_priv, Super_priv FROM mysql.user;
5 accounts hold SUPER privilege; 2 are unused legacy service accounts
# Enforce TLS-only client and replication transport
$ SET GLOBAL require_secure_transport = ON;
[OK] require_secure_transport = ON
# Remove anonymous and unused accounts
$ DROP USER ''@'localhost', 'legacy_report'@'%';
Query OK, 0 rows affected
# Verify at-rest encryption status
$ SHOW VARIABLES LIKE 'innodb_encrypt_tables';
innodb_encrypt_tables = ON
SUPER privilege granted to inactive service accounts
Two unused legacy service accounts retained SUPER privilege, giving any compromised credential full administrative control of the cluster.
Client connections permitted over unencrypted transport
require_secure_transport was disabled, allowing credentials and query data to traverse the network in plaintext.
At-rest encryption disabled on customer PII tables
innodb_encrypt_tables was unset on the primary node, leaving PII-bearing tablespaces readable directly from disk or backup.
- Revoke SUPER privilege from inactive accounts; enforce least privilege via role-based grants
- Require TLS for all client and replication connections
- Enable InnoDB tablespace encryption for PII-bearing tables
- Recalculate residual risk quarterly using the NIST SP 800-30 quantitative scale