Oracle Database 12c

Enterprise Edition
Security Target
Evaluation Assurance Level (EAL): EAL2+

Doc No: 1932-000-D102

Version: 1.2
6 March 2017

Oracle Corporation
5000 Oracle Parkway
Redwood Shores, California
94065

Prepared by:
EWA-Canada
1223 Michael Street
Ottawa, Ontario, Canada
K1J7T2
 Oracle Database 12c Enterprise Edition
Security Target

CONTENTS
1 SECURITY TARGET INTRODUCTION ............................................. 1
1.1 DOCUMENT ORGANIZATION............................................................. 1
1.2 SECURITY TARGET REFERENCE ........................................................ 1
1.3 TOE REFERENCE ............................................................................. 1
1.4 TOE OVERVIEW .............................................................................. 2
1.5 TOE DESCRIPTION .......................................................................... 2
1.5.1 Physical Scope ............................................................................... 2
1.5.2 TOE Environment ........................................................................... 4
1.5.3 TOE Guidance ................................................................................ 4
1.5.4 Logical Scope................................................................................. 4
1.5.5 Functionality Excluded from the Evaluated Configuration ..................... 5

2 CONFORMANCE CLAIMS ............................................................... 7

2.1 COMMON CRITERIA CONFORMANCE CLAIM ........................................ 7
2.2 ASSURANCE PACKAGE CLAIM........................................................... 7
2.3 PROTECTION PROFILE CONFORMANCE CLAIM .................................... 7

3 SECURITY PROBLEM DEFINITION ................................................ 8

3.1 THREATS ....................................................................................... 8
3.2 ORGANIZATIONAL SECURITY POLICIES ............................................. 9
3.3 ASSUMPTIONS ............................................................................... 9

4 SECURITY OBJECTIVES .............................................................. 11

4.1 SECURITY OBJECTIVES FOR THE TOE.............................................. 11
4.2 SECURITY OBJECTIVES FOR THE OPERATIONAL ENVIRONMENT ......... 12
4.2.1 Operational Environment Security Objectives ................................... 12
4.2.2 Operational Environment IT Domain Security Objectives ................... 13
4.3 SECURITY OBJECTIVES RATIONALE ................................................ 14
4.3.1 Security Objectives Rationale Related to Threats .............................. 15
4.3.2 Security Objectives Rationale Related to OSPs ................................. 23
4.3.3 Security Objectives Rationale Related to Assumptions ....................... 27

5 EXTENDED COMPONENTS DEFINITION ...................................... 34

5.1 FIA_USB USER-SUBJECT BINDING .................................................. 34
5.2 FTA_TAH TOE ACCESS HISTORY ..................................................... 35

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page i of iii
 Oracle Database 12c Enterprise Edition
Security Target

5.3 SECURITY ASSURANCE REQUIREMENTS .......................................... 36

6 SECURITY REQUIREMENTS ........................................................ 37

6.1 CONVENTIONS ............................................................................. 37
6.2 TOE SECURITY FUNCTIONAL REQUIREMENTS................................... 37
6.2.1 Security Audit (FAU) ..................................................................... 38
6.2.2 User Data Protection (FDP) ............................................................ 41
6.2.3 Identification and Authentication (FIA) ............................................ 42
6.2.4 Security Management (FMT) .......................................................... 43
6.2.5 Protection of the TSF (FPT) ............................................................ 45
6.2.6 TOE Access (FTA) ......................................................................... 45
6.3 SECURITY FUNCTIONAL REQUIREMENTS RATIONALE ........................ 47
6.3.1 SFR Rationale Related to Security Objectives ................................... 48
6.4 DEPENDENCY RATIONALE .............................................................. 53
6.5 TOE SECURITY ASSURANCE REQUIREMENTS ................................... 54
6.5.1 Security Assurance Requirements Rationale..................................... 54

7 TOE SUMMARY SPECIFICATION ................................................. 57

7.1 TOE SECURITY FUNCTIONS............................................................ 57
7.1.1 Security Audit .............................................................................. 57
7.1.2 User Data Protection ..................................................................... 58
7.1.3 Identification and Authentication .................................................... 59
7.1.4 Security Management ................................................................... 60
7.1.5 Protection of the TSF .................................................................... 61
7.1.6 TOE Access .................................................................................. 61

8 TERMINOLOGY AND ACRONYMS ................................................ 63

8.1 TERMINOLOGY ............................................................................. 63
8.2 ACRONYMS .................................................................................. 66

LIST OF TABLES
Table 1 – Operational Environment Operating System and Hardware
Requirements ...................................................................................... 4
Table 2 – Logical Scope of the TOE .............................................................. 5
Table 3 – Threats ...................................................................................... 9

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page ii of iii
 Oracle Database 12c Enterprise Edition
Security Target

Table 4 – Organizational Security Policies ..................................................... 9

Table 5 – Assumptions ............................................................................. 10
Table 6 – Security Objectives for the TOE ................................................... 12
Table 7 – Operational Environment Security Objectives ................................ 13
Table 8 – Operational Environment IT Security Objectives ............................ 13
Table 9 – Mapping Between Objectives, Threats, OSPs, and Assumptions ....... 14
Table 10 – Summary of Security Functional Requirements ............................ 38
Table 11 – Auditable Events ...................................................................... 40
Table 12 – Mapping of SFRs to Security Objectives ...................................... 48
Table 13 – Functional Requirement Dependencies ....................................... 54
Table 14 – Security Assurance Requirements .............................................. 56
Table 15 – Terminology ............................................................................ 66
Table 16 – Acronyms ............................................................................... 66

LIST OF FIGURES
Figure 1 – Oracle Database 12c Diagram ...................................................... 3
Figure 2 – FIA_USB_(EXT): User-subject binding Component Levelling .......... 34
Figure 3 – FTA_TAH_(EXT): TOE Access History Component Levelling ............ 36

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page iii of iii
 Oracle Database 12c Enterprise Edition
Security Target

1 SECURITY TARGET INTRODUCTION

This Security Target (ST) defines the scope of the evaluation in terms of the
assumptions made, the intended environment for the TOE, the Information
Technology (IT) security functional and assurance requirements to be met, and
the level of confidence (evaluation assurance level) to which it is asserted that
the TOE satisfies its IT security requirements. This document forms the baseline
for the Common Criteria (CC) evaluation.

1.1 DOCUMENT ORGANIZATION

Section 1, ST Introduction, provides the Security Target (ST) reference, the
Target of Evaluation (TOE) reference, the TOE overview and the TOE description.
Section 2, Conformance Claims, describes how the ST conforms to the
Common Criteria, Protection Profile, and Assurance Packages.
Section 3, Security Problem Definition, describes the expected environment
in which the TOE is to be used. This section defines the set of threats that are
relevant to the secure operation of the TOE, organizational security policies with
which the TOE must comply, and secure usage assumptions applicable to this
analysis.
Section 4, Security Objectives, defines the set of security objectives to be
satisfied by the TOE and by the TOE operating environment in response to the
problem defined by the security problem definition.
Section 5, Extended Components Definition, defines the extended
components which are then detailed in Section 6.
Section 6, Security Requirements, specifies the security functional and
assurance requirements that must be satisfied by the TOE and the Information
Technology (IT) environment.
Section 7, TOE Summary Specification, describes the security functions and
assurance measures that are included in the TOE to enable it to meet the IT
security functional and assurance requirements.
Section 8 Terminology and Acronyms, defines the acronyms and
terminology used in this ST.

1.2 SECURITY TARGET REFERENCE

ST Title: Oracle Database 12c Enterprise Edition Security Target

ST Version: 1.2

ST Date: 6 March 2017

1.3 TOE REFERENCE

TOE Identification: Oracle Database 12c (12.1.0.2) Enterprise Edition with

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 1 of 66

 Oracle Database 12c Enterprise Edition
Security Target

Critical Patch Update (CPU) January 2017

TOE Developer: Oracle Corporation

TOE Type: Database Management System

1.4 TOE OVERVIEW

Oracle Database 12c is a relational database management system (RDBMS)
from the Oracle Corporation. The system is built around a relational database
framework in which data objects may be directly accessed by users, or an
application front end, through structured query language (SQL). Oracle is a fully
scalable relational database architecture typically used by global enterprises to
manage and process data across wide and local area networks.
The security functionality in Oracle Database 12c includes:
• Configurable audit capture.
• Fine-grained access controls on database objects. Discretionary Access
Control (DAC) is based on object and system privileges, as well as roles.
Fine-grained access control may be implemented to allow access based on
the information itself. For example, a user may be granted access to their
own human resources details, but not the details of the other users
contained in the same tables.
• User identification and authentication. Users are identified and
authenticated before access to database objects is allowed. On login, the
user identity is associated with role and privilege information that is used
to make access control decisions.
• Security management functionality. The security functionality associated
with audit, access control, and user accounts are provided through the
SQL command line interface (CLI).
• Consistent replication. The content of a database may be replicated to
another server, with assurances that the consistency of the data is
maintained.
The TOE is a software only TOE.

1.5 TOE DESCRIPTION

1.5.1 Physical Scope
The TOE consists of the Oracle Database 12c software in one of the four
configurations shown in Figure 1.

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 2 of 66

 Oracle Database 12c Enterprise Edition
Security Target

DBMS Client Legend

TOE

Operational
Environment
DBMS Server

Oracle Linux

General Purpose Computing

Hardware

Standalone Database Configuration

DBMS Client

Oracle Linux
DBMS Server
General Purpose Computing
Oracle Linux Hardware

General Purpose Computing

Hardware

Client Server Database Configuration

DBMS Client

DBMS Server

Oracle Linux
DBMS Server
General Purpose Computing
Hardware
Oracle Linux

General Purpose Computing

Hardware

Distributed Database Configuration

Middle Tier Client

Thin Client
Application Application

Oracle Linux Oracle Linux

DBMS Server
General Purpose Computing General Purpose Computing
Oracle Linux Hardware Hardware

General Purpose Computing

Hardware

Multi-tier Database Configuration

Figure 1 – Oracle Database 12c Diagram

The configurations are:

a. the DBMS server operated with a co-located client;
b. the DBMS server operated with a remote client;
c. a primary DBMS server and a secondary DBMS server with replicated
data; and

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 3 of 66

 Oracle Database 12c Enterprise Edition
Security Target

d. a DBMS server accessed by a thin client through a middle tier application

proxy.

1.5.2 TOE Environment

The following operating system and hardware components are required for
operation of the TOE in the evaluated configuration.

Component Operating System Hardware

Oracle Database 12c Oracle Linux 7 General Purpose

(TOE component) Computing Hardware

Oracle Database 12c, Oracle Linux 7 General Purpose

second instance Computing Hardware
(TOE component)

Database client Oracle Linux 7 General Purpose

(Non-TOE component) Computer Hardware

Table 1 – Operational Environment Operating System and Hardware Requirements

Note that the Database client refers to the presentation of the SQL commands at
the TOE interface. These are the same whether they are entered on the
database machine, from a client machine or from an application.

1.5.3 TOE Guidance

The TOE includes the following guidance documentation:
• Oracle® Database Installation Guide 12c Release 1 (12.1) for Linux
E41491-16, August 2016
• Oracle® Database Administrator's Guide 12c Release 1 (12.1) E41484-12,
October 2016
• Oracle® Database SQL Language Reference 12c Release 1 (12.1) E41329-
20, January 2016
• Oracle® Database PL/SQL Language Reference 12c Release 1 (12.1)
E50727-04, July 2014
• Oracle® Database Security Guide 12c Release 1 (12.1) E48135-15,
September 2016
• Oracle® Data Guard Concepts and Administration 12c Release 1 (12.1)
E48552-07, November 2015

1.5.4 Logical Scope

The logical boundary of the TOE includes all interfaces and functions within the
physical boundary. The logical boundary of the TOE may be broken down by the
security function classes described in Section 6. Table 2 summarizes the logical
scope of the TOE.

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 4 of 66

 Oracle Database 12c Enterprise Edition
Security Target

Functional Classes Description

Security Audit Audit entries are generated for security related events.
Audit policies may be created to generate logs based on
details such as the user, the object being accessed, event
type or success or failure of the operation.

User Data Protection The TOE provides a discretionary access control policy to
provide fine-grained access control between users and
database objects. Once data is allocated to a resource, the
previous information content is no longer available.

Identification and Users must identify and authenticate prior to TOE access.
Authentication Attributes are maintained to support the access control
policy.

Security Management The TOE provides management capabilities via SQL

statements. Management functions allow the
administrators to:
• configure auditing and access control options (including
granting and revoking privileges)
• configure users (including the maximum number of
concurrent sessions) and roles
• configure replication options
• configure logon triggers to support additional data
collection and login enforcement tasks

Protection of the TSF Data may be consistently replicated to a secondary DBMS

server.

TOE Access The number of concurrent user sessions may be limited by

policy. Information on successful and unsuccessful login
attempts is collected and user login may be restricted
based on user identity, time of day or day of week.

Table 2 – Logical Scope of the TOE

1.5.5 Functionality Excluded from the Evaluated

Configuration
The following features are excluded from this evaluation:
• Authentication features
o Although Oracle Database 12c supports several authentication
mechanisms, including Kerberos and Public Key Infrastructure, only
Oracle password authentication was demonstrated for the purposes
of this evaluation.
• Real Application Clusters (RAC)

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 5 of 66

 Oracle Database 12c Enterprise Edition
Security Target

• Oracle Label Security (OLS)

• Database Vault
• Multi-tenancy
• External clients

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 6 of 66

 Oracle Database 12c Enterprise Edition
Security Target

