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 . can be collected from the following supported database versions: Oracle9 i Database release 2 (9.2) Oracle Database 10g release 2 (10.2) Oracle Database 11g release 1 (11.1) Microsoft SQL Server. 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. 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