Oracle Database 19c Security Hardening – Part 16

By | | ,

Implementing CIS Oracle Database 19c Security Benchmark Controls

Security hardening is not only about applying individual best practices. In enterprise environments, organizations need a documented security baseline that can be measured, audited, and continuously improved.

This is where security benchmarks become important.

Frameworks such as CIS Benchmarks, ISO 27001 controls, PCI DSS requirements, and internal security standards provide structured guidance for protecting database platforms.

In this article, we will map Oracle Database 19c security controls to a practical hardening methodology inspired by CIS benchmark principles.

Why Security Benchmarks Matter

A common question during audits is:

“How do you prove that your Oracle database is secure?”

The answer cannot simply be:

“We configured it correctly.”

Security requires evidence.

A benchmark provides:

  • A documented security baseline.
  • Repeatable validation.
  • Audit evidence.
  • Risk measurement.
  • Continuous improvement.

Oracle Security Benchmark Categories

A database security benchmark usually evaluates the following areas:

+--------------------------------+
| Oracle Database Security       |
+--------------------------------+
| Authentication                 |
| Authorization                  |
| Auditing                       |
| Encryption                     |
| Network Security               |
| Configuration                  |
| User Management                |
| Privilege Management           |
| Backup Protection              |
| Patch Management               |
+--------------------------------+

1. Authentication Controls

Control Objective

Ensure that only authorized users can authenticate to the database.

Review Default Accounts

Oracle databases contain many predefined accounts.

Review:

SELECT username, account_status FROM dba_users ORDER BY username;

Look for:

  • Default accounts.
  • Unused accounts.
  • Accounts that should be locked.

Lock Unused Accounts

Example:

ALTER USER WADHAH ACCOUNT LOCK;

However, always validate dependencies before locking Oracle-maintained accounts.

2. Password Security Controls

Password policy is managed through profiles.

Review:

SELECT profile, resource_name, limit FROM dba_profiles WHERE resource_type='PASSWORD';

Recommended controls:

ParameterRecommendation
FAILED_LOGIN_ATTEMPTSLimited
PASSWORD_LIFE_TIMEDefined
PASSWORD_REUSE_TIMEControlled
PASSWORD_VERIFY_FUNCTIONEnabled

Example:

ALTER PROFILE DEFAULT LIMIT FAILED_LOGIN_ATTEMPTS 5;

3. Privilege Management

The principle of least privilege is one of the most important database security concepts.

Identify powerful privileges:

SELECT grantee, privilege FROM dba_sys_privs WHERE privilege LIKE '%ANY%';

Examples requiring review:

SELECT ANY TABLE
INSERT ANY TABLE
ALTER ANY PROCEDURE
DROP ANY TABLE

These privileges should be granted only when justified.

4. Role Management

Review roles:

SELECT grantee, granted_role FROM dba_role_privs ORDER BY grantee;

Pay special attention to:

  • DBA
  • EXP_FULL_DATABASE
  • IMP_FULL_DATABASE
  • DATAPUMP_EXP_FULL_DATABASE
  • DATAPUMP_IMP_FULL_DATABASE

5. Public Privilege Review

The PUBLIC role affects every database user.

Review:

SELECT owner, table_name, privilege FROM dba_tab_privs WHERE grantee='PUBLIC';

Examples requiring attention:

EXECUTE ON UTL_HTTP
EXECUTE ON UTL_SMTP
EXECUTE ON UTL_TCP

These packages can provide external communication capabilities.

6. Audit Configuration

Auditing must provide evidence of security activity.

Verify Unified Auditing:

SELECT parameter, value FROM v$option WHERE parameter='Unified Auditing';

Review policies:

SELECT policy_name, enabled_option FROM audit_unified_enabled_policies;

Recommended audit areas:

  • Logon activity.
  • Failed authentication.
  • Privilege changes.
  • User creation.
  • Role changes.
  • Database configuration changes.

7. Encryption Controls

Encryption should protect sensitive information both at rest and during transmission.

Verify TDE

SELECT wallet_type, status FROM v$encryption_wallet;

Expected:

OPEN

Verify Encrypted Tablespaces

SELECT ts# , encryptionalg FROM v$encrypted_tablespaces;

Verify Network Encryption

Covered previously in Part 3.

Validate:

  • AES encryption.
  • SHA integrity checking.
  • TLS where required.

8. Database Link Security

Database links are trust relationships.

Review:

SELECT owner, db_link, username, host FROM dba_db_links;

Security requirements:

✓ No unnecessary PUBLIC links
✓ No SYS connections
✓ Dedicated service accounts
✓ Encrypted communication

9. Data Pump Security Controls

Review Data Pump privileges:

SELECT grantee, granted_role FROM dba_role_privs WHERE granted_role LIKE 'DATAPUMP%';

Ensure:

  • Export files are encrypted.
  • Directory permissions are restricted.
  • Old dumps are removed.

10. Scheduler Security

Review external jobs:

SELECT owner, job_name, credential_name FROM dba_scheduler_jobs WHERE credential_name IS NOT NULL;

Validate:

  • Operating system accounts.
  • Job ownership.
  • Execution privileges.

11. Patch Compliance

Security controls are incomplete without current patching.

Review:

SELECT patch_id, description, status FROM dba_registry_sqlpatch;

Maintain:

  • Current Release Update.
  • Documented patch process.
  • Testing procedure.

Building a Compliance Scorecard

A practical benchmark report could look like:

ControlResult
Default Accounts SecuredPASS
Password PolicyPASS
Excessive PrivilegesWARNING
Unified AuditingPASS
TDE EncryptionPASS
Network EncryptionPASS
Database LinksWARNING
Data Pump SecurityPASS
Patch LevelFAIL

Automating Compliance Checks

The controls from previous parts can be converted into automated tests.

Example structure:

oracle19c-security/
|
├── authentication.sql
├── privileges.sql
├── auditing.sql
├── encryption.sql
├── database_links.sql
├── scheduler.sql
├── datapump.sql
├── patching.sql
|
└── security_report.sql

The final report can generate:

  • HTML output.
  • CSV export.
  • Security score.
  • Remediation recommendations.

Common Findings During Audits

Finding 1: Too Many DBA Users

Example:

Application_User   DBA
Developer_User     DBA
Reporting_User     DBA

Recommendation:

Remove unnecessary DBA privileges.

Finding 2: No Password Expiration

Example:

PASSWORD_LIFE_TIME UNLIMITED

Recommendation:

Apply controlled password policies.

Finding 3: Missing Patch Updates

Example:

Database Release Update:
19.12

Required:
19.25+

Recommendation:

Implement quarterly patch cycles.

Finding 4: Unencrypted Sensitive Data

Example:

Customer tablespaces:
NOT ENCRYPTED

Recommendation:

Enable TDE after impact analysis.

Security Checklist

Before completing a benchmark review:

✓ User accounts reviewed
✓ Default accounts secured
✓ Password policies enforced
✓ Privileges minimized
✓ PUBLIC grants reviewed
✓ Auditing enabled
✓ Encryption validated
✓ DB Links reviewed
✓ Scheduler reviewed
✓ Data Pump secured
✓ Patch level verified

Conclusion

A security benchmark transforms Oracle security from a collection of recommendations into a measurable process.

The goal is not to achieve a perfect score by disabling everything. The goal is to create a secure, documented, and controlled database environment that supports business requirements.

A mature Oracle security program continuously asks:

“Is this configuration still justified?”

That question is at the heart of database security.

Bookmark the permalink.
Loading Facebook Comments ...

Leave a Reply