2 CONFORMANCE CLAIMS
2.1 COMMON CRITERIA CONFORMANCE CLAIM
This Security Target claims to be conformant to Version 3.1 of Common Criteria
for Information Technology Security Evaluation according to:
• Common Criteria for Information Technology Security Evaluation, Part 1:
Introduction and General Model; CCMB-2012-09-001, Version 3.1,
Revision 4, September 2012
• Common Criteria for Information Technology Security Evaluation, Part 2:
Security Functional Components; CCMB-2012-09-002, Version 3.1,
Revision 4, September 2012
• Common Criteria for Information Technology Security Evaluation, Part 3:
Security Assurance Requirements CCMB-2012-09-003, Version 3.1,
Revision 4, September 2012
As follows:
• CC Part 2 extended
• CC Part 3 conformant
The Common Methodology for Information Technology Security Evaluation,
Version 3.1, Revision 4, September 2012 (CEM) has to be taken into account.

2.2 ASSURANCE PACKAGE CLAIM

This Security Target claims conformance to Evaluation Assurance Level 2
augmented with ALC_FLR.2, Flaw Reporting Procedures.

2.3 PROTECTION PROFILE CONFORMANCE

CLAIM
The TOE for this ST claims strict conformance with the Base Protection Profile for
Database Management Systems (DBMS PP) version 2.07, dated September 9th,
2015.

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 7 of 66

 Oracle Database 12c Enterprise Edition
Security Target

3 SECURITY PROBLEM DEFINITION

3.1 THREATS
Section 3 lists the threats addressed by the TOE. In accordance with the DBMS
Protection Profile, a threat agent is defined as an entity that can adversely act
on assets. Potential threat agents are authorized TOE users, unauthorized
persons, and unauthorized processes. The level of expertise associated with
these threat agents is assumed to be unsophisticated.
TOE users are assumed to have access to the TOE, extensive knowledge of TOE
operations and to possess a level of skill commensurate with their
responsibilities. They have moderate resources to alter TOE parameters, but are
assumed not to be wilfully hostile.
Unauthorized persons have little knowledge of TOE operations, a low level of
skill, limited resources to alter TOE parameters, and no physical access to the
TOE. Unauthorized processes are assumed to be equivalent in sophistication to
an attacker with a basic attack potential.
Mitigation to the threats is through the objectives identified in Section 4.1
Security Objectives.

Threat Description

T.ACCESS_TSFDATA A threat agent may read or modify TSF data using

functions of the TOE without the proper authorization.

T.ACCESS_TSFFUNC A threat agent may use or manage TSF, bypassing

protection mechanisms of the TSF.

T.IA_MASQUERADE A user or a process acting on behalf of a user may

masquerade as an authorized entity in order to gain
unauthorized access to user data, TSF data, or TOE
resources.

T.IA_USER A threat agent may gain access to user data, TSF data, or
TOE resources with the exception of public objects
without being identified and authenticated.

T.RESIDUAL_DATA A user or a process acting on behalf of a user may gain

unauthorized access to user or TSF data through
reallocation of TOE resources from one user or process to
another.

T.TSF_COMPROMISE A user or a process acting on behalf of a user may

cause configuration data to be inappropriately
accessed (viewed, modified or deleted), or may
compromise executable code within the TSF.

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 8 of 66

 Oracle Database 12c Enterprise Edition
Security Target

Threat Description

T.UNAUTHORIZED_ACCESS A threat agent may gain unauthorized access to user

data for which they are not authorized according to the
TOE security policy.

Table 3 – Threats

3.2 ORGANIZATIONAL SECURITY POLICIES

Organizational Security Policies (OSPs) are security rules, procedures, or
guidelines imposed upon an organization in the operational environment. Table
4 lists the OSPs that are presumed to be imposed upon the TOE or its
operational environment by an organization that implements the TOE in the
Common Criteria evaluated configuration.

OSP Description

P.ACCOUNTABILITY The authorized users of the TOE shall be held accountable for
their actions within the TOE.

P.ROLES Administrative authority to TSF functionality shall be given to

trusted personnel and be as restricted as possible supporting
only the administrative duties the person has. This role shall
be separate and distinct from other authorized users.

P.USER Authority shall only be given to users who are trusted to

perform the actions correctly.

Table 4 – Organizational Security Policies

3.3 ASSUMPTIONS
The assumptions required to ensure the security of the TOE are listed in Table 5.

Assumptions Description

Physical aspects

A.PHYSICAL It is assumed that the IT environment provides the TOE with

appropriate physical security, commensurate with the value of
the IT assets protected by the TOE.

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 9 of 66

 Oracle Database 12c Enterprise Edition
Security Target

Assumptions Description

Personnel aspects

A.AUTHUSER Authorized users possess the necessary authorization to access

at least some of the information managed by the TOE.

A.MANAGE The TOE security functionality is managed by one or more

competent administrators. The system administrative personnel
are not careless, willfully negligent, or hostile, and will follow and
abide by the instructions provided by the guidance
documentation.

A.TRAINEDUSER Users are sufficiently trained and trusted to accomplish some

task or group of tasks within a secure IT environment by
exercising complete control over their user data.

Procedural aspects

A.NO_GENERAL There are no general-purpose computing capabilities (e.g.,

_PURPOSE compilers or user applications) available on DBMS servers, other
than those services necessary for the operation, administration,
and support of the DBMS.

A.PEER_FUNC All remote trusted IT systems trusted by the TSF to provide TSF
_&_MGT data or services to the TOE, or to support the TSF in the
enforcement of security policy decisions are assumed to correctly
implement the functionality used by the TSF consistent with the
assumptions defined for this functionality and to be properly
managed and operate under security policy constraints
compatible with those of the TOE.

A.SUPPORT Any information provided by a trusted entity in the IT

environment and used to support the provision of time and date,
information used in audit capture, user authentication, and
authorization that is used by the TOE is correct and up to date.

Connectivity aspects

A.CONNECT All connections to and from remote trusted IT systems and

between separate parts of the TSF are physically or logically
protected within the TOE environment to ensure the integrity and
confidentiality of the data transmitted and to ensure the
authenticity of the communication end points.

Table 5 – Assumptions

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 10 of 66

 Oracle Database 12c Enterprise Edition
Security Target

4 SECURITY OBJECTIVES
The purpose of the security objectives is to address the security concerns and to
show which security concerns are addressed by the TOE and which are
addressed by the environment. Threats may be addressed by the TOE or the
security environment or both. Therefore, the CC identifies two categories of
security objectives:
• Security objectives for the TOE
• Security objectives for the environment

4.1 SECURITY OBJECTIVES FOR THE TOE

This section identifies and describes the security objectives that are to be
addressed by the TOE.

Security Objective Description

O.ACCESS_HISTORY The TOE will store information related to previous attempts to
establish a session and make that information available to the
user.

O.ADMIN_ROLE The TOE will provide a mechanism (e.g. a "role") by which the
actions using administrative privileges may be restricted.

O.AUDIT The TSF must be able to record defined security-relevant

_GENERATION events (which usually include security-critical actions of users
of the TOE). The information recorded for security-relevant
events must contain the time and date the event happened
and, if possible, the identification of the user that caused the
event, and must be in sufficient detail to help the authorized
user detect attempted security violations or potential
misconfiguration of the TOE security features that would leave
the IT assets open to compromise.

O.DISCRETIONARY The TSF must control access of subjects and/or users to

_ACCESS named resources based on identity of the object, subject, or
user. The TSF must allow authorized users to specify for each
access mode which users/subjects are allowed to access a
specific named object in that access mode.

O.I&A The TOE ensures that users are authenticated before the TOE
processes any actions that require authentication.

O.MANAGE The TSF must provide all the functions and facilities necessary
to support the authorized users that are responsible for the
management of TOE security mechanisms, must allow
restricting such management actions to dedicated users, and
must ensure that only such authorized users are able to
access management functionality.

O.MEDIATE The TOE must protect user data in accordance with its
security policy, and must mediate all requests to access such

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 11 of 66

 Oracle Database 12c Enterprise Edition
Security Target

Security Objective Description

data.

O.RESIDUAL The TOE will ensure that any information contained in a

_INFORMATION protected resource within its Scope of Control is not
inappropriately disclosed when the resource is reallocated.

O.TOE_ACCESS The TOE will provide functionality that controls a user's logical
access 1 to user data and to the TSF.

Table 6 – Security Objectives for the TOE

4.2 SECURITY OBJECTIVES FOR THE

OPERATIONAL ENVIRONMENT
This section identifies and describes the security objectives that are to be
addressed by non-technical or procedural means, and by the IT domain.

4.2.1 Operational Environment Security Objectives

The following table describes the operational environment security objectives.

Security Description
Objective
OE.ADMIN Those responsible for the TOE are competent and trustworthy
individuals, capable of managing the TOE and the security of
the information it contains.

OE.INFO_PROTECT Those responsible for the TOE must establish and implement
procedures to ensure that information is protected in an
appropriate manner. In particular:
• All network and peripheral cabling must be approved for
the transmittal of the most sensitive data transmitted
over the link. Such physical links are assumed to be
adequately protected against threats to the
confidentiality and integrity of the data transmitted using
appropriate physical and logical protection techniques.
• DAC protections on security-relevant files (such as audit
trails and authorization databases) shall always be set
up correctly.
• Users are authorized to access parts of the data
managed by the TOE and are trained to exercise control
over their own data.

OE.NO_GENERAL There will be no general-purpose computing capabilities (e.g.,

1
As noted in the DBMS PP, "logical access" is specified, since the control of "physical
access" is outside the scope of the evaluation.

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 12 of 66

 Oracle Database 12c Enterprise Edition
Security Target

Security Description
Objective
_PURPOSE compilers or user applications) available on DBMS servers,
other than those services necessary for the operation,
administration, and support of the DBMS.

OE.PHYSICAL Those responsible for the TOE must ensure that those parts of
the TOE critical to enforcement of the security policy are
protected from physical attack that might compromise IT
security objectives. The protection must be commensurate with
the value of the IT assets protected by the TOE.

Table 7 – Operational Environment Security Objectives

4.2.2 Operational Environment IT Domain Security

Objectives
The following table describes the operational environment IT security objectives.

Security Description
Objective

OE.IT_I&A Any information provided by a trusted entity in the environment

and used to support user authentication and authorization used
by the TOE is correct and up to date.

OE.IT_REMOTE If the TOE relies on remote trusted IT systems to support the

enforcement of its policy, those systems provide that the
functions and any data used by the TOE in making policy
decisions required by the TOE are sufficiently protected from any
attack that may cause those functions to provide false results.

OE.IT_TRUSTED The remote trusted IT systems implement the protocols and

_SYSTEM mechanisms required by the TSF to support the enforcement of
the security policy.
These remote trusted IT systems are managed according to
known, accepted, and trusted policies based on the same rules
and policies applicable to the TOE, and are physically and
logically protected equivalent to the TOE.

Table 8 – Operational Environment IT Security Objectives

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 13 of 66

 Oracle Database 12c Enterprise Edition
Security Target

4.3 SECURITY OBJECTIVES RATIONALE

The following table maps the security objectives to the assumptions, threats,
and organisational policies identified for the TOE.

T.UNAUTHORIZED_ACCESS

A.NO_GENERAL_PURPOSE
A.PEER_FUNC_&_MGT
T.TSF_COMPROMISE
T.ACCESS_TSFFUNC
T.ACCESS_TSFDATA

P.ACCOUNTABILITY
T.IA_MASQUERADE

T.RESIDUAL_DATA

A.TRAINEDUSER
A.AUTHUSER
A.PHYSICAL

A.CONNECT
A.SUPPORT
T.IA_USER

A.MANAGE
P.ROLES
P.USER
O.ACCESS_HISTORY X X X
O.ADMIN_ROLE X X X
O.AUDIT
X X
_GENERATION
O.DISCRETIONARY
X X
_ACCESS
O.I&A X X X X X
O.MANAGE X X X X
O.MEDIATE X X X
O.RESIDUAL
X X X
_INFORMATION
O.TOE_ACCESS X X X X X X X X
OE.ADMIN X X X X
OE.INFO_PROTECT X X X X X X X X X
OE.NO_GENERAL
X X X
_PURPOSE
OE.PHYSICAL X X X
OE.IT_I&A X
OE.IT_REMOTE X X X X
OE.IT_TRUSTED
X X X X
_SYSTEM

Table 9 – Mapping Between Objectives, Threats, OSPs, and Assumptions

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 14 of 66

 Oracle Database 12c Enterprise Edition
Security Target

4.3.1 Security Objectives Rationale Related to

Threats
The security objectives rationale related to threats traces the security objectives
for the TOE and the Operational Environment back to the threats addressed by
the TOE. The rationale tracing the threats to the security objectives for the TOE
and to the Operational Environment have been separated to provide consistency
with the claimed PP.

4.3.1.1 Threats Mapped to Security Objectives for the TOE

Threat: A threat agent may read or modify TSF data using functions of the
TOE without the proper authorization.
T.ACCESS
_TSFDATA

Objectives: O.ACCESS The TOE will store information related to

_HISTORY previous attempts to establish a session and
make that information available to the user.

O.I&A The TOE ensures that users are authenticated

before the TOE processes any actions that
require authentication.

O.MANAGE The TSF must provide all the functions and

facilities necessary to support the authorized
users that are responsible for the
management of TOE security mechanisms,
must allow restricting such management
actions to dedicated users, and must ensure
that only such authorized users are able to
access management functionality.

O.RESIDUAL The TOE will ensure that any information

_INFORMATION contained in a protected resource within its
Scope of Control is not inappropriately
disclosed when the resource is reallocated.

O.TOE_ACCESS The TOE will provide functionality that controls

a user's logical access to user data and to the
TSF.

Rationale: O.ACCESS_HISTORY diminishes this threat because it ensures the

