Applied Oracle Security: Developing Secure Database and Middleware Environments- P10 docx

64 Part I: Oracle Database Security New Features
When considering when to audit, the guiding principle is to audit whenever something
destructive occurs and when critical actions take place. A critical action is admittedly a nebulous
term, but here it’s meant to imply any action that can have significant impact. For example,
consider an application in which the update of a field (column and/or row update) allows a user
to join a membership group that then gives her privileges to execute important and sensitive tasks.
This would be considered a critical action. Note that it’s not the fact that a data field value
changed, but what the change in the value meant.
Audit Patterns
As mentioned earlier, auditing offers ever-increasing value. Many organizations are obtaining
valuable information from their auditing capabilities because they have figured out how to
audit—what to audit and when—and not just from a security perspective.
We call this collection of auditing actions “audit patterns” to signify that a grouping exists and
that the grouping occurs frequently. Recognizing the grouping tells us that auditing does not have
to be considered at a statement-by-statement or action-by-action level. Aggregating and grouping
related statements or actions is a more effective auditing technique, as the actions can be grouped
into patterns, which subsequently tell us intent.
Consider this example: You need to audit important information, and you decide to audit the
table containing financial data. If you simply look at it from a statement-by-statement level, all
you may see in the audit logs are a bunch of INSERT, UPDATE, and DELETE statements. These
don’t tell you everything, however, and they may not tell you anything insightful. It may be
difficult to tell whether an update is OK (from a security policy perspective), since some table
updates could be OK and others might be problematic. It all depends on the context of the update.
Now consider auditing from the perspective of a financial transaction. The transaction itself is
the item of interest, and it happens to consist of several statements. (This is precisely why you can
group Oracle audit records by transaction identifier.) The transaction establishes context for the
DML statements that make up the transaction. The order of the statements follows a sequence
or pattern. Thus, you can relate the pattern to the transaction and you can begin to consider
questions such as “Is this transaction authorized at this time of day and day of the year?”
You can take the lesson learned from aggregating statements into transactions up another level
by looking at multiple actions or transactions. This time, you may even want to aggregate and

correlate across multiple databases and applications. This would require a single auditing repository
in which the cooperating databases and applications all sent their audit data.
Regardless of the motive of level, auditing patterns will exist. You can think about audit
patterns in two ways: known audit patterns and unknown audit patterns.
Known Audit Patterns
Known patterns consist of transactions that you understand—a series of actions in a specific order
that were used for a specific intent. For example, a bank transfer consists of a debit from one
account and credit to another account. It occurs in that order and the intent, as stated, was to
transfer money.
Within the enterprise, known audit patterns are derived from known activities. Your job will
be to recognize the patterns and when they occur.
We’ve used the top five patterns as examples. An exhaustive list of known patterns is not
possible, if for no other reason than known activities (that is, actions that create audit records)
are often unique within an organization.
Chapter 3: Applied Auditing and Audit Vault 65
Privilege Escalation Privilege escalation is a common security “attack vector” or method. It is
based on the simple process of using one account or privilege within an account to gain greater
and greater privileges. The end goal is usually to escalate the privileges to the point at which
something harmful can be done.
To identify this problem, you would typically see a series of privilege grants to a single user
or to two users. For example, you might see a grant on the EXECUTE ANY PROCEDURE system
privilege. This privilege might be used to execute PL/SQL code that, in the code itself, enabled
another privilege or possibly even a secure application role. The pattern we identified was an
anomalous grant to a user followed by more grants to or from that user.
This example is a simplification used to help convey the point that it can happen and it is
not too difficult to do once given access to an account with some privileges. Unfortunately, this
attack can be executed in many ways, which makes stopping it difficult. Therefore, from a
security perspective, auditing provides an invaluable tool to help you identify such a problem
has occurred or, better yet, is occurring.
High-frequency Logon Failures and Failed Accesses A common attack method consists of

