Technical and Risk Management Reference Series

Security, Audit and

Control Features
Oracle
Database

3rd Edition

ExcerptExecutive Summary Through Chapter 4.

Oracle Database System Architecture Overview

Security, Audit and Control Features Oracle Database, 3rd Edition

ISACA
With more than 86,000 constituents in more than 160 countries, ISACA (www.isaca.org) is a leading
global provider of knowledge, certifications, community, advocacy and education on information
systems assurance and security, enterprise governance of IT, and IT-related risk and compliance.
Founded in 1969, ISACA sponsors international conferences, publishes the ISACA Journal, and
develops international information systems auditing and control standards. It also administers the
globally respected Certified Information Systems Auditor (CISA), Certified Information Security
Manager (CISM) and Certified in the Governance of Enterprise IT (CGEIT) designations.
ISACA developed and continually updates the CobiT, Val IT and Risk IT frameworks, which help
IT professionals and enterprise leaders fulfill their IT governance responsibilities and deliver value to
the business.
Disclaimer
ISACA has designed and created Security, Audit and Control Features Oracle Database, 3rd Edition
(Technical and Risk Management Reference Series) (the Work), primarily as an educational resource
for control professionals. ISACA makes no claim that use of all of the Work will assure a successful
outcome. The Work should not be considered inclusive of all proper information, procedures and
tests or exclusive of other information, procedures and tests that are reasonably directed to obtaining
the same results. In determining the propriety of all specific information, procedure or test, security
professionals should apply their own professional judgment to the specific control circumstances
presented by the particular systems or information technology environment.
Oracle is a registered trademark of Oracle Corporation. Oracle Corporation is not the publisher of this
book and is not responsible for it under any aspect of press law.
Reservation of Rights
2009 ISACA. All rights reserved. No part of this publication may be used, copied, reproduced,
modified, distributed, displayed, stored in a retrieval system or transmitted in any form by any
means (electronic, mechanical, photocopying, recording or otherwise) without the prior written
authorization of ISACA. Reproduction and use of all or portions of this publication are permitted
solely for academic, internal and noncommercial use and for consulting/advisory engagements, and
must include full attribution of the materials source. No other right or permission is granted with
respect to this work.

ISACA
3701 Algonquin Road, Suite 1010
Rolling Meadows, IL 60008 USA
Phone: +1.847.253.1545
Fax: +1.847.253.1443
E-mail: info@isaca.org
Web site: www.isaca.org
ISBN 978-1-60420-118-5
Security, Audit and Control Features Oracle Database, 3rd Edition (Technical and Risk Management
Reference Series)
Printed in the United States of America
CGEIT is a trademark/service mark of ISACA. The mark has been applied for or registered in countries
throughout the world.
Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be
trademarks of their respective owners. This publication was not created in conjunction with or endorsed
by the Oracle Corporation and/or its affiliates.

ii

Acknowledgments

Acknowledgments
ISACA wishes to recognize:
Researchers
Rik Boren, CISA, CISM, CISSP, CPA, PricewaterhouseCoopers LLP, USA
David W. Stanton, CISM, CISSP, PricewaterhouseCoopers LLP, USA
Igor Oreper, PricewaterhouseCoopers LLP, USA
Philip D. Wainwright, PricewaterhouseCoopers LLP, USA
Roger Heiniluoma, CIMA Energy, USA
Expert Reviewers
Emmanuel Osei Kwame Adjei, Kofi Annan Centre of Excellence-Advanced Information Technology
Institute, Ghana
Akin Akinbosoye, CISA, CISM, CGEIT, PMI-RMP, Healthcare Corporation of America, USA
Kelvin J. Arcelay, CISA, CISSP, HISP, IRCA ISMS Auditor, PMP, SSGB, Arcelay and Associates
LLC, USA
Deepak Agrawal, CISA, CISM, CISSP, PMP, PricewaterhouseCoopers, India
Jeffrey T. Hare, CISA CPA CIA, ERP Seminars, USA
Kamal Khan, CISA, CISSP, CITP, Saudi Aramco, Saudi Arabia
Prashant A. Khopkar, CISA, CA, USA
Arbogast Celestine Kihaule, CISA, OCP9i, IT Consultant, Tanzania
Stephen Kost, Integrigy Corporation, USA
Larry Marks, CISA, CGEIT, CFE, CISSP, CSTE, PMP, Resources Global Professionals, USA
K.K. Mookhey, CISA, CISM, CISP, Network Intelligence, India
Felix Ramirez, CISA, CGEIT, Riebeeck Stevens Ltd., USA
Nitin Sood, CISM, CISSP, CSSLP, OCA, PMP, Independent Consultant, Canada
Peter Tessin, CISA, PMP, Altran Control Solutions, USA
Sanjay Kumar Vaid, CISA, CISM, CGEIT, Belgium
Jinu Varghese, CISA, CISSP, OCA, PricewaterhouseCoopers LLP, Canada
ISACA Board of Directors
Emil DAngelo, CISA, CISM, Bank of Tokyo-Mitsubishi UFJ Ltd., USA, International President
George Ataya, CISA, CISM, CGEIT, CISSP, ICT Control SA-NV, Belgium, Vice President
Yonosuke Harada, CISA, CISM, CGEIT, CAIS, InfoCom Research Inc., Japan, Vice President
Ria Lucas, CISA, CGEIT, Telstra Corporation Ltd., Australia, Vice President
Jose Angel Pena Ibarra, CGEIT, Alintec, Mexico, Vice President
Robert E. Stroud, CGEIT, CA Inc., USA, Vice President
Kenneth L. Vander Wal, CISA, CPA, Ernst & Young LLP (retired), USA, Vice President
Rolf von Roessing, CISA, CISM, CGEIT, KPMG Germany, Germany, Vice President
Lynn Lawton, CISA, FBCS CITP, FCA, FIIA, KPMG LLP, UK, Past International President
Everett C. Johnson Jr., CPA, Deloitte & Touche LLP (retired), USA, Past International President
Gregory T. Grocholski, CISA, The Dow Chemical Co., USA, Director
Tony Hayes, CGEIT, AFCHSE, CHE, FACS, FCPA, FIIA, Queensland Government,
Australia, Director
Howard Nicholson, CISA, CGEIT, City of Salisbury, Australia, Director
Jeff Spivey, CPP, PSP, Security Risk Management, USA, Trustee
Knowledge Board
Gregory T. Grocholski, CISA, The Dow Chemical Co., USA, Chair
Michael Berardi Jr., CISA, CGEIT, Energizer, USA
John Ho Chi, CISA, CISM, CBCP, CFE, Ernst & Young, Singapore
Jose Angel Pena Ibarra, CGEIT, Alintec, Mexico
Jo Stewart-Rattray, CISA, CISM, CGEIT, CSEPS, RSM Bird Cameron, Australia
Jon Singleton, CISA, FCA, Auditor General of Manitoba (retired), Canada
Patrick Stachtchenko, CISA, CGEIT, CA, Stachtchenko & Associates SAS, France
Kenneth L. Vander Wal, CISA, CPA, Ernst & Young LLP (retired), USA

