This is Part 2 in our series on how to secure your data. In Part 1, we established the theoretical foundation and the necessity of balancing and prioritizing detection over prevention. In this installment, we move into practical implementation, starting with database session control.

Session control is generally easier, but you have to learn to walk before you can run. Getting basic session visibility right is fundamental before securing more complex activity patterns inside those sessions.

Session control is relatively simple, accessible, and easily understood, but limited in what it can address. Yet, despite its simplicity, most organizations fail to execute it properly. They dump millions of connection logs into reports or a SIEM, never look at them, and assume they do “session security”. That is a report graveyard, not actionable security.

We start here for three reasons:

1. It has security value: While this value is limited, session control can detect certain attacks. Most notably, credential theft and abuse of the application account. In those cases, the activity source tends to change, giving you an early warning before any data is modified or stolen.
2. It is the first step in visibility: Session control gives you the most basic understanding of who touches your database, from where, and using what tools. Most organizations cannot answer these basic questions, and without these answers, you cannot plan your security controls or segment them effectively.
3. It is the ideal testing ground for methodologies: Applying concepts like daily reports, declarative alerts, anomaly detection, proactive forensics, and blocking is far easier to implement on simple connection events (logins, IPs, program names) before attempting to apply them to billions of SQL queries.

Session control isn’t the ultimate solution – it’s Step 1. After that come Steps 2, 3, and 4. But you should not skip to the end.

What Session Control Misses

Let’s be completely transparent about what session control can and cannot do. In many cases, session control will not be your hero:

• It doesn’t detect most attacks: From privilege abuse or C2 activity to complex application attacks – if the attacker is a real user or impersonates them well enough, session control will not detect them.
• Unverified client-supplied metadata: When a connection opens, the client sends information like the program name, client OS user, and terminal. The database server cannot verify any of this. A sophisticated attacker can spoof this information.
• Unreliable information: The username is reliable because the database server authenticated it, and the IP address carries reasonable weight since spoofing it is more complex. However, client-reported metadata, such as program name and OS user, is entirely client-side text that can be manipulated.

When we move beyond session control, we will discuss how to detect more sophisticated attacks without relying on client-supplied data. However, catching common, simpler attacks at the session layer is a great easy win.

Exploring the Methodologies

To make session control useful, we need a way to convert raw connection data into actionable security intelligence. We do this using six distinct mechanisms: Reactive Forensics, Proactive Forensics, Reports, Alerts, Anomalies, and Blocking.

Reactive Forensics: The Post-Mortem

Reactive forensics is what happens after a security event occurs and you need to investigate. That is the traditional meaning of forensics: an alert was fired, you were notified of a breach, or an auditor asked a simple question like “Who was logged into the database on Tuesday at 03:00 AM?” It is an indispensable investigative tool for piecing together an incident timeline.

When considering a post-mortem investigation, the primary concern is: “Will we have the necessary data when the time comes?” With session data, it is entirely possible to retain all the sessions so nothing is missing. It is also good practice to conduct routine investigations to ensure the data is available and that your team knows how to query it.

However, if reactive forensics is your only operational use of session data, you are operating entirely in a reactive breach-response posture.

Proactive Forensics: Gaining Visibility

While both forms of forensics use historical session logs, their objectives are entirely opposite: Looking Back vs. Hunting Forward. Proactive forensics is an exploratory tool used as part of regular security operations. It answers foundational operational questions like:

• Who connects to this database on a normal business day?
• What client applications are originating these connections?
• Are there unexpected local connections running internally from the database server?
• Do multiple human operators share a single privileged account?

You cannot write an alert for abnormal behavior if you do not know what normal looks like. Proactive forensics provides the basic visibility required to map out the “players” in your system. It is the first tool you use to understand the environment and plan your security controls. Without this visibility, your security controls are like shooting in the dark – unlikely to hit an intruder.

Proactive forensics also exposes poor security practices. It quickly surfaces dangerous habits, such as DBAs connecting via unapproved third-party utilities, accounts connecting from multiple machines, or old service accounts logging in from outdated subnets.

When performed regularly, proactive forensics ensures you are always aware of what’s happening in your database and whether new behaviors merit updating your security controls.

Effective Reporting

Most database security reporting fails because it attempts to be exhaustive rather than informative.

If your session reporting strategy consists of emailing a 50,000-line PDF containing every connection event from the past 24 hours to a SOC analyst’s inbox, you don’t have reporting – you have inbox spam. That report will be ignored, auto-archived, or deleted immediately. It serves no security purpose – just a waste of resources.

An effective session report delivers a 30-second daily glance so a human operator can spot a problem or detect a macro-level shift that requires action. For example:

