Академический Документы
Профессиональный Документы
Культура Документы
3rd Edition
ISACA
3701 Algonquin Road, Suite 1010
Rolling Meadows, IL 60008 USA
Phone: +1.847.253.1545
Fax: +1.847.253.1443
E-mail: info@isaca.org
Web site: www.isaca.org
ISBN 978-1-60420-118-5
Security, Audit and Control Features Oracle Database, 3rd Edition (Technical and Risk Management
Reference Series)
Printed in the United States of America
CGEIT is a trademark/service mark of ISACA. The mark has been applied for or registered in countries
throughout the world.
Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be
trademarks of their respective owners. This publication was not created in conjunction with or endorsed
by the Oracle Corporation and/or its affiliates.
ii
Acknowledgments
Acknowledgments
ISACA wishes to recognize:
Researchers
Rik Boren, CISA, CISM, CISSP, CPA, PricewaterhouseCoopers LLP, USA
David W. Stanton, CISM, CISSP, PricewaterhouseCoopers LLP, USA
Igor Oreper, PricewaterhouseCoopers LLP, USA
Philip D. Wainwright, PricewaterhouseCoopers LLP, USA
Roger Heiniluoma, CIMA Energy, USA
Expert Reviewers
Emmanuel Osei Kwame Adjei, Kofi Annan Centre of Excellence-Advanced Information Technology
Institute, Ghana
Akin Akinbosoye, CISA, CISM, CGEIT, PMI-RMP, Healthcare Corporation of America, USA
Kelvin J. Arcelay, CISA, CISSP, HISP, IRCA ISMS Auditor, PMP, SSGB, Arcelay and Associates
LLC, USA
Deepak Agrawal, CISA, CISM, CISSP, PMP, PricewaterhouseCoopers, India
Jeffrey T. Hare, CISA CPA CIA, ERP Seminars, USA
Kamal Khan, CISA, CISSP, CITP, Saudi Aramco, Saudi Arabia
Prashant A. Khopkar, CISA, CA, USA
Arbogast Celestine Kihaule, CISA, OCP9i, IT Consultant, Tanzania
Stephen Kost, Integrigy Corporation, USA
Larry Marks, CISA, CGEIT, CFE, CISSP, CSTE, PMP, Resources Global Professionals, USA
K.K. Mookhey, CISA, CISM, CISP, Network Intelligence, India
Felix Ramirez, CISA, CGEIT, Riebeeck Stevens Ltd., USA
Nitin Sood, CISM, CISSP, CSSLP, OCA, PMP, Independent Consultant, Canada
Peter Tessin, CISA, PMP, Altran Control Solutions, USA
Sanjay Kumar Vaid, CISA, CISM, CGEIT, Belgium
Jinu Varghese, CISA, CISSP, OCA, PricewaterhouseCoopers LLP, Canada
ISACA Board of Directors
Emil DAngelo, CISA, CISM, Bank of Tokyo-Mitsubishi UFJ Ltd., USA, International President
George Ataya, CISA, CISM, CGEIT, CISSP, ICT Control SA-NV, Belgium, Vice President
Yonosuke Harada, CISA, CISM, CGEIT, CAIS, InfoCom Research Inc., Japan, Vice President
Ria Lucas, CISA, CGEIT, Telstra Corporation Ltd., Australia, Vice President
Jose Angel Pena Ibarra, CGEIT, Alintec, Mexico, Vice President
Robert E. Stroud, CGEIT, CA Inc., USA, Vice President
Kenneth L. Vander Wal, CISA, CPA, Ernst & Young LLP (retired), USA, Vice President
Rolf von Roessing, CISA, CISM, CGEIT, KPMG Germany, Germany, Vice President
Lynn Lawton, CISA, FBCS CITP, FCA, FIIA, KPMG LLP, UK, Past International President
Everett C. Johnson Jr., CPA, Deloitte & Touche LLP (retired), USA, Past International President
Gregory T. Grocholski, CISA, The Dow Chemical Co., USA, Director
Tony Hayes, CGEIT, AFCHSE, CHE, FACS, FCPA, FIIA, Queensland Government,
Australia, Director
Howard Nicholson, CISA, CGEIT, City of Salisbury, Australia, Director
Jeff Spivey, CPP, PSP, Security Risk Management, USA, Trustee
Knowledge Board
Gregory T. Grocholski, CISA, The Dow Chemical Co., USA, Chair
Michael Berardi Jr., CISA, CGEIT, Energizer, USA
John Ho Chi, CISA, CISM, CBCP, CFE, Ernst & Young, Singapore
Jose Angel Pena Ibarra, CGEIT, Alintec, Mexico
Jo Stewart-Rattray, CISA, CISM, CGEIT, CSEPS, RSM Bird Cameron, Australia
Jon Singleton, CISA, FCA, Auditor General of Manitoba (retired), Canada
Patrick Stachtchenko, CISA, CGEIT, CA, Stachtchenko & Associates SAS, France
Kenneth L. Vander Wal, CISA, CPA, Ernst & Young LLP (retired), USA
iii
Acknowledgments (cont.)
Guidance and Practices Committee
Kenneth L. Vander Wal, CISA, CPA, Ernst & Young LLP (retired), USA, Chair
Phillip J. Langeschulte, CGEIT, CPA, KPMG LLP, USA
Mark A. Lobel, CISA, CISM, CISSP, PricewaterhouseCoopers LLP, USA
Adel H. Melek, CISA, CISM, CGEIT, CISSP, Deloitte & Touche, Canada
Ravi Muthukrishnan, CISA, CISM, FCA, ISCA, Capco IT Service India Private Ltd, India
Anthony P. Noble, CISA, CCP, Viacom Inc., USA
Salamon Rico, CISA, CISM, CGEIT, Deloitte, Mexico
Eddy Schuermans, CISA, CGEIT, ESRAS bv ba, Belgium
Frank Van Der Zwaag, CISA, CISSP, Westpac, New Zealand
To the ISACA Chicago chapter for its financial support
iv
Table of Contents
Table of Contents
Executive Summary.................................................................................... 1
1. Introduction............................................................................................ 3
Intended Audience.............................................................................................. 3
Conventions/Explanations of Illustrations......................................................... 3
Overall Audit Approach..................................................................................... 4
A Brief History of Oracle Database Security..................................................... 4
2. Security and Control Approach/Framework.................. 9
3. Security Policies................................................................................. 11
4. Oracle Database System Architecture Overview...... 13
Instance vs. Database........................................................................................ 14
Tablespace......................................................................................................... 14
Server Processes............................................................................................... 15
File Structure..................................................................................................... 17
Memory Structure............................................................................................. 19
Oracle Net......................................................................................................... 20
5. Planning the Audit............................................................................. 21
6. Understanding the IT Environment....................................... 23
7. Operating System Security.......................................................... 27
Risks Associated With Poor OS Security........................................................ 27
Controls............................................................................................................. 28
8. New Features........................................................................................... 35
Oracle 10gNew Security Features................................................................ 35
Oracle 11gNew Security Features .............................................................. 37
9. Database Security Privileges.................................................... 39
System Privileges.............................................................................................. 40
10. Access Control..................................................................................... 43
Roles.................................................................................................................. 43
Stored Procedures and Triggers....................................................................... 56
ALL_SOURCE View....................................................................................... 58
Data Dictionary................................................................................................. 59
Encryption of Database Records...................................................................... 62
Database Access............................................................................................... 65
Emergency Access............................................................................................ 70
Generic Accounts.............................................................................................. 70
Password Controls............................................................................................ 71
Resource Limits................................................................................................ 74
v
Table of Contents
Appendix 5. Frequently Asked Questions................................. 187
Appendix 6. CobiT References............................................................ 189
Appendix 7. Glossary............................................................................... 193
Appendix 8. Acronyms............................................................................. 205
Appendix 9. Reading Suggestions................................................... 209
Appendix 10. References........................................................................ 211
ISACA Professional Guidance Publications.......................... 213
Index.................................................................................................................. 216
vii
viii
Executive Summary
Executive Summary
As systems have migrated from mainframe to client-server and multitiered web
application environments, the criticality of protecting the relational database has
grown steadily over the last decade. The confidentiality, integrity and availability
requirements of the database tier are at an all-time high. Consumers of information
(e.g., employees, customers and business partners) all demand instant access
to data in a near real-time and accurate manner. Further, the level of awareness
around securing the database has steadily increased over the years due to increased
legal and regulatory compliance requirements. Enterprises continue to realize the
business impact that could result from a data security breach, including financial
loss, negative perception in the marketplace and loss of shareholder value. These
factors have led to higher security expectations of database administrators,
application developers and the assessors role in identifying risk. As a result, there
has been an increased focus on auditing the database itself to ensure that there are
appropriate safeguards in place to protect against reasonably foreseeable threats.
This book sets out to assist the assessor in reviewing the security of an Oracle
Database environment. It can be used as a field reference for the assessor or can be
read cover to cover by those interested in learning more about Oracle security.
Throughout the book, a background and review of security controls are provided.
Several different frameworks that can be used to assess security risks are
discussed. The book covers other soft topics with which an assessor needs to
be familiar, such as developing a strategy to plan the audit, understanding the
information technology (IT) environment, and reviewing policies and standards.
The book also discusses technical topics, including an overview of Oracle
Databases architecture, operating system controls, auditing and logging, network
security and new features offered in Oracle 11g (the latest version of Oracle
Database as of the writing of this book). Additionally, differences in previous
versions of Oracle Database are noted, as well as differences that may exist based
on the host operating system of the database.
Topics such as automated assessment tools, enterprise resource planning (ERP)
and customer relationship management (CRM) architectures, and interfaces with
legacy systems are also addressed. While these specific topics are not covered in
great detail, they do provide the assessor with an overall framework for assessing
Oracle Database security in the context of actual client deployment scenarios and
environments.
The goal of this book is not to be an all-inclusive instruction manual for the
everyday database administrator. It is intended to guide the assessor through a
comprehensive evaluation of security for an Oracle Database based on business
objectives and risks. It is also intended that the assessor will review and integrate
other related audit/assurance program documents, in relation to the requirements
of the project/assignment; specific scope; IT/enterprise architecture; availability of
the time, budget and resources; and other relevant factors.
1. Introduction
1. Introduction
An effective approach to assessing security must consider security controls at each
layer of the system or application architecture (e.g., application, operating system,
database, network and physical levels). A security weakness within any component
of the system may lead to the compromise of the entire system. In many system
environments, an Oracle Database is a key component of the system architecture.
Before the US Sarbanes-Oxley Act, many IT audits focused on application,
network and operating system controls, often overlooking the database layer
entirely. However, the database is usually the repository or authoritative source
of critical business data and sensitive customer or employee data that are heavily
regulated. Unauthorized access to the database can also lead to unauthorized access
to the underlying operating system, which could allow an attacker to compromise
additional systems and databases on the network. As a result, the database should
be included as a key component of any systems security audit.
This book provides the reader with the knowledge and tools to effectively audit an
Oracle Database 11g environment. At the time of the writing of this book, Oracle
Database 11g is the most recent version released by Oracle. Because older versions
of Oracle Database are still prevalent in the industry and fully supported by Oracle,
including Oracle Database 9i and 10g, many of the concepts discussed for Oracle
Database 11g will also apply to older versions, unless otherwise specified.
Intended Audience
The primary audience of this book is assessors who review and assess the security
of environments that include an Oracle Database component. Other audiences,
such as information security practitioners and database administrators (DBAs),
also will find this book useful to understand and assess Oracle security risks.
The intended audience for this book should already have an existing high-level
knowledge of Oracle Database technologies and understand general auditing and
security concepts.
Conventions/Explanations of Illustrations
The objective of this book is to provide the reader with a practical, real-world
approach to auditing Oracle Database security. Case studies and examples are
provided and identified in grey boxes, titled Real-world Examples, to illustrate
different concepts. Although these examples are based on real-world scenarios, it
is difficult to relate in a single example to the varied environments where Oracle
Database is implemented. With that said, it is hoped that readers will be able to
relate the context in the examples to their own environments.
DBA
1. Introduction
Responding to the suggestions and requests of its customers, Oracle added security
functions to version 6 and as such, version 6 of Oracles database was the first
major release of the product to contain significant security enhancements. Version
6 was also the first Oracle Database to include the use of roles. These roles were
assigned privileges that defined the access rights to data stored in tables. The
roles were then granted to users of the database; thus, users could access only data
to which they were granted access via a role assignment. This is essentially the
same user access model that all later versions of Oracle Database have used as a
foundation. In version 6, DBAs could not create their own roles; they could assign
only the Oracle-supplied default roles. Version 6 also included auditing features,
which provided the ability to audit logins, track actions performed on the database
and identify all objects accessed, as well as new backup features, such as redo logs
and rollback segments.
Oracle Database version 7 was released in 1994, coinciding with the growth of
client-server technologies. Version 7 contained some auditing enhancements over
version 6, including triggers which were introduced to track modifications of a
table and record before and after pictures of the data. In version 7, the audit trail
could be saved in the database or exported to an external file. This version also
introduced hot backups, which enabled the entire database to be backed up while it
was still operational. One of the key improvements in version 7 was the capability
for DBAs to create new, custom roles and assign them to database users.
With the release of version 7.3, Oracle introduced the Oracle Advanced
Networking Option. This option was sold as an add-on at an additional cost. The
Advanced Networking Option provided the capability to encrypt queries and
replies between the client and server. Even though this provided a good level
of security, it often negatively impacted database performance in a significant
way and, thus, was not implemented by many enterprises. Oracle Advanced
Networking also provided additional authentication options from third-party
software vendors, such as SecureID and Kerberos. Oracle also offered an addedcost security feature called Trusted Oracle 7, which allowed data to be classified
in a database. Each row of data could be assigned a classification, and only users
who matched the assigned security level to each classification level could gain
access to the information.
Oracle Database version 8 was released in 1997. Major upgrades included
stronger password management controls and other enhanced security features.
Prior versions contained virtually no password control enforcement features;
administrators were only able to create a user ID and assign it a password. The
new password controls available within version 8 included password expiration,
locking out an account after a predetermined amount of failed login attempts,
prohibiting use of the same password within a certain period of time, password
complexity controls, and password length. It also allowed for administrators to
set up user IDs, requiring users who logged on to the database for the first time
5
1. Introduction
External application security also was addressed in Oracle 9i. External application
refers to applications and tools such as SQL*Plus, that interact with the database for
administrative purposes,. Every application that interacts with the database can have
its own set of security policies. Unique roles and privileges can be created, which
will provide varying levels of security based upon the individuals job responsibility.
Oracle NetSolutions for Oracle 9i, known in previous versions as SQL*Net, has
increased functionality for firewall usage. Access to the database can be permitted
or restricted by destination database names, source IP addresses, source host names,
destination IP addresses and destination host names. In addition to these features, many
of the well-known default accounts associated with Oracle now are locked during
the initial installation. This provides additional security over the database, since these
accounts and the default passwords associated with them are widely known.
Oracle introduced Oracle Database 10g in 2003. The g is meant to focus on
Oracles abilities in grid computing, and many features were added to enhance the
database operation in distributed environments. Security enhancements in version
10g improved several of the features introduced in 9i:
VPD10g introduced column-level security and masking, which enabled finergrained access controls to security administrators. Policy types and caching were
introduced to enhance performance of these more secure databases.
Password change option at installationThe default passwords, which an
administrator had to change immediately, had to now be changed as part of the
installation process.
FGAData Manipulation Language (DML) auditing, which allows monitoring
of INSERT, DELETE and UPDATE statements in addition to SELECT, was
added in this version of FGA. The FGA records and standard log records were
presented in a single unified format. The auditing records were enhanced with
the exact SQL text of audited statements, the date/time stamp in Coordinated
Universal Time (UTC) and added support for enterprise users.
Enhanced encryptionAs part of Oracle Advanced Security, significant
improvements were made for encrypting data at rest with features such as
Transparent Data Encryption (TDE) and increased support for encrypted
network communications to secure user logins and data transfers over the
network using Advanced Encryption Standard (AES) encryption. In addition, the
DBMS_CRYPTO package replaced the DBMS_OBFUSCATION_TOOLKIT,
simplifying the use of encryption within the database.
Strong authentication for privileged usersSecure logins over the network for
privileged users with SYSDBA and SYSOPER privileges using Kerberos or
Secure Sockets Layer (SSL) were required.
Oracle Database VaultThis was an additional Oracle component used
to safeguard application data from privileged users, including database
administrators and security administrators. More information regarding Oracle
Database Vault is available in a white paper.1
1
10
3. Security Policies
3. Security Policies
Chapter Overview
Clear, consistent and enforceable information security policies are important to
every enterprise, regardless of the level of information security required. Security
policies help protect the enterprises information assets from unauthorized access
and disclosure that could damage its reputation and/or reduce the level of public
confidence in the enterprise. This chapter shows how policies, standards and
technical controls relate to auditing Oracle Database and the chapter references
CobiT control objectives: DS5.1 and PO2.3.
Policies should communicate managements objectives and goals for
implementing security enterprisewide and should be general statements that apply
to all employees, across multiple business units. The following is an example of a
policy statement:
Information resources are essential to our success. Therefore, access to
all information resources will be granted in a controlled manner driven
by business requirements. The overall strategy is that access is strictly
forbidden unless explicitly granted. Employees are explicitly granted
access to information or systems. There is no implicit right of access.
Real-world Example
PCI DSS version 1.2, Requirement 12, defines a set of detailed criteria for
maintaining an information security policy for employees and contractors. PCI
DSS also calls for a formal security awareness program to make employees aware
of the enterprises information security policy and responsibilities for protecting
sensitive data. Other countries around the world also have similar requirements.
Standards communicate how the policies should be implemented and should
be independent of any particular technology. The following is an example of a
standard:
All access to computer systems must be controlled by an authentication
method involving a minimum of a username/password combination.
All employees must authenticate to systems using their individually
identifiable accounts.
The last piece in the policy puzzle is technical controls, which should define
how the standards will be implemented in Oracle Database. The following is an
example of a technical control for Oracle Database:
The SYS and SYSTEM passwords must be known only by the Oracle
system administrator and authorized database administrators. The
SYS and SYSTEM account passwords should not be the same, and
11
Policy
(senior management, regulatory,
advisory, informative)
Standards
(use of specific technologies in
uniform way)
Technical Controls
Guidelines (recommended actions
that are not compulsory)
Procedures (steps to perform a
specific task in compliance with a
mandatory standard)
Enterprises may have different models for their policies and standards. For
example, an enterprises model may consist of a hierarchy of policies (senior
management, regulatory, advisory, informative), standards (use of specific
technologies in a uniform way), guidelines (recommended actions that are not
compulsory), and procedures (steps to perform a specific task in compliance
with a mandatory standard). It is important to review an enterprises model and
understand how it relates to database security.
12
Client Process
Oracle Instance
Shadow
Thread
Shared Pool
Memory
Structures
Library Cache
Data Dictionary Cache
Recover
(RECO)
System
Monitor
(SMON)
Database
Writer
(DBWO)
Database
Buffer Cache
Process
Monitor
(PMON)
Redo Log
Buffer
Checkpoint
(CKPT)
Log
Writer
(LGWR)
Archiver
(ARCO)
Oracle Database
Oracle
Processes
(background
processes)
Parameter File
Data Files
Control Files
Archived
Log
FIles
Password File
13
Tablespace
A tablespace is a logical collection of data files and must be defined before data
can be entered into the database. It is composed of segments that hold various
database objects (e.g., tables, views, indexes, stored procedures). The segments
within a tablespace store data in a logical entity called an extent, which in turn
consists of one or more blocks. The block size in a database is determined when
the database is first created. Information about the data to be stored is created
within the data dictionary of the database, which is owned by the user SYS. Oracle
ships with many predefined data dictionary views, or catalog views, which permit
users to query the data dictionary to obtain descriptive data about objects stored
in the database. As an example, catalog views exist to obtain a listing of all tables
residing in a database along with descriptive data such as column names, data
types of the columns and constraints enforced on the data. Also, several catalog
views exist to obtain security-relevant information for the database, including
privileges for database objects and users and audit logging configurations. What
is commonly referred to as metadata, and the catalog views can be used to query
information for any default or user-defined tablespace. The following tablespaces
are either built in or common to many databases:
System tablespaceIncludes system data that the database needs to manage
itself and holds the data dictionary (metadata of the database). It must always
exist, and cannot be taken offline when the instance is running and has the
database open.
14
Server Processes
An Oracle instance runs as several processes on the host operating system. Each
instance has a set of processes that interacts only with the data files associated with
that particular instance. Further, to ensure the integrity of the database, no other
system processes should be allowed to interact with any of the data files. Four
essential processes are required for any instance to function properly: DBWn,
LGWR, PMON and SMON. Other processes are introduced when additional
database components, such as the Queue Monitor, are enabled. Key Oracle
Database processes and their descriptions are listed in figure 4.2.
Figure 4.2Key Oracle Database Process Names
Process Name
Process Description
Writes data from the database buffer cache to the data files; multiple
database writer processes can exist
CKPT (Checkpoint)
ARCn (Archiver)
RECO (Recoverer)
Dnnn (Dispatcher)
QMNn (Queue
Monitor)optional
LCK (Lock)
1 0 16:05 ?
00:00:00 ora_pmon_test
oracle 2618
1 0 16:05 ?
00:00:00 ora_vktm_test
oracle 2622
1 0 16:05 ?
00:00:00 ora_diag_test
oracle 2624
1 0 16:05 ?
00:00:00 ora_dbrm_test
oracle 2626
1 0 16:05 ?
00:00:00 ora_psp0_test
oracle 2630
1 0 16:05 ?
00:00:00 ora_dia0_test
oracle 2632
1 1 16:05 ?
00:00:05 ora_mman_test
oracle 2634
1 0 16:05 ?
00:00:00 ora_dbw0_test
oracle 2636
1 0 16:05 ?
00:00:01 ora_lgwr_test
oracle 2638
1 0 16:05 ?
00:00:00 ora_ckpt_test
oracle 2640
1 0 16:05 ?
00:00:03 ora_smon_test
oracle 2642
1 0 16:05 ?
00:00:00 ora_reco_test
oracle 2644
1 1 16:05 ?
00:00:05 ora_mmon_test
oracle 2646
1 0 16:05 ?
00:00:00 ora_mmnl_test
oracle 2649
1 0 16:05 ?
00:00:00 ora_d000_test
oracle 2651
1 0 16:05 ?
00:00:00 ora_s000_test
oracle 2659
1 0 16:06 ?
00:00:00 ora_fbda_test
oracle 2661
1 0 16:06 ?
00:00:00 ora_smco_test
oracle 2663
1 0 16:06 ?
00:00:00 ora_qmnc_test
oracle 2665
1 0 16:06 ?
00:00:00 ora_w000_test
oracle 2667
1 0 16:06 ?
00:00:00 ora_q000_test
oracle 2669
1 0 16:06 ?
00:00:00 ora_q001_test
oracle 2817
1 0 16:10 ?
00:00:00 ora_cjq0_test
In figure 4.3, there are multiple processes associated with the database instance.
These processes include the essential processes as well as the Recoverer
(ora_reco_test), Checkpoint (ora_ckpt_test), Job Queue
(ora_cjq0_test), and other background processes performing various
maintenance tasks.
16
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
18
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
Oracle Net
Oracle Net is comprised of client and server software that enables applications
and Oracle Database to communicate over the network. The Oracle Net Listener
is a process that listens for incoming connection requests on the network. The
listener.ora and tnsnames.ora files both contain network configuration
settings related to the Oracle Database and available services. Both of these files
are stored in the ORACLE_HOME/network/admin directory on UNIX/Linux
operating systems and the %ORACLE_HOME%/network/admin directory on
Windows systems. The listener.ora file defines the Oracle Net Listener
configuration, including the name of the listener, protocol addresses on which the
listener is accepting requests, and a list of database services. The tnsnames.
ora file is a configuration file that defines Oracle Net service names (SIDs)
mapped to listener protocol addresses. The following sample tnsnames.ora
file defines a connect descriptor for database SID prod1.
DBNAME =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 172.168.2.3)
(PORT = 1521)))
(CONNECT_DATA =
(SID = prod1)
(SERVER = DEDICATED)))
Unauthorized access to the tnsnames.ora file can provide the necessary
information for a malicious user to connect to Oracle Database or negatively
impact the availability of the database. Refer to chapter 13, Network Security, for
more information related to the TNS Listener and how Oracle Advanced Security
can be used to implement secure network communication protocols.
END OF EXCERPT
20