TOE will store the information that is needed to advise the user of
previous authentication attempts and allows this information to be
retrieved.
O.I&A supports this policy by requiring that each entity interacting
with the TOE is properly identified and authenticated before
allowing any action the TOE is defined to provide to authenticated
users only.
O.MANAGE diminishes this threat since it ensures that functions
and facilities used to modify TSF data are not available to

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 15 of 66

 Oracle Database 12c Enterprise Edition
Security Target

unauthorized users.
O.RESIDUAL_INFORMATION diminishes this threat since
information contained in protected resources will not be easily
available to the threat agent through reallocation attacks.
O.TOE_ACCESS diminishes this threat since it makes it more
unlikely that a threat agent has access to the TOE.

Threat: A threat agent may use or manage TSF, bypassing protection

mechanisms of the TSF.
T.ACCESS
_TSFFUNC

Objectives: O.ADMIN_ROLE The TOE will provide a mechanism (e.g. a

"role") by which the actions using
administrative privileges may be restricted.

O.I&A The TOE ensures that users are authenticated

before the TOE processes any actions that
require authentication.

O.MANAGE The TSF must provide all the functions and

facilities necessary to support the authorized
users that are responsible for the
management of TOE security mechanisms,
must allow restricting such management
actions to dedicated users, and must ensure
that only such authorized users are able to
access management functionality.

O.RESIDUAL The TOE will ensure that any information

_INFORMATION contained in a protected resource within its
Scope of Control is not inappropriately
disclosed when the resource is reallocated.

O.TOE_ACCESS The TOE will provide mechanisms that control

a user's logical access to user data and to the
TSF.

Rationale: O.ADMIN_ROLE diminishes this threat by providing isolation of

privileged actions.
O.I&A diminishes this threat since the TOE requires successful
authentication to the TOE prior to gaining access to any controlled-
access content. By implementing strong authentication to gain
access to these services, an attacker's opportunity to masquerade
as another entity in order to gain unauthorized access to data or
TOE resources is reduced.
O.MANAGE diminishes this threat because an access control policy
is specified to control access to TSF data. This objective is used to
dictate who is able to view and modify TSF data, as well as the
behavior of TSF functions.

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 16 of 66

 Oracle Database 12c Enterprise Edition
Security Target

O.RESIDUAL_INFORMATION diminishes this threat by ensuring that

TSF data and user data is not persistent when resources are
released by one user/process and allocated to another
user/process.
O.TOE_ACCESS diminishes this threat since it makes it more
unlikely that a threat agent has access to the TOE.

Threat: A user or a process acting on behalf of a user may masquerade as

an authorized entity in order to gain unauthorized access to user
T.IA data, TSF data, or TOE resources.
_MASQUERADE

Objectives: O.ACCESS The TOE will store information related to

_HISTORY previous attempts to establish a session and
make that information available to the user.

O.I&A The TOE ensures that users are authenticated

before the TOE processes any actions that
require authentication.

O.MEDIATE The TOE must protect user data in accordance

with its security policy, and must mediate all
requests to access such data.

O.TOE_ACCESS The TOE will provide mechanisms that control

a user's logical access to user data and to the
TSF.

Rationale: O.ACCESS_HISTORY diminishes this threat because it ensures the

TOE will be able to store and retrieve the information that will
advise the user of the last successful login attempt and performed
actions without their knowledge.
O.I&A diminishes this threat by requiring that each entity
interacting with the TOE is properly identified and authenticated
before allowing any action the TOE has defined to provide to
authenticated users only.
O.MEDIATE diminishes this threat by ensuring that all access to
user data are subject to mediation, unless said data has been
specifically identified as public data. The TOE requires successful
authentication to the TOE prior to gaining access to any controlled-
access content. By implementing strong authentication to gain
access to these services, an attacker's opportunity to masquerade
as another entity in order to gain unauthorized access to data or
TOE resources is reduced.
O.TOE_ACCESS diminishes this threat by controlling the logical
access to the TOE and its resources. By constraining how and when
authorized users can access the TOE, and by mandating the type
and strength of the authentication mechanism this objective helps
mitigate the possibility of a user attempting to login and
masquerade as an authorized user. In addition, this objective

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 17 of 66

 Oracle Database 12c Enterprise Edition
Security Target

provides the administrator the means to control the number of

failed login attempts a user can generate before an account is
locked out, further reducing the possibility of a user gaining
unauthorized access to the TOE.

Threat: A threat agent may gain access to user data, TSF data, or TOE
resources with the exception of public objects without being
T.IA_USER identified and authenticated.

Objectives: O.DISCRETIONARY The TSF must control access of subjects

_ACCESS and/or users to named resources based on
identity of the object, subject, or user. The
TSF must allow authorized users to specify
for each access mode which users/subjects
are allowed to access a specific named object
in that access mode.

O.I&A The TOE ensures that users are

authenticated before the TOE processes any
actions that require authentication.

O.MEDIATE The TOE must protect user data in

accordance with its security policy, and must
mediate all requests to access such data.

O.TOE_ACCESS The TOE will provide mechanisms that

control a user's logical access to user data
and to the TSF.

Rationale: O.DISCRETIONARY_ACCESS diminishes this threat by requiring

that data including user data stored with the TOE, have
discretionary access control protection.
O.I&A diminishes this threat by requiring that each entity
interacting with the TOE is properly identified and authenticated
before allowing any action the TOE is defined to provide to
authenticated users only.
O.MEDIATE diminishes this threat by ensuring that all access to
user data are subject to mediation, unless said data has been
specifically identified as public data. The TOE requires successful
authentication to the TOE prior to gaining access to any controlled-
access content. By implementing strong authentication to gain
access to these services, an attacker's opportunity to masquerade
as another entity in order to gain unauthorized access to data or
TOE resources is reduced.
O.TOE_ACCESS diminishes this threat by controlling logical access
to user data, TSF data or TOE resources.

Threat: A user or a process acting on behalf of a user may gain

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 18 of 66

 Oracle Database 12c Enterprise Edition
Security Target

T.RESIDUAL unauthorized access to user or TSF data through reallocation of

_DATA TOE resources from one user or process to another.

Objectives: O.RESIDUAL The TOE will ensure that any information

_INFORMATION contained in a protected resource within its
Scope of Control is not inappropriately
disclosed when the resource is reallocated.

Rationale: O.RESIDUAL_INFORMATION diminishes this threat because even if

the security mechanisms do not allow a user to view TSF data, if
TSF data were to reside inappropriately in a resource that was
made available to a user, that user would be able to view the TSF
data without authorization.

Threat: A user or a process acting on behalf of a user may cause

configuration data to be inappropriately accessed (viewed, modified
T.TSF
or deleted), or may compromise executable code within the TSF.
_COMPROMISE

Objectives: O.ACCESS The TOE will store information related to

_HISTORY previous attempts to establish a session and
make that information available to the user.

O.AUDIT The TOE will provide the capability to detect

_GENERATION and create records of security relevant
events associated with users.

O.TOE_ACCESS The TOE will provide mechanisms that

control a user's logical access to user data
and to the TSF.

Rationale: O.ACCESS_HISTORY diminishes this threat because it ensures the

TOE will be able to store and retrieve the information that will
advise the user of the last successful login attempt and performed
actions without their knowledge.
O.AUDIT_GENERATION diminishes this threat by providing the
authorized administrator with the appropriate audit records
supporting the detection of compromise of the TSF.
O.TOE_ACCESS diminishes this threat since controlled user's logical
access to the TOE will reduce the opportunities for an attacker’s
access to configuration data.

Threat: A threat agent may gain unauthorized access to user data for
which they are not authorized according to the TOE security
T.UNAUTHOR-
policy.
IZED_ACCESS

Objectives: O.DISCRETIONARY The TSF must control access of subjects

_ACCESS and/or users to named resources based on
identity of the object, subject or user. The

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 19 of 66

 Oracle Database 12c Enterprise Edition
Security Target

TSF must allow authorized users to specify

for each access mode which users/subjects
are allowed to access a specific named
object in that access mode.

O.MANAGE The TSF must provide all the functions and

facilities necessary to support the
authorized users that are responsible for
the management of TOE security
mechanisms, must allow restricting such
management actions to dedicated users,
and must ensure that only such authorized
users are able to access management
functionality.

O.MEDIATE The TOE must protect user data in

accordance with its security policy, and
must mediate all requests to access such
data.

Rationale: O.DISCRETIONARY_ACCESS diminishes this threat by requiring

that data including TSF data stored with the TOE, have
discretionary access control protection.
O.MANAGE diminishes this threat by ensuring that the functions
and facilities supporting that authorized users can be held
accountable for their actions by authorized administrators are in
place.
O.MEDIATE diminishes this threat because it ensures that all
access to user data are subject to mediation, unless said data has
been specifically identified as public data. The TOE requires
successful authentication to the TOE prior to gaining access to any
controlled-access content. By implementing strong authentication
to gain access to these services, an attacker's opportunity to
conduct a man-in-the-middle and/or password guessing attack
successfully is greatly reduced. Lastly, the TSF will ensure that all
configured enforcement functions (authentication, access control
rules, etc.) must be invoked prior to allowing a user to gain
access to TOE or TOE mediated services. The TOE restricts the
ability to modify the security attributes associated with access
control rules, access to authenticated and unauthenticated
services, etc. to the administrator. This feature ensures that no
other user can modify the information flow policy to bypass the
intended TOE security policy.

4.3.1.2 Threats Mapped to Security Objectives for the

Operational Environment
Threat: A user or process may masquerade as an authorized entity in order
to gain unauthorized access to user data, TSF data, or TOE
T.IA
resources.

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 20 of 66

 Oracle Database 12c Enterprise Edition
Security Target

_MASQUERADE

Objectives: OE.NO_GENERAL There will be no general-purpose computing

_PURPOSE capabilities (e.g., compilers or user
applications) available on DMBS servers, other
than those services necessary for the
operation, administration, and support of the
DBMS.

Rationale: OE.NO_GENERAL_PURPOSE
The DBMS server must not include any general-purpose computing
or storage capabilities.
This diminishes the threat of masquerade since only users with
DBMS or related functions will be defined in the TOE environment.

Threat: A user or process acting on behalf of a use may cause configuration

data to be inappropriately accessed (viewed, modified or deleted),
T.TSF
or may compromise executable code within the TSF.
_COMPROMISE

Objectives: OE.INFO Those responsible for the TOE must establish

_PROTECT and implement procedures to ensure that
information is protected in an appropriate
manner. In particular:
• All network and peripheral cabling
must be approved for the transmittal
of the most sensitive data transmitted
over the link. Such physical links are
assumed to be adequately protected
against threats to the confidentiality
and integrity of the data transmitted
using appropriate physical and logical
protection techniques.
• DAC protections on security-relevant
files (such as audit trails and
authorization databases) shall always
be set up correctly.
• Users are authorized to access parts
of the data managed by the TOE and
are trained to exercise control over
their own data.

OE.IT_REMOTE If the TOE relies on remote trusted IT

systems to support the enforcement of its
policy, those systems provide that the
functions and any data used by the TOE in
making policy decisions, required by the TOE
are sufficiently protected from any attack
that may cause those functions to provide
false results.

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 21 of 66

 Oracle Database 12c Enterprise Edition
Security Target

OE.IT_TRUSTED The remote trusted IT systems implement

_SYSTEM the protocols and mechanisms required by
the TSF to support the enforcement of the
security policy.
These remote trusted IT systems are
managed according to known, accepted, and
trusted policies based on the same rules and
policies applicable to the TOE, and are
physically and logically protected equivalent
to the TOE.

OE.NO_GENERAL There will be no general-purpose computing

_PURPOSE capabilities (e.g., compilers or user
applications) available on DMBS servers,
other than those services necessary for the
operation, administration, and support of the
DBMS.

OE.PHYSICAL Those responsible for the TOE must ensure

that those parts of the TOE critical to
enforcement of the security policy are
protected from physical attack that might
compromise IT security objectives. The
protection must be commensurate with the
value of the IT assets protected by the TOE.

Rationale: OE.INFO_PROTECT diminishes the threat by ensuring that all

network and peripheral cabling must be approved for the
transmittal of the most sensitive data transmitted over the link.
Such physical links are assumed to be adequately protected against
threats to the confidentiality and integrity of the data transmitted
using appropriate physical and logical protection techniques.
OE.IT_REMOTE diminishes the threat by ensuring that remote
trusted IT systems are sufficiently protected.
OE.IT_TRUSTED_SYSTEM diminishes the threat by ensuring that
remote trusted IT systems are managed according to known,
accepted and trusted policies based on the same rules and policies
applicable to the TOE, and are physically and logically protected
equivalent to the TOE.
OE.NO_GENERAL_PURPOSE diminishes this threat by reducing the
opportunities to subvert non TOE related capabilities in the TOE
environment.
OE.PHYSICAL diminishes the threat of a TSF compromise due to
exploitation of physical weaknesses or vulnerabilities as a vector in
an attack.

Threat: A threat agent may gain unauthorized access to user data for
which they are not authorized according to the TOE security
T.UNAUTHOR-

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 22 of 66

 Oracle Database 12c Enterprise Edition
Security Target

IZED_ACCESS policy.

Objectives: OE.INFO Those responsible for the TOE must

_PROTECT establish and implement procedures to
ensure that information is protected in an
appropriate manner. In particular:
• All network and peripheral cabling
must be approved for the transmittal
of the most sensitive data
transmitted over the link. Such
physical links are assumed to be
adequately protected against threats
to the confidentiality and integrity of
the data transmitted using
appropriate physical and logical
protection techniques.
• DAC protections on security-relevant
files (such as audit trails and
authorization databases) shall
always be set up correctly.
• Users are authorized to access parts
of the data managed by the TOE and
are trained to exercise control over
their own data.

Rationale: OE.INFO_PROTECT diminishes the threat by ensuring that the