iii

Security, Audit and Control Features Oracle Database, 3rd Edition

Acknowledgments (cont.)
Guidance and Practices Committee
Kenneth L. Vander Wal, CISA, CPA, Ernst & Young LLP (retired), USA, Chair
Phillip J. Langeschulte, CGEIT, CPA, KPMG LLP, USA
Mark A. Lobel, CISA, CISM, CISSP, PricewaterhouseCoopers LLP, USA
Adel H. Melek, CISA, CISM, CGEIT, CISSP, Deloitte & Touche, Canada
Ravi Muthukrishnan, CISA, CISM, FCA, ISCA, Capco IT Service India Private Ltd, India
Anthony P. Noble, CISA, CCP, Viacom Inc., USA
Salamon Rico, CISA, CISM, CGEIT, Deloitte, Mexico
Eddy Schuermans, CISA, CGEIT, ESRAS bv ba, Belgium
Frank Van Der Zwaag, CISA, CISSP, Westpac, New Zealand
To the ISACA Chicago chapter for its financial support

iv

Table of Contents

Table of Contents
Executive Summary.................................................................................... 1
1. Introduction............................................................................................ 3
Intended Audience.............................................................................................. 3
Conventions/Explanations of Illustrations......................................................... 3
Overall Audit Approach..................................................................................... 4
A Brief History of Oracle Database Security..................................................... 4
2. Security and Control Approach/Framework.................. 9
3. Security Policies................................................................................. 11
4. Oracle Database System Architecture Overview...... 13
Instance vs. Database........................................................................................ 14
Tablespace......................................................................................................... 14
Server Processes............................................................................................... 15
File Structure..................................................................................................... 17
Memory Structure............................................................................................. 19
Oracle Net......................................................................................................... 20
5. Planning the Audit............................................................................. 21
6. Understanding the IT Environment....................................... 23
7. Operating System Security.......................................................... 27
Risks Associated With Poor OS Security........................................................ 27
Controls............................................................................................................. 28
8. New Features........................................................................................... 35
Oracle 10gNew Security Features................................................................ 35
Oracle 11gNew Security Features .............................................................. 37
9. Database Security Privileges.................................................... 39
System Privileges.............................................................................................. 40
10. Access Control..................................................................................... 43
Roles.................................................................................................................. 43
Stored Procedures and Triggers....................................................................... 56
ALL_SOURCE View....................................................................................... 58
Data Dictionary................................................................................................. 59
Encryption of Database Records...................................................................... 62
Database Access............................................................................................... 65
Emergency Access............................................................................................ 70
Generic Accounts.............................................................................................. 70
Password Controls............................................................................................ 71
Resource Limits................................................................................................ 74
v

Security, Audit and Control Features Oracle Database, 3rd Edition

11. Auditing and Log Files..................................................................... 79
12. Trusted Relationships..................................................................... 85
Protecting the DBLINK (SYS.LINK$)............................................................ 87
Operating System Authentication.................................................................... 87
Remote Operating System Authentication....................................................... 89
OSOPER, OSDBA and OSASM Access............................................................. 89
13. Network Security............................................................................... 91
TNS Listener..................................................................................................... 91
Firewalls............................................................................................................ 93
Valid Node Checking....................................................................................... 94
Oracle Advanced Security................................................................................ 95
14. General Controls............................................................................... 99
Change Management........................................................................................ 99
Information Classification................................................................................ 99
Segregation of Duties..................................................................................... 100
System Development Life Cycle.................................................................... 101
Documentation................................................................................................ 102
Monitoring...................................................................................................... 102
Intrusion Response.......................................................................................... 103
Vulnerability and Patch Management............................................................ 104
Security Awareness........................................................................................ 104
Backup and Recovery..................................................................................... 104
Logical Backups............................................................................................. 106
Physical Backups............................................................................................ 106
Recovery Manager . ....................................................................................... 107
15. Application Security...................................................................... 109
16. Tools........................................................................................................... 113
Oracle Enterprise Manager............................................................................. 113
Oracle SQL Developer................................................................................... 118
Tool for Oracle Application Developers . ..................................................... 119
UTL_FILE Package........................................................................................ 120
UTL_HTTP Package...................................................................................... 121
UTL_INADDR Package................................................................................ 121
Appendix 1. Automated Assessment Tool
Recommendations................................................................................... 123
Appendix 2. Audit/Assurance Program and Internal
Control Questionnaire....................................................................... 125
Appendix 3. Questions and Answers.............................................. 183
Appendix 4. Recommendations for the Professional..... 185
vi

Table of Contents
Appendix 5. Frequently Asked Questions................................. 187
Appendix 6. CobiT References............................................................ 189
Appendix 7. Glossary............................................................................... 193
Appendix 8. Acronyms............................................................................. 205
Appendix 9. Reading Suggestions................................................... 209
Appendix 10. References........................................................................ 211
ISACA Professional Guidance Publications.......................... 213
Index.................................................................................................................. 216

