Oracle Database Security
Raju Mehtahe Oracle database provides the nec-essary features to configure ade-quate and granular level security, including strong authentication, authoriza-tion, and monitoring controls. This article provides an understanding of key security concepts for the Oracle 8x and 9x environ-ments.
The Oracle database is one of the widely used database systems utilized by corpora-tions for transaction processing and to store critical information. It is widely used as a database server for ERP systems as well as the back-end database server for Internet-based applications. However, there are many known security vulnerabilities related to Oracle databases. For example, Oracle Corporation reported 15 new vulnerabilities from the time period of January 2003
through November 2003.1 In addition,
Securityfocus.com has posted numerous security vulnerabilities for Oracle database since 1999.2
Considering the criticality of data stored and processed through database systems, it’s important to understand how to secure and evaluate security of the Oracle database environment(s). The importance has
increased even more with corporate gover-nance drivers such as the Sarbanes–Oxley Act, Health Insurance Portability and Accountability Act, Gramm–Leach–Bliley requirements, and others.
This article discusses some of the key security features and considerations. It is not meant to provide an in-depth security discussion, but rather provide an under-standing of key concepts for the Oracle 8x and 9x environments. Further details can be obtained by reviewing the respective Oracle administrator guide as well as references provided in this article. Also, this article does not discuss security implications spe-cific to new database implementations.
DATABASE ACCESS PATHS
As seen from Figure 1, there are three ways data can be accessed (authorized or unau-thorized manner) in a database environment regardless of the specific database system used:
1. Through a front-end application 2. Through direct database connection
(e.g., ODBC and SQL*Plus)
T
A P P L I C A T I O N P R O G R A M S E C U R I T Y
RAJ MEHTA, CPA, CITP, CISA, CISSP, is a Senior Manager with Deloitte & Touche’s Enterprise Risk Services in Houston, Texas. He has nine years of experience in performing technical information secu-rity reviews and controls consulting. Information secusecu-rity reviews have included platforms such as OS390/RACF, AS/400, UNIX, Windows 2000/NT, and Novell; specific focus has been in network and database security. Raj has given a number of presentations to organizations such as ISACA (Informa-tion Systems Audit and Control Associa(Informa-tion), IIA (Institute of Internal Auditors), and SIM (Society of Information Management) on various information security topics, including Oracle Database Security. In addition, he has published articles on security-related topics in the ISACA Controls Journal. Raj can be contacted at [email protected].
3. Through another database (i.e., database link)
So let’s discuss the security categories and controls.
AUTHENTICATION
A password is still the primary way most systems authenticate users and other sys-tems. Weak passwords are probably the number one reason for unauthorized users (such as unauthorized employees and hack-ers) to be able to access information. Thus, stringent authentication control is neces-sary. Even if the application users are not database users, strong authentication con-trol at the database level is necessary to ensure that the Database Administrators (DBAs) and other information technology (IT) personnel (who usually have powerful privileges) do not violate the control expec-tations. User authentication at the Oracle level can be configured through creating custom profile(s) within the dba_profiles table. A profile within Oracle is a set of con-trols that can be applied to users. Different profiles can be created for different classes of accounts. For example, you may not want
to enable password expiration for system accounts but enable it for user accounts. See
Figure 2 for an example.
Some of the important authentication controls include those listed in Table 1: ■One or the other should be set —
basi-cally prevents the usage of the same pass-word over and over again.
■The PASSWORD_VERIFY_
FUNCTION is Oracle’s password com-plexity verification routine that can be enabled using a PL/SQL script “utlp-wdmg.sql”. If this script is enabled, the following password complexity verifica-tion routine is enforced:
– The password has a minimum length of 4.
– The password is not the same as the userid.
– The password has at least one alpha, one numeric, and one punctuation mark.
– The password does not match simple words like welcome, account, data-base, or user.
– The password differs from the previ-ous password by at least three letters. FIGURE 1 Data Access Methods
Web Server Database Application Database Internet Firewall (a) (c) (b)
DBAs can create their own enhanced or custom verification routines by developing new procedures or editing the utlp-wdmg.sql. However, the password
verifica-tion control will go into effect for new accounts only. Existing accounts will not be affected (or at least until the specific account’s password expires, if enabled). FIGURE 2 Creating Custom Profiles within the dba_profiles Table
TABLE 1 Recommended Values for Profile Types
Profile Type Recommended Value
FAILED_LOGIN_ATTEMPTS 3 – 5
SESSIONS_PER_USER 0 – 3
PASSWORD_LIFE_TIME 30 – 90 (in days)
PASSWORD_REUSE_TIME (1) 180 – 540 (in days)
PASSWORD_REUSE_MAX (1) 6 or more
PASSWORD_VERIFY_FUNCTION VERIFY_FUNCTION(2)
PASSWORD_LOCK_TIME 1 or more (in days)
PASSWORD_GRACE_TIME 3 – 10 (in days)
SQL> select username, password, profile, account_status from dba_users; USERNAME PASSWORD PROFILE ACCOUNT_STATUS --- -- --- ---SYS D4C5016086B2DC6A DEFAULT OPEN
SYSTEM D4DF7931AB130337 DEFAULT OPEN OUTLN 4A3BA55ED8595C81 DEFAULT OPEN DBSNMP ED66D214D5421CCC DEFAULT OPEN PO8 7E15FBACA7CDEBEC DEFAULT OPEN AURORA$ORB$UNAUTHENTICATED 80C099F0EADF877E DEFAULT OPEN SCOTT F894844C34402B67 DEFAULT OPEN DEMO MY_ACCOUNT_LK DEFAULT OPEN OPS$RMEHTA 19FD63F2F6C2772C NORMAL_USER OPEN PROD D8F098AC9321ABA7 SYSTEM_ACCT OPEN 11 rows selected.
SQL> select profile, resource_name, limit from dba_profiles; PROFILE RESOURCE_NAME LIMIT
---- --- ---DEFAULT COMPOSITE_LIMIT UNLIMITED DEFAULT FAILED_LOGIN_ATTEMPTS UNLIMITED DEFAULT SESSIONS_PER_USER UNLIMITED DEFAULT PASSWORD_LIFE_TIME UNLIMITED DEFAULT CPU_PER_SESSION UNLIMITED DEFAULT PASSWORD_REUSE_TIME UNLIMITED DEFAULT CPU_PER_CALL UNLIMITED DEFAULT PASSWORD_REUSE_MAX UNLIMITED DEFAULT LOGICAL_READS_PER_SESSION UNLIMITED DEFAULT PASSWORD_VERIFY_FUNCTION UNLIMITED DEFAULT LOGICAL_READS_PER_CALL UNLIMITED DEFAULT PASSWORD_LOCK_TIME UNLIMITED DEFAULT IDLE_TIME UNLIMITED DEFAULT PASSWORD_GRACE_TIME UNLIMITED DEFAULT CONNECT_TIME UNLIMITED DEFAULT PRIVATE_SGA UNLIMITED NORMAL_USER FAILED_LOGIN_ATTEMPTS 5 NORMAL_USER SESSIONS_PER_USER 3 NORMAL_USER PASSWORD_LIFE_TIME 90 NORMAL_USER PASSWORD_REUSE_MAX 12
NORMAL_USER PASSWORD_VERIFY_FUNCTION VERIFY_FUNCTION NORMAL_USER PRIVATE_SGA UNLIMITED SYSTEM_ACCT FAILED_LOGIN_ATTEMPTS 5 SYSTEM_ACCT SESSIONS_PER_USER UNLIMITED SYSTEM_ACCT PASSWORD_LIFE_TIME UNLIMITED SYSTEM_ACCT PASSWORD_REUSE_MAX UNLIMITED SYSTEM_ACCT PASSWORD_VERIFY_FUNCTION VERIFY_FUNCTION SYSTEM_ACCT PRIVATE_SGA UNLIMITED 28 roles selected.
Example of Locked Account (but not disabled)
Other Authentication-Related Considerations
Default Passwords. The Oracle database typically comes with a number of built-in ids and default passwords. It is imperative to change all passwords, and lock accounts that are not needed. The default accounts SYS and SYSTEM have powerful privi-leges. See the example listing of default passwords in Appendix A. One of the ways an account can be locked, yet active, is to update the password field as shown in Figure 2 for the DEMO account. This is because all valid passwords create a 16-character hexa-decimal hash value. By typing a word in this field, no password will create a matching hash and, thus, effectively the account will be locked. This is useful for system accounts that do not need to be logged on interactively.
Orapw Password File. T h e r e a r e s o m e accounts within Oracle that do not appear in the dba_users view (see Figure 2 for an example dba_users view). An example of such an account is INTERNAL. This account authenticates to an operating sys-t e m f i l e [ o r a p w &lsys-t; S I D &gsys-t; ( U N I X ) o r orapw<SID>.ora (Windows) — usually located in the $ORACLE_HOME\dbs directory3] rather than the database. The
purpose of this file is for remote users to authenticate for database administration purposes. Typically, any user that has been granted the SYSDBA or SYSOPER privi-lege will have an entry in this file along with the hashed password. It is necessary to ensure that strong passwords are selected as these accounts will have powerful privileges. In order for this password file to be utilized, the parameter REMOTE_LOGIN_ PASS-WORDFILE needs to be initialized. See the section on Oracle parameters for details. Trust Issues. The Oracle database can be set up to allow all or certain users to be authenticated through another system. Thus, Oracle would only perform the iden-tification, but trust the authentication from another system, for example, the operating
system on which the database resides. In most cases, reliance should be placed on the Oracle database authentication, unless strin-gent controls have been enabled on the trusting system. To ensure only database authentication is relied upon, the parameter value “remote_os_authent” should be set to false. See the section on Oracle parameters for details.
Encryption. The user passwords are main-tained in an encrypted format within the dba_users table (see Figure 2). However, in order to protect the passwords during the authentication process, Oracle can be con-figured to allow only encrypted passwords for client-to-server and server-to-server connections. This can be accomplished by:
■Setting the ORA_ENCRYPT_LOGIN
parameter to TRUE on the client machine
■Setting the
DBLINK_ENCRYPT_LOGIN parame-ter to TRUE on the server (see more detail under Database Links discussed later)4
AUTHORIZATION
Another important aspect of security is authorization; that is, do authenticated users have the correct level of access? The Oracle database provides the ability to enable role-based security. The following are the key tables that would help determine what access a user and/or a role has.
■dba_roles: shows the listing of all defined roles (see Table 2)
■dba_role_privs: shows which users and other roles are connected to the specific role
■dba_sys_privs: shows the system-level privileges (such as adding users, drop-ping users, altering any role, etc.) assigned to roles and/or users
■dba_tab_privs: shows the table or object permissions (such as insert, update, delete, and select) assigned to roles and/or users
■dba_col_privs: shows the column level permissions assigned to roles and/or users
Oracle can be configured to allow only encrypted passwords for client-to-server and server-to-server connections.
See Figure 3 on how the tables relate. In addition to the tables above, a number of data dictionary views are available that focus on specific items. For example, there is a view called ROLE_ROLE_PRIVS that provides a listing of nested roles. However, the same information can be generated by correlating the dba_roles and dba_role_ privs tables. See an example of a dba_sys_ privs table in Table 3.
Example key system tables to which users should not be granted any privileges include:
■SYS.AUD$ (maintains the audit trail if enabled — see details later under Moni-toring Controls)
■SYS.USER$ (maintains listing of users and roles as well as the associated pass-words in encrypted format)
■SYS.LINK$ (maintains passwords for
linked servers in cleartext)
■USER_DB_LINKS (same issue as
above)
■DBA_TAB_PRIVS
■DBA_SYS_PRIVS
Within the dba_role_privs and dba_sys_ privs, there is a field called ADMIN OPTIONS (see ADM column in Table 3). Roles and system-level privileges can be provided with an ADMIN OPTION. A grantee with the ADMIN option has several expanded capabilities.
■The grantee can grant or revoke the sys-tem privilege or role to or from any user or other role in the database (users cannot revoke a role from themselves).
■The grantee can further grant the system privilege or role with the ADMIN OPTION.
■The grantee of a role can alter or drop the role.5
FIGURE 3 How the Tables Relate
List of Roles
dba_roles
Who has been given what roles?
dba_role_privs List of Users dba_users dba_col_privs Privilege/Permission assigned to a role or individual dba_sys_privs dba_tab_privs
TABLE 2 All Defined Roles
SQL> select * from dba_roles; ROLE PASSWORD ---CONNECT NO RESOURCE NO DBA NO AP_MAINTENANCE YES AQ_USER_ROLE NO SELECT_CATALOG_ROLE NO EXECUTE_CATALOG_ROLE NO DELETE_CATALOG_ROLE NO AQ_ADMINISTRATOR_ROLE NO IMP_FULL_DATABASE NO EXP_FULL_DATABASE NO RECOVERY_CATALOG_OWNER NO JAVAIDPRIV NO SNMPAGENT NO JAVADEBUGPRIV NO JAVAUSERPRIV NO JAVASYSPRIV NO 17 rows selected.
Thus, ADMIN OPTION of YES should be limited.
Besides reviewing the access rights of users, PUBLIC permissions should be reviewed. PUBLIC is like the “Everyone” group in Windows NT: it’s the default per-mission(s) that all database users will get. The Oracle database comes with a number of default PUBLIC permissions over vari-ous objects (e.g., PUBLIC can view the USER_DB_LINKS object that can have cleartext passwords of database links). An analysis should be done for the business and technical need of such configuration. How-ever, revoking a privilege from PUBLIC can cause significant cascading effects. If any privilege related to a Data Manipulation Language (DML) operation is revoked from PUBLIC, all procedures in the database, including functions and packages, must be reauthorized before they can be used again. Therefore, exercise caution when granting DML-related privileges to PUBLIC.6
Other Authorization-Related Consideration Administrator Level Access. T h e t w o main roles that provide powerful access rights are the SYSDBA and SYSOPER privileges. These are special system roles and do not appear in the dba_roles table (see
Table 2). The SYSDBA role basically pro-vides access to all system privileges with ADMIN OPTION and SYSOPER privi-lege. The SYSOPER role allows the admin-istrator to perform operational tasks such as startup, shutdown, archive log, recover, and so on. Access to the data dictionary is restricted to the users who connect as SYS-DBA and SYSOPER.
By default the SYS account has the
SYS-DBA and SYSOPER roles. See Table 4. A
u s e r c a n c o n n e c t a s a S Y S D B A o r SYSOPER either through granting of such role (see Table 4 for an example) or by knowing the SYS password. Access to such privileges should be restricted along with the knowledge of the SYS password. One of the ways to determine who has been granted TABLE 3 dba_sys_privs Table
SQL> SELECT grantee, privilege, admin_option 2 FROM dba_sys_privs
3 WHERE (privilege = 'CREATE USER' or 4 privilege = 'CREATE ROLE' or
5 privilege = 'ALTER USER' or 6 privilege = 'ALTER ANY ROLE' or 7 privilege = 'DROP USER' or 8 privilege = 'DROP ANY ROLE' or 9 privilege = 'GRANT ANY PRIVILEGE' or 10 privilege = 'GRANT ANY ROLE')
11 ORDER BY grantee;
GRANTEE PRIVILEGE ADM -- -- ---DBA ALTER ANY ROLE YES DBA ALTER USER YES DBA CREATE ROLE YES DBA CREATE USER YES DBA DROP ANY ROLE YES DBA DROP USER YES DBA GRANT ANY PRIVILEGE YES DBA GRANT ANY ROLE YES IMP_FULL_DATABASE CREATE ROLE NO IMP_FULL_DATABASE CREATE USER NO IMP_FULL_DATABASE DROP ANY ROLE NO IMP_FULL_DATABASE DROP USER NO 12 roles selected.
the SYSDBA or SYSOPER role is by view-ing the v$pwfile_users table. See Table 4 for an example.
Also, the DBA role is provided to a num-ber of accounts by default, including the SYSTEM account (see Table 4). Thus, in order to determine the user with DBA equivalent privileges, one has to query both t h e d b a _ r o l e _ p r i v s a s w e l l a s t h e v$pwfile_users tables. As seen in the exam-ple in Table 4, although “rmehta” has SYS-DBA privilege, “rmehta” does not appear as a DBA within the dba_role_privs table.
In addition to DBA privileges, system-level privileges should be restricted based on business need only. Although there are many system type privileges (approxi-mately 115 types), the following system-level privileges (see dba_sys_privs example in Table 3) should be highly restricted:
■CREATE USER
■CREATE ROLE
■ALTER USER
■ALTER ANY ROLE
■DROP USER
■DROP ANY ROLE
■GRANT ANY PRIVILEGE
■GRANT ANY ROLE
One last consideration related to DBA access is that in larger organizations, responsibility of DBAs may be focused on
specific tasks (e.g., database tuning and per-formance). In such cases, specific roles can be developed with the necessary privileges so that DBA access can be revoked (e.g., creating a role called DBA_TUNE with privileges specific to database tuning and performance).7
DBMS_OBFUSCATION_TOOLKIT. The Oracle database provides a mechanism to encrypt selected fields within a table(s). Thus, if the payroll department needs to have SELECT access to the employee table, and you don’t want them to see the social security numbers, this tool can be used to encrypt the social security field within the employee table.
VPD (Virtual Private Database). This mechanism improves security for restricting access to information by adding security policies directly to tables. Thus, with any user query against a table or view that has a security policy associated with it, the users’ statement would be modified by adding a “where” clause. For example, if you are an ASP (Application Service Provider) that has multiple clients sharing the same data-base instance, this can help enforce certain defined rules such that one company will not be able to access information of another company even if the records are within the same table. Thus, if XYZ company performs TABLE 4 SYS Account with the SYSDBA and SYSOPER Roles
SQL> grant sysdba to rmehta; Grant succeeded.
SQL> select * from v$pwfile_users; USERNAME SYSDB SYSOP ---SYS TRUE TRUE RMEHTA TRUE FALSE
SQL> select * from dba_role_privs where granted_role = 'DBA'; GRANTEE GRANTED_ROLE ADM DEF
- - ---SYS DBA YES YES WKSYS DBA NO YES CTXSYS DBA NO YES SYSTEM DBA YES YES
a “select * from customer_table”, a “where company = XYZ” clause would be gener-ated to restrict access to the company’s record(s).8
OTHER SECURITY CONSIDERATIONS Direct Database Connections
Although most users connect through front-end applications, the possibility exists for users to connect to the database outside of application controls through ODBC-com-pliant applications (e.g., Excel, Access) and utilities such as SQL*Plus (see Figure 1b).
The risk with this capability is that users can bypass the application controls and business logic that enforce data integrity. In addition there are operational risks where inappro-priate database queries can bring down the system.
One of the ways to minimize this risk is to password protect Oracle roles. Thus even if users have access to certain data by virtue of the role they belong to, the user would need to know the password of the role. See
Table 2 for a dba_roles table that shows defined roles and whether they are pass-word protected. Thus, in the example shown in Table 2, a user will not be able to connect directly to the database and create a new vendor within the Accounts Payable (AP) system as the AP_MAINTENANCE role is password protected.
However, there are some risks of embed-ding the passwords for roles within the application. If not properly protected within the application, this can introduce new secu-rity risks. This could be an appropriate con-trol for the Oracle database that is accessed within the internal network of the corpora-tion. Other possible mitigating controls including monitoring any direct database connections.
Another control specific to controlling the usage of SQL*Plus related to the direct c o n n e c t i o n r i s k i s t o p o p u l a t e t h e Product_User_Profile table to specify what users cannot do using SQL*Plus. However, this could be an administrative burden if there are many users with differing require-ments.
Database Link
A database link provides a mechanism to connect to another instance of a database without the worry of where and how the data resides on the other database. Thus, it allows a user to access data from multiple databases as one data source. Thus, weak-nesses in one database may have an impact on the integrity of the subject database. See Figure 1c. Typically, the authenticating password for the link is hard-coded. Thus, it is important to ensure that the communica-t i o n l i n k b e communica-t w e e n communica-t h e d a communica-t a b a s e s i s encrypted. As discussed earlier, this can be enforced by ensuring the parameter value “ d b l i n k _ e n c r y p t _ l o g i n ” ( c h e c k t h e v$parameter view). To determine what database links exist, one can view the v$dblink view as well as query all the data-bases in the corporation by checking the contents of the dba_db_links and user_db_ links objects.
Oracle Listener Service
The Oracle listener service basically listens for database connection requests. It runs as a separate process and performs tasks out-side the database. The default configuration of the listener utility is no password. This can be verified by reviewing the contents of the listener.ora file. Based on personal experience, most organizations do not have this control in place in spite of published vulnerabilities associated with it. A strong password should be selected and defined in the listener.ora file. In addition, the listener utility should not be managed remotely as the password will not be encrypted over the network. The default listener port for the lis-tener service is 1521; nobody should be able to access this from the Internet. Users should be connecting to the Web applica-tion through port 80 (http) or 443 (https) and the application would connect to the data-base through port 1521.9
Oracle Parameters
A number of the Oracle parameters have been discussed in the various sections above. Oracle parameters can be viewed
A database link allows a user to access data from multiple
databases as one data source.
through the init.ora file and/or v$parameter table. Table 5 summarizes the important security related parameters.
Operating System Security
Obviously, operating system-level security is critical to adequately protect the database. Thus, operating systems should be hardened to follow good security practices. Some of the Oracle specific considerations include:
■Protect the Oracle data and control files through operating system permissions (check v$datafile and v$controlfile tables for file names and path)
■Protect the Oracle Home Directory
■Protect all the *.ora files
■Limit access to operating system level group membership of DBA group
MONITORING CONTROLS
Based on experience of Oracle database security assessments, this area is perhaps the least effectively used and understood. Monitoring security is an important element for a good security program. There are two types of security monitoring.
Audit Trails/Logging
Most of the commercial applications have some form of built-in logging features for business transactions. So the focus of this sec-tion is system-level monitoring. Logging can be achieved through enabling the Oracle audit_trail parameter. When the audit_trail parameter is enabled, the logs can be stored within the database (SYS.AUD$ table) or can be stored in the operating system audit trail file (if supported by the operating system). TABLE 5 Important Security-Related Parameters
Parameter Value/Meaning REMOTE_LOGIN_
PASSWORDFILE
NONE — ignores the password file. No privileged connections are allowed over non-secure connections.
or
EXCLUSIVE — password file can be used only for one database. Allows you to grant SYSDBA and SYSOPER system privileges to individual users and have them connect as themselves (Recommended Setting)
or
SHARED — password file can be used by multiple databases. However, the only users recognized by a SHARED password file are SYSDBA and SYSOPER; all users needing SYSDBA or SYSOPER system privileges must connect using the same name, SYS, and password
REMOTE_OS_ AUTHENT
FALSE — Rely only on database authentication (Recommended Setting) or
TRUE — Rely on remote operating system authentication DBLINK_ENCRYPT_
LOGIN
TRUE — Enforces encrypted authentication for database links
(Recommended Setting)
or
FALSE — Does not enforce encryption
AUDIT_TRAIL TRUE or DB — Logging stored within database — SYS.AUD$ table
(Recommended Setting)
or
NONE — No logging enabled or
OS — Logging stored within OS audit trail file 07_DICTIONARY_
ACCESSIBILITY
FALSE — Enforces the restriction of people with select any table privilege from selecting the data dictionary tables (Recommended Setting) or
TRUE — Does not enforce it. OS_ROLES TRUE — Rely on the OS for roles
or
FALSE — Rely only on the database for user role (Recommended Setting) REMOTE_OS_
ROLES
TRUE — Rely on the remote OS for roles or
However, for audit_trail to be an effec-tive and meaningful control, you must decide what types of activities are important to audit; that is, don’t log everything! Some of the important areas that you may want to log include:
■Connections to the database
■Changes to the database accounts
■Creation of database links
■Alter system commands
■Administrator-level user access
Thus, once the audit_trail parameter is enabled, specify the items to log. In addi-tion, you can specify the conditions of auditing the selected areas by:
■Whenever successful/whenever not
suc-cessful
■By session/by access
Oracle does provide some “canned” views of the SYS.AUD$ table by executing the CATAUDIT.sql. Examples include U S E R _ A U D I T _ T R A I L , D B A _ O B J _ A U D I T _ O P T S , a n d D B A _ A U D I T _ TRAIL.10
Also, there are events that are audited by default, whether the audit_trail is enabled or not. This includes database instance startup, shutdown, and connections to the database with administrator privileges (i.e., connect-ing as SYSDBA or SYSOPER). This log is maintained in an operating system file stored within the Oracle home directory
($ORACLE_HOME/rdbms/audit).11
If auditing is enabled, one can view the audit options enabled within the database by reviewing the dba_stmt_audit_opts view. The contents of this view are meaningless unless the audit_trail parameter has been enabled. Logging items such as creating, altering, and dropping of objects tends to generate volumes of unmeaningful informa-tion as Oracle applicainforma-tions tend to cause these as part of daily operations.
One last point on system-level logging. The audit_trail logs do not provide details on data values (e.g., before and after images of a field that may have been updated). For
such logging, database triggers should be utilized for DML statements involving crit-ical tables.
Security Vulnerability Monitoring
Besides monitoring of day-to-day system-level activities, database vulnerabilities should be assessed. Items may include:
■Password weaknesses, including default passwords
■Exploitable parameters and utilities
■Misconfigurations
There are numerous commercial as well as free tools available to perform Oracle security assessments. In addition, special SQL routines can be developed for such purposes as well.
CONCLUSION
Oracle database provides the necessary fea-tures to configure adequate and granular-level security, including strong authentica-tion, authorizaauthentica-tion, and monitoring con-trols. However, to determine what should be configured, the organization needs to docu-ment its security policy and strategy. For example, what kind of security logging should be enabled? You can configure the audit trail feature to log as much or as little as possible; the policy will help guide that process. Based on such security policy, the Oracle database baseline security standards should be documented. Finally, the data-base security should be assessed by an inde-pendent party on a periodic basis.
Notes
1. Source: http://www.oracle.com.
2. Source: http://Securityfocus.com.
3. SID is the database instance identifier. 4. Oracle8i Administrator’s Guide. 5. Oracle8i Administrator’s Guide. 6. Oracle 8i Administrator’s Guide. 7. Oracle8i Administrator’s Guide.
8. 2001, Oracle Security Handbook, by Marlene Theriault and Aaron C. Newman.
9. 2001, Oracle Security Handbook, by Marlene Theriault and Aaron C. Newman.
10. Oracle8i Administrator’s Guide.
11. March 2003, Guide to Auditing in Oracle
Appli-cations by Integrigy Corporation.
For audit_trail to be an effective and meaningful control, you must decide what types of activities are important to audit; that is, don’t log everything!
APPENDIX A
This appendix provides a listing of known default passwords and its hashes. Not all databases will have all these accounts. It will depend on the Oracle version as well as applications utilized by the specific organization.
Account Name Default Password Password Hash
ADAMS WOOD 72CDEF4A3483F60D
ADLDEMO ADLDEMO 147215F51929A6E8
APPLSYS FND 0F886772980B8C79
APPLYSYSPUB PUB A5E09E84EC486FC9
APPS APPS D728438E8A5925E0
AQ AQ 2B0C31040A1CFB48
AQDEMO AQDEMO 5140E342712061DD
AQJAVA AQJAVA 8765D2543274B42E
AQUSER AQUSER 4CF13BDAC1D7511C
AUDIOUSER AUDIOUSER CB4F2CEC5A352488
AURORA$JIS$UTILITY$ INVALID E1BAE6D95AA95F1E
AURORA$ORB$UNAUTHENTICATED INVALID 80C099F0EADF877E
BC4J BC4J EAA333E83BF2810D
BLAKE PAPER 9435F2E60569158E
CATALOG CATALOG 397129246919E8DA
CDEMO82 CDEMO83 67B891F114BE3AEB
CDEMOCOR CDEMOCOR 3A34F0B26B951F3F
CDEMORID CDEMORID E39CEFE64B73B308
CDEMOUCB CDEMOUCB CEAE780F25D556F8
CENTRA CENTRA 63BF5FFE5E3EA16D
CIDS CIDS AA71234EF06CE6B3
CIS ZWERG AA2602921607EE84
CISINFO ZWERG BEA52A368C31B86F
CLARK CLOTH 7AAFE7D01511D73F
COMPANY COMPANY 402B659C15EAF6CB
COMPIERE COMPIERE E3D0DCF4B4DBE626
CQSCHEMAUSER PASSWORD 04071E7EDEB2F5CC
CSMIG CSMIG 09B4BB013FBD0D65
CTXDEMO CTXDEMO CB6B5E9D9672FE89
CTXSYS CTXSYS 24ABAB8B06281B4C
DBI MUMBLEFRATZ D8FF6ECEF4C50809
DBSNMP DBSNMP E066D214D5421CCC
DEMO DEMO 4646116A123897CF
DEMO8 DEMO8 0E7260738FDFD678
DEMO9 DEMO9 EE02531A80D998CA
DES DES ABFEC5AC2274E54D
EJSADMIN EJSADMIN_PASSWORD 313F9DFD92922CD2
EMP EMP B40C23C6E2B4EA3D
ESTOREUSER ESTORE 51063C47AC2628D4
EVENT EVENT 7CA0A42DA768F96D
FINANCE FINANCE 6CBBF17292A1B9AA
FND FND 0C0832F8B6897321
FROSTY SNOWMAN 2ED539F71B4AA697
GPFD GPFD BA787E988F8BC424
GPLD GPLD 9D561E4D6585824B
HCPARK HCPARK 3DE1EBA32154C56B
HLW HLW 855296220C095810
HR HR 4C6D73C3E8B0F0DA
IMAGEUSER IMAGEUSER E079BF5E433F0B89
IMEDIA IMEDIA 8FB1DC9A6F8CE827
JMUSER JMUSER 063BA85BF749DF8E
JONES STEEL B9E99443032F059D
LBACSYS LBACSYS AC9700FD3F1410EB
LIBRARIAN SHELVES 11E0654A7068559C
MASTER PASSWORD 9C4F452058285A74
MDSYS MDSYS 72979A94BAD2AF80
MFG MFG FC1B0DD35E790847
MIGRATE MIGRATE 5A88CE52084E9700
Account Name Default Password Password Hash
MMO2 MMO3 A0E2085176E05C85
MODTEST YES BBFF58334CDEF86D
MOREAU MOREAU CF5A081E7585936B
MTS_USER MTS_PASSWORD E462DB4671A51CD4
MTSSYS MTSSYS 6465913FF5FF1831
MXAGENT MXAGENT C5F0512A64EB0E7F
NAMES NAMES 9B95D28A979CC5C4
OAS_PUBLIC OAS_PUBLIC A8116DB6E84FA95D
OCITEST OCITEST C09011CB0205B347
ODS ODS 89804494ADFC71BC
ODSCOMMON ODSCOMMON 59BBED977430C1A8
OE OE D1A2DFC623FDA40A
OEMADM OEMADM 9DCE98CCF541AAE6
OLAPDBA OLAPDBA 1AF71599EDACFB00
OLAPSVR INSTANCE AF52CFD036E8F425
OLAPSYS MANAGER 3FB8EF9DB538647C
OMWB_EMULATION ORACLE 54A85D2A0AB8D865
OPENSPIRIT OPENSPIRIT D664AAB21CE86FD2
ORACACHE ORACACHE 5A4EEC421DE68DDD
ORAREGSYS ORAREGSYS 28D778112C63CB15
ORDPLUGINS ORDPLUGINS 88A2B2C183431F00
ORDSYS ORDSYS 7EFA02EC7EA6B86F
ORACLE ORACLE 38E38619A12E0257
OSE$HTTP$ADMIN INVALID 05327CD9F6114E21
OSP22 OSP22 C04057049DF974C2
OUTLN OUTLN 4A3BA55E08595C81
OWA OWA CA5D67CD878AFC49
OWA_PUBLIC OWA_PUBLIC 0D9EC1D1F2A37657
PANAMA PANAMA 3E7B4116043BEAFF
PATROL PATROL 0478B8F047DECC65
PERFSTAT PERFSTAT AC98877DE1297365
PLSQL SUPERSECRET C4522E109BCF69D0
PM PM C7A235E6D2AF6018
PO PO 355CBEC355C10FEF
PO7 PO7 6B870AF28F711204
PO8 PO8 7E15FBACA7CDEBEC
PORTAL30 PORTAL31 D373ABE86992BE68
PORTAL30_DEMO PORTAL30_DEMO CFD1302A7F832068
PORTAL30_PUBLIC PORTAL30_PUBLIC 42068201613CA6E2
PORTAL30_SSO PORTAL30_SSO 882B80B587FCDBC8
PORTAL30_SSO_PS PORTAL30_SSO_PS F2C3DC8003BC90F8
PORTAL30_SSO_PUBLIC PORTAL30_SSO_PUBLIC 98741BDA2AC7FFB2
POWERCARTUSER POWERCARTUSER 2C5ECE3BEC35CE69
PRIMARY PRIMARY 70C3248DFFB90152
PUBSUB PUBSUB 80294AE45A46E77B
QS QS 4603BCD2744BDE4F
QS_ADM QS_ADM 3990FB418162F2A0
QS_CB QS_CB 870C36D8E6CD7CF5
QS_CBADM QS_CBADM 20E788F9D4F1D92C
QS_CS QS_CS 2CA6D0FC25128CF3
QS_ES QS_ES 9A5F2D9F5D1A9EF4
QS_OS QS_OS 0EF5997DC2638A61
QS_WS QS_WS 0447F2F756B4F460
RE RE 933B9A9475E882A6
REP_MANAGER DEMO 2D4B13A8416073A1
REP_OWNER DEMO 88D8F06915B1FE30
REP_OWNER REP_OWNER BD99EC2DD84E3B5C
REPADMIN REPADMIN 915C93F34954F5F8
RMAIL RMAIL DA4435BBF8CAE54C
RMAN RMAN E7B5D92911C831E1
SAMPLE SAMPLE E74B15A3F7A19CA8
SAP SAPR3 BEAA1036A464F9F
SCOTT TIGER F894844C34402B67
SDOS_ICSAP SDOS_ICSAP C789210ACC24DA16
Account Name Default Password Password Hash
SH SH 54B253CBBAAA8C48
SITEMINDER SITEMINDER 061354246A45BBAB
SLIDE SLIDEPW FDFE8B904875643D
STARTER STARTER 6658C384B8D63B0A
STRAT_USER STRAT_PASSWD AEBEDBB4EFB5225B
SWPRO SWPRO 4CB05AA42D8E3A47
SWUSER SWUSER 783E58C29D2FC7E1
SYMPA SYMPA E7683741B91AF226
SYS CHANGE_ON_INSTALL D4C5016086B2DC6A
SYSADM SYSADM BA3E855E93B5B9B0
SYSMAN OEM_TEMP 639C32A115D2CA57
SYSTEM MANAGER D4DF7931AB130E37
TAHITI TAHITI F339612C73D27861
TDOS_ICSAP TDOS_ICSAP 7C0900F751723768
TESTPILOT TESTPILOT DE5B73C964C7B67D
TRACESVR TRACE F9DA8977092B7B81
TRAVEL TRAVEL 97FD0AE6DFF0F5FE
TSDEV TSDEV 29268859446F5A8C
TSUSER TSUSER 90C4F894E2972F08
TURBINE TURBINE 76F373437F33F347
ULTIMATE ULTIMATE 4C3F880EFA364016
USER USER 74085BE8A9CF16B4
USER0 USER0 8A0760E2710AB0B4
USER1 USER1 BBE7786A584F9103
USER2 USER2 1718E5DBB8F89784
USER3 USER3 94152F9F5B35B103
USER4 USER4 2907B1BFA9DA5091
USER5 USER5 6E97FCEA92BAA4CB
USER6 USER6 F73E1A76B1E57F3D
USER7 USER7 3E9C94488C1A3908
USER8 USER8 D148049C2780B869
USER9 USER9 0487AFEE55ECEE66
UTLBSTATU UTLESTAT C42D1FA3231AB025
VIDEOUSER VIDEOUSER 29ECA1F239B0F7DF
VIF_DEVELOPER VIF_DEV_PWD 9A7DCB0C1D84C488
VIRUSER VIRUSER 404B03707BF5CEA3
VRR1 VRR2 3D703795F61E3A9A
WEBCAL01 WEBCAL01 C69573E9DEC14D50
WEBDB WEBDB D4C4DCDD41B05A5D
WEBREAD WEBREAD F8841A7B16302DE6
WKSYS WKSYS 545E13456B7DDEA0
WWW WWW 6DE993A60BC8DBBF
WWWUSER WWWUSER F239A50072154BAC