logical and physical threats to network and peripheral cabling are
appropriately protected.
DAC protections if implemented correctly may support the
identification of unauthorized accesses.

4.3.2 Security Objectives Rationale Related to OSPs

The security objectives rationale related to OSPs traces the security objectives
for the TOE and the Operational Environment back to the OSPs applicable to the
TOE. The rationale tracing the OSPs to the security objectives for the TOE and to
the Operational Environment have been separated to provide consistency with
the claimed PP.

4.3.2.1 OSPs Mapped to Security Objectives for the TOE

Policy: The authorized users of the TOE shall be held accountable for their
actions within the TOE.
P.ACCOUNT-
ABILITY

Objectives: O.ADMIN_ROLE The TOE will provide a mechanism (e.g. a

"role") by which the actions using
administrative privileges may be restricted.

O.AUDIT The TOE will provide the capability to detect

_GENERATION and create records of security relevant events

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 23 of 66

 Oracle Database 12c Enterprise Edition
Security Target

associated with users.

O.I&A The TOE ensures that users are authenticated

before the TOE processes any actions that
require authentication.

O.TOE_ACCESS The TOE will provide mechanisms that control

a user's logical access to user data and to the
TSF.

Rationale: O.ADMIN_ROLE supports this policy by ensuring that the TOE has
an objective to provide authorized administrators with the
privileges needed for secure administration.
O.AUDIT_GENERATION supports this policy by ensuring that audit
records are generated. Having these records available enables
accountability.
O.I&A supports this policy by requiring that each entity interacting
with the TOE is properly identified and authenticated before
allowing any action the TOE is defined to provide to authenticated
users only.
O.TOE_ACCESS supports this policy by providing a mechanism for
controlling access to authorized users.

Policy: Administrative authority to TSF functionality shall be given to

trusted personnel and be as restricted as possible supporting only
P.ROLES the administrative duties the person has. This role shall be separate
and distinct from other authorized users.

Objectives: O.ADMIN_ROLE The TOE will provide a mechanism (e.g. a

"role") by which the actions using
administrative privileges may be restricted.

O.TOE_ACCESS The TOE will provide mechanisms that control

a user's logical access to user data and to the
TSF.

Rationale: O.ADMIN_ROLE
The TOE has the objective of providing an authorized administrator
role for secure administration. The TOE may provide other roles as
well, but only the role of authorized administrator is required.
O.TOE_ACCESS supports this policy by ensuring that an authorized
administrator role can be distinguished from other authorized
users.

Policy: Authority shall only be given to users who are trusted to perform
the actions correctly.
P.USER

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 24 of 66

 Oracle Database 12c Enterprise Edition
Security Target

Objectives: O.MANAGE The TSF must provide all the functions and
facilities necessary to support the authorized
users that are responsible for the
management of TOE security mechanisms,
must allow restricting such management
actions to dedicated users, and must ensure
that only such authorized users are able to
access management functionality.

O.TOE_ACCESS The TOE will provide mechanisms that control

a user's logical access to user data and to the
TSF.

Rationale: O.MANAGE supports this policy by ensuring that the functions and
facilities supporting the authorized administrator role are in place.
O.TOE_ACCESS supports this policy by providing a mechanism for
controlling access to authorized users.

4.3.2.2 OSPs Mapped to Security Objectives for the Operational

Environment
Policy: The authorized users of the TOE shall be held accountable for their
actions within the TOE.
P.ACCOUNT-
ABILITY

Objectives: OE.ADMIN Those responsible for the TOE are competent

and trustworthy individuals, capable of
managing the TOE and the security of
information it contains.

OE.INFO Those responsible for the TOE must establish

_PROTECT and implement procedures to ensure that
information is protected in an appropriate
manner. In particular:
• All network and peripheral cabling must
be approved for the transmittal of the
most sensitive data transmitted over
the link. Such physical links are
assumed to be adequately protected
against threats to the confidentiality
and integrity of the data transmitted
using appropriate physical and logical
protection techniques.
• DAC protections on security-relevant
files (such as audit trails and
authorization databases) shall always
be set up correctly.
• Users are authorized to access parts of
the data managed by the TOE and are
trained to exercise control over their

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 25 of 66

 Oracle Database 12c Enterprise Edition
Security Target

own data.

Rationale: OE.ADMIN supports the policy that the authorized administrators

are assumed competent in order to help ensure that all the tasks
and responsibilities are performed effectively.
OE.INFO_PROTECT supports the policy by ensuring that the
authorized users are trained and have procedures available to
support them and that the DAC protections function and are able to
provide sufficient information to inform those pursuing
accountability.

Policy: Administrative authority to TSF functionality shall be given to

trusted personnel and be as restricted as possible supporting only
P.ROLES the administrative duties the person has. This role shall be separate
and distinct from other authorized users.

Objectives: OE.ADMIN Those responsible for the TOE are competent

and trustworthy individuals, capable of
managing the TOE and the security of
information it contains.

Rationale: OE.ADMIN supports the policy by ensuring that an authorized

administrator role for secure administration of the TOE is
established.

Policy: Authority shall only be given to users who are trusted to perform
the actions correctly.
P.USER

Objectives: OE.ADMIN Those responsible for the TOE are competent

and trustworthy individuals, capable of
managing the TOE and the security of
information it contains.

OE.INFO Those responsible for the TOE must establish

_PROTECT and implement procedures to ensure that
information is protected in an appropriate
manner. In particular:
• All network and peripheral cabling must
be approved for the transmittal of the
most sensitive data transmitted over
the link. Such physical links are
assumed to be adequately protected
against threats to the confidentiality
and integrity of the data transmitted
using appropriate physical and logical
protection techniques.
• DAC protections on security-relevant
files (such as audit trails and

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 26 of 66

 Oracle Database 12c Enterprise Edition
Security Target

authorization databases) shall always

be set up correctly.
• Users are authorized to access parts of
the data managed by the TOE and are
trained to exercise control over their
own data.

Rationale: OE.ADMIN supports the policy by ensuring that the authorized

administrators, responsible for giving appropriate authorities to
users, are trustworthy.
OE.INFO_PROTECT supports the policy by ensuring that users are
authorized to access parts of the data managed by the TOE and are
trained to exercise control over their own data and that DAC
protections on security-relevant files (such as audit trails and
authorization databases) shall always be set up correctly.

4.3.3 Security Objectives Rationale Related to

Assumptions
The security objectives rationale related to assumptions traces the security
objectives for the operational environment back to the assumptions for the
TOE’s operational environment.

Assumption: It is assumed that the IT environment provides the TOE with

appropriate physical security, commensurate with the value of the
A.PHYSICAL IT assets protected by the TOE.

Objectives: OE.PHYSICAL Those responsible for the TOE must ensure

that those parts of the TOE critical to
enforcement of the security policy are
protected from physical attack that might
compromise IT security objectives. The
protection must be commensurate with the
value of the IT assets protected by the TOE.

OE.INFO Those responsible for the TOE must establish

_PROTECT and implement procedures to ensure that
information is protected in an appropriate
manner. In particular:
• All network and peripheral cabling must
be approved for the transmittal of the
most sensitive data transmitted over
the link. Such physical links are
assumed to be adequately protected
against threats to the confidentiality
and integrity of the data transmitted
using appropriate physical and logical
protection techniques.
• DAC protections on security-relevant
files (such as audit trails and
authorization databases) shall always

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 27 of 66

 Oracle Database 12c Enterprise Edition
Security Target

be set up correctly.
• Users are authorized to access parts of
the data managed by the TOE and are
trained to exercise control over their
own data.

Rationale: OE.PHYSICAL
The TOE, the TSF data, and protected user data is assumed to be
protected from physical attack (e.g., theft, modification,
destruction, or eavesdropping). Physical attack could include
unauthorized intruders into the TOE environment, but it does not
include physical destructive actions that might be taken by an
individual that is authorized to access the TOE environment.
OE.INFO_PROTECT supports the assumption by requiring that all
network and peripheral cabling must be approved for the
transmittal of the most sensitive data transmitted over the link.
Such physical links are assumed to be adequately protected against
threats to the confidentiality and integrity of the data transmitted
using appropriate physical and logical protection techniques.

Assumption: Authorized users possess the necessary authorization to access at

least some of the information managed by the TOE.
A.AUTHUSER

Objectives: OE.INFO Those responsible for the TOE must establish

_PROTECT and implement procedures to ensure that
information is protected in an appropriate
manner. In particular:
• All network and peripheral cabling must
be approved for the transmittal of the
most sensitive data transmitted over
the link. Such physical links are
assumed to be adequately protected
against threats to the confidentiality
and integrity of the data transmitted
using appropriate physical and logical
protection techniques.
• DAC protections on security-relevant
files (such as audit trails and
authorization databases) shall always
be set up correctly.
• Users are authorized to access parts of
the data managed by the TOE and are
trained to exercise control over their
own data.

OE.IT_REMOTE If the TOE relies on remote trusted IT systems

to support the enforcement of its policy, those
systems provide that the functions and any
data used by the TOE in making policy

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 28 of 66

 Oracle Database 12c Enterprise Edition
Security Target

decisions, required by the TOE are sufficiently

protected from any attack that may cause
those functions to provide false results.

OE.IT_TRUSTED The remote trusted IT systems implement the

_SYSTEM protocols and mechanisms required by the TSF
to support the enforcement of the security
policy.
These remote trusted IT systems are managed
according to known, accepted, and trusted
policies based on the same rules and policies
applicable to the TOE, and are physically and
logically protected equivalent to the TOE.

Rationale: OE.INFO_PROTECT supports the assumption by ensuring that users

are authorized to access parts of the data managed by the TOE and
is trained to exercise control over their own data.
Having trained, authorized users, who are provided with relevant
procedures for information protection supports the assumption of
co-operation.
OE.IT_REMOTE supports this assumption by ensuring that remote
systems that form part of the IT environment are protected. This
gives confidence that the environment is benign.
OE.IT_TRUSTED_SYSTEM supports this assumption by providing
confidence that systems in the TOE IT environment contribute to a
benign environment.

Assumption: The TOE security functionality is managed by one or more

competent administrators. The system administrative personnel are
A.MANAGE not careless, willfully negligent, or hostile, and will follow and abide
by the instructions provided by the guidance documentation.

Objectives: OE.ADMIN Those responsible for the TOE are competent

and trustworthy individuals, capable of
managing the TOE and the security of
information it contains.

OE.INFO Those responsible for the TOE must establish

_PROTECT and implement procedures to ensure that
information is protected in an appropriate
manner. In particular:
• All network and peripheral cabling must
be approved for the transmittal of the
most sensitive data transmitted over
the link. Such physical links are
assumed to be adequately protected
against threats to the confidentiality
and integrity of the data transmitted
using appropriate physical and logical

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 29 of 66

 Oracle Database 12c Enterprise Edition
Security Target

protection techniques.
• DAC protections on security-relevant
files (such as audit trails and
authorization databases) shall always
be set up correctly.
• Users are authorized to access parts of
the data managed by the TOE and are
trained to exercise control over their
own data.

Rationale: OE.ADMIN supports the assumption since the authorized

administrators are assumed competent in order to help ensure that
all the tasks and responsibilities are performed effectively.
OE.INFO_PROTECT supports the assumption by ensuring that the
information protection aspects of the TOE and the system(s) and
relevant connectivity that form the platform for the TOE is vital to
addressing the security problem, described in this ST and the PP.
Managing these effectively using defined procedures is reliant on
having competent administrators.

Assumption: Users are sufficiently trained and trusted to accomplish some task
or group of tasks within a secure IT environment by exercising
A.TRAINED- complete control over their user data.
USER

Objectives: OE.INFO Those responsible for the TOE must establish

_PROTECT and implement procedures to ensure that
information is protected in an appropriate
manner. In particular:
• All network and peripheral cabling must
be approved for the transmittal of the
most sensitive data transmitted over
the link. Such physical links are
assumed to be adequately protected
against threats to the confidentiality
and integrity of the data transmitted
using appropriate physical and logical
protection techniques.
• DAC protections on security-relevant
files (such as audit trails and
authorization databases) shall always
be set up correctly.
• Users are authorized to access parts of
the data managed by the TOE and are
trained to exercise control over their
own data.

Rationale: OE.INFO_PROTECT supports the assumption by ensuring that users

are authorized to access parts of the data managed by the TOE and
is trained to exercise control over their own data.

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 30 of 66

 Oracle Database 12c Enterprise Edition
Security Target

Assumption: There are no general-purpose computing capabilities (e.g.,

compilers or user applications) available on DBMS servers, other
A.NO_GENERAL than those services necessary for the operation, administration,
_PURPOSE and support of the DBMS.

Objectives: OE.NO_GENERAL There will be no general-purpose computing

_PURPOSE capabilities (e.g., compilers or user
applications) available on DMBS servers, other
than those services necessary for the
operation, administration, and support of the
DBMS.

Rationale: OE.NO_GENERAL_PURPOSE
The DBMS server must not include any general-purpose computing
or storage capabilities. This will protect the TSF data from malicious
processes. The environmental objective is tightly related to the
assumption, which when fulfilled will address the assumption.

Assumption: All remote trusted IT systems trusted by the TSF to provide TSF
data or services to the TOE, or to support the TSF in the
A.PEER_FUNC enforcement of security policy decisions are assumed to correctly
_&_MGT implement the functionality used by the TSF consistent with the
assumptions defined for this functionality and to be properly
managed and operate under security policy constraints compatible
with those of the TOE.

Objectives: OE.IT_REMOTE If the TOE relies on remote trusted IT systems

to support the enforcement of its policy, those
systems provide that the functions and any
data used by the TOE in making policy
decisions, required by the TOE are sufficiently
protected from any attack that may cause
those functions to provide false results.

OE.IT_TRUSTED The remote trusted IT systems implement the

