Information Systems Audit and Control Association

www.isaca.org

Oracle Database Security, Audit and Control Features

Audit Program and Internal Control Questionnaire
Information Systems Audit and Control Association

With more than 35,000 members in more than 100 countries, the Information Systems Audit and Control Association (ISACA) (www.isaca.org) is a recognized worldwide leader in IT governance, control, security and assurance. Founded in 1969, ISACA sponsors international conferences, publishes the Information Systems Control Journal, develops international information systems auditing and control standards, and administers the globally respected Certified Information Systems Auditor (CISA ) designation earned by more than 35,000 professionals since inception, and Certified Information Security Manager (CISM) designation, a groundbreaking credential earned by 5,000 professionals in its first two years.

IT Governance Institute
The IT Governance Institute (ITGI) (www.itgi.org) was established in 1998 to advance international thinking and standards in directing and controlling an enterprises information technology. Effective IT governance helps ensure that IT supports business goals, optimizes business investment in IT, and appropriately manages IT-related risks and opportunities. The IT Governance Institute offers symposia, original research and case studies to assist enterprise leaders and boards of directors in their IT governance responsibilities.

Purpose of Audit Programs and Internal Control Questionnaires

One of ISACAs goals is to ensure that educational products support member and industry information needs. Responding to member requests for useful audit programs, ISACAs Education Board has released audit programs and internal control questionnaires, for member use through K-NET. These products are developed from ITGI publications, or provided by practitioners in the field.

Control Objectives for Information and related Technology

Control Objectives for Information and related Technology (COBIT) has been developed as a generally applicable and accepted standard for good information technology (IT) security and control practices that provides a reference framework for management, users, and IS audit, control and security practitioners. The audit programs included in K-NET have been referenced to key COBIT control objectives.

Disclaimer
ITGI, ISACA and the author of this document have designed the publication primarily as an educational resource for control professionals. ISACA makes no claim that use of this product will assure a successful outcome. The publication should not be considered inclusive of any proper procedures and tests or exclusive of other procedures and tests that are reasonably directed to obtaining the same results. In determining the propriety of any specific procedure or test, the controls professional should apply his/her own professional judgment to the specific control circumstances presented by the particular systems or information technology environment. Users are cautioned not to consider these audit programs and internal control questionnaires to be allinclusive or applicable to all organizations. They should be used as a starting point to build upon based on an organizations constraints, policies, practices and operational environment.

Oracle Database Security, Audit and Control Features Audit Plan and ICQ
Audit Plan
The purpose of this audit plan is to provide the audit, control and security professional with a methodology for evaluating the subject matter of the IT Governance Institute publication Oracle Database Security, Audit and Control Features. It examines key issues and components that need to be considered for this topic. The audit plan been developed and reviewed with regard to COBIT. Note: The professional should customize the audit plan to define each specific organizations constraints, policies and practices.
Control Objective/Test Documentation/ Matters Arising COBIT

A. Prior Audit/Examination Report Follow-up Review prior report, if one exists, and verify completion of any agreed upon corrections. Note remaining deficiencies. B. Preliminary Audit Steps Gain an understanding of the Oracle Database environment. a) Obtain the following important information about the Oracle Database environment: Version and release of the Oracle Database software and related tools (Oracle Enterprise Manager, Oracle Advanced Security Option, etc.) that are implemented Version and release of the underlying operating system Total number of named users (for comparison with logical access security testing results) Number of database instances Applications and related versions accessing the database (e.g., ERP, web, custom) Utilities used to logon and manage the database Details of the risk assessment approach taken in the organization to identify and prioritize risks Copies of the organizations key security policies and standards Organization charts identifying system owners and maintainers Outstanding audit findings, if any, from previous years

M1

PO2 PO3 PO4 PO6 PO9 DS2 DS5 AI2 AI6 M1 M2 M4

Control Objective/Test

Documentation/ Matters Arising

COBIT

