Database Security Controls

Why Database Security Controls Matter
Databases are where the crown jewels live. Almost every breach you read about ends with an attacker exfiltrating records from a data store: customer PII, payment card data, credentials, health records, intellectual property. In the ISC2 CSSLP body of knowledge, database security sits inside Domain 4: Secure Software Architecture and Design because the decisions that protect data must be made when the architecture is designed, not patched in after a penetration test fails. A secure application sitting on an insecure database is still an insecure system. The CSSLP expects you to understand that the database is a trust boundary, that the application is often the only thing standing between an attacker and the data, and that defense-in-depth requires controls inside the database itself, in the data access layer, and in the surrounding operational environment.

What Database Security Controls Are
Database security controls are the architectural, technical, and procedural safeguards that protect the confidentiality, integrity, and availability of data at rest, in use, and in transit to and from a data store. They address four broad questions:
1. Who can connect to the database and what can they do? (authentication, authorization, privilege management)
2. What can be seen or reconstructed even by authorized users? (encryption, hashing, masking, inference and aggregation controls, views)
3. How does the application talk to the database? (parameterized queries, stored procedures, secure connection strings, connection pooling, least-privilege service accounts)
4. How do we know what happened? (auditing, logging, triggers, integrity monitoring)

How the Controls Work: The Core Catalog

1. Encryption at Rest
Transparent Data Encryption (TDE) encrypts entire database files, tablespaces, or disks. It protects against stolen backups, lost disks, and offline attacks, but it does not protect against a legitimate connection that queries the data, because the database decrypts transparently for any authorized session. Column-level (cell-level) encryption encrypts specific sensitive fields (SSN, card numbers) so that even a DBA or an attacker with SELECT privileges sees ciphertext unless they also hold the key. Column encryption is more granular and resists insider threats better, but it breaks indexing, sorting, and range queries on that column and adds application complexity. Application-layer encryption encrypts before data ever reaches the database, giving the strongest separation of duties between the data owner and the database administrator. Key management is the hard part: keys should live in an HSM or key management service, never in source code, config files, or the same database as the data they protect.

2. Hashing and Salting
Passwords and other secrets that never need to be read back should be hashed, not encrypted. Use a slow, adaptive algorithm designed for passwords (bcrypt, scrypt, Argon2, PBKDF2) with a unique per-record salt to defeat rainbow tables and make identical passwords produce different hashes. A pepper (a secret value stored outside the database) adds another layer. Exam tip in miniature: if the question says the value must be verified but never recovered, the answer is hashing; if it must be recovered, the answer is encryption.

3. Tokenization and Data Masking
Tokenization replaces sensitive data with a surrogate token; the real value is stored in a separate, hardened vault. This shrinks compliance scope (for example PCI DSS) because the application database never holds real card numbers. Data masking (static or dynamic) obscures data for non-production environments or for users who do not need the full value. Static masking permanently transforms copies used in dev and test; dynamic masking alters query results in real time based on the caller's role. Anonymization and pseudonymization are related privacy techniques; pseudonymized data can be re-linked with a key, anonymized data cannot.

4. Access Control and Privilege Management
Apply least privilege at every layer. The application service account should have only the CRUD rights it needs on only the objects it needs; it should never own the schema, never be sysadmin or DBA, and never be able to run DDL in production. Use role-based access control (RBAC) so permissions are granted to roles, not individual accounts. Separate accounts for migrations, reporting, and runtime. Enforce separation of duties so the person who administers the database is not the person who can read application secrets. Disable default accounts and change default credentials. Use strong authentication for administrative access (MFA, certificate-based, or integrated authentication rather than SQL logins where possible).

5. Views
A view is a stored query that presents a filtered or projected subset of one or more tables. Views are a classic security control because you can grant users access to the view while denying access to the underlying table, restricting both columns (vertical restriction) and rows (horizontal restriction, often called row-level security). Views support the principle of need-to-know and are a primary defense against inference attacks by hiding sensitive columns entirely.

6. Stored Procedures and Parameterized Queries
The number one database attack remains SQL injection, which happens when untrusted input is concatenated into a query string. The architectural fix is to separate code from data: parameterized queries (prepared statements) send the query structure and the values separately so the database never interprets input as code. Stored procedures encapsulate logic on the server, allow you to grant EXECUTE on the procedure without granting SELECT on the tables, reduce attack surface, and centralize validation. Be careful: a stored procedure that builds dynamic SQL internally with string concatenation is still injectable. ORMs help but can be misused with raw query methods. Input validation (allow-listing) is defense-in-depth, not a replacement.

7. Triggers
Triggers are procedures that fire automatically on INSERT, UPDATE, or DELETE. From a security standpoint they enforce integrity rules that the application cannot bypass, write audit records whenever sensitive rows change, block modifications outside permitted windows, or prevent deletion of records under legal hold. The exam frames triggers as an integrity and auditing control. The trade-off is performance overhead and hidden logic that developers may not realize is executing.