_SYSTEM protocols and mechanisms required by the TSF
to support the enforcement of the security
policy.
These remote trusted IT systems are managed
according to known, accepted, and trusted
policies based on the same rules and policies
applicable to the TOE, and are physically and
logically protected equivalent to the TOE.

Rationale: OE.IT_REMOTE
The assumption that connections between trusted systems or
physically separated parts of the TOE is addressed by the objective
specifying that such systems are sufficiently protected from any

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 31 of 66

 Oracle Database 12c Enterprise Edition
Security Target

attack that may cause those functions to provide false results.

OE.IT_TRUSTED_SYSTEM
The assumption on all remote trusted IT systems to implement
correctly the functionality used by the TSF consistent with the
assumptions defined for this functionality is supported by physical
and logical protections and the application of trusted policies
commensurate with those applied to the TOE.

Assumption: Any information provided by a trusted entity in the IT environment

and used to support the provision of time and date, information
A.SUPPORT used in audit capture, user authentication, and authorization that is
used by the TOE is correct and up to date.

Objectives: OE.IT_I&A Any information provided by a trusted entity in

the environment and used to support user
authentication and authorization used by the
TOE is correct and up to date.

Rationale: OE.IT_I&A supports the assumption implicitly.

Assumption: All connections to and from remote trusted IT systems and between
separate parts of the TSF are physically or logically protected within
A.CONNECT
the TOE environment to ensure the integrity and confidentiality of
the data transmitted and to ensure the authenticity of the
communication end points.

Objectives: OE.IT_REMOTE If the TOE relies on remote trusted IT systems

to support the enforcement of its policy, those
systems provide that the functions and any
data used by the TOE in making policy
decisions, required by the TOE are sufficiently
protected from any attack that may cause
those functions to provide false results.

OE.INFO Those responsible for the TOE must establish

_PROTECT and implement procedures to ensure that
information is protected in an appropriate
manner. In particular:
• All network and peripheral cabling must
be approved for the transmittal of the
most sensitive data transmitted over
the link. Such physical links are
assumed to be adequately protected
against threats to the confidentiality
and integrity of the data transmitted
using appropriate physical and logical
protection techniques.
• DAC protections on security-relevant
files (such as audit trails and
authorization databases) shall always

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 32 of 66

 Oracle Database 12c Enterprise Edition
Security Target

be set up correctly.
• Users are authorized to access parts of
the data managed by the TOE and are
trained to exercise control over their
own data.

OE.IT_TRUSTED The remote trusted IT systems implement the

_SYSTEM protocols and mechanisms required by the TSF
to support the enforcement of the security
policy.
These remote trusted IT systems are managed
according to known, accepted, and trusted
policies based on the same rules and policies
applicable to the TOE, and are physically and
logically protected equivalent to the TOE.

OE.PHYSICAL Those responsible for the TOE must ensure

that those parts of the TOE critical to
enforcement of the security policy are
protected from physical attack that might
compromise IT security objectives. The
protection must be commensurate with the
value of the IT assets protected by the TOE.

Rationale: OE.IT_REMOTE supports the assumption by levying a requirement

in the environment that connections between trusted systems or
physically separated parts of the TOE are sufficiently protected
from any attack that may cause those functions to provide false
results.
OE.INFO_PROTECT supports the assumption by requiring that All
network and peripheral cabling must be approved for the
transmittal of the most sensitive data transmitted over the link.
Such physical links are assumed to be adequately protected against
threats to the confidentiality and integrity of the data transmitted
using appropriate physical and logical protection techniques.
OE.IT_TRUSTED_SYSTEM supports the assumption by ensuring that
remote trusted IT systems implement the protocols and
mechanisms required by the TSF to support the enforcement of the
security policy.
OE.PHYSICAL supports the assumption by ensuring that
appropriate physical security is provided within the domain.

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 33 of 66

 Oracle Database 12c Enterprise Edition
Security Target

5 EXTENDED COMPONENTS DEFINITION

This section specifies the extended Security Functional Requirements (SFRs)
used in this ST and defined in the PP. Two extended SFRs have been created to
address additional security features of the TOE. The SFRs and the rationale for
their inclusion are as follows:
a. Enhanced user-subject binding (FIA_USB_(EXT).2)
A DBMS may derive subject security attributes from other TSF data that
are not directly user security attributes. An example is the point-of-entry
the user has used to establish the connection. An access control policy
may also use this subject security attribute within its access control
policy, allowing access to critical objects only when the user has
connected through specific ports-of-entry; and
b. TOE access information (FTA_TAH_(EXT).1)
The DBMS PP does not require the TOE to contain a client. Therefore, the
PP cannot require the client to display a message. This requirement has
been modified to require the TOE to store and retrieve the access history
instead of displaying it.

5.1 FIA_USB USER-SUBJECT BINDING

Family Behaviour
An authenticated user, in order to use the TOE, typically activates a subject. The
user's security attributes are associated (totally or partially) with this subject.
This family defines requirements to create and maintain the association of the
user's security attributes to a subject acting on the user's behalf.
FIA_USB_(EXT).2 is an extended SFR modelled after FIA_USB.1 and added to
this existing family.
Component Levelling
FIA_USB_(EXT).2 is hierarchical to FIA_USB.1.

FIA_USB: User-subject binding 1 EXT.2

Figure 2 – FIA_USB_(EXT): User-subject binding Component Levelling

Management: FIA_USB_(EXT).2
The following actions could be considered for the management functions in FMT:

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 34 of 66

 Oracle Database 12c Enterprise Edition
Security Target

a. an authorized administrator can define default subject security attributes.

b. an authorized administrator can change subject security attributes.
Audit: FIA_USB_(EXT).2
The following actions should be auditable if FAU_GEN Security audit data
generation is included in the PP/ST:
a. Minimal: Unsuccessful binding of user security attributes to a subject (e.g.
creation of a subject).
b. Basic: Success and failure of binding of user security attributes to a
subject (e.g. success or failure to create a subject).
FIA_USB_(EXT).2 Enhanced user-subject binding
Hierarchical to: FIA_USB.1
Dependencies: FIA_ATD.1 User attribute definition
FIA_USB_(EXT).2.1 The TSF shall associate the following user security attributes with
subjects acting on the behalf of that user: [assignment: list of user
security attributes].
FIA_USB_(EXT).2.2 The TSF shall enforce the following rules on the initial association
of user security attributes with subjects acting on the behalf of
users: [assignment: rules for the initial association of attributes].
FIA_USB_(EXT).2.3 The TSF shall enforce the following rules governing changes to the
user security attributes associated with subjects acting on the
behalf of users: [assignment: rules for the changing of attributes].
FIA_USB_(EXT).2.4 The TSF shall enforce the following rules for the assignment of
subject security attributes not derived from user security attributes
when a subject is created: [assignment: rules for the initial
association of the subject security attributes not derived from user
security attributes].

5.2 FTA_TAH TOE ACCESS HISTORY

Family Behaviour
This family defines requirements for the TSF to display to a user, upon
successful session establishment, a history of successful and unsuccessful
attempts to access the user's account.
FTA_TAH_(EXT).1 is an extended SFR modelled after FTA_TAH.1 and added to
this existing family.
Component Levelling
FTA_TAH_(EXT).1 is not hierarchical to any other components.

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 35 of 66

 Oracle Database 12c Enterprise Edition
Security Target

FTA_TAH: TOE Access History

EXT.1

Figure 3 – FTA_TAH_(EXT): TOE Access History Component Levelling

Management: FTA_TAH_(EXT).1
There are no management activities foreseen.
Audit: FTA_TAH_(EXT).1
There are no auditable events foreseen.
FTA_TAH_(EXT).1 TOE access information
Hierarchical to: No other components.
Dependencies: No dependencies
FTA_TAH_(EXT).1.1 Upon a session establishment attempt, the TSF shall store

a. the [date and time] of the session establishment attempt of the

user.
b. the incremental count of successive unsuccessful session
establishment attempt(s).
FTA_TAH_(EXT).1.2 Upon successful session establishment, the TSF shall allow the
[date and time] of
a. the previous last successful session establishment, and
b. the last unsuccessful attempt to session establishment and the
number of unsuccessful attempts since the previous last
successful session establishment to be retrieved by the user.

5.3 SECURITY ASSURANCE REQUIREMENTS

This ST does not include extended Security Assurance Requirements.

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 36 of 66

 Oracle Database 12c Enterprise Edition
Security Target

6 SECURITY REQUIREMENTS
Section 6 provides security functional and assurance requirements that must be
satisfied by a compliant TOE. These requirements consist of functional
components from Part 2 of the CC, extended requirements, and an Evaluation
Assurance Level (EAL) that contains assurance components from Part 3 of the
CC.

6.1 CONVENTIONS
The CC permits four types of operations to be performed on functional
requirements: selection, assignment, refinement, and iteration. These
operations, when performed on requirements that derive from CC Part 2 are
identified in this ST in the following manner:
• Selection: Indicated by surrounding brackets, e.g., [selected item].
• Assignment: Indicated by surrounding brackets and italics, e.g., [assigned
item].
• Refinement: Refined components are identified by using bold for
additional information, or strikeout for deleted text.
• Iteration: Indicated by assigning a number in parenthesis to the end of
the functional component identifier as well as by modifying the functional
component title to distinguish between iterations, e.g., ‘FDP_ACC.1(1),
Subset access control (administrators)’ and ‘FDP_ACC.1(2) Subset access
control (devices)’.

6.2 TOE SECURITY FUNCTIONAL REQUIREMENTS

The security functional requirements for this ST consist of the following
components from Part 2 of the CC and extended components defined in Section
5, summarized in Table 10 - Summary of Security Functional Requirements.

Class Identifier Name

Security Audit (FAU) FAU_GEN.1 Audit data generation

FAU_GEN.2 User identity association

FAU_SEL.1 Selective audit

User Data Protection FDP_ACC.1 Subset access control

(FDP)
FDP_ACF.1 Security attribute based access
control

FDP_RIP.1 Subset residual information protection

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 37 of 66

 Oracle Database 12c Enterprise Edition
Security Target

Class Identifier Name

Identification and FIA_ATD.1 User attribute definition

Authentication (FIA)
FIA_UAU.1 Timing of authentication

FIA_UID.1 Timing of identification

FIA_USB_(EXT).2 Enhanced user-subject binding

Security Management FMT_MOF.1 Management of security functions

(FMT) behaviour

FMT_MSA.1 Management of security attributes

FMT_MSA.3 Static attribute initialisation

FMT_MTD.1 Management of TSF data

FMT_REV.1(1) Revocation (user attributes)

FMT_REV.1(2) Revocation (subject, object attributes)

FMT_SMF.1 Specification of management

functions

FMT_SMR.1 Security roles

Protection of the TSF FPT_TRC.1 Internal TSF consistency

(FPT)

TOE Access (FTA) FTA_MCS.1 Basic limitation on multiple concurrent

sessions

FTA_TAH_(EXT).1 TOE access information

FTA_TSE.1 TOE session establishment

Table 10 – Summary of Security Functional Requirements

6.2.1 Security Audit (FAU)

6.2.1.1 FAU_GEN.1 Audit data generation
Hierarchical to: No other components.
Dependencies: FPT_STM.1 Reliable time stamps
FAU_GEN.1.1 The TSF shall be able to generate an audit record of the following
auditable events:
a) Start-up and shutdown of the audit functions;

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 38 of 66

 Oracle Database 12c Enterprise Edition
Security Target

b) All auditable events for the [minimum] level of audit listed in Table
11: Auditable Events; 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]].
FAU_GEN.1.2 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 three of Table 11: Auditable Events, below].

Column 1: Column 2: Column 3:

Security Functional Auditable Event(s) Additional Audit Record
Requirement Contents

FAU_GEN.1 None None

FAU_GEN.2 None None

FAU_SEL.1 All modifications to the audit The identity of the authorized

configuration that occur while administrator that made the
the audit collection functions change to the audit
are operating configuration

FDP_ACC.1 None None

FDP_ACF.1 Successful requests to The identity of the subject

perform an operation on an performing the operation
object covered by the SFP

FDP_RIP.1 None None

FIA_ATD.1 None None

FIA_UAU.1 Unsuccessful use of the None

authentication mechanism

FIA_UID.1 Unsuccessful use of the user None

identification mechanism,
including the user identity
provided

FIA_USB_(EXT).2 Unsuccessful binding of user None

security attributes to a
subject (e.g. creation of a
subject)

FMT_MOF.1 None None

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 39 of 66

 Oracle Database 12c Enterprise Edition
Security Target

Column 1: Column 2: Column 3:

Security Functional Auditable Event(s) Additional Audit Record
Requirement Contents

FMT_MSA.1 None None

FMT_MSA.3 None None

FMT_MTD.1 None None

FMT_REV.1(1) Unsuccessful revocation of Identity of individual

security attributes attempting to revoke security
attributes

FMT_REV.1(2) Unsuccessful revocation of Identity of individual

security attributes attempting to revoke security
attributes

FMT_SMF.1 Use of the management Identity of the administrator

functions performing these functions

FMT_SMR.1 Modifications to the group of Identity of authorized

users that are part of a role administrator modifying the
role definition

FPT_TRC.1 Restoring consistency None

FTA_MCS.1 Rejection of a new session None

based on the limitation of
multiple concurrent sessions

FTA_TAH_(EXT).1 None None

FTA_TSE.1 Denial of a session Identity of the individual

establishment due to the attempting to establish a
session establishment session
mechanism

Table 11 – Auditable Events

6.2.1.2 FAU_GEN.2 User identity association

Hierarchical to: No other components.
Dependencies: FAU_GEN.1 Audit data generation
FIA_UID.1 Timing of identification
FAU_GEN.2.1 For audit events resulting from actions of identified users and any
identified groups, the TSF shall be able to associate each auditable
event with the identity of the [user] that caused the event.