b) Interview database administrators (DBA) to determine the following: The level of overall security awareness and knowledge of corporate policies and procedures The skillset of the DBAs and the training programs in place to keep their technical skills up-todate Current processes and tools in place to maintain the security of the database Identify the significant risks and determine the key controls. c) Develop a high-level system architecture and overall understanding of the system environment including the following: Key applications accessing the database Interfaces Trust relationships Underlying operating system Tools (change control, scheduling, backup, etc.) d) Assess the key risks, determine key controls or control weaknesses and test controls (refer to the following sample testing program for testing configurable controls and logical access security) having regard to the following factors: The controls culture of the organization (e.g., a justenough-control philosophy) The need to exercise judgement to determine the key controls in the process and whether the controls structure is adequate (Any weaknesses in the control structure should be reported to executive management and resolved.) C. Detailed Audit Steps 1. Patch Management 1.1 Security patches are applied in a timely manner. 1.1.1 Determine if the database version is current and supported by reviewing the result of the following query and comparing the version to current versions supported by Oracle: SELECT * FROM V$VERSION; 1.1.2 Discuss with the database and system administrators the process for reviewing and applying database, application and operating system patches. 1.1.3 Verify the number of database instances installed by obtaining the init<SID>.ora files under the

DS5 DS9 AI4 DS2

AI1 PO9 DS13

DS5 DS9 PO9 M2

AI2 AI6 DS5 DS9 DS10

Control Objective/Test

Documentation/ Matters Arising

COBIT

$ORACLE_HOME directory. 1.1.4 Determine how DBAs monitor and are notified of new patches. 1.1.5 Review change control procedures to ensure that all database updates and patches are adequately tested before being applied to production environments. 2. Security Monitoring 2.1 Processes are in place to regularly monitor security on the system. 2.1.1 Discuss with the DBAs their processes for monitoring key database functions and security-related events to determine if system activity is regularly monitored. Obtain from the DBAs any reports or queries that are used to monitor the system. 2.1.2 Discuss with the DBAs the level of auditing that is performed on users actions. Review the setting for the AUDIT_TRAIL parameter in the init<SID>.ora file to determine if auditing is enabled. 2.1.3 Review the retention policy on audit trails and logs. 2.1.4 Discuss with the DBAs procedures for monitoring sensitive accounts and privileges. Review the output of the following query to determine if updates made by the DBAs account are monitored: SELECT * FROM SYS.DBA_STMT_AUDIT_OPTS; 2.1.5 Review the output of the following query to determine auditing in place for all system-level privileges: SELECT * FROM DBA_PRIV_AUDIT_OPTS; 2.1.6 Review the output of the following query to determine if statement-level auditing is enabled: SELECT * FROM DBA_STMT_AUDIT_OPTS; 2.1.7 Review the output of the following query to determine auditing in place for database objects: SELECT * FROM DBA_OBJ_AUDIT_OPTS; 2.1.8 Discuss with the DBA where audit trails are stored and how that location is secured from tampering. 2.1.9 Discuss with the DBA the process for monitoring errors in the alert log and the process for monitoring the creation of trace files. 2.1.10 Determine the procedures used for reviewing inactive profiles. Verify the process by reviewing the last login dates of a user list to determine if any accounts have been inactive for more than 60 days or the maximum required by corporate policy. 2.1.11 Review the process for monitoring unexpected database startups and shutdowns.

DS5 DS11 DS12 M4 DS1 M1

Control Objective/Test

Documentation/ Matters Arising

COBIT

2.1.12 Obtain a list of triggers in the database and discuss with the DBA how they are used to monitor the database. 2.1.13 Obtain any service level agreements and support contracts for the database. Review the service level agreements to ensure that the following requirements are in place: Vendor must maintain documentation for the secure configuration of the system Vendor must actively monitor systems for security violations and report the violations to the organization Vendor must test and load security patches within one week of the patch release and immediately for high risk security issues Vendor must maintain system uptime as defined by business requirements 3. Operating System Security 3.1 The underlying operating system is secured and key database files are protected. 3.1.1 Discuss with the operating system and database administrators the steps that are taken and the controls that are implemented to ensure that the operating system is secured. 3.1.2 Discuss with the DBA the passwords used for the operating system account(s) that owns the files for each instance. Each instance should use a unique account and password. 3.1.3 Review file permissions on key database files. 3.1.4 Review file permissions on scripts that contain. database accounts and passwords. 3.1.5 Perform a vulnerability scan of the operating system to identify any vulnerabilities. 4. Physical Security 4.1 Controls are in place to physically protect the database 4.1.1 Tour the data center and identify the location of key database systems. Ensure that the systems are stored in a secure environment and that password-protected screen savers are in place. 4.1.2 Review documented disaster recovery procedures and confirm that they are tested on a regular basis. 4.1.3 Inquire about the processes for securing and storing tape backups. 4.1.4 Review database log mode to determine if the database needs to be recoverable to a point in time, and ensure that the backup strategy is sufficient to meet this

