5/11

# 1 Introducing the Oracle Database Firewall System

This chapter contains:

- Downloading the Latest Version of This Manual

- About the Oracle Database Firewall System

- Oracle Database Firewall Applications

- Planning the Protection Level for Your Databases

## Downloading the Latest Version of This Manual

You can download the latest version of this manual from the Oracle Database Firewall Web site, which is in the Database section of Oracle Technology Network. The URL is as follows:

`http://www.oracle.com/technetwork/indexes/documentation/index.html`

## About the Oracle Database Firewall System

This section contains:

- What Is the Oracle Database Firewall System?

- The Oracle Database Firewall Approach to Database Security

- Oracle Database Firewall Architecture

- Using Policy Files to Create Data Policies

- Oracle Database Firewall Operational Modes

- How the Oracle Database Firewall Logging Feature Works

### What Is the Oracle Database Firewall System?

The Oracle Database Firewall system secures and protects data in Oracle, Microsoft SQL Server, Sybase Adaptive Server Enterprise (ASE), Sybase SQL Anywhere SQL, and IBM DB2 SQL (Linux, UNIX, and Microsoft Windows) databases. It blocks attempted attacks, logs activity, and produces related warnings. It provides tools to assess vulnerabilities and enhances existing database security features, such as encryption and user authentication.

Traditional systems usually test the syntax of statements passed to the database, recognizing predefined expressions. Creating a set of rules using this technique requires a hand-crafted approach and can be very time-consuming and complex, even for someone very knowledgeable about the database. Even if significant resources create satisfactory protection for known threats, little protection may be offered for unknown threats. The Database Firewall addresses these challenges.

### The Oracle Database Firewall Approach to Database Security

The Oracle Database Firewall system works by analyzing the meaning of the SQL statements that database clients send to the database. This provides a much higher degree of protection than traditional database firewalls, because it does not depend on the source of an attack or recognition of syntax of known security threats.

There is no limit to the length of SQL statements that the Analyzer can analyze; it displays up to the first 2000 characters of a statements. Also, it looks at all types of SQL statements, not just product-specific SQL. For example, it looks at regular ANSI SQL as well as Oracle PL/SQL.

The database firewall can block previously unseen attacks (known as "zero-day" attacks), including those targeted individually against your organization. Zero-day attacks are becoming more widespread, and there is a great need to protect databases against such attacks. The database firewall also blocks blind SQL injection attacks

The Oracle Database Firewall protects the database server without affecting the performance of the database server or its client applications. The system protects from attacks originating from inside firewalls, as well as from external sources.

### Oracle Database Firewall Architecture

The central feature of an Oracle Database Firewall system is the ability to scan and log SQL traffic to and from the monitored databases. The Database Firewall system scans all SQL statements passed to the databases in real time. You can configure enforcement points to monitor traffic, generate warnings of potential attacks, and block harmful statements.

Figure 1-1 shows a typical deployment of Oracle Database Firewall.

Figure 1-1 Oracle Database Firewall Architecture

Description of "Figure 1-1 Oracle Database Firewall Architecture"

The main components are as follows:

- Database clients and applications: These represent the end users of your applications.

- Oracle Database Firewalls: The Database Firewall enforces data policies that you create in Oracle Database Firewall Analyzer. Oracle Database Firewall employs at least one Database Firewall for up to 20 protected databases. Each Database Firewall collects the SQL data from these databases, sends it to the Management Server, and then deletes their SQL data locally. The Database Firewall handles real-time recording and analysis of SQL transaction requests and responses from a protected database. The Database Firewall can use the remote and local monitoring features to forward network traffic from remote or local databases to Database Firewall.

- Protected databases: You can protect Oracle, Microsoft SQL Server, Sybase Adaptive Server Enterprise (ASE), Sybase SQL Anywhere SQL, and IBM DB2 SQL (Linux, UNIX, and Microsoft Windows) databases.

- Oracle Database Firewall Analyzer: You use the Analyzer to create data policies so that you can monitor your site's protected databases. See "Oracle Database Firewall Analyzer" and "Using Policy Files to Create Data Policies" for more information.