vii

Security, Audit and Control Features Oracle Database, 3rd Edition

Page intentionally left blank

viii

Executive Summary

Executive Summary
As systems have migrated from mainframe to client-server and multitiered web
application environments, the criticality of protecting the relational database has
grown steadily over the last decade. The confidentiality, integrity and availability
requirements of the database tier are at an all-time high. Consumers of information
(e.g., employees, customers and business partners) all demand instant access
to data in a near real-time and accurate manner. Further, the level of awareness
around securing the database has steadily increased over the years due to increased
legal and regulatory compliance requirements. Enterprises continue to realize the
business impact that could result from a data security breach, including financial
loss, negative perception in the marketplace and loss of shareholder value. These
factors have led to higher security expectations of database administrators,
application developers and the assessors role in identifying risk. As a result, there
has been an increased focus on auditing the database itself to ensure that there are
appropriate safeguards in place to protect against reasonably foreseeable threats.
This book sets out to assist the assessor in reviewing the security of an Oracle
Database environment. It can be used as a field reference for the assessor or can be
read cover to cover by those interested in learning more about Oracle security.
Throughout the book, a background and review of security controls are provided.
Several different frameworks that can be used to assess security risks are
discussed. The book covers other soft topics with which an assessor needs to
be familiar, such as developing a strategy to plan the audit, understanding the
information technology (IT) environment, and reviewing policies and standards.
The book also discusses technical topics, including an overview of Oracle
Databases architecture, operating system controls, auditing and logging, network
security and new features offered in Oracle 11g (the latest version of Oracle
Database as of the writing of this book). Additionally, differences in previous
versions of Oracle Database are noted, as well as differences that may exist based
on the host operating system of the database.
Topics such as automated assessment tools, enterprise resource planning (ERP)
and customer relationship management (CRM) architectures, and interfaces with
legacy systems are also addressed. While these specific topics are not covered in
great detail, they do provide the assessor with an overall framework for assessing
Oracle Database security in the context of actual client deployment scenarios and
environments.

Security, Audit and Control Features Oracle Database, 3rd Edition

The goal of this book is not to be an all-inclusive instruction manual for the
everyday database administrator. It is intended to guide the assessor through a
comprehensive evaluation of security for an Oracle Database based on business
objectives and risks. It is also intended that the assessor will review and integrate
other related audit/assurance program documents, in relation to the requirements
of the project/assignment; specific scope; IT/enterprise architecture; availability of
the time, budget and resources; and other relevant factors.

1. Introduction

1. Introduction
An effective approach to assessing security must consider security controls at each
layer of the system or application architecture (e.g., application, operating system,
database, network and physical levels). A security weakness within any component
of the system may lead to the compromise of the entire system. In many system
environments, an Oracle Database is a key component of the system architecture.
Before the US Sarbanes-Oxley Act, many IT audits focused on application,
network and operating system controls, often overlooking the database layer
entirely. However, the database is usually the repository or authoritative source
of critical business data and sensitive customer or employee data that are heavily
regulated. Unauthorized access to the database can also lead to unauthorized access
to the underlying operating system, which could allow an attacker to compromise
additional systems and databases on the network. As a result, the database should
be included as a key component of any systems security audit.
This book provides the reader with the knowledge and tools to effectively audit an
Oracle Database 11g environment. At the time of the writing of this book, Oracle
Database 11g is the most recent version released by Oracle. Because older versions
of Oracle Database are still prevalent in the industry and fully supported by Oracle,
including Oracle Database 9i and 10g, many of the concepts discussed for Oracle
Database 11g will also apply to older versions, unless otherwise specified.

Intended Audience
The primary audience of this book is assessors who review and assess the security
of environments that include an Oracle Database component. Other audiences,
such as information security practitioners and database administrators (DBAs),
also will find this book useful to understand and assess Oracle security risks.
The intended audience for this book should already have an existing high-level
knowledge of Oracle Database technologies and understand general auditing and
security concepts.

Conventions/Explanations of Illustrations
The objective of this book is to provide the reader with a practical, real-world
approach to auditing Oracle Database security. Case studies and examples are
provided and identified in grey boxes, titled Real-world Examples, to illustrate
different concepts. Although these examples are based on real-world scenarios, it
is difficult to relate in a single example to the varied environments where Oracle
Database is implemented. With that said, it is hoped that readers will be able to
relate the context in the examples to their own environments.

Security, Audit and Control Features Oracle Database, 3rd Edition

Throughout this book, different fonts are used to help distinguish user names,
SQL commands, and other special words or phrases from normal text, as shown in
figure 1.1.
Figure 1.1Font Conventions Used in This Text
Root, SYSTEM, SYS

Directory, file and user names

SELECT, DROP, SYS.LINK$

Default accounts, passwords, profiles,

parameters, process names, roles, SQL
commands, table names, values, view names

DBA

Operating system group names

Similarly, when referring to job titles or positions within an enterprise, statements

were written within the following context:
End userA person who accesses the system to perform business processrelated functions
Database administratorA person who is responsible for the maintenance and
support of the database
Security administratorThe primary person responsible for administering
security for an environment
VendorA third party that is temporarily engaged to address an issue or provide
support for the system
ContractorA third party that is engaged to assist in system implementation,
administration and support
DeveloperA person responsible for creating or changing application functions

Overall Audit Approach

This book recommends a risk-based IT audit approach based on the CobiT 4.1
framework. The level of security and controls implemented for a system should
be proportional to the level of risk that the system poses to the enterprise. Not all
systems present the same level of risk to an enterprise; therefore, not all systems
should implement the same security model. Based on this approach, identified
controls may vary depending on the level of risk identified for a given system. The
audit approach is addressed in more detail in chapter 2.

A Brief History of Oracle Database Security