DS3 DS5 PO11 M1

DS4 DS5

Control Objective/Test

Documentation/ Matters Arising

COBIT

requirement. 4.1.5 Review the processes for disposal of damaged or obsolete equipment. 4.1.6 Verify the database is connected to an uninterruptible power supply that will sustain availability long enough to meet business requirements 5. Logical Security 5.1 Appropriate account and password controls in place 5.1.1 Discuss with the DBA procedures used to log onto the system. Ensure that DBA does not use the CONNECT INTERNAL option to connect to the database. Ensure that each DBA uses a unique account to log on and administer the database. 5.1.2 Obtain a list of users by executing the following command: SELECT * FROM DBA_USERS; 5.1.3 Obtain the settings for the default profile (obtain settings for customized profiles if they are used): SELECT * FROM DBA_PROFILES; 5.1.4 Review the list of users to ensure that generic accounts are not used (e.g., test, guest or shared accounts). 5.1.5 Review the list to ensure that default accounts and passwords are not used. Verify this by attempting to log onto the database using the default accounts and passwords. 5.1.6 Review the list of users to ensure that profiles are appropriately assigned to accounts. 5.1.7 Review the list of users to ensure that profiles are appropriately assigned to accounts. 5.1.8 Review the following profile settings to ensure that password controls and resource limits are in place: COMPOSITE_LIMIT SESSIONS_PER_USER CPU_PER_SESSION CPU_PER_CALL LOGICAL_READS_PER_SESSION LOGICAL_READS_PER_CALL IDLE_TIME PRIVATE_SGA CONNECT_TIME FAILED_LOGIN_ATTEMPTS PASSWORD_LIFE_TIME PASSWORD_REUSE_TIME PASSWORD_REUSE_MAX

DS5 PO1 PO6 PO4 AI4 DS3

Control Objective/Test

Documentation/ Matters Arising

COBIT

5.1.9

PASSWORD_VERIFY_FUNCTION PASSWORD_LOCK_TIME PASSWORD_GRACE_TIME Discuss with the DBA the processes for obtaining emergency access to the database. Ensure that procedures are in place to establish access for emergency situations, document each occurrence when emergency access is used, and terminate access after the business issue is resolved.

5.1.10 Determine if operating system security is used by reviewing REMOTE_OS_AUTHENT parameter in the init<sid>.ora file. The REMOTE_OS_AUTHENT parameter should be set to false. If it is used, discuss the business requirements with the DBA. 5.1.11 If operating system authentication is used, review the OS_AUTHENT_PREFIX parameter in the init<sid>.ora file to determine the prefix for accounts authentication by the operating system. Review user accounts to determine users that are authenticated externally by the operating system (typically preceded with OPS$) or external password file. Discuss with the DBA the business requirements for this type of authentication. Review the output of the following query to identify users that authenticate via an external password file: SELECT * FROM V$PWFILE_USERS; 5.1.12 Discuss with the DBA processes in place to grant and terminate access for vendors, contractors and consultants. Ensure that access is only granted where necessary and is commensurate with job responsibilities. Ensure that access is also terminated in a timely manner 5.2 Users are restricted to information required to perform their job responsibilities. 5.2.1.1 Review processes for granting and terminating access to users within the database. 5.2.1.2 Obtain a list of users on the system by executing the following command: SELECT * FROM DBA_USERS; 5.2.1.3 Obtain a current list of roles defined in the system by executing the following command: SELECT * FROM DBA_ROLE_PRIVS; 5.2.1.4 Obtain a list of users with their assigned roles by executing the following command: a 5.2.1.5 Select a sample of user access requests and determine

DS5 DS6 DS7 DS9 DS11 PO2 PO4

Control Objective/Test

Documentation/ Matters Arising

COBIT