- Oracle Database Firewall Management Server: The Database Firewall Management Server manages all Database Firewalls that are connected to it. It accumulates SQL from these firewalls, stores and manages log files, provides business reports, and integrates with third-party applications as needed. You, as the administrator responsible for managing policies, use the Management Server to upload policies, set the monitoring mode, and so on. See "Oracle Database Firewall Administration Console" for more information.

### Using Policy Files to Create Data Policies

A policy file is a set of rules the Database Firewall uses when it monitors SQL traffic to a database. Using a policy file, the Database Firewall compares incoming SQL statements and determines what actions to take when intercepting a SQL statement. Actions can be allowing, blocking, or producing a warning for each SQL statement that the Database Firewall passes to the database. The policy file can produce an alert when a specific database user logs in or out, and block database users who make a specified number of unsuccessful logins attempts.

You can use Oracle Database Firewall Analyzer to customize the policy file to the exact needs of the protected database, detecting any unusual system activity, from both inside or outside of the organization. The policy file can, for example, generate a warning when previously unseen classes of SQL statements occur, or block injected SQL statements that attempt to delete or access information in specified tables.

#### Creating Policy Files

You use the Analyzer to create an initial policy file from SQL statements that the Database Firewall logs while monitoring normal database traffic. The Database Firewall system automatically trains itself with knowledge of the protected database. This process produces a set of logged SQL statements that reflect actual usage of the database to provide a model of normal operation. This model stores all the settings used to create a policy and the results of testing logged SQL statements against the previous set of data. The Analyzer then generates a policy from these logged statements.

See Also:

"Oracle Database Firewall Operational Modes" for further information about Training Mode

The Analyzer also can generate a policy file from a train file or a server trace file. See "Using Oracle Database Firewall Analyzer" for further information.

In all cases, you can further customize the policy file to the specific requirements of the site and the database being protected.

#### Using Policy Files

The Analyzer uses its knowledge of the SQL language to group the logged SQL statements into clusters, defined by similar semantics. The rules to allow, block, or produce a warning for a statement are defined not at the statement level, but at the cluster level, which may encompass many different individual statements.

### Oracle Database Firewall Operational Modes

Depending on operational needs (which are reflected in the design of the policy), a Database Firewall can operate in either a monitoring or blocking mode. See "Planning the Protection Level for Your Databases" for more information.

### How the Oracle Database Firewall Logging Feature Works

This section contains:

- What Is the Purpose of Logging?

- What Logs Does Oracle Database Firewall Maintain?

#### What Is the Purpose of Logging?

You can use the information logged by a Database Firewall for the following purposes:

- System monitoring and report generation: Enables you to monitor the system for possible attacks and then generate reports based on these findings.

- Analysis and comparison against the data used to create the policy: Enables the Analyzer to detect behavior changes and improve the policy.

  The process of analyzing new log data can expose new and undesirable features of database client applications, such as unexpected permission changes, which may occur over time. In this way, a Database Firewall can help to maintain focus on security over the entire life of the database.

- Independent logging of database activity for audit or compliance purposes: Logged information can, for example, be used for forensic analysis to determine how a database was accessed and by whom.

The Database Firewall can perform targeted logging, such as only logging statements that match specific clusters or only logging statements that do not match previously seen clusters. Targeted logging reduces log storage requirements and ensures that only required information is saved. The logging rules are stored in the policy.

Note:

For informational reasons, you should always enable logging for actions that you want to block.

A Database Firewall digitally signs all logged data to indicate the authenticity and origin of the data.

#### What Logs Does Oracle Database Firewall Maintain?

A Database Firewall maintains three logs:

- Traffic Log: Stores all SQL statements and database login and logout events that the policy requires.

  Each logged statement and event can include a set of attributes that provide additional information about the originator, including:

  - The database user login name

  - The IP address of the database client

  - The user's operating system login name

  - The name of the client program

  If the information about the originator is not available from the SQL traffic directly, a direct database interrogation (DDI) feature enables a Database Firewall to query the database to obtain the information. DDI can be enabled or disabled as required. DDI can only be used with Microsoft SQL Server and Sybase SQL Anywhere.

  See Also:

  Oracle Database Firewall Administration Guide for further information

  In addition, you can enable a database response monitoring feature, which stores all responses that the protected database makes to SQL statements and login and logout requests, in the traffic log.

