It might be just my pet peeve, but I never really liked the term “Firewall”. Of course, the history of IT is full of words that have completely changed their meaning over the decades yet still occasionally cause discussions among experts. Is antivirus dead, for example, considering that they stopped making real viruses years ago?
Firewall, however, stands out even more. The original brick-and-mortar one had one purpose only: to limit the spread of fire between buildings. A real firewall does not have any holes, and surely, it cannot apply any logic to different kinds of fire… A network firewall, however, could. That was its primary purpose – to filter network traffic based on defined rules, letting “good” traffic in, and keeping malicious stuff out. Over the following decades, the concept has evolved significantly, with next-generation firewalls adding capabilities like deep packet inspection, intrusion prevention, and even identity management.
Multiple ranges of specialized products have emerged, like Web Application Firewalls specializing on protecting web apps and APIs or even Database Firewalls designed to prevent SQL-specific attacks on relational databases. A modern firewall is thus a sophisticated solution that combines multiple layers of security, often powered by behavior analytics and artificial intelligence – a far cry from the original rules-based one. Is it even fair to continue referring to them as brick walls?
I can see you asking me already: why have I even brought this pet peeve of mine up? Well, recently I was looking at a new security tool — Oracle SQL Firewall — which the company has built into its upcoming Oracle Database 23ai release. And while I wholeheartedly agree with the product’s vision, surely, calling it just a firewall is a bit odd.
You see, all past and current firewalls (even Oracle’s own specialized Database Firewall) are operating on the network level, forming a perimeter around a resource that requires protection and filtering traffic between it and its clients. The problem is that in the modern hyperconnected world, there are so many potential network paths between sensitive data and potentially malicious actors that protecting them all appears to be impossible.
This is why the concept of data-centric security has emerged years ago, focusing on protecting data itself throughout its entire lifecycle instead of constantly plugging holes in existing networks, servers, and applications. Oracle Database’s “killer feature” has always been the ability to keep all kinds of information (relational, document- and graph-based, spatial, and even vector) in one place and run complex workloads like AI training directly within the database. Integrating an additional security layer to prevent SQL-level attacks directly into the DB core is therefore a major step towards data-centric security.
The new Oracle Database 23ai adds multiple new capabilities that can also create new attack vectors. For example, using Select AI to generate SQL queries from natural language prompts is a great tool for data analysts and business application developers. But to enable it, a database must communicate with an external large language model, and conventional firewalls simply cannot protect it from potential abuse.
Figure 1: High-level overview of SQL Firewall’s architecture
Oracle SQL Firewall, on the other hand, operates directly in the database core, making sure that it cannot be bypassed, regardless of the SQL execution path – whether coming from an external client, a local privileged user, or a generative AI solution. Residing directly in the database also provides it with the necessary insight into all the activities happening there.
Over time, it learns how various clients work with the data, establishing their behavior profiles and creating policies based on actions that are allowed for specific data. These allow-lists explicitly define what SQL statements a specific database user is supposed to perform. Everything else – suspicious anomalies, zero-day attacks, and, of course, SQL injection attacks – is blocked. However, it is possible to run SQL Firewall in a permissive mode as well, just generating audit records and alerts.
This protection is not only ubiquitous and impossible to bypass, but also completely transparent to any client applications, local or remote. There is no need to change existing network settings, introduce a proxy service or give a third-party vendor access to your sensitive data for monitoring. As an added benefit, SQL Firewall incorporates mandatory identity checks through session context, making credential theft or abuse much more difficult.
Of course, Oracle already had several security tools with similar coverage for years, including Audit Vault and Database Firewall – and they are even more capable in a way, providing coverage for non-Oracle databases as well. However, SQL Firewall is a core function of the new 23ai release, not an additional product. It is currently available in Oracle Database Enterprise Edition and requires either Oracle Database Vault or Oracle Audit Vault and Database Firewall.
Its configuration can be managed in several ways: either using the Oracle Cloud’s UI (exposed through Oracle Data Safe) or by utilizing command line tools or APIs. Needless to say, it is available at no extra cost and has negligible performance overhead. This way, it not only implements data-centric security, but also helps enforce the “security by design” principle and facilitates the adoption of Zero Trust architectures.
So, is SQL Firewall supposed to replace all the other data security tools? Not at all, its goal is to add another layer of protection into an existing defense-in-depth stack. Often, it will, in fact, be the last line of defense, positioned directly in front of your sensitive data. Should it be called a firewall? Again, while I, personally, don’t like the term, a rose by any other name would smell as sweet… As KuppingerCole Analysts always stress – you should not look at the labels and always check the actual capabilities offered by a product.
With Oracle’s new solution, you can address two major problems at the same time: protecting databases from SQL-based attacks and implementing 100% audit coverage of database activities. Not bad for a firewall, I think…