that access is approved by the appropriate business/system owners and whether access is commensurate with each users job responsibilities. 5.2.1.6 Compare the approved access requests to the roles assigned to users to ensure that roles are appropriately assigned. 5.2.1.7 Review the following views to determine the roles and privileges assigned to a sample of users. Ensure that the users access is commensurate with their job responsibilities (pay close attention to privileges that are assigned directly to users rather than roles): DBA_SYS_PRIVS view ROLE_PRIVS view ROLE_ROLE_PRIVS view ROLE_TAB_PRIVS view 5.2.1.8 Obtain a list of terminated employees from HR. Compare the terminated employee list to the list of users on the system to ensure that accounts are terminated in a timely manner. 5.2.1.9 Ensure that users do not have access to the ALL_SOURCE view by reviewing the results of the following command: SELECT * FROM SYS.DBA_TAB_PRIVSWHERE TABLE_NAME = ALL_SOURCE; 5.2.1.10 Review any roles and/or user accounts that are assigned INSERT, UPDATE or DELETE privileges. Discuss the business requirements for this type of access with the database administrator. 5.2.1.11 Review accounts that are assigned highprivilege roles such as DBA. Discuss the business requirement for this type of access with the database administrator. 5.2.1.12 Determine whether roles are created with the WITH ADMIN option only when necessary to meet clearly defined business requirements. Review the output of the following command to identify roles created with the WITH ADMIN option: SELECT * FROM SYS.DBA_ROLE_PRIVSWHERE ADMIN_OPTION = YES; 5.2.1.13 Determine if any privileges have been assigned to the public account by reviewing the output of the following query: SELECT OWNER, TABLE_NAME, GRANTOR, PRIVILEGEFROM SYS.DBA_TAB_PRIVSWHERE GRANTEE =

Control Objective/Test

Documentation/ Matters Arising

COBIT

PUBLICAND GRANTOR <>SYS; AND GRANTOR <> SYSTEM;SELECT GRANTED_ROLE FROM SYS.DBA_ROLE_PRIVSWHERE GRANTEE = PUBLIC; 5.2.1.14 Review privileges assigned to users and roles. Discuss with the DBA any privileges directly assigned to users rather than roles. Execute the following queries to review list of object and system privileges: SELECT * FROM SYS.DBA_TAB_PRIVS; SELECT * FROM SYS.DBA_SYS_PRIVS; 5.2.1.15 Ensure that SYS or SYSTEM own all objects in the SYSTEM tables. 5.2.1.16 Review the security over access to the Data Dictionary. Review the setting of the O7_DICTIONARY_ACCESSIBILITY parameter by issuing the query SELECT NAME, VALUE FROM SYS.V_$PARAMETER WHERE NAME = O7_DICTIONARY_ACCESSIBILITY; If this is set to true, review the users that have been granted the SELECT ANY TABLE privilege, as all of these tables can view the information in the Data Dictionary. 5.2.1.17 Review the results of the following query to identify any privileges that are assigned with the GRANT option. Discuss any of these privileges with the DBA: SELECT * FROM SYS.DBA_TAB_PRIVS WHERE GRANTABLE = YES; 6. Backup and Recovery 6.1 A backup and recovery strategy exists and is tested. 6.1.1.1 Discuss with the DBA the strategy for backup and recovery of the database. Confirm with the DBA that the strategy is tested on a regular basis. Review procedure documents and discuss results of the most recent test. 6.1.1.2 Obtain a copy of the init<SID>. ora file. 6.1.1.3 Review the LOG_ARCHIVE_START parameter. If it is set to true, ARCHIVELOG mode is enabled. Review the LOG_ARCHIVE_DEST and the LOG_ARCHIVE_FORMAT parameters to determine the location and naming convention of the log files. 6.1.1.4 Discuss with the DBA procedures for regularly

DS4 DS13

Control Objective/Test

Documentation/ Matters Arising

COBIT

