1. Core Database Integrity and Bootability

Objective: Preserve the integrity of Oracle-maintained objects and the internal structures
required for a trustworthy, functional database.

• Protect critical dictionary objects and internal database components.
• Detect unauthorized modifications to designated Oracle-maintained objects.
• Distinguish successful startup from verified database integrity: a database can open while important internal objects have been altered.
• Maintain a tested recovery path to a known-good state.

2. Identity and Authentication

Objective: Ensure every database identity and connection is authenticated through an
approved mechanism.

• Use strong authentication and appropriately protected credentials.
• Restrict privileged access, including SYSDBA.
• Eliminate shared administrative identities where practical.
• Control authentication paths for both human and automated accounts.

3. Least Privilege and Authorization

Objective: Ensure identities can perform only the operations required by their legitimate
responsibilities.

• Minimize powerful system privileges and direct object grants.
• Separate administration, application ownership, monitoring, and security functions.
• Control privilege escalation and access to critical Oracle-maintained objects.
• Review privileged roles, grants, and authorization changes.

4. Network and Connection Isolation

Objective: Control which systems and identities can reach the database, and enable rapid
isolation when trust is lost.

• Restrict listener exposure, source addresses, services, and management interfaces.
• Separate application, administrative, and replication traffic where appropriate.
• Provide a tested mechanism to isolate a compromised primary and terminate customer sessions.
• Prevent unintended re-connection or split-brain operation during incident recovery.

5. Data Confidentiality and Protection

Objective: Prevent unauthorized disclosure or misuse of database information.

• Apply appropriate encryption in transit and at rest.
• Protect keys, credentials, backups, exports, and replication channels.
• Restrict access to sensitive data independently of application-level controls.
• Consider confidentiality risks in monitoring, incident evidence, and recovery procedures.

6. Secure Configuration and Attack-Surface Reduction

Objective: Minimize exploitable functionality and insecure configuration.

• Apply supported security fixes and maintain controlled Oracle homes.
• Disable unnecessary services, components, privileges, and network access.
• Protect operating-system accounts, database files, and administrative tooling.
• Detect unauthorized changes to configuration and executable software.

7. Accountability, Auditing, and Detection

Objective: Detect suspicious activity quickly and preserve evidence independently of the
potentially compromised database.

• Audit privileged actions and sensitive changes.
• Maintain external, independently protected audit and alert records.
• Compare critical objects against a trusted baseline.
• Treat critical integrity violations as incident triggers, not merely audit findings.

Operational rule: Containment must not wait for root-cause analysis. Preserve evidence
where practical, but never let evidence collection delay protective action.

8. Operational Resilience and Trusted Recovery

Objective: Restore service from a known-good database state without reintroducing the
compromise.

• Maintain tested backups, Flashback Database capability, and an appropriately configured physical standby.
• Establish recovery points that are actually usable—not merely recorded as restore points.
• Account for redo propagation: a physical standby may already contain the same malicious change as the primary. A logical standby database will be always containing the same malicious change as the primary.
• Isolate the suspect primary, freeze standby recovery as needed, select and validate a pre-incident recovery point, flash back the standby if required, and only then activate it.
• Validate integrity before reopening customer access.
• Explicitly account for legitimate transactions lost when recovering to an earlier point.

The governing rule is: restore trust before restoring service.

9. Secure Lifecycle and Continuous Assurance

Objective: Ensure security controls remain e ective throughout the database lifecycle.

• Automate security configuration, baseline verification, and integrity monitoring.
• Test isolation, Flashback, failover, and recovery procedures regularly.
• Verify that monitoring works independently of the database being monitored.
• Reassess controls after upgrades, migrations, configuration changes, and incidents.
• Require documented authorization before returning a compromised system to trusted service.

10. Host-Level Trust and Privileged OS Compromise

Objective: Prevent operating-system administrative access from automatically becoming unrestricted Oracle database administrative access and protect the database when the OS security boundary is compromised.

• Assume local Oracle binaries, files, logs, and monitoring may have been tampered with.
• Separate control over database hosts, recovery infrastructure, credentials, and backups.
• Maintain independent detection, evidence, and isolation capabilities.
• Prevent a compromised primary host from compromising the standby or recovery resources.
• Re-establish trust through independent verification or a trusted rebuild before reusing the a ected host.
• Prevent OS-to-SYSDBA privilege escalation. A user with OS root access must not obtain Oracle SYSDBA solely by switching to the Oracle software owner account and executing sqlplus “/ as sysdba”.
• Require independent authorization for privileged database access. Enforce an additional authorization step that cannot be satisfied merely by assuming the oracle OS identity.
• Restrict and audit OS identity transitions. Control access to the Oracle software owner account and record attempts to assume that identity or obtain privileged database access.
• Separate trust boundaries. Do not rely exclusively on controls that a compromised root account can modify, disable, or bypass.
• Protect independent recovery infrastructure. Prevent primary-host administrators from unilaterally controlling the standby, backups, recovery credentials, or external monitoring.
• Detect and contain host compromise externally. Preserve evidence outside the host and provide an independent means to isolate it.
• Re-establish host trust before reusing. Verify or rebuild the OS and Oracle software from trusted sources before returning the a ected host to service.

The governing rule is: always exercise control over the Oracle database parts that are accessible to the high-privileged OS users.

How the pillars work together

Prevent
Pillars 2–6: access, privileges, network, data, configuration

Detect loss of integrity
Pillars 1 and 7: critical-object protection, independent detection and evidence

Contain immediately
Isolate the primary, terminate customer activity, prevent further propagation

Recover and validate
Pillar 8: select a trusted recovery point, flash back if necessary, activate, validate, then restore service

Improve assurance
Pillar 9: test the response, address the cause, strengthen controls

Trust yourself only
Pillar 10: be always prepared for the OS security breaches

The important distinction is that detection, containment, investigation, and recovery are separate activities. Investigation determines how the compromise happened; it must not be a prerequisite for stopping the damage. Whatever you do, the main goals are operational resilience and continuous data trust.