repetitive attempts to break into an account using a slightly different approach on each attempt,
such as by guessing the password. This would easily manifest itself in audit trails as consecutive
logon failures for the same user.
Likewise, consecutive failed access attempts may be a strong indication that someone is trying
to gain access to something she is not supposed to access. This is analogous to someone banging
on a locked door in desperate efforts to break down the door. You generally want to know when
someone is trying to break down your door because, sooner or later, they just might get through.
The same holds true with data access attempts. In data security, a malicious hacker is often
unsuccessful on his first attempts.
A large set of failed attempts is very suspicious—except when it’s not! When is a large set of
failed attempts not suspicious? Failed access attempts may also signify that an authorized person
is trying to gain legitimate access to something she is supposed to access, but an unfortunate
coding or configuration error is preventing her from doing this. The benefit to proactive auditing
is that you would be able to see who was trying to access what, and upon further investigation,
update the security to allow the person the ability to do what she is supposed to be doing. This
could theoretically be accomplished before the trouble ticket is issued.
Default Account Logon Failure One aspect that significantly increases the security risks to a
product is the popularity of the product itself. The popularity of the product is believed to draw
significantly more attackers, because more people know about the product, more information will
be available publicly, and more will know how the product works. The saying goes: The bigger
the popularity, the bigger the target.
This holds true for Oracle, and you can see this by searching on simple terms such as “Default
Oracle Account Passwords.” You will find a list of tools that define the default user accounts
and passwords for Oracle databases. Many of these accounts are now locked by default and the
passwords have expired. However, people are creatures of habit, and you might be surprised at
how many will flip the traditional accounts back to their default passwords to make their jobs
easier.
While you cannot see what password a person used when he tried to authenticate (which
might help you see if he was using the known default password), you can see that a logon failure
occurred. The pattern you are looking for is someone cycling through the default accounts. Your

66 Part I: Oracle Database Security New Features
audit logs would show failures for these accounts. The logs may even record several failures for
the same account where other well-known passwords (such as the password “manager”) may
be used.
If you are auditing with Audit Vault, you might even see this on multiple databases. The
pattern presents the clear intent of someone trying to hack into your database(s).
Across Databases The preceding point regarding failed logons to known accounts across
multiple databases is a good transition into this topic. Many security breaches occur through very
indirect access paths. Identifying known patterns is as simple as looking at the audit records from
the various systems. Any attack on a single database can often be found across database instances.
If you notice a series of failed logons on your Oracle10g databases, you should inspect any
Oracle 9i databases, too, since they are not locked by default. Seeing the attempts on multiple
databases may indicate that someone has mapped your network and is jumping from server to
server, the same way a burglar might move from door, to window, to window, to door.
One of the true values of an enterprise Audit Vault is its ability to present security attacks that
were never visible before, because no one could correlate the information.
Business Use Policies In Chapter 4, we discuss the concept of context-based security. Security
access decisions can be based on the context of the action and not just the action itself. For
example, the ability to update data may be allowed when the user is accessing data through a
secure application, but it may be disallowed otherwise.
A corollary to this occurs in auditing when you factor your business or application use with
the actual application use. For example, you may allow a credit verification application access
to your core financial data. However, a policy may state that the access can occur only during
business hours. This is a very good policy, because generally more people are around watching
each other during business hours.
An audit of financial data could indicate that someone was accessing the application data at
inappropriate or questionable times. A Sunday access at 5
A.M. could, and possibly should, set off
an investigation (unless of course, this is when the batch verification program runs).
Unknown Patterns: Looking for Anomalies

Unknown patterns are repeating sets of events whose intent or function are unknown. Sometimes
these patterns are harmless, but sometimes they are harmful. Both types are valuable to your
understanding of what’s going on in the database. The more familiar you are with your data and
the manner in which your users and applications access the data, the better you will become at
recognizing things that don’t fit.
One effective technique for noticing patterns uses the basics of an audit data warehouse. It
is based on the notion of aggregates, averages, and trends. Suppose, for example, that you are
collecting information, and all the access and actions you see are authorized and legitimate.
Within that data, you notice very important statistics that help you determine the health of your
systems. For example, you can calculate the average number of users on a given day, when
people log on, what schemas are accessed, what tables are accessed, and at what frequency.
All this information establishes a baseline considered “normal use.”
Chapter 3: Applied Auditing and Audit Vault 67
NOTE
In Chapter 7, you’ll see how to determine which objects to protect
with Database Vault: sensitive objects, users, paths, and privileges
information. You will also learn how to establish a baseline for normal
database use. Database Vault provides a default audit policy for the
best practices mentioned here.
After you have collected this information, you can begin to identify patterns in usage and
behavior. For example, you might find that a particular application is used only on Fridays. This
turns out to be the activity reporting application, and people log their activities on Friday. You
could then set up an alert that notifies you if access occurs any other day of the week.
The three biggest audit factors that stand out as anomalies may be the time of day and day
of week that something is accessed, the frequency of access, and the path used for access. The
access path is usually a rigid, or static, access path from application server, through a database
account to the data. If you find a strong deviation in either one of these factors, you have found
something legitimate to investigate. This information can be easily obtained with proper auditing.
Other Audit Action Best Practices
In addition to noticing audit patterns, you should always use several auditing best practices. First

