rd

Security, Audit and Control Features Oracle ® Database, 3 rd 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 C obi
T ® , 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, 3 rd 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 material’s 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, 3 rd 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
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 D’Angelo, 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, 3 rd Edition
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
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 10g—New Security Features ............................................................... 35
Oracle 11g—New 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, 3 rd 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. C obi
T ® 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, 3 rd Edition
Page intentionally left blank viii

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 assessor’s 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
Database’s 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.
1

Security, Audit and Control Features Oracle ® Database, 3 rd 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.
2

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

Security, Audit and Control Features Oracle ® Database, 3 rd 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.1—Font 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 user—A person who accesses the system to perform business processrelated functions
• Database administrator—A person who is responsible for the maintenance and support of the database
• Security administrator—The primary person responsible for administering security for an environment
• Vendor—A third party that is temporarily engaged to address an issue or provide support for the system
• Contractor—A third party that is engaged to assist in system implementation, administration and support
• Developer—A person responsible for creating or changing application functions
This book recommends a risk-based IT audit approach based on the C obi
T ® 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.
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 Oracle’s 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, 3 rd 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 protection”—a 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 encryption—This 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 Security—This 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.
6

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 individual’s 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
Oracle’s 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:
• VPD—10 g 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 installation—The default passwords, which an administrator had to change immediately, had to now be changed as part of the installation process.
• FGA—Data 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 encryption—As 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 users—Secure logins over the network for privileged users with SYSDBA and SYSOPER privileges using Kerberos or
Secure Sockets Layer (SSL) were required.
• Oracle Database Vault—This 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 Oracle, “Best Practices,” 2008, www.oracle.com/technology/deploy/security/database-security/pdf/ twp_database_vault_bestpractices_20080219.pdf
7

Security, Audit and Control Features Oracle ® Database, 3 rd Edition
• Oracle Audit Vault—This 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 security—Several 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 services—As 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 enhancements—Several 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
2 Oracle, “Best Practices,” 2007, www.oracle.com/technology/products/audit-vault/pdf/twp_auditvault_
3 bestpractices_200711.pdf
Newman, Aron; Marlene Theriault; Oracle Security Handbook: Implement a Sound Security Plan in
Your Oracle Environment, Osborne/McGraw-Hill, USA, 2001, p. 36-70
8

2. Security and Control Approach/Framework
Chapter Overview
The C obi
T 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 C obi
T 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 enterprise’s systems and implement the right level of controls to mitigate those risks. C obi
T is a framework or tool that provides clear policies and good practices for IT control from a business perspective. The C obi
T 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. C obi
T includes 34 key IT processes grouped into the following four domains (refer to appendix 6 for additional information on the C obi
T 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 C obi
T 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 C obi
T control objectives to help the reader view the specific detailed Oracle controls from the overall business risk and control perspective provided by the C obi
T framework. These control objectives are specifically intended to help an organization meet the following security requirements:
• Confidentiality—Relates 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, 3 rd 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).
• Integrity—Relates 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
• Availability—Relates 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
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 enterprise’s 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
C obi
T control objectives: DS5.1 and PO2.3.
Policies should communicate management’s 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 enterprise’s 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, 3 rd 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.1—Sample Organization Policy Model
(senior management, regulatory, advisory, informative)
(use of specific technologies in uniform way)
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 enterprise’s 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 enterprise’s model and understand how it relates to database security.
12

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.1—High-level Database Architecture
Oracle Instance
Shared Pool
Library Cache
Data Dictionary Cache
Client Process
Shadow
Thread
System Global Area
Database
Buffer Cache
Redo Log
Buffer
Memory
Structures
Recover
(RECO)
System
Monitor
(SMON)
Database
Writer
(DBWO)
Oracle Database
Process
Monitor
(PMON)
Checkpoint
(CKPT)
Log
Writer
(LGWR)
Archiver
(ARCO)
Oracle
Processes
(background processes)
Parameter File
Data Files
Archived
Log
FIles
Password File
Control Files Redo Log Files
13

Security, Audit and Control Features Oracle ® Database, 3 rd Edition
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.
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 tablespace—Includes 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 tablespace—Oracle’s 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 tablespace—Stores the objects used by tools that interact with the database
• User’s tablespace—Stores a user’s personal objects
• Rollback tablespace—Where 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 tablespaces—Used to store the application data
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
.
Process Name
Figure 4.2—Key Oracle Database Process Names
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)
CKPT (Checkpoint)
Writes redo logs to disk
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)
D nnn (Dispatcher)
CJQ0 (Job Queue)
Resolves pending transactions as a result of a failure
Optional process used when shared server configuration is enabled
Manages batch processing and job scheduling
Manages resources in Oracle Real Application Clusters LMS (Global Cache
Service)
QMNn (Queue
Monitor)—optional
LCK (Lock)
Optional process used when Oracle Streams Advanced Queuing is used to monitor message queues
Optional process used to manage instances in a parallel server configuration
15

Security, Audit and Control Features Oracle ® Database, 3 rd 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.3—UNIX 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.4—Oracle 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.
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, 3 rd 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 server’s 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
Oracle’s 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.5—Oracle Default File Structure (ORACLE_BASE)
Figure 4.6—Oracle Home Subdirectories (ORACLE_HOME)
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, 3 rd 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 process—information such as process variables and internal arrays.
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.
20