6.2.1.3 FAU_SEL.1 Selective audit

Hierarchical to: No other components.
Dependencies: FAU_GEN.1 Audit data generation
FMT_MTD.1 Management of TSF data

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 40 of 66

 Oracle Database 12c Enterprise Edition
Security Target

FAU_SEL.1.1 The TSF shall be able to select the set of events to be audited from
the set of all auditable events based on the following attributes:
a) [object identity,
b) user identity,
c) [no other identities];
d) event type;]
e) [success of auditable security events;
f) failure of auditable security events; and
g) [[no additional attributes]].]
Application Note: The audit functionality may be configured to audit specified operations.
‘Event type’ is defined to be these specified operations for the purposes of FAU_SEL.1.

6.2.2 User Data Protection (FDP)

6.2.2.1 FDP_ACC.1 Subset access control
Hierarchical to: No other components.
Dependencies: FDP_ACF.1 Security attribute based access control
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].

6.2.2.2 FDP_ACF.1 Security attribute based access control

Hierarchical to: No other components.
Dependencies: FDP_ACC.1 Subset access control
FMT_MSA.3 Static attribute initialisation
FDP_ACF.1.1 The TSF shall enforce the [Discretionary Access Control Policy] to
objects based on the following: [
Subjects: Database Users
Subject attributes: database role, system privileges
Objects: Database object
Object attributes: object privileges, any attribute].
FDP_ACF.1.2 The TSF shall enforce the following rules to determine if an operation
among controlled subjects and controlled objects is allowed: [A user may
access an object if:
a. the user is the owner of the object or has been granted specific
object privileges;
b. the user has been granted specific system privileges allowing access
to the object;
c. the user is a member of a role that has been granted specific object
and/or system privileges;
d. a policy allows the user access based on the value of a specified
attribute;
e. the object is accessible by 'PUBLIC'.].
FDP_ACF.1.3 The TSF shall explicitly authorise access of subjects to objects based on
the following additional rules: [no additional rules].
FDP_ACF.1.4 The TSF shall explicitly deny access of subjects to objects based on
the following additional rules: [no additional rules].

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 41 of 66

 Oracle Database 12c Enterprise Edition
Security Target

Application Note: A database object is an object in the database that may be manipulated
with SQL. These include tables, cases, files, and views.
Application Note: ‘PUBLIC’ is a special role granted to all users.

6.2.2.3 FDP_RIP.1 Subset residual information protection

Hierarchical to: No other components.
Dependencies: No dependencies.
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]
the following objects: [table, row].

6.2.3 Identification and Authentication (FIA)

6.2.3.1 FIA_ATD.1 User attribute definition
Hierarchical to: No other components.
Dependencies: No dependencies.
FIA_ATD.1.1 The TSF shall maintain the following list of security attributes belonging
to individual users:
a) [Database user identifier and any associated group memberships;
b) Security-relevant database roles; and
c) [object privileges, system privileges, any attribute]].
Application Note: The intent of this requirement, as described in the DBMS PP, is to specify
the TOE security attributes that the TOE utilizes to determine access. However, it should be
noted that the object privileges, system privileges and attributes, although used in the access
control decision, are not specifically associated with individual users.

6.2.3.2 FIA_UAU.1 Timing of authentication

Hierarchical to: No other components.
Dependencies: FIA_UID.1 Timing of identification
FIA_UAU.1.1 The TSF shall allow [no TSF mediated actions] on behalf of the user to
be performed before the user is authenticated.
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.

6.2.3.3 FIA_UID.1 Timing of identification

Hierarchical to: No other components.
Dependencies: No dependencies.
FIA_UID.1.1 The TSF shall allow [no TSF mediated actions] on behalf of the user to
be performed before the user is identified.
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.

6.2.3.4 FIA_USB_(EXT).2 Enhanced user-subject binding

Hierarchical to: FIA_USB.1 User-subject binding
Dependencies: FIA_ATD.1 User attribute definition

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 42 of 66

 Oracle Database 12c Enterprise Edition
Security Target

FIA_USB_(EXT).2.1 The TSF shall associate the following user security attributes with
subjects acting on the behalf of that user: [Database user
identifier, roles, privileges].
FIA_USB_(EXT).2.2 The TSF shall enforce the following rules on the initial association
of user security attributes with subjects acting on the behalf of
users: [an authorized administrator may allow a proxy user to
perform database operations on behalf on another user].
FIA_USB_(EXT).2.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. granting and revoking of directly assigned privileges are
effective immediately;
b. granting and revoking of indirectly assigned privileges are
effective at the next log in].
FIA_USB_(EXT).2.4 The TSF shall enforce the following rules for the assignment of
subject security attributes not derived from user security attributes
when a subject is created: [the proxy may be limited to the
privileges of a particular role when acting on behalf of another
user].

6.2.4 Security Management (FMT)

6.2.4.1 FMT_MOF.1 Management of security functions behaviour
Hierarchical to: No other components.
Dependencies: FMT_SMR.1 Security roles
FMT_SMF.1 Specification of management functions
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 [authorised
administrators].

6.2.4.2 FMT_MSA.1 Management of security attributes

Hierarchical to: No other components.
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
FMT_SMR.1 Security roles
FMT_SMF.1 Specification of management functions
FMT_MSA.1.1 The TSF shall enforce the [Discretionary Access Control Policy] to
restrict the ability to [[manage]] [all] the security attributes to
[authorised administrators].
Application Note: The security attribute assignment has been moved to enhance readability,
and for consistency with the PP.

6.2.4.3 FMT_MSA.3 Static attribute initialisation

Hierarchical to: No other components.
Dependencies: FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 43 of 66

 Oracle Database 12c Enterprise Edition
Security Target

FMT_MSA.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.
FMT_MSA.3.2 The TSF shall allow the [no user] to specify alternative initial values to
override the default values when an object or information is created.

6.2.4.4 FMT_MTD.1 Management of TSF data

Hierarchical to: No other components.
Dependencies: FMT_SMR.1 Security roles
FMT_SMF.1 Specification of management functions
FMT_MTD.1.1 The TSF shall restrict the ability to [[include or exclude]] the [auditable
events] to [authorized administrators].

6.2.4.5 FMT_REV.1(1) Revocation

Hierarchical to: No other components.
Dependencies: FMT_SMR.1 Security roles
FMT_REV.1(1).1 The TSF shall restrict the ability to revoke [system privileges, roles]
associated with the [users] under the control of the TSF to [the
authorised administrator].
FMT_REV.1(1).2 The TSF shall enforce the rules [
a. granting and revoking of directly assigned privileges are effective
immediately; and
b. granting and revoking of indirectly assigned privileges are effective
at the next log in].

6.2.4.6 FMT_REV.1(2) Revocation

Hierarchical to: No other components.
Dependencies: FMT_SMR.1 Security roles
FMT_REV.1(2).1 The TSF shall restrict the ability to revoke [object privileges]
associated with the [objects] under the control of the TSF to [the
authorized administrator and database users with sufficient privileges
as allowed by the Discretionary Access Control Policy].
FMT_REV.1(2).2 The TSF shall enforce the rules [
a. authorized administrators and object owners may revoke object
privileges; and
b. object owners may grant other users privileges to grant and
revoke object privileges].

6.2.4.7 FMT_SMF.1 Specification of Management Functions

Hierarchical to: No other components.
Dependencies: No dependencies.
FMT_SMF.1.1 The TSF shall be capable of performing the following management
functions: [
a. management of the events to be audited;
b. granting or revoking of system privileges;

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 44 of 66

 Oracle Database 12c Enterprise Edition
Security Target

c. granting or revoking of object privileges;

d. changes to user accounts (including authentication) and roles;
e. configuration of Active Data Guard replication options;
f. configuration of the maximum number of concurrent sessions for an
individual user; and
g. configuration of logon triggers].

6.2.4.8 FMT_SMR.1 Security roles

Hierarchical to: No other components.
Dependencies: FIA_UID.1 Timing of identification
FMT_SMR.1.1 The TSF shall maintain the roles [authorized administrator, database
user and other roles defined by authorized administrators].
FMT_SMR.1.2 The TSF shall be able to associate users with roles.

6.2.5 Protection of the TSF (FPT)

6.2.5.1 FPT_TRC.1 Internal TSF consistency
Hierarchical to: No other components.
Dependencies: FPT_ITT.1 Basic internal TSF data transfer
protection
FPT_TRC.1.1 The TSF shall ensure that TSF data is consistent when replicated
between parts of the TOE.
FPT_TRC.1.2 When parts of the TOE containing replicated TSF data are
disconnected, the TSF shall ensure the consistency of the replicated TSF
data upon reconnection before processing any requests for [queries].

6.2.6 TOE Access (FTA)

6.2.6.1 FTA_MCS.1 Basic limitation on multiple concurrent
sessions
Hierarchical to: No other components.
Dependencies: FIA_UID.1 Timing of identification
FTA_MCS.1.1 The TSF shall restrict the maximum number of concurrent sessions that
belong to the same user.
FTA_MCS.1.2 The TSF shall enforce, by default, a limit of [an administrator
configurable number of] sessions per user.

6.2.6.2 FTA_TAH_(EXT).1 TOE access information

Hierarchical to: No other components.
Dependencies: No dependencies.
FTA_TAH_(EXT).1.1 Upon a session establishment attempt, the TSF shall store

a. the [date and time] of the session establishment attempt of

the user.

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 45 of 66

 Oracle Database 12c Enterprise Edition
Security Target

b. the incremental count of successive unsuccessful session

establishment attempt(s).
FTA_TAH_(EXT).1.2 Upon successful session establishment, the TSF shall allow the
[date and time] of
a. the previous last successful session establishment, and
b. the last unsuccessful attempt to session establishment and the
number of unsuccessful attempts since the previous last
successful session establishment to be retrieved by the user.

6.2.6.3 FTA_TSE.1 TOE session establishment

Hierarchical to: No other components.
Dependencies: No dependencies.
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, time of day, day of the week], and [[no additional attributes]]].

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 46 of 66

 Oracle Database 12c Enterprise Edition
Security Target

6.3 SECURITY FUNCTIONAL REQUIREMENTS

RATIONALE
The following Table provides a mapping between the SFRs and Security
Objectives.

O.DISCRETIONARY_ACCESS

O.RESIDUAL_INFORMATION
O.AUDIT_GENERATION
O.ACCESS_HISTORY

O.ADMIN_ROLE

O.TOE_ACCESS
O.MEDIATE
O.MANAGE
FAU_GEN.1 X O.I&A

FAU_GEN.2 X

FAU_SEL.1 X

FDP_ACC.1 X X X

FDP_ACF.1 X X X

FDP_RIP.1 X

FIA_ATD.1 X X

FIA_UAU.1 X

FIA_UID.1 X

FIA_USB_(EXT).2 X

FMT_MOF.1 X

FMT_MSA.1 X

FMT_MSA.3 X

FMT_MTD.1 X

FMT_REV.1(1) X

FMT_REV.1(2) X

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 47 of 66

 Oracle Database 12c Enterprise Edition
Security Target

O.DISCRETIONARY_ACCESS

O.RESIDUAL_INFORMATION
O.AUDIT_GENERATION
O.ACCESS_HISTORY

O.ADMIN_ROLE

O.TOE_ACCESS
O.MEDIATE
O.MANAGE
O.I&A
FMT_SMF.1 X

FMT_SMR.1 X X

FPT_TRC.1 X

FTA_MCS.1 X

FTA_TAH_(EXT).1 X

FTA_TSE.1 X

Table 12 – Mapping of SFRs to Security Objectives

6.3.1 SFR Rationale Related to Security Objectives

The following rationale traces each SFR back to the Security Objectives for the
TOE.

Objective: The TOE will store information related to previous attempts to

establish a session and make that information available to the user.
O.ACCESS
_HISTORY

Security FTA_TAH_(EXT).1 TOE access information

Functional
Requirements:

Rationale: The TOE must be able to store and retrieve information about
previous unauthorized login attempts and the number of times the
login was attempted every time the user logs into their account.
The TOE must also store the last successful authorized login. This
information will include the date, time, method, and location of the
attempts. When appropriately displayed, this will allow the user to
detect if another user is attempting to access their account. These
records should not be deleted until after the user has been notified
of their access history. [FTA_TAH_(EXT).1]

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 48 of 66

 Oracle Database 12c Enterprise Edition
Security Target

Objective: The TOE will provide a mechanism (e.g. a "role") by which the
actions using administrative privileges may be restricted.
O.ADMIN_ROLE

Security FMT_SMR.1 Security roles

Functional
Requirements:

Rationale: The TOE will establish, at least, an authorized administrator role.

The ST writer may choose to specify more roles. The authorized
administrator will be given privileges to perform certain tasks that
other users will not be able to perform. These privileges include,
but are not limited to, access to audit information and security
functions. [FMT_SMR.1]

Objective: The TSF must be able to record defined security-relevant events

(which usually include security-critical actions of users of the TOE).
O.AUDIT The information recorded for security-relevant events must contain
_GENERATION the time and date the event happened and, if possible, the
identification of the user that caused the event, and must be in
sufficient detail to help the authorized user detect attempted
security violations or potential misconfiguration of the TOE security
features that would leave the IT assets open to compromise.

Security FAU_GEN.1 Audit data generation

Functional
Requirements: FAU_GEN.2 User identity association

FAU_SEL.1 Selective audit