on the list of events to audit are logon and access failures, as mentioned earlier in the context of
patterning the logons. Frankly, any failed logon as a DBA or analogous account is worthy of an
audit inspection. Access failures should also be audited. As with logon failures, an access failure
as a single element is worthy of audit inspection because these failures generally mean one of two
things: someone is trying to do something he shouldn’t, or the code or configuration is broken.
Successful logons are important because they provide a list of eligible suspects. If something
bad happens, knowing who was on the system at the time gives you a concrete starting point.
Logons are also invaluable in providing information about the normal use of the database or
application. When establishing a baseline for your system, the frequency and number of logons
are good statistics to note. Any large deviation in the frequency or number of logons may indicate
something of significance. For example, a failed server may cause an increased number of logons
on your server if your server is the backup. An increase in logons would be an indirect indication
that the other server has failed or is unreachable to the clients. This is not necessarily a security
issue, but it is an important issue.
Account creations, especially on production systems, may be considered anomalous activities
and are worthy of audit and inspection. This could result from a compromised account that has
the CREATE USER system privilege. The plan may be to create a new user and then use the new
user account for future logons. This would protect someone if the initial account is re-secured.
Part of our message is that auditing is not always a security issue. A new account creation on
a production system may not mean that someone is setting up an access account from which to
conduct nefarious activities in the future; a new account may simply signal that a new application
is being installed. This is good information for you to know, especially if strange things begin to
happen shortly after the account is created. It’s also not considered unusual for someone to install
68 Part I: Oracle Database Security New Features
unapproved applications/products on the production server accidentally, either because the user
forgot she was on the production server or forgot she was supposed to get permission to install
such an application. Auditing with alerts could proactively detect and notify you of such
important events.
You should begin to see the methodology espoused here. You want to look for actions and
activities that are considered highly unusual or highly risky. In addition, you can use auditing as a

way to indicate that something is broken or working in a suboptimal way. Before we walk through
the specifics of Audit Vault, consider the following abbreviated list of audit suggestions:
System grants and object grants The granting of system and object privileges in an
already running production system is a huge red flag. Clearly, the only reason this would
be done is to fix another problem or patch the system—both of which should be easily
confirmable. Something as simple as a GRANT SELECT on SH.SALES to SCOTT could be
an indication of a privilege escalation attack.
DDL in production If you ask most DBAs whether random DDL changes to a
production systems are occurring, chances are you’ll get a look of disdain and a quick
remark of “absolutely not.” Configuration control and the reliability of the system highly
depend on the system staying architecturally rigid. Auditing to capture DDL changes is an
obvious thing to do.
Source code modifications PL/SQL code in the database can do so much, from integrity
to security. No matter what the code is used for, doing anything to it other than executing
it is reason for investigation. Viewing the source code and updating the code can be real
security issues.
System alterations System changes, often invoked with the ALTER SYSTEM command,
can have enormous security relevance. Checking to ensure that auditing has not been
disabled (NOAUDIT) and that other system settings such as O7_DICTIONARY_
ACCESSIBLITY, SQL_92_SECURITY, and AUDIT_SYS_OPERATIONS are still operating
as planned is critical to ensuring that the system is still acting in a safe and secure state.
Resource optimization/usage Looking at access frequency has huge value in capacity
planning and resource optimization. Additionally, unused applications and schemas are
security vulnerabilities that provide a potential foothold for nefarious users.
A SQL script that contains many of these settings as well as a few practical others is included
in the Audit Vault installation. It can be found at $ORACLE_HOME/demo/secconf.sql.
The Audit Warehouse Becomes the Audit Vault
You may have guessed by now that the best thing you can do to secure your Oracle Database
involves the judicious use of Oracle Database Vault. Chapters 4–7 cover the Database Vault in
detail. It’s mentioned here because Database Vault was needed by the Audit Vault developers to