- Event Log: Stores system events that are not directly related to the Database Firewall software, such as operating system warnings.

- Administration Log: Stores the login ID of any user who changes configurations for system actions such as shutdowns, restarts, and policy uploads, in the Administration Console.

## Oracle Database Firewall Applications

This section describes the Database Firewall applications that you will use to create Database Firewall policies.

- Oracle Database Firewall Analyzer

- Oracle Database Firewall Administration Console

### Oracle Database Firewall Analyzer

You use the Oracle Database Firewall Analyzer to create the policy that the Database Firewalls use to block, alert, log or permit SQL statements for the database. The Analyzer does this by reading logs that the Database Firewalls create. It enables users who have little knowledge of SQL to develop policies automatically, while enabling users who have detailed knowledge of SQL to customize policies.

As part of the process of developing a policy, the Analyzer tests the logged data against previous sets of data. This enables you to identify new potential threats and to further improve the policy.

Oracle Database Firewall Analyzer is installed on a Microsoft Windows client computer, and uses secure communications to the Database Firewall or Database Firewall Management Server.

See Chapter 3, "Using Oracle Database Firewall Analyzer," for details on using the analyzer and creating policies.

Note:

Oracle Database Firewall Analyzer has Online Help that you can access using the F1 key.

### Oracle Database Firewall Administration Console

This section contains:

- About the Administration Console

- Types of Reports Generated from the Administration Console

- Stored Procedure Auditing and User Role Auditing

#### About the Administration Console

The Administration Console is a Web browser-based application for configuring, managing, and monitoring the system. You display it by logging into a Database Firewall or Database Firewall Management Server from a Web browser.

See Chapter 2, "Using the Administration Console," for more information on using the Administration Console.

#### Types of Reports Generated from the Administration Console

You can produce a variety of different types of reports directly from the Administration Console. The reports can be generated and displayed as Adobe Acrobat PDF documents or Microsoft Excel spreadsheets.

You can schedule reports to run automatically at defined intervals, such as every day, week, or month. Scheduled reports are automatically forwarded to a nominated e-mail address.

See Chapter 6, "Generating Oracle Database Firewall Reports," for details about Oracle Database Firewall reports.

#### Stored Procedure Auditing and User Role Auditing

Stored procedure auditing and user role auditing are part of the Database Firewall reporting system.

- Stored procedure audits record any changes or additions to stored procedures on a specified database server.

- User role audits record any new or changed user roles. The user role audits capture information about nested roles as well as directly-granted roles.

You can use options in the Administration Console to audit and approve changes to stored procedures and user roles in the databases on a specified database server.

See Oracle Database Firewall Administration Guide for information about configuring stored procedure and user role auditing.

See Chapter 4, "Auditing Stored Procedures and Roles," for information about viewing and approving changes to stored procedure and user role auditing

## Planning the Protection Level for Your Databases

Depending on operational needs, Database Firewall can operate in one of the following modes:

- Database Activity Monitoring (DAM): The system detects and logs unusual activity, and produces warnings, but does not block potential threats. This is useful during the early stages of deployment while you are developing and refining a policy. It is also known as monitoring mode.

- Database Policy Enforcement (DPE): The system performs all the actions of database activity monitoring and blocks potential attacks. It is also known as blocking mode.

These operations can continue independently of the Analyzer or other Database Firewall applications. For example, one Database Firewall can simultaneously monitor one protected database while blocking another.

Consider what you want Oracle Database Firewall to achieve for you. Do you want:

- Audit logging?

- Warnings of potential attacks?

- Blocking of potential attacks?

In general, implementing only audit logging requires the least up-front development time to create a satisfactory policy. SQL statement blocking requires the most development time, but provides the greatest protection.

One strategy for deployment is to start with audit logging only, and then deploy a policy file that can protect the database against potential attacks at a later date. This helps you to become familiar with the deployment.

If you want to block SQL statements eventually, then using Database Activity Monitoring (DAM) can build confidence before you deploy the system fully.

When DAM mode is set, policies can include block action levels, but statements with specified action levels pass straight through. Syslog events and reports show the statements as blocked, while in reality, the statements passed through normally. This enables you to evaluate the system in a live environment before you switch on statement blocking. During this evaluation phase, you can change the policy to modify the system responses.