Key Takeaways
|
2025 made a strong case for going back to basics. The Cl0p ransomware campaign exploited a critical vulnerability in Oracle E-Business Suite (CVE-2025-61882, rated 9.8 on the CVSS scale) and hit more than 100 organizations, including Harvard, the Washington Post, Canon, and Mazda. Ransom demands reached $50 million. Oracle issued patches on October 4, but many customers didn’t recognize the intrusion activity until extortion emails surfaced weeks earlier. In a separate incident, a threat actor compromised an Oracle Cloud Classic server that was part of Gen1 infrastructure and hadn’t been updated since September 2014. That server was still operational in February 2025. The resulting breach exposed 6 million records across more than 140,000 tenants.
Neither of these incidents required a sophisticated, novel attack technique. One exploited a known vulnerability before patches were applied. The other exploited a server that had been unpatched for over a decade.
IBM’s 2025 Cost of a Data Breach Report puts the global average breach cost at $4.44 million, with U.S. organizations averaging $10.22 million. Over 12,000 confirmed data breaches occurred globally in 2025, and 68% involved some form of human element, often through legitimate-looking login credentials. Even with AI-powered defenses helping organizations detect and contain breaches faster, 76% of affected organizations still took more than 100 days to fully recover.
The point isn’t to be alarmist. The point is that the fundamentals of Oracle database security haven’t changed much in the last decade, but the consequences of neglecting them have escalated dramatically. The eight steps outlined below aren’t exotic or cutting-edge. They’re the baseline. And the gap between organizations that execute on these basics consistently and those that treat them as “we’ll get to it later” items is the gap between a secure database and a breach notification.
At a Glance: 8 Database Hardening Steps
| Step | What It Addresses | What Happens If You Skip It |
| 1. Change default passwords | Known credentials on admin accounts | Brute force attacks succeed on first attempt |
| 2. Patch quarterly (or immediately) | Known vulnerabilities with public CVEs | Exploitation within hours of disclosure |
| 3. Lock default/unused accounts | Dormant accounts as entry points | Unauthorized access through forgotten accounts |
| 4. Implement least privilege | Excessive user permissions | Internal threats, lateral movement, unauthorized data access |
| 5. Enable TDE encryption | Unprotected data at rest | Stolen datafiles and backups are readable in cleartext |
| 6. Secure network connections (TLS) | Unencrypted data in transit | Credential and data interception on the network |
| 7. Enable unified auditing | Unmonitored database activity | Breaches go undetected; no forensic trail for investigation |
| 8. Remove unnecessary components | Unused features as attack surface | Exploitable code paths that serve no business purpose |
Oracle Database Security Best Practices
Step 1: Change Default Passwords and Enforce Password Policy
This one sounds almost embarrassingly basic, and yet it remains one of the most common findings in database security assessments. Every Oracle installation ships with default administrative accounts (SYS, SYSTEM, DBSNMP, OUTLN, and others), and the default passwords for these accounts are publicly documented. If they haven’t been changed, they’re the first thing an attacker tries.
IBM’s data reinforces why this matters: 68% of breaches involve the human element, and credential-based attacks remain the easiest, lowest-effort path into a system. Changing default passwords is the single fastest security improvement you can make on any Oracle database.
But changing them once isn’t enough. Oracle Database includes tools that most organizations underutilize. The Secure External Password Store creates a wallet file for protected credential storage, eliminating the need to embed passwords in scripts or application code. The built-in checkpwd utility scans password hashes against a dictionary file to identify weak passwords. And Oracle’s password verification function, which is often disabled by default, can enforce complexity requirements and expiration policies when enabled. Account lockout after failed login attempts should also be configured to prevent brute force attacks.
If you’re running Oracle databases and you’re not sure whether default passwords have been changed across every instance in your environment, that’s the first thing to fix. Today.
Step 2: Patch Quarterly. Patch Immediately When Critical
Oracle releases Critical Patch Updates (CPUs) four times a year: January, April, July, and October. These updates fix known security vulnerabilities across Oracle products, and Oracle publishes details about the vulnerabilities being patched.
Here’s the problem with that transparency: it tells attackers exactly where the weaknesses are. Industry research from Wallarm found that hackers can begin exploiting disclosed vulnerabilities in as few as two hours after a patch advisory is published. The organizations that delay patching are the ones that get exploited.
The Cl0p campaign is a textbook example. The vulnerability existed. Oracle released a patch. Organizations that applied it promptly were protected. Organizations that didn’t found themselves on the receiving end of extortion emails with $50 million demands. And the Oracle Cloud Classic breach is the extreme version of the same lesson: a server left unpatched for more than ten years, sitting in a production environment, accessible from the network, and eventually compromised.
Quarterly patching should be the minimum cadence for every Oracle database in your environment. When Oracle issues an out-of-band security alert for a critical vulnerability, the response time should be measured in days, not weeks. If your organization doesn’t have the internal capacity to maintain this patching cadence, that’s a strong signal that managed database services should be part of the conversation.
Step 3: Lock Default and Unused Accounts
Every Oracle installation creates accounts for sample schemas, optional features, and system-level functions. Many of these accounts are never used in production, but unless they’re explicitly locked and expired, they remain potential entry points.
The principle is straightforward: if an account isn’t actively needed, it shouldn’t be active. Lock it, expire it, and document the decision. This applies to sample schema accounts (SCOTT, HR, OE, SH), accounts for features you haven’t deployed, and any user accounts belonging to former employees or contractors.
Dormant accounts are particularly dangerous because they’re rarely monitored. An attacker who gains access through an unused account may go undetected far longer than one who compromises an active user, precisely because nobody is watching that account’s activity.
Step 4: Implement Least Privilege and Actually Enforce It
The principle of least privilege says that every user should have only the minimum database permissions necessary to perform their job. In practice, this is one of the most frequently violated principles in Oracle environments.
The most common violation: granting the DBA role to application service accounts or developers who need elevated access for one task. Once granted, that level of access rarely gets revoked. Over time, privilege creep accumulates, and the database ends up with multiple accounts holding far more access than they need.
The fix is two-part. First, audit existing privileges and revoke anything that exceeds what each user or application actually requires. Second, establish a review cycle. Privileges should be re-evaluated quarterly, at minimum, and whenever a user changes roles or leaves the organization.
Internal threats remain among the hardest to detect, and excessive privileges make them worse. A user with DBA-level access who decides to exfiltrate data, whether intentionally or through a compromised account, has far fewer guardrails in their way than a user with appropriately scoped permissions.
Step 5: Enable Transparent Data Encryption (TDE)
Transparent Data Encryption protects data at rest by encrypting datafiles, tablespaces, and backups at the storage level. The encryption is transparent to applications, meaning queries and transactions work normally while the underlying data is protected on disk.
Why does this matter if you already have strong access controls? Because defense in depth assumes that any single layer of security can fail. If an attacker gains access to the operating system or steals backup media, TDE ensures the data they find is encrypted and unreadable without the encryption keys. Without TDE, stolen datafiles and backups are readable in cleartext.
IBM’s 2025 report found that breaches involving data stored across multiple environments (public cloud, private cloud, on-premises) averaged $5.05 million in cost and 276 days to contain. For organizations running Oracle databases in hybrid environments, TDE is not optional. It’s the layer that protects you when everything else has already failed.
Step 6: Secure Network Connections with TLS
Encrypting data at rest (Step 5) protects the storage layer. Encrypting data in transit protects the network layer. Both are necessary.
Oracle Net Services can be configured to use Transport Layer Security (TLS) for all connections between clients, application servers, and databases. Without TLS, database credentials and query results travel across the network in cleartext, which makes them vulnerable to interception through network sniffing, man-in-the-middle attacks, or compromised network equipment.
This is particularly important in cloud and hybrid environments where network paths cross shared infrastructure. Configuring TLS for Oracle database connections closes a vector that attackers routinely use for lateral movement once they’ve gained initial access to a network.
Step 7: Enable Unified Auditing
You can’t detect what you’re not monitoring. Unified auditing in Oracle Database consolidates audit records from multiple sources into a single, queryable audit trail, covering privileged user actions, schema changes, data access, failed login attempts, and policy violations.
The value of centralized auditing goes beyond individual event detection. When audit data is aggregated and reviewed over time, patterns emerge that individual session-level monitoring would miss: a privileged account accessing data outside normal hours, a series of failed login attempts followed by a successful one from a different IP, or a gradual escalation of privileges across multiple accounts.
For organizations subject to regulatory compliance (CIS benchmarks, STIG, PCI DSS, HIPAA), unified auditing provides the evidence trail that auditors require. Oracle Enterprise Manager’s Database Lifecycle Management compliance functionality can run automated, continuous security checks against these industry standards, flagging configuration drift and compliance violations before they become audit findings.
The worst time to discover you don’t have adequate audit data is during a breach investigation. If your Oracle databases don’t have unified auditing enabled, the question isn’t whether to enable it. It’s how soon you can get it turned on.
Step 8: Remove Unnecessary Components
Every installed database feature, option, sample schema, and optional component represents potential attack surface. If it’s installed but not used, it’s code that could contain vulnerabilities, code that needs to be patched, and code that an attacker could potentially exploit.
Oracle’s own security documentation recommends removing or disabling unused database options and features during or after installation. This includes sample schemas (which contain well-known table structures and data), optional components that aren’t required for your specific workloads, and any features that were enabled for testing but never used in production.
The goal isn’t to run a stripped-down database for its own sake. The goal is to reduce the number of things that could go wrong and the number of things that need to be patched, monitored, and secured. Less surface area means less risk.
These 8 Steps Are a Starting Point, Not a Finish Line
The steps above represent the security baseline for any Oracle database. They are necessary. They are not sufficient.
Database security is a continuous practice, not a one-time project. Configurations drift. New vulnerabilities are disclosed. Users accumulate privileges. Patching cycles get delayed. Without ongoing monitoring and enforcement, a hardened database gradually softens until the next assessment reveals gaps that should have been caught months ago.
Oracle provides tools for continuous security management. Oracle Enterprise Manager’s DBLM capabilities automate configuration drift monitoring against reference baselines. Compliance management functionality runs ongoing checks against CIS, STIG, PCI DSS, and HIPAA standards. And Oracle Database 26ai introduces additional security capabilities, including SQL Firewall for in-database protection against SQL injection attacks and quantum-resistant encryption algorithms for organizations planning ahead for post-quantum threats.
But tools alone don’t solve the problem. Somebody needs to be watching, tuning, and responding. For organizations where the DBA team is stretched thin across operational demands, patching cycles, and modernization projects, the security baseline inevitably becomes the thing that slips. This is where managed database services provide measurable value: security hardening, patching, auditing, and compliance monitoring handled as an ongoing operational practice rather than an annual checkbox.
IT Convergence’s managed database services team handles exactly this. We maintain patching cadence, audit configurations, enforce hardening standards, and monitor for drift across Oracle databases running on-premises, on OCI, and in multicloud environments. For organizations running Oracle E-Business Suite, JD Edwards, PeopleSoft, or Fusion Cloud, ITC’s managed services integrate database security into the broader application and infrastructure management practice. Security isn’t a separate workstream. It’s embedded in how we operate your Oracle environment every day.
Your Database is Either Hardened or It’s Waiting to Be Tested
The eight steps in this checklist are not new. DBAs have known about default passwords, patching, least privilege, and encryption for years. What has changed is the threat environment. Attackers are faster, more organized, and increasingly targeting enterprise database systems specifically. The Cl0p campaign wasn’t a theoretical exercise. It was a real-world demonstration of what happens when the fundamentals are deferred.
If your Oracle databases are fully patched, encrypted, audited, and locked down to least-privilege access, you’re ahead of most organizations. If they’re not, the gap between your current state and the baseline described above is your window of exposure.
IT Convergence can help you close that gap and keep it closed. Whether you need a one-time security assessment, a migration from legacy EBS to a hardened cloud environment, or ongoing managed database services that keep security baked into daily operations, ITC’s Oracle-certified team is ready.
Frequently Asked Questions (FAQs)
- How often should Oracle databases be patched?
At minimum, quarterly, in alignment with Oracle’s Critical Patch Update schedule (January, April, July, October). When Oracle issues out-of-band security alerts for critical vulnerabilities, patches should be applied within days, not weeks. The Cl0p campaign and the Oracle Cloud Classic breach both demonstrate what happens when patching cadence slips. - Is Transparent Data Encryption (TDE) necessary if we already have strong access controls?
Yes. TDE operates as a defense-in-depth measure. Access controls protect against unauthorized login. TDE protects against scenarios where those controls have already been bypassed, such as theft of backup media, compromise of the operating system, or direct access to storage. Both layers are necessary; neither is sufficient on its own. - What compliance standards can Oracle Enterprise Manager check against?
Oracle Enterprise Manager’s DBLM compliance management supports automated checks against CIS benchmarks, STIG (Security Technical Implementation Guide), PCI DSS, and HIPAA standards. These checks run continuously, flagging configuration deviations and compliance violations against established baselines. - How do we know if default passwords are still in use across our Oracle environment?
Oracle provides SQL scripts that can identify user accounts still using default passwords. The checkpwd utility can scan password hashes against dictionary files to flag weak passwords. If you haven’t run either of these checks recently, or if you’re not sure whether they’ve been run across every database instance in your environment, a security assessment should be the first step. - What’s the difference between a one-time security hardening project and managed database security?
A hardening project addresses the current state and creates a baseline. Managed database security maintains that baseline over time through ongoing patching, audit monitoring, privilege reviews, compliance checks, and configuration drift detection. Without the managed component, security posture degrades between assessments.