The Oracle Corporation was founded in 1977. Since its inception, the company
has strived to provide a leading-edge database technology. Oracle is a relational
database, linking information using relationships between key fields in tables,
which consist of rows and columns. Objects in relational databases do not have a
predetermined relationship, which enables the database to be flexible and provide
a wide range of functionality.
4

1. Introduction
Responding to the suggestions and requests of its customers, Oracle added security
functions to version 6 and as such, version 6 of Oracles database was the first
major release of the product to contain significant security enhancements. Version
6 was also the first Oracle Database to include the use of roles. These roles were
assigned privileges that defined the access rights to data stored in tables. The
roles were then granted to users of the database; thus, users could access only data
to which they were granted access via a role assignment. This is essentially the
same user access model that all later versions of Oracle Database have used as a
foundation. In version 6, DBAs could not create their own roles; they could assign
only the Oracle-supplied default roles. Version 6 also included auditing features,
which provided the ability to audit logins, track actions performed on the database
and identify all objects accessed, as well as new backup features, such as redo logs
and rollback segments.
Oracle Database version 7 was released in 1994, coinciding with the growth of
client-server technologies. Version 7 contained some auditing enhancements over
version 6, including triggers which were introduced to track modifications of a
table and record before and after pictures of the data. In version 7, the audit trail
could be saved in the database or exported to an external file. This version also
introduced hot backups, which enabled the entire database to be backed up while it
was still operational. One of the key improvements in version 7 was the capability
for DBAs to create new, custom roles and assign them to database users.
With the release of version 7.3, Oracle introduced the Oracle Advanced
Networking Option. This option was sold as an add-on at an additional cost. The
Advanced Networking Option provided the capability to encrypt queries and
replies between the client and server. Even though this provided a good level
of security, it often negatively impacted database performance in a significant
way and, thus, was not implemented by many enterprises. Oracle Advanced
Networking also provided additional authentication options from third-party
software vendors, such as SecureID and Kerberos. Oracle also offered an addedcost security feature called Trusted Oracle 7, which allowed data to be classified
in a database. Each row of data could be assigned a classification, and only users
who matched the assigned security level to each classification level could gain
access to the information.
Oracle Database version 8 was released in 1997. Major upgrades included
stronger password management controls and other enhanced security features.
Prior versions contained virtually no password control enforcement features;
administrators were only able to create a user ID and assign it a password. The
new password controls available within version 8 included password expiration,
locking out an account after a predetermined amount of failed login attempts,
prohibiting use of the same password within a certain period of time, password
complexity controls, and password length. It also allowed for administrators to
set up user IDs, requiring users who logged on to the database for the first time
5

Security, Audit and Control Features Oracle Database, 3rd Edition

to change their default passwords. Enhancements also were made to the auditing
functionality. For example, auditing was designed in the new version to be more
granular, with the ability to audit any privilege or action performed within a
database.
In 1999, Oracle released Oracle 8i, its database with built-in support for
Internet deployment (e-commerce). With this release, upgrades were made to
the Advanced Networking Option, which was renamed the Advanced Security
Option. The Oracle Advanced Security Option offers single-security integration
with encryption solutions, authentication solutions, single sign-on services and
security protocols. Another feature introduced was the Virtual Private Database
(explained in greater detail in chapter 8), which uses fine-grained access control
and allows for flexibility by applying policies directly to the data. Oracle Label
Security relies on the functionality of the Virtual Private Database concept. Oracle
Label Security is the successor to Trusted Oracle 7. It utilizes the same label or
classification scheme in Trusted Oracle 7, but incorporates it with Virtual Private
Database technology.
Oracle released Oracle 9i in 2001, describing it as an unbreakable database
and the foremost Internet database. The security enhancements were the most
significant since version 6. Security features in the database included capability
to scale to millions of users, thus providing a powerful basis for Internet usage.
One of the new features offered in Oracle 9i was what the Oracle Corporation
termed deep data protectiona layered approach to security. The concept is that
a failure of one mechanism will not result in the complete exposure of the entire
database. Deep data protection in Oracle 9i was accomplished with a combination
of the following four features:
Virtual Private Database (VPD)Enhancements included the Oracle Policy
Manager, a tool designed to ease policy administration and maintain fine-grained
access control for partitions with multiple application environments on the same
database at the same time. This partitioning ensured that users could access only
their own information.
Selective data encryptionThis tool, provided by the DBMS_OBFUSCATION_
TOOLKIT, encrypted and decrypted data stored in the database using either Data
Encryption Standard (DES) or Triple DES (3DES).
Oracle Label SecurityThis add-on security feature for Oracle 9i provided
row-based security. For example, a label could be assigned to a row and then
associated with a session. Privileges were then assigned based upon the user
session.
Fine-grained Auditing (FGA)This feature allowed for more granular auditing
on specific rows. FGA could also be used as an intrusion detection mechanism
for the database, if appropriately configured. Certain audit events could act as a
trigger, which could then be logged to a separate area or could activate an alert,
such as a phone call, to the security or database administrator.

