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

Audit Vault Architecture The Oracle Audit Vault architecture consists of two basic components: the Audit Vault Server and the Audit Vault Collection Agent.. The data is transformed in th

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

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

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.”

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

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

■

■

■

■

■

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

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

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

■

■

■

■

■

■

■

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

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

Type

Order of operations SessionId, EntryId

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

from the sybsecurity database

log (db2audit.log) located in the security subdirectory of the DB2 database

TABLE 3-1 Audit Source Collectors for Non-Oracle Databases