Rationale: FAU_GEN.1 defines the set of events that the TOE must be capable
of recording. This requirement ensures that the administrator has
the ability to audit any security relevant events that takes place in
the TOE. This requirement also defines the information that must
be contained in the audit record for each auditable event. This
requirement also places a requirement on the level of detail that is
recorded on any additional security functional requirements a ST
author adds to the ST. [FAU_GEN.1]
FAU_GEN.2 ensures that the audit records associate a user and any
associated group identity with the auditable event. In the case of
authorized users, the association is accomplished with the user ID.
In the case of authorized groups, the association is accomplished
with the group ID. [FAU_GEN.2]
FAU_SEL.1 allows the administrator to configure which auditable
events will be recorded in the audit trail. This provides the
administrator with the flexibility in recording only those events that
are deemed necessary by site policy, thus reducing the amount of
resources consumed by the audit mechanism. [FAU_SEL.1]

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 49 of 66

 Oracle Database 12c Enterprise Edition
Security Target

Objective: The TSF must control access of subjects and/or users to named
resources based on identity of the object, subject, or user. The TSF
O.DISCRETION must allow authorized users to specify for each access mode which
-ARY_ACCESS users/subjects are allowed to access a specific named object in that
access mode.

Security FDP_ACC.1 Subset access control

Functional
Requirements: FDP_ACF.1 Security attribute based access control

Rationale: The TSF must control access to resources based on the identity of
users that are allowed to specify which resources they want to
access for storing their data.
The access control policy must have a defined scope of control
[FDP_ACC.1]. The rules for the access control policy are defined
[FDP_ACF.1].

Objective: The TOE ensures that users are authenticated before the TOE
processes any actions that require authentication.
O.I&A

Security FIA_ATD.1 User attribute definition

Functional
Requirements: FIA_UAU.1 Timing of authentication

FIA_UID.1 Timing of identification

FIA_USB_(EXT).2 Enhanced user-subject binding

Rationale: The TSF must ensure that only authorized users gain access to the
TOE and its resources. Users authorized to access the TOE must
use an identification and authentication process [FIA_UID.1,
FIA_UAU.1].
To ensure that the security attributes used to determine access are
defined and available to the support authentication decisions.
[FIA_ATD.1].
Proper authorization for subjects acting on behalf of users is also
ensured [FIA_USB_(EXT).2]. The appropriate strength of the
authentication mechanism is ensured.

Objective: The TSF must provide all the functions and facilities necessary to
support the authorized users that are responsible for the
O.MANAGE management of TOE security mechanisms, must allow restricting
such management actions to dedicated users, and must ensure
that only such authorized users are able to access management
functionality.

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 50 of 66

 Oracle Database 12c Enterprise Edition
Security Target

Security FMT_MOF.1 Management of security functions behaviour

Functional
Requirements: FMT_MSA.1 Management of security attributes

FMT_MSA.3 Static attribute initialisation

FMT_MTD.1 Management of TSF data

FMT_REV.1(1) Revocation (user attributes)

FMT_REV.1(2) Revocation (subject, object attributes)

FMT_SMF.1 Specification of management functions

FMT_SMR.1 Security roles

Rationale: FMT_MOF.1 requires that the ability to use particular TOE

capabilities be restricted to the administrator. [FMT_MOF.1]
FMT_MSA.1 requires that the ability to perform operations on
security attributes be restricted to particular roles. [FMT_MSA.1]
FMT_MSA.3 requires that default values used for security attributes
are restrictive. [FMT_MSA.3]
FMT_MTD.1 requires that the ability to manipulate TOE content is
restricted to administrators. [FMT_MTD.1]
FMT_REV.1 restricts the ability to revoke attributes to the
administrator. [FMT_REV.1(1), FMT_REV.1(2)]
FMT_SMF.1 identifies the management functions that are available
to the authorized administrator. [FMT_SMF.1]
FMT_SMR.1 defines the specific security roles to be supported.
[FMT_SMR.1]

Objective: The TOE must protect user data in accordance with its security
policy, and must mediate all requests to access such data.
O.MEDIATE

Security FDP_ACC.1 Subset access control

Functional
Requirements: FDP_ACF.1 Security attribute based access control

FPT_TRC.1 Internal TSF consistency

Rationale: The FDP requirements were chosen to define the policies, the
subjects, objects, and operations for how and when mediation
takes place in the TOE.
FDP_ACC.1 defines the Access Control policy that will be enforced
on a list of subjects acting on the behalf of users attempting to gain
access to a list of named objects. All the operations between

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 51 of 66

 Oracle Database 12c Enterprise Edition
Security Target

subject and object covered are defined by the TOE's policy.

[FDP_ACC.1]
FDP_ACF.1 defines the security attribute used to provide access
control to objects based on the TOE's access control policy.
[FDP_ACF.1]
FPT_TRC.1 ensures replicated TSF data that specifies attributes for
access control must be consistent across distributed components of
the TOE. The requirement is to maintain consistency of replicated
TSF data. [FPT_TRC.1]

Objective: The TOE will ensure that any information contained in a protected
resource within its Scope of Control is not inappropriately
O.RESIDUAL disclosed when the resource is reallocated.
_INFORMATION

Security FDP_RIP.1 Subset residual information protection

Functional
Requirements:

Rationale: FDP_RIP.1 is used to ensure the contents of resources are not

available to subjects other than those explicitly granted access to
the data. [FDP_RIP.1]

Objective: The TOE will provide mechanisms that control a user's logical
access to user data and to the TSF.
O.TOE_ACCESS

Security FDP_ACC.1 Subset access control

Functional
Requirements: FDP_ACF.1 Security attribute based access control

FIA_ATD.1 User attribute definition

FTA_MCS.1 Basic limitation on multiple concurrent

sessions

FTA_TSE.1 TOE session establishment

Rationale: FDP_ACC.1 requires that each identified access control SFP be in

place for a subset of the possible operations on a subset of the
objects in the TOE. [FDP_ACC.1]
FDP_ACF.1 allows the TSF to enforce access based upon security
attributes and named groups of attributes. Furthermore, the TSF
may have the ability to explicitly authorize or deny access to an
object based upon security attributes. [FDP_ACF.1]
FIA_ATD.1 defines the security attributes for individual users
including the user's identifier and any associated group
memberships. Security relevant roles and other identity security

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 52 of 66

 Oracle Database 12c Enterprise Edition
Security Target

attributes. [FIA_ATD.1]
FTA_MCS.1 ensures that users may only have a maximum of a
specified number of active sessions open at any given time.
[FTA_MCS.1]
FTA_TSE.1 allows the TOE to restrict access to the TOE based on
certain criteria. [FTA_TSE.1]

6.4 DEPENDENCY RATIONALE

Table 13 identifies the Security Functional Requirements from Part 2 of the CC
and their associated dependencies. It also indicates whether the ST explicitly
addresses each dependency.

SFR Dependency Rationale

FAU_GEN.1 FPT_STM.1 This requirement is satisfied by the assumption

on the IT environment, given in A.SUPPORT.

FAU_GEN.2 FAU_GEN.1 satisfied by FAU_GEN.1

FIA_UID.1 satisfied by FIA_UID.1

FAU_SEL.1 FAU_GEN.1 satisfied by FAU_GEN.1

FAU_MTD.1 satisfied by FAU_MTD.1

FDP_ACC.1 FDP_ACF.1 satisfied by FDP_ACF.1

FDP_ACF.1 FDP_ACC.1 satisfied by FDP_ACC.1

FMT_MSA.3 satisfied by FMT_MSA.3

FDP_RIP.1 None N/A

FIA_ATD.1 None N/A

FIA_UAU.1 FIA_UID.1 satisfied by FIA_UID.1

FIA_UID.1 None N/A

FIA_USB_(EXT).2 FIA_ATD.1 satisfied by FIA_ATD.1

FMT_MOF.1 FMT_SMR.1 satisfied by FMT_SMR.1

FMT_SMF.1 satisfied by FMT_SMF.1

FMT_MSA.1 FDP_ACC.1 or satisfied by FDP_ACC.1

FDP_IFC.1

FMT_SMR.1 satisfied by FMT_SMR.1

FMT_SMF.1 satisfied by FMT_SMF.1

FMT_MSA.3 FMT_MSA.1 satisfied by FMT_MSA.1

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 53 of 66

 Oracle Database 12c Enterprise Edition
Security Target

SFR Dependency Rationale

FMT_SMR.1 satisfied by FMT_SMR.1

FMT_MTD.1 FMT_SMR.1 satisfied by FMT_SMR.1

FMT_SMF.1 satisfied by FMT_SMF.1

FMT_REV.1(1) FMT_SMR.1 satisfied by FMT_SMR.1

FMT_REV.1(2) FMT_SMR.1 satisfied by FMT_SMR.1

FMT_SMF.1 None N/A

FMT_SMR.1 FIA_UID.1 satisfied by FIA_UID.1

FPT_TRC.1 FPT_ITT.1 FPT_ITT.1 is not applicable. For a distributed

TOE, the dependency is satisfied through the
assumption on the environment, A.CONNECT,
that assures the confidentiality and integrity of
the transmitted data.

FTA_MCS.1 FIA_UID.1 satisfied by FIA_UID.1

FTA_TAH_(EXT).1 None N/A

FTA_TSE.1 None N/A

Table 13 – Functional Requirement Dependencies

6.5 TOE SECURITY ASSURANCE REQUIREMENTS

The TOE assurance requirements for this ST consist of the requirements
corresponding to the EAL 2 level of assurance, as defined in the CC Part 3,
augmented by the inclusion of Flaw reporting procedures (ALC_FLR.2). This is
the assurance level described in the claimed PP.

6.5.1 Security Assurance Requirements Rationale

The DBMS PP was developed for use by commercial DBMS security software
developers. Since the PP will be applied to commercial DBMS products that are
used internationally the EAL 2 assurance package was selected by the PP writers
to meet the maximum level of assurance that is recognized internationally
through the Common Criteria Recognition Arrangement (CCRA).
Flaw Remediation is the only requirement not included in any EAL level because
it does not add any assurance to the current system, but to subsequent
releases. Therefore, the DBMS WG/TC decided to augment EAL2 with ALC_FLR.2
to instruct the vendors on proper flaw remediation techniques.
The dependencies for security assurance requirements are all fulfilled based on
the following facts:

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 54 of 66

 Oracle Database 12c Enterprise Edition
Security Target

• EAL2 is completely self-sufficient with all dependencies being fulfilled with

the package of EAL2.
• The security assurance requirement of ALC_FLR.2, which is in addition to
EAL2, does not have any dependencies.
The assurance requirements are summarized in the Table 14.

Assurance Components
Assurance Class
Identifier Name

Development ADV_ARC.1 Security architecture description

Security-enforcing functional
ADV_FSP.2
specification

ADV_TDS.1 Basic design

Guidance Documents AGD_OPE.1 Operational user guidance

AGD_PRE.1 Preparative procedures

Life-cycle support ALC_CMC.2 Use of a CM 2 system

ALC_CMS.2 Parts of the TOE CM coverage

ALC_DEL.1 Delivery procedures

ALC_FLR.2 Flaw reporting procedures

Security Target ASE_CCL.1 Conformance claims

Evaluation
ASE_ECD.1 Extended components definition

ASE_INT.1 ST introduction

ASE_OBJ.2 Security objectives

ASE_REQ.2 Derived security requirements

ASE_SPD.1 Security problem definition

ASE_TSS.1 TOE summary specification

Tests ATE_COV.1 Evidence of coverage

2
Configuration Management

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 55 of 66

 Oracle Database 12c Enterprise Edition
Security Target

Assurance Components
Assurance Class
Identifier Name

ATE_FUN.1 Functional testing

ATE_IND.2 Independent testing - sample

Vulnerability
AVA_VAN.2 Vulnerability analysis
Assessment

Table 14 – Security Assurance Requirements

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 56 of 66

 Oracle Database 12c Enterprise Edition
Security Target

7 TOE SUMMARY SPECIFICATION

This section provides a description of the security functions and assurance
measures of the TOE that meet the TOE security requirements.

7.1 TOE SECURITY FUNCTIONS

A description of each of the TOE security functions follows.

7.1.1 Security Audit

Oracle Database 12c supports two auditing mechanisms: traditional auditing and
unified auditing. For the purposes of meeting the auditing requirements of the
DBMS PP, either method, or a combination of both methods may be used.
The AUDIT statement is used to track the issuance of specific SQL statements,
or all SQL statements authorized by a particular system privilege. It may also
be used to track operations on a specific schema object. The AUDIT_TRAIL
system parameter may be used to determine the format and location of the
audit entries. Entries for start-up and shutdown events are sent to the operating
system for logging.
Audit policies may be created (using the CREATE AUDIT POLICY statement) to
determine exactly which events are audited, based on numerous criteria
including use of particular roles or privileges. Each record includes the date and
time of the event (EVENT_TIMESTAMP), type of event (ACTION_NAME), subject
identity (DBUSERNAME, if applicable), and outcome (RETURN_CODE).
The policies required to capture the auditable events detailed in Column 2 of
Table 11 are generally established through the Audit policy. However, the
following details should be noted:
a. For the auditing requirements of FPT_TRC.1, restoring consistency, the
actions are recorded on the primary database. The secondary database is
an exact replica of the primary and therefore does not include platform
specific audit records;
b. For the auditing requirements for FTA_MCS.1, rejection of a new session
based on the limitation of multiple concurrent sessions, the audit record
appears as a failed login. However, the error code indicates the reason
for failure (SESSION_PER_USER); and
c. For the auditing requirements of FTA_TSE.1, denial of a session
establishment due to the session establishment mechanism, it should be
noted that this functionality must be set up using a logon trigger and a
custom table. Therefore, the audit records for denial events are
contained in this custom table, and not the location specified for the other
records.
TOE Security Functional Requirements addressed: FAU_GEN.1, FAU_GEN.2,
FAU_SEL.1.

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 57 of 66

 Oracle Database 12c Enterprise Edition
Security Target

7.1.2 User Data Protection