archiving redo logs to offline media. Determine procedures for securely protecting and disposing of offline media. 6.1.1.5 Review the CONTROL_FILES = <PATH> parameter to determine where the control files are stored. Determine how many control files exist and ensure that files are protected. 7. Encryption 7.1 An encryption strategy exists and is implemented to protect confidential information where appropriate. 7.1.1 Discuss with the DBA the use of encryption within the DS5 database. Determine if a third-party package or the DS9 native DBMS_OBFUSCATION_TOOLKIT is used to DS11 implement encryption. 7.1.2 Review the companys data classification standards and requirements for encryption. 7.1.3 Discuss with the DBA application and database development standards in place to use encryption to protect information in the database. 7.1.4 If encryption is required by the company, review a sample of records that contain sensitive information to ensure that the information is encrypted. 8. Trusted Relationships 8.1 Trusted Relationships are restricted and protected. 8.1.1 Discuss with the DBA of any database links used DS5 within the database. Discuss with the DBA the business purpose for the links and gather information about the use and purpose of all trusted databases. Determine if private or public links are used. 8.1.2 If a database link exists review the DBLINK_ENCRYPT_LOGIN parameter in the init.ora file. If it is set to true, encryption is enabled. 8.1.3 Review the SYS.LINK$ table with the query SELECT * FROM SYS.LINK$; confirm that plain text passwords are not visible. 9. Network Security 9.1 Controls are in place to protect database information communicated over a network. 9.1.1 Review a network architecture diagram that depicts the DS5 logical relationship between the database and other DS10 systems and networks within the organization. Ensure M1 that the database is protected by a firewall from any third party or Internet access points. 9.1.2 Discuss with the DBA the use of Oracles Advanced

Control Objective/Test

Documentation/ Matters Arising

COBIT

Security Option (ASO) product. If ASO is implemented, discuss with the DBA how the product is implemented and maintained. 9.1.3 Discuss with the DBA procedures for applying the latest patches to the listener file. Ensure that the latest patches are applied. 9.1.4 Obtain a copy of the listener.ora file and review the following: The default port number for the database is changed. The PASSWORD_LISTENER parameter is set to a strong password. The ADMIN_RESTRICTIONS_listener_name is set to on. 9.1.5 Obtain a copy of the protocol.ora (Oracle Net configuration file) file. The following parameters must be set to the corresponding values to enable Valid Node Checking: tcp.validnode_checking = YES tcp.excluded_nodes = {list of IP addresses} tcp.invited_nodes = {list of IP addresses}

Internal Control Questionnaire (ICQ)

The purpose of this internal control questionnaire is to provide the audit, control and security professional with a methodology for evaluating the subject matter of the IT Governance Institute publication Oracle Database Security, Audit and Control Features. It examines key issues and components that need to be considered for this topic. The review questions have been developed and reviewed with regard to COBIT. Note: The professional should customize the internal control questionnaire to define each specific organizations constraints, policies and practices.
Control Objectives/Questions Response
Yes No N/A

Comments

COBIT References

1. Patch Management 1.1 Security patches are applied in a timely manner. 1.1.2 Is there a process for staying informed about security patches and applying the patches in a timely manner? 1.1.3 Is there a change control process in place used to ensure that only tested and approved changes are applied to production environments? 2. Security Monitoring 2.1 Processes are in place to regularly monitor security on the system. 2.1.1 Are key database functions and security related events regularly monitored? 2.1.2 Are audit logs regularly reviewed? Do audit records and log information comply with the companys data retention policy? 2.1.3 Are sensitive accounts and privileges monitored? 2.1.4 Are the audit records secured? Is access to the audit records restricted? 2.1.5 Is there a process for monitoring errors in the alert log and monitoring the creation of trace files? 2.1.6 Are there procedures for regularly reviewing inactive users? 2.1.7 Are unexpected startup and shutdown occurrences of the database regularly reviewed? 2.1.8 Are clear security requirements built into service level agreements and support contracts for the database? Is security involved in approving the terms and conditions outlined in the agreements? 2.1.9 Are database triggers used to monitor the database?

DS5 DS10 DS11 DS5

DS5 M1 DS5 M1 DS5 DS5 DS5 DS11 DS5 DS2 DS5 DS5

DS5

Control Objectives/Questions

Response
Yes No N/A

Comments

