First Line of Defense
Oracle Database Firewall monitors database traffic
and blocks unauthorized activity.
Tom Haunert, Oracle Magazine editor in chief, recently sat down with Steve Moyle,
chief technical officer of Oracle Database
Firewall, for an in-depth discussion of that
product’s cutting-edge security features and
functionality. The following is an excerpt from
that interview. Download the full podcast at
oracle.com/magcasts.
Oracle Magazine: Let’s start at the beginning. Our readers are likely familiar with the
concept of a firewall, but what’s different
about a database firewall?
Moyle: A database firewall has some simi-larities with a traditional network-based
firewall, in that it’s about protecting and
controlling items that flow across the
network. But unlike a network-based firewall
that’s predominately focused on ensuring
only the right destinations can connect
to the right sources, a database firewall is
entirely focused on the conversations that
are flowing in and out of your databases.
Oracle Database Firewall has a complete
understanding of the database language—
SQL—and it’s this database language that
powers the firewall and ensures that only the
conversations you want to have going into
your database are permitted. All others can
be blocked.
JOHN BLYTHE
Oracle Magazine: What are some other key
features of Oracle Database Firewall?
Moyle: The database firewall is there to
monitor database activity and to help
prevent unauthorized access to and particular attacks on databases, including SQL
injections, privilege or role escalations,
and illegal access to sensitive data. Oracle
Database Firewall has a highly accurate
approach to controlling interactions with the
database, based on a SQL grammar analysis.
This ensures that there are no costly false
alarms triggered by the firewall.
The product also provides a very flex-
ible level of enforcement options based on
Oracle Database
Firewall reduces
the risk profile of
a database at the
network level.
two different security paradigms: a positive
security model known as white lists, and a
negative security model known as black lists.
Customers deploy the firewall using a combination of these two paradigms.
Going beyond this, the firewall has a
very scalable architecture that provides
enterprise-level performance in many different deployment modes. The great news
for database administrators and application
authors is that it requires no configuration
changes at either the application level or
the database level to provide a very powerful
level of protection in the environment.
Oracle Magazine: You mentioned SQL injection, and that’s of course something DBAs
Steve Moyle, Chief Technical Officer of Oracle
Database Firewall
and database developers must always be conscious of. How does Oracle Database Firewall
address SQL injection and other threats?
Moyle: SQL injection is a development-side
error. It’s an application-layer error, but it’s
not just one single mistake—it can manifest in many different ways. It’s also entirely
application specific; each application that
has a particular SQL injection vulnerability
will appear different to its database than
its operator.
Since there’s no one-size-fits-all way of
looking for SQL injections, the technology
for protecting against them needs to understand what is normal for each database and
application in the operating environment.
However, with this level of understanding
comes protection against all manner of risks.
So although a SQL injection is often caused
by a malicious attacker on the outside, the
same sorts of controls work for protecting
against a malicious user on the inside or
perhaps someone who has connected a piece
of software to the network that is outside
policy. All of these unauthorized access
mechanisms can be protected against very
powerfully by Oracle Database Firewall.
Oracle Magazine: What are some other key
risk areas that Oracle Database Firewall can
address to ensure security in the enterprise?
Moyle: Oracle Database Firewall reduces the
risk profile of a database at the network level
by ensuring that only permitted locations
can connect through to the database—only
permitted applications at permitted times
of day with permitted users. For example,
high-privilege users may only connect to the
database from their workstations at particular times of day, which are their normal
hours of business. Should the credentials
for a high-privilege user become compromised, it would not be possible to use them
from another location within the organization’s network.