1. Introduction
External application security also was addressed in Oracle 9i. External application
refers to applications and tools such as SQL*Plus, that interact with the database for
administrative purposes,. Every application that interacts with the database can have
its own set of security policies. Unique roles and privileges can be created, which
will provide varying levels of security based upon the individuals job responsibility.
Oracle NetSolutions for Oracle 9i, known in previous versions as SQL*Net, has
increased functionality for firewall usage. Access to the database can be permitted
or restricted by destination database names, source IP addresses, source host names,
destination IP addresses and destination host names. In addition to these features, many
of the well-known default accounts associated with Oracle now are locked during
the initial installation. This provides additional security over the database, since these
accounts and the default passwords associated with them are widely known.
Oracle introduced Oracle Database 10g in 2003. The g is meant to focus on
Oracles abilities in grid computing, and many features were added to enhance the
database operation in distributed environments. Security enhancements in version
10g improved several of the features introduced in 9i:
VPD10g introduced column-level security and masking, which enabled finergrained access controls to security administrators. Policy types and caching were
introduced to enhance performance of these more secure databases.
Password change option at installationThe default passwords, which an
administrator had to change immediately, had to now be changed as part of the
installation process.
FGAData Manipulation Language (DML) auditing, which allows monitoring
of INSERT, DELETE and UPDATE statements in addition to SELECT, was
added in this version of FGA. The FGA records and standard log records were
presented in a single unified format. The auditing records were enhanced with
the exact SQL text of audited statements, the date/time stamp in Coordinated
Universal Time (UTC) and added support for enterprise users.
Enhanced encryptionAs part of Oracle Advanced Security, significant
improvements were made for encrypting data at rest with features such as
Transparent Data Encryption (TDE) and increased support for encrypted
network communications to secure user logins and data transfers over the
network using Advanced Encryption Standard (AES) encryption. In addition, the
DBMS_CRYPTO package replaced the DBMS_OBFUSCATION_TOOLKIT,
simplifying the use of encryption within the database.
Strong authentication for privileged usersSecure logins over the network for
privileged users with SYSDBA and SYSOPER privileges using Kerberos or
Secure Sockets Layer (SSL) were required.
Oracle Database VaultThis was an additional Oracle component used
to safeguard application data from privileged users, including database
administrators and security administrators. More information regarding Oracle
Database Vault is available in a white paper.1
1

 racle, Best Practices, 2008, www.oracle.com/technology/deploy/security/database-security/pdf/

O
twp_database_vault_bestpractices_20080219.pdf

Security, Audit and Control Features Oracle Database, 3rd Edition

Oracle Audit VaultThis additional Oracle component was used to aggregate
audit logs and system monitoring and reporting. More information regarding the
Oracle Audit Vault is available in a white paper.2
As of the publication of this book, Oracle 11g is the latest version of Oracle
Database. Oracle 11g has seen more enhancements in usability and manageability,
and offers incremental security enhancements over Oracle 10g:
Enhanced password securitySeveral new password protection features were
introduced, including case-sensitive passwords, enhanced password complexity
verification, a new database view to easily identify Oracle accounts with default
passwords, and storage of database passwords using the more secure SHA-1
hashing algorithm.
Fine-grained access to network servicesAs databases are more prevalent in
networked environments, fine-grained access control rules can be used to restrict
which users and hosts can invoke Oracle network service packages from the
database.
Encryption enhancementsSeveral new features were introduced in Oracle 11g
to enhance encryption, including support for compression and encryption of
large object (LOB) data using SecureFiles, added support for hardware security
modules (HSM) using TDE, and a new Transparent Tablespace Encryption
(TTE) feature to encrypt all data in a tablespace.
Oracle Database security has improved greatly from version 6.x to 11g. Oracle
has provided DBAs and security administrators with constantly improved tools to
secure the database, but IT auditors and security practitioners know that security
vulnerabilities can exist when systems are implemented and managed improperly.
Consistent and thorough security audits are necessary to ensure that Oracle
Database is configured and managed securely.3

 racle, Best Practices, 2007, www.oracle.com/technology/products/audit-vault/pdf/twp_auditvault_

O
bestpractices_200711.pdf
3
Newman, Aron; Marlene Theriault; Oracle Security Handbook: Implement a Sound Security Plan in
Your Oracle Environment, Osborne/McGraw-Hill, USA, 2001, p. 36-70
2

2. Security and Control Approach/Framework

2. Security and Control Approach/Framework

Chapter Overview
The CobiT framework provides a structure for developing control objectives. These
objectives are enforced through technical features provided by Oracle, organizational
policies and standards, management commitment to security, people, and processes.
This chapter describes the IT control approach of the CobiT framework, which serves
as the foundation for the audit approach discussed in this book.
It is the responsibility of management to understand the risks related to the
enterprises systems and implement the right level of controls to mitigate
those risks. CobiT is a framework or tool that provides clear policies and good
practices for IT control from a business perspective. The CobiT 4.1 framework
is intended to provide management, users of IT and auditors with a framework
for approaching the management of IT resources by a set of naturally grouped
processes. CobiT includes 34 key IT processes grouped into the following four
domains (refer to appendix 6 for additional information on the CobiT domains):
Plan and Organize
Acquire and Implement
Deliver and Support
Monitor and Evaluate
There are approximately three to 14 control objectives defined for each process,
for a total of 210. An IT control objective is defined by CobiT as a statement of the
desired result or purpose to be achieved by implementing control procedures in a
particular IT activity.
The primary intent of this book is to provide an overview of key Oracle Database
security features and offer guidance to IT auditors and security practitioners
regarding the evaluation of these features; therefore, this book focuses on the
control objectives embodied in the Deliver and Support domain, specifically
DS5 Ensure systems security. There are 11 control objectives defined for the
DS5 process (refer to appendix 6 for a detailed definition of the control
objectives). Each chapter in this book includes a reference to the related CobiT
control objectives to help the reader view the specific detailed Oracle controls
from the overall business risk and control perspective provided by the CobiT
framework. These control objectives are specifically intended to help an
organization meet the following security requirements:
ConfidentialityRelates to the protection of sensitive information from
unauthorized disclosure. Unauthorized disclosure can result from threats that are
external to the enterprise (e.g., hackers) or internal (e.g., employees). Privacy
and security regulations in the US over the last two decades, such as HIPAA,
the Graham-Leach-Bliley Act (GLBA), at least 48 state and territorial data
breach laws, and industry regulations such as PCI DSS have made protecting
the confidentiality of private information a primary focus of enterprises today.
9

Security, Audit and Control Features Oracle Database, 3rd Edition