harden the audit data warehouse. This helps you meet many, if not all, security requirements that
you desire when considering the use of an audit database for compliance and other important
issues.
■
■
■
■
■
Chapter 3: Applied Auditing and Audit Vault 69
The notion of customer-built audit data warehouses was transformed into an Oracle-built
Audit Vault. Oracle’s product is not merely an analogous creation of what people were already
doing wrapped up in an Oracle package. Audit Vault almost always undergoes kernel and code
changes and various optimizations when it’s put to use. Add to that regression testing and support,
and the overall cost per functionality could not get lower.
In addition, when you consider the code tweaks and optimizations, the Oracle products are
in fact technically superior to those we would create using the base technology, and Oracle Audit
Vault is no exception. It is a hardened database that acts a data warehouse for auditing data.
A final important note on Oracle auditing, and Oracle Audit Vault in particular: Auditing
is always transparent to the application. As mentioned in Chapter 1, this is one of the critical
success factors for an effective security implementation. The good thing about auditing is that the
administrator, security administrator, or even the auditor can control what to audit and when. This
important separation between auditing and audit policy are important factors for implementing a
compliance-based auditing environment.
Throughout the remaining sections, we describe how Oracle Audit Vault meets the auditing
requirements described in the first parts of this chapter. A key reference used for this section was
the document “Oracle Audit Vault Best Practices,” published in 2007 by Oracle Corporation. This
document was written by Tammy Bednar with contributions by Paul Needham and Vipul Shah. It
is extremely well written, so, with their permission, we have reused some of their graphics and
tables here to provide the highest quality content without replicating what has already been done.
Audit Vault Architecture

The Oracle Audit Vault architecture consists of two basic components: the Audit Vault Server and
the Audit Vault Collection Agent.
Audit Vault Server
The Audit Vault Server is the audit data warehouse and acts as the consolidated repository of all
audit data. It installs with an Oracle Containers for J2EE (OC4J) Audit Vault Console and is integrated
with Oracle Enterprise Manager’s Database Control.
The Audit Vault Server is built on a hardened Oracle database. The data is transformed in
the Audit Vault Server and loaded into a special data warehousing schema that is optimized for
reporting and query functions and leverages advanced data warehousing technologies, such as
partitioning, that Oracle builds into the database.
Audit Vault Collection Agent
As Figure 3-1 shows, the Audit Vault collection agent consists of the collectors for the relevant
audit source. The collectors work to extract the data from the audit source and securely transfer
that data to the Audit Vault Server. When login credentials are required, the collection agent also
maintains an Audit Vault Wallet that securely stores the credentials for later access to the audit
sources.
Audit Vault collection agents are deployed on the each of the database servers from which
you intend to collect audit data. Clustering technology, which provides load-balancing and
active-active failover, is used along with Data Guard, which provides offsite disaster-recovery
capability.
70 Part I: Oracle Database Security New Features
Installation Options
You will consider several factors when deciding how and where to install the Audit Vault Server
and the Audit Vault collection agents. In this section, we describe these options. The intent here
is not to duplicate the information provided in the installation manuals, but to describe the
components and discuss installation from an architectural perspective.
Installing Audit Vault Server
The Audit Vault Server, the data warehouse for the enterprise audit functions, is built on a
hardened Oracle database. The schema is optimized for reporting and query functions and
leverages the advanced data warehousing technologies, such as partitioning, that Oracle builds

FIGURE 3-1 Audit Vault architecture overview
Chapter 3: Applied Auditing and Audit Vault 71
into the database for doing these very things. You should install this data warehouse on a server
that is built to run this type of application.
The Audit Vault Server stores, manages, and acts upon data that is collected by the Audit Vault
collection agents. The Audit Vault Server can use other core Oracle database technologies. For
example, to achieve scalability and provide high reliability, Oracle Audit Vault can be deployed
to a Real Application Cluster (RAC) architecture. To create a disaster recovery capability, Oracle
Audit Vault can be deployed using Data Guard.
Communication channels to and from the Audit Vault Server are protected with network
encryption via the Advanced Security option, which helps to ensure the data has not been
tampered with or viewed while in transit from one of the audit sources to the server itself.
The availability of Audit Vault is required in both the capture and the analysis of audit data.
If the Audit Vault were unavailable for a period of time, data would be collected on the source
systems and problems would occur during the collection “catch-up.” By including both RAC (for
high-availability and standby failover) and Data Guard support (for disaster recovery sites), the
architecture can be built to suit the needs of any organization’s service level requirements. Note
that while using RAC and Data Guard are a best practice, Audit Vault doesn’t require their use.
TIP
The Audit Vault Server should be installed on its own host or on
a host that contains other repository databases such as Enterprise
Manager Grid Control or the Oracle Recovery Manager (RMAN)
repository database. You should consider deploying Audit Vault
in a RAC configuration with Data Guard enabled for disaster
recovery capabilities. By installing the Audit Vault Server separate
from the source database servers, you can get better control of the
availability, speed, and overall security of the auditing functions. This
independence is what makes Audit Vault so appealing.
Installing Audit Vault Collection Agent
The Audit Vault collection agent consists of various collectors for the various sources it supports.

