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

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

Documentation/ COBIT
Control Objective/Test
Matters Arising
A. Prior Audit/Examination Report Follow-up
Review prior report, if one exists, and verify completion of any M1
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 PO2
Oracle Database environment: PO3
 Version and release of the Oracle Database software PO4
and related tools (Oracle Enterprise Manager, Oracle PO6
Advanced Security Option, etc.) that are implemented PO9
 Version and release of the underlying operating system DS2
 Total number of named users (for comparison with DS5
logical access security testing results) AI2
 Number of database instances AI6
 Applications and related versions accessing the M1
database (e.g., ERP, web, custom) M2
 Utilities used to logon and manage the database M4
 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
 Documentation/ COBIT
Control Objective/Test
Matters Arising
b) Interview database administrators (DBA) to determine the DS5
following: DS9
 The level of overall security awareness and knowledge AI4
of corporate policies and procedures DS2
 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
Identify the significant risks and determine the key controls.
c) Develop a high-level system architecture and overall AI1
understanding of the system environment including the PO9
following: DS13
 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 DS5
weaknesses and test controls (refer to the following sample DS9
testing program for testing configurable controls and PO9
logical access security) having regard to the following M2
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.)
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 AI2
supported by reviewing the result of the following query AI6
and comparing the version to current versions supported DS5
by Oracle: DS9
 SELECT * FROM V$VERSION; DS10
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.
 Documentation/ COBIT
Control Objective/Test
Matters Arising
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 DS5
key database functions and security-related events to DS11
determine if system activity is regularly monitored. DS12
Obtain from the DBAs any reports or queries that are M4
used to monitor the system. DS1
2.1.2 Discuss with the DBAs the level of auditing that is M1
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.
 Documentation/ COBIT
Control Objective/Test
Matters Arising
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 DS3
administrators the steps that are taken and the controls DS5
that are implemented to ensure that the operating PO11
system is secured. M1
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 DS4
database systems. Ensure that the systems are stored in DS5
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.
 Documentation/ COBIT
Control Objective/Test
Matters Arising
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
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 DS5
system. Ensure that DBA does not use the CONNECT PO1
INTERNAL option to connect to the database. Ensure PO6
that each DBA uses a unique account to log on and PO4
administer the database. AI4
5.1.2 Obtain a list of users by executing the following DS3
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 Discuss with the DBA the process for establishing an
initial password. Ensure that generic or passwords that
can be easily guessed are not used.
 Documentation/ COBIT
Control Objective/Test
Matters Arising
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
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;
 Documentation/ COBIT
Control Objective/Test
Matters Arising
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 DS5
to users within the database. DS6
5.2.1.2 Obtain a list of users on the system by executing the DS7
following command: SELECT * FROM DBA_USERS; DS9
5.2.1.3 Obtain a current list of roles defined in the system by DS11
executing the following command: SELECT * FROM PO2
DBA_ROLE_PRIVS; PO4
5.2.1.4 Obtain a list of users with their assigned roles by
executing the following command: SELECT * FROM
USER_ROLE_PRIVS;
5.2.1.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.
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’;
 Documentation/ COBIT
Control Objective/Test
Matters Arising
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 high-
privilege 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 =
‘PUBLIC’AND 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.
 Documentation/ COBIT
Control Objective/Test
Matters Arising
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 DS4
recovery of the database. Confirm with the DBA that DS13
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
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 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 Relationships
 Documentation/ COBIT
Control Objective/Test
Matters Arising
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 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
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.

Response COBIT
Control Objectives/Questions Comments
Yes No N/A 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 DS5
security patches and applying the patches in DS10
a timely manner?
1.1.3 Is there a change control process in place DS11
used to ensure that only tested and approved DS5
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 DS5
related events regularly monitored? M1
2.1.2 Are audit logs regularly reviewed? Do audit DS5
records and log information comply with the
company’s data retention policy?
2.1.3 Are sensitive accounts and privileges M1
monitored? DS5
2.1.4 Are the audit records secured? Is access to DS5
the audit records restricted?
2.1.5 Is there a process for monitoring errors in the DS5
alert log and monitoring the creation of trace DS11
files?
2.1.6 Are there procedures for regularly reviewing DS5
inactive users?
2.1.7 Are unexpected startup and shutdown DS2
occurrences of the database regularly DS5
reviewed?
2.1.8 Are clear security requirements built into DS5
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 DS5
database?
 Control Objectives/Questions Response Comments COBIT
Yes No N/A References
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 DS5
the underlying operating system is secured? AI4
3.1.2 Are file permissions on key database files AI5
reviewed? Are there clear standards for DS3
setting appropriate file permissions? DS5
3.1.3 Are database authentication credentials DS5
stored in batch files or scripts in plaintext?
3.1.4 Are operating system vulnerability scans M1
conducted? DS5
4. Physical Security
4.1 Controls are in place to physically control the database.
4.1.1 Are physical controls in place to protect DS5
database systems? DS12
4.1.2 Are password protected screen savers in DS5
place on server terminals?
4.1.3 Is there a documented disaster recovery plan DS4
in place that is regularly tested? DS5
4.1.4 Are backup tapes secured and stored? AI4
DS5
4.1.5 Is there a clear database backup strategy? AI4
DS4
DS5
4.1.6 Is there a process for disposing of damaged DS4
or obsolete equipment? DS5
5. Logical Security
5.1 Appropriate account and password controls in place.
5.1.1 Does each DBA have a unique account on DS5
the database? DS3
5.1.2 Are there procedures in place to change AI4
default passwords? DS5
5.1.3 Are customized profiles other than PO2
DEFAULT used? DS5
5.1.4 Are generic or test accounts used? DS5
5.1.5 Is there a process for establishing new DS5
accounts and communicating the initial
password to the user?
5.1.6 Are profiles appropriately assigned to DS5
accounts?
5.1.7 Is there a process for emergency access to the DS5
database? DS10
 Control Objectives/Questions Response Comments COBIT
Yes No N/A References
5.1.8 Are appropriate profile settings in place to DS5
enforce password and resource usage DS9
controls?
5.1.9 Are there users who are authenticated DS5
externally by the operating system? Is there a DS10
valid and documented business requirement
for this type of access?
5.1.10 Are there procedures for managing vendor DS1
access to the database? DS2
DS5
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 DS5
terminating user access to the database?
5.2.2 Is the list of active users reviewed on a DS11
regular basis?
5.2.3 Is the list of active roles reviewed on a PO4
regular basis? DS11
5.2.4 Is role membership reviewed on a regular DS11
basis? M1
5.2.5 Are accounts with high-privilege access (e.g., PO9
DBA) regularly reviewed? DS11
5.2.6 Do SYS and SYSTEM own all objects in the DS9
SYSTEM tables?
5.2.7 Is access to the Data Dictionary protected? DS5
5.2.8 Do any users have access to the PO1
ALL_SOURCE view? What is the business DS5
requirement for this type of access? PO9
5.2.9 Are any users assigned the INSERT, PO1
UPDATE, or DELETE privileges? What is DS5
the business requirement for this type of
access?
5.2.10 Are users created with the WITH ADMIN DS5
option? What is the business requirement for
this type of access?
5.2.11 Does the special account, public, have any DS5
privileges assigned to it?
5.2.12 Are any privileges, rather than roles, PO4
assigned directly to users? PO9
5.2.13 Are any privileges assigned with the DS5
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 DS4
recovery of the database? DS13
 Control Objectives/Questions Response Comments COBIT
Yes No N/A References
6.1.2 Are database logs archived? DS11
DS13
6.1.3 Are control files protected and backed up? 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