Auditoria Oracle

Information Systems Audit and Control Associationwww.isaca.org

Oracle DatabaseSecurity, Audit and Control Features

Audit Programand

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 enterprise’s 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 QuestionnairesOne of ISACA’s goals is to ensure that educational products support member and industry information needs. Responding to member requests for useful audit programs, ISACA’s 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 TechnologyControl 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.

DisclaimerITGI, 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 all-inclusive or applicable to all organizations. They should be used as a starting point to build upon based on an organization’s constraints, policies, practices and operational environment.

http://www.isaca.org/cobit

http://www.itgi.org/

http://www.isaca.org/Content/NavigationMenu/About_ISACA/Overview_and_History/Overview_and_History.htm

Oracle Database Security, Audit and Control Features Audit Plan and ICQ

Audit PlanThe 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 organization’s constraints, policies and practices.

Control Objective/TestDocumentation/Matters Arising

COBIT References

A. Prior Audit/Examination Report Follow-upReview prior report, if one exists, and verify completion of any agreed upon corrections. Note remaining deficiencies.

M1

B. Preliminary Audit StepsGain 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 organization’s key security policies and

standards Organization charts identifying system owners and

maintainers Outstanding audit findings, if any, from previous years

PO2PO3PO4PO6PO9DS2DS5AI2AI6M1M2M4


COBIT References

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-to-date Current processes and tools in place to maintain the

security of the database

DS5DS9AI4DS2

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

AI1PO9DS13

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 just-

enough-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.)

DS5DS9PO9M2

C. Detailed Audit Steps1. Patch Management1.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;

AI2AI6DS5DS9DS10

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 $ORACLE_HOME directory.

1.1.4 Determine how DBAs monitor and are notified of new


COBIT References

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

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

2.1.12Obtain a list of triggers in the database and discuss with the DBA how they are used to monitor the database.


COBIT References

2.1.13Obtain 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 Security3.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.

DS3DS5PO11M1

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 Security4.1 Controls are in place to physically protect the database4.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.

DS4DS5

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

4.1.5 Review the processes for disposal of damaged or


COBIT References

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

DS5PO1PO6PO4AI4DS35.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 PASSWORD_VERIFY_FUNCTION PASSWORD_LOCK_TIME PASSWORD_GRACE_TIME


COBIT References

5.1.9 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.1 Review processes for granting and terminating access

to users within the database. DS5DS6DS7DS9DS11PO2PO4

2 Obtain a list of users on the system by executing the following command: SELECT * FROM DBA_USERS;

3 Obtain a current list of roles defined in the system by executing the following command: SELECT * FROM DBA_ROLE_PRIVS;

4 Obtain a list of users with their assigned roles by executing the following command: a

5 Select a sample of user access requests and determine that access is approved by the appropriate business/system owners and whether access is commensurate with each user’s job responsibilities.


COBIT References

6 Compare the approved access requests to the roles assigned to users to ensure that roles are appropriately assigned.

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

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.

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’;

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.

11 Review accounts that are assigned high-privilege roles such as DBA. Discuss the business requirement for this type of access with the database administrator.

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’;

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 = ‘PUBLIC’AND GRANTOR <>’SYS; AND GRANTOR <> ‘SYSTEM’;SELECT GRANTED_ROLE FROM SYS.DBA_ROLE_PRIVSWHERE GRANTEE =


COBIT References

‘PUBLIC’;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;

15 Ensure that SYS or SYSTEM own all objects in the SYSTEM tables.

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.

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 Recovery6.1 A backup and recovery strategy exists and is tested. 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.

DS4DS13

2 Obtain a copy of the init<SID>. ora file.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.

4 Discuss with the DBA procedures for regularly archiving redo logs to offline media. Determine procedures for securely protecting and disposing of offline media.

5 Review the CONTROL_FILES = <PATH> parameter to determine where the control files are stored.


COBIT References

Determine how many control files exist and ensure that files are protected.

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

database. Determine if a third-party package or the native DBMS_OBFUSCATION_TOOLKIT is used to implement encryption.

DS5DS9DS11

7.1.2 Review the company’s 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 Relationships8.1 Trusted Relationships are restricted and protected.8.1.1 Discuss with the DBA of any database links used

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.

DS5

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 Security9.1 Controls are in place to protect database information communicated over a network. 9.1.1 Review a network architecture diagram that depicts the

logical relationship between the database and other systems and networks within the organization. Ensure that the database is protected by a firewall from any third party or Internet access points.

DS5DS10M1

9.1.2 Discuss with the DBA the use of Oracle’s Advanced 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


COBIT References

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 organization’s constraints, policies and practices.

Control Objectives/QuestionsResponse

CommentsCOBIT

ReferencesYes No N/A

1. Patch Management1.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?

DS5DS10

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?

DS11DS5

