Security, Audit and Control Features Oracle Database Audit and Control Features Oracle® Database, 3rd Edition ii ISACA® With more than 86,000 constituents in more than 160 countries,

Security, Audit and Control Features

Technical and Risk Management Reference Series

Oracle®

Database3rd Edition

Excerpt—Executive Summary Through Chapter 4. Oracle Database System Architecture Overview

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

ii

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.

DisclaimerISACA 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 material’s source. No other right or permission is granted with respect to this work.

ISACA3701 Algonquin Road, Suite 1010 Rolling Meadows, IL 60008 USAPhone: +1.847.253.1545 Fax: +1.847.253.1443E-mail: [email protected] Web site: www.isaca.org

ISBN 978-1-60420-118-5Security, 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.

Acknowledgments

iii

AcknowledgmentsISACA wishes to recognize:

Researchers Rik Boren, CISA, CISM, CISSP, CPA, PricewaterhouseCoopers LLP, USADavid W. Stanton, CISM, CISSP, PricewaterhouseCoopers LLP, USAIgor Oreper, PricewaterhouseCoopers LLP, USAPhilip D. Wainwright, PricewaterhouseCoopers LLP, USARoger Heiniluoma, CIMA Energy, USA

Expert Reviewers Emmanuel Osei Kwame Adjei, Kofi Annan Centre of Excellence-Advanced Information Technology

Institute, GhanaAkin Akinbosoye, CISA, CISM, CGEIT, PMI-RMP, Healthcare Corporation of America, USAKelvin J. Arcelay, CISA, CISSP, HISP, IRCA ISMS Auditor, PMP, SSGB, Arcelay and Associates

LLC, USADeepak Agrawal, CISA, CISM, CISSP, PMP, PricewaterhouseCoopers, IndiaJeffrey T. Hare, CISA CPA CIA, ERP Seminars, USAKamal Khan, CISA, CISSP, CITP, Saudi Aramco, Saudi ArabiaPrashant A. Khopkar, CISA, CA, USAArbogast Celestine Kihaule, CISA, OCP9i, IT Consultant, TanzaniaStephen Kost, Integrigy Corporation, USALarry Marks, CISA, CGEIT, CFE, CISSP, CSTE, PMP, Resources Global Professionals, USAK.K. Mookhey, CISA, CISM, CISP, Network Intelligence, IndiaFelix Ramirez, CISA, CGEIT, Riebeeck Stevens Ltd., USANitin Sood, CISM, CISSP, CSSLP, OCA, PMP, Independent Consultant, CanadaPeter Tessin, CISA, PMP, Altran Control Solutions, USASanjay Kumar Vaid, CISA, CISM, CGEIT, BelgiumJinu Varghese, CISA, CISSP, OCA, PricewaterhouseCoopers LLP, Canada

ISACA Board of DirectorsEmil D’Angelo, CISA, CISM, Bank of Tokyo-Mitsubishi UFJ Ltd., USA, International PresidentGeorge Ataya, CISA, CISM, CGEIT, CISSP, ICT Control SA-NV, Belgium, Vice PresidentYonosuke Harada, CISA, CISM, CGEIT, CAIS, InfoCom Research Inc., Japan, Vice PresidentRia Lucas, CISA, CGEIT, Telstra Corporation Ltd., Australia, Vice PresidentJose Angel Pena Ibarra, CGEIT, Alintec, Mexico, Vice PresidentRobert E. Stroud, CGEIT, CA Inc., USA, Vice PresidentKenneth L. Vander Wal, CISA, CPA, Ernst & Young LLP (retired), USA, Vice PresidentRolf von Roessing, CISA, CISM, CGEIT, KPMG Germany, Germany, Vice PresidentLynn Lawton, CISA, FBCS CITP, FCA, FIIA, KPMG LLP, UK, Past International PresidentEverett C. Johnson Jr., CPA, Deloitte & Touche LLP (retired), USA, Past International PresidentGregory T. Grocholski, CISA, The Dow Chemical Co., USA, DirectorTony Hayes, CGEIT, AFCHSE, CHE, FACS, FCPA, FIIA, Queensland Government,

Australia, DirectorHoward Nicholson, CISA, CGEIT, City of Salisbury, Australia, DirectorJeff Spivey, CPP, PSP, Security Risk Management, USA, Trustee

Knowledge BoardGregory T. Grocholski, CISA, The Dow Chemical Co., USA, ChairMichael Berardi Jr., CISA, CGEIT, Energizer, USAJohn Ho Chi, CISA, CISM, CBCP, CFE, Ernst & Young, SingaporeJose Angel Pena Ibarra, CGEIT, Alintec, MexicoJo Stewart-Rattray, CISA, CISM, CGEIT, CSEPS, RSM Bird Cameron, AustraliaJon Singleton, CISA, FCA, Auditor General of Manitoba (retired), CanadaPatrick Stachtchenko, CISA, CGEIT, CA, Stachtchenko & Associates SAS, FranceKenneth L. Vander Wal, CISA, CPA, Ernst & Young LLP (retired), USA


iv

Acknowledgments (cont.)Guidance and Practices CommitteeKenneth L. Vander Wal, CISA, CPA, Ernst & Young LLP (retired), USA, ChairPhillip J. Langeschulte, CGEIT, CPA, KPMG LLP, USAMark A. Lobel, CISA, CISM, CISSP, PricewaterhouseCoopers LLP, USAAdel H. Melek, CISA, CISM, CGEIT, CISSP, Deloitte & Touche, CanadaRavi Muthukrishnan, CISA, CISM, FCA, ISCA, Capco IT Service India Private Ltd, India Anthony P. Noble, CISA, CCP, Viacom Inc., USASalamon Rico, CISA, CISM, CGEIT, Deloitte, MexicoEddy Schuermans, CISA, CGEIT, ESRAS bv ba, BelgiumFrank Van Der Zwaag, CISA, CISSP, Westpac, New Zealand