Other similar laws and regulations exist in many other countries, including the
European Union Safe Harbor Directive for Data Protection and the Canadian
Personal Information Protection and Electronic Documents Act (PIPEDA).
IntegrityRelates to the accuracy and completeness of information as well as
its validity in accordance with business values and expectations. Data integrity
controls are a key element of ensuring that data transmitted electronically are
received by the intended recipient in the form in which they were transmitted
(i.e., they have not been subject to alteration or modification). The current
regulatory environment has greatly increased the need for enterprises to have
effective controls over their financial systems, which often include databases.
Integrity controls can vary from simple to complex. Some examples of these
controls are highlighted as follows:
Edit checks that ensure that the information entered is numeric vs. alphabetic
(as well as vice versa and almost any permutation), and does not exceed a
preset maximum value or fall below a preset minimum value
Hash totals that ensure that the number of records processed equals the number
of records submitted
Validation routines that ensure that all submitted data contain the required data
elements
Digital signatures on certain critical data elements, incorporating complex
algorithms, to ensure all of the previously listed controls and more
AvailabilityRelates to information being available when required by the
business now and in the future. It also concerns the safeguarding and backup of
necessary resources and associated capabilities, such as hardware and skilled
employees. The subject of availability includes system controls that require the
periodic and frequent backup of data, as well as the protection and maintenance
of critical system software and hardware components. Most enterprises today
depend on real-time, or near-real-time, access to information.
Real-world Example
US California Senate Bill (SB) 1386 requires that anyone conducting business in
the state of California must report any unauthorized acquisition of computerized
data that compromises the security, confidentiality or integrity of the personal
data of any California resident. To date, 48 other states and territories have
enacted similar legislation, often using the same wording as SB1386. The
repercussions surrounding a disclosure like this could result in substantial
financial penalties for an enterprise. More information on states that have breach
notification laws can be found at www.ncsl.org/default.aspx?tabid=13489.

10

3. Security Policies

3. Security Policies
Chapter Overview
Clear, consistent and enforceable information security policies are important to
every enterprise, regardless of the level of information security required. Security
policies help protect the enterprises information assets from unauthorized access
and disclosure that could damage its reputation and/or reduce the level of public
confidence in the enterprise. This chapter shows how policies, standards and
technical controls relate to auditing Oracle Database and the chapter references
CobiT control objectives: DS5.1 and PO2.3.
Policies should communicate managements objectives and goals for
implementing security enterprisewide and should be general statements that apply
to all employees, across multiple business units. The following is an example of a
policy statement:
Information resources are essential to our success. Therefore, access to
all information resources will be granted in a controlled manner driven
by business requirements. The overall strategy is that access is strictly
forbidden unless explicitly granted. Employees are explicitly granted
access to information or systems. There is no implicit right of access.
Real-world Example
PCI DSS version 1.2, Requirement 12, defines a set of detailed criteria for
maintaining an information security policy for employees and contractors. PCI
DSS also calls for a formal security awareness program to make employees aware
of the enterprises information security policy and responsibilities for protecting
sensitive data. Other countries around the world also have similar requirements.
Standards communicate how the policies should be implemented and should
be independent of any particular technology. The following is an example of a
standard:
All access to computer systems must be controlled by an authentication
method involving a minimum of a username/password combination.
All employees must authenticate to systems using their individually
identifiable accounts.
The last piece in the policy puzzle is technical controls, which should define
how the standards will be implemented in Oracle Database. The following is an
example of a technical control for Oracle Database:
The SYS and SYSTEM passwords must be known only by the Oracle
system administrator and authorized database administrators. The
SYS and SYSTEM account passwords should not be the same, and
11

Security, Audit and Control Features Oracle Database, 3rd Edition

different passwords must be assigned to accounts within different
Oracle instances. The SYS and SYSTEM passwords must be changed
periodically in accordance with the information security policy and
enterprise requirements. These passwords should be disseminated in a
secure manner and in accordance with corporate security standards and
guidelines. The security administrator must have a procedure to change
the SYS and SYSTEM passwords in the event of an emergency.
The relationship among policies, standards and technical controls makes it
essential for system administrators to understand how day-to-day operational
activities relate to corporate security objectives. Of course, it is not enough
that these documents exist; it is important to ensure that system and database
administrators know, understand and implement the policies, standards and
technical controls, as shown in figure 3.1.
Figure 3.1Sample Organization Policy Model

Policy
(senior management, regulatory,
advisory, informative)

Standards
(use of specific technologies in
uniform way)

Technical Controls
Guidelines (recommended actions
that are not compulsory)
Procedures (steps to perform a
specific task in compliance with a
mandatory standard)

Enterprises may have different models for their policies and standards. For
example, an enterprises model may consist of a hierarchy of policies (senior
management, regulatory, advisory, informative), standards (use of specific
technologies in a uniform way), guidelines (recommended actions that are not
compulsory), and procedures (steps to perform a specific task in compliance
with a mandatory standard). It is important to review an enterprises model and
understand how it relates to database security.

12

4. Oracle Database System Architecture Overview

4. Oracle Database System Architecture

Overview
Chapter Overview
An individual performing an IT audit should understand the architecture of the
system being audited. Understanding the system architecture gives the assessor
a high-level, logical perspective of how the technology operates and interfaces
with other systems. This chapter provides a high-level overview of the database
architecture and gives the assessor a basic understanding of the database
components that exist on a system.
When system architecture is referenced in this book, it refers to the logical
design of the database architecture and related components. The assessor should
understand the database architecture and how Oracle Database is designed to
promote a secure and reliable operating environment. In this section, a high-level
overview of the database architecture is provided. An overview of key Oracle
Database components is illustrated in figure 4.1.
Figure 4.1High-level Database Architecture

Client Process
Oracle Instance
Shadow
Thread

System Global Area

Shared Pool

Memory
Structures

Library Cache
Data Dictionary Cache

Recover
(RECO)

System
Monitor
(SMON)

Database
Writer
(DBWO)

Database
Buffer Cache

Process
Monitor
(PMON)

Redo Log
Buffer

Checkpoint
(CKPT)

Log
Writer
(LGWR)

Archiver
(ARCO)

Oracle Database

Oracle
Processes
(background
processes)

Parameter File

Data Files

Control Files

Redo Log Files

Archived
Log
FIles

Password File

13

Security, Audit and Control Features Oracle Database, 3rd Edition

Instance vs. Database

