Nearly a decade later, it is still the breach the industry points to. In 2016, 3.2 million debit cards were quietly compromised across several major banks. The systems of the day did not catch it. Customers did, when their cards started being used in China and the US while they sat at home in India. The breach had gone undetected for months.
The databases a organization guards most closely are the ones it watches least. The core banking ledger, the claims system, the account master. Too sensitive for a managed cloud service, so they stay on Oracle, on hardware the company owns. The data stayed under control. Monitoring it was the part that slipped.
The privileged user blind spot in self-hosted Oracle
A self-hosted Oracle instance is run by a handful of DBAs who can read any table, run any query, export whatever a job needs. That access is the job.
The problem that is they are also the only ones who can see what happens to the data. If a DBA account is misused, or a credential leaks, the activity looks exactly like work. A query is a query. An export is an export. Stolen access and legitimate access generate the same log entry.
Oracle ships with its own auditing capabilities, but most teams already know its limits. Turn it up on a busy production system and it costs affect performance and generating more logs than anyone has time to review. So it runs light on the systems that matter most. Even at full volume, native auditing gives you a record, not a warning. It tells you what happened after someone asks. It does not tell you something is wrong while it is happening.
That is the difference between a log and a monitor. And it is the gap that remained open on self-hosted Oracle long after it closed in the cloud.
How Matters DAM covers self-hosted Oracle
Matters Database Activity Monitoring now supports Oracle in self-hosted and on-premise environments, not just databases running in the cloud. The rest of this article explains how it works.
How Matters collects Oracle activity
Matters collects query and activity data from Oracle using its native audit logging mechanisms, capturing database activity without routing production traffic through a separate monitoring layer.
Deployment follows the on-premise model, a lightweight component inside your environment rather than relying on an API connected to a cloud.
What Matters monitors on your Oracle database
Collection is not limited to queries. Matters captures the full range of database activity a security team needs to reconstruct what happened:
Query operations broken down by type, so schema changes (DDL), data changes (DML), and read operations (DQL) are separated rather than lumped together. A spike in one is a different signal from a spike in another.
Privileged and administrative activity, which is where the highest-impact access reside.
Grants and revokes, so privileges that appear where it should not is detected as it is granted, not discovered later.
Logins and failed login attempts, which surface credential stuffing and the slow brute-force attacks that native logs usually bury.
Bulk reads and direct exports, the pattern behind most quiet data theft.
Access to specific sensitive tables and columns, which is where the next piece comes in.
Fewer false positives through data context
Most DAM deployments fail for one reason. Legacy tools are rule-based, they fire based on volume, and every alert looks as important as every other. SOC teams drown in alerts, stop investigating, and the tool becomes an audit checkbox instead of a control.
Matters correlates database activity with data classification from DSI (DSPM), so the system knows which tables and columns hold regulated data before deciding whether an event matters. A SELECT against a non-sensitive reference table is logged and left alone. Access to columns containing card numbers or customer identifiers, outside the normal application path, is escalated. Severity is driven by data impact, not by how many rules a query happened to trip.
That is the difference between an alert queue nobody reads and a short list of things worth waking someone for.
Real-time detection on Oracle activity
Matters ships with detection policies tuned for Oracle that run against the live activity stream, so a risky event surfaces as an alert the moment it happens rather than during a review weeks later.
On top of the built-in policies, behavioral baselining learns what normal looks like for each account. It profiles the tables a user typically accesses, the volume they usually retrives, and the hours they usually work, then flags the deviation. This is the case rule-based systems miss: a credential that is completely legitimate, running queries it is fully authorized to run, yet behaving nothing like the person it belongs to. A DBA account that suddenly reads ten times its usual volume, or reaches into tables it has never accessed before, breaks its own baseline. That is the signal.
It also makes the risky-user ranking meaningful. Users are scored on how far they drift from their own normal, so the account at the top of the list is the one worth a look, not the one that ran the most queries that day.
One view across on-prem and cloud databases
Oracle now sits in the same monitoring view as your PostgreSQL, MySQL, Redshift, and RDS databases. One alerting model, one investigation flow, one place to ask who accessed what. When an auditor or an incident forces the question, the answer comes from a single console instead of a DBA reconstructing it from raw logs spread across separate systems over two days.
The dashboard ranks databases by risk based on sensitive data access and unresolved alerts, highlights the sensitive columns being accessed most, shows which users are triggering the most policy violations, and tracks which of your databases are monitored versus still dark. It also measures how fast alerts are raised after risky activity and how fast they are resolved, so the program is something you can manage rather than hope about.
From alert to response
Detection without a next step is just a nicer log. Matters maps alerts to response workflows so the SOC knows what to do with each one, and every action is captured with the actor, the affected data, and the timestamp. When something warrants stopping, containment is one step and stays in human hands. A person makes the call. Nothing auto blocks on its own, which is what keeps a false positive from taking down a production system at the worst possible moment.
Oracle DAM for RBI, SEBI, and PCI DSS compliance
For a regulated bank, the compliance requirement is not complicated to state. Show who accessed the sensitive data, and prove you would catch misuse. Continuous monitoring answers both in a way a quarterly log export never could. The access trail is always current, the evidence is generated as activity happens, and it is retrievable on demand rather than rebuilt under deadline. DAM stops being the thing you keep for the audit and starts being the thing that would catch the incident the audit is worried about.
Self-hosted Oracle, finally watched
The 2016 breach ran for months because no one inside was watching the data leave. For many banks, the system that fits that description is a self-hosted Oracle database in their own datacenter, holding the data they protect most and see into least. It can now be watched, in real time, like every other database they run.
See how Matters monitors self-hosted Oracle. Book a demo.
