ibm canada, ltd., ontario, canada - common criteria · ibm canada, ltd., ontario, canada ......
TRANSCRIPT
National Information Assurance Partnership
Common Criteria Evaluation and Validation Scheme Validation Report
IBM Canada, Ltd., Ontario, CANADA
IBM DB2 Enterprise Server Edition V9.7 for Linux, Unix, and Windows
National Institute of Standards and Technology National Security Agency
Information Technology Laboratory Information Assurance Directorate
100 Bureau Drive 9800 Savage Road STE 6757
Gaithersburg, MD 20899 Fort George G. Meade, MD 20755-6757
Report Number: CCEVS-VR-VID10336-2009
Dated: 18 August 2009
Version: 1.0
2
ACKNOWLEDGEMENTS
Validation Team
Dr. Patrick W. Mallett
The MITRE Corporation
McLean, Virginia
Mr. Daniel P. Faigin, CISSP
The Aerospace Corporation
El Segundo, California
Common Criteria Testing Laboratory
Ms. Cynthia Reese Ms. Dawn Campbell Ms. Marie Eve Pierre
Science Applications International Corporation Columbia, Maryland
This report contains material that was extracted from evaluation material prepared by the
CCTL. The CCTL team deserves credit for their hard work in developing that material. Many
of the product descriptions in this report are extracted from the IBM DB2 Security Target.
3
TABLE of CONTENTS
ACKNOWLEDGEMENTS ................................................................................................ 2
EXECUTIVE SUMMARY ................................................................................................ 6
1 IDENTIFICATION..................................................................................................... 8
2 SECURITY POLICY.................................................................................................. 9
2.1 Audit ..................................................................................................................... 9
2.2 Access Control ..................................................................................................... 9
2.3 Identification and Authentication ....................................................................... 10
2.4 Security Management ......................................................................................... 11
2.5 TOE Protection ................................................................................................... 11
3 ASSUMPTIONS AND CLARIFICATION OF SCOPE .......................................... 12
3.1 Usage Assumptions ............................................................................................ 12
3.1.1 Personnel Assumptions ............................................................................... 12
3.1.2 Physical Assumptions ................................................................................. 12
3.1.3 Connectivity Assumptions .......................................................................... 12
3.2 Operating Environment ...................................................................................... 12
3.3 Clarification of Scope......................................................................................... 14
4 ARCHITECTURAL INFORMATION .................................................................... 16
4.1 DRDA Protocol Handler .................................................................................... 18
4.2 SQL Processing .................................................................................................. 18
4.3 SQL Manager ..................................................................................................... 19
4.4 SQL Compiler .................................................................................................... 20
4.5 SQL Runtime...................................................................................................... 20
4.6 Non-SQL Processing .......................................................................................... 20
5 DOCUMENTATION ............................................................................................... 21
5.1 Design documentation ........................................................................................ 21
5.2 Guidance documentation .................................................................................... 21
4
5.3 Lifecycle documentation .................................................................................... 22
5.4 Test documentation ............................................................................................ 22
5.5 Security Target ................................................................................................... 22
6 IT PRODUCT TESTING ......................................................................................... 23
6.1 Vendor Testing ................................................................................................... 23
6.1.1 Testing Approach ........................................................................................ 23
6.1.2 Test Descriptions ........................................................................................ 23
6.1.3 Depth and Coverage .................................................................................... 23
6.1.4 Test Results ................................................................................................. 23
6.2 Evaluator Testing ............................................................................................... 24
7 EVALUATED CONFIGURATION ........................................................................ 25
8 RESULTS OF THE EVALUATION ....................................................................... 26
8.1 Evaluation of the IBM DB2 Security Target (ST) (ASE) .................................. 26
8.2 Evaluation of the Development (ADV) ............................................................. 26
8.3 Evaluation of the Guidance Documents (AGD) ................................................ 26
8.4 Evaluation of the Life Cycle Support Activities (ALC) .................................... 26
8.5 Evaluation of the Test Documentation and the Test Activity (ATE) ................. 27
8.6 Evaluation of the Vulnerability Assessment Activity (AVA) ............................ 27
8.7 Summary of Evaluation Results ......................................................................... 27
8.8 Assurance Requirement Results ......................................................................... 27
8.8.1 Common Criteria Assurance Components .................................................. 28
8.8.2 Testing and Vulnerability Assessment........................................................ 28
8.9 Conclusions ........................................................................................................ 28
8.9.1 ST Evaluation.............................................................................................. 28
8.9.2 TOE Evaluation .......................................................................................... 28
8.10 Summary of Evaluation Results ..................................................................... 29
9 VALIDATOR COMMENTS AND RECOMMENDATIONS ................................ 30
10 SECURITY TARGET .............................................................................................. 32
5
11 ACRONYMS ............................................................................................................ 33
12 BIBLIOGRAPHY ..................................................................................................... 34
6
EXECUTIVE SUMMARY
This report documents the results of the Validation Panel‘s oversight of the evaluation of
the IBM Corporation DB2 Version 9.7 product. It presents the evaluation results,
justifications, and the conformance results. This Validation Report is not an endorsement
of the Target of Evaluation (TOE) by any agency of the U.S. Government and no
warranty of the TOE is either expressed or implied.
Science Applications International Corporation (SAIC) Common Criteria Testing
Laboratory (CCTL) performed the evaluation. The Lab completed the evaluation in July
2009. The information in this report is largely derived from the Evaluation Technical
Report (ETR) written by SAIC and submitted to the Validation Panel. The evaluation
determined that the product conforms to the Common Criteria Version 3.1 Revision 2,
Part 2 extended and Part 3 conformant and meets the requirements of Evaluation
Assurance Level (EAL) 4 augmented with ALC_FLR.1 (Basic Flaw Remediation).
This evaluation was primarily a maintenance upgrade, with two narrowly focused
changes. Previous versions of IBM DB2 have undergone successful evaluations. The 9.7
evaluation introduced the following features: finer granularity in the role mechanism
allowing for separation of duties, the option to use AES to protect the communication of
the user ID and password to the TOE.
The TOE is an IBM Corporation relational database management system. The TOE
provides interfaces to clients connected to the database server. Commands are entered
from the client interactively or through an executing program to the database server to
create databases, database tables, and to store and retrieve information from tables. The
TOE operates as a set of software applications in an Information Technology (IT)
environment consisting of the hosting operating system and platform (not covered by the
evaluation). The security services of the operational environment required by the DB2
TOE have not been evaluated and therefore, need to be determined and assessed
separately. The IT security services provided by the environment include support for
protection of the TOE Security Functions (TSF), reliable time-stamps (used in time-
stamping audit records), audit generation, security management and user identification
and authentication.
The DB2 TOE provides functionality to meet security requirements in the following
areas:
Security audit (generation, association of users in events, audit overflow detection,
and audit review),
User data protection, (implementation of a discretionary access control policy
(DAC) and a label based access control (LBAC) policy for its objects),
Identification and authentication, security management and protection of the TSF
(enforcement of the security policy).
7
The TOE environment and the TOE security requirements are stated in the Security
Target (DB2 9.7 Security Target, Revision 1.0, 3 August 2009). The TOE includes DB2
Enterprise Server Edition Versions for Linux, Unix and Windows operating systems.
The cryptography used in this product is provided by the IBM Global Security Kit (GSKIT)
component and the IBM Crypto for C (ICC) component both of which were not analyzed within
the scope of this evaluation. However, both have received Federal Information Processing
Standard (FIPS) 140-2 validation.
The Validation Team provided oversight on the activities of the evaluation team,
provided guidance on technical issues and evaluation processes, reviewed successive
versions of the Security Target, reviewed selected evaluation evidence, reviewed test
plans, reviewed intermediate evaluation results (i.e., the Common Evaluation
Methodology (CEM) work units), and reviewed successive versions of the ETR and test
report. The Validators‘ observations support the CCTL's conclusion that the product
satisfies the functional and assurance requirements defined in the Security Target (ST).
Therefore, the Validation Panel concludes that the findings of the evaluation team are
accurate, and the conclusions justified.
8
1 IDENTIFICATION
The CCEVS is a joint National Security Agency (NSA) and National Institute of
Standards and Technology (NIST) effort to establish commercial facilities to perform
trusted product evaluations. Under this program, security evaluations are conducted by
commercial testing laboratories called Common Criteria Testing Laboratories (CCTLs)
using the Common Evaluation Methodology (CEM) for Evaluation Assurance Level
(EAL) 1 through EAL 4 in accordance with National Voluntary Laboratory Assessment
Program (NVLAP) accreditation.
The NIAP Validation Body assigns Validators to monitor the CCTLs to ensure quality
and consistency across evaluations. Developers of information technology products
desiring a security evaluation contract with a CCTL and pay a fee for their product‘s
evaluation. Upon successful completion of the evaluation, the product is added to
NIAP‘s Validated Products List. Table 1 provides information to identify the product.
Table 1. Evaluation Identifiers
Item
Identifier
Evaluation Scheme United States NIAP Common Criteria Evaluation and Validation Scheme
Target of Evaluation IBM DB2 Enterprise Server Edition V9.7 for Linux, Unix, and Windows
Protection Profile None
Security Target IBM DB2 Enterprise Server Edition V9.7 for Linux, Unix, and Windows
Security Target, Revision 1.0, 3 August 2009
Evaluation Technical Report Final Evaluation Technical Report For IBM DB2 Version 9.7, Part1 (Non
Proprietary), Version 1.0, 4 August 2009; Final Evaluation Technical
Report For IBM DB2 Version 9.7, Part 1 (Proprietary), Version 1.0, 4
August 2009; Final Evaluation Technical Report For IBM DB2 Version
9.7, Part 2 (Proprietary), Version 1.0, 4 August 2009
CC Version Common Criteria for Information Technology Security Evaluation Part 2:
Security functional requirements, Version 3.1, Revision 2, September
2007. Common Criteria for Information Technology Security Evaluation
Part 3: Security assurance requirements, Version 3.1, Revision 2,
September 2007
Conformance Result Part 2 extended, Part 3 conformant, EAL4 augmented
Sponsor IBM Canada, Ltd.
Developer IBM Canada, Ltd.
Evaluators SAIC, Columbia, MD
Validators Mr. Daniel P. Faigin, CISSP, The Aerospace Corporation
Dr. Patrick W. Mallett, The MITRE Corporation
9
2 SECURITY POLICY
The TOE supports the following security functions: Audit, Access Control, Identification
and Authentication, Security Management, and TOE Protection.
2.1 Audit
DB2 records security relevant events that occur within its scope of control. These events
are associated with individual users for individual accountability and can be accessed
only by authorized administrators1. For DB2 instances and databases the audit log files
are stored in files in the operational environment (i.e., underlying OS) configured during
installation and the audit configuration file (db2audit.cfg) is located in each instance‘s
security subdirectory. In addition to relying on the underlying OS to store and protect
audit data stored in files, DB2 relies on the OS to provide reliable time information to
record in its audit records.
2.2 Access Control
DB2 enforces an access control policy on a subset of its objects, which per the Security
Target are databases, schemas, table spaces, tables, views, packages, procedures,
functions, and methods. DB2 associates privileges and authorities with each individual
user, group of users, and database role. These privileges and authorities are associated
with operations that can be performed on the objects (e.g., database) that are implemented
by DB2. DB2 uses identities, privileges, authorities, and access control lists associated
with users, groups, roles, and objects to determine whether specific operations will be
allowed when attempted by client users.
Note that while the term ‗security roles‘ is used in this ST to distinguish authorized
administrators from non-administrator users, DB2 implements this concept using a
variety of authorities and privileges. DB2 implements a number of authorities–SQLADM,
WLMADM, ACCESSCTRL, DATAACCESS, SYSADM, SYSCTRL, SYSMON,
SYSMAINT, DBADM, or SECADM.
SYSADM authority makes a user a system administrator. The system administrator is not
considered a database administrator and has no inherent privilege in the database. Users
with system administrator authority have sufficient authority to run most DB2 utility
programs, issue database manager commands, maintain database partition groups, table
spaces, and bufferpools. SECADM makes a user a security administrator that performs
database security administration, and essentially has full control of database security.
DBADM authority is intended to allow management of a database, but the authority can
be limited depending on whether ACCESSCTRL or DATAACCESS are also granted. As
of Version 9.7, DBADM authority no longer inherently grants additional database level
authorities to the applicable authorization id. The ACCESSCTRL authority provides the
1 The term authorized administrator is used to generally refer to an administrator authorized (e.g., by role)
to perform a corresponding function depending on the context in which the term is used.
10
holder with the ability to issue grant and revoke statements on objects. In previous
versions of DB2, ACCESSCTRL authority was held implicitly by all database
administrators. In order to preserve existing DB2 behavior, the GRANT DBADM syntax
provides two new options: WITH ACCESSCTRL and WITHOUT ACCCESSCTRL.
Without the DATAACCESS authority, the database administrator is restricted from
accessing data in the database tables. Users with this authority can issue the database
load statement; issue the select, insert, updated, and delete statements on tables, views,
and nicknames; and, execute packages and routines (except further restricted audit
routine). Note that, as with ACCESSCTRL authority, DATAACCESS authority was
previously held implicitly by all database administrators. In order to preserve existing
DB2 behavior, the GRANT DBADM syntax provides two new options: WITH
DATAACCESS and WITHOUT DATAACCESS.
In addition to using privileges and authorities to control access, DB2 implements a LBAC
mechanism on database table objects. The DB2 security administrator can grant (or
revoke) security labels and exemptions to (or from) users as well as create and drop
LBAC security objects in order to define LBAC polices for specific database tables. Once
a table is configured with a LBAC policy (i.e., the table is LBAC protected relative to
either rows or columns), users must additionally satisfy the LBAC access rules in order to
access or modify the applicable table rows or columns. It is important to note that LBAC
only applies to configured tables and that DB2 is not a multilevel system. It is assumed
the TOE administrators will be cleared to the highest security level processed by the TOE.
2.3 Identification and Authentication
DB2 requires all users to be identified and authenticated before allowing them access to
DB2 resources. The operational environment (i.e., host operating system, Lightweight
Directory Access Protocol (LDAP) server, or Key Distribution Center (KDC) server)
performs the actual authentication and association of users with groups and passes the
result to DB2. DB2 subsequently enforces the result returned by the operational
environment and uses the user identity and group memberships (i.e., list of groups)
returned by the operational environment, along with its own associations of users, groups,
and other database roles with database roles, to associate privileges, authorities, and
security labels and exemptions with the authenticated user.
Note that the association between users and groups is managed within the operational
environment. Operational environment user and group identities are uniquely mapped in
the TOE and when a user accesses the TOE, the operational environment provides the
user and all group identities associated with that user. However, database roles are
defined within the TOE where users, groups, and other database roles can be associated
with specific database roles.
Users who acquire a trusted connection may have the ability to use alternate identities,
without further authentication, in accordance with the definition of the trusted context
object associated with that trusted connection in the TOE. A trusted context definition may
only be defined by a user with SECADM authority and it may be defined to require
authentication or to not require authentication upon the changing of identities. They could be
11
configured so that they can use only a specific set of identities or alternately so that they
can use any identity known to the TOE.
2.4 Security Management
DB2 includes the security roles of system administrator, security administrator, and user,
implemented using DB2 authorities and privileges. DB2 allows individual users to be
assigned to those security roles by virtue of group assignments in the operational
environment. Management of the DB2 TOE, including the ability to select and review
audit records, is restricted to appropriate administrators based on authorities.
Management of DB2 objects, including management of security labels, as well as
database roles and audit policies is restricted to those users that are assigned the
appropriate privileges to do so.
Note that the trusted context feature effectively introduces a new security role, referred to
simply as trusted context in this Security Target, as the users trusted by virtue of a trusted
context configuration may have the ability to assert alternate identities without requiring
authentication by the TOE, depending upon how the SECADM defined the associated
trusted context.
2.5 TOE Protection
DB2 executes within processes provided and protected by the hosting operational
environment. However, DB2 is not designed to share its process space with non-TOE entities
in order to ensure that TSF resources are protected. DB2 has been designed so that each of
its interfaces performs the necessary access checks before allowing access to DB2
resources. DB2 communicates between Database Partition Facility (DPF) instances,
when so configured, and with clients that can be remote from the DB2 server. DB2
implements Secure Sockets Layer (SSL), using a separate GSKit product in the
operational environment for cryptographic services. DB2 can be configured using the
IBM Crypto for C (ICC) library to implement AES for protection of the user ID and
password as it is communicated to the TOE. Otherwise, DB2 relies upon the operational
environment to ensure adequate communication protections. In the case of DPF instances,
a dedicated network can be configured to be used exclusively by DB2.
Remote clients need to communicate securely with DB2. If some of the hosts on the
applicable network are not adequately trusted, IPSec or other host- or network-based
protection mechanisms could be configured to protect any otherwise insecure network
traffic.
Fenced routines execute in processes separate from the DB2 server, while unfenced
routines share the DB2 server process. Given that the DB2 server must protect itself (e.g.,
from tampering) and its ability to do so is limited when users can create routines that
execute within the same operating system process, unfenced routines are excluded from
the evaluated configuration of the TOE.
12
3 ASSUMPTIONS AND CLARIFICATION OF SCOPE
3.1 Usage Assumptions
The expectation is that the system will be used in what has traditionally been known as a
relatively benign, or non-hostile, environment.
The assumptions as presented in the ST are noted below.
3.1.1 Personnel Assumptions
There will be one or more competent individuals assigned to manage the TOE and
the security of the information it contains.
The system administrative personnel are not careless, willfully negligent, or
hostile, and will follow and abide by the instructions provided by the
administrator documentation.
Authorized users possess the necessary access authorization to at least some of the
information managed by the TOE and are expected to act in a cooperating manner
in a benign environment.
Procedures exist for granting users authorization for access to specific security
levels.
3.1.2 Physical Assumptions
The TOE is intended for application in areas that have physical control and
monitoring. It is assumed that the following physical conditions will exist:
The processing resources of the TOE will be located within controlled access
facilities that will prevent unauthorized physical access.
The hardware and software critical to security policy enforcement will be
protected from unauthorized physical modification.
3.1.3 Connectivity Assumptions
All connections to peripheral devices reside within the controlled access facilities.
The TOE only addresses security concerns related to the manipulation of the TOE
through its authorized access points. It is assumed that internal communication
paths to access points such as terminals are adequately protected.
The operational environment underlying the TOE is assumed to fulfill the
requirements for the operational environment described in the ST.
3.2 Operating Environment
The following components are required in the operational environment to provide the
13
following services to the TOE.
Hosting OS: IBM AIX 6, Red Hat Enterprise Linux (RHEL) 5 update 2, SuSE
Linux Enterprise Server (SLES) 10 with SP2, Microsoft Windows Server 2003
Enterprise Edition with SP2, or Solaris 10. The TOE relies on the underlying
operating system to perform the following functions:
o Instantiate the executing DB2 Instance Server process
o Provide memory that is exclusive to the DB2 Instance Server process
o Provide memory that does not contain residual information
o Provide operating system user accounts that DB2 may map to DB2 user
accounts
o Provide management of operating system user accounts to include creation,
modification, deletion, and revocation of rights
o Authenticate user identities given identities and authentication data provided
by clients
o Make information available about the user identities associated with executing
processes
o Provide reliable timestamps for use by DB2 processes
o Audit its own security functions
o Provide access to and protection for the DB2 configuration and audit files
o Provide access to shared memory in order to communicate with the DB2
Instance Server
o Provide a communication facility/subsystem that allows users and other DB2
partitions to communicate with the applicable DB2 Instance Server
Authentication server (when not using the services of the hosting OS): Any
standard-compliant LDAP or KDC server. DB2 can be configured to utilize
authentication services of a LDAP or KDC server, rather than the operating
system, in its environment. When so configured, DB2 relies on the presence of a
standard-compliant server to perform this function rather than the underlying
operating system.
IBM Global Security Kit: DB2 depends on access to an installed instance of the
IBM GSKit in order to support the use of SSL when communicating with clients.
IBM Crypto for C (ICC): DB2 uses the AES-256 algorithm from this
component to protect passwords as the TOE can optionally be configured to
require that passwords be encrypted by associated clients.
14
3.3 Clarification of Scope
The Security Target specified the security requirements of the TOE, which determined
the scope of the evaluation. It is the responsibility of the integrator to ensure the
Objectives for the operational environment are satisfied. The IT security services
provided by the environment support the protection of the TOE Security Functions (TSF),
reference mediation (preventing bypass of the security functions), reliable time stamps
(used in time stamping audit records), audit generation, security management and user
identification and authentication. The scope of the evaluation includes a determination of
the TOE partially protecting its interface. The TOE relies on the operational environment
for protection from tampering and the ability to maintain a security domain that is
protected from interference and tampering by untrusted subjects or to enforce separation
between the security domains of subjects in the TOE Scope of control.
While DB2 can alternately be installed using a non-root install option, that configuration
limits the functions of DB2 and has not been subject to evaluation. Also note that the
product is shipped with libraries and programs that expose other application
programming interfaces (APIs) (command line, Open Database Connectivity (ODBC),
Java Database Connectivity (JDBC), etc.); the libraries and programs simply serve to
convert their exposed APIs to Distributed Relational Database Architecture (DRDA)
flows to the DB2 server. With the exception of those tools and utilities identified in the
TOE‘s guidance documentation, these libraries and programs are outside the scope of the
TOE.
The following products, though required for the operational environment, are outside the
scope of the TOE:
Hosting OS: IBM AIX 6, Red Hat Enterprise Linux (RHEL) 5 update 2, SuSE
Linux Enterprise Server (SLES) 10 with SP2, Microsoft Windows Server 2003
Enterprise Edition with SP2, or Solaris 10.
Authentication server (when not using the services of the hosting OS): Any
standard-compliant LDAP or KDC server.
IBM Global Security Kit
IBM Crypto for C (ICC). In addition to non-security functions, the following
security-related functions are not within the scope of the TOE (i.e., there are no
corresponding security claims) even though they are shipped with the product:
Data Encryption Standard (DES): While the TOE can be configured to use
DES to protect authentication credentials, this mechanism has not been subject to
evaluation and as such should not be solely relied upon as an adequate means of
protection.
Data encryption functions (ENCRYPT, DECRYPT_BIN, DECRYPT_CHAR,
and GETHINT): Users can employ these functions to encrypt and decrypt data.
However, the functions were not subject to evaluation and as such should not be
solely relied upon as an adequate means of protection. Note that this is intended to
15
address the functions shipped with the product, but any such functions developed
by end users would also not be included within the scope of evaluation.
Unfenced routines: Fenced routines execute in processes separate from the DB2
server, while unfenced routines share the DB2 server process (see section 6.1.5 of
the Security Target). Given that the DB2 server must protect itself (e.g., from
tampering) and its ability to do so is limited when users can create routines that
execute within the same operating system process, unfenced routines are excluded
from the evaluated configuration of the TOE.
CLIENT authentication: The TOE supports a number of authentication
configurations. While for the most part the TOE administrator can choose the
configuration that best fits their specific environment, the configuration whereby
the client is trusted to authenticate the user is excluded from the evaluated
configuration. The evaluation only addressed the configuration where the DB2
server is responsible to ensure that users are authenticated, although it relies on
other configured components to do so.
16
4 ARCHITECTURAL INFORMATION
DB2 is a relational database management system (RDBMS) provided by IBM. As a
RDBMS, DB2 supports the Structured Query Language (SQL) interface from a client
that is connected to the database server. From the client, commands can be entered
interactively or through an executing program to the database server to create databases,
database tables, and to store and retrieve information from tables. DB2 can be installed
on a number of possible operating environments.
Figure 1. TOE Security Environment
17
DB2 operates as a set of applications (e.g., servers) in an operational environment
consisting of all software residing on the host platform(s) but not part of the DB2 TOE.
For the purposes of this discussion, it is referred to as the Host OS. The operational
environment, including the Host OS and optionally an LDAP or KDC authentication
server, provides fundamental supporting mechanisms to the TOE. In particular, the
operational environment supplies a trusted authentication mechanism and utilities to
manage system resources and I/O channels.
DB2 is realized as a running server (i.e., DB2 Instance) and a set of commands (i.e., DB2
Commands) that can be exercised by appropriate users. Both the server and the
commands rely upon services provided by the operating system to instantiate themselves
and offer their services in turn. In particular, the server uses operating system services to
communicate with local and remote DB2 clients using shared memory and network
services, respectively. Similarly, the DB2 Commands use operating system services to
store configuration data (i.e., in files) and to act as a local client to communicate with the
server in order to facilitate necessary management services.
A DB2 Server may be configured as a partitioned instance. This optional configuration is
known as Data Partitioning Feature (DPF). Each data partition is composed of a complete
DB2 Server and a subset of the data stored in all the databases managed by the DB2
Server instance. These partitions may be either ―logical‖ (meaning they run on the same
host machine) or ―physical‖ (they run on different host machines). Combinations of both
logical and physical partitions are also supported. From a user perspective, the partitioned
aspect of the instance is transparent. The user may interact with DB2 as if it was a single
server.
DB2 also provides a ―trusted context‖ feature. Trusted contexts are database objects that
provide a specification for a trust relationship between the database and an external entity.
The trust relationship is based on three attributes: an authorization ID, a data stream
encryption attribute, and an IP address (or addresses). The user associated with any
connection that matches the definition of a trusted context object is considered ―trusted‖
by the database. Users trusted in this manner (e.g., ―trusted servers‖) can be configured
such that they are allowed to modify some of the security attributes associated with their
database connections. Specifically, they can be configured such that the ―user‖
associated with an existing connection to be changed. Depending on the DB2
configuration, this may or may not require authentication of the new user identity.
Furthermore, the trusted context object can define database roles that can be assigned to
trusted context sessions. During the initial connection or during an authorization name
(i.e., user) change, the session will be assigned an additional database role if a) one is
defined explicitly for the applicable authorization name, or b) there is a default database
role defined. When explicitly defined for an authorization name, the session would be
assigned that role. Otherwise, the session would be assigned the default database role for
the trusted context. If neither is defined then no additional role will be assigned to the
trusted context.
The end-user identity assertion aspect of this function is intended for multi-tier
environments where the middle tier, typically an application server, might already
perform authentication of end users. Trusted contexts provide a mechanism for the
18
database to trust the middle tier and effectively establish connections on behalf of end
users without necessarily supplying the credentials (password) of the end user to the
database. For the purpose of this document, Trusted Context users are treated like any
other client.
DB2 also supports the use of SSL with clients. As such, users of DB2 can choose to
enable that feature, though it is not necessary particularly when other means of client
communication protection are configured in the operating environment of DB2. The
Common Criteria evaluation design documentation describes DB2 in terms of two
subsystems: the Security Management subsystem and the Server subsystem. The Security
Management subsystem is responsible to provide the tools and server interfaces
necessary for administrators and other users to manage the security-relevant
configuration of DB2. Note that the Security Management subsystem implements only
some of the security management related functions. However, it is so named because it
provides all of the interfaces that are to be used for security management. In the case
where the security management functions are implemented, entirely or in part, in the
Server subsystem, the Security Management subsystem provides the user interface and
interacts with the Server subsystem to achieve the function. The Server subsystem is
responsible to implement database instances, offering interfaces for the creation and
manipulation of databases and associated database objects.
4.1 DRDA Protocol Handler
The DRDA Application Server (AS) module within DB2 allows DB2 to act as an
Application Server within the Distributed Relational Database Architecture (DRDA).
DRDA is an Open Group standard used in the management of distributed data. The DB2
DRDA AS module architecture provides support for one or more DRDA Application
Requestors (DRDA AR), commonly referred to as clients, to access a specific DB2
instance or DB2 database and issue SQL and non-SQL requests against that object. Upon
initiation of communication between a client and the DB2 DRDA AS module, a common
―security mechanism‖ is negotiated. This mechanism may be one of a number of different
security protocols; for the purpose of this TOE, the only allowed security mechanism is
the ―Userid, Password‖ mechanism as described in the DRDA standard. If validation of
the password fails, the DRDA AS terminates conversation with the client that provided
the failed password. If the password is authenticated, a DRDA session, or connection, is
established and the client may begin to pass requests to DB2 for processing. These
requests are of two general types: SQL requests, which are handled by the DB2 SQL
Processing module, and non-SQL requests, which are handled by the DB2 Non-SQL
Processing module. The DRDA AS module identifies the type of request and passes it to
the appropriate module for further processing.
4.2 SQL Processing
The DB2 SQL Processing module is responsible for the analysis and execution of client
requests related to the processing of Structured Query Language (SQL) statements. DB2
supports the American National Standards Institute (ANSI)/ International Organization
for Standardization (ISO) SQL2 standard for all types of SQL statements including:
19
Data Definition Language (DDL) statements that create, alter, drop, rename, or
transfer ownership of database objects.
Data Manipulation Language (DML) statements that are used to query or modify
the data contained within database objects. Modification can occur in one of three
ways: row insertion, row deletion, or row modification via column updates. These
statements include SELECT, INSERT, UPDATE, and DELETE SQL statements.
GRANT and REVOKE (Data Control Language (DCL)) statements that control
the access to database authorities as well as privileges on database objects.
Transaction control statements that manage the integrity of the database with
respect to any modification made by a client. These statements include, among
others, the ROLLBACK and COMMIT SQL statements.
Miscellaneous statements used to perform a number of different actions on
database objects or on the connection environment. The DB2 SQL Processing
module is comprised of three distinct components: the SQL Manager, the SQL
Compiler, and the SQL Runtime components. The responsibilities of these
components as they relate to the processing of SQL statements are described in
the following sections.
4.3 SQL Manager
The SQL Manager is responsible for accepting SQL requests from the client, validating
them, and then coordinating any subsequent processing of the request to ensure it is
properly answered. The SQL Manager can accept SQL requests related to static or
dynamic SQL statements. Static SQL statements have their contents made known to DB2
prior to the request arriving from the client through a process called ―binding,‖ which
results in the statement being compiled by the SQL Compiler and the resultant
information being stored in the DB2 system catalogs for later use. Dynamic SQL
statements are unknown to DB2 until the request arrives, at which time they are compiled
by the SQL Compiler. The information produced by the SQL compiler contains the
executable form of the statement, referred to as a section, a list of the required privileges
for any client wishing to run the section as well as a list of the database objects upon
which the section is dependent for its execution integrity.
The SQL Manager processes SQL requests from a client by matching the request to a
specific SQL statement. Once the statement has been identified and its related
information acquired (from either the DB2 system catalogs or the SQL Compiler), the
SQL Manager then enforces the discretionary access control policy by ensuring that the
required privileges for the section are held by the primary authorization name (a specific
user identifier), or by any relevant secondary authorization names (the identifiers for any
relevant groups to which the primary authorization name belongs and roles to which any
other authorization name belongs2), associated with the request from the client. If the
2 Note that users, groups, and other roles can be assigned to roles. As such, role hierarchies are supported.
20
privileges are held, then the section is passed to the SQL Runtime component for
execution.
4.4 SQL Compiler
The SQL Compiler is responsible for analyzing an SQL statement and producing an
efficient executable form of that statement, called a ―section‖, as well as additional
information about that section such as its object dependencies and required privileges.
The SQL Compiler parses an SQL statement into an internal representation, or model, of
the statement that is then used to analyze the scope and intent of the statement. Additional
information is added to the internal model, where appropriate, from the DB2 system
catalogs in order to represent properly the full extent of the statement‘s use of any
database objects. Once complete, the internal model is then analyzed and optimized in
order to produce the most efficient plan to satisfy the statement. The SQL Compiler then
generates an executable form of the statement using the internal DB2 constructs and
operators used by the SQL Runtime component.
4.5 SQL Runtime
Note that users, groups, and other roles can be assigned to roles. As such, role hierarchies
are supported. The SQL Runtime component is responsible for the actual execution of the
section related to the request and the production of any response to the client required by
the request. The success or failure of the actual execution as well as any additional
response is given back to the SQL Manager for return to the client.
4.6 Non-SQL Processing
The DB2 Non-SQL Processing module is responsible for the analysis and execution of all
those client requests not concerned with SQL statements. Such requests are used to
invoke a number of Application Program Interfaces (APIs) and utilities provided by DB2
that do not use SQL statements to perform their specified actions. There exist a number
of these APIs and utilities at both the DB2 Instance level as well as at the individual
database level within a DB2 instance. Each API and utility provided by DB2 has an
assigned privilege or authority requirement as defined by DB2. The DB2 Non-SQL
Processing module enforces the discretionary access control policy for these non-SQL
requests by ensuring that the required privilege or authority is held by either the primary
authorization name or secondary authorization names where applicable, of the requestor.
21
5 DOCUMENTATION
The following documentation was used as evidence for the evaluation of the TOE.
Documents that are publically available are shown in boldface.
5.1 Design documentation
Document Revision Date
IBM DB2 V9.7 Enterprise Server Edition Functional
Specification 0.33 2009-07-07
IBM DB2 V9.7 Enterprise Server Edition High-level Design
Specification 0.3 2009-07-02
IBM DB2 V9.7 Enterprise Low-level Design Specification 0.2 2009-04-24
DB2 Access Control Mechanism FPFS 0.1 2008-11-17
DB2 Audit Facility Design 0.2 2008-11-17
DB2 Audit Facility FPFS 0.21 2009-04-24
DB2 Identification & Authentication Facility Design 0.21 2009-04-24
DB2 Identification & Authentication Facility FPFS 0.21 2009-04-24
DB2 Security Management Facility FPFS 0.1 2008-11-13
DB2 Self Protection Facilities FPFS 0.11 2009-04-24
DB2 9.7 Fast Communication Manager Design 0.11 2009-04-24
IBM DB2 V9.7 Enterprise Server Edition for Linux, Unix,
and Windows Security Target 1.0 2009-08-03
IBM DB2 V9.7 Enterprise Server Edition Security Architecture
Document 0.3 2009-07-02
5.2 Guidance documentation
Document Revision Date
Common Criteria Certification: Installing IBM DB2 Version 9.7
Enterprise Server Edition for Linux, UNIX, and Windows, IBM
Document No. GC14-7215-00
7 N/A
IBM DB2 9.7 for Linux, UNIX, and Windows: Common
Criteria Certification: Administration and User
Documentation – Volume 1, IBM Document No. SC14-7213-
00
6 N/A
IBM DB2 9.7 for Linux, UNIX, and Windows: Common
Criteria Certification: Administration and User
Documentation – Volume 2, IBM Document No. SC14-7214-
00
5 N/A
IBM DB2 9.7 Delivery Procedures 0.1 2009-02-17
22
5.3 Lifecycle documentation
Document Revision Date
IBM DB2 Enterprise Server Edition Version 9.7 for Linux,
Unix, and Windows Configuration Management Plan
0.1 2009-02-17
IBM DB2 Enterprise Server Edition Version 9.7 for Linux,
Unix, and Windows Life Cycle Document
0.1 2009-02-17
5.4 Test documentation
Document Revision Date
IBM DB2 Enterprise Server Edition Version 9.7 For Linux,
Unix, and Windows Test Plan
0.2 2009-04-26
DB2 Universal Database Version V9.7 Test Coverage Analysis 0.3 2009-05-08
IBM DB2 Enterprise Server Edition Version 9.7 For Linux,
Unix, and Windows Test Suite Readme Document
0.5 2009-05-13
5.5 Security Target
Document Revision Date
IBM DB2 V9.7 Enterprise Server Edition for Linux, Unix,
and Windows Security Target
1.0 2009-08-03
23
6 IT PRODUCT TESTING
6.1 Vendor Testing
The description of the vendor suite is documented in the ―IBM DB2 Enterprise Server
Edition Version 9.7 For Linux, Unix, and Windows Test Plan‖ in the section describing
the test cases for the Common Criteria.
6.1.1 Testing Approach
The developer testing approach is described in ―IBM DB2 Enterprise Server Edition Version
9.7 for Linux, Unix, and Windows Test Plan‖. The testing of the DB2 security functions
is automated. These tests were mapped to the test cases outlined in the Functional
Specification document. Together they demonstrate the security-relevant behavior of
DB2 at the interfaces defined in that document: the Command Line User Interface, SQL
Interface, API Interface, and the DRDA Interface. The results of the tests demonstrated
that DB2 meets the security functional requirements specified in the Security Target. The
security functions that were tested are the same as those mentioned in the Security
Target: Audit, User Data Protection, Identification & Authentication, Security
Management, and Protection of the TSF.
6.1.2 Test Descriptions
The test procedure descriptions are documented in a collection of text files that include
several test cases. For each test case within the text file, a description of what is tested
(equivalent to a test case in the Functional Specification document) and an overview of
how it is tested is provided.
A test package is provided for each platform included in the test configuration. The test
package includes several directories, each containing test output, test source files, the
expected test results, and the actual test results.
6.1.3 Depth and Coverage
The amount of testing performed as it relates to the required functionality is
described in the rationale for ATE_COV work units. The depth of testing performed
as it relates to the High Level design is described in the rationale for the ATE_DPT
work units in the Evaluation Technical Report.
6.1.4 Test Results
The test suite consisted of automated tests. For each test description file, there is
corresponding file that describes the expected results and another file that provides the
actual results of a test run. Additional files are also generated detailing any
inconsistencies between the expected results and the actual results.
24
6.2 Evaluator Testing
The evaluation team performed the TOE installation, as specified in the Installation,
Generation and Startup documentation and performed functional, independent and
vulnerability testing. The test configuration consisted of Version 9.7 of DB2 installed on
the following platforms: Windows 2003 operating system and RHEL 5.
The following product options were installed on the indicated platforms:
Enterprise Server Edition on the Windows 2003 platform: Optional features: with
DPF configured twice on two DPF installations
Enterprise Server Edition on RHEL 5 platform: Optional features: with single
partition configured
Enterprise Server Edition on AIX 6 platform: with single partition configured
The test tools used by the developer test suite are documented in the ―IBM DB2
Enterprise Server Edition Version 9.7 for Linux, Unix, and Windows Test Plan‖.
The above test configurations were compared to the TOE identification included in the
ST and found to be consistent by the CCTL. All platforms included in the ST were
included in the vendor test configuration and sufficiently represented in the evaluator test
configuration.
The DB2 security testing consisted of automated test procedures. The tests map to the
test cases outlined in ―IBM DB2 V9.7 Enterprise Server Edition Functional
Specification‖ and demonstrate the security-relevant behavior of DB2 at the interfaces
defined in the functional specification. These interfaces consist of the Command Line
User Interface, SQL Interface, API Interface, and the DRDA Interface.
The results of the evaluator testing demonstrated that DB2 meets the security functional
requirements specified in the Security Target. The security functions tested were those
described in the Security Target: Audit, User Data Protection, Identification &
Authentication, Security Management, and Protection of the TSF. Team tests for audit
and access control were performed with passing results. A penetration test for access
control (LBAC) was performed with a passing result. The evaluation team ensured the
Functional Specification substantiated the TSS in the evaluation of the functional
specification (rationale in the ADV_FSP work units). The evaluation team then ensured
the vendor‘s test approach and test suite completely addressed the functional
specification in its evaluation of the Test evidence (rationale in the ATE_COV work
units).
25
7 EVALUATED CONFIGURATION
IBM DB2 Enterprise Server Edition Version 9.7 for Linux, Unix, and Windows (the
TOE) is a Relational Database Management System (RDBMS) developed by IBM
Canada, Ltd., 8200 Warden Avenue East, Markham, Ontario L6G 1C7, Canada and sold
by IBM Corporation, Route 100, Somers, NY, USA 10589.
In the evaluated configuration, the TOE can be installed on the following platforms:
AIX 6
SuSE Linux Enterprise Server v10 with SP2
RedHat Linux (RHEL 5) update 2
Windows Server 2003 with SP2
Solaris 10
26
8 RESULTS OF THE EVALUATION
The evaluation was conducted based upon CC version 3.1 Revision 2 and CEM version
3.1 Revision 2. The evaluation determined the IBM DB2 TOE to be Part 2 extended and
Part 3 conformant, and that the TOE meets the Part 3 Evaluation Assurance Level (EAL
4) requirements augmented with ALC_FLR.1
8.1 Evaluation of the IBM DB2 Security Target (ST) (ASE)
The evaluation team applied each ASE CEM work unit. The ST evaluation ensured the
ST contains description of the environment in terms of policies and assumptions, a
statement of security requirements claimed to be met by the IBM DB2 product that
are consistent with the Common Criteria, and product security function descriptions
that support the requirements.
8.2 Evaluation of the Development (ADV)
The evaluation team applied each EAL 4 ADV CEM work unit. The evaluation team
assessed the design documentation and found it adequate to aid in understanding how the
TSF provides the security functions. The design documentation consists of a security
architecture description, a functional specification, basic modular design, and a sample of
the implementation representation. The evaluation team also ensured that the
correspondence analysis between the design abstractions correctly demonstrated that the
lower abstraction was a correct and complete representation of the higher abstraction.
Additionally, the evaluation team ensured that the security policy model document
clearly describes the security policy rules that were found to be consistent with the design
documentation.
8.3 Evaluation of the Guidance Documents (AGD)
The evaluation team applied each EAL 4 AGD CEM work unit. The evaluation team
ensured the adequacy of the user guidance in describing how to use the operational TOE.
Additionally, the evaluation team ensured the adequacy of the administrator guidance in
describing how to administer the TOE securely.
8.4 Evaluation of the Life Cycle Support Activities (ALC)
The evaluation team applied each EAL 4 ALC CEM work unit. The evaluation team
ensured the adequacy of the developer procedures to protect the TOE and the TOE
documentation during TOE development and maintenance to reduce the risk of the
introduction of TOE exploitable vulnerabilities during TOE development and
maintenance. The evaluation team ensured the procedures described the life-cycle model
and tools used to develop and maintain the TOE. The evaluation ensured the TOE is
identified such that the consumer is able to identify the evaluated TOE. The evaluation
team ensured the adequacy of the procedures used by the developer to accept, control and
27
track changes made to the TOE implementation, design documentation, test
documentation, user and administrator guidance, security flaws and the CM
documentation. The evaluation team ensured the procedure included automated support
to control and track changes to the implementation representation. The procedures reduce
the risk that security flaws exist in the TOE implementation or TOE documentation. The
evaluation ensured the adequacy of the procedures to deliver, install, and configure the
TOE securely.
The evaluation team also applied the ALC_FLR.1 related work units from the Flaw
Remediation CEM Supplement (Evaluation Methodology Supplement: ALC_FLR - Flaw
Remediation, Version 1.1, February 2002, CEM-2001/0015R). The evaluation team
ensured the developer has a process to track flaws, document flaws, address flaws, and
provide flaw information to TOE users.
8.5 Evaluation of the Test Documentation and the Test Activity (ATE)
The evaluation team applied each EAL 4 ATE CEM work unit. The evaluation team
ensured that the TOE performed as described in the design documentation and
demonstrated that the TOE security functional requirements are enforced by the TOE.
Specifically, the evaluation team ensured that the vendor test documentation
sufficiently addresses the security functions as described in the functional specification
and high level design specification. The evaluation team performed a sample of the
vendor test suite, and devised an independent set of team test and penetration tests. The
results of the vendor tests, team tests, and penetration tests substantiated the security
functional requirements in the ST.
8.6 Evaluation of the Vulnerability Assessment Activity (AVA)
The evaluation team applied each EAL 4 AVA CEM work unit. The evaluation team
ensured that the TOE does not contain exploitable flaws or weaknesses in the TOE based
upon the evaluation team‘s vulnerability analysis, and the evaluation team‘s performance
of penetration tests.
8.7 Summary of Evaluation Results
The evaluation team‘s assessment of the evaluation evidence demonstrates that the claims
in the ST are met. Additionally, the evaluation team‘s performance of a subset of the
vendor tests suite, the independent tests, and the penetration test also demonstrated the
accuracy of the claims in the ST.
8.8 Assurance Requirement Results
The assurance requirements for the TOE evaluation are those required by EAL4.
28
8.8.1 Common Criteria Assurance Components
The CEM work units associated with EAL4 are distributed amongst the ETR sections in
chapter 15 of the ETR. Collectively, the ETR sections in chapter 15 encompass all CEM
work units for EAL4. Each ETR section includes the CEM work units associated with
that ETR section title (e.g. ACM). Within each ETR section, for each CEM work unit the
following is provided:
Verdict
Verdict Rationale
The rationale justifies the verdict using the CC, the CEM, and any interpretations and the
evaluation evidence examined. The rationale demonstrates how the evaluation evidence
meets each aspect of the criteria.
The work performed contains a description of the action performed or the method used to
apply the work unit.
8.8.2 Testing and Vulnerability Assessment
In addition to ETR sections, the evaluators developed a Test Plan/Report Part to capture
the detail beyond the CEM work unit information. This detail is described within the
CEM guidance for the testing and vulnerability assessment work units. Primarily, the
additional detail is focused on team test procedures, penetration test procedures, results
from running the vendor‘s sample, and the justification of running the vendor‘s sample.
The evaluation team prepared a Draft of the Test Plan/Report prior to testing that
addressed the selection of vendor tests to run, the team test procedures, and the
penetration test procedures. After performing the test, the Test Report Part was updated
to include the actual results from the vendor sample run and the team test. The Test
Report is included in the ―IBM DB2 9.7 Part 2 Final ETR Proprietary‖ ETR document,
chapter "IBM DB2 Team Test Report".
8.9 Conclusions
The conclusions for the ST evaluations and the TOE evaluations are addressed below.
8.9.1 ST Evaluation
Each verdict for each CEM work unit in the ASE ETR is a ―PASS‖. Therefore, the
IBM DB2 Enterprise Server Edition version 9.7 Security Target is a CC compliant ST.
8.9.2 TOE Evaluation
The verdicts for each CEM work unit in the ETR sections included in chapter 15 are each
―PASS‖. Therefore, the IBM DB2 TOE (see below product identification) satisfies the
IBM DB2 9.7 Security Target, when configured according to the following guidance
documentation: Common Criteria Certification: Installing IBM DB2 Version 9.7
Enterprise Server Edition for Linux, UNIX, and Windows – Revision 7.
29
8.10 Summary of Evaluation Results
The evaluation team‘s assessment of the evaluation evidence demonstrates that the claims
in the ST are met. Additionally, the evaluation team‘s performance of a subset of the
vendor test suite, the independent tests, and the penetration test further demonstrated the
claims in the ST.
30
9 VALIDATOR COMMENTS AND RECOMMENDATIONS
This evaluation was primarily a maintenance upgrade, with two narrowly focused
changes that affected a few SFRs, and that were mostly independent from other product
functionality. The Validation Panel's observations support the evaluation team‘s
conclusion that the DB2 9.7 meets the claims stated in the Security Target. The
following are some recommendations and guidance for those integrating this product into a
system:
1. The audience should be aware of the impact of configuring the TOE to perform
synchronous vs. asynchronous auditing and note the benefits and drawbacks of
each approach. A characterization of the audit loss for asynchronous auditing can
be found in the Administration Guidance document.
2. There are limitations of the Encrypt/Decrypt UDF approach: namely, that this
function allows users to issue instructions to encrypt and decrypt data within DB2.
However, IBM generally discourages use of this function since there are a number
of known weaknesses (e.g., applicable passphrases are not adequately protected).
This function does not serve to allow any access controls, etc. to be violated, but
if users were to rely on this mechanism to protect data that would be a mistake.
Note that we have been informed it is only in the product due to some backward
compatibility issues (for product users).
3. There are limitations to the creation of user accounts and passwords in the
Operational environment passwords that might be of concern to the integrator.
These limitations can be found in the Administration Guidance documentation.
4. The audience should understand that the scope of the evaluation does not address
the protection of the connection to the LDAP or Kerberos servers (e.g. whether or
not is encrypted). This may of interest for the integrator.
5. Whether user clients echo passwords or not is not really under the control of the
DB2 server. DB2 cannot prevent users from building scripts and put passwords in
them. However, when using the provided client, the normal connection interfaces
would not echo passwords. It comes down to whether the product knows it is
dealing with a password at that point in time and there are areas where the product
does not know and hence cannot prevent echoing.
6. The audience should be aware of the implications of the access checking approach
for static and dynamic DML. Static DML packages appear to have access
checking performed only at the time of binding—at that time, the access is
checked for the user bound to that package. To use a given package, the user must
be explicitly authorized to do so. Specifically, DB2 checks if the user holds
EXECUTE privilege on the package. This is always checked.
7. DB2 also maintains privileges dependencies after a package is bound. If in the
future the user who bound the package loses any of the privileges they needed to
bind the package, that package becomes invalid and cannot be used unless it is
rebound by a user who has the required privileges. For Dynamic DML statements,
31
the privilege checking is performed for a user when the DML is initially prepared.
Subsequent executions for the same user have no privilege checking. Only if these
executions are within the same unit of work or in a different unit of work but there
were no changes. In other words, if a user prepares a statement and then loses the
privileges they needed to prepare that statement, the execution will re-prepare the
statement and it will fail if the user still lacks the needed privilege.
8. The scope of the evaluation assumes the administrator is at System High with
respect to the LBAC mechanism.
9. Although database commands are available through the CLP, such use is not in
accordance with administrative guidance and may introduce unknown risks.
10. Proper protection of the operating environment is important, as this was a key
assumption in the vulnerability testing.
11. Passwords used within scripts are stored in plaintext. As such, users and
administrators must ensure that such scripts are protected from unauthorized
disclosure.
12. The TOE records audit information in multiple audit logs (instance, database,
node, etc.). No mechanism is provided to obtain a unified view of these logs. It is
the responsibility of integrators of this product to provide appropriate audit log
integration and reduction tools.
13. The cryptography used in this product is provided by the IBM Global Security Kit
(GSKIT) component and the IBM Crypto for C (ICC) component. Both of which
were not analyzed within the scope of this evaluation. However, both
components have received Federal Information Processing Standard (FIPS) 140-2
validation.
32
10 SECURITY TARGET
The IBM Corporation DB2 Version 9.7 Enterprise Server Edition for Linux, Unix, and
Windows Security Target, version 1.0, 3 August 2009 is included here by reference.
33
11 ACRONYMS
CC Common Criteria
CCEVS Common Criteria Evaluation and Validation Scheme
CCTL Common Evaluation Testing Laboratory
CEM Common Evaluation Methodology
CM Configuration Management
DAC Discretionary Access Control
DDL Data Definition Language
DML Data Manipulation Language
DRDA Distributed Relational Database Architecture
EAL Evaluation Assurance Level
ETR Evaluation Technical Report
LBAC Label Based Access Control
NIAP National Information Assurance Partnership
NIST National Institute of Standards & Technology
NSA National Security Agency
NVLAP National Voluntary Laboratory Assessment Program
OS Operating System
PP Protection Profile
RDBMS Relational Database Management System
SFR Security Functional Requirement
SQL Structured Query Language
ST Security Target
TCSEC Trusted Computer System Evaluation Criteria
TOE Target of Evaluation
TSF TOE Security Function TSFI TOE Security Function Interface
34
12 BIBLIOGRAPHY
1. Common Criteria for Information Technology Security Evaluation – Part 1:
Introduction and general model, dated September 2007, Version 3.1 Revision 2
2. Common Criteria for Information Technology Security Evaluation – Part 2:
Security functional requirements, dated September 2007, Version 3.1 Revision 2
3. Common Criteria for Information Technology Security Evaluation – Part 3:
Security assurance requirements, dated September 2007, Version 3.1 Revision 2
4. Common Evaluation Methodology for Information Technology Security
Evaluation, Evaluation Methodology, dated September 2007, Version 3.1
Revision 2
5. Part 2: Evaluation Methodology, Supplement: ALC_FLR - Flaw Remediation,
Version 1.1, February 2002, CEM-2001/0015R
6. Evaluation Technical Report for IBM DB2 9.7 Part 2 (Proprietary), Revision 1.0
7. IBM Corporation DB2 9.7 Security Target, Revision 1.0, 3 August 2009.
8. NIAP Common Criteria Evaluation and Validation Scheme for IT Security,
Guidance to Common Criteria Testing Laboratories, Version 1.0, March 20,
2001