• Distinct Client Programs: A summarized list of all unique users and program names seen in the last 24 hours. If MSACCESS.EXE suddenly appears on the summary list, it takes 2 seconds to spot the anomaly.
• Privileged Accounts: A consolidated summary of where DBA accounts logged in from yesterday (DBA user, program, source IP, login count). It will be immediately obvious if a DBA connects from a suspicious subnet, uses an unusual program, or logs in an unreasonable number of times.
• Application Account: A report of the programs and IPs using the application account. If an application account was used by a different program or an additional IP address, that extra line in the report sticks out immediately.

Reports cannot catch attacks in real time – that is the job of alerts. Reports exist to ensure you are aware of what happens in your databases, maintain basic environmental hygiene, and ensure your operational baseline hasn’t quietly drifted over time.

Declarative Alerts

While reports tell you what happened yesterday, alerts exist to tell you what is happening right now. The primary goal of declarative alerts is immediate awareness, allowing your team to respond before exfiltration or damage escalates.

Alerts operate on a mindset of reporting exclusively on things that should not happen. Unlike daily reports, alerts only consume analyst time when triggered. This means you can maintain significantly more alerts than reports.

To build effective declarative alerts, you must explicitly define what “bad” looks like. This can be a blacklist defining known bad behaviors, or a whitelist defining approved good behaviors – making everything else “bad”. In the context of session control, you create hard rules based on connection metadata combinations:

• Privileged Users: Alert if a DBA account connects via anything other than SQL*Plus or Management Studio, or if a privileged account logs in from a workstation outside the administrator subnet.
• Application Accounts: Alert if an application account initiates a session from an IP address that isn’t a designated application server, or originates from an unapproved program.
• Network Anomalies: Alert on direct database connections originating from unexpected subnets, like VPN pools, external networks, or internal subnets that should never reach the database interface directly.

Unlike daily reports, declarative alerts scale exceptionally well because they remain silent until triggered. You can define 50 distinct declarative rules across your environment. As long as they are tightly scoped to clear policy violations, they will rarely fire – meaning when one does trigger, it demands immediate investigation.

Anomaly Analysis

Declarative alerts require you to know the exact conditions you want to enforce. But what about changes you cannot predict or that are too complex to hardcode? For example, triggering an alert when a user connects from a new IP would require creating a manual rule for every user and their current IP – an impractical approach.

This is where anomaly detection comes in. Instead of defining a static rule (“Alert if user X connects from an IP that isn’t Y”), anomaly engines track changes in activity profiles over time (e.g., “Alert when a user connects from an IP they haven’t used in the past 3 months”). This can extend across multiple dimensions, filters, and comparison parameters (“Alert when user X uses an unfamiliar combination of programs and IPs at an unusual time of day”).

Comparing the Two Approaches:

	Declarative Alert	Anomaly Detection
Rule Type	Explicit, static rules	Dynamic, behavioral
Rule Example	If program is SQLPLUS.EXE	If DB user uses a NEW program
Violation Type	Fires when a policy is violated	Fires when a behavior changes
False Positives	Predictable, simpler to tune	Potential noise, harder to tune
Attack Coverage	Harder to catch a real attack	Easier to target unknown attacks

How Anomalies Enhance Security

Beyond behavioral flexibility, anomaly detection offers two key advantages:

• Massive Scale: The automated anomaly engine processes activity volumes that no human analyst could manually audit.
• Subtle Changes: It highlights minute differences that human eyes easily miss.

For example:

• A DBA who logged in from the same three IPs for six months connects in from a fourth, previously unseen IP address.
• An application account used by different programs from various servers receives a connection from a valid server but with the wrong app for that server.
• In a database with 2,000 users on 2,000 workstations, one workstation is suddenly used by two different accounts, or a single account connects from multiple endpoints.

The Pitfall of Anomaly Detection

Anomalies are a powerful tool, but they have one glaring flaw: machines do not apply human judgment.

If a DBA legitimately changes their workstation IP and connects from it every day, an anomaly engine will alert on day one, but eventually accept the new behavior as the “new normal”. If that new IP happens to be a compromised endpoint belonging to an administrative assistant, the anomaly engine will ignore it once the new behavior is part of the baseline.

This is why anomaly detection cannot exist in a vacuum. It must be paired with proactive forensics and reporting so human operators regularly validate whether behavioral shifts are legitimate.

Blocking

Activity blocking is the natural escalation of alerting: instead of sending an alert when a policy is violated, the solution can block the session in real time.

In session control, blocking relies on strict blacklisting or whitelisting of specific connection paths. For example, blocking connections based on subnets, database users, client programs, or a combination of all three.

The Practical Reality of Blocking

While inline blocking offers live protection against unauthorized access, it also carries a risk of self-inflicted downtime.

In a production environment, a false positive on a blocking rule doesn’t just generate a ticket – it takes down applications, halts business processes, and triggers emergency helpdesk calls. If a network engineer reconfigures an application server cluster to use a new IP range without updating your blocking engine, your security control just caused a self-inflicted outage.

For session control, inline blocking should be applied conservatively:

