Database Activity Monitoring (DAM) or its modern variation, Database Activity Control (DAC), aims to enhance database security and achieve regulatory compliance. Since most database users have access to sensitive information, controlling the activity from those accounts is a primary mechanism for mitigating external and internal threats.
This review covers all the high-end solutions currently on the market. High-end solutions tend to be more expensive and include higher-quality capture, storage, and other advanced features (more below). However, there are substantial differences even within the high-end market, and no two solutions are the same.
When contemplating activity control, data quality is the most essential aspect. A solution cannot report, alert, analyse, display, or block activity it hasn’t seen or stored. Coverage is fundamental to combating threats since you cannot secure what you cannot see.
As a derivative, it is also essential to determine the type of databases we aim to secure. Securing on-prem and IaaS clouds is vastly different from DBaaS clouds. In this review, we examine on-prem and IaaS security, and more on that below.
Overall Rating
We’ll start with the final rating, and expand below with a breakdown of the data quality scores and a brief review of each solution. In this table, all the columns have equal weights. However, due to its significance, you may choose to pay special attention to Data Quality (more on that below).
| Data Quality | Reports & Alerts | Anomaly | Forensic | Blocking | Overall Score | |
|---|---|---|---|---|---|---|
| Blue Core Research Core Audit | 9 complete | 7 decent | 9 powerful | 9 complete | 8 declarative | 8.4 |
| Imperva DAM (part of DSF) | 6 profile only | 9 complete | 7 some limits | 4 very limited | 5 timing | 6.2 |
| IBM Guardium | 4 profiling | 8 decent | 1 minimal | 4 very limited | 5 timing | 4.4 |
| Oracle Database Firewall | 4 storage | 8 decent | 7 some limits | 4 very limited | 2 coverage | 5.0 |
| Trellix Database Security | 2 polling | 6 acceptable | 0 | 4 very limited | 4 coverage | 3.2 |
| WareValley Chakra Max | 3 profiling | 9 decent | 0 | 4 very limited | 2 coverage | 3.6 |
| Varonis Next-Gen DAM | 6 app proxy | 8 decent | 9 powerful | 8 decent | 2 coverage | 6.6 |
| Satori DAM | 3 proxy, prof | 6 acceptable | 0 | 3 very limited | 1 coverage | 2.6 |
| DataSunrise DAM and DB Firewall | 2 no storage | 2 external | 0 | 2 external | 2 coverage | 1.6 |
General scoring explanations:
Data Quality scores the coverage and retention of data that enables the rest of the features in the solution. It is broken down below into Capture, Traditional Storage, and Behavioral Storage.
Reports & Alerts scores the quality of reports and alerts. Most solutions do fairly well in this category.
Anomaly scores a solution’s ability to identify malicious activity without declarative rules or thresholds. Applications are the primary source of activity in the database and a principal security risk, and this type of automation is vital to securing application activity and beyond.
Forensic scores your ability to find out what happened using the solution. A partial score is given when you can only examine activities you instructed the solution to record. A full score is given when the solution gives you visibility into everything that happened.Blocking is the ability of the solution to stop individual SQL statements or kill the session in response to malicious activity. The score is affected by performance and coverage. The score is lower if using blocking slows down the database or if it allows malicious activity to execute. The score is also lower if potential attack vectors (like local, encrypted, and internal activity) can bypass the blocking. However, it is important to note that using blocking is dangerous on a production database, as it may interfere with legitimate activity (false positives). You should carefully consider if this feature is important to you and how well a vendor can assist you in reducing those false positives.
Blocking is the ability of the solution to stop individual SQL statements or kill the session in response to malicious activity. The score is affected by performance and coverage. The score is lower if using blocking slows down the database or if it allows malicious activity to execute. The score is also lower if potential attack vectors (like local, encrypted, and internal activity) can bypass the blocking. However, it is important to note that using blocking is dangerous on a production database, as it may interfere with legitimate activity (false positives). You should carefully consider if this feature is important to you and how well a vendor can assist you in reducing those false positives.
Security Goals and Scoring
The guideline for this review is the best security for on-prem databases or databases installed in IaaS clouds. Those are the “traditional” types of databases that store and manage all the critical data organizations retain in-house. There are many opposing views on whether the world is or should move to the cloud, but those are outside the scope of this article. We seek to find the best technical solution to secure the data you have on-prem.
The unique security challenge for on-prem and IaaS cloud databases is the significant risk from local access. Local access is available to DBAs and is also a major attack vector exploited in all double extortion ransomware attacks. In some environments, local access is also a primary source of activity.
A direct implication for securing local access is that you need an agent on the database server to see it. This review also includes solutions that don’t have such agents (or rarely deploy them) because while they support on-prem, they are more geared towards DBaaS clouds. As a result, these solutions got lower scores and would have fared better in a DBaaS review.
Another important consideration is compliance or security. Some solutions are mostly focused on reporting, while others aim to provide comprehensive security that includes the application. As the primary source of database activity and a significant attack vector, applications should not be ignored. Securing the billions of SQLs from applications requires anomalies or some form of automation, and solutions that lack those scored poorly overall.
The Technology Landspace
Let’s step back and examine the components in this review. Every solution is comprised of three core components:
- Capture (and, eventually, Blocking)
- Processing & Storage
- Reporting, Alerting, Anomalies, and Forensics
This path is critical to understand because data that isn’t captured never gets processed or stored, and cannot be used in reports, alerts, anomaly analysis, or forensics. Data that isn’t stored cannot be used either.
In other words, the most critical component is Capture since it drives the entire solution. Storage is the second most important component, and the final features all rely on those underlying layers. While many features are significant, they can only deliver available information.
While the scoring calculation uses equal weights for all the columns, you may want to pay special attention to the capture score and the data quality.
High-end Solutions
The Database Activity Control market is divided into two product classes:
- High-end solutions are more expensive and offer better security. One of the tell-tale signs is a proprietary capture technology that can access vast amounts of SQL activity. Such technology is essential for enabling anomaly analysis, more comprehensive activity records, and blocking features.
- Low-end solutions are significantly less expensive and more suitable for certain types of compliance reporting. For example, Idera, ApexSQL, and Netwrix. These types of solutions never include expensive capture tech and rely on native auditing. Due to the performance impact of capturing SQLs, they are limited by the activity they can inspect and, generally, offer a storage and reporting mechanism on top of the database functionality. They cannot offer blocking or anomaly detection, and their target is a type of compliance where the goal is to report based on minimal available audit data.
High-end and low-end solutions target different audiences and have a massive difference in price and capabilities. We, therefore, segmented these into two different markets that deserve independent reviews and should not be compared to one another. This review focuses on the high-end market.
Data Quality
Since data quality is paramount, we provide a better breakdown of the scoring for each product. These 3 columns are an extension of the triple value Data Quality in the top rating matrix. These are the high-level technology capabilities of each vendor, and below are detailed explanations of the scoring per solution.
| Capture | Traditional Storage | Behavioral Storage | Overall Data Score | |
|---|---|---|---|---|
| Blue Core Research Core Audit | 9 SQL Engine Capture | 9 footprint, perf | 9 always available | 9 |
| Imperva DAM (part of DSF) | 7 Packet Capture | 7 DB storage | 5 live profiling | 6 |
| IBM Guardium | 7 Packet Capture | 6 DB Storage | 0 | 4 |
| Oracle Database Firewall | 4 Packet Capture | 4 DB Storage | 4 live profiling | 4 |
| Trellix Database Security | 3 memory capture | 3 DB storage | 0 | 2 |
| WareValley Chakra Max | 4 mostly proxy | 5 DB Storage | 0 | 3 |
| Varonis Next-Gen DAM | 3 app proxy | 6 cloud, retention | 9 automatic profiling | 6 |
| Satori DAM | 3 proxy only | 5 cloud storage | 0 | 3 |
| DataSunrise DAM and DB Firewall | 4 mostly proxy | 1 external storage | 1 SQL Whitelist | 2 |
General scoring explanations:
Capture refers to a solution’s ability to inspect activity. An activity that isn’t captured is a security hole that allows an attacker to bypass the solution. Gaining access to the activity is the most critical and challenging aspect of database activity control.
There are, generally, 4 categories of technologies (more explanations per product):
- SQL Engine Capture can see all the activity. That includes remote, local, encrypted, and internal database activity (such as stored procedures and triggers).
- Packet capture can mostly see remote network activity, but with an agent, it may also see local activity. It can sometimes inspect encrypted activity, but that depends. This technology cannot see internal database activity.
- Memory capture has the potential to see any database activity, but that activity must be long enough to capture. The reason is the polling loop scanning the database memory. Short SQLs that occur between two memory samples are missed. The lack of short SQL capture is crippling and the reason for the low score.
- Proxy capture can only see activity that was routed through the proxy. They cannot see local or internal database activity. Without a complex network configuration, even remote connections can bypass them.
Traditional Storage refers to the standard repository that records SQL executions. A high score is for a repository that scales better. That means record more activity, faster, and with less disk space. Such capabilities enable you to record more activity and retain it online for a longer time.
Behavioral Storage refers to an alternate repository that stores aggregate or profile information. That is where a solution can leverage the vast volume of activity it captured and not simply discard everything that wasn’t recorded in the traditional storage. Depending on the data the solution stores, it can detect anomalous behavior and/or deliver more comprehensive forensic capabilities.
We’ll emphasize, again, that information that wasn’t captured or stored cannot bring value. A solution without good traditional storage cannot deliver compliance reports with sufficient granularity. One without behavioral storage cannot provide anomalies and offers more limited forensics.
Solutions
Now, let’s look more closely at each solution to understand the specifics of capture, storage, anomalies, forensic, and blocking.
Blue Core Research
Core Audit from Blue Core Research is an advanced activity control solution that represents a disruptive shift from legacy solutions such as Imperva and IBM Guardium in both data quality and features. The SQL Engine Capture technology sees everything, and the dual repository leverages that data to deliver powerful features. Moving the capture closer to the data enhances security while reducing overhead, making it the premier choice for on-prem databases. However, it is incompatible with DBaaS environments (such as RDS), where OS-level access is not available.
Capture: The capture mechanism relies on SQL Engine Capture. This technology is unique in the field and offers unparalleled visibility. It can see remote, local, encrypted, and internal activities. It uses a high-performance user-space agent that consumes less than 3% overhead. Unlike other solutions where agents are recommended but not required, Core Audit relies on the agent. That is a challenge with DBaaS environments where such agents cannot be installed.
Storage: The storage consists of a dual repository and is based on a file-based storage that scales remarkably well. The primary repository records exact SQLs with millisecond timestamps and is equivalent to the standard repository in most products. However, it is optimized with massive deduplication and high data density, which allows it to record a billion SQLs in 32 GB of disk space. The secondary repository records all the database activity. By stripping literals and using 5-minute aggregates, this repository records everything that executes in the database in a few megabytes per day. This data drives on-demand profiling for anomaly analysis and delivers a 360-degree forensic view.
Anomalies: Activity profiling is performed on demand and can compare any historical time range. Anomalies provide near real-time alerting on any aspect of the activity. It can identify changes in the SQL construct, activity volume, users, programs, time-of-day differences, relationships, and more.
Forensic: Forensic capabilities can leverage either repository and deliver a comprehensive view of everything that happened in the database. The solution comes with both proactive and reactive forensic capabilities, graphical activity analysis, and drill-down inspection.
Blocking: The solution is capable of blocking individual SQL statements without introducing measurable latency or allowing malicious activity to pass through. It is capable of performing blocking on any monitored activity, including external, local, encrypted, and internal activity.
Scoring: For the parameters measured in this review, Blue Core Research did very well. Other parameters you may choose to include in your scoring:
- This is a small, specialized vendor, and not a giant like IBM.
- The solution is poorly suited for DBaaS (which is not in this review). The solution addresses DBaaS through Application Activity Control (AAC) and some recent proxy offerings.
Imperva
Imperva DAM (part of DSF) is a popular solution with a mature but aging capture technology (from the early 2000’s). Its primary strength is in providing compliance reports, but the security value for preventing a breach is somewhat limited. It’s comparable to Guardium, but technically fares much better.
Capture: The capture mechanism relies on packet capture with local agents. Local activity capture requires an agent. They have both a kernel agent (more dangerous) and a newer user-space one for a limited number of platforms. Encrypted activity may be visible depending on the database platform, the agent, and other factors (such as encryption key). Internal database activity is never visible.
Storage: The storage is based on a standard database platform with significant storage requirements (in terabytes).
Anomalies: Activity profiling is performed live, and only the profile information is stored. Querying the profiled data gives little value. Anomaly analysis can only reference the activity profile, but it covers many of the common use cases.
Forensic: Forensic capabilities are limited to the data stored in the traditional repository and are, therefore, rather limited.
Blocking: Blocking is extremely porous, where the underlying problem is that blocking decisions cannot be made locally and must be rendered by the Imperva appliance. This back-and-forth communication creates a built-in delay that has no acceptable solution. Blocking can operate in two modes, each with a different crippling limitation. One mode is not inline or sniffing, and allows malicious activity to execute in the database. In this mode, if the activity is found to be malicious, the session will be killed later. A second mode is inline or synchronous, introducing significant latency. In this mode, the agent waits for the Imperva appliance to render a blocking decision before passing each packet.
Scoring: The scoring for Imperva was harmed by:
- Blind spots in its packet capture technology.
- Lack of behavioral forensics (they have anomalies, but no visibility into what users did).
- Blocking technology offers a choice between two poor alternatives.
IBM Guardium
Guardium Data Protection (GDP) is a popular solution with mature but aging technology (most of the tech is 25 years old). Its primary strength is in providing compliance reports, but the security value for preventing a breach is very limited. It’s comparable to Imperva, though technically not as good. Their main strength is support for many esoteric database platforms, but that is only relevant to users who have those and find them critical.
Capture: The capture mechanism relies on packet capture with local agents. Local activity capture requires an agent. S-TAP is a kernel agent (more popular and more dangerous), and A-TAP is a user-space agent with a limited number of supported platforms. Encrypted activity may be visible depending on the database platform, the agent, and other factors (such as encryption key). Internal database activity is never visible.
Storage: The storage is based on a standard database platform with significant storage requirements (in terabytes). There is no behavioral profile, neither live nor on-demand.
Anomalies: There is no anomaly detection. Guardium only offers traditional threshold alerts.
Forensic: Forensic capabilities are limited to the data stored in the traditional repository and are, therefore, rather limited.
Blocking: Blocking with S-GATE is extremely porous because blocking decisions cannot be made locally and must be rendered by the Guardium appliance. This back-and-forth communication creates a built-in delay that has no acceptable solution. Blocking it can operate in two modes, each with a different crippling limitation. One blocking mode is “Detached” or asynchronous, allowing malicious activity to execute in the database. In this mode, a session will be killed asynchronously (later) if it is found to be malicious. A second blocking mode is “Attached” or synchronous and introduces significant latency. In this mode, the agent waits for the Guardium server to render a blocking decision before passing each packet.
Scoring: The scoring for Guardium was harmed by:
- Blind spots in its packet capture technology.
- No behavioral data at all. No anomalies or forensic information.
- Blocking technology offers a choice between two poor alternatives.
Oracle AVDF
Oracle Audit Vault and Database Firewall (AVDF) is a bundle of a high-end product called Database Firewall (that relies on packet capture) and a low-end product called Oracle Audit Vault (that relies on native auditing). It has poor data quality, and its claim to fame is a 20-year-old Grammar Analysis engine that aims to understand the intent of a query. The bundle aims to compensate for the extreme limitation of each solution, but AVDF has no penetration outside the Oracle world, and even there, it is not a significant player.
Capture: The Database Firewall portion of the bundle uses packet capture. It has a relatively recent host monitor agent, which is critical to capturing local activity. Encrypted activity from Oracle databases can be monitored if you share encryption keys with the database. In proxy mode (required for blocking), this solution is extremely partial and easy to bypass.
The Audit Vault portion of the bundle relies entirely on native auditing. It is a low-end solution with a high price tag. Its only reason for being part of the bundle is to compensate for the Database Firewall’s visibility limitations, as native auditing has visibility into local and internal activity. However, the limited capture capacity of native auditing and the lack of advanced features offered by the Database Firewall make this portion of the bundle weak.
Storage: The storage is based on a standard database platform with significant storage requirements.
Anomalies: Database Firewall incorporates a unique SQL grammar classification engine. By supplying the product with examples of “good” and “bad” SQLs, this engine learns to differentiate between them, and over time, the number of false positives diminishes dramatically. However, there is no measurement of the number of false negatives (undetected “bad” SQLs), as those are likely to increase as the false positives diminish.
Forensic: Forensic capabilities are limited to the data stored in the traditional repository and are, therefore, rather limited.
Blocking: Blocking only works in proxy mode and is limited to SQLs that go through the proxy. It can only see and block network-based activity (no local activity), and activity hasn’t bypassed the proxy.
Scoring: The scoring for Oracle AVDF was harmed by:
- Blind spots in the packet capture technology, and limited platform support (mostly for one database).
- Lack of behavioral forensics (they have anomalies, but no visibility into what users did).
- Blocking technology only works for remote connections and doesn’t cover local activity.
Trellix (formerly McAfee)
Trellix Database Security is based on memory sniffing. This technology is unique in the field and with good reason. The solution offers a highly limited capture technology and no innovations.
Capture: The capture mechanism relies on memory sniffing. Memory sniffing technology is ideal for performance monitoring, where long-running SQL queries are the primary concern. However, scanning the memory in a loop can easily miss short-running SQLs that occur between samples. In security, short-running SQLs can be catastrophic, while long-running ones are rarely a concern. Additionally, in Oracle, DDLs don’t appear in the SGA (the shared memory), and the solution resorts to triggers to capture those. It is one of the few technologies that captures internal database activity and isn’t fazed by encryption. However, it is not suitable for security.
Storage: The storage is using SQL Server, and scales poorly. There is no behavioral profile, neither live nor on-demand.
Anomalies: There is no anomaly detection. The solution only offers traditional filters and threshold alerts.
Forensic: Forensic capabilities are limited to the data stored in the traditional repository and are, therefore, extremely limited.
Blocking: Blocking is achieved by killing the session, but it is done asynchronously. With shorter SQLs, even if captured, the blocking may occur after the SQL finishes executing. The solution also offers virtual patching, which is also limited by its ability to block.
Scoring: The scoring for Trellix was harmed by:
- Significant blind spots in its packet capture technology.
- Repository scalability challenges.
- No behavioral data at all. No anomalies or forensic information.
- Blocking technology can miss activity at random.
WareValley
WareValley Chakra Max is popular in South Korea and a few other parts of Southeast Asia, primarily valued for localized compliance reports (e.g., PIPA in Korea). It is often used as a security gateway to the database (Database Access Control) more than a DAM.
Capture: The capture mechanism relies on packet capture that can operate in three modes: proxy (gateway), sniffer, and local agent (software tap). Encrypted activity may be visible depending on using a proprietary client (Chakra client) and other factors (such as encryption key). Internal database activity is never visible. Local activity is only visible with the local agent, but gateway mode is the most popular, rendering the solution partial.
Storage: The storage is based on the proprietary PetaSQL, which has significant storage requirements. There is no behavioral profile, neither live nor on-demand.
Anomalies: There is no anomaly detection. Chakra Max only offers traditional filters and threshold alerts.
Forensic: Forensic capabilities are limited to the data stored in the traditional repository and are, therefore, rather limited.
Blocking: Blocking usually operates in proxy (gateway mode). However, proxy mode cannot see or block local activity or activity that bypasses the proxy. The limited coverage renders blocking extremely weak and inappropriate for the primary usage of this product (Database Access Control).
Scoring: The scoring for WareValley was harmed by:
- Blind spots in its packet capture technology, especially since it’s mostly used as a proxy.
- No behavioral data at all. No anomalies or forensic information.
- Blocking coverage that cannot block local activity or one that bypasses the proxy.
Varonis
Varonis database activity control operates primarily as an application proxy. That is its strength and weakness. It is designed primarily to audit SQL activity in cloud applications and isn’t suited for on-prem environments.
Capture: The capture mechanism relies on distributed collectors that operate as sidecars or proxies. As a distributed proxy that operates inside or near the application server, its strength is in providing a distributed, high-performance monitoring of application database access. However, its weakness is its lack of visibility into local or internal database activity. Since it is an application proxy, it requires a complex network configuration to prevent bypassing it. All these render the capture extremely limited and mostly “auditing by choice”.
Storage: The solution operates as SaaS, meaning storage is provided by a Varonis-managed cloud. For better or worse, many of the retention parameters are automatically handled by the solution. Everything aims to be “automatic”, both for exact SQL activity recording and for profiled behavior.
Anomalies: The solution collects various activity profiles, evaluates them, and finds anomalies. There is no exact list of anomalies it can detect or details about the behavioral data it collects. While the details are vague, the solution appears to align with primary customer concerns.
Forensic: Similar to anomalies, the exact information that can be accessed is a little vague, as it’s mostly queried through an AI via natural language.
Blocking: Similar to everything in the solution, these are mostly automatic decisions by the solution. They extrapolate blocking rules from the behavioral data and implement those inside their proxies.
Scoring: One of the few solutions with solid anomalies and forensic. You may like or dislike the automatic nature of things and the lack of manual controls, but we did not include that in the scoring. The scoring for Varonis was harmed by its proxy-only technology:
- Blind spots in its proxy technology (essentially, auditing by choice).
- Blind spots in its blocking (only for connections routed through the proxy).
Satori
Satori Data Security Platform proxy capture solution. While it offers activity monitoring, its primary focus is on blocking based on permission requests and approvals. Additionally, while it supports on-prem monitoring, it is mostly geared towards the cloud. Having the cloud as a primary target aligns with its proxy nature, as proxy-only security is poorly suited for on-prem.
Capture: The capture mechanism relies on a proxy. A DNS or other redirect sends database traffic to the proxy, which, in turn, sends it to the database. Local and internal database activity is never visible, and the solution requires a complex network configuration to prevent remote activity from bypassing it.
Storage: The solution is primarily designed to run in the cloud (with storage from AWS, Azure, or Google). However, you can run on-prem with a “cloud-like” on-prem environment. There is no behavioral profile, neither live nor on-demand.
Anomalies: There is no anomaly detection. The solution only offers traditional filters and threshold alerts.
Forensic: The solution offers extremely limited forensic capabilities, as those are expected to be part of another solution. Generally, the solution is expected to integrate with a SIEM or similar 3rd party solutions, which aren’t specifically designed for databases.
Blocking: The solution can block activity through the proxy, but is blind to everything else. The limited coverage renders blocking extremely weak.
Scoring: The scoring for Satori was harmed by:
- Blind spots in its proxy technology.
- No behavioral data at all. No anomalies or forensic information.
- Blocking coverage that is limited to what their proxy can see.
DataSunrise
DataSunrise Activity Monitoring and Database Firewall are complementary network-based packet capture solutions. Such network-only solutions typically target DBaaS clouds, as they are ineffective when a DBA can log into the database server.
Capture: The capture mechanism relies on network-based packet capture. It has a sniffer option, but mostly deploys as a proxy. There is a recent agent mode, but it currently has very limited platform support. Encrypted activity may be visible in proxy and agent modes depending on the database platform and encryption keys. Internal database activity is never visible.
Storage: DataSunsite activity recording is a bit of a “built your own solution”. It can write to various external databases, but offers no features beyond recording. For example, a suggested implementation for alerting is through manually created database triggers. The recommendation is to record and process the activity using external 3rd-party solutions such as a SIEM. There is no behavioral profile, neither live nor on-demand.
Anomalies: The closest thing to automation is a learning process that created a SQL whitelist for blocking. However, there is no real anomaly detection.
Forensic: Capabilities are extremely limited as they are expected to be part of other solutions. Even in the 3rd-party case, that solution is never designed for database activity monitoring.
Blocking: Blocking only operates in proxy mode, but it cannot see or block local activity or activity that bypasses the proxy. The limited coverage renders blocking extremely weak.
Scoring: The scoring for DataSunrise was harmed by:
- Blind spots in their packet capture technology, which is mostly deployed as a proxy.
- No built-in repository or any derived capability such as alerting, reporting, or forensics.
- No behavioral data at all. No anomalies or forensic information.
- Blocking coverage that is limited to what their proxy can see.
What’s Right for You
Solutions in the market drive in several different directions, and it’s important to figure out what you expect to gain.
Administrators: If DBAs are a potential threat, you must have a solution that, at the very least, can capture local activity. Ideally, such a solution would also capture internal database activity, since DBAs are more than skilled enough to bypass a packet capture solution that doesn’t see inside the database engine. Leading contenders are Blue Core Research, Imperva, and IBM Guardium, where only Blue Core Research can see activity inside the database engine.
Applications: If applications are an attack vector, most high-end capture can see their activity, but few can leverage it to detect attacks. A solution that can target application activity requires an anomaly analysis engine that can sift through the billions of SQLs to find malicious ones. Check out the Behavioral Storage column in the Data Quality table and the Anomaly column in the Overall Rating. Leading contenders are Blue Core Research and Varonis. Another possibility is Imperva, though it isn’t top-tier.
End-Users: To gain a deeper understanding of end-user activity, check out Application Activity Control (AAC). Those solutions have visibility into application activity, from a URL GET to a JDBC SQL call and everything in between. While some solutions, like Varonis, integrate that into their SQL monitoring, controlling end-users is part of the application domain, not the database one.
Blocking: If you wish to block activity, it’s vital to consider who you’re aiming to block. It is better to block DBAs with Blue Core Research, as DBAs cannot bypass Core Audit. However, blocking application attacks is better with Varonis, as that is their specialty.
Cloud: Securing the cloud breaks into two sub-markets: IaaS and DBaaS. When examining them, you must accept that the more control you give up by outsourcing to the cloud, the less security control you can expect. You retain sufficient control in IaaS, and security threats and solutions are similar to on-prem. However, you cannot control the database machine in DBaaS and cannot have such tight security. You must, therefore, abandon server security and rely only on network and proxy-based solutions. Such solutions received low scores in this review since they don’t cover the database server, but they are best suited for DBaaS environments.
The Path Forward
The Database Activity Control market is at a crossroads. For years, organizations accepted “compliance-level” security. Products that provide enough reports to pass an audit but lack the visibility and control required to stop a modern breach. The cost of a data breach makes partial capture and a lack of application control an unacceptable risk.
If your goal is to secure a cloud-native DBaaS, Application Activity Control, or proxy-based solutions would be ideal for you. However, for organizations protecting mission-critical data in self-managed infrastructure, complete capture, anomaly analysis, and powerful forensics are no longer optional.
- Introduction
- Overall Rating
- Security Goals & Scoring
- The Technology Landspace
- High-End Solutions
- Data Quality
- Solutions
- What’s Right For You
- The Path Forward
Comments
AI Recommended
Ask a Question
If you have a question or a comment, please let us know. We’ll be happy to hear from you.