8. Inference, Aggregation, and Polyinstantiation
These are classic CSSLP concepts. Aggregation is when individually non-sensitive pieces of data combine into something sensitive (a list of names, a list of departments, and a list of salaries together reveal who earns what). Inference is when a user deduces protected information from authorized queries (if the average salary of a department of two is X and you know your own salary, you know your colleague's). Controls include query restriction, limiting result set size, cell suppression, noise or perturbation, differential privacy, and polyinstantiation, where multiple rows with the same primary key exist at different classification levels so a low-clearance user sees a plausible cover story instead of a telling null value. Polyinstantiation is specifically a multilevel security control to prevent inference.

9. Secure Connections and Connection Strings
Data in transit between the application and database must be encrypted with TLS; configure the server to require encryption rather than merely allow it, and validate certificates to prevent man-in-the-middle downgrade. Connection strings contain credentials and must never be hard-coded or committed to source control; store them in a secrets manager or protected configuration with encryption, and prefer managed identities or integrated authentication so no password exists at all. Use connection pooling carefully: pooled connections share the identity of the pool, so row-level security that depends on the end-user identity must be passed through explicitly (for example via session context) rather than assumed.

10. Auditing, Logging, and Monitoring
Enable native database auditing for logins, failed logins, privilege changes, schema changes, and access to sensitive tables. Ship logs to a separate, write-once or append-only store so an attacker who compromises the database cannot erase the evidence. Database Activity Monitoring (DAM) tools watch traffic for anomalous queries such as bulk exports. Log enough to reconstruct who did what and when, but do not log sensitive values themselves. Integrity controls such as checksums, hash chains, or digital signatures on critical records detect unauthorized modification.

11. Hardening, Patching, and Availability
Remove sample databases, disable unused features and extended procedures, bind listeners to private interfaces, place the database in a segmented network tier reachable only from the application tier, and keep the engine patched. For availability, implement encrypted backups that are tested for restore, replication, and failover, and protect backups with the same rigor as production because a backup is a complete copy of your data.

12. Normalization and Schema Design
The CSSLP treats normalization as an integrity control: eliminating redundant data reduces update anomalies and inconsistent copies of sensitive fields. Denormalization for performance should be a deliberate, documented decision with compensating integrity controls. Referential integrity constraints, check constraints, and appropriate data types are the cheapest defenses against bad data.

Putting It Together: Defense-in-Depth Architecture
A well-designed data tier looks like this: the application authenticates to the database with a least-privilege, non-shared identity over mandatory TLS; all data access flows through parameterized queries or stored procedures; sensitive columns are encrypted or tokenized with keys held in an HSM; passwords are salted and hashed; reporting users see only views; triggers write tamper-evident audit records; the database host is hardened, segmented, patched, and monitored; backups are encrypted and tested. No single control is relied upon; each layer assumes the layer in front of it will eventually fail.

Exam Tips: Answering Questions on Database Security Controls

Tip 1: Match the control to the data state. At rest means TDE, column encryption, or hashing. In transit means TLS. In use means dynamic masking, views, access control, or application-level encryption. If a question describes a stolen backup tape, the answer is encryption at rest, not access control.

Tip 2: Hash versus encrypt. If the data must be retrievable, encrypt. If it only needs to be verified (passwords, integrity checks), hash with a salt. Any answer proposing to encrypt passwords with a reversible algorithm is a distractor.

Tip 3: Know the inference family cold. Aggregation equals combining innocuous data into sensitive data. Inference equals deducing protected information from permitted queries. Polyinstantiation equals multiple versions of the same record at different classification levels to defeat inference. These are among the most frequently tested vocabulary terms.

Tip 4: Views and stored procedures are access-control answers. When a question asks how to let users read some columns but not others, or how to let an application modify data without granting table-level rights, the answer involves views or granting EXECUTE on stored procedures rather than direct table privileges.

Tip 5: SQL injection has one best answer. Parameterized queries or prepared statements are the primary control. Input validation, least privilege, and stored procedures are defense-in-depth. If the options include both parameterization and input validation and the question asks for the most effective control, choose parameterization. If the stored procedure builds dynamic SQL, it is not a fix.

Tip 6: Triggers equal integrity and audit. When the scenario describes automatically recording changes or enforcing a rule that must hold regardless of which application touches the table, think triggers.

Tip 7: Watch for TDE limitations. TDE does not stop an authenticated user or an injected query from reading plaintext. If the threat is an insider or compromised application, column-level or application-layer encryption is the stronger answer.

Tip 8: Key management is the real question. If an option stores keys in the database, in code, or in a config file next to the data, it is wrong. Look for HSM, key management service, or separation of key custody from data custody.

Tip 9: Least privilege and separation of duties beat convenience. Any answer that has the application connect as DBA, sysadmin, or schema owner is a distractor regardless of how well it solves the functional problem.

Tip 10: Think like an architect, not an administrator. CSSLP questions want design-time decisions. When two answers both work, prefer the one that is built into the architecture (parameterization, encryption by design, RBAC) over the one that relies on operational vigilance (periodic reviews, manual monitoring). When a question asks for the first step, it is usually classify the data or identify requirements, because you cannot choose controls until you know what you are protecting and from whom.

Tip 11: Read for the asset and the threat. Identify what is being protected (credentials, PII, card data), the state it is in, and who the adversary is (external attacker, insider DBA, compromised application, lost media). The correct control almost always falls out of those three facts.

Quick Review Checklist
Encryption at rest (TDE versus column versus application layer) and key management
Hashing with salt and pepper for secrets
Tokenization, static and dynamic masking, anonymization versus pseudonymization
Least privilege service accounts, RBAC, separation of duties, MFA for admins
Views for column and row restriction
Parameterized queries and stored procedures against SQL injection
Triggers for integrity enforcement and audit trails
Aggregation, inference, and polyinstantiation
Mandatory TLS, protected connection strings, secrets management
Auditing to a separate tamper-evident store, DAM
Hardening, segmentation, patching, encrypted and tested backups
Normalization and constraints as integrity controls

Master these, understand the trade-offs behind each, and you will be able to reason through any CSSLP database security scenario rather than relying on memorization.