Security, Audit and Control Features Oracle Database

Transcription

1 Technical and Risk Management Reference Series Security, Audit and Control Features Oracle Database 3 rd Edition Excerpt Executive Summary Through Chapter 4. Oracle Database System Architecture Overview

2 Security, Audit and Control Features Oracle Database, 3 rd Edition ISACA With more than 86,000 constituents in more than 160 countries, ISACA ( is a leading global provider of knowledge, certifications, community, advocacy and education on information systems assurance and security, enterprise governance of IT, and IT-related risk and compliance. Founded in 1969, ISACA sponsors international conferences, publishes the ISACA Journal, and develops international information systems auditing and control standards. It also administers the globally respected Certified Information Systems Auditor (CISA ), Certified Information Security Manager (CISM ) and Certified in the Governance of Enterprise IT (CGEIT ) designations. ISACA developed and continually updates the CobiT, Val IT and Risk IT frameworks, which help IT professionals and enterprise leaders fulfill their IT governance responsibilities and deliver value to the business. Disclaimer ISACA has designed and created Security, Audit and Control Features Oracle Database, 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 USA Phone: Fax: [email protected] Web site: ISBN 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

3 Acknowledgments Acknowledgments ISACA wishes to recognize: Researchers Rik Boren, CISA, CISM, CISSP, CPA, PricewaterhouseCoopers LLP, USA David W. Stanton, CISM, CISSP, PricewaterhouseCoopers LLP, USA Igor Oreper, PricewaterhouseCoopers LLP, USA Philip D. Wainwright, PricewaterhouseCoopers LLP, USA Roger Heiniluoma, CIMA Energy, USA Expert Reviewers Emmanuel Osei Kwame Adjei, Kofi Annan Centre of Excellence-Advanced Information Technology Institute, Ghana Akin Akinbosoye, CISA, CISM, CGEIT, PMI-RMP, Healthcare Corporation of America, USA Kelvin J. Arcelay, CISA, CISSP, HISP, IRCA ISMS Auditor, PMP, SSGB, Arcelay and Associates LLC, USA Deepak Agrawal, CISA, CISM, CISSP, PMP, PricewaterhouseCoopers, India Jeffrey T. Hare, CISA CPA CIA, ERP Seminars, USA Kamal Khan, CISA, CISSP, CITP, Saudi Aramco, Saudi Arabia Prashant A. Khopkar, CISA, CA, USA Arbogast Celestine Kihaule, CISA, OCP9i, IT Consultant, Tanzania Stephen Kost, Integrigy Corporation, USA Larry Marks, CISA, CGEIT, CFE, CISSP, CSTE, PMP, Resources Global Professionals, USA K.K. Mookhey, CISA, CISM, CISP, Network Intelligence, India Felix Ramirez, CISA, CGEIT, Riebeeck Stevens Ltd., USA Nitin Sood, CISM, CISSP, CSSLP, OCA, PMP, Independent Consultant, Canada Peter Tessin, CISA, PMP, Altran Control Solutions, USA Sanjay Kumar Vaid, CISA, CISM, CGEIT, Belgium Jinu Varghese, CISA, CISSP, OCA, PricewaterhouseCoopers LLP, Canada ISACA Board of Directors Emil 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

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

5 Table of Contents Table of Contents Executive Summary Introduction... 3 Intended Audience... 3 Conventions/Explanations of Illustrations... 3 Overall Audit Approach... 4 A Brief History of Oracle Database Security Security and Control Approach/Framework Security Policies Oracle Database System Architecture Overview Instance vs. Database Tablespace Server Processes File Structure Memory Structure Oracle Net Planning the Audit Understanding the IT Environment Operating System Security Risks Associated With Poor OS Security Controls New Features Oracle 10g New Security Features Oracle 11g New Security Features Database Security Privileges System Privileges Access Control Roles Stored Procedures and Triggers ALL_SOURCE View Data Dictionary Encryption of Database Records Database Access Emergency Access Generic Accounts Password Controls Resource Limits v

6 Security, Audit and Control Features Oracle Database, 3 rd Edition 11. Auditing and Log Files Trusted Relationships Protecting the DBLINK (SYS.LINK$) Operating System Authentication Remote Operating System Authentication OSOPER, OSDBA and OSASM Access Network Security TNS Listener Firewalls Valid Node Checking Oracle Advanced Security General Controls Change Management Information Classification Segregation of Duties System Development Life Cycle Documentation Monitoring Intrusion Response Vulnerability and Patch Management Security Awareness Backup and Recovery Logical Backups Physical Backups Recovery Manager Application Security Tools Oracle Enterprise Manager Oracle SQL Developer Tool for Oracle Application Developers UTL_FILE Package UTL_HTTP Package UTL_INADDR Package Appendix 1. Automated Assessment Tool Recommendations Appendix 2. Audit/Assurance Program and Internal Control Questionnaire Appendix 3. Questions and Answers Appendix 4. Recommendations for the Professional vi

7 Table of Contents Appendix 5. Frequently Asked Questions Appendix 6. CobiT References Appendix 7. Glossary Appendix 8. Acronyms Appendix 9. Reading Suggestions Appendix 10. References ISACA Professional Guidance Publications Index vii

8 Security, Audit and Control Features Oracle Database, 3 rd Edition Page intentionally left blank viii

9 Executive Summary Executive Summary As systems have migrated from mainframe to client-server and multitiered web application environments, the criticality of protecting the relational database has grown steadily over the last decade. The confidentiality, integrity and availability requirements of the database tier are at an all-time high. Consumers of information (e.g., employees, customers and business partners) all demand instant access to data in a near real-time and accurate manner. Further, the level of awareness around securing the database has steadily increased over the years due to increased legal and regulatory compliance requirements. Enterprises continue to realize the business impact that could result from a data security breach, including financial loss, negative perception in the marketplace and loss of shareholder value. These factors have led to higher security expectations of database administrators, application developers and the 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

10 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

11 1. Introduction 1. Introduction An effective approach to assessing security must consider security controls at each layer of the system or application architecture (e.g., application, operating system, database, network and physical levels). A security weakness within any component of the system may lead to the compromise of the entire system. In many system environments, an Oracle Database is a key component of the system architecture. Before the US Sarbanes-Oxley Act, many IT audits focused on application, network and operating system controls, often overlooking the database layer entirely. However, the database is usually the repository or authoritative source of critical business data and sensitive customer or employee data that are heavily regulated. Unauthorized access to the database can also lead to unauthorized access to the underlying operating system, which could allow an attacker to compromise additional systems and databases on the network. As a result, the database should be included as a key component of any systems security audit. This book provides the reader with the knowledge and tools to effectively audit an Oracle Database 11g environment. At the time of the writing of this book, Oracle Database 11g is the most recent version released by Oracle. Because older versions of Oracle Database are still prevalent in the industry and fully supported by Oracle, including Oracle Database 9i and 10g, many of the concepts discussed for Oracle Database 11g will also apply to older versions, unless otherwise specified. Intended Audience The primary audience of this book is assessors who review and assess the security of environments that include an Oracle Database component. Other audiences, such as information security practitioners and database administrators (DBAs), also will find this book useful to understand and assess Oracle security risks. The intended audience for this book should already have an existing high-level knowledge of Oracle Database technologies and understand general auditing and security concepts. Conventions/Explanations of Illustrations The objective of this book is to provide the reader with a practical, real-world approach to auditing Oracle Database security. Case studies and examples are provided and identified in grey boxes, titled Real-world Examples, to illustrate different concepts. Although these examples are based on real-world scenarios, it is difficult to relate in a single example to the varied environments where Oracle Database is implemented. With that said, it is hoped that readers will be able to relate the context in the examples to their own environments. 3

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

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

14 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

15 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 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 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, twp_database_vault_bestpractices_ pdf 7

16 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, bestpractices_ pdf 3 Newman, Aron; Marlene Theriault; Oracle Security Handbook: Implement a Sound Security Plan in Your Oracle Environment, Osborne/McGraw-Hill, USA, 2001, p

17 2. Security and Control Approach/Framework 2. Security and Control Approach/Framework Chapter Overview The CobiT framework provides a structure for developing control objectives. These objectives are enforced through technical features provided by Oracle, organizational policies and standards, management commitment to security, people, and processes. This chapter describes the IT control approach of the CobiT framework, which serves as the foundation for the audit approach discussed in this book. It is the responsibility of management to understand the risks related to the 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. 9

18 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 10

19 3. Security Policies 3. Security Policies Chapter Overview Clear, consistent and enforceable information security policies are important to every enterprise, regardless of the level of information security required. Security policies help protect the 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 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

20 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 Policy (senior management, regulatory, advisory, informative) Standards (use of specific technologies in uniform way) Technical Controls Guidelines (recommended actions that are not compulsory) Procedures (steps to perform a specific task in compliance with a mandatory standard) Enterprises may have different models for their policies and standards. For example, an 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

21 4. Oracle Database System Architecture Overview 4. Oracle Database System Architecture Overview Chapter Overview An individual performing an IT audit should understand the architecture of the system being audited. Understanding the system architecture gives the assessor a high-level, logical perspective of how the technology operates and interfaces with other systems. This chapter provides a high-level overview of the database architecture and gives the assessor a basic understanding of the database components that exist on a system. When system architecture is referenced in this book, it refers to the logical design of the database architecture and related components. The assessor should understand the database architecture and how Oracle Database is designed to promote a secure and reliable operating environment. In this section, a high-level overview of the database architecture is provided. An overview of key Oracle Database components is illustrated in figure 4.1. Figure 4.1 High-level Database Architecture Client Process Oracle Instance Shadow Thread Shared Pool Library Cache System Global Area Memory Structures Data Dictionary Cache Database Buffer Cache Redo Log Buffer 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 Control Files Redo Log Files Archived Log FIles Password File 13

22 Security, Audit and Control Features Oracle Database, 3 rd Edition Instance vs. Database Before discussing the Oracle Database architecture, the reader must understand the difference between a database and an instance. These words often are used interchangeably when referring to an Oracle Database environment, but there is an important distinction between them. A database is a collection of physical files residing on one or more disks that store and organize data. The database structure consists primarily of user-defined data, metadata (data describing other data), and control files used to manage the integrity and availability of the data. For example, the metadata defined in the Oracle data dictionary provide the necessary information for the Oracle software to manage user data. A database is made up of one or more data files, and data files are grouped together to form a tablespace. An Oracle instance refers to the collection of background operating system processes used to update, retrieve and manage the user data, metadata and control files associated with the database. Further, a database instance can be viewed as the data in the database at a particular point in time. The database instance also consists of a group of shared memory areas known as the System Global Area (SGA), used to support the background processes and memory allocation for the instance. The assessor should not confuse these terms when auditing or discussing Oracle Database. Tablespace A tablespace is a logical collection of data files and must be defined before data can be entered into the database. It is composed of segments that hold various database objects (e.g., tables, views, indexes, stored procedures). The segments within a tablespace store data in a logical entity called an extent, which in turn consists of one or more blocks. The block size in a database is determined when the database is first created. Information about the data to be stored is created within the data dictionary of the database, which is owned by the user SYS. Oracle ships with many predefined data dictionary views, or catalog views, which permit users to query the data dictionary to obtain descriptive data about objects stored in the database. As an example, catalog views exist to obtain a listing of all tables residing in a database along with descriptive data such as column names, data types of the columns and constraints enforced on the data. Also, several catalog views exist to obtain security-relevant information for the database, including privileges for database objects and users and audit logging configurations. What is commonly referred to as metadata, and the catalog views can be used to query information for any default or user-defined tablespace. The following tablespaces are either built in or common to many databases: System 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

23 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 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 Manages resources in Oracle Real Application Clusters 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

24 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 :05? 00:00:00 ora_pmon_test oracle :05? 00:00:00 ora_vktm_test oracle :05? 00:00:00 ora_diag_test oracle :05? 00:00:00 ora_dbrm_test oracle :05? 00:00:00 ora_psp0_test oracle :05? 00:00:00 ora_dia0_test oracle :05? 00:00:05 ora_mman_test oracle :05? 00:00:00 ora_dbw0_test oracle :05? 00:00:01 ora_lgwr_test oracle :05? 00:00:00 ora_ckpt_test oracle :05? 00:00:03 ora_smon_test oracle :05? 00:00:00 ora_reco_test oracle :05? 00:00:05 ora_mmon_test oracle :05? 00:00:00 ora_mmnl_test oracle :05? 00:00:00 ora_d000_test oracle :05? 00:00:00 ora_s000_test oracle :06? 00:00:00 ora_fbda_test oracle :06? 00:00:00 ora_smco_test oracle :06? 00:00:00 ora_qmnc_test oracle :06? 00:00:00 ora_w000_test oracle :06? 00:00:00 ora_q000_test oracle :06? 00:00:00 ora_q001_test oracle :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

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

26 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

27 4. Oracle Database System Architecture Overview 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 19

28 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 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 = ) (PORT = 1521))) (CONNECT_DATA = (SID = prod1) (SERVER = DEDICATED))) Unauthorized access to the tnsnames.ora file can provide the necessary information for a malicious user to connect to Oracle Database or negatively impact the availability of the database. Refer to chapter 13, Network Security, for more information related to the TNS Listener and how Oracle Advanced Security can be used to implement secure network communication protocols. END OF EXCERPT 20