To the ISACA Chicago chapter for its financial support

Table of Contents

v

ExECuTIvE SummARy ................................................................................... 1

1. InTRoDuCTIon ........................................................................................... 3Intended Audience ............................................................................................. 3Conventions/Explanations of Illustrations ........................................................ 3Overall Audit Approach .................................................................................... 4A Brief History of Oracle Database Security .................................................... 4

2. SECuRITy AnD ConTRol APPRoACh/FRAmEwoRK ................. 9

3. SECuRITy PolICIES................................................................................. 11

4. oRAClE DATABASE SySTEm ARChITECTuRE ovERvIEw ..... 13Instance vs. Database ....................................................................................... 14Tablespace ........................................................................................................ 14Server Processes .............................................................................................. 15File Structure .................................................................................................... 17Memory Structure ............................................................................................ 19Oracle Net ........................................................................................................ 20

5. PlAnnInG ThE AuDIT............................................................................. 21

6. unDERSTAnDInG ThE IT EnvIRonmEnT ...................................... 23

7. oPERATInG SySTEm SECuRITy ......................................................... 27Risks Associated With Poor OS Security ....................................................... 27Controls ............................................................................................................ 28

8. nEw FEATuRES .......................................................................................... 35Oracle 10g—New Security Features ............................................................... 35Oracle 11g—New Security Features .............................................................. 37

9. DATABASE SECuRITy PRIvIlEGES ................................................... 39System Privileges ............................................................................................. 40

10. ACCESS ConTRol .................................................................................... 43Roles ................................................................................................................. 43Stored Procedures and Triggers ...................................................................... 56ALL_SOURCE View ...................................................................................... 58Data Dictionary ................................................................................................ 59Encryption of Database Records ..................................................................... 62Database Access .............................................................................................. 65Emergency Access ........................................................................................... 70Generic Accounts ............................................................................................. 70Password Controls ........................................................................................... 71Resource Limits ............................................................................................... 74

Table of Contents


vi

11. AuDITInG AnD loG FIlES .................................................................... 79

12. TRuSTED RElATIonShIPS .................................................................... 85Protecting the DBLINK (SYS.LINK$) ........................................................... 87Operating System Authentication ................................................................... 87Remote Operating System Authentication ...................................................... 89OSOPER, OSDBA and OSASM Access ............................................................ 89

13. nETwoRK SECuRITy .............................................................................. 91TNS Listener .................................................................................................... 91Firewalls ........................................................................................................... 93Valid Node Checking ...................................................................................... 94Oracle Advanced Security ............................................................................... 95

14. GEnERAl ConTRolS .............................................................................. 99Change Management ....................................................................................... 99Information Classification ............................................................................... 99Segregation of Duties .................................................................................... 100System Development Life Cycle ................................................................... 101Documentation ............................................................................................... 102Monitoring ..................................................................................................... 102Intrusion Response ......................................................................................... 103Vulnerability and Patch Management ........................................................... 104Security Awareness ....................................................................................... 104Backup and Recovery .................................................................................... 104Logical Backups ............................................................................................ 106Physical Backups ........................................................................................... 106Recovery Manager ........................................................................................ 107

15. APPlICATIon SECuRITy ..................................................................... 109

16. ToolS .......................................................................................................... 113Oracle Enterprise Manager ............................................................................ 113Oracle SQL Developer .................................................................................. 118Tool for Oracle Application Developers ...................................................... 119UTL_FILE Package ....................................................................................... 120UTL_HTTP Package ..................................................................................... 121UTL_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

Table of Contents

vii

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


viii

Page intentionally left blank

Executive Summary

1

Executive SummaryAs 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.


2

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

3

1. IntroductionAn 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.


4

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 process-related 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

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.

1. Introduction

5

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 added-cost 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


6

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.

1. Introduction

7

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—10g introduced column-level security and masking, which enabled finer-

grained 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


8

• 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_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. Security and Control Approach/Framework

9

2. Security and Control Approach/FrameworkChapter 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 enterprise’s 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:• 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.


10

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

3. Security Policies

11

3. Security PoliciesChapter 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 CobiT 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 ExamplePCI 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


12

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

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.

Policy(senior management, regulatory,

advisory, informative)

Standards(use of specific technologies in

uniform way)

Technical ControlsGuidelines (recommended actionsthat are not compulsory)Procedures (steps to perform aspecific task in compliance with amandatory standard)

4. Oracle Database System Architecture Overview

13


Chapter OverviewAn 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

OracleProcesses(backgroundprocesses)

ProcessMonitor(PMON)

SystemMonitor(SMON)

ShadowThread

Recover(RECO)

DatabaseWriter

(DBWO)

Checkpoint(CKPT)

LogWriter

(LGWR)

Archiver(ARCO)

Data Files Control Files Redo Log Files

ArchivedLogFIles

Password File

Parameter File

Oracle Database

Client Process

Oracle Instance

System Global AreaShared Pool

Redo LogBuffer

MemoryStructures

DatabaseBuffer CacheData Dictionary Cache

Library Cache


14

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


15

• 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

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.2—Key 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


16

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.


17

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.

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


18

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.


19

Figure 4.5—Oracle Default File Structure (ORACLE_BASE)

Figure 4.6—Oracle 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


20

• 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

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