As of Audit Vault 10.2.3, audit information can be collected from the following supported
database versions:
Oracle9i Database release 2 (9.2)
Oracle Database 10g release 2 (10.2)
Oracle Database 11g release 1 (11.1)
Microsoft SQL Server 2000
Microsoft SQL Server 2005
IBM DB2 UDB 8.2 and 9.5
Sybase ASE 12.5 and 15.0
Oracle has future plans for an SDK, which would allow you to integrate various audit sources
not currently supported. As you might imagine, the actual audit data collected from each source
will vary by product.
■
■
■
■
■
■
■
72 Part I: Oracle Database Security New Features
For Oracle databases, the collection agent can use three different collectors:
DBAUD Grabs data directly from the Oracle database audit trails. It extracts data
created from standard auditing, which is stored in SYS.AUD$; it extracts data created
from fine-grained auditing, which is stored in SYS.FGA_LOG$; and it extracts data from
the Database Vault audit records stored in DVSYS.AUDIT_TRAIL$.
OSAUD Captures Oracle database audit records written to the operating system files
(.aud or .xml) or the operating system’s syslog daemon.
REDO Extracts data from the database redo log files. This has the benefit of capturing
BEFORE and AFTER values and uses the change data capture technology of Oracle
Streams, but it is managed centrally in the Audit Vault console.

Figure 3-2 summarizes the three collectors for the Oracle database.
Table 3-1 shows from what, or more specifically from where, the audit information is
retrieved for the other supported audit sources.
The Audit Vault collection agent configures the collector processes for each source. It also sets
up the configuration and connections from the collectors back to the Audit Vault Server. Later in
this chapter, we will look at a collector installation process.
Choosing the Collector Type
Choosing the correct collector has obvious importance in two areas. First, you want to ensure
that you collect the right information. Second, you want to do so in a way that does not limit the
performance of the audit source. For the non-Oracle audit sources, you don’t have a choice on
which collector type to choose. For Oracle, however, you can choose among OSAUD, DBAUD,
and REDO collections.
Your choice of collector can also be based by logically thinking about Oracle Database
auditing. Following is a list of ways you might categorize the types of auditing events that occur
■
■
■
FIGURE 3-2 Audit Vault agent collectors for the Oracle database
Chapter 3: Applied Auditing and Audit Vault 73
in the database. Using these categories as guidelines, you can decide what to audit based on how
the audit events map to your compliance initiatives and security concerns.
System and SYS events Manage settings and initialization parameters. Core changes to
the database are included. They are captured only when you audit SYS or use the ALTER
SYSTEM command. The best practice is to have the audits written to the OS, as whoever
generated the audit event may also have the privileges to delete from the database audit
tables. This category is often mandatory in compliance settings, because changes to the
system imply changes to a standard or baseline configuration.
Database DDL and DML events Track access by any user, operation, or object within
the database. The following table depicts some of the basic functions and the specific
fields being audited:

Audit Function Example Audit Fields
User data DB User, OS User, Client Identifier
Object Object_Owner, Object_Name, Object_
Type
Operation Action, System Privilege User
Time Timestamp, Logon, Logoff
Location Terminal, IP Address
Order of operations SessionId, EntryId
Transaction Transaction ID, SCN
SQL request SQL Text, Bind Variables
Database Vault events Manage the DBV settings, including Realm Audit, Factor Audit,
and Rule Audit. This information is stored in DVSYS.AUDIT_TRAIL$.
Data access events Include access to specific table columns, data rows, or data records.
This is the primary use of fine-grained auditing (FGA), and the auditing is not enabled
through a database event but through invoking the DBMS_FGA package. Auditing is very
selective, which allows you to focus precisely on the data fields of interest. The data is
stored in SYS.FGA_LOG$.
■
■
■
■
Database Collector Collected Log Location
Microsoft SQL Server MSSQLDB C2 audit logs, server-side trace logs,
Windows event logs
Sybase ASE SYBDB System audit tables (sysaudits_01-08)
from the sybsecurity database
IBM DB2 DB2DB ASCII text file extraction of binary audit
log (db2audit.log) located in the security
subdirectory of the DB2 database
TABLE 3-1 Audit Source Collectors for Non-Oracle Databases