Security Target for Oracle Database 11g 1
Release 2 (11.2.0.2), Enterprise Edition
Security Target for
Oracle Database 11g Release 2
(11.2.0.2)
Enterprise Edition
October 2011
Version 1.3
Security Evaluations
Oracle Corporation
500 Oracle Parkway
Redwood Shores, CA 94065
2 Security Target for Oracle Database 11g
Release 2 (11.2.0), Enterprise Edition
Security Target for Oracle Database 11g Enterprise Edition
Release 2 (11.2.0.2)
Author: Helmut Kurth
Contributors: Shaun Lee, Petra Manche
Copyright © 1999, 2011, Oracle Corporation. All rights reserved. This documentation contains proprietary information of Oracle
Corporation; it is protected by copyright law. Reverse engineering of the software is prohibited. If this documentation is delivered
to a U.S. Government Agency of the Department of Defense, then it is delivered with Restricted Rights and the following legend
is applicable:
RESTRICTED RIGHTS LEGEND
Use, duplication or disclosure by the Government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of DFARS
252.227-7013, Rights in Technical Data and Computer Software (October 1988).
Oracle Corporation, 500 Oracle Parkway, Redwood City, CA 94065.
The information in this document is subject to change without notice. If you find any problems in the documentation, please
report them to us in writing. Oracle Corporation does not warrant that this document is error free.
Oracle is a registered trademark and Oracle Database 10g, Oracle9i, PL/SQL, Oracle Enterprise Manager, Oracle Call Interface,
SQL*Plus, SQL*Loader and Oracle Net are trademarks or registered trademarks of Oracle Corporation. Other names may be
trademarks of their respective owners.
Security Target for Oracle Database 11g 3
Release 2 (11.2.0.2), Enterprise Edition
Contents
1 Introduction............................................................................... 5
ST Reference.......................................................................................... 5
TOE Reference ...................................................................................... 5
TOE Overview....................................................................................... 6
TOE Product Components..................................................................... 7
Document Overview.............................................................................. 7
Conformance Claims ............................................................................. 8
Conformance Rationale ......................................................................... 8
2 TOE Description...................................................................... 11
Oracle Database 11g R2 Architecture ................................................. 11
An Oracle Database ............................................................................. 13
Access Control..................................................................................... 17
Quotas.................................................................................................. 21
Identification and Authentication ........................................................ 22
Auditing ............................................................................................... 23
Security Management .......................................................................... 25
Consistency of Replicated TSF Data................................................... 26
Secure Distributed Processing ............................................................. 27
Other Oracle Database 11g Security Features..................................... 27
3 Security Problem Definition................................................... 30
Threats ................................................................................................. 30
Organisational Security Policies.......................................................... 30
Assumptions ........................................................................................ 30
4 Security Objectives................................................................. 32
TOE Security Objectives ..................................................................... 32
Environmental Security Objectives ..................................................... 32
Security Objectives Rationale.............................................................. 33
5 IT Security Requirements....................................................... 35
TOE Security Functional Requirements.............................................. 35
TOE Security Assurance Requirements .............................................. 48
Security Requirements Rationale......................................................... 48
Assurance Measures Rationale............................................................ 53
4 Security Target for Oracle Database 11g
Release 2 (11.2.0), Enterprise Edition
6 TOE Summary Specification.................................................. 54
TOE Security Functionality................................................................. 54
Security Mechanisms and Techniques................................................. 67
Assurance Measures ............................................................................ 67
TOE Summary Specification Rationale............................................... 68
A References.............................................................................. 73
B Glossary.................................................................................. 76
Acronyms............................................................................................. 76
Terms ................................................................................................... 77
Security Target for Oracle Database 11g 5
Release 2 (11.2.0.2), Enterprise Edition
CHAPTER
1 Introduction
This document is the Security Target for the Common Criteria evaluation of Oracle
Database 11g Release 2 (11.2.0.2) Enterprise Edition.
ST Reference
Title: Security Target for Oracle Database 11g Release 2 Enterprise Edition, Version
1.3.
TOE Reference
Target of Evaluation (TOE): Oracle Database 11g Enterprise Edition.
Release: 11.2.0.2 with all critical patch updates up to and including October 2011 via
the July 2011 PSU as well as the October 2011 CPU.
Note: This includes the guidance documentation which consists of [ECD] and the
Oracle Database 11g Release 2 documentation library (Part No. E11882_01).
Note: Oracle’s release numbers are of the form a.b.c.d where
• a is the major release number
• b is the maintenance release number
• c is the application server release number
• d is the component release number
In some cases there may be an additional number at the end which then defines a
platform-specific release number (usually a patch set). In the case of the TOE, all
components have the release number 11.2.0.x with no platform.
Operating System Platforms: Red Hat Enterprise Linux 5.5 Advanced Platform;
SuSE Linux Enterprise Server 11;
Oracle Enterprise Linux Version 5 Update 5.
6 Security Target for Oracle Database 11g
Release 2 (11.2.0), Enterprise Edition
TOE Overview
The following overview applies to the Oracle Database 11g Release 2 Enterprise
Edition.
• Enterprise Edition has no limitations on the number of CPUs..
• Enterprise Edition has no limitation on the number of users.
• Enterprise Edition supports databases up to a size of 8 Exabyte.
Enterprise Edition is targeted at large to very large organizations with a high volume
of transactions.
Oracle Database 11g is an object-relational database management system (ORDBMS),
providing advanced security functionality for multi-user distributed database
environments. The security functionality in Oracle Database 11g includes:
• user identification and authentication, with password management options and
support for enterprise users (password option only). In the case of Enterprise Users
(defined later) this function is partly provided by the IT-environment. Note that
[BR-DBMSPP] defines identification and authentication as a function of the IT
environment. This is the case for a DBMS that relies on the underlying operating
system for the identification and authentication of the user. In the case of the
Oracle DBMS the identification and authentication is either performed by the TOE
in total (in the case of users that are not Enterprise Users) or performed with the
assistance of an authentication server in the IT environment (in the case of
Enterprise Users). In both cases it is the TOE that mediates the identification and
authentication of the user;
• discretionary access controls on database objects, which controls access to objects
based on the identity of the subjects or groups to which the subjects and objects
belong, and which allows authorized users to specify how the objects that they
control are protected;
• granular privileges for the enforcement of least privilege;
• user-configurable roles for privilege management, including an authorized
administration role to allow authorized administrators to configure the policies for
discretionary access control, identification and authentication, and auditing. The
TOE must enforce the authorized administration role;
• quotas on the amount of processing resources a user can consume during a
database session;
• audit capture is the function that creates information on all auditable events;
• extensive and flexible auditing options;
• secure access to remote Oracle databases; and
• stored procedures, triggers and security policies for user-defined access controls
and auditing.
Those functions are a superset of the security functions defined in [BR-DBMSPP],
chapter 2.3.
Security Target for Oracle Database 11g 7
Release 2 (11.2.0.2), Enterprise Edition
Oracle Database 11g relies on the IT-environment for the non-bypassibility and
domain separation properties. Those properties need to be provided by the underlying
operating systems in co-operation with the hardware platform. The operating system
platforms listed above have all been evaluated for conformance to the Controlled
Access Protection Profile [CAPP] which requires to enforce those properties. In
addition Oracle Database 11g enforces its own separation between different users
based on the functions provided by the underlying operating system.
Oracle Database 11g supports both client/server and standalone architectures. In
addition, Oracle Database 11g supports multi-tier architectures, however in this
environment any tier (middle-tier) that communicates directly with the server is
actually an Oracle client and any lower tiers are outside of the scope of this ST. In all
architectures, the Oracle Database 11g Server acts as a data server, providing access to
the information stored in a database. Access requests are made via Oracle Database
11g interface products that provide connectivity to the database and submit Structured
Query Language (SQL) statements to the Oracle Database 11g data server.
The Oracle Database 11g interface products may be used on the same computer as the
data server, or they may run on separate client machines and communicate with the
data server via network interfaces.
TOE Product Components
The Oracle Database 11g includes the products identified in Table 1. Access to the
Oracle Database 11g server is provided via the interface products identified in Table 2.
[ECD] defines which TOE products must be installed in the evaluated configuration
and defines the requirements for setting up the TOE environment.
Table 1: TOE Server Products
TOE Server Products
Oracle Database 11g Enterprise Edition 11.2.0.2
Table 2: TOE Interface Products
TOE Interface Products
SQL*Plus 11.2.0.2
Oracle Call Interface 11.2.0.2
Oracle Net Services 11.2.0.2
Document Overview
This document consists of an update to the security target for Oracle11g Release 1
(11.1.0) Enterprise Edition, [ST11gR1-EE], which was used in the most recent
8 Security Target for Oracle Database 11g
Release 2 (11.2.0), Enterprise Edition
Common Criteria evaluation of Oracle11g. Changes made relative to [ST11gR1-EE]
are minor and are explained in the chapter on Security in [WHATSNEW].
Chapter 2 of this security target provides a high-level overview of the security features
of the Oracle Database 11g R2 data server. Chapter 3 describes the security problem
definition with the identification of the assumptions, threats, and security policies of
the TOE environment. Chapter 4 describes the security objectives for the TOE and for
the environment needed to address the assumptions, threats, and security policies
identified in Chapter 3. Chapter 5 identifies the Security Functional Requirements
(SFRs) and the Security Assurance Requirements (SARs). Chapter 6 summarises each
Security Function (SF) provided by Oracle Database 11g R2 to meet the security
requirements.
Appendix A contains a list of references and Appendix B provides a glossary of the
terms.
Conformance Claims
The CC conformance claim is: part 2 extended and part 3 conformant. This Security
Target conforms to [CC, Part 2] and [CC, Part 3]. [BR-DBMSPP] contains extended
SFRs which are included in this Security Target. All other SFRs in this Security
Target are conformant to [CC, Part 2]. ALC_FLR.3 is the only augmented assurance
criterion specified in addition to the ones in the EAL4 assurance package.
Assurance: EAL4 augmented with ALC_FLR.31
Keywords: Oracle Database 11g R2, O-RDBMS, database, security target, EAL4
.
Version of the Common Criteria [CC] used to produce this document: 3.1
Release 3.
Demonstrable conformance to the U.S. Government Protection Profile for Database
Management Systems in Basic Robustness Environments, Version 1.3.
([BRDBMSPP]). This protection profile requires at least demonstrable conformance.
Note that [BR-DBMSPP] even in version 1.3 (published in December 2010) is based
on Release 1 of CC V3.1. In CC V3.1 R3 some SFR components have changed and
this Security Target uses the SFR components as defined in CC V3.1 3. Therefore, as
in the previous evaluation (which was based on CC V3.1 R2 and used version 1.2 of
the Protection Profile), this Security Target can only claim demonstrable conformance.
Conformance Rationale
Table 3 in chapter 5 identifies each SFR for this Security Target that was derived from
[BR-DBMSPP] and the tailoring operations performed relative to [BR-DBMSPP].
The tailoring is identified in ITALICISED CAPITAL LETTERS within the text of each
SFR in chapter 5. All of the tailoring operations are in conformance with the
assignments and selections in [BR-DBMSPP]. Security functional requirements
1
ALC_FLR.3 provides assurance at the highest defined component level that there are flaw
remediation procedures for the TOE by which discovered security flaws can be reported to, tracked and
corrected by the developer, and by which corrective actions can be issued to TOE users in a timely
fashion.
CC Conformance
Protection Profile
Conformance
Security Target for Oracle Database 11g 9
Release 2 (11.2.0.2), Enterprise Edition
additional to those defined in [BR-DBMSPP] are marked bold in table 3 of chapter 5.
Tailoring of those SFRs with respect to part 2 of the CC is also identified in
ITALICISED CAPITAL LETTERS.
There are two additional threats not listed in [BR-DBMSPP]:
T.RESOURCE has been added as the threat of a single user attempting to consume
database resources in a way that would prohibit other users from accessing the DBMS.
T.AUDIT_COMPROMISE has been added as the threat of an unauthorized user to
compromise the audit trail such that accountability of a user for his actions is no
longer given.
There are the following additional security objectives not listed in [BR-DBMSPP]:
O.RESOURCE has been added to address the threat T.RESOURCE.
O.AUDIT_REVIEW has been added to address the ability of the TOE to provide
functions for authorized administartors to evaluate the audit log entries. This objective
supports the organizational security policy P.ACCOUNTABILITY included in
[BRDBMSPP]. Reviewing the audit records is a function [BR-DBMSPP] allows to be
done in the IT-environment, but Oracle Database 10g provides its own functions to do
this.
O.AUDIT_PROTECTION has been added to address the ability of the TOE to protect
its audit trail. While [BR-DBMSPP] allows to store the audit trail in storage managed
and protected by the IT environment, Oracle Database 10g uses objects it controls
itself to store the audit trail. Therefore the TOE is also responsible for the protection
of the audit trail.
Note that the additional objectives O.AUDIT_REVIEW and
O.AUDIT_PROTECTION have been taken from [BR-MAN] with
O.AUDIT_REVIEW being phrased more specific.
There is an additional security objective for the IT environment, OE.DIR_CONTROL
addressing the objective for a controlled directory server in the IT environment to
support authentication of Enterprise Users.
There is another additional security objective for the environment, OE.COM_PROT
addressing the objective of securing the communication between distributed parts of
the TOE and between the TOE and the external directory server.
There is an additional underlying system assumption, A.MIDTIER, which is included
to ensure accountability in multi-tier environments. Although the O-RDBMS can
audit the actions of a proxy user, accountability relies upon the correct identity of the
client (given during the connection by the middle-tier). As explained in chapter 1
(TOE Overview), this type of environment is an addition to the scope of evaluation
(which was first introduced for Oracle8i).
An additional assumption A.DIR_PROT is included to address the issue of users
managed centrally in a directory server.
An additional assumption A.COM_PROT is included to address the issue of secure
communication between different parts of the TOE as well as between the TOE and
the directory server. [BR-DBMSPP] does not include communication with an external
directory server nor does it assume a distributed TOE. Therefore this additional
assumption is related to functionality not covered by [BR-DBMSPP]. It is a
refinement of the assumption A.PHYSICAL that assumes physical protection of
10 Security Target for Oracle Database 11g
Release 2 (11.2.0), Enterprise Edition
transmitted information. A.COM_PROT generalizes this to allow also IT based
protection (e. g. a cryptographically secured channel) and not only physical protection.
Another additional assumption A.CLIENT_AP has been included to address the
distributed nature of the TOE where client applications execute on a separate system.
It is a refinement the assumption A.NO_EVIL in [BR-DBMSPP], which is related to
administrators. A.CLIENT_AP refines this to include application developers that
develop applications executing on the client part of the TOE
Table 3 in chapter 5 lists each TOE Security Functional Requirement (SFR) included
in this Security Target. These SFRs were all included in [BR-DBMSPP], with the
exception of those additional SFRs marked in bold in table 3 of chapter 5.
The assurance requirements specified in this security target are those for EAL4
augmented with ALC_FLR.3. This is a superset of all assurance requirements listed in
[BR-DBMSPP].
The additional threats and objectives have been included to address the additional
security functional requirements in the ST. Some of the additional security functional
requirements address also security objectives listed in [BR-DBMSPP]. They actually
address the sometimes incomplete coverage of the objectives listed in [BR-DBMSPP]
by the security functional requirements listed in [BR-DBMSPP]. The rationale
sections in this document will discuss this in more detail.
The only difference between version 1.2 and version 1.3 of the U.S Government
Protection Profile for Database Management Systems is the omission of the
assumption (and the associated objective for the IT environment) that the underlying
operating system is evaluated in accordance with a U.S government approved
Protection Profile.
Security Target for Oracle Database 11g 11
Release 2 (11.2.0.2), Enterprise Edition
CHAPTER
2 TOE Description
This section describes the product features that provide security mechanisms and
contribute to the security of a system configured using Oracle Database 11g R2. For a
detailed description of the security features of Oracle Database 11g R2 the reader is
referred to [SG] and [DAG, part 1, chapter 7 and part V]. In general, these
descriptions correspond to the specifications of IT security functions provided in
chapter 6 of this Security Target.
This chapter describes the major elements of the Oracle Database 11g R2 architecture,
the types of database objects supported by Oracle Database 11g R2, the access control
mechanisms used to protect those objects, controls on user resource consumption, the
accountability and auditing mechanisms, and the security management features
provided by Oracle Database 11g R2. Additional Oracle Database 11g R2 security
features that are not addressed by the security functional requirements of Chapter 5
are also briefly discussed.
Oracle Database 11g R2 Architecture
The Oracle Database 11g architectural components are described in detail in [CON].
A database consists of a set of files which contain, in addition to some control data,
the information which is said to be stored in the database. Each database is an
autonomous unit with its own data dictionary that defines the database objects it
contains (e.g. tables, views, etc.). In a distributed system there can be many databases:
each database can contain many database objects, but each database object is stored
within a single database.
An instance consists of a set of Oracle background processes, which do the work of
the DBMS by executing Oracle Database 11g software, and a shared memory area. An
instance is therefore an active entity, and a database is passive. In order for users to
access the database, the instance must be started and must mount and open the
database for use. A database is persistent: it has an indefinite lifetime from the time it
is created, and the database files and contents exist independently of whether the
database is mounted to an instance and whether the underlying platform is running.
Database
Instance
12 Security Target for Oracle Database 11g
Release 2 (11.2.0), Enterprise Edition
The lifetime of an instance can be indefinite, from when it is started to when it is shut
down, and is dependent on whether the underlying platform is running.
Each database user employs Oracle Database 11g interface products to establish a
database connection to an Oracle Database 11g server process for a particular
database instance. If the user is defined as a valid user for the database and has the
required privileges, then the server will create a database session for the user. While
connected, the user can make requests to the Oracle Database 11g server to read and
write information in the database. The server handles each request, performing the
read and write accesses to database objects and returning data and results to the user,
in accordance with the user’s privileges to database objects and other constraints
configured by a database administrative user.
In a distributed environment, a user may access database objects from multiple
databases. After establishing an initial database session on one instance, the user can
transparently establish database sessions on other (remote) database instances using
database links. A database link identifies a remote database and provides
authentication information. By qualifying references to database objects with the
name of a database link, a user can access remote database objects. However, each
Oracle Database 11g database instance is autonomous with respect to security — a
remote server enforces security based on the privileges of the user as defined in that
remote database.
The Oracle Database 11g server supports the ANSI/ISO SQL standard [SQL92] at the
entry level of compliance and provides Oracle-specific SQL language extensions. All
operations performed by the Oracle Database 11g server are executed in response to
an SQL statement that specifies a valid SQL command.
• Data Definition Language (DDL) statements are statements which create, alter,
drop, and rename database objects, grant and revoke privileges and roles,
configure audit options; add comments to the data dictionary; and obtain statistical
information about the database and its use;
• Data Manipulation Language (DML) statements are statements which manipulate
the data controlled by database objects in one of four ways: by querying the data
held in a database object; by row insertions; by row deletion; by column update.
They include the command to lock a database object.
• Transaction Control statements are statements which manage changes made by
DML statements and help to ensure the integrity of the database. They include
commits and rollbacks for individual transactions, and checkpoints for the
database;
• Session Control statements dynamically manage the properties of a user’s database
session.
• System Control statements dynamically manage the processes and parameters of
an Oracle Database 11g instance.
• Embedded SQL statements incorporate DDL, DML, and transaction control
statements within a procedural language program.
Programming Language/SQL (PL/SQL) is a procedural language supported by Oracle
Database 11g that provides program flow control statements as well as SQL
Database Connections
and Sessions
Distributed Databases
Structured Query
Language (SQL)
Security Target for Oracle Database 11g 13
Release 2 (11.2.0.2), Enterprise Edition
statements [PLS]. Program units written in PL/SQL can be stored in a database and
executed during the processing of a user’s SQL command.
The flashback query feature allows data to be queried from a point in the past. Once a
user has set the date and time that they would like to view, any SQL query that they
execute will operate on data as it existed at that point in time. This can allow suitably
authorised users to correct their own mistakes. SQL operations can be used to view
the change history in order to identify the error. The error can then be backed out of
by restoring data as it existed before the error.
Note that the Flashback functionality does not reverse certain DDL statements such as
TRUNCATE, although it can provide a way to restore accidentally dropped tables. It
also does not apply to packages, procedures, or functions.
The Oracle Call Interface (OCI - described in [OCI]) provides an application
programming interface (API) for developing database applications written in high
level languages such as C.
An Oracle Database
An Oracle database contains the data dictionary and two different types of database
objects:
• schema objects that belong to a specific user schema and contain user-defined
information [CON part I and part 2]; and
• non-schema objects to organise, monitor, and control the database [SQL, chapter
3].
In an Oracle database there are two types of connections for users of the database:
• Administrator connection.
This covers users who connect to the database via AS SYSOPER or AS SYSDBA
by virtue of possessing either the SYSOPER or SYSDBA system privilege (see
[DAG, 1]). Users making a connection AS SYSOPER are allowed to perform
operator administrative tasks (e.g. database startup and shutdown, and ALTER
DATABASE commands). Users making a connection AS SYSDBA are allowed to
perform all administrative tasks (including granting and/or revoking object
privileges on other users’ objects);
• Normal connection (note that this includes users SYS and SYSTEM. [DAG, 1]).
This covers users who are authorised to access the database by virtue of being
explicitly defined and identified to an instance of the Oracle database server.
At the centre of an Oracle database is the data dictionary - a set of internal Oracle
tables that contain all of the information the Oracle database server needs to manage
the database. The data dictionary tables are owned by the user SYS and can only be
modified by highly privileged users. [SG, 4: Managing System Privileges] cautions
that extreme care must be taken when granting roles which provide privileged access
to the data dictionary. A set of read-only views is provided to display the contents of
the internal tables in a meaningful way and also allow Oracle users to query the data
dictionary without the need to access it directly.
Client side interfaces
Data Dictionary
14 Security Target for Oracle Database 11g
Release 2 (11.2.0), Enterprise Edition
All of the information about database objects is stored in the data dictionary and is
updated by the SQL DDL commands that create, alter, and drop database objects.
Other SQL commands also insert, update, and delete information in the data
dictionary in the course of their processing.
A schema is a collection of user-defined database objects that are owned by a single
database user. Oracle Database 11g supports the schema object types identified in
[SQL, 3] and contains the following objects
• Clusters
• Constraints
• Database links
• Database triggers
• Dimensions
• External procedure libraries
• Index-organized tables
• Indexes
• Indextypes
• Java classes, Java resources, Java sources
• Materialized views
• Materialized view logs
• Object tables
• Object types
• Object views
• Operators
• Packages
• Sequences
• Stored functions, stored procedures
• Synonyms
• Tables
• Views.
A special schema PUBLIC is provided by Oracle Database 11g to contain objects that
are to be accessible to all users of the database. Typically, the kinds of objects that are
created in the PUBLIC schema are:
• Public database links that define access to remote databases;
• Public synonyms which point to objects which all users may need to access.
Schema Objects
Nonschema Objects
Security Target for Oracle Database 11g 15
Release 2 (11.2.0.2), Enterprise Edition
[SQL, chapter 3, section “Database Objects”] lists object types that can be created and
manipulated with SQL, but are not contained within a schema. These include:
• Contexts
• Directories
• Parameter files (PFILEs) and server parameter files (SPFILEs)
• Profiles
• Roles
• Rollback segments
• Tablespaces
• Users.
The primary storage management database object is a tablespace — it is used to
organise the logical storage of data. A suitably privileged user manages tablespaces to:
• create new tablespaces and allocate database files to the tablespace,
• add database files to existing tablespaces to increase storage capacity,
• assign default tablespaces to users for data storage, and
• alter tablespaces for backup and recovery operations.
Within the database files, Oracle Database 11g allocates space for data in three
hierarchical physical units: data blocks, extents, and segments. When a user creates a
schema object to store data (e.g., a table), a segment is created and the space for the
segment is allocated in a specific tablespace.
Oracle Database 11g has two kinds of user connection: administrative connection
(connecting AS SYSDBA or AS SYSOPER) and normal connection. Throughout this
document the following terms are used to classify the types of database users:
• Normal User/Database Subject:
A user who is connected via a normal connection. Note that the pre-defined users
SYS and SYSTEM can be normal users.
• Database Administrative User/Administrative User:
Any user who is authorised to perform administrative tasks. This term covers:
• A Normal User who is authorised to perform an administrative task via
the possession of an administrative privilege which permits the operation
of the task.
• A user who connects to the database via an administrative connection.
Users making an administrative connection are authorised to access the database by
virtue of having the SYSDBA or SYSOPER system privilege (i.e. they possess OS
platform specific access rights, or are listed in the Oracle Database 11g password file
as a SYSDBA or SYSOPER user).
Database Users
16 Security Target for Oracle Database 11g
Release 2 (11.2.0), Enterprise Edition
Note that the word authorised is used (e.g. “an authorised administrative user”) to
indicate that the user has the specific authorisation (e.g. via a privilege) for the
operation under consideration.
Database security is managed by privileged users through the maintenance of users,
roles, and profiles.
• USERS identify distinct database user names and their authentication method.
• ROLES provide a grouping mechanism for a set of privileges.
• PROFILES provide a set of properties (e.g., resource limits, password
management options) that can be assigned to individual users.
These security topics are discussed in detail in subsequent sections of this chapter.
In addition to the two types of users mentioned above the TOE also allows users to
managed either locally or centrally within a directory. Users managed within a
directory are called Enterpsise users. Each enterprise user has a unique identity across
the enterprise. Users defined locally in the database are called local users.
Single password authentication lets users authenticate to multiple databases with a
single global password although each connection requires a unique authentication. A
password verifier, which is the hash of the password is securely stored in the centrally
located, LDAP-compliant directory. In addition the directory also stores a user’s
global roles.
The password policy for Enterprise users is enforced by the directory, not by the TOE.
Passwords need to be set and changed via functions of the directory. The directory
server will then generate the password verifier (the hash value of the password).
Enterprise User Security requires Oracle Internet Directory 10g (9.0.4) or higher.
Other LDAP-compliant directory services are supported by using Oracle Internet
Directory Integration Platform to synchronize them with Oracle Internet Directory.
The evaluated configuration however is restricted to use Oracle Internet Directory.
Note that the Oracle Internet Directory is not part of the TOE but a part of the TOE
environment.
Although Enterprise User Security also offers user authentication using public key
certificates or using Kerberos, only password based authentication is supported in the
evaluated configuration.
Partitioning addresses key issues in supporting very large tables and indexes by letting
you decompose them into smaller and more manageable pieces called partitions. SQL
queries and DML statements do not need to be modified in order to access partitioned
tables. However, after partitions are defined, DDL statements can access and
manip¬ulate individual partitions rather than entire tables or indexes. This is how
partitioning can simplify the manageability of large database objects. Also,
partitioning is entirely transparent to applications.
Partitioning is useful for many different types of applications, particularly applications
that manage large volumes of data. OLTP systems often benefit from improvements in
manageability and availability, while data warehousing systems benefit from
performance and manageability.
Enterprise Users
Partitioning
Security Target for Oracle Database 11g 17
Release 2 (11.2.0.2), Enterprise Edition
Partitioning is a feature now included in the evaluated configuration. All the security
functions used to protect elements of an Oracle database defined in this Security
Target work transparently with Partitioning.
Real Application Clusters (RAC) comprises several Oracle instances running on
multiple clustered computers, which communicate with each other by means of a so-
called interconnect. RAC uses cluster software to access a shared database that resides
on shared disk. RAC combines the processing power of these multiple interconnected
computers to provide system redundancy, near linear scalability, and high availability.
RAC also offers significant advantages for both OLTP and data warehouse systems
and all systems and applications can efficiently exploit clustered environments.
Oracle Database 11g provides mechanisms to ensure that the consistency and integrity
of TSF and user data held in a database can be maintained. These mechanisms are
transactions, concurrency controls, and integrity constraints. Transactions ensure that
updates to the database occur in well-defined steps that move the database from one
consistent state to another. Transactions and concurrency controls together ensure that
multiple users can have shared access to the database with consistent and predictable
results: each user sees a consistent state of the database and can make updates without
interfering with other users. Integrity constraints ensure that the values of individual
data items are of the defined type and within defined limits, and that defined
relationships between database tables are properly maintained.
With RAC installed each instance of RAC maintains its own copy of the system
global area and the database cache, which are synchronized over the interconnect. In
addition global locks on the RAC environment ensure that concurrent updates are
synchronized. Those mechanisms together with the mechanisms mentioned above for
transaction management and concurrency control for the database ensure the
consistency and integrity of both user and TSF data in a RAC environment.
Access Control
Access control is the process of defining a user’s ability to read or write information.
For this, Oracle Database 11g provides discretionary access control (DAC).
DAC can be used to selectively share database information with other users. This
access control mechanism can be used to enforce need-to-know style confidentiality
as well as to control data disclosure, entry, modification, and destruction. In addition
to the DAC controls enforced by the Oracle Database 11g server, application-specific
access controls can be implemented using views and triggers to mediate a user’s
access to application data.
The DAC mechanism controls access to database objects based on the privileges
enabled in the database session. There are two types of DAC privileges: object
privileges and system privileges. Both object and system privileges may be granted
directly to individual users, or granted indirectly by granting the privilege to an Oracle
role and then granting the role to the user. Privileges and roles may also be granted to
PUBLIC, authorising all database users for the privilege. During a database session,
the privileges enabled in the session may be changed using several Oracle Database
11g mechanisms that affect the set of privileges held by the session.
Real Application
Clusters
Data Integrity
Discretionary Access
Control
18 Security Target for Oracle Database 11g
Release 2 (11.2.0), Enterprise Edition
Oracle Database 11g provides over 80 distinct system privileges to support the
concept of least privilege — each database user can be granted only those system
privileges that are needed to perform his or her job function. Often end-users would
only need a minimal set of system privileges to connect to the database. Some users
may be granted more powerful system privileges to authorise them to manage
administrative objects, bypass particular server access controls, or perform specialized
operations. A user may grant a system privilege to additional database users only if he
or she holds that privilege with an administrative option (WITH ADMIN OPTION).
An object privilege is permission to access a schema object in a prescribed manner
(e.g., to INSERT rows into a table or EXECUTE a stored procedure). The owner of
the schema containing the object may grant object privileges to other database users or
roles. In addition, the owner may grant other users the right to grant those object
privileges to additional database users (WITH GRANT OPTION).
Because object privileges are granted to users at the discretion of other users, this type
of security is termed discretionary. Oracle Database 11g ensures that users who
attempt to gain access to objects have been granted the necessary object privileges for
the specific operation, or have an overriding system privilege or role. The owner of an
object always has total access to that object.
Oracle Database 11g facilitates correct privilege administration by enabling privileges
to be grouped together into database roles. The benefits of Oracle database roles
include:
• Reduced privilege administration,
• Dynamic privilege management,
• Least privilege,
• Privilege bracketing, and
• Consistency.
Rather than explicitly granting the same set of privileges to several users, the
privileges for a group of related users can be granted to a role, and then only the role
needs to be granted to each member of the group. Roles permit numerous Oracle
privileges to be granted or revoked with a single SQL statement
If the privileges of a group of users must change, only the privileges of the role(s)
need to be modified instead of the privileges granted to every user. The security
domains of all users granted the group's role automatically reflect the changes made to
the role.
The roles granted to a user can be selectively enabled (available for use) or disabled
(not available for use). This helps a user to control use of those privileges which could
result in unintended disclosure, entry, modification, or destruction of data.
Because the Oracle data dictionary records which roles have been granted to the
System Privileges
Object Privileges
Roles
Reduced privilege
administration
Dynamic privilege
management
Least privilege
Privilege Bracketing
Security Target for Oracle Database 11g 19
Release 2 (11.2.0.2), Enterprise Edition
current user, database applications can be designed to query the dictionary and
automatically enable and disable selective roles when a user attempts to execute
applications.
To enable centralised implementation of privilege management in a system of which
Oracle may be only one component, Oracle also provides for linking database roles to
platform-specific group access controls. In this way, database roles can only be
enabled by users if they are a current member of the appropriate group in the
underlying platform. This helps to ensure a correct and consistent implementation of a
system-wide security policy. Note that this feature is not used to implement any
security functional requirement of this Security Target.
A secure application role is a role which is enabled by a PL/SQL package. A database
administrative user can grant a secure application role all the privileges necessary to
run a particular application. The role will then only be enabled if the application’s
check of the relevant conditions is successful. This means that the use of such a role
can be based on information about the user’s session, such as the IP address of a user
who has connected through a proxy.
Global roles are roles assigned to an Enterprise User within the user schema in the
directory server. Assigning privileges to global roles is still done within each database.
This allows to have the privileges associated with a global role to be defined and
managed individually for each database. When an Enterprise user successfully logs
into a database, the database will get the user’s global roles from the directory and
than assigns the user’s privileges in accordance with the privileges assigned to the
local and global roles the user has.
Privileges held via roles cannot be used to perform a DML operation that is required
to issue a DDL statements. For example a user who receives the SELECT ANY
TABLE system privilege or the SELECT object privilege for a table through a role
can use neither privilege to create a view on a table that belongs to another user. The
user must have directly granted privileges authorising the access to the underlying
tables.
By default Oracle databases contain several pre-defined roles including:
• CONNECT — containing the system privileges to connect and create basic
schema objects,
• RESOURCE — containing the system privileges necessary to create PL/SQL
program units and triggers, and
• DBA — containing all system privileges WITH ADMIN OPTION.
These roles are provided for backward compatibility and can be modified or removed
by suitably privileged users [SG, 4].
During the database session, the privileges held by the session can vary. When a
database session is initially established, it has all of the system and object privileges
System Security Policy
Secure Application Roles
Global Roles
DDL Restriction
Pre-defined Roles
Session Privileges
20 Security Target for Oracle Database 11g
Release 2 (11.2.0), Enterprise Edition
directly granted to the user in addition to those granted to PUBLIC. The session also
has all of the privileges granted to any default roles associated with the user. The set
of privileges can be changed by:
• Enabling and disabling roles,
• Accessing a view,
• Executing a stored program unit, or
• Firing a trigger.
During a database session, a user can enable and disable any granted role.
Consequently, the privileges of the database subject can be modified to reflect
different requirements for access to database objects.
When a user creates a view, that user must have directly granted privileges that
authorise access to all of the tables (or views) referenced in the view’s query. In
addition, if the user holds the necessary privileges WITH GRANT option or WITH
ADMIN option, then the user may grant access to the view to other database users,
authorizing them for indirect access to the tables in the view. In this way, views can
be used to restrict access to information based on complex SQL queries that select
only the authorised data from the tables.
In order to use a stored program unit (procedure, function, or package), a user must
have the privilege to EXECUTE the program unit. However, when the program unit
runs, the privileges for its execution may be set to the owner’s directly granted
privileges (definers rights), or the invoker’s privileges (invokers rights) depending on
options set when the program unit is created. This allows access privileges to be
encapsulated with the database operations being performed by the program unit. Any
user with EXECUTE privilege for the program unit is authorised to indirectly access
any database objects accessible to the program unit’s owner.
The security context for the execution of triggers is similar to that of stored program
units. When a trigger fires as a result of a table access, the execution privileges for the
trigger are set to the trigger owner’s directly granted privileges rather than the
privileges of the user who initiated the table update.
Fine-grained (or row-level) access control is available with the virtual private database
(VPD) technology which is a standard feature of the Oracle Database 1 1g Enterprise
Edition. Fine-grained access control allows a database administrative user to associate
security policies with tables, views and synonyms. These policies are implemented by
PL/SQL functions and are enforced on a normal user no matter how the data is
accessed (unless the user is authorised by the possession of the system privilege
EXEMPT ACCESS POLICY). Such security policies can be defined to be enforced
when a query references particular columns.
Different policies can be applied for SELECT, INSERT, UPDATE and DELETE
operations. Note that the use of the Oracle Database 1 1g MERGE SQL command
causes SELECT and INSERT or UPDATE operations to be performed. Note also that
it is possible for more than one policy to be applied to a table, including building on
top of base policies in packaged applications.
Enabling Roles
Views
Stored Program Units
Triggers
Fine-grained Access
Control
Security Target for Oracle Database 11g 21
Release 2 (11.2.0.2), Enterprise Edition
This feature is not used to implement the access control policy defined in chapters 5 of
this document. Only aspect c) of F.DAC.OBA in chapter 6 is related to this function.
An application context allows an application to make security decisions based on
additional attributes attached to a user’s session information. An application context
provides a protected session persistent storage area for additional user attributes
defined by the application.
To support application managed session pooling by middle tier applications, the
DBMS_SESSION interface for managing application context is enhanced for Oracle
Database 11g. This interface now has a client identifier for each application context so
that the application context can be managed globally while each client will see only
their assigned application context.
Oracle Database 1 1g provides the ability to partition security policy enforcement by
application. This enables different security policies to be applied, depending upon
which application is accessing the data. Oracle Database 1 1g enables partitioning of
fine-grained access control through policy groups and a driving application context.
The driving application context securely determines which application is accessing the
data, and policy groups facilitate the management of policies which apply by
application.
A database administrative user specifies which policy group the policy falls into when
adding a policy to a table/view using the ADD _GROUPED _POLICY interface. The
driving context is defined using the ADD _POLICY _CONTEXT interface.
This feature is not used to implement the access control policy defined in chapters 5
Quotas
Using Oracle Database 11g profiles, a database administrative user can set quotas on
the amount of processing resources a user can consume during a database session.
Limits can be specified for the following:
• enabled roles per session (via an init.ora parameter)
• database sessions per user,
• CPU time per session,
• CPU time per SQL call,
• connect time per session,
• idle time per session,
• database reads per session,
• database reads per SQL command, and
• a composite limit (based on CPU time, connect time, and database reads).
Once a profile has been created, it can be assigned to one or more users, depending on
their need for processing resources. When a user exceeds the resource limit, the
Oracle Database 11g server will abort the operation, and, in some cases, terminate the
Application Context
Partitioned Fine-grained
Access Control
22 Security Target for Oracle Database 11g
Release 2 (11.2.0), Enterprise Edition
user’s session, or, in other cases, simply terminate the current SQL statement or
rollback the current transaction.
A database administrative user may also set quotas on the amount of storage space
that can be allocated for each user’s schema objects in any specific tablespace.
Resumable statements are a feature in Oracle Database 11g which allows an
administrator to temporarily suspend a large operation, such as a batch update data
load. This might be necessary when space has run out. Suspending the operation gives
the database administrator an opportunity to take corrective steps to resolve the error
condition. After the error has been corrected, the suspended operation automatically
resumes execution. A suspended resumable operation is aborted automatically if the
error is not fixed within a set time period.
Users must have the RESUMABLE system privilege before they can execute
resumable operations. An ALTER SESSION ENABLE RESUMABLE statement is
provided to enable SQL statements to be resumable when they are invoked within the
session. Resumable operations are suspended under one of the conditions: Out of
space, Space limit error, or Space quota error.
Identification and Authentication
Oracle Database 11g always identifies authorised users of an Oracle database prior to
establishing a database session for the user. Authentication can be performed directly
by the Oracle Database 11g server using passwords managed by the server, or the
server can rely on the authentication done by the underlying OS platform.
For OS authentication, the database user connects to the Oracle Database 11g server
without specifying a user name or password. The server obtains the user’s identity
from the OS, and if the user is an authorised database user, a database session is
created. This form of authentication is appropriate for Oracle Database 11g only if it is
running on a Microsoft Windows operating system. Since no Microsoft Windows
operating system platforms are to be used for this evaluation, the TOE does not use
this form of authentication.
As an option the TOE can authenticate users via a TOE-external LDAP compliant
directory server (e. g. Oracle Internet Directory). This function (named “Enterprise
Users”) is included as an option for authenticating users in the TOE but restricted to
password based authentication only. Other authentication options (e. g. using digital
certificates) are not supported in the evaluated configuration.
For Oracle authentication, a user must specify a user name and password in order to
connect. For local authentication the password is compared to the password for the
user stored in the data dictionary and if they match, a database session is created. The
user’s password is stored in the data dictionary in a one-way encrypted form, so
before the comparison is made, the password specified by the user is also one-way
encrypted.
For enterprise user authentication using passwords the database server requests the
user password verifier from the directory and performs the comparison. When
successful, the database gets the user’s global roles from the directory.
A local user may change his or her password at any time. Oracle Database 11g
provides the facility for suitably privileged users to create password complexity check
functions that can screen new passwords of local users for certain criteria, e.g.:
Password Management
Security Target for Oracle Database 11g 23
Release 2 (11.2.0.2), Enterprise Edition
• a minimum number of characters in length;
• not equal to the user name;
• includes a minimum number of alphabetic, numeric, or punctuation characters;
• does not match any word on an internal list of words;
• differs from the previous password by a certain number of characters.
A suitably authorised user can also set password lifetime, a failed logon count leading
to account lockout, expiration options, and password reuse requirements in an Oracle
Database 11g profile. By assigning different profiles to different groups of users, the
password management parameters can vary among users.
By default the database does not enforce any password profile limits, however it is
critical that certain password controls are used in all profiles such that the TOE
achieves a high strength of function for the password mechanism. Guidance covering
the different password controls, and instructions for modifying profiles to achieve
strong passwords, is provided in the TOE’s Evaluated Configuration Document
[ECD].
For Enterprise Users the password management is performed by the external LDAP
server and is therefore a function of the IT-environment.
Database administrative users may connect to the database to perform functions such
as starting up or shutting down an Oracle Database 11g instance. These users can be
authorised by either the use of a password file, or by having platform-specific access
rights.
Platform-specific access rights are normally established by being a member of a
special operating system group. For example, on a UNIX platform, the group defaults
to the ‘dba’ group, but can be changed.
When a database administrative user wants to undertake special operations, he or she
connects to the database through a special keyword: AS SYSDBA or AS SYSOPER.
When connected using the AS SYSDBA keywords the database session then runs as
the user SYS. When connected using the AS SYSOPER keyword the database session
then runs as the user PUBLIC.
Auditing
Oracle Database 11g ensures that relevant information about operations performed by
users can be recorded so that the consequences of those operations can later be linked
to the user in question, and the user held accountable for his or her actions. Oracle
Database 11g does this by providing auditing options which are designed to be as
granular and flexible as possible to ensure that exactly what needs to be audited, as
dictated by the application or system security policy, is recorded, but nothing more.
This helps to ensure that the size of audit trails remain manageable and the important
records easily accessible. Oracle Database 11g provides capabilities to permit auditing
plans to be quickly enabled to implement crisis responses. In addition to the standard
Oracle Database 11g auditing features described here, application-specific audit trails
can be implemented using triggers to capture auditing details about the changes made
to the information in the database.
Special Authentication
24 Security Target for Oracle Database 11g
Release 2 (11.2.0), Enterprise Edition
A database administrative user can request auditing of a number of actions in each of
three categories:
• By Statement
Auditing specific types of SQL statements including database connections and
disconnections. Statement auditing can be set to audit one, several, or all users.
• By Object
Auditing specific statements on specific database objects for all users.
• By Privilege
Auditing use of specific system privileges. Privilege auditing can be set to audit
one, several, or all users.
Database administrative users can further focus each auditing request by specifying
auditing for only successful, only unsuccessful, or both successful and unsuccessful
attempts. Such users can also specify, for most audit events, that audit records be
created by session or by access: by session results in only a single record for an
audited action for the duration of a database session; by access results in a record for
every occurrence of an audited action.
Oracle also permits database administrative users to assign default object auditing
options which will automatically be used for any new schema objects which are
created.
Database administrative users can request fine-grained auditing to monitor query
access based on content and can also request that DML operations be monitored.
Whenever the policy conditions are met for returning a row from a query block, the
query is audited. These policies are implemented by PL/SQL functions.
Note that fine-grained auditing is not required to satisfy the security functional
requirements for auditing defined in chapter 5.
Oracle auditing permits audit information to be written to a database audit trail or to
the audit trail of the underlying operating system. Audit records always include the
following elements when they are meaningful for the audited event:
• User;
• Session Identifier;
• Terminal Identifier;
• Name of Object Accessed;
• Operation Performed;
• Completion Code of Operation;
• Date and Timestamp;
• System Privilege Used.
If Oracle writes to the database audit trail, then the powerful SQL data manipulation
facilities of the DBMS can be used by database administrative users to perform
Audit Categories
Audit Options
Fine-Grained Auditing
Audit Records
Audit Analysis
Security Target for Oracle Database 11g 25
Release 2 (11.2.0.2), Enterprise Edition
selective audit analysis of relevant database operations, user actions, uses of privilege,
and object accesses in a secure manner. Oracle provides a number of pre-defined
views on the database audit trail to assist in such audit analysis.
If Oracle is configured to write to an operating system audit trail, then platform
services can be used to consolidate and analyse the database audit trail with audit
trails from other system components to provide a comprehensive auditing portrait for
the system. Alternatively, the audit data in the operating system or network services
audit trail could be loaded securely into an Oracle database for comprehensive audit
analysis using the SQL data manipulation facilities of the DBMS.
Connections AS SYSDBA and AS SYSOPER along with attempts to startup or
shutdown an instance are always recorded in the OS platform audit trail because they
are OS events and because the database may not be available to be written into.
Oracle Database 11g provides for information to be written to the OS platform audit
trail about all SQL commands performed by users connected as the special user SYS
and users connected through the keywords AS SYSDBA and AS SYSOPER. Such OS
audit trail files should have OS DAC protection set by the OS system administrator to
prevent all database users being able to tamper with them (including those users who
are able to connect to the database as the special user SYS or through the keywords
AS SYSDBA or AS SYSOPER). Note that this auditing is still performed by the TOE
but using an object provided by the underlying OS instead of the database audit trail.
Security Management
Oracle Database 1 1g provides a number of mechanisms to support the management
of database security. This section discusses the administrative system privileges, the
importance of the initialisation file, the use of AS SYSOPER and AS SYSDBA, and
Oracle Database 1 1g server dependencies on the administration of the underlying OS
platform.
Oracle Database 11g contains over 80 distinct system privileges. Each system
privilege allows a user to perform a particular database operation or class of database
operations. If a user has no privileges then they cannot perform any operations,
including connecting to the database.
Database Administrative Users acquire the ability to perform administrative functions
by being granted specific administrative system privileges. Other users are given only
a minimal set of privileges allowing them to connect to the database and access the
necessary data.
Oracle Database 11g security management can be delegated to any number of users.
Site-specific roles can be defined to delegate administrative responsibilities based on
organisational structures.
When an Oracle Database 1 1g instance is started, the parameters specified in an
initialisation file specify operational characteristics of Oracle Database 1 1g server
functionality, including security functionality. It is critical that the security parameters
specified in the initialisation file for the instance be set to the values which conform to
the evaluated configuration. The parameter values required by this security target are
identified in the TOE’s Evaluated Configuration Document [ECD].
Auditing of SYS
Administrative
Privileges
Initialisation File
26 Security Target for Oracle Database 11g
Release 2 (11.2.0), Enterprise Edition
When a user is connected AS SYSOPER or AS SYSDBA, the user is authorised to
perform special database operations. Authorisation to connect as AS SYSDBA or AS
SYSOPER is made via OS mechanisms (i.e., membership in an OS-defined group and
requires that a user be authenticated by the OS), or by an Oracle Database 11g
password.
A user connected AS SYSOPER is authorised to perform database startup, shutdown,
create server parameter file and backup operations. A user connected via AS
SYSDBA has the same authorisations as SYSOPER with the additional capabilities to
create databases and perform the operations allowed by all system privileges WITH
ADMIN option. Users who connect via AS SYSDBA have access to all of the data
dictionary tables and can grant and/or revoke object privileges on other users’ objects.
The security of the data managed by the Oracle Database 11g data server is dependent
not only on the secure administration of Oracle Database 11g, but also on the correct
administration of the underlying OS platform and any other nodes connected in a
distributed environment. The requirements on OS and network configuration for this
security target are identified in the TOE’s Evaluated Configuration Document [ECD].
Guidance on the correct configuration of Oracle Database 11g for a specific OS
platform is contained in the Oracle Database 11g Installation Guide [ICG] for that
platform.
In addition the security management also includes the management of the user
information for Enterprise users which is stored in the Oracle Internet Directory. The
roles and privileges for Enterprise users are determined form roles and privileges
stored locally in the database as well as global roles stored and managed in the
directory. Only the management of local roles and privileges as well as the assignment
of privileges to global roles is part of the TOE management functions while the
assignment of global roles to Enterprise users is performed within the TOE
environment (the directory server). The requirements for the protection and
management of Enterprise users specific for the evaluated configuration are also
identified in the TOE’s Evaluated Configuration Document [ECD]. The standard
procedures for management of Enterprise users are described in Oracle Database 11g
Enterprise User Administrator’s Guide [EUA]
Consistency of Replicated TSF Data
TSF data is replicated in the TOE in the following situations:
• TSF data is stored in the system global area (SGA) or in the database cache in
addition to its storage on disk. TSF data is held in data structures that are part of
the database and the mechanisms used for maintaining the consistency between the
cache/SGA and the data stored on disk apply for all database objects. Transac¬tion
management ensures the consistency of data between the cache and the disk.
• In the case of Real Application Clusters, the SGA and the cache are replicated in
each node. Consistency for this replicated data is achived by having each item in
the cache or SGA being managed by one dedicated master node for the item which
initiates and controls the update of SGA and cache on the other nodes. Those
updates are done using the interconnect. In addition the interconnect is also used
SYSDBA and SYSOPER
OS Administration
Enterprise User
Administration
Security Target for Oracle Database 11g 27
Release 2 (11.2.0.2), Enterprise Edition
for a heartbeat of each node. If a node fails to present the heartbeat, other nodes
will take over the responsibility for the items managed by this node. Global
locking mechanisms are used to synchronize concurrent database updates in a
RAC environment.
Secure Distributed Processing
The basic distributed features included in the Oracle Database 11g server make use of
database links to define a connection path to a remote Oracle database. When a
connection is made to a remote database, the information in the database link
definition is used to provide identification and authentication information to the
remote Oracle server. The remote server creates a database session for the user
specified by the database link (if the user is authorised for access to the remote
database) and then makes its access control decisions based on that identity and its
privileges in the remote database.
By using database links to qualify schema object names, a user in a local database can
• select (e.g., join) data from tables in any number of remote Oracle databases,
• use DML statements to update tables in remote Oracle databases (Oracle
Database 11g automatically implements a two-phase commit protocol), and
• execute stored program units in remote Oracle databases.
Access to the remote database is transparent; however careful administration and
control of the distributed environment is essential (see [DAG, part 5]). Access to non-
Oracle distributed databases is provided by Oracle Database 11g, but such databases
are not part of the evaluated configuration.
Other Oracle Database 11g Security Features
In addition to the security features described above, Oracle Database 1 1g provides
features which are related to security but do not directly address any of the functional
requirements identified in this Oracle Database 1 1g Security Target. These features
provide significant security capabilities to support robust and reliable database
applications. Apart from Data Integrity, for which no specific security functionality is
claimed in Chapter 6, the features described below are not part of the evaluated
configuration defined in [ECD].
It is important to ensure that data can be moved out of one database and re-inserted
into the same or a different database while maintaining the data integrity and
confidentiality. Oracle enables secure exporting of information from a database into
an operating system file. Only appropriately privileged users may export information
to which they do not normally have read access. Similarly, Oracle enables secure
importing of information into a database from Oracle-generated operating system
export files. Only appropriately privileged users may import information into database
tables to which they do not normally have write access.
When a database object is exported, the list of users having object privileges to access
the object can also be exported and then imported into the new database with the
database object.
Import/Export
28 Security Target for Oracle Database 11g
Release 2 (11.2.0), Enterprise Edition
Backup of an Oracle database can be performed using platform-specific backup
programs, the Oracle database import/export utilities, or the Oracle database recovery
manager. The choice of mechanism depends upon the application needs, but all
approaches can provide secure, reliable backup and recovery of the database.
The Oracle Database 11g transaction integrity mechanisms also provide the basis for
secure recovery following the failure of an Oracle Database 1 1g instance or platform
operating system. Whenever an Oracle Database 1 1g instance is started, any
transactions that were not committed prior to the failure are rolled back. This returns
all of the information in the database, including the data dictionary tables, to a
consistent and secure state.
Oracle Advanced Security is an optional product which provides encryption of the
Oracle network traffic between clients and servers and between two communicating
servers and adaptors for various external authentication services and certificate
authorities.
A number of standard packages are available to install in an Oracle database. These
provide supportive functionality that can be invoked by other users and applications.
They provide the following types of functions:
• Access to SQL features from PL/SQL programs, including dynamic SQL,
• Alert mechanisms for asynchronous notification of database events,
• File access functions to read and write OS files,
• Job queues for scheduling repeating administrative procedures,
• Lock management functions for user-defined locks,
• Oracle pipes for communication among database sessions,
• Output operations for procedure debugging,
• Functions to manipulate LOBs,
• Queues for asynchronous message generation and delivery (Advanced Queuing),
• Administration of distributed transactions and snapshots, and
• HTTP callouts to access Web services.
In addition to the authentication methods described above, Oracle Database 1 1g can
be configured to use an external third party authentication service. Only the use of
Enterprise Users managed in a directory server is supported in the evaluated
configuration as an authentication service based on information stored external to the
TOE. In the case of Enterprise users the TOE will request the password verifier from
the directory, compute the hash of the password entered by the user and perform the
comparison. Therefore Enterprise users are authenticated by the TOE based on a
password verifier that is generated and managed in the TOE environment.
Backup and Recovery
Oracle Advanced
Security
Supplied Packages
External Authentication
Services
Security Target for Oracle Database 11g 29
Release 2 (11.2.0.2), Enterprise Edition
Roles can be protected by use of a password. Applications can be created specifically
to enable a role when the application is supplied with the correct password. Users can
not enable the database role if they do not know the password.
SQLJ allows application programmers to embed static SQL operations in Java code in
a way that is compatible with the Java design philosophy. Oracle provides support for
SQLJ at both the client and server, so that database applications written in Java may
be executed at the client or at the server.
Oracle supports two SQLJ client side models; a thick client model where Java
programs can make calls to the database via OCI using Oracle Net Services, and a thin
client model where Java programs can call the database server directly bypassing the
Oracle Net Services interface.
Application-Specific
Security
Support for SQLJ
30 Security Target for Oracle Database 11g
Release 2 (11.2.0), Enterprise Edition
CHAPTER
3 Security Problem
Definition
Threats
[BR-DBMSPP], section 3.1 provides the characterization of the threat agents
considered as well as the threats to be countered. The following additional threats are
handled by the TOE:
T.RESOURCE Excessive Consumption of Resources. An authenticated database
user consumes global database resources, in a way which
compromises the ability of other database users to access the DBMS.
T.AUDIT_COMPROMISE A user or process may view audit records, cause audit
records to be lost or modified, or prevent future audit records from
being recorded, thus masking a user’s action.
Organisational Security Policies
[BR-DBMSPP], section 3.2 provides the definition of the organizational security
policies that apply for the TOE.
Assumptions
As per [BR-DBMSPP], section 3.3. The following additions have been added to
reflect the specific architecture of the TOE:
Underlying System Assumptions
A.MIDTIER To ensure accountability in multi-tier environments, any
middletier(s) will pass the original client ID through to the TOE.
A.DIR_PROT The directory server used by the TOE provides protection
mechanisms against unauthorized access to TSF data stored in the
directory. This includes the assumptions that queries are properly
Security Target for Oracle Database 11g 31
Release 2 (11.2.0.2), Enterprise Edition
authenticated, that the TSF data stored in the directory is protected
by the access control mechanisms of the directory server, that the
TSF data in the directory server is properly managed by the
administrative personnel, and that the directory server as well as its
network connections are physically and logically protected from
access and interference by unuathorized persons.
A.DIR_MGMT The information about enterprise users stored in the directory
(password verifier, password policy, global roles and privileges) is
managed correctly by authorized personnel of the Enterprise.
A.COM_PROT Internal TSF communication as well as communication between the
TOE and the directory server are protected from unauthorized
access to the transmitted data and ensure that the communication
piers are the intended ones.
A.CLIENT_AP Client applications are assumed to be developed in accordance with
Oracle’s application development documentation and not use any
undocumented interfaces of the client part of the TOE.
32 Security Target for Oracle Database 11g
Release 2 (11.2.0), Enterprise Edition
CHAPTER
4 Security Objectives
TOE Security Objectives
As per [BR-DBMSPP], section 4.1 with the addition of the following objectives:
O.RESOURCE The TOE must provide the means of controlling the consumption of
database resources by authorised users of the TOE.
O.AUDIT_REVIEW The TOE must provide the means of reviewing the audit log
entries allowing user with the required access rights to the audit log
to evaluate the audit log entries.
O.AUDIT_PROTECTION The TOE will provide the capability to protect audit
information.
Environmental Security Objectives
As per [BR-DBMSPP], section 4.2 with the following addition:.
OE.DIR_CONTROL The directory server must provide access control mechanisms to
prohibit unauthorized access to directory entries. The directory
server must authenticate users before it allows them to access TSF
data stored in the directory.
OE.COM_PROT The environment must provide protection mechanisms that prohibit
unauthorized access to data the TOE transfers over communication
links. This applies to data the TOE transmits to another part of itself
as well as data exchanged between the TOE and the external
directory server. This protection may be provided by physical
protection, logical protection or a combination of both.
OE.CLIENT_AP The environment must ensure that only applications developed in
accordance with the Oracle development guidance using the
published interfaces are installed on the client system.
Security Target for Oracle Database 11g 33
Release 2 (11.2.0.2), Enterprise Edition
Security Objectives Rationale
As per [BR-DBMSPP, chapter 6] with the additional TOE security objectives
O.RESOURCE, O.AUDIT_REVIEW, O.AUDIT_PROTECTION and the additional
environmental security objectives OE.DIR_CONTROL and OE.COMPROT.
This section therefore discusses only the additional security objectives not included in
[BR-DBMSPP].
O.RESOURCE helps to mitigate the threat T.RESOURCE by ensuring that individual
users can not use more of specific resources than defined in their quota. An authorized
administrator that can assign quotas to users can use this function to ensure that a
sufficient amount of resources of a specific kind is always available allowing
authorized users to use the DBMS at any time they are allowed by the TOE policy to
use it.
O.AUDIT_REVIEW helps to address the organizational security policy
P.ACCOUNTABILITY by providing authorized administrators with the ability to
selectively review the audit log information.
O.AUDIT_PROTECT helps to mitigate the threat T.AUDIT_COMPROMISE by
protecting the audit trail from unauthorized access and loss of audit records.
OE.DIR _CONTROL addresses the need to control an external directory server used
as an external entity supporting the TOE in the authentication of Enterprise Users.
Proper authentication and access control is required to prohibit that user information
stored in the directory is accessed in an unauthorized way. OE.DIR_CONTROL is
mapped to SFRs for the IT environment (specific for the directory server).
OE.COM_PROT addresses the need to protect communication links between
distributed parts of the TOE as well as between the TOE and the external directory
server.
OE.CLIENT_AP addresses the need to have only applications installed on the client
system that are developed in accordance with the Oracle development guidance and
use only the interfaces published there.
The assumptions rationale in [BR-DBMSPP, chapter 6.2] applies to the TOE, with the
following additions:
A.MIDTIER states that any middle-tier must pass the original client ID through to the
TOE. A.MIDTIER is directly provided by OE.NO_EVIL because [ECD] includes this
requirement for the use of a middle-tier and advises the administrator how to
configure it correctly.
A.DIR_PROT states that the directory server used to store information for Enterprise
Users is protected from unauthorized access and managed correctly. A.DIR_PROT is
provided by OE.DIR_CONTROL and the guidance for the configuration and
management of the directory server. OE.DIR_CONTROL is an objective for the IT
environment, since the directory server is not part of the TOE.
A.DIR_MGMT states that the the information about Enterprise users stored in the
directory is managed by authorized personnel only. This is provided by
Assumptions Rationale
34 Security Target for Oracle Database 11g
Release 2 (11.2.0), Enterprise Edition
OE.DIR_CONTROL which allows to restrict access to the information on Enterprise
users to defined users.
A.COM_PROT states that communication links between distributed parts of the TOE
as well as communication links between the TOE and the external directory server
need to be protected. This assumption is covered by OE.COM_PROT.
A.CLIENT_AP states that client applications shall be developed in accordance with
the Oracle development documentation and only use the published interfaces. This
assumption is covered by OE.CLIENT.AP.
Security Target for Oracle Database 11g 35
Release 2 (11.2.0.2), Enterprise Edition
CHAPTER
5 IT Security
Requirements
TOE Security Functional Requirements
Table 3 below lists each Security Functional Requirement (SFR) included in this
Security Target. Since this Security Target claims compliance to [BR-DBMSPP], all
SFRs listed in this Protection Profile are part of this table. Additional SFRs not
contained in [BR-DBMSPP] are marked in bold.
For each SFR, Table 3 identifies which Common Criteria operations (assignment (A),
selection (S), refinement (R), and/or iteration (I)) have additionally been applied,
namely:
a) (for SFRs that are in [BR-DBMSPP]): the operations additional to those in [BR-
DBMSPP]; or
b) (for the SFRs that are not in [BR-DBMSPP]): the operations additional to Part 2 of
[CC].
The remainder of this section details the functional requirements as completed for this
Security Target. The text for completed operations which have been applied to the
requirement relative to the Basic Robustness DBMS Protection Profile [BR-
DBMSPP] or relative to Part 2 of [CC] (for SFRs that are not [BR-DBMSPP]) is
highlighted with ITALICISED CAPITAL LETTERS within each requirement. Annex B
provides definitions for various terms used in the functional requirements.
36 Security Target for Oracle Database 11g
Release 2 (11.2.0), Enterprise Edition
Table 3: List of Security Functional Requirements
Component Name A S R I
FAU_GEN.1-
NIAP-0410
Audit Data Generation X X X
FAU_GEN_
(EXT).2 User and/or Group Identity Association
FAU_SAR.1 Audit Review X
FAU_SAR.3 Selectable Audit Review X X
FAU_SEL.1-
NIAP-0407
Selective Audit X X
FAU_STG.1 Protected Audit Trail Storage X
FAU_STG.4 Prevention of Audit Data Loss X X
FDP_ACC.1 Subset Access Control
FDP_ACF.1-
NIAP-0407
Security Attribute Based Access Control X X
FDP_RIP.1 Subset Residual Information Protection X
FIA_AFL.1 Authentication Failure Handling X X
FIA_ATD. 1 User Attribute Definition X
FIA_SOS.1 Verification of Secrets X X
FIA_UAU.1 Timing of Authentication X
FIA_UID.1 Timing of Identification X
FIA_USB.1 User-Subject Binding X
FMT_MOF.1 Management of Security Functions Behaviour
FMT_MSA.1 Management of Security Attributes
FMT_MSA_
(EXT).3
Static Attribute Initialisation
FMT_MTD.1(1) Management of TSF Data (auditable events) X
FMT_MTD.1(2)
Management of TSF Data (other than auditable
events)
X X X X
FMT_REV.1(1) Revocation (User Attributes) X X
FMT_REV.1(2) Revocation (Subject, Object Attributes) X X
FMT_SMF. 1 Specification of Management Functions X
FMT_SMR.1 Security Roles X
FPT_TRC_
(EXT).1
Internal TSF Consistency
FRU_RSA.1 Maximum Quotas X X
Security Target for Oracle Database 11g 37
Release 2 (11.2.0.2), Enterprise Edition
Component Name A S R I
FTA_MCS. 1 Basic Limitation on Multiple Concurrent Sessions X
FTA_TAH_
(EXT).1
TOE Access History
FTA_TSE. 1 TOE Session Establishment X
FAU_GEN.1.1-NIAP-0410 The TSF shall be able to generate an audit record of the
following auditable events:
a) Start-up and shutdown of the audit functions;
b) All auditable events for the minimum level of audit listed in
Table 8 OF [BR-DBMSPP] AND TABLE 4 BELOW; and
c) Start-up and shutdown of the DBMS;
d) Use of special permissions (e.g., those often used by authorized
administrators to circumvent access control policies); and
e) NO ADDITIONAL EVENTS.
Table 4: List of Auditable Events for the additional SFRs
Component Event Additional Data
FAU_SAR.1 ReadingofinformationfromtheDATABASE
audit records
None
FAU_SAR.3 None None
FAU_STG.1 None None
FAU_STG.4 Actions taken due to audit storage failure None
FIA_AFL.1 Lockingofanaccountduetotoomanyfailed
authentication attempts
None
FIA_SOS.1 Successful and unsuccessful attempts to change a
user’s password
None
FIA_UAU.1
All use of the DATABASE user authentication
mechanism, including success or failure of the
authentication attempt
None
FIA_UID.1
All use of the DATABASE user identification
mechanism, including the DATABASE user iden-
tity provided
None
FIA_USB.1
Success and failure of binding of DATABASE
user security attributes to a DATABASE subject
(e.g. success and failure to create a DATABASE
subject)
None
FMT_MTD.1(2) None None
Security Audit
38 Security Target for Oracle Database 11g
Release 2 (11.2.0), Enterprise Edition
Component Event Additional Data
FRU_RSA.1
All attempted uses of the DATABASE resource
allocation functions for resources that are under
control of the TSF
None
FAU_GEN.1.2-NIAP-0410 The TSF shall record within each audit record at least the
following information:
a) Date and time of the event, type of event, subject identity (if
applicable), and the outcome (success or failure) of the event;
and
b) For each audit event type, based on the auditable event
definitions of the functional components included in the PP/ST,
information specified in column 3 of table 8 OF [BR-DBMSPP].
FAU_GEN_(EXT).2.1 For audit events resulting from actions of identified users and/
or identified groups, the TSF shall be able to associate each
auditable event with the identity of the user and/or group that caused
the event.
FAU_SAR.1.1 The TSF shall provide USERS WITH READ ACCESS TO
SYS.AUD$ with the capability to read ALL DATABASE AUDIT
INFORMATION from the audit records.
FAU_SAR.1.2 The TSF shall provide the audit records in a manner suitable for the
user to interpret the information.
Application note:
In addition users can read their own audit records but do not have
access to other audit records unless they satisfy the criteria defined
by FAU_SAR.1.1.
FAU_SAR.3.1 The TSF shall provide the ability to perform SEARCHES AND
SORTING of audit data based on THE VALUES OF AUDIT DATA
FIELDS.
Application note:
The Common Criteria defines the second assignment as
‘[assignment: criteria with logical relations]’. Since audit data is
stored within a database, the TOE allows to use SQL to search and
sort the audit data, which provides more possibilities for logical
relations than can be expressed in such an assignment. The ST
author therefore has chosen the wording as expressed in the SFR
above.
FAU_SEL.1.1-NIAP-0407 The TSF shall allow only the administrator to include or
exclude auditable events from the set of events to be audited based
on the following attributes:
a) user identity and/or group identity;
b) event type;
c) object identity;
Security Target for Oracle Database 11g 39
Release 2 (11.2.0.2), Enterprise Edition
d) SUBJECT IDENTITY;
e) success of auditable security events;
f) failure of auditable security events;
g) DATABASE SYSTEM PRIVILEGE;
h)
i)
STATEMENT AUDITING
j)
PRIVILEGE AUDITING
Application note:
SCHEMA OBJECT AUDITING
[BR-DBMSPP] requires the ST writer to define the event type, but
does not have an assignment or selection option in the SFR to do
this. The ST author has therefore decided to refine the requirement
to include also the following criteria an administrator can use to
include or exclude an auditable event:
1 Statement auditing
2 Privilege auditing
3 Schema object auditing
For additional information on those event types see [SG, chapter 9].
There was a small editorial change in CC V3.1 R3 related to this
SFR. The SFR in this ST has adopted this and is therefore textwise
not fully compliant with the one stated in [BR-DBMSPP].
FAU_STG.1.1 The TSF shall protect the stored audit records from unauthorized
deletion.
FAU_STG.1.2 The TSF shall be able to PREVENT unauthorised modifications to
the stored audit records in the audit trail.
FAU_STG.4.1 The TSF shall PREVENT AUDITABLE EVENTS, EXCEPT THOSE
TAKEN BY THE AUTHORISED USER WITH SPECIAL RIGHTS, if
the audit trail is full.
FDP_ACC.1.1 The TSF shall enforce the Discretionary Access Control policy on
all subjects, all DBMS-controlled objects and all operations among
them.
FDP_ACF.1.1-NIAP-0407 The TSF shall enforce the Discretionary Access Control
policy to objects based on the following:
a) the authorized user identity and/or group membership
associated with a subject;
b) access operations implemented for DBMS-controlled objects;
and
c) object identity.
FDP_ACF.1.2-NIAP-0407 The TSF shall enforce the following rules to determine if
an operation among controlled subjects and DBMS-controlled
objects is allowed:
User Data Protection
40 Security Target for Oracle Database 11g
Release 2 (11.2.0), Enterprise Edition
The Discretionary Access Control policy mechanism shall, either by
explicit authorized user/group action or by default, provide that
database management system controlled objects are protected from
unauthorized access according to the following ordered rules:
a) IF THE REQUESTED MODE OF ACCESS IS DENIED TO
THAT AUTHORIZED USER, DENY ACCESS;
b) IF THE REQUESTED MODE OF ACCESS IS PERMITTED
TO THAT AUTHORIZED USER, PERMIT ACCESS;
c) IF THE REQUESTED MODE OF ACCESS IS DENIED TO
EVERY GROUP OF WHICH THE AUTHORIZED USER IS A
MEMBER, DENY ACCESS;
d) IF THE REQUESTED MODE OF ACCESS IS PERMITTED
TO ANY GROUP OF WHICH THE AUTHORIZED USER IS A
MEMBER, GRANT ACCESS;
e) ELSE, DENY ACCESS
Application note:
[BR-DBMSPP] includes an application note for FDP_ACF.1.2-
NIAP-0407 stating that the deny mode of access may be implicit.
Oracle Database 11g does not have explicit deny lists, but satisfies
the requirement by implicitly denying access unless it is explicitly
allowed. As the application note in [BR-DBMSPP] explains this is
compliant with the requirement FDP_ACF.1.2-NIAP-0407 as
included in [BR-DBMSPP].
FDP_ACF.1.3-NIAP-0407 The TSF shall explicitly authorise access of subjects to
DBMS-controlled objects based on the following additional rules:
a) IF THE DATABASE SUBJECT HAS A DATABASE
ADMINISTRATIVE PRIVILEGE TO OVERRIDE THE
DATABASE OBJECT ACCESS CONTROLS FOR THE
REQUESTED ACCESS TO THE DATABASE OBJECT, THEN
THE REQUESTED ACCESS IS ALLOWED;
b) IF THE SUBJECT IS CONNECTED AS SYSDBA THEN THE
REQUESTED ACCESS IS ALLOWED; OR
c) IF THE SUBJECT IS CONNECTED AS SYSOPER AND THE
REQUESTED ACTION IS ONE OF THE OPERATIONS
PERMITTED FOR THE SYSOPER USER SPECIFIED IN
[DAG, 1], THEN THE REQUESTED ACCESS IS ALLOWED.
FDP_ACF.1.4-NIAP-0407 The TSF shall explicitly deny access of subjects to objects
based on the following additional rules: NO ADDITIONAL
EXPLICIT DENIAL RULES.
Application Note:
The word “additional” has been added to comply with CC V3.1 R3.
FDP_RIP.1.1 The TSF shall ensure that any previous information content of a
resource is made unavailable upon the allocation of the resource to
SCHEMA OBJECTS (INCLUDING NON-SCHEMA OBJECTS,
WHICH ARE STORED IN THE SYS SCHEMA).
Security Target for Oracle Database 11g 41
Release 2 (11.2.0.2), Enterprise Edition
FIA_AFL.1.1 The TSF shall detect when AN ADMINISTRATOR
CONFIGURABLE POSITIVE INTEGER WITHIN THE RANGE 1
TO 2,147,483,646 unsuccessful authentication attempts occur
related to A USER’S LAST SUCCESSFUL DATABASE SESSION
ESTABLISHMENT.
Application Note:
The values allowed for those parameters in the evaluated
configuration are defined in [ECD].
FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts
has been MET, the TSF shall LOCK THE DATABASE USER’S
ACCOUNT.
Application Note:
In the case of Enterprise Users no such counter is held and managed
globally. Also for Enterprise Users the counters are held locally on
each database instance.
FIA_ATD.1.1 The TSF shall maintain the following list of security attributes
belonging to individual users:
a) Database user identifier and/or group memberships;
b) Security-relevant database roles; and
c) DATABASE OBJECT ACCESS PRIVILEGES;
d) DATABASE ADMINISTRATIVE PRIVILEGES;
Application Note:
Also in the case of Enterprise users the TSF will maintain the list of
security attributes of the user once the user has been authenticated.
The TSF will extract global roles of an Enterprsie user from the
directory once the user is successfully authenticated and set the
user’s roles and privileges as the combination of both his local and
global roles and the privileges assigned to those roles. After this step
the directory is not contacted again during a user’s session. All
access decisions are performed by the TSF based on the user’s
security attributes determined after successful authentication.
FIA_SOS.1.1 The TSF shall provide a mechanism to verify that secrets
(PASSWORDS FOR USERS) meet REUSE, LIFETIME, AND
CONTENT METRICS AS DEFINED BY AN AUTHORISED
ADMINISTRATIVE USER.
Application Note:
In the case of Enterprise Users the Directory Server checks the
password policy. This SFR for the TOE applies therefore only for
local users. In the case of Enterprise Users the IT environment (the
directory) will enforce the password policy defined by the directory.
Identification and
Authentication
42 Security Target for Oracle Database 11g
Release 2 (11.2.0), Enterprise Edition
FIA_UAU.1.1 The TSF shall allow THE FOLLOWING LIST OF ACTIONS on
behalf of the user to be performed before the user is authenticated:
a) OBTAIN THE CURRENT ORACLE VERSION STRING AND
NUMBER;
b) ESTABLISH A DATABASE CONNECTION; AND;
c) RECEIVE AN ERROR MESSAGE UPON ERROR.
FIA_UAU.1.2 The TSF shall require each user to be successfully authenticated
before allowing any other TSF-mediated actions on behalf of that
user.
FIA_UID.1.1 The TSF shall allow THE FOLLOWING LIST OF ACTIONS on
behalf of the user to be performed before the user is identified:
a) OBTAIN THE CURRENT ORACLE VERSION STRING AND
NUMBER;
b) ESTABLISH A DATABASE CONNECTION; AND;
c) RECEIVE ERROR MESSAGES UPON ERROR.
FIA_UID.1.2 The TSF shall require each user to be successfully identified before
allowing any other TSF-mediated actions on behalf of that user.
FIA_USB.1.1 The TSF shall associate the following user security attributes with
subjects acting on the behalf of that user: USER IDENTIFIER,
PRIVILEGES AND ROLES.
FIA_USB.1.2 The TSF shall enforce the following rules on the initial association
of user security attributes with subjects acting on the behalf of users:
a) ONCE A USER HAS BEEN SUCCESSFULLY IDENTIFIED
AND AUTHENTICATED AT THE START OF A SESSION
WITH THE TSF, THE USER’S IDENTIFIER IS ACCESSIBLE
THROUGHOUT THAT SESSION.
b) AN OBJECT OR SYSTEM PRIVILEGE IS EFFECTIVE AT
THE START OF A USER SESSION IF IT WAS PREVIOUSLY
GRANTED TO THE USER (AND NOT SUBSEQUENTLY
REVOKED) DIRECTLY, VIA THE PUBLIC USER GROUP OR
VIA A ROLE, OR (IN THE CASE OF EN ENTERPRISE USER)
GRANTED AS A GLOBAL ROLE OR PRIVILEGE IN THE
DIRECTORY.
c) A USER ESTABLISHING A PROXY SESSION WITH THE TSF
ON BEHALF OF ANOTHER USER CAN CONTROL WHICH
ROLES ARE AVAILABLE TO THAT USER AT THE START OF
THE SESSION.
FIA_USB.1.3 The TSF shall enforce the following rules governing changes to the
user security attributes associated with subjects acting on the behalf
of users:
a) IF AN OBJECT OR SYSTEM PRIVILEGE APPLYING TO A
USER IS GRANTED OR REVOKED WHILE THE USER HAS
A CURRENT SESSION WITH THE TSF, THIS CHANGE
APPLIES TO THE SET OF LOCALLY MANAGED
Security Target for Oracle Database 11g 43
Release 2 (11.2.0.2), Enterprise Edition
PRIVILEGES EFFECTIVE DURING THE USER SESSION.
THIS RULE APPLIES TO PRIVILEGES GRANTED TO THE
USER DIRECTLY OR VIA THE PUBLIC USER GROUP OR
VIA A ROLE. IN THE CASE OF AN ENTERPRISE USER
CHANGES TO HIS GLOBAL ROLES AND PRIVILEGES
BECOME EFFECTIVE THE NEXT TIME THE USER LOGS
ON.
b) DURING A SESSION WITH THE TSF, THE USER CAN
CONTROL WHICH ROLES GRANTED TO THAT USER ARE
EFFECTIVE.
c) IF A USER EXECUTES A VIEW OR A PROGRAM UNIT
OWNED BY ANOTHER USER THAT WAS CREATED WITH
“DEFINER’S RIGHTS”, THE PRIVILEGES OF THE
OWNING USER ARE EFFECTIVE DURING THE
EXECUTION OF THE VIEW OR PROGRAM UNIT.
d) A LOCAL USER CAN CHANGE THE PASSWORD
ASSOCIATED WITH THAT USER IF THE NEW PASSWORD
COMPLIES WITH THE CONFIGURABLE CONTROLS
INCLUDED IN THE PASSWORD MANAGEMENT
INFORMATION THAT APPLIES TO THE USER.
FMT_MOF.1.1 The TSF shall restrict the ability to disable and enable the functions
relating to the specification of events to be audited to authorized
administrators.
FMT_MSA.1.1 The TSF shall enforce the Discretionary Access Control policy to
restrict the ability to manage all the security attributes to authorized
administrators.
Application note:
This requirement is implemented as follows:
a) database object access privileges to the object’s owner and
other database users authorized by the owner.
b) database system privileges to users who have been granted that
privilege with admin option or users who connect as sysdba.
c) database roles to database users authorized to modify roles.
This requirement applies to all security attributes stored and
managed by the TSF. For security attributes managed outside of the
TSF, the IT environment needs to ensure proper management.
Application note:
A refinement of this requirement has been performed in [BR-
DBMSPP] and this refinement is also included in this Security
Target.
Security Management
44 Security Target for Oracle Database 11g
Release 2 (11.2.0), Enterprise Edition
FMT_MSA_(EXT).3.1 The TSF shall enforce the Discretionary Access Control policy
to provide restrictive default values for security attributes that are
used to enforce the SFP.
Application note:
This requirement applies to all security attributes managed locally
by the TSF. For security attributes managed outside of the TSF, the
IT environment needs to ensure proper management.
FMT_MTD.1.1(1) The TSF shall restrict the ability to include or exclude the auditable
events to authorized administrators.
FMT_MTD.1.1(2) The TSF shall, ACCORDING TO TABLES 5 BELOW, restrict the
ability to PERFORM OPERATIONS ON the TSF DATA to
AUTHORIZED ADMINISTRATORS.
FMT_REV.1.1(1) The TSF shall restrict the ability to revoke THE RESOURCE
LIMITS, ROLES AND PRIVILEGES associated with the USERS
under the control of the TSC to THE AUTHORISED
ADMINISTRATOR.
Application note:
This requirement applies to all security attributes managed locally
by the TSF. For security attributes managed outside of the TSF, the
IT environment needs to ensure proper management.
Application note:
This requirement has been modified from the requirement as stated
in [BR-DBMSPP] to take the format of the component as defined in
CC V3.1 R3. The content has been preserved. This modification is
necessary to make this ST compliant with CC V3.1 R3 while the
original version of [BR-DBMSPP] was developed before release 3
of CC V3.1 was published and the latest version of [BR-DBMSPP]
was not adjusted with CC V3.1 Release 3.
FMT_REV.1.2(1) The TSF shall enforce the FOLLOWING rules:
a) REVOCATION OF DATABASE ADMINISTRATIVE
PRIVILEGES SHALL TAKE EFFECT PRIOR TO WHEN THE
DATABASE USER BEGINS THE NEXT DATABASE SESSION;
FMT_REV.1.1(2) The TSF shall restrict the ability to revoke ALL MANAGEABLE
security attributes associated with the OBJECTS under the control
of the TSC to the AUTHORISED ADMINISTRATOR AND
DATABASE USERS AS ALLOWED BY THE
DISCRETIONARY ACCESS CONTROL POLICY.
Application note:
This requirement has been modified from the requirement as stated
in [BR-DBMSPP] to take the format of the component as defined in
CC V3.1 R3. The content has been preserved. This modification is
necessary to make this ST compliant with CC V3.1 R3 while the
original version of [BR-DBMSPP] was developed before release 3
of CC V3.1 was published and the latest version of [BR-DBMSPP]
was not adjusted with CC V3.1 Release 3.
Security Target for Oracle Database 11g 45
Release 2 (11.2.0.2), Enterprise Edition
FMT_REV.1.2(2) The TSF shall enforce the FOLLOWING rules:
a) REVOCATION OF DATABASE OBJECT ACCESS
PRIVILEGES SHALL TAKE EFFECT PRIOR TO ALL
SUBSEQUENT ATTEMPTS TO ESTABLISH ACCESS TO THE
DATABASE OBJECT;
FMT_SMF.1.1 The TSF shall be capable of performing the following management
functions:
a) THE OPERATIONS ON TSF DATA SPECIFIED IN TABLE 5
BELOW;
b) MODIFICATION OF THE DATABASE OBJECT SECURITY
ATTRIBUTES AS SPECIFIED IN SFR FMT_MSA.1.1.
Table 5: Required Management Functionality
Component Operation TSF Data
FAU_GEN.1-NIAP-
0410
- -
FAU_GEN_(EXT).2 - -
FAU_SAR.1
deletion,
modification,
addition
the group of database users with
read access right to the database
audit records
FAU_SAR.3 - -
FAU_SEL.1-NIAP-
0407
maintenance of
the right to view /
modify
the database audit events
FAU_STG.1 - -
FAU_STG.4
a) maintenance
b) deletion,
modification,
addition
actions to be taken in case of
DATABASE audit storage failure
FDP_ACC.1 - -
FDP_ACF.1-NIAP-
0407
managing
the attributes used to make explicit
access or denial based decisions
FDP_RIP.1 - -
FIA_AFL.1 management
a)the threshold for unsuccessful
DATABASE authentication
attempts
b)actions to be taken in the event
of an DATABASE authentication
failure
FIA_ATD.1
46 Security Target for Oracle Database 11g
Release 2 (11.2.0), Enterprise Edition
Component Operation TSF Data
FIA_SOS.1 management
the metric used to verify the DATA-
BASE secrets
FIA_UAU.1 management
a)the DATABASE authentication
data
b)the DATABASE authentication
data by the associated DATABASE
user
c)the action lists, if an authorised
DATABASE administrator can
change the actions allowed before
authentication
FIA_UID. 1 management the user identities
FIA_USB.1 - -
FMT_MOF. 1 manage auditable events
FMT_MSA. 1 manage
the group of DATABASE roles that
can interact with the DATABASE
security attributes
FMT_MSA_(EXT).3 manage
a) thegroupofDATABASErolesthat
can specify initial values
b) the permissive or restrictive setting
of default values for a given
DATABASE access control SFP
FMT_MTD. 1 manage
the group of DATABASE roles that
can interact with the TSF data
FMT _REV. 1(1)
FMT_REV. 1(2)
FMT_SMR. 1 manage
the group of DATABASE users that
are part of a DATABASE role
FRU_RSA. 1 specify
maximum limits for a resource for
DATABASE groups and/or individ-
ual DATABASE users and/or
DATABASE subjects by an DATA-
BASE administrator
FTA_MCS.1 manage
the maximum allowed number of
concurrent DATABASE user
DATABASE sessions by a DATA-
BASE administrator
FTA_TAH_(EXT).1 - -
FTA_TSE.1 - -
Security Target for Oracle Database 11g 47
Release 2 (11.2.0.2), Enterprise Edition
Application note:
In [BR-DBMSPP] the SFR is related to ‘security management
functions’. This Security Target has chosen the wording
‘management functions’ as defined in part 2 of the Common Criteria.
FMT_SMR.1.1 The TSF shall maintain the roles:
a) authorized administrator; and
b) DATABASE USER;
c) DATABASE ROLES DEFINED BY SUITABLY PRIVILEGED
DATABASE ADMINISTRATIVE USERS.
FMT_SMR.1.2 The TSF shall be able to associate users with roles.
FPT_TRC_(EXT).1.1 The TSF shall ensure that TSF data is consistent between parts
of the TOE by providing a mechanism to bring inconsistent TSF
data into a consistent state in a timely manner.
Application note:
It should be noted that the TOE holds TSF data like all the user
related data, all the privileges and user roles as well as its
configuration data and audit data in data structures that are part of
the database. The TOE replicates TSF data between the disk and its
cache and system global area to ensure fast access to the data.
Consistency between the data on disk and the data in the cache is
achieved using the database mechanisms to ensure data integrity on
database update.
In the case of Real Application Cluster, the cache and system global
area itself are replicated on each node and consistency is achieved
using RAC specific functions to manage the update of items in the
cache or system global area on each node.
It should be noted that other mechanisms like RAID may optionally
be used to ensure consistency of replicated data on disks. Those
mechanisms are not part of the TOE but are part of the TOE
environment. They are neither mandated by the TOE, nor are they -
if used - evaluated in any way in this evaluation.
FRU_RSA.1.1 The TSF shall enforce maximum quotas of the following resources:
a) CPU_TIME;
b) ELAPSED TIME;
c) LOGICAL DATA BLOCKS READ; AND:
d) DATABASE STORAGE ALLOCATED. that AN INDIVIDUAL
USER can use OVER A SPECIFIED PERIOD OF TIME.
FTA_MCS.1.1 The TSF shall restrict the maximum number of concurrent sessions
that belong to the same user.
Protection of the TOE
Security Functions
Resource Utilisation
TOE Access
48 Security Target for Oracle Database 11g
Release 2 (11.2.0), Enterprise Edition
FTA_MCS.1.2 The TSF shall enforce, by default, a limit of AN ADMIN
CONFIGURABLE NUMBER OF sessions per user.
FTA_TAH_(EXT).1.1 Upon successful session establishment, the TSF shall store and
retrieve the date and time of the last successful session
establishment to the user.
FTA_TAH_(EXT).1.2 Upon successful session establishment, the TSF shall store and
retrieve the date and time of the last unsuccessful attempt to session
establishment and the number of unsuccessful attempts since the last
successful session establishment.
FTA_TSE.1.1 The TSF shall be able to deny session establishment based on
attributes that can be set explicitly by authorized administrator(s),
including user identity and/or group identity, time of day, day of the
week, and NO ADDITIONAL ATTRIBUTES.
Application Note:
Note that the DBA and OPER users can always connect to the
database.
TOE Security Assurance Requirements
The target assurance level is EAL4 as defined in Part 3 of the CC, augmented with
ALC_FLR.3. This is a superset of the security assurance requirements of
[BR-DBMSPP].
Security Requirements Rationale
[BR-DBMSPP, section 6.3] show that the SFRs defined in [BR-DBMSPP, sections
5.1 and 5.2 and 5.3] satisfy the IT security objectives defined in [BR-DBMSPP].
The table below correlates the IT security objectives to the SFR that is additional to
those provided in [BR-DBMSPP] which satisfy them (as indicated by a Y), showing
that each IT security objective is satisfied by the additional SFR, and that the
additional SFR satisfies at least one IT security objective. Note that some additional
SFRs actually contribute to satisfy security objectives defined in [BR-DBMSPP].
Therefore the security objectives those SFRs contribute to are listed in the table, while
those security objectives listed in [BR-DBMSPP] where none of the additional SFRs
contribute to are not listed.
Suitability of Security
Requirements
Security Target for Oracle Database 11g 49
Release 2 (11.2.0.2), Enterprise Edition
Table 6: Correlation of IT Security Objectives to the
SFR Additional to [BR-DBMSPP] and to the
security architecture
Requirement
O.RESOURCE
O.AUDIT_REVIEW
O.AUDIT_PROTECTION
O.TOE_ACCESS
O.MANAGE
FAU_SAR.1 Y
FAU_SAR.3 Y
FAU_STG.1 Y
FAU_STG.4 Y
FIA_AFL.1 Y
FIA_SOS.1 Y
FIA_UAU.1 Y
FIA_UID. 1 Y
FIA_USB.1 Y
FIA_MTD.1(2) Y
FRU_RSA.1 Y
Note: O.TOE_ACCESS is an objective defined in [BR_DBMSPP], but it maps to
several of the additional SFRs in this Security Target. Therefore this objective is listed
in the table.
[BR_DBMSPP] maps the security objective O.PARTIAL_SELF_PROTECTION to
ADV_ARC.1 and not to any SFR. This is viewed as acceptable, since the objective is
indeed fully addressed by the security architecture.
Suitability of the additional SFRs
FAU_SAR.1 in conjunction with FMT_MTD.1(2) and FMT_SMF.1 allows an
authorized administrator to read the audit records.
FAU_SAR.3 in combination with FAU_SAR.1 allows to evaluate the audit records
thus assisting in making users accountable for their actions.
FAU_STG.1 in combination with FPT_SEP_EXP.1 allows the TOE to protect the
audit records from unauthorized deletion.
50 Security Target for Oracle Database 11g
Release 2 (11.2.0), Enterprise Edition
FAU_STG.4 in combination with FPT_SEP_EXP.1, FMT_MTD.1(2) and
FMT_SMF.1 allows to limit the loss of audit records in the event the audit log gets
full.
FIA_AFL.1 in combination with FMT_MTD.1(2) and FMT_SMF.1 allows an
authorized administrator to limit the number of unsuccessful authentication attempts.
FIA_SOS.1 in combination with FMT_MTD.1(2) and FMT_SMF.1 allows an
authorized administrator to define a password policy enforcing a defined metric for
password quality.
FIA_UAU.1 in combination with FIA_UID.1 ensures that users must identify and
authenticate correctly before they are allowed to use TOE functions that require
access control, accountability or the use of resources that can be limited.
FIA_UID.1 supports FIA_UAU.1 and ensures that the TOE is able to identify the
identity of users as required for the access control, accountability and resource control
functions.
FIA_USB.1 relies on FIA_UAU.1 and FIA_UID.1 to provide the correct user identity
and allows database subjects to identify the user they are action on behalf of. This
function allows the TSF to link calls of TSF interfaces by database subjects with the
user this call is associated with and thus perform access control, accountability and
resource control also for functions a database subject performs on behalf of a user.
ADV_ARC.1 ensures that any access to controlled resources of the TOE that is
performed using interfaces of the TOE is mediated by the access control functions of
the TOE.
FRU_RSA.1 in combination with FMT_MTD.1(2) and FMT_SMF.1 ensures that an
authorized administrator is able to define resource limits for defined resources that a
user is allowed to use and ensure that the user does not exceed the defined limits.
In addition with the rationale provided in [BR-DBMSPP], this rationale thus
demonstrates the suitability of the TOE security requirements.
Table 14 in [BR-DBMSPP] provides the dependency analysis for the SFRs included
there. The following modifications to the arguments provided there apply for this
TOE:
FAU_GEN_EXP.2: Due to the additional functions included in the TOE the
dependency on FIA_UID.1 is satisfied by the TOE, not the TOE environment.
FMT_SMR.1: Due to the additional functions included in the TOE the dependency on
FIA_UID.1 is satisfied by the TOE, not the TOE environment.
FTA_MCS.1: Due to the additional functions included in the TOE the dependency on
FIA_UID.1 is satisfied by the TOE, not the TOE environment.
The following table includes the dependency analysis for the additional SFRs included
in this ST:
Dependency Analysis
Security Target for Oracle Database 11g 51
Release 2 (11.2.0.2), Enterprise Edition
Table 7: Functional Component Dependency Analysis
Requirement Dependencies Satisfied
FAU_SAR.1 FAU_GEN.1
Yes, by
FAU_GEN.1-
NIAP-0410
FAU_SAR.3 FAU_SAR. 1 Yes
FAU_STG.1 FAU_GEN.1
Yes, by
FAU_GEN.1-
NIAP-0410
FAU_STG.4 FAU_STG. 1 Yes
FIA_AFL.1 FIA_UAU.1 Yes
FIA_SOS.1 - -
FIA_UAU.1 FIA_UID.1 Yes
FIA_UID.1 - -
FIA_USB.1 FIA_ATD.1 Yes
FMT_MTD.1(2) FMT_SMF.1
FMT_SMR. 1
Yes
FRU_RSA.1 - -
For the dependency analysis of the security assurance requirements: EAL4 is a self-
contained assurance package and ALC_FLR.3 has no dependencies on any other
component.
The supportive dependencies discussed in [BR-DBMSPP] apply to the TOE. The
following additional supportive dependencies exist for the TOE with the SFRs that are
not present in [BR-DBMSPP]:
FAU_SAR.1 and FAU_SAR.3 are supported by FMT_SMF.1 and FMT_SMR.1 to
manage the privileges allowing an authorized administrator to read and evaluate the
audit records, by FAU_STG.1 to protect the audit trail from unauthorized access and
by FAU_STG.4 to ensure the completeness of the audit trail.
FAU_STG.1 supports FAU_SAR.1 by preventing unauthorized access to the audit
trail.
FAU_STG.4 supports FAU_SAR.1 and FAU_SAR.3 by ensuring the completeness of
the audit trail.
FIA_AFL.1 supports FIA_UAU.1 and FIA_SOS.1 by ensuring that the authentication
function is not weakened by allowing unlimited authentication attempts.
Demonstration of
Mutual Support
52 Security Target for Oracle Database 11g
Release 2 (11.2.0), Enterprise Edition
FIA_SOS.1 supports FIA_UAU.1 by ensuring that passwords are not easily guessable
thereby reducing the probability of an unauthorized person getting access to the TOE.
FIA_UAU.1 together with FIA_USB.1 supports almost all other functions by ensuring
that the TOE can make decisions (access, audit, management) based on the verified
identity of the user.
FIA_UID.1 supports FIA_USB.1 allowing to bind database subjects to users.
FRU_RSA.1 is a security function of its own. It is supported by the user identification
and authentication allowing to enforce quotas for users and FMT_MTD.1 allowing to
manage those quotas.
The target assurance level is EAL4, augmented with ALC_FLR.3, which exceeds the
minimum assurance requirement stated in [BR-DBMSPP]. EAL4 is appropriate for
the TOE because it is designed for use in environments where EAL4 assurance is
required to reduce the risk to the assets that the TOE is intended to protect.
ALC_FLR.3 has been included in addition to EAL4 to cause the evaluation of the
TOE’s flaw remediation procedures which Oracle database users need to be in place
following the release of the TOE. These procedures are required to offer continuing
assurance to users that Oracle Database 11g provides secure storage of and access to
the data which is crucial to their enterprise’s success.
To meet this requirement, the flaw remediation procedures must offer:
• the ability for TOE users to report potential security flaws to Oracle,
• the resolution and correction of any flaws with assurance that the corrections
introduce no new security flaws, and
• the timely distribution of corrective actions to users.
ALC_FLR.3 is the ALC_FLR component which is at an appropriate level of rigour to
cover these requirements.
Assurance Requirements
Appropriate
Security Target for Oracle Database 11g 53
Release 2 (11.2.0.2), Enterprise Edition
Assurance Measures Rationale
Table 9 in Chapter 6 demonstrates that all assurance requirements are suitably met by
one or more assurance measures.
54 Security Target for Oracle Database 11g
Release 2 (11.2.0), Enterprise Edition
CHAPTER
6 TOE Summary
Specification
TOE Security Functionality
This section contains a high-level specification of each Security Function (SF) of the
TOE that contributes to satisfaction of the Security Functional Requirements of
chapter 5. The specifications cover five major areas: identification and authentication,
database resource quotas, access controls, privileges and roles, and auditing.
Table 8 below shows that all the SFRs are satisfied by at least one SF and that every
SF is used to satisfy at least one SFR (but note that SFR FDP_ACF.1.4 is not satisfied
by any particular SF because this SFR specifies null functionality).
Security Target for Oracle Database 11g 55
Release 2 (11.2.0.2), Enterprise Edition
Table 8: Mapping of SFs to SFRs
FIA FDP FMT
FPT
FRU
FTA FAU
AFL.1.1
AFL.1.2
ATD.1.1
SOS.1.1
UAU.1.1
UAU.1.2
UID.1.1
UID.1.2
USB.1.1
USB.1.2
USB.1.3
ACC.1.1
ACF.1.1-NIAP
ACF.1.2-NIAP
ACF.1.3-NIAP
ACF.1.4-NIAP
RIP.1
MOF.1.1
MSA.1.1
MSA_(EXT).3.1
MTD.1.1(1)
MTD.1.1(2)
REV.1.1(1)
REV.1.2(1)
REV.1.1(2)
REV.1.2(2)
SMF.1.1
SMR.1.1
SMR.1.2
TRC_(EXT).1.1
RSA.1.1
MCS.1.1
MCS.1.2
TAH_(EXP).1.1
TAH_(EXP).1.2
TSE.1.1
GEN.1.1-NIAP
GEN.1.2-NIAP
GEN_(EXT).1.2
SAR.1.1
SAR.1.2
SAR.3.1
SEL.1.1-NIAP
STG.1.1
STG.1.2
STG.4.1
F.IA.PRE Y Y Y Y
F.IA.UID Y Y
F.IA.DBA Y Y Y
F.IA.EUA Y Y Y
F.IA.CNF Y
F.IA.IDE Y Y
F.IA.CSA Y Y Y Y Y Y Y
F.IA.CSN Y Y Y Y Y Y
F.IA.PWD Y Y Y
F.IA.ATT Y Y Y Y
F.IA.ATT-EU Y Y Y Y
F.IA.USE Y Y
F.LIM.CNF Y Y Y Y Y
F.LIM.POL Y Y
F.LIM.NSESS Y Y Y
F.LIM.TIME Y
F.LIM.RSESS Y
F.LIM.RCALL Y
F.DAC.OBID Y Y Y
F.DAC.OBREF Y Y Y
F.DAC.SUA Y Y
F.DAC.OBA Y Y
F.DAC.POL Y Y Y Y
F.DAC.OR Y
F.APR.GOP Y Y Y
F.APR.ROP Y Y Y Y
F.APR.GRSP Y Y Y Y
F.APR.GRR Y Y Y Y Y
F.APR.DER Y
F.APR.EDR Y Y
F.PRI.SPRIV Y Y Y Y Y Y Y Y
F.PRI.XVP Y
F.PRI.PRX Y Y
F.PRI.DEF Y
F.AUD.SOM Y Y
F.AUD.SEV Y Y Y
F.AUD.ALW Y Y
F.AUD.CNF Y Y Y Y
F.AUD.ACC Y Y Y Y
F.AUD.DEL Y Y Y Y
F.AUD.INF Y Y
F.AUD.VIEW Y Y
F.AUD.FULL Y
F.CON.DIC Y
F.CON.RAC Y
56 Security Target for Oracle Database 11g
Release 2 (11.2.0), Enterprise Edition
F.IA.PRE The TOE shall only allow users to:
a) obtain the current TOE version string and version number;
b) establish a connection;
c) receive error messages upon error
before identifying and authenticating the user.
Note that users can obtain the current Oracle version string and version number by
calling OCIServerVersion, as described in [OCI, 17: OCIServerVersion].
F.IA.UID Each database user is uniquely identified.
F.IA.DBA DBMS Identification and Authentication:
If a user is configured in the TOE as a local user being
authenticated by a password then the TOE will:
a) identify the user by confirming that the user provides a valid
user identifier, and
b) authenticate the user by confirming that the user provides a
password corresponding to the stored password for that user.
F.IA.EUA Enterprise User Identification and Authentication:
If a user is configured in the TOE as an Enterprise User being
authenticated by a password then the TOE will:
a) identify the user by confirming with a reqeust to the directory
that the user provides a valid user identifier for a global user,
and
b) authenticate the user by confirming that the value of the
password presented by the user is identical to the password
verifier retrieved for that user from the directory
Note that in the case of an enterprise user the TOE is still mediating the
authentication, obtains the user’s password, computes the hash value of the password,
obtains the password verifier for that user from the directory and compares the two
values. Only in this case the TOE will allow the user login to proceed and will
establish a session for the user. In the case the two values don’t match the TOE will
reject the user.
The TOE therefore is directly involved in the authentication process, although the
hash value of the password is stored and managed outside of the TOE. The TOE
therefore has to rely on the correct operation of the directory server, the correct
management of the user’s password and security attributes in the directory server, the
protection of the user’s password and security attributes in the directory server, and
the protection of the communication between the TOE and the directory server. Still
the TOE is directly involved in the user identification and authentication process since
the external user will use the same TSF interface for authentication and perform the
comparison of the hash values, regardless if the TOE uses local authentication or
Enterprise User authentication.
Identification and
Authentication
Security Target for Oracle Database 11g 57
Release 2 (11.2.0.2), Enterprise Edition
F.IA.CSN The TOE will create a database session as a normal user only if the
CREATE SESSION privilege is held by the database user and the
TOE has identified and authenticated the user as a valid database
user. The supplied LOGON trigger function can be used to restrict
the ability of a user to login to specific days of the week and specific
times of the day. Such a LOGON trigger can also be used to store
and retrieve the time and day of the last successful login as well as
the number of unsuccessful login attempts since the last successful
login.
(Note: triggers are functions the database calls upon specific events.
Login is one of the those events a trigger can be assigned to.)
F.IA.IDE For each interaction between a user and the TOE following the
successful creation of a database session, the TOE is able to
establish the identity of the user. A subject can only submit requests
to a Server and receive responses (information) from a Server while
the subject is establishing a connection or connected to an instance
during the course of a database session.
F.IA.CSA The TOE will create a database session as the SYS user (for AS
SYSDBA connections) or the PUBLIC user (for AS SYSOPER
connections) only if the provided user identifier and password
correspond to users stored in the Oracle password file as being
allowed SYSDBA or SYSOPER connections, respectively.
F.IA.CNF The TOE will allow only a suitably authorised user to create a local
database user.
F.IA.PWD The TOE provides the following configurable controls on passwords
for local users: [SQL, 15: CREATE PROFILE]
a) the number of failed login attempts before the user account is
locked,
b) the number of days the same password can be used before
expiring,
c) the number of days before which a password cannot be reused
d) the number of password changes required before the current
password can be reused,
e) the number of days a user account will be locked after the
specified number of consecutive failed logins,
f) the number of days of grace period after a password expires
before the user account is locked,
g) a password complexity check to screen passwords selected by
the user.
F.IA.ATT The data dictionary contains a unique set of security attributes for
each local user including their username, password management
information, account status (i.e. locked or unlocked), privileges,
roles and resource limits that can be displayed and modified by
suitably authorised users using standard SQL commands.
58 Security Target for Oracle Database 11g
Release 2 (11.2.0), Enterprise Edition
F.IA.ATT-EU In the case of an enterprise user the password management
information is held in the directory. Privileges and roles are
determined by the TOE using a combination of the local privileges
and roles stored for the user in the local database and the global
roles stored and managed for the user in the directory.
Note that the determination of a user’s privileges and attributes is
still a function of the TOE even in the case of enterprise users,
although this function then may retrieve and use also information
about the user from the directory. Note that the directory stores only
information about the global roles a user has. Assigning privileges
to those global roles is still done in each database. The privileges
assigned to global roles may therefore differ from database to
database. Managing the privileges assigned to global roles is
therefore done in each database and uses the same management
functions as are used for managing local roles.
F.IA.USE A local database user is authorised to change the password
associated with that user within the following constraints:
a) If the user’s profile includes a complexity check function, then
the new password is accepted only if it meets the criteria of the
complexity check.
b) If the user’s profile specifies password reuse constraints and the
user attempts to reuse a password, the TOE rejects the change if
the reuse constraints are not met. [SQL, 15: CREATE
PROFILE].
F.LIM.CNF The TOE will allow only a suitably authorised user to:
a) alter the default Resource Profile for a database;
b) create and alter specific Resource Profiles and assign and
reassign them to each individual database users.
F.LIM.POL When a user attempts to use a database resource that is subject to
controls specified by Resource Profiles, the TOE will enforce the
limits specified by the resource profile (if any) explicitly assigned to
the user, otherwise it enforces the limits specified by the default
Resource Profile for the database.
F.LIM.NSESS The TOE prevents a user from creating more than the maximum
number of concurrent sessions specified for that user for an instance
of the TOE.
F.LIM.TIME If a user exceeds the specified CONNECT_TIME or IDLE_TIME
resource limits by the (OS specific) amount for a single session then
the TOE will terminate the session when the user attempts an
operation.
Resource Control
Database Resources
Security Target for Oracle Database 11g 59
Release 2 (11.2.0.2), Enterprise Edition
F.LIM.RSESS If a user attempts to perform an operation that exceeds the specified
resource limits for a single session then the TOE will:
a) terminate the operation;
b) force the termination of the session.
F.LIM.RCALL If a user attempts to perform an operation that exceeds the specified
resource limits for a single SQL statement then the TOE will
terminate the operation.
F.DAC.OBID The TOE ensures that every object created in a database is uniquely
identified in that database. Specifically, each schema object owned
by a normal user is uniquely identified within the user’s schema2
F.DAC.OBREF The TOE correctly resolves every reference to a database object that
conforms to the Object naming rules specified in [SQL, 3],
including references via database links
.
3
F.DAC.SUA For normal users, the TOE enforces DAC on database objects based
on the following subject attributes:
.
a) the identity of the user associated with the database session;
b) the system privileges and object privileges which are effective
for the database session.
F.DAC.OBA For normal users, the TOE enforces DAC on database objects based
on the following object attributes:
a) the identity of the owner of the object;
b) the object privileges which have been granted on the object;
c) and any security policies providing fine-grained access control
for the object.
F.DAC.POL The TOE enforces the following rules to determine if an operation
among controlled subjects and controlled objects is allowed:
a) If the user is the owner of the object then the requested access is
allowed.
b) If the database session has the necessary object privileges
effective for the object then the requested access is allowed.
The object privileges relevant to different types of objects are
specified in [SQL, 18: GRANT (grant_object_privileges)], and
provide the ability to restrict a user’s access to an object to
those operations which do not modify the object..
2
The owner of an object is the owner of the schema containing the object, not necessarily the user who
created the object. More precisely, unique identification is by object type as well as object name within a
schema.
3
A reference to a database link (e.g. CONNECT /@otherdb or SELECT * FROM TBL@otherdb) will be
correctly resolved to the referenced database. A database object can be uniquely identified in a distributed
system, because it is uniquely identified in the database, and the database is unique in the system. The threat
is that failure to uniquely identify objects and user accounts could result in reading, creating, modifying or
destroying the wrong object (or copy of an object) if the user has the same access rights in each database.
Object Access Control
Discretionary Access Control
60 Security Target for Oracle Database 11g
Release 2 (11.2.0), Enterprise Edition
c) If the database session has the necessary system privileges
effective then the requested access is allowed. The system
privileges relevant to different types of database-wide and
schema-specific operations are specified in [SQL, 18: GRANT
(grant_system_privileges)] and provide the ability to restrict a
user’s use of operations to those operations which do not
modify objects.
d) To perform DML operations that are required to issue a DDL
statement the user must have all the privileges required as
directly granted privileges. Privileges received through a role
will not be evaluated in this case
e) If the user is connected AS SYSDBA (the database session has
the privilege to override the access controls) then the requested
access is allowed.
f) If the user is connected AS SYSOPER and the operation is one
of those specified in [DAG, 1: Database Administrator
Authentication (OSOPER and OSDBA)], for the OSOPER role
then the requested access is allowed.
F.DAC.OR Upon allocation of a resource to schema and non-schema objects,
any previous information is unavailable. In Oracle, there is no way
to access an object once it has been deleted, i.e. the resources have
been returned to the TOE. This is because any references to it no
longer exist and, even if they were recreated, they would never be
associated with the previous, non-existent object.
All objects have a unique ID. Even if a deleted object is recreated
using the same name, the object ID would be different.
Schema and non-schema objects are defined in [SQL, 3].
Oracle Database 11g has implemented a role concept that allows to
define new roles, assign privileges (including privileges to access
database objects) to a role and assign roles to users. This mechanism
allows to model the concept of a “group” where system privileges
and object privileges are assigned to a group and users inherit such
privileges when they become a member of the group. Therefore
“group access rights to database objects” as required by [BR-
DBMSPP] can be easily modelled in Oracle Database 11g using the
role model and assigning object privileges to roles. The privileges
assigned to roles are always defined in the local database, but an
Enterprise user may have global roles assigned to him, which are
stored and maintained in the directory. The privileges that a user
gets assigned via those roles are those that are associated with this
role in each local database.
F.APR.GOP A normal user (the grantor) can grant an object privilege to another
user, role or PUBLIC (the grantee) only if:
a) the grantor is the owner of the object; or
Privileges and Roles
Granting and Revoking
Privileges and Roles
Security Target for Oracle Database 11g 61
Release 2 (11.2.0.2), Enterprise Edition
b) the grantor has been granted that object privilege with the
GRANT OPTION.
F.APR.ROP A normal user (the revoker) can revoke an object privilege from
another user, role or PUBLIC (the revokee), and any further
propagation of that object privilege started by the revokee, only if
the revoker is the original grantor of the object privilege.
F.APR.GRSP A user (the grantor) can grant a system privilege to another user,
role or PUBLIC (the grantee), and revoke a system privilege from
the grantee, only if:
a) the grantor (or revoker) is connected AS SYSDBA; or
b) the database session of the grantor (or revoker) has the GRANT
ANY PRIVILEGE privilege effective; or
c) the grantor (or revoker) has been granted that system privilege
directly with the ADMIN OPTION.
F.APR.GRR A user (the grantor) can grant a role to another user, role or PUBLIC
(the grantee), and revoke a role from the grantee, only if:
a) the grantor is connected AS SYSDBA; or
b) the database session of the grantor (or revoker) has the GRANT
ANY ROLE privilege effective; or
c) the grantor (or revoker) has been granted that role with the
ADMIN OPTION.
To create a role a user must have the CREATE ROLE system
privilege.
Note that c) includes the case where the grantor is the user who created the role – see
[SG, 4: Granting the ADMIN OPTION], which states: “When a user creates a role,
the role is automatically granted to the creator with the ADMIN OPTION.”.
F.APR.DER A non-global role can be granted to a user in one of the following
ways:
a) As a default role, in which case the role will be enabled
automatically for each database session created by that user4
b) As a
.
non-default role
i. if the role is configured in the TOE as being identified
using a package, then that package must explicitly
enable the role during a database session in order for
any other roles within that role to be enabled and any
privileges within that role to become effective for that
user; or
, in which case
ii. if the role is configured in the TOE as being not
identified, then the user must explicitly enable the role
during a database session in order for any other roles
4
A default role is enabled at session creation bypassing any authorisation required for that role.
Enabling and Disabling Roles
62 Security Target for Oracle Database 11g
Release 2 (11.2.0), Enterprise Edition
within that role to be enabled and any privileges within
that role to become effective for that user.
iii. if the role is configured in the TOE as being identified
globally then the user can only be authorized to use the
role by an enterprise directory service. The role is
defined in the database by granting privileges and roles
to it, but the global role can not be granted itself to any
user or other role in the database. When a global user
attempts to connect to the database, the enterprise
directory is queried to obtain any global roles
associated with the user.
F.APR.EDR During a database session the user can control which roles are
effective at any time during the course of the database session by
enabling and disabling the roles which have been granted to that
user (where the role may have been granted directly to the user or
granted indirectly to the user through other roles5
a) The non-default roles granted to a user in a remote database
cannot be enabled while the user is connected to the remote
database.
), subject to the
following restrictions which apply to remote sessions:
b) The default roles granted to a user in a remote database cannot
be disabled while the user is connected to the remote database.
Note: the ‘set role’ command can not be implemented on a remote
database via a Database link. You cannot specify a role identified
globally. Global roles are enabled by default at login, and cannot be
re-enabled later.
F.PRI.SPRIV An object or system privilege will be effective in a user session
only if:
a) the privilege was granted to the user directly and has not been
revoked from the user; or
b) the privilege was granted indirectly via the PUBLIC user group
and has not been revoked from PUBLIC; or
c) the privilege was granted to the user indirectly via a role, and
has not been revoked from that role and the role is effective in
the current session.
F.PRI.XVP A suitably authorised user can provide other users with access to
proxy mechanisms (namely Views and Program Units) which will
act on behalf of the owning user (by executing with the directly
granted privileges of the owning user) to allow other users to have
controlled access to specified aggregations of data.
F.PRI.PRX A suitably authorised user can provide other users with the ability to
establish a proxy connection for another user. The authorized user
can control which user roles are available to the proxy session.
5
When a role that has been granted other roles is enabled all the indirectly granted roles are implicitly
enabled.
Effective Privileges
Security Target for Oracle Database 11g 63
Release 2 (11.2.0.2), Enterprise Edition
F.PRI.DEF When a new user is created, by default the new user’s objects are
stored in the database default tablespace. If no default tablespace is
assigned for the database, the user’s objects are stored in the
SYSTEM tablespace.
F.AUD.SOM When standard auditing is enabled (as DBMS or OS Auditing) for
an instance, the TOE will:
a) write an audit record for every occurrence of an auditable event
other than CONNECT and DISCONNECT; and
b) write an audit record for every pair of CONNECT/
DISCONNECT events.
F.AUD.SEV The TOE will allow a suitably authorised user to specify which
events for a database are auditable, as follows:
a) by use of DDL statements;
b) by use of DML statements;
i. for specified Object Privilege Objects;
ii. for all Object Privilege Objects subsequently created, by
default;
c) by use of system privileges;
d) by use of data access based on content;
e) for each event of type b) by session or by access, i.e. only one
audit record written for each auditable event that occurs in the
same session or one audit record written for each auditable
event. For events of type c) by session or by access, unless a
DDL statement when always by access;
f) for each event of type a), b) and c) by outcome, i.e. success,
failure, or both.
g) for each event of type a) and c);
i. for all users;
ii. for specified users;
iii. for specified proxies on behalf of any user;
iv. for specified proxies on behalf of specified users;
F.AUD.ALW Irrespective of the TOE's audit configuration, the TOE will audit
every successful occurrence of the following events to the operating
system:
a) start-up;
b) shut-down;
c) connection through the keywords AS SYSDBA or AS
SYSOPER.
Note that for the Solaris and Linux platforms OS auditable Oracle records are written
to standard text file audit logs in the OS.
Audit and
Accountability
64 Security Target for Oracle Database 11g
Release 2 (11.2.0), Enterprise Edition
F.AUD.CNF The TOE will allow only a suitably authorised user to set or alter the
audit configuration for a database. This includes also enabling or
disabling of the audit function in general.
Note that, by default (after installation), the TOE allows only SYS and SYSTEM (who
are granted the DBA role during installation) and users connected AS SYSDBA to set
and alter the audit configuration. It is possible for these users to grant the relevant
privileges to other users.
F.AUD.ACC The TOE will allow suitably authorised users to select by criteria
audit information from the database audit trail, as follows:
a) any suitably authorised user can view all audit records;
b) the owner of an object can view the audit records relating to
that object.
F.AUD.DEL The TOE will allow only a suitably authorized6
F.AUD.INF The TOE will record the following information into each Database
Audit Trail record, provided that the information is meaningful to
the particular audited event:
user to delete or
update audit records from the Database Audit Trail.
Date and time of event; username; instance number for the Oracle
instance where the user is accessing the database; session identifier;
terminal identifier of the user’s terminal; name of object accessed;
operation performed or attempted; outcome of the operation; system
privileges used.
In particular:
a) when a user attempts a connection to a database, whether
successful or not, at least the following information is recorded
when the TOE is configured to audit connection attempts: date
and time of event, username, instance number for the Oracle
instance where the user is accessing the database, session
identifier, terminal identifier of the user’s terminal, outcome of
the connection attempt;
b) when a user attempts to access any database object, whether
successful or not, at least the following information is recorded
when the TOE is configured to audit such access attempts: date
and time of event, username, name of object accessed,
operation performed or attempted, outcome of the operation;
c) when a user attempts to create or drop any database object,
whether successful or not, at least the following information is
recorded when the TOE is configured to audit such create or
drop actions: date and time of event, username, name of object
to be created or dropped, operation performed or attempted,
outcome of the operation;
6
By default, the TOE allows only SYS and SYSTEM (who are granted the DBA role during installation)
and users connected AS SYSDBA to delete or update rows from the database audit trail (which is held
in SYS.AUD$). It is possible for these users to grant the relevant privileges to other users, but it is assumed
that they will not do this in practice.
Security Target for Oracle Database 11g 65
Release 2 (11.2.0.2), Enterprise Edition
d) when a user attempts to affect the security of the TOE, by, for
example, starting up and shutting down an instance of the TOE,
creating new, modifying existing or dropping old user accounts,
tablespaces, databases, rollback segments, etc. as the TOE
permits at least the following information is recorded when the
TOE is configured to audit such actions: date and time of event,
username, name of object accessed, operation performed or
attempted, outcome of the operation.
F.AUD.VIEW Oracle provides both the SQL language and built-in views, based on
the underlying audit trail table, with the ability to both view and
search the audit data.
F.AUD.FULL With DBMS auditing, if the tablespace containing the audit trail
table becomes full, no further auditable actions can occur until space
is made available.
F.CON.DIC TSF data used by the database is stored in the database dictionary,
which is itself treated as a database object. The data dictionary is a
collection of database tables and views containing reference
information about the database, its structures, and its users. Oracle
accesses the data dictionary frequently during SQL statement
parsing. This access is essential to the continuing operation of
Oracle.
The data dictionary is accessed so often by Oracle that two special
locations in memory are designated to hold dictionary data. One
area is called the data dictionary cache, also known as the row cache
because it holds data as rows instead of buffers (which hold entire
blocks of data). The other area in memory to hold dictionary data is
the library cache. All Oracle user processes share these two caches
for access to data dictionary information.
When accessing data in the dictionary the Oracle database first
checks if the requested data is in the cache. If not, the cache
functions are used to load the data into the cache potentially
overwriting another block in the cache. The Oracle database
includes functions that will ensure that cache entries are marked
dirty when they are updated and will ensure that dirty cache entries
are written back to disk in due time (at least before they are
overwritten by another block retrieved from disk).
F.CON.RAC Note: this function is not available in Standard Edition One. Real
Application Clusters (RAC) use a cache-to-cache block transfer
mechanism known as Cache Fusion to transfer read-consistent
images of blocks from one instance to another. RAC does this using
high speed, low latency interconnects to satisfy remote requests for
data blocks. This ensures that all nodes will access the latest version
of a block of the database (including one from the dictionary) they
need to read or update. RAC includes protocols that tell other nodes
when it needs shared or exclusive access to a block, get this access
granted using a global locking mechanism, control that no other
node has any conflicting lock, write dirty blocks to disk, update the
Data Consistency
66 Security Target for Oracle Database 11g
Release 2 (11.2.0), Enterprise Edition
information about the block in other nodes and release any lock
granted.
Note: This Security Function applies only when the TOE is
configured with Real Application Clusters (RAC). In configurations
without RAC, data consistency in a clustered configuration is not
considered and consistency is achieved solely by the security
function F.CON.DIC.
Security Target for Oracle Database 11g 67
Release 2 (11.2.0.2), Enterprise Edition
Security Mechanisms and Techniques
When authentication is performed by Oracle Database 11g, a password is used for
authentication. The TOE performs a cryptographic hash function (using a modified
Data Encryption Standard (DES) algorithm) on passwords prior to storing them in the
database. The TOE password management functions (together called the PWD
mechanism) provide strong passwords for local users. This exceeds the DBMS PP
Strength of Function level of SOF-basic as required by [BR-DBMSPP]. Note that CC
version 3.1 no longer has a separate strength of function analysis but this aspect still
needs to be considered as part of the vulnerability analysis.
In the case of en enterprise user, the password is managed in the directory server and
stored there in the same way as the password for local users is stored in the database
dictionary. The directory server allows to define a password policy ensuring that the
passwords are strong.
Assurance Measures
The target assurance level is EAL4 augmented with ALC_FLR.3, which exceeds the
assurance requirements stated in [BR-DBMSPP]. No other specific assurance
measures are claimed. The following table identifies the Oracle Database 11g
documentation that supports each security assurance requirement for EAL4 and also
the assurance requirement for ALC_FLR.3.
Table 9: TOE Security Assurance Requirements
Component Name Documents
ALC_CMC.4
Production support,
acceptanceprocedures
and automation
[CM]
ALC_CMS.4
ProblemtrackingCM
coverage [CM]
ALC_DEL. 1 Delivery procedures [OQM]
ALC_DVS. 1 Identification of security
measures
[SODE]
ALC_FLR.3
Systematicflaw
remediation [FLR]
ALC_LCD. 1 Developer defined life-
cycle model
[LCS]
ALC_TAT. 1
Well-defined
development tools [CM]
AGD_OPE.1
Operational user
guidance [ECD] [GA]
AGD_PRE.1 Preparative procedures [ICG] [ECD] [GA]
TOE Security Assurance
Requirements
68 Security Target for Oracle Database 11g
Release 2 (11.2.0), Enterprise Edition
Component Name Documents
ADV_ARC.1
Security architecture
description [AD]
ADV_FSP.4
Complete functional
specification [ERR] [OCI]
ADV_TDS.3 Basic modular design [AD]
ADV_IMP.1
Implementation
representation of the
TSF
[SRC]
ATE_COV.2 Analysis of coverage [TP]
ATE_DPT.2 Testing: security
enforcing modules
[TP]
ATE_FUN.1 Functional testing [TP]
ATE_IND.2 Independent testing -
sample
[TP]
AVA_VAN.3 Focused vulnerability
analysis
[VA]
TOE Summary Specification Rationale
This section demonstrates that the TOE Security Functions and Assurance Measures
are suitable to meet the TOE security requirements.
Table 8 of chapter 6 identifies the Oracle Database 11g TOE Security Functions that
address each of the SFRs in chapter 5.
The table below demonstrates that for each SFR the TOE security functions are
suitable to meet the SFR, and the combination of TOE security functions work
together so as to satisfy the SFR:
Table 10: TOE Security Function Suitability and Binding
SFR
TOE Security
Functions
Rationale
FIA_AFL.1.1 F.IA.PWD
The number of allowed failed logon attempts for local
users can be configured.
FIA_AFL.1.2 F.IA.PWD
When the configured number of failed logon attempts is
reached the account is locked.
FIA_ATD.1.1
F.IA.ATT
F.IA.ATT-EU
The data dictionary stores the required security attributes.
In the case of Enterprise Users the security attributes are
stored in the directory server.
FIA_SOS.1.1
F.IA.PWD
F.LIM.CNF
F.IA.USE
F.IA.PWD specifies the controls available on database
secrets (passwords) for local users. These controls are
implemented via profiles which are required by
F.LIM.CNF. F.IA.USE allows local users to change their
TOE Security Functions
Satisfy Requirements
Security Target for Oracle Database 11g 69
Release 2 (11.2.0.2), Enterprise Edition
SFR
TOE Security
Functions
Rationale
own passwords within the limits configured by an
administrator. In the case of Enterprise Users the password
policy is stored and enforced by the directory server.
FIA_UAU.1.1 F.IA.PRE
F.IA.PRE maps onto FIA_UAU.1.1 and FIA_UID.1.2
directly.
FIA_UAU.1.2
F.IA.PRE
F.IA.DBA
F.IA.CSA
F.IA.CSN
F.IA.EUA
F.IA.CSN and F.IA.CSA state the conditions for being
able to establish a database session and hence perform
TSF-mediated actions. These security functions depend
directly on F.IA.DBA. F.IA.PRE is relevant because one
of the actions allowed prior to session creation is
attempting to establish a session. In the case of
Enter¬prise Users the authentication is supported by the
exter¬nal directory server as described in F.IA.EUA.
FIA_UID.1.1 F.IA.PRE
F.IA.PRE satisfies FIA_UAU.1.1 and FIA_UID.1.1
directly.
FIA_UID.1.2
F.IA.PRE
F.IA.UID
F.IA.DBA
F.IA.IDE
F.IA.CSA
F.IA.CSN
F.IA.EUA
F.IA.CSN and F.IA.CSA state the conditions for being
able to establish a database session and hence perform
TSF-mediated actions. These security functions depend
directly on F.IA.DBA. F.IA.PRE is relevant one of the
actions allowed prior to session creation is attempting to
establish a session. F.IA.IDE ensures that the identity of
the user is known for the duration of the session, once
created.
In the case of Enterprise Users the user identification is
supported by the external directory server as described in
F.IA.EUA.
FIA_USB.1.1
F.IA.ATT
F.IA.ATT-EU
F.IA.ATT and F.IA.ATT-EU cover the security attributes
for each user.
FIA_USB.1.2
F.IA.DBA
F.IA.IDE
F.PRI.SPRIV
F.PRI.PRX
F.IA.EUA
F.IA.DBA covers user identification, and the authentica-
tion of the user by a password when starting a database
session. F.IA.IDE ensures that the TSF is able to establish
the identity of the user during a database session.
F.PRI.PRX defines the rules governing privileges in proxy
user sessions, whilst F.PRI.SPRIV defines rules for which
privileges are effective when starting a session.
In the case of Enterprise Users, some of the user security
attributes are stored in the external directory server and
transferred to the TOE such that the TOE can assign the
correct user security attributes to the subject that is bound
to the user. This is described in F.IA.EUA.
FIA_USB.1.3
F.IA.USE
F.APR.EDR
F.PRI. SPRIV
F.PRI.XVP
F.PRI.SPRIV governs the effect of changing privileges
during a session. F.APR.EDR defines which roles are
effective at any time during the course of the database
session. F.PRI.XVP governs which privileges are effective
when executing a view or program owned by another user.
F.IA.USE governs when a user is authorised to make
changes to a password associated with that user .
FDP_ACC. 1.1
F.DAC.OBID
F.DAC.OBREF
F.DAC.SUA
F.DAC.OBA
F.DAC.OBID and F.DAC.OBREF ensure that all objects
(which are subject to DAC) can be uniquely identified.
F.DAC.SUA and F.DAC.OBA state that the DAC policy
extends to all subjects and objects.
FDP_ACF. 1.1-
NIAP-0407
F.DAC.OBID
F.DAC.OBREF
F.DAC.SUA
F.DAC.OBA
F.DAC.POL
F.PRI.SPRIV
F.DAC.OBID and F.DAC.OBREF ensure that all objects
(which are subject to DAC) can be uniquely identified.
F.DAC.SUA includes the subject and their enabled privi-
leges (as specified in F.PRI.SPRIV) in the DAC policy.
F.DAC.OBA states that the object and any associated
object privileges are considered by the DAC policy.
F.DAC.POL is a statement of the DAC policy.
70 Security Target for Oracle Database 11g
Release 2 (11.2.0), Enterprise Edition
SFR
TOE Security
Functions
Rationale
FDP_ACF. 1.2-
NIAP-0407
F.IA.CNF
F.DAC.OBID
F.DAC.OBREF
F.DAC.POL
F.PRI.SPRIV
F.AUD.CNF
F.DAC.POL a) and b) specifies access to objects based on
ownership or object privileges. F.DAC.OBID and
F.DAC.OBREF are relevant as they define object owner-
ship which is the basis of the DAC policy. FPRI.SPRIV is
relevant as it defines which privileges are enabled for any
user. F.IA.CNF and F.AUD.CNF are relevant I&A data
and the audit trail are subject to the DAC policy.
FDP_ACF.1.3-
NIAP-0407
F.DAC.POL
F.PRI.SPRIV
F.AUD.CNF
F.DAC.POL c) specifies access to objects based on ena-
bled system privileges. F.DAC.POL d) and e) cover access
via connections AS SYSDBA and AS SYSOPER.
F.PRI.SPRIV is relevant as it defines which privileges are
enabled for any user. F.AUD.CNF is relevant as the audit
trail is subject to the DAC policy
FDP_ACF.1.4-
NIAP-0407
N/A
This SFR does not mandate any functionality. It is
included for compliance with the CC.
FDP_RIP.1.1 F.DAC.OR F.DAC.OR satisfies FDP _RIP.1.1 directly.
FMT_MOF.1.1 F.AUD.CNF F.AUD.CNF restricts all functions related to the
FMT_MSA.1.1
F.APR.GOP
F.APR.ROP
F.APR.GRSP
F.APR.GRR
F.APR.GOP and F.APR.ROP cover FMT _MSA.1.1 a)
which is concerned with modifying object privileges.
F.APR.GRSP covers FMT_MSA.1.1 b) which is con-
cerned with modifying system privileges. F.APR.GRR
covers FMT _MSA.1.1 c) which is concerned with modi-
fying roles.
FMT_MSA_
(EXT).3.1
F.DAC.POL
F.PRI.SPRIV
F.PRI.DEF
F.DAC.POL and F.PRI.SPRIV implicitly include restric-
tive default values. If a user has not been explicitly
granted the necessary privilege or a role containing the
required privilege then the requested action will not suc-
ceed. F.PRI.DEF defines the default rights for new users,
which are the most restrictive rights that just allow to use
the DBMS.
FMT_MTD.1.1
(1)
F.AUD.SEV
F.AUD.SEV covers the requirement to restrict the ability
to select the events to be audited to an authorized admin-
istrator.
FMT_MTD.1.1
(2)
F.IA.ATT
F.IA.ATT-EU
F.LIM.CNF
F.APR.GOP
F.APR.ROP
F.APR.GRSP
F.APR.GRR
F.AUD.ACC
F.AUD.DEL
These TOE security functions are concerned with the
modification of TSF data (security attributes and audit
data). This data is stored in the data dictionary and is pro-
tected from unauthorised access by the same mechanism
as all other data in the database. F.IA.ATT and
F.LIM.CNF cover identification and authentication data
and resource limit attributes. F.APR.* cover privilege and
role TSF data. F.AUD.* cover audit data.
Note that security attributes of enterprise users may be
stored and managed external to the TOE in the directory
FMT_REV.1.1
(1)
F.LIM.CNF
F.APR.GRSP
F.APR.GRR
Only suitably privileged users can revoke (or modify) the
following attributes: resource limits (F.LIM.CNF), system
privileges (F.APR.GRSP) and roles (F.APR.GRR).
FMT_REV.1.2
(1)
F.PRI.SPRIV
Directly granted privileges and roles are revoked imme-
diately. This is more rigorous than SFR FMT_REV.1.2.
Revocation of roles takes effect when a role is re-enabled
in the current session or a new user session is created.
FMT_REV. 1.1
(2)
F.APR.ROP
Only suitably privileged users can revoke (or modify) the
object privileges (F.APR.ROP),
FMT_REV.1.2
(2)
F.PRI.SPRIV
Directly granted privileges are revoked immediately. This
is more rigorous than SFR FMT_REV.1.2.
FMT_SMF.1.1 F.IA.ATT
F.IA.ATT-EU
These TOE security functions are concerned with the
management functions provided by the TOE. These
Security Target for Oracle Database 11g 71
Release 2 (11.2.0.2), Enterprise Edition
SFR
TOE Security
Functions
Rationale
F.LIM.CNF
F.APR.GOP
F.APR.ROP
F.APR.GRSP
F.APR.GRR
F.AUD.ACC
F.AUD.DEL
functions relate to TSF data (security attributes and audit
data). This data is stored in the data dictionary and is pro-
tected from unauthorised access by the same mechanism
as all other data in the database. F.IA.ATT and
F.LIM.CNF cover identification and authentication data
and resource limit attributes. F.APR.* cover privilege and
role TSF data. F.AUD.* cover audit data.
Note that security attributes of enterprise users may be
stored and managed external to the TOE in the directory
FMT_SMR.1.1
F.IA.UID F.IA.CSA
F.IA.CSN
F.APR.GRR
F.IA.UID, F.IA.CSA and F.IA.CSN in combination ensure
that the TSF maintains normal database users and database
administrative users. F.APR.GRR covers database roles
defined by a suitably authorised user.
FMT_SMR.1.2
F.IA.CSA
F.APR.DER
F.APR.EDR
F.PRI.PRX
F.APR.DER and F.APR.EDR cover granting database
roles to database users. F.IA.CSA is relevant because it
specifies how to allow a user to connect AS SYSDBA or
AS SYSOPER. F.PRI.PRX covers database roles available
to a proxy user session.
FPT_TRC_
(E XT).1.1
F. CON.DIC
F.CON.RAC
F.CON.DIC ensures consistency when multiple users
simultaneously query and update an item in the dictionary.
A locking concept ensures that no conflicting updates can
be made. Modified dictionary entries are written back to
disk as fast as possible using the mechanism provided by
the caching function. F. CON.RAC ensures that data is
consistent when the Real Application Clusters function is
used. Note that the Real Application Clusters functionality
is not available in Standard Edition One.
FRU_RSA.1.1
F.LIM.CNF
F.LIM.POL
F.LIM.NSESS
F.LIM.TIME
F.LIM.RSESS
F.LIM.RCALL
F.LIM.CNF covers configuration of the resource quotas.
F.LIM.POL, F.LIM.NSESS, F.LIM.TIME,
F.LIM.RSESS and F.LIM.RCALL enforces the resource
quotas configured.
FTA_MCS.1.1 F.LIM.NSESS F.LIM.NSESS directly satisfies FTA_MCS.1.2
FTA_MCS.1.2
F.LIM.NSESS
F.LIM.POL
As with FTA_MCS.1.1 except that F.LIM.POL ensures
that the default number of concurrent sessions allowed is
enforced if a user specific configuration has not been
specified.
FTA_TAH_
(E XT).1.1
F.IA.CSN
F.IA.CSA
F.IA.CSN is the function that creates a session as a nor-
mal user. A LOGON trigger can be used to store and
manage the date and time of login and retrieve the date
and time of the last successful login. For a SYS user,
F.IA.CSA (with a LOGON trigger) can perform the same
function.
FTA_TAH_
(E XT).1.2
F.IA.CSN
F.IA.CSA
F.IA.CSN is the function that creates a session as a nor-
mal user. A LOGON trigger can be used to record the
number of unsuccessful login attempts since the last suc-
cessful login. For a SYS user, F.IA.CSA (with a LOGON
trigger) can perform the same function.
FTA_TSE.1.1
F.IA.CSN
F.IA.CSA
F.IA.CSN and F.IA.CSA define the pre-requisites for
session establishment, including possession of the CRE-
ATE SESSION privilege and being identified as SYS-
DBA/SYSOPER, respectively. These are configured on
the basis of individual user identity. Therefore, it is pos-
sible to deny access based on user identity.
FAU_GEN.1.1 -
NIAP-0410
F.AUD.SOM
F.AUD.SEV
The database audit functionality is always active. Whether
or not auditing is actually performed is dependent on the
72 Security Target for Oracle Database 11g
Release 2 (11.2.0), Enterprise Edition
SFR
TOE Security
Functions
Rationale
F.AUD.ALW configuration of a parameter in the init.ora file which is
controlled by the OS. F.AUD.SOM,
F.AUD.SEV and F.AUD.ALW ensure all actions config-
ured to be audited are audited.
FAU_GEN.1.2 -
NIAP-0410
F.AUD.INF F.AUD.INF directly satisfies FAU_GEN.1.2-NIAP0410
FAU_GEN_
E XP.2.1
F.AUD.INF F.AUD.INF directly satisfies FAU_GEN_EXP.2. 1
FAU_SAR.1.1 F.AUD.ACC F.AUD.ACC directly satisfies FAU_SAR.1.1
FAU_SAR.1.2 F.AUD.VIEW F.AUD.VIEW directly satisfies FAU_SAR.1.2
FAU_SAR.3.1
F.AUD.VIEW
F.AUD.ACC
F.AUD.VIEW satisfies FAU_SAR.3.1. Additionally
F.AUD.ACC determines which records are available to
the user for selection.
FAU_SEL.1.1-
NIAP-0407
F.AUD.SOM
F.AUD.SEV
F.AUD.ALW
F.AUD.CNF
F.AUD.SEV and F.AUD.CNF allow a suitably privileged
user to configure exactly which events should be audited.
F.AUD.SOM and F.AUD.ALW specify events that are
always audited. Note that for audit records database
subjects are always the database users, so that for example
an audit record generated by a stored procedure will be
generated with the username of the invoker, not that of the
procedure or the procedure owner.
FAU_STG.1.1 F.AUD.DEL F.AUD.DEL directly satisfies FAU_STG.1.1.
FAU_STG.1 .2 F.AUD.DEL
F.AUD.DEL protects audit records from unauthorised
modification or deletion.
FAU_STG.4.1 F.AUD.FULL F.AUD.FULL directly satisfies FAU_STG.4.1
Security Target for Oracle Database 11g 73
Release 2 (11.2.0.2), Enterprise Edition
ANNEX
A References
[AD] Architecture for Oracle Database 11g Release 2 (11.2.0),
Oracle Corporation
[BR-DBMSPP] U.S. Government Protection Profile for Database Management Systems in Basic
Robustness Environments, Version 1.3, December 24, 2010,
Information Assurance Directorate, National Security Agency
[CAPP] Controlled Access Protection Profile, Version 1.d, 8 October 1999,
Information Assurance Directorate, National Security Agency
[CC] Common Criteria for Information Technology Security Evaluation,
Version 3.1 Release 3.
[CCEVS-VR-07-0054] Common Criteria Evaluation and Validation Scheme Validation Report,
Red Hat Enterprise Linux, Version 5, NIAP-CCEVS
[CCEVS-VR-VID10271] Common Criteria Evaluation and Validation Scheme Validation Report,
SUSE LINUX Enterprise Server, Version 10 Service Pack 1, NIAP-CCEVS
[CM] Oracle Database Configuration Management Plan, 11g Release 2 (11.2.0),
Oracle Corporation.
[CON] Oracle Database Concepts, 11g Release 2 (11.2),
Oracle Corporation.
[DAG] Oracle Database Administrator’s Guide, 11g Release 2 (11.2),
Oracle Corporation.
[DD] Detailed Design for Oracle Database 11g Release 2 (11.2.0),
Oracle Corporation.
[DPP] Database Management System Protection Profile (DBMS PP), Issue 2.1,
Oracle Corporation, May 2000.
[DT] Design Traceability for Oracle Database 11g Release 2 (11.2.0),
Oracle Corporation.
74 Security Target for Oracle Database 11g
Release 2 (11.2.0), Enterprise Edition
[DSZ0481] Certification Report BSI-DSZ-CC-0481-2008, for Oracle Enterprise Linux,
Version 5 Update 1, October 2008. Available from
http://www.bsi.bund.de/zertifiz/zert/reporte/0481a.pdf.
[ECD] Evaluated Configuration Document for Oracle Database 11g Release 2 (11.2.0),
Oracle Corporation.
[ERR] Oracle Database Error Messages, 11g Release 2 (11.2),
Oracle Corporation.
[EUA] Enterprise User Security Administrator’s Guide, 11g Release 2 (11.2),
Oracle Corporation.
[FIPS46-3] Federal Information Processing Standard Publication 46-3,
National Institute of Standards and Technology (NIST), October 1999.
[FIPS81] Federal Information Processing Standard Publication 81,
National Institute of Standards and Technology (NIST), December 1980.
[FLR] Oracle Flaw Remediation Procedures,
Oracle Corporation.
[GA] Guidance Analysis for Oracle Database, 11g Release 2 (11.2.0),
Oracle Corporation.
[ICG] Oracle Database Installation Guide, 11g Release 2 (11.2) for Linux,
Oracle Corporation.
[ITSEC] Information Technology Security Evaluation Criteria, Issue 1.2,
Commission of the European Communities, 28 June 1991.
[LCS] Life Cycle Support for Oracle Database 11g, Release 2 (11.2.0),
Oracle Corporation.
[MEMO 1] CESG Computer Security Memorandum No. 1 - Glossary of Computer Security
Terms, Issue 2.0, November 1989.
[OCI] Oracle Database Call Interface Programmers Guide, 11g Release 2 (11.2),
Oracle Corporation.
[OQM] Quality Manual for Manufacturing & Distribution,
Oracle Corporation.
[PLS] PL/SQL Language Reference, 11g Release 2 (11.2),
Oracle Corporation.
[SG] Oracle Database Security Guide, 11g Release 2 (11.2),
Oracle Corporation.
[SODE] Security of the Oracle Development Environment,
Oracle Corporation.
[SQL] Oracle Database SQL Language Reference, 11g Release 2 (11.2),
Oracle Corporation.
[SQL92] Database Language SQL, ISO/IEC 9075:1992 and ANSI X3.135-1992
Security Target for Oracle Database 11g 75
Release 2 (11.2.0.2), Enterprise Edition
[SRC] Oracle Database Source Code 11g, Release 2 (11.2.0),
Oracle Corporation.
[SRF] Oracle Database Reference, 11g Release 2 (11.2),
Oracle Corporation.
[ST11gR1-EE] Security Target for Oracle 11g, Release 1 (11.1.0), Enterprise Edition,
Oracle Corporation.
[TCSEC] Trusted Computer Security Evaluation Criteria, Department of Defense,
United States of America, DoD 5200.28-STD, December 1985.
[TP] Test Plan, Procedures, Results, and Analysis for Oracle Database 11g Release 2
(11.2.0), Oracle Corporation.
76 Security Target for Oracle Database 11g
Release 2 (11.2.0), Enterprise Edition
ANNEX
B Glossary
Acronyms
DAC Discretionary Access Control
DDL Data Definition Language
DES Data Encryption Standard
DML Data Manipulation Language
O-RDBMS Object-Relational Database Management System
RAC Real Application Clusters
SF Security Function
SFP Security Function Policy
SFR Security Functional Requirement
SOF Strength of Function
SQL Structured Query Language
TOE Target Of Evaluation
TSC TOE Scope of Control
TSF TOE Security Functions
TSFI TSF Interface
TSP TOE Security Policy
Security Target for Oracle Database 11g 77
Release 2 (11.2.0.2), Enterprise Edition
Terms
Authorised administrative
user
Another name for a Database Administrative User.
Data Definition Language
(DDL)
The SQL statements used to define the schema and schema objects in a database
[SQL]
Data dictionary A set of internal Oracle tables that contain information about the logical and physical
structure of the database. [SCN]
Data Encryption Standard
(DES)
A standard for encryption, FIPS PUB 46-3 and FIPS PUB 81. [FIPS46-3],[FIPS81]
Data Manipulation
Language (DML)
The SQL statements used to query and manipulate data in schema objects [SQL]
Data server A component of a DBMS that supports concurrent access to a database by multiple
users, possibly at different nodes in a distributed environment. [ST]
Database A collection of data that is treated as a unit; the general purpose of a database is to
store and retrieve related information [SCN]
Database administrative
user
A database user to whom one or more administrative privileges have been granted.
[DPP].
This includes users connected AS SYSOPER or AS SYSDBA as well as Normal
Users who are authorised to perform an administrative task via the posession of an
administrative privilege which permits the operation of the task.
Database connection A communication pathway between a user and a DBMS. [DPP]
Database link A definition of a one-way communication path from an Oracle database to another
database. [SCN]
Database non-
administrative user
A database user who only has privileges to perform operations in accordance with the
TSP. [DPP]
Database object An object contained within a database. [DPP]
Database session A connection of an identified and authenticated user to a specific database; the
session lasts from the time the user connects (and is identified and authenticated) until
the time the user disconnects. [DPP]
Database subject A subject that causes database operations to be performed. [DPP]
Database user A user who interacts with a DBMS and performs operations on objects stored within
the database. [DPP]
Discretionary Access
Control
Access control based on access rights granted by users other than the System Security
Officer. [MEMO 1]
Enterprise User A user managed centrally in a directory server. For those users the userid and
78 Security Target for Oracle Database 11g
Release 2 (11.2.0), Enterprise Edition
password, global user roles and privileges, and the password policy are centrally
managed.
Instance The combination of a set of Oracle background processes and memory that is shared
among the processes. A database instance must be started (the shared memory
allocated and the background processes created) by an authorised administrative user
before the database managed by the instance can be accessed. [SCN]
Interface product A TOE component that resides in a user process and can be used to communicate
with an Oracle database server in a secure manner. [ST]
Normal User A database user who has made a normal connection to the database. This can include
the users SYS and SYSTEM but excludes users connected AS SYSOPER or AS
SYSDBA.
Object An entity within the TSC that contains or receives information and upon which
subjects perform operations. Objects are visible through the TSFI and are composed
of one or more TOE resources encapsulated with security attributes. [CC]
Object-Relational
Database Management
System (ORDBMS)
A DBMS that supports object-oriented technology as well as relational databases.
[SCN]
Owner The owner of a named database object is the database user who is responsible for the
object and may grant other database users access to the object on a discretionary
basis. [DPP]
Platform The combination of software and hardware underlying the DBMS. [ST]
Privilege A right to access objects and/or perform operations that can be granted to some users
and not to others. [DPP]
Privilege, database
administrative
A privilege authorising a subject to perform operations that may bypass, alter, or
indirectly affect the enforcement of the TSP. [DPP]
Privilege, database object
access
A privilege authorising a subject to access a named database object. [DPP]
Privilege, directly granted An Oracle system or object privilege that has been explicitly granted to a user.
Privileges granted to any roles the user has been granted are not included in the set of
directly granted privileges. [SCN]
Privilege, object An Oracle privilege that allows users to perform a particular action on a specific
schema object. Oracle object privileges are database object access privileges. [SCN]
Privilege, system An Oracle privilege that allows users to perform a particular system-wide action or a
particular action on a particular type of object. Some Oracle system privileges are
database administrative privileges. [SCN]
Program unit A PL/SQL program; a procedure, function, or package. [PLS]
Role (CC) A predefined set of rules establishing the allowed interactions between a user and the
TOE. [CC]
Role (Oracle) A named group of related system and/or object privileges that can be granted to users
or to other roles. [SCN]
Security Target for Oracle Database 11g 79
Release 2 (11.2.0.2), Enterprise Edition
Schema A collection of logical structures of data (schema objects), owned by a specific
database user. [SQL]
Security attribute Information associated with subjects, users, and/or objects which is used for the
enforcement of the TSP. [CC]
Security domain The set of objects that a subject has the ability to access. [TCSEC]
Security Function (SF) A part or parts of the TOE which have to be relied upon for enforcing a closely
related subset of the rules from the TSP. [CC]
Security Function Policy
(SFP)
The security policy enforced by a SF. [CC]
Security Functional
Requirement (SFR)
A security functional requirement defined in a protection profile or security target.
[CC]
Server process An Oracle process that services requests for access to an Oracle database from
connected user processes. [SCN]
SQL statement A string of SQL text containing a command and supporting clauses. All access to an
Oracle database is via SQL statements. [SCN]
Structured Query
Language (SQL)
A standardised database access language; Oracle8 SQL is a superset of the ANSI/ISO
SQL92 standard at entry level conformance. [SQL]
Subject An entity within the TSC that causes operations to be performed. [CC]
Suitably authorised user A user who is authorised to perform an administrative task via the posession of an
administrative privilege which permits the operation of the task. This includes users
connected AS SYSOPER or AS SYSDBA as well as privileged Normal Users.
System A specific IT installation, with a particular purpose and operational environment [CC]
Target Of Evaluation (TOE) The product or system being evaluated. [CC]
TOE resource Anything usable or consumable in the TOE. [CC]
TOE Scope of Control
(TSC)
The set of interactions which can occur with or within a TOE and are subject to the
rules of the TSP. [CC]
TOE Security Functions
(TSF)
A set consisting of all the software of the TOE that must be relied on for the correct
enforcement of the TSP. [CC]
TOE Security Policy (TSP) A set of rules that regulate how assets are managed, protected and distributed within a
TOE. [CC]
TSF Interface (TSFI) A set of interfaces, whether interactive (man-machine interface) or programmatic
(application programming interface), through which TOE resources are accessed,
mediated by the TSF, or information is obtained from the TSF. [CC]
User Any entity (human or machine) outside the TOE that interacts with the TOE. [CC]
User process A process that requests services, on behalf of a user or application, from an Oracle
server process. [SCN]
80 Security Target for Oracle Database 11g
Release 2 (11.2.0), Enterprise Edition