3. Operating System Security 3.1 The underlying operating system is secured and key database files are protected. 3.1.1 Are there procedures in place to ensure that the underlying operating system is secured? 3.1.2 Are file permissions on key database files reviewed? Are there clear standards for setting appropriate file permissions? 3.1.3 Are database authentication credentials stored in batch files or scripts in plaintext? 3.1.4 Are operating system vulnerability scans conducted? 4. Physical Security 4.1 Controls are in place to physically control the database. 4.1.1 Are physical controls in place to protect database systems? 4.1.2 Are password protected screen savers in place on server terminals? 4.1.3 Is there a documented disaster recovery plan in place that is regularly tested? 4.1.4 Are backup tapes secured and stored? 4.1.5 Is there a clear database backup strategy? 4.1.6 Is there a process for disposing of damaged or obsolete equipment? 5. Logical Security 5.1 Appropriate account and password controls in place. 5.1.1 Does each DBA have a unique account on the database? 5.1.2 Are there procedures in place to change default passwords? 5.1.3 Are customized profiles other than DEFAULT used? 5.1.4 Are generic or test accounts used? 5.1.5 Is there a process for establishing new accounts and communicating the initial password to the user? 5.1.6 Are profiles appropriately assigned to accounts? 5.1.7 Is there a process for emergency access to the database?

COBIT References

DS5 AI4 AI5 DS3 DS5 DS5 M1 DS5 DS5 DS12 DS5 DS4 DS5 AI4 DS5 AI4 DS4 DS5 DS4 DS5 DS5 DS3 AI4 DS5 PO2 DS5 DS5 DS5 DS5 DS5 DS10

Control Objectives/Questions

Response
Yes No N/A

Comments

5.1.8 Are appropriate profile settings in place to enforce password and resource usage controls? 5.1.9 Are there users who are authenticated externally by the operating system? Is there a valid and documented business requirement for this type of access? 5.1.10 Are there procedures for managing vendor access to the database? 5.2 Users are restricted to information required to perform their job responsibilities. 5.2.1 Is there a process in place for granting and terminating user access to the database? 5.2.2 Is the list of active users reviewed on a regular basis? 5.2.3 Is the list of active roles reviewed on a regular basis? 5.2.4 Is role membership reviewed on a regular basis? 5.2.5 Are accounts with high-privilege access (e.g., DBA) regularly reviewed? 5.2.6 Do SYS and SYSTEM own all objects in the SYSTEM tables? 5.2.7 Is access to the Data Dictionary protected? 5.2.8 Do any users have access to the ALL_SOURCE view? What is the business requirement for this type of access? 5.2.9 Are any users assigned the INSERT, UPDATE, or DELETE privileges? What is the business requirement for this type of access? 5.2.10 Are users created with the WITH ADMIN option? What is the business requirement for this type of access? 5.2.11 Does the special account, public, have any privileges assigned to it? 5.2.12 Are any privileges, rather than roles, assigned directly to users? 5.2.13 Are any privileges assigned with the GRANT option? 6. Backup and Recovery 6.1 A backup and recovery strategy exists and is tested. 6.1.1 Is there a clear strategy for backup and recovery of the database?

COBIT References

DS5 DS9

DS5 DS10 DS1 DS2 DS5 DS5 DS11 PO4 DS11 DS11 M1 PO9 DS11 DS9 DS5 PO1 DS5 PO9 PO1 DS5 DS5 DS5 PO4 PO9 DS5

DS4 DS13

Control Objectives/Questions

Response
Yes No N/A

Comments

6.1.2 Are database logs archived? 6.1.3 Are control files protected and backed up?

COBIT References

DS11 DS13 DS4 DS13

7. Encryption 7.1 An encryption strategy exists and is implemented to protect confidential information where appropriate. 7.1.1 Is encryption used to protect confidential PO1 information in the database? DS5 AI1 7.1.2 Are there standards in place for developing PO1 applications that use database utilities to PO6 encrypt data? AI1 AI2 8. Trusted Relationships 8.1 Trusted Relationships are restricted and protected. 8.1.1 Are database links used within the database? DS5 Are the links private or public? AI3 8.1.2 Are the database links encrypted? DS5 9. Network Security 9.1 Controls are in place to protect database information communicated over a network. 9.1.1 Is the database system accessible from any PO4 applications, systems or users on the Internet AI5 or third-party networks? If the system is DS2 accessible from these networks, is it DS5 adequately protected by a firewall and intrusion detection system? 9.1.2 Is Oracle Advanced Security Option (ASO) AI5 implemented in the environment? If ASO is DS3 implemented, how is it deployed in the DS5 environment? 9.1.3 Is the Oracle Listener service protected with AI3 a password? DS5 9.1.4 Are the latest patches applied to the Listener? DS5 DS13