Before discussing the Oracle Database architecture, the reader must understand
the difference between a database and an instance. These words often are used
interchangeably when referring to an Oracle Database environment, but there is
an important distinction between them. A database is a collection of physical files
residing on one or more disks that store and organize data. The database structure
consists primarily of user-defined data, metadata (data describing other data),
and control files used to manage the integrity and availability of the data. For
example, the metadata defined in the Oracle data dictionary provide the necessary
information for the Oracle software to manage user data. A database is made up of
one or more data files, and data files are grouped together to form a tablespace.
An Oracle instance refers to the collection of background operating system
processes used to update, retrieve and manage the user data, metadata and control
files associated with the database. Further, a database instance can be viewed as
the data in the database at a particular point in time. The database instance also
consists of a group of shared memory areas known as the System Global Area
(SGA), used to support the background processes and memory allocation for the
instance. The assessor should not confuse these terms when auditing or discussing
Oracle Database.

Tablespace
A tablespace is a logical collection of data files and must be defined before data
can be entered into the database. It is composed of segments that hold various
database objects (e.g., tables, views, indexes, stored procedures). The segments
within a tablespace store data in a logical entity called an extent, which in turn
consists of one or more blocks. The block size in a database is determined when
the database is first created. Information about the data to be stored is created
within the data dictionary of the database, which is owned by the user SYS. Oracle
ships with many predefined data dictionary views, or catalog views, which permit
users to query the data dictionary to obtain descriptive data about objects stored
in the database. As an example, catalog views exist to obtain a listing of all tables
residing in a database along with descriptive data such as column names, data
types of the columns and constraints enforced on the data. Also, several catalog
views exist to obtain security-relevant information for the database, including
privileges for database objects and users and audit logging configurations. What
is commonly referred to as metadata, and the catalog views can be used to query
information for any default or user-defined tablespace. The following tablespaces
are either built in or common to many databases:
System tablespaceIncludes system data that the database needs to manage
itself and holds the data dictionary (metadata of the database). It must always
exist, and cannot be taken offline when the instance is running and has the
database open.
14

4. Oracle Database System Architecture Overview

Temp tablespaceOracles temporary clipboard. This tablespace is used by the
database to manage its own transactions or transactions on behalf of a user, such
as sorting data from an ORDER BY clause in a query.
Tools tablespaceStores the objects used by tools that interact with the database
Users tablespaceStores a users personal objects
Rollback tablespaceWhere the rollback segments are stored. These rollback
segments are used by the database to roll back data when a database or
transaction failure occurs or users explicitly execute a rollback command to undo
any uncommitted changes they may have performed in the database.
Data and index tablespacesUsed to store the application data

Server Processes
An Oracle instance runs as several processes on the host operating system. Each
instance has a set of processes that interacts only with the data files associated with
that particular instance. Further, to ensure the integrity of the database, no other
system processes should be allowed to interact with any of the data files. Four
essential processes are required for any instance to function properly: DBWn,
LGWR, PMON and SMON. Other processes are introduced when additional
database components, such as the Queue Monitor, are enabled. Key Oracle
Database processes and their descriptions are listed in figure 4.2.
Figure 4.2Key Oracle Database Process Names
Process Name

Process Description

DBWn (Database Writer)

Writes data from the database buffer cache to the data files; multiple
database writer processes can exist

LGWR (Log Writer)

Writes redo logs to disk

CKPT (Checkpoint)

Responsible for signaling the database writer process at checkpoints

for recovery purposes

SMON (System Monitor)

Manages database recovery that may be required at start-up

PMON (Process Monitor)

Monitors for user sessions that are prematurely disconnected and

handles cleanup

ARCn (Archiver)

Copies redo log files to the archive file destination

RECO (Recoverer)

Resolves pending transactions as a result of a failure

Dnnn (Dispatcher)

Optional process used when shared server configuration is enabled

CJQ0 (Job Queue)

Manages batch processing and job scheduling

LMS (Global Cache

Service)

Manages resources in Oracle Real Application Clusters

QMNn (Queue
Monitor)optional

Optional process used when Oracle Streams Advanced Queuing is

used to monitor message queues

LCK (Lock)

Optional process used to manage instances in a parallel server

configuration
15

Security, Audit and Control Features Oracle Database, 3rd Edition

On UNIX systems, the Oracle processes are referred to as background processes
because they run in the background, independently of other processes. The
command ps ef on most UNIX systems will display a listing of running
processes. This command can be used in conjunction with grep to view only
those processes associated with a particular database instance. For example, to
view all of the processes associated with the instance test, issue the command in
figure 4.3.
Figure 4.3UNIX Command to View Oracle Processes
$ ps -ef | grep test
oracle 2616

1 0 16:05 ?

00:00:00 ora_pmon_test

oracle 2618

1 0 16:05 ?

00:00:00 ora_vktm_test

oracle 2622

1 0 16:05 ?

00:00:00 ora_diag_test

oracle 2624

1 0 16:05 ?

00:00:00 ora_dbrm_test

oracle 2626

1 0 16:05 ?

00:00:00 ora_psp0_test

oracle 2630

1 0 16:05 ?

00:00:00 ora_dia0_test

oracle 2632

1 1 16:05 ?

00:00:05 ora_mman_test

oracle 2634

1 0 16:05 ?

00:00:00 ora_dbw0_test

oracle 2636

1 0 16:05 ?

00:00:01 ora_lgwr_test

oracle 2638

1 0 16:05 ?

00:00:00 ora_ckpt_test

oracle 2640

1 0 16:05 ?

00:00:03 ora_smon_test

oracle 2642

1 0 16:05 ?

00:00:00 ora_reco_test

oracle 2644

1 1 16:05 ?

00:00:05 ora_mmon_test

oracle 2646

1 0 16:05 ?

00:00:00 ora_mmnl_test

oracle 2649

1 0 16:05 ?

00:00:00 ora_d000_test

oracle 2651

1 0 16:05 ?

00:00:00 ora_s000_test