1. Strict Whitelisting for Service Accounts: Mandate that core application service accounts can only connect from explicitly defined application servers and programs, blocking everything else.
2. Whitelisting Approved Client Tools: Restrict access to approved programs. For example, DBAs may use SQL*Plus or Toad while everyone else may only use the application client (e.g., Java client or .NET SQL Client). Direct database logins from legacy or dangerous tools like MSACCESS.EXE are immediately blocked.
3. Alert-First Validation: Run new blocking rules in “log-only” mode for weeks so you can observe traffic and assess the false-positive risk, before turning on active enforcement.

Session control provides basic surface-area protection. It stops obvious bad actors at the door and catches crude credential theft. But session control cannot stop an attacker who looks like a legitimate user. For that, you must move beyond the session facade and control the actual SQL activity – which we will cover in Parts 3 and 4.

From Theory to Practice: The Implementation Reality

Armed with an understanding of the theoretical mechanisms at the core of activity control, we are faced with implementing this theory in reality. While session control is easier than SQL control, it still faces the same two fundamental challenges:

• Data Capture: Collecting information about all the sessions can be challenging. Direct connections can come from many sources, both remote and local. Many sessions are encrypted with TLS, and some packet-based technologies find those difficult to monitor. With modern design patterns like “connection per request” or “connection per transaction”, the sheer number of sessions can also hit tens of millions a day. Collecting all this information without impacting database performance and without missing anything can be challenging.
• Data Processing: Converting all this raw data into meaningful and actionable information requires an application of all the above methodologies at scale. While some solutions fare reasonably well in some aspects, it is pretty rare to do everything.

To understand how these six mechanisms operate in a real production environment, let’s look at the architectural requirements necessary to run them at scale – using our platform, Core Audit, as an example.

Full Data Capture & Performance Impact

The capture capabilities of Core Audit are unique because it collects data directly from the database engine. Other solutions often rely on native database auditing (which creates performance problems) or packet capture (which creates visibility problems). Consider these limitations:

• Encrypted Connections: Packet capture technologies often fail to inspect encrypted session handshakes. Core Audit captures context directly from the database engine, remaining completely impervious to TLS encryption.
• Local Server Connections: Local connection paths (e.g., shared memory, domain sockets, or loopback connections) bypass standard network interfaces and are notoriously missed by network monitoring tools.
• Performance Impact: Solutions that rely on native database auditing severely degrade performance, and local packet capture techniques ship massive network traffic off-host. Core Audit avoids both pitfalls, operating with negligible performance impact (less than 3% overhead) and requiring minuscule network bandwidth.

Turning Raw Data into Actionable Information

We extensively discussed the main challenge in session control: converting the raw data into effective operational controls. Let’s review these mechanisms and what they may look like in a poor implementation vs. a proper implementation (like Core Audit):

Mechanism	Poor Implementation	Modern Solution (Core Audit Design)
Reactive Forensics (retain evidence)	On-server repository, Significant storage space, or Partial recording (not all the sessions).	Records every session into an off-server immutable, efficient, and historical repository. So you know, for example, who connected 6 weeks ago at 3 am.
Proactive Forensics (gain visibility)	A long list of all the sessions without interactive visualization to help digest the information.	Visualize the active database “players” through interactive list views, trees, sankey diagrams, pie charts, network graphs, and more.
Effective Reports (keep you informed)	Large reports personnel cannot read. Lack of customization. External reporting solutions. A compliance checkbox that doesn’t add security value.	Built-in reporting engine to distill millions of connection events into simple daily, weekly, or monthly summaries. Automatically deliver through file, email, Syslog, or custom actions.
Alerts (Declarative & Anomalies)(real-time notification)	Too many alerts or too few (false negatives). Cannot cover all the attack vectors. Lack of detail about what happened. No tuning options.	Static alerts (e.g., a failed DBA login) alongside Dynamic behavioral anomalies (e.g., a user connecting from a new program or IP). Alerts are an extension of reporting, customizable, and tunable.
Blocking (active prevention)	Introduce latency. Let malicious activity pass and drop the session later. No mechanism to help avoid false positives.	Real-time blocking engine you can test in “Log-only” mode. Lock down connections by the activity source, ensuring both the application and DBAs connect from approved programs and subnets.

Walk Before You Run

Session control is not the pinnacle of database security. It cannot stop most database attacks and does not replace the more advanced SQL activity control.

However, skipping session control because it isn’t “bulletproof” is a fundamental operational mistake. Session control provides the baseline anchors for catching attacks where the activity source changes. They also build up your mental model of the environment you operate in. Finally, they serve as the ultimate sandbox for mastering forensics, reporting, alerting, anomalies, and blocking.

Once you have established firm control over who comes knocking at the front door, you are ready to evaluate what those sessions are actually doing inside the database.

In Part 3, we move beyond the connection to explore SQL activity controls for sensitive data access.