2. Security Monitoring2.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?DS5M1

2.1.2 Are audit logs regularly reviewed? Do audit records and log information comply with the company’s data retention policy?

DS5

2.1.3 Are sensitive accounts and privileges monitored?

M1DS5

2.1.4 Are the audit records secured? Is access to the audit records restricted?

DS5

2.1.5 Is there a process for monitoring errors in the alert log and monitoring the creation of trace files?

DS5DS11

2.1.6 Are there procedures for regularly reviewing inactive users?

DS5

2.1.7 Are unexpected startup and shutdown occurrences of the database regularly reviewed?

DS2DS5

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?

DS5

2.1.9 Are database triggers used to monitor the database?

DS5

Control Objectives/Questions Response Comments COBIT ReferencesYes No N/A

3. Operating System Security3.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?DS5AI4

3.1.2 Are file permissions on key database files reviewed? Are there clear standards for setting appropriate file permissions?

AI5DS3DS5

3.1.3 Are database authentication credentials stored in batch files or scripts in plaintext?

DS5

3.1.4 Are operating system vulnerability scans conducted?

M1DS5

4. Physical Security4.1 Controls are in place to physically control the database.4.1.1 Are physical controls in place to protect

database systems?DS5DS12

4.1.2 Are password protected screen savers in place on server terminals?

DS5

4.1.3 Is there a documented disaster recovery plan in place that is regularly tested?

DS4DS5

4.1.4 Are backup tapes secured and stored? AI4DS5

4.1.5 Is there a clear database backup strategy? AI4DS4DS5

4.1.6 Is there a process for disposing of damaged or obsolete equipment?

DS4DS5

5. Logical Security5.1 Appropriate account and password controls in place.5.1.1 Does each DBA have a unique account on

the database?DS5DS3

5.1.2 Are there procedures in place to change default passwords?

AI4DS5

5.1.3 Are customized profiles other than DEFAULT used?

PO2DS5

5.1.4 Are generic or test accounts used? DS55.1.5 Is there a process for establishing new

accounts and communicating the initial password to the user?

DS5

5.1.6 Are profiles appropriately assigned to accounts?

DS5

5.1.7 Is there a process for emergency access to the database?

DS5DS10


5.1.8 Are appropriate profile settings in place to enforce password and resource usage controls?

DS5DS9

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?

DS5DS10

5.1.10 Are there procedures for managing vendor access to the database?

DS1DS2DS5

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?DS5

5.2.2 Is the list of active users reviewed on a regular basis?

DS11

5.2.3 Is the list of active roles reviewed on a regular basis?

PO4DS11

5.2.4 Is role membership reviewed on a regular basis?

DS11M1

5.2.5 Are accounts with high-privilege access (e.g., DBA) regularly reviewed?

PO9DS11

5.2.6 Do SYS and SYSTEM own all objects in the SYSTEM tables?

DS9

5.2.7 Is access to the Data Dictionary protected? DS55.2.8 Do any users have access to the

ALL_SOURCE view? What is the business requirement for this type of access?

PO1DS5PO9

5.2.9 Are any users assigned the INSERT, UPDATE, or DELETE privileges? What is the business requirement for this type of access?

PO1DS5

5.2.10 Are users created with the WITH ADMIN option? What is the business requirement for this type of access?

DS5

5.2.11 Does the special account, public, have any privileges assigned to it?

DS5

5.2.12 Are any privileges, rather than roles, assigned directly to users?

PO4PO9

5.2.13 Are any privileges assigned with the GRANT option?

DS5

6. Backup and Recovery6.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?DS4DS13


6.1.2 Are database logs archived? DS11DS13

6.1.3 Are control files protected and backed up? DS4DS13

7. Encryption7.1 An encryption strategy exists and is implemented to protect confidential information where appropriate.7.1.1 Is encryption used to protect confidential

information in the database?PO1DS5AI1

7.1.2 Are there standards in place for developing applications that use database utilities to encrypt data?

PO1PO6AI1AI2

8. Trusted Relationships8.1 Trusted Relationships are restricted and protected.8.1.1 Are database links used within the database?

Are the links private or public?DS5AI3

8.1.2 Are the database links encrypted? DS59. Network Security9.1 Controls are in place to protect database information communicated over a network.9.1.1 Is the database system accessible from any

applications, systems or users on the Internet or third-party networks? If the system is accessible from these networks, is it adequately protected by a firewall and intrusion detection system?

PO4AI5DS2DS5

9.1.2 Is Oracle Advanced Security Option (ASO) implemented in the environment? If ASO is implemented, how is it deployed in the environment?

AI5DS3DS5

9.1.3 Is the Oracle Listener service protected with a password?

AI3DS5

9.1.4 Are the latest patches applied to the Listener? DS5DS13

Documents

Auditoria Oracle