oracle 2659

1 0 16:06 ?

00:00:00 ora_fbda_test

oracle 2661

1 0 16:06 ?

00:00:00 ora_smco_test

oracle 2663

1 0 16:06 ?

00:00:00 ora_qmnc_test

oracle 2665

1 0 16:06 ?

00:00:00 ora_w000_test

oracle 2667

1 0 16:06 ?

00:00:00 ora_q000_test

oracle 2669

1 0 16:06 ?

00:00:00 ora_q001_test

oracle 2817

1 0 16:10 ?

00:00:00 ora_cjq0_test

In figure 4.3, there are multiple processes associated with the database instance.
These processes include the essential processes as well as the Recoverer
(ora_reco_test), Checkpoint (ora_ckpt_test), Job Queue
(ora_cjq0_test), and other background processes performing various
maintenance tasks.
16

4. Oracle Database System Architecture Overview

In a Microsoft Windows Server environment, the Oracle processes run as threads
within a single system process. Since threads are not displayed in the Windows
Task Manager, the specific Oracle threads can be monitored using the Oracle
Administration Assistant (installed by default during database installation).
Figure 4.4 shows how the Oracle Database threads can be displayed using the
Oracle Administration Assistant.
Figure 4.4Oracle Administration Assistant for Windows Displaying Oracle Database Threads

Note: In many client environments, the monitoring of operating system processes is

handled by system administrators and does not fall under the responsibility of DBAs.
In these environments, it is imperative that DBAs ensure that there is an automated
system in place to monitor key database system processes and notify appropriate
personnel in the event that they are not running. The assessor should ensure that the
key database processes are running on the database server. Termination of these
processes can lead to availability, recoverability and connectivity issues.

File Structure
The Oracle Database file structure is comprised of the following types of files:
Physical data files
Oracle software files
Parameter files
Control files
Log/trace files
Key Point
Operating system security and backups often fall outside of the control of the
database administration group. While the responsibility for securing and backing
up these files may not fall under their direct control, it is critical that DBAs take
an active role in the process to ensure database integrity and availability.
17

Security, Audit and Control Features Oracle Database, 3rd Edition

Physical data files include all files that store the database data. These include
rollback segments, redo logs, audit files (if implemented) and files that form the
basis for tablespaces and indices. These files are crucial to the functionality of the
database. They typically have the extension .dbf.
Oracle software files typically hold the database servers binary code and the code
of all of the other programs that together constitute the database functionality. The
library, Java and listener files are all classified under this category.
Parameter files store configuration information about the database server and
the database instance. They include the location of control files, log files and the
init.ora file, as well as data regarding the amount of memory available for
Oracles data buffer.
During start-up, the database uses the init.ora file to set the memory space,
file locations, audit settings, etc. Before changes to this file will take effect, the
database needs to be restarted. Alternatively, the ALTER SYSTEM command can
be used to dynamically adjust system settings without restarting the database. The
current system settings can be viewed in the V$PARAMETER view at any time.
The control file is a small binary file that contains information about the database
instance and is needed to start the database. All major changes to the structure
of the database are recorded in the control file. If the control file is corrupted
or missing, it is very difficult to start the database instance; therefore, it is good
practice to have multiple copies of the control file.
Log files, which include trace files generated by the database to facilitate
troubleshooting, make up the last component of the database file structure.
Log files contain a sequential list of all changes to the data in the database. The
alert.log file stores any server messages that are generated by the database
server.
During installation of Oracle Database, an environment variable called
ORACLE_BASE is used to define the base directory for the Oracle software. A
common ORACLE_BASE location for UNIX or Linux systems is /app/oracle.
Another variable, ORACLE_HOME is a subdirectory of the ORACLE_BASE
location and contains subdirectories, binaries, scripts and other files for each database
instance. The default file structure of the database is shown in figure 4.5, and
subdirectories located in the ORACLE_HOME path are shown in figure 4.6.
Note: The Oracle directory structure is similar across different platforms, such as
Windows.

18

4. Oracle Database System Architecture Overview

Figure 4.5Oracle Default File Structure (ORACLE_BASE)

Figure 4.6Oracle Home Subdirectories (ORACLE_HOME)

Memory Structure
There are two types of memory areas: system global area (SGA) and program
global area (PGA). The SGA memory area is used by Oracle to store pertinent
information about itself. All server and client processes share the SGA. Its four
components are:
Data cache
19

Security, Audit and Control Features Oracle Database, 3rd Edition

Dictionary cache
Redo log
Shared SQL pool
Before a user process can access information out of the database, the information
must first reside in the SGA. PGA is an area of memory that is used by a single
Oracle process and is not shared among processes. The PGA contains data and
control information for a single processinformation such as process variables
and internal arrays.

Oracle Net
Oracle Net is comprised of client and server software that enables applications
and Oracle Database to communicate over the network. The Oracle Net Listener
is a process that listens for incoming connection requests on the network. The
listener.ora and tnsnames.ora files both contain network configuration
settings related to the Oracle Database and available services. Both of these files
are stored in the ORACLE_HOME/network/admin directory on UNIX/Linux
operating systems and the %ORACLE_HOME%/network/admin directory on
Windows systems. The listener.ora file defines the Oracle Net Listener
configuration, including the name of the listener, protocol addresses on which the
listener is accepting requests, and a list of database services. The tnsnames.
ora file is a configuration file that defines Oracle Net service names (SIDs)
mapped to listener protocol addresses. The following sample tnsnames.ora
file defines a connect descriptor for database SID prod1.
DBNAME =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 172.168.2.3)
(PORT = 1521)))
(CONNECT_DATA =
(SID = prod1)
(SERVER = DEDICATED)))
Unauthorized access to the tnsnames.ora file can provide the necessary
information for a malicious user to connect to Oracle Database or negatively
impact the availability of the database. Refer to chapter 13, Network Security, for
more information related to the TNS Listener and how Oracle Advanced Security
can be used to implement secure network communication protocols.

END OF EXCERPT

20