FDP_ACC.1 and FDP_ACF.1 are used to describe how database users are
granted access to database objects. Database objects are defined as any object
in the database that may be manipulated with SQL. This includes, but is not
limited to tables, rows, columns, cases, files, and views.
Access may be granted in one of several ways:
a. An object privilege is a system-defined privilege that controls access to a
specific object. A database user has access to an object if the user is the
owner of the object. In this case, the user has object privileges for the
object. Object privileges may be granted to other users, as well. These
privileges may be limited to certain operations. For example, the owner
may be able to perform any operation (e.g. read, write, etc.), but another
user may have read only access to the object;
b. A system privilege may be granted to or revoked from a user by an
administrator. These privileges allow users to perform specific database
operations. For example, a user with the CREATE TABLE system privilege
may create a table within that user’s schema;
c. A role is a collection of privileges and other roles. Some system-defined
roles exist, but most are created by administrators to provide the least
privilege required to perform the assigned tasks. Roles group together
privileges and other roles, which facilitates the granting of multiple
privileges and roles to users. Roles may be granted object privileges and
system privileges in much the same way that users may be granted these
privileges. A user in a role would have the ability to perform actions
permitted by the privileges;
d. Users may be granted access to objects based on any attribute. A policy
rule must be created to allow this access. For example, in a table of
human resources data, a user may be granted access to his or her own
information by creating a rule that provides access to a row in a table if
the database user account name matches a username field in that row;
and
e. An object privilege may grant access to users in the ‘PUBLIC’ role. The
PUBLIC role is a special role automatically provided to every database
account. By default, it has no privileges assigned to it, but it is granted
access to many objects. The PUBLIC role may not be granted or revoked
because the user account will always assume this role. Because all
database user accounts assume the PUBLIC role, it does not appear in
any list of roles.
Once a resource is allocated to a table, row or other database object, the
previous content of that resource is no longer available.
TOE Security Functional Requirements addressed: FDP_ACC.1, FDP_ACF.1,
FDP_RIP.1.

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 58 of 66

 Oracle Database 12c Enterprise Edition
Security Target

7.1.3 Identification and Authentication

To create a user, the administrator must provide a user account name and a
password, and limitations on the resources available to the user. These
limitations are in the form of defined tablespace and profile information. The
tablespace assignment limits the number of resources available to the user and
is measured in bytes. The profile associates the user with session limitations,
such as number of concurrent sessions allowed, and password parameters, such
as the number of failed login attempts allowed before the account is locked.
Users are granted privileges, such as the right to run a particular type of SQL
statement, or the right to access an object that belongs to another user. Roles
are created to group together privileges and other roles, making it easier to
grant multiple privileges to a new user. A role must first be created by
identifying the role, and then adding privileges. Once the role is defined, it may
be granted to a user.
In addition to granting object and system privileges to users through roles,
these privileges may also be granted to users individually.
Users may be granted access to database objects based on any attribute. When
configured, the policy appends a WHERE clause to queries to control access at
the row and column level. This could be used to allow users to query a human
resources table, but only see their own information, or only certain columns
associated with the employees who report to these users. This policy (and
therefore, this attribute) is not directly associated with the database user’s
account. Please note that these users must also have object or system privileges
to access the database objects. Attributes may be used to provide a more fine-
grained access control to data within accessible objects.
Oracle Database 12c ensures that users are identified and authenticated prior to
being allowed access to database objects or resources. Although several
authentication mechanisms are supported, only local username and password
authentication is examined for the purposes of this evaluation.
One database user may act with the privileges of another as a proxy user. To
enable this, the user must be granted permission to access the database
through a proxy. This grant operation may specify which roles (and therefore
which privileges) are enabled for this access. In this way, the proxy access may
be limited to a specific set of required privileges, rather than all of the primary
user’s privileges. This is typically used in cases where the proxy user is an
application server or middle tier entity.
When a directly assigned privilege is granted or revoked, this takes effect
immediately. This includes granting or revoking object privileges or system
privileges, or granting or revoking object or system privileges from a role. When
an indirectly assigned privilege is granted or revoked, this is effective at the
next login. This includes adding or removing a role from a user account.
TOE Security Functional Requirements addressed: FIA_ATD.1, FIA_UAU.1,
FIA_UID.1, FIA_USB_(EXT).2.

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 59 of 66

 Oracle Database 12c Enterprise Edition
Security Target

7.1.4 Security Management

An audit policy determines which events are to be audited. The privileges
required to specify this policy are only available to authorized administrators.
The access control decision for the Discretionary Access Control Policy is made
based on object privileges, system privileges, roles and any attribute. All of
these attributes may be managed by authorized administrators. Object
privileges and attributes may also be managed by their owners, or users to
whom the owner has granted that privilege. In this case, the owner or
delegated user is considered to be an authorized administrator of the object or
attribute. The default values for these attributes are restrictive. System
privileges, object privileges and roles must be specifically granted to users.
Attribute values do not permit access until a policy granting that access has
been created by an authorized administrator.
Only authorized administrators may revoke system privileges and roles.
Revocation of directly assigned system privileges (i.e. system privileges granted
directly to a user or a role) takes effect immediately. Revocation of a role from
a user account is effective at the next login.
Authorized administrators and object owners may revoke object privileges. The
ability to grant and revoke object privileges may also be granted to other users
by an authorized administrator, or the object owner.
The TOE is managed by submitting SQL statements to the database using the
SQL *Plus command line interface. The commands allow authorized
administrators to perform all of the security management functionality required
to manage the claimed security features of the TOE including:
a. management of the events to be audited;
b. changes to the system privileges;
c. changes to the object privileges;
d. changes to user accounts (including changes to authentication options)
and roles;
e. configuration of Data Guard options in support of the replication
requirements;
f. configuration of the maximum number of concurrent sessions for an
individual user;
g. configuration of logon triggers to support maintenance of information on
successful and unsuccessful login attempts; and
h. configuration of logon triggers to be able to deny logon based on time of
day and day of week.
Each database requires at least one user in the database administrator role.
(This role is described as ‘authorized administrator’ in the SFRs.) Other
administrative roles may be created by authorized administrators with the
unique set of system and object privileges required to perform assigned tasks.

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 60 of 66

 Oracle Database 12c Enterprise Edition
Security Target

Database users make use of the database, but do not typically have
administrative system privileges.
TOE Security Functional Requirements addressed: FMT_MOF.1, FMT_MSA.1,
FMT_MSA.3, FMT_MTD.1, FMT_REV.1(1), FMT_REV.1(2), FMT_SMF.1,
FMT_SMR.1.

7.1.5 Protection of the TSF

The TOE provides replication of data using the Data Guard feature. Primary
database transactions generate redo records. A redo record is made up of a
group of change vectors, each of which is a description of a change made to a
single block in the database. For example, if a value is changed in a table, a
redo record containing change vectors that describe changes to the data
segment block for the table, the undo segment data block and the transaction
table of the undo segments is generated. Data Guard works by shipping the redo
to the replicated database and then applying that redo.
Redo records contain all the information needed to reconstruct changes made to
the database. During media recovery, the database will read change vectors in
the redo records and apply the changes to the relevant blocks. When configured
to use the Synchronous transport method (also called the "zero data loss"
method), the commit operation will not be confirmed until it is written to both
the local and the remote database. If the connection between the databases is
lost, updates to the primary database are halted until the secondary database is
reconnected, thereby assuring consistency of the replicated data.
TOE Security Functional Requirements addressed: FPT_TRC.1.

7.1.6 TOE Access

The TSF may restrict the maximum number of concurrent sessions for a user.
This is configured using the SESSIONS_PER_USER option in the resource
parameters of a profile assigned to a user. Although the default value is
unlimited, in the evaluated configuration, an authorized administrator must
select a finite number for this limit.
Upon user login, the date and time of the successful or unsuccessful login
attempt is saved in the audit records. The audit records also maintain a count
of successive unsuccessful login attempts. In order to maintain the date and
time of the last successful login, the last unsuccessful login attempt and the
number of unsuccessful attempts since the previous last successful login, and
make that data accessible to the user, a logon trigger must be configured. This
will set up a table with the required information, and make that table accessible
to the user.
The TOE is able to deny session establishment based on user identity by
dropping the user account. In order to deny a session based on time of day or
day of week, a logon trigger must be configured. This will cause the TOE to
check the time of day and day of week before allowing the login to succeed.

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 61 of 66

 Oracle Database 12c Enterprise Edition
Security Target

TOE Security Functional Requirements addressed: FTA_MCS.1,

FTA_TAH_(EXT).1, FTA_TSE.1.

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 62 of 66

 Oracle Database 12c Enterprise Edition
Security Target

8 TERMINOLOGY AND ACRONYMS

8.1 TERMINOLOGY
The following terminology from the DBMS PP is relevant to this ST:

Term Description

Access Interaction between an entity and an object that results

in the flow or modification of data.

Access Control Security service that controls the use of resources3 and
the disclosure and modification of data 4.

Accountability Property that allows activities in an IT system to be

traced to the entity responsible for the activity.

Administrator A user who has been specifically granted the authority to

manage some portion or the entire TOE and whose
actions may affect the TOE security policy.
Administrators may possess special privileges that
provide capabilities to override portions of the TOE
security policy.

Assurance A measure of confidence that the security features of an

IT system are sufficient to enforce its security policy.

Attack An intentional act attempting to violate the security

policy of an IT system.

Authentication Security measure that verifies a claimed identity.

Authentication data Information used to verify a claimed identity.

Authorization Permission, granted by an entity authorized to do so, to

perform functions and access data.

Authorized The authorized person in contact with the Target of

Administrator Evaluation who is responsible for maintaining its
operational capability.

Authorized user An authenticated user who may, in accordance with the

TOE security policy, perform an operation.

Availability Timely 5, reliable access to IT resources.

3
Hardware and software
4
Stored or communicated
5
According to a defined metric

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 63 of 66

 Oracle Database 12c Enterprise Edition
Security Target

Term Description

Compromise Violation of a security policy.

Confidentiality A security policy pertaining to the disclosure of data.

Configuration data Data this is used in configuring the TOE.

Conformant Product A Target of Evaluation that satisfied all the functional

security requirements and satisfies all the TOE security
assurance requirements.

Database A suite of programs that typically manage large

Management structured sets of persistent data, offering ad hoc query
System (DBMS) facilities to many users. They are widely used in
business applications.

Discretionary Access A means of restricting access to objects based on the

Control (DAC) identity of subjects and/or groups to which they belong.
Those controls are discretionary in the sense that a
subject with certain access permission is capable of
passing that permission (perhaps indirectly) on to any
other subject.

Enclave A collection of entities under the control of a single

authority and having a homogeneous security policy.
They may be logical, or may be based on physical
location and proximity.

Entity A subject, object, user or another IT device, which

interacts with TOE objects, data, or resources.

Executable code The software that makes up the TSF which is in a form
within the TSF that can be run by the computer.

External IT entity Any trusted Information Technology (IT) product or

system, outside of the TOE, which may, in accordance
with the TOE security policy, perform an operation.

Identity A representation (e.g., a string) uniquely identifying an

authorized user, which can either be the full or
abbreviated name of that user or a pseudonym.

Integrity A security policy pertaining to the corruption of data and

TSF mechanisms.

Named Object An object that exhibits all of the following

characteristics:
• The object may be used to transfer information
between subjects of differing user and/or group
identities within the TSF.

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 64 of 66

 Oracle Database 12c Enterprise Edition
Security Target

Term Description
• Subjects in the TOE must be able to require a
specific instance of the object.
• The name used to refer to a specific instance of
the object must exist in a context that potentially
allows subjects with different user and/or group
identities to require the same instance of the
object.

Object An entity within the TOE scope of control that contains

or receives information and upon which subjects perform
operations.

Operating The total environment in which a TOE operates. It

Environment includes the physical facility and any physical,
procedural, administrative and personnel controls.

Public Object An object for which the TSF unconditionally permits all
entities “read” access. Only the TSF or authorized
administrators may create, delete, or modify the public
objects.

Secure State Condition in which all TOE security policies are enforced.

Security attributes TSF data associated with subjects, objects, and users
that are used for the enforcement of the TOE security
policy.

Security level The combination of a hierarchical classification and a set

of non-hierarchical categories that represent the
sensitivity of the information.

Sensitive Information that, as determined by a competent

information authority, must be protected because its unauthorized
disclosure, alteration, loss, or destruction will at least
cause perceivable damage to someone or something.

Subject An entity within the TOE scope of control that causes

operation to be performed.

Threat Capabilities, intentions and attack methods of

adversaries, or any circumstance or event, with the
potential to violate the TOE security policy.

TOE resources Anything useable or consumable in the TOE.

Unauthorized user A user who may obtain access only to system provided
public objects if any exist.

User Any entity (human user or external IT entity) outside

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 65 of 66

 Oracle Database 12c Enterprise Edition
Security Target

Term Description
the TOE that interacts with the TOE.

Vulnerability A weakness that can be exploited to violate the TOE

security policy.

Table 15 – Terminology

8.2 ACRONYMS
The following acronyms are used in this ST:

Acronym Definition
CC Common Criteria

CLI Command Line Interface

CM Configuration Management

DAC Discretionary Access Control

DBMS Database Management System

DBMS PP Database Management System Protection Profile

EAL Evaluation Assurance Level

GUI Graphical User Interface

I&A Identification and Authentication

IT Information Technology

OSP Organizational Security Policy

PP Protection Profile

RDBMS Relational Database Management System

SAR Security Assurance Requirement

SFP Security Function Policy

SFR Security Functional Requirement

SQL Structured Query Language

ST Security Target

TOE Target of Evaluation

TSF TOE Security Functionality

Table 16 – Acronyms

Doc No: 1932-000-D102 Version: 1.2 Date: 6 March 2017 Page 66 of 66