webMethods Fabric 6.5
EAL2 Common Criteria Evaluation
Security Target V1.0
12 December 2005
Prepared for:
webMethods, Inc.
3877 Fairfax Ridge Road,
Fairfax, VA 22030
http://www.webmethods.com/
Unclassified Controlled
Prepared by:
An Entrust Company
Suite 5200♦ 7925 Jones Branch Drive ♦ McLean, VA 22102-3305 ♦ 703 848-0883 ♦ Fax 703 848-0960
TABLE OF CONTENTS
SECTION PAGE
1 Security Target Introduction .................................................................................................1
1.1 Security Target Identification ..........................................................................................1
1.2 Security Target Overview ...............................................................................................1
1.3 Document Organization..................................................................................................1
2 TOE Description...................................................................................................................3
2.1 Product Type ..................................................................................................................3
2.2 How webMethods Fabric Works.....................................................................................3
2.3 webMethods Fabric Components...................................................................................4
2.3.1 webMethods Integration Server...............................................................................4
2.3.2 webMethods Broker.................................................................................................6
2.3.3 webMethods Adapters.............................................................................................6
2.3.4 webMethods Developer...........................................................................................7
2.4 TSF Physical Boundary and Scope of the Evaluation ....................................................8
2.5 Logical Scope and Boundary........................................................................................10
2.6 TOE Exclusions: ...........................................................................................................10
3 TOE Security Environment.................................................................................................13
3.1 Introduction...................................................................................................................13
3.2 Assumptions .................................................................................................................13
3.3 Threats..........................................................................................................................13
4 Security Objectives.............................................................................................................15
4.1 Security Objectives for the TOE ...................................................................................15
4.2 Security Objectives for the Environment.......................................................................15
4.2.1 Security Objectives for Non-IT Security Environment ...........................................16
5 IT Security Requirements...................................................................................................17
5.1 Formatting Conventions................................................................................................17
5.2 TOE Security Functional Requirements .......................................................................17
5.2.1 Class FAU: Security Audit .....................................................................................18
FAU_GEN.1 Audit data generation ..................................................................................18
FAU_SAR.1 Audit review .................................................................................................19
FAU_SAR.2 Restricted audit review ................................................................................19
FAU_SAR.3 Selectable audit review................................................................................19
FAU_SEL.1 Selective audit..............................................................................................19
5.2.2 Class FDP: User Data Protection..........................................................................20
FDP_ACC.1 Subset access control .................................................................................20
FDP_ACF.1 Security attribute based access control .......................................................20
5.2.3 Class FIA: Identification and Authentication..........................................................21
FIA_ATD.1 User attribute definition..................................................................................21
FIA_SOS.1 Verification of secrets....................................................................................22
FIA_UAU.5-1 Multiple authentication mechanisms..........................................................22
5.2.4 Class FMT: Security Management (FMT) .............................................................22
FMT_MOF.1 Management of Security Functions Behavior .............................................22
FMT_MSA.1 Management of security attributes..............................................................23
FMT_MSA.3 Static attribute initialisation..........................................................................24
FMT_MTD.1-1 Management of TSF data ........................................................................24
FMT_SMF.1 Specification of management functions.......................................................25
Security Target V1.0 12 December 2005
ii
FMT_SMR.1 Security roles ..............................................................................................25
5.2.5 Class FPT: Protection of the TOE Security Functions...........................................25
FPT_RVM_EXP.1-1 Non-bypassability of the TSP: TOE ................................................25
FPT_SEP_EXP.1-1 TSF domain separation: TOE ..........................................................26
5.2.6 Strength of Function ..............................................................................................26
5.3 IT Environment Security Assurance Requirements......................................................26
5.3.1 Class FAU: Security Audit .....................................................................................27
FAU_STG.1 Protected audit trail storage.........................................................................27
5.3.2 Class FIA: Identification and authentication ..........................................................27
FIA_UAU.5-2 Multiple authentication mechanisms..........................................................27
5.3.3 Class FMT: Security management ........................................................................28
FMT_MTD.1-2 Management of TSF data ........................................................................28
FPT_RVM_EXP.1-2 Non-bypassability of the TSP..........................................................28
FPT_SEP_EXP.1-2 TSF domain separation: IT ..............................................................28
FPT_STM.1 Reliable time stamps....................................................................................29
5.4 TOE Security Assurance Requirements.......................................................................29
6 TOE Summary Specification ..............................................................................................30
6.1 IT Security Functions....................................................................................................30
6.1.1 Security Audit Function..........................................................................................30
6.1.1.1 AU-1 Audit trail (FAU_GEN.1)........................................................................30
6.1.1.2 AU-2 Audit review (FAU_SAR.1)....................................................................31
6.1.1.3 AU-3 Restricted audit review (FAU_SAR.2)...................................................31
6.1.1.4 AU-4 Selectable audit review (FAU_SAR.3) ..................................................31
6.1.1.5 AU-5 Selective audit (FAU_SEL.1) ................................................................31
6.1.2 Access Control Policy............................................................................................31
6.1.2.1 AC-1 Access control function (FDP_ACC.1) (FDP_ACF.1) ...........................31
6.1.3 Identification and Authentication............................................................................34
6.1.3.1 IA-1 Security Attributes (FIA_ATD.1) .............................................................34
6.1.3.2 IA-2 Password Policy (FIA_SOS.1)................................................................35
6.1.3.3 IA-3 User authentication (FIA_UAU.5-1)........................................................35
6.1.4 Security Management............................................................................................35
6.1.4.1 SM-1 Management of Security Functions (FMT_MOF.1) ..............................35
6.1.4.2 SM-2 Management of security attributes (FMT_MSA.1) ................................36
6.1.4.3 SM-3 Default Values of Security Attributes (FMT_MSA.3).............................38
6.1.4.4 SM-4 Management of TSF Data (FMT_MTD.1-1)..........................................38
6.1.4.5 SM-5 Specification of Management Functions (FMT_SMF.1) .......................38
6.1.4.6 SM-6 Security Roles (FMT_SMR.1)...............................................................38
6.1.5 TSF Self-Protection ...............................................................................................39
6.1.5.1 SP-1 Non-bypassability (FPT_RVM_EXP.1-1) ..............................................39
6.1.5.2 SP-2 TSF domain separation (FPT_SEP_EXP.1-1) ......................................39
6.2 Assurance Measures....................................................................................................40
7 PP Claims ..........................................................................................................................43
8 Rationale ............................................................................................................................44
8.1 Security Objectives Rationale.......................................................................................44
8.1.1 Threats to Security ................................................................................................44
8.1.2 Assumptions..........................................................................................................48
8.2 Security Requirements Rationale .................................................................................50
Security Target V1.0 12 December 2005
iii
8.2.1 Functional Requirements.......................................................................................50
8.2.2 Dependencies........................................................................................................54
8.2.3 Rationale why dependencies are not met .............................................................55
8.2.4 Strength of Function Rationale..............................................................................55
8.2.5 Assurance Rationale .............................................................................................56
8.2.6 Rationale that IT Security Requirements are internally Consistent .......................56
8.2.7 Requirements for the IT Environment....................................................................57
8.3 TOE Summary Specification Rationale ........................................................................58
8.3.1 IT Security Functions.............................................................................................58
8.3.2 Assurance Measures.............................................................................................59
8.4 PP Claims Rationale.....................................................................................................61
8.5 Explicitly Stated Requirements Rationale.....................................................................61
9 Acronyms ...........................................................................................................................62
10 Bibliography .......................................................................................................................64
Security Target V1.0 12 December 2005
iv
Tables and Figures
Figures Page
Figure 2-1 – webMethods Architecture Diagram...........................................................................8
Figure 2-2 – Basic TOE Configuration with Physical Separation..................................................9
Figure 2-3 – Basic TOE Configuration with Procedural Separation..............................................9
Figure 2-4 – Reverse Invoke TOE Configuration........................................................................10
Figure 6-1 – Relationship of Users, Groups, ACLs, Folders, Services, and Ports......................33
Figure 6-2 – Relationship of Users, Groups, ACLs, .access Files and DSPs .............................33
Tables Page
Table 2-1 TOE Components .........................................................................................................4
Table 2-2 Product Components not Included in the TOE ...........................................................11
Table 3-1 Assumptions ...............................................................................................................13
Table 3-2 Threats........................................................................................................................14
Table 4-1 TOE Security Objectives.............................................................................................15
Table 4-2 Security Objectives for the IT Environment.................................................................15
Table 4-3 Security Objectives for Non-IT Security Environment.................................................16
Table 5-1 Functional Components.............................................................................................18
Table 5-2 IS Management of Security Functions Behavior.........................................................23
Table 5-3 IS Management of Security Attributes .......................................................................23
Table 5-4 IS Management of TSF Data ......................................................................................24
Table 5-5 IT Environment Functional Components....................................................................27
Table 5-6 TOE Management of TSF Data ..................................................................................28
Table 5-7 EAL2 Assurance Requirements..................................................................................29
Table 6-1 Service Logging Levels...............................................................................................30
Table 6-2 Access Privileges........................................................................................................34
Table 6-3 Default Password Policy Rules...................................................................................35
Table 6-4 IS Default User to Default Group Assignment ...........................................................36
Table 6-5 IS Default Group to ACL Mapping .............................................................................36
Table 6-6 IS Default Access Control Lists..................................................................................37
Table 6-7 EAL2 Assurance Requirements Measures.................................................................40
Table 8-1 All Threats to Security Countered..............................................................................44
Table 8-2 Reverse Mapping of TOE Security Objectives to Threats ..........................................47
Table 8-3 All Assumptions Addressed ........................................................................................48
Table 8-4 Environment Objective to Threat or Assumption Mapping..........................................49
Table 8-5 All Objectives Met by Functional Components ..........................................................50
Table 8-6 All Objectives Met by Functional Components Reversed..........................................53
Table 8-7 TOE Dependencies Satisfied.....................................................................................54
Table 8-8 IT Environment Dependencies are Satisfied..............................................................55
Table 8-9 All Objectives for the IT Environment map to Requirements in the IT environment ...57
Table 8-10 Mapping of Functional Requirements to TOE Summary Specification....................58
Table 8-11 Assurance Measures Rationale...............................................................................60
Table 8-12 EAL2 SAR Dependencies Satisfied.........................................................................60
Table 9-1 Acronyms....................................................................................................................62
Security Target V1.0 12 December 2005
v
1 Security Target Introduction
1.1 Security Target Identification
TOE Identification: webMethods Fabric 6.5
ST Title: webMethods Fabric 6.5 Security Target
ST Version: Security Target V1.0
ST Authors: Daniel DePrez
ST Date: 12 December 2005
Assurance Level: EAL2
Strength of Function: SOF-basic
Registration: VID10070-0001-MR
Keywords: Internet, Intranet, business integration, SSL, TLS, HTTP, FTP,
JDBC, JMS
1.2 Security Target Overview
This Security Target (ST) defines the Information Technology (IT) security requirements for
webMethods Fabric 6.5.
webMethods Fabric is a client/server application that provides access control of services
hosted on the webMethods Integration Server. The product facilitates the secure exchange of
data and logic among resources and supports the development and management of complex
business processes through web enabled or browser interfaces.
The TOE implements the following security functions: Information Flow, Identification &
Authentication, Security Management, and Self Protection. The TOE also supports auditing of
security functions.
The TOE is CC Part 2 extended, Part 3 conformant, and meets the requirements of Evaluation
Assurance Level (EAL) 2 from the Common Criteria Version 2.2, Rev 256 CCIMB-2004-01-
001 January 2004.
1.3 Document Organization
The main sections of an ST are:
the ST Introduction, Target of Evaluation (TOE) Description, TOE Security Envi-
ronment, Security Objectives, IT Security Requirements, TOE Summary Specification,
and Rationale.
Section 2, TOE Description, describes the product type and the scope and boundaries
of the TOE.
Section 3, TOE Security Environment, identifies assumptions about the TOE’s
intended usage and environment and threats relevant to secure TOE operation.
Section 4, Security Objectives, defines the security objectives for the TOE and its
environment.
Section 5, IT Security Requirements, specifies the TOE Security Functional
Requirements (SFR), Security Requirements for the IT Environment, and the Security
Assurance Requirements.
Security Target V1.0 12 December 2005
1
Section 6, TOE Summary Specification, describes the IT Security Functions and
Assurance Measures.
Section 7, Protection Profile (PP) Claims, is not applicable, as this product does not
claim conformance to any PP.
Section 8, Rationale, presents evidence that the ST is a complete and cohesive set of
requirements and that a conformant TOE would provide an effective set of IT security
countermeasures within the security environment. The Rationale has three main
parts:
o Security Objectives Rationale,
o Security Requirements Rationale, and
o TOE Summary Specification Rationale.
Sections 9 and 10 provide acronym definitions and bibliography.
Security Target V1.0 12 December 2005
2
2 TOE Description
2.1 Product Type
webMethods Fabric is a client/server application that provides access control of services
hosted on the webMethods Integration Server. The product facilitates the secure exchange of
data and logic among resources and supports the development and management of complex
business processes through browser or web enabled interfaces.
2.2 How webMethods Fabric Works
The TOE has two main components:
Integration Server (IS) – Enables access control over the integration logic throughout the
integrated applications.
Broker - a high-speed message router. Enables access control over asynchronous
messaging.
Other architectural components are included in the Target of Evaluation (TOE) and will be
introduced and discussed later.
The TOE implements the following security functions:
Access Control Policy - The flow of information is controlled between the external user
and the IS, and between the IS and the Broker in accordance with a Discretionary Access
Control (DAC) information flow control policy.
Identification & Authentication - Administrators are identified and authenticated by the
Target of Evaluation Security Functions (TSF). Administrator identification and
authentication (I&A) is through a user identifier and password. External users may also be
I&A by the TSF through a user identifier and password.
Security Management - One administrative role is supported. An Administrator can I&A
remotely with the IS and monitor and manage the interaction between external users. An
Administrator can also I&A with the Broker Server and manage the interaction between
TOE components, or I&A through the Developer interface and configure and develop
services or workflows.
Self Protection - The TOE environment ensures all information from a client to a host or a
host to a client goes through the TSF. The TSF ensures that all information must flow
through the policy enforcement mechanisms.
Security Audit – The TOE supports limited auditing of TOE security functions.
The TOE relies on the IT environment to provide Cryptographic Support. The TSF integrates
with and relies upon cryptographic support to protect all data sent between the external users
and the IS, mutually authenticate TOE Components, and optionally authenticate external
users.
The basic building blocks of an integration solution are documents (data) and steps (services
or workflows that carry out work) that an Authorized Administrator can assemble into multi-
step processes called flows.
Documents are objects that the webMethods Fabric uses to encapsulate and exchange data
among the participating resources and systems in an integration solution. Documents provide
the data on which services and workflows operate. In a general sense, a document represents
the body of data that a resource passes to the webMethods Fabric (or vice versa). For
Security Target V1.0 12 December 2005
3
example, a service that performs a database query requires a ‘document’ that contains a
query statement. This service would produce a ‘document’ containing the results of the query.
Documents that the webMethods Fabric handles are associated with a document type. A
document type is a named schema-like definition that describes the structure of a particular
kind of document. The webMethods Fabric uses document types to validate instances of
documents at run time, determine how a document is routed, and for internal access control
measures.
Services are method-like units of logic that operate on documents. They are executed on the
Integration Server. An Authorized Administrator builds services to carry out work such as
extracting data from documents, interacting with back-end resources (through adapters), and
publishing documents to the Broker (through Broker Clients). The Integration Server is
installed with an extensive library of built-in services for performing common integration tasks.
Services may be integrated using the webMethods Flow Language.
2.3 webMethods Fabric Components
The webMethods Fabric is made up of components to design, execute, and manage
integration solutions. Components fall into three basic categories: run-time components,
design-time components, and administrative interfaces. TOE components are identified in
Table 2-1. Excluded components are listed in Table 2-2.
Table 2-1 TOE Components
Component Type Description
Run-Time These components execute integration solutions. The TOE run-time
components are:
• webMethods Integration Server
• webMethods Broker
• webMethods Adapter (JDBC and JMS)
Design-Time These components provide tools for developing and testing integration
solutions. The TOE design-time component is:
• webMethods Developer
Administrative and
Monitoring Interface
Only the administrative interface of the TOE components is included in the
TOE. Explicitly, no distinct administrative component is included in the
evaluated configuration.
Rather the TOE will be administered by pointing a browser directly at an
Integration Server administrative interface. A specific package1
on the IS
will provide access to the Broker’s administrative interface.
2.3.1 webMethods Integration Server
webMethods Integration Server (IS) is the platform’s central run-time component and the
primary engine for the execution of integration logic. It is the main entry point for the systems
and applications. An extensive library of built-in services installed with the IS.
1
A Java package is a group of types. A type is either a class or an interface.
Security Target V1.0 12 December 2005
4
webMethods Integration Server plays the following key roles:
• Hosts adapters. The Integration Server hosts adapters, which are special modules
that link the back-end resources to the webMethods Fabric. Adapters interact directly
with the integrated applications and systems. A single Integration Server can host
zero or more adapters. The TOE includes two adapters, one for JDBC (to Oracle,
Microsoft SQL Server, or other database servers) and one for JMS.
• Serves as a business-to-business gateway. The Integration Server is the external
interface between the webMethods Fabric and systems outside the enterprise. It
provides the underlying support for transporting and encoding business documents
using the open standards of the Internet. In the evaluated configuration, the TOE
supports the application protocols HTTP, HTTPS, FTP, and FTPS. However, in
general, it may host modules that provide support for e-commerce standards such as
EDI, RosettaNet, and ebXML.
• Executes integration logic. Integration logic is housed in units called services. The
Integration Server performs the work of retrieving data from one resource and
delivering it to another by executing integration logic. Services are also used to
perform administrative functions, such as adding a new user or configuring a new
HTTP port. Services, other than those built in to the Integration Server, are not part of
the TOE.
• Access Control Mechanisms - The Integration Server provides access control
mechanisms, which collectively restrict access to services, folders, and ports based on
the groups to which users belong, their IP address and their credentials. The access
control mechanisms are implemented both on the TCP port the user accesses the
TOE through and the resource the user is attempting to access. Access to a port is
controlled both through the presumed IP address and the Integration Server service.
Access to the Integration Server resources is controlled at the group level.
• webMethods Administrator Interface - An Authorized Administrator is able to point
an HTML-based browser at any Integration Server in order to manage the server and
its functions remotely. The webMethods Administrator interface is used by authorized
users to:
• Maintain the Client Certificate store.
• Create the Integration Server users’ accounts (and passwords), user groups
and access control lists of user groups. User accounts are assigned to the
appropriate groups by the Authorized Administrator.
• Set IP connection level security. The Authorized Administrator may define a list
of IP addresses and domain names that may access the TOE through a
configured port. IP addresses and domain names may contain wildcards.
• Set service connection level security. The Authorized Administrator may define
a list of services that are permitted for a given configured port. Services may
contain wildcards. This capability does not extend to other Integration Server
resources such as server pages.
• Set service level security. The Authorized Administrator may define a list of
users that are permitted access to an installed service.
• Access the webMethods Broker Administrator interface through the IS if the
Broker Administrator package has been installed on the IS.
Security Target V1.0 12 December 2005
5
2.3.2 webMethods Broker
The role of a Broker is to route documents between information producers (publishers) and
information consumers (subscribers). In the webMethods Fabric evaluated configuration,
Integration Servers function as both publishers and subscribers. They interact with the Broker
using a proprietary protocol. In the evaluated configuration, the webMethods Broker is
considered to be an internal TOE component having only one external interface: an
Authorized Administrator accessing the Broker components configuration files through the IT
environment host OS.
webMethods Broker is a high-speed message router. It is the primary component of what is
generally referred to as the platform's “message backbone” or “message facility.” Along with
supporting features provided by the other components, webMethods Broker facilitates
asynchronous, message-based solutions using the publish-and-subscribe model.
The publish-and-subscribe model is a specific type of message-based solution in which
resources exchange messages (carrying documents) anonymously through a message
broker. Under this model, applications that produce information make that information
available in specific types of documents that they publish to a Broker. Applications that
require information subscribe to the specific types of documents that they need.
The Broker maintains a list of subscribers that are interested in receiving certain types of
documents. When a component publishes a document, the Broker queues the document for
the subscribers of that particular document type. When a subscriber receives a document
from its queue, an action is triggered on the subscriber’s system that processes the document.
The evaluated configuration contains a single Broker only. However, a webMethods Fabric
can contain multiple Brokers that operate in groups called territories.
The webMethods Broker Server Administrative interface (accessible in the evaluated
configuration through the Integration Server) exposes the following security functionality:
• Permit or Deny based on the Client Certificate store Distinguished names.
• Guaranteed transactions - ensures that a document reaches its subscribers
queue or it is never published (included in the TOE, but not claimed as security
relevant).
• Provides Publish and Subscribe functionality across multiple server instances.
(when multiple resources need to obtain information from the same
transaction).
• Filter transactions, based on fields within the document (included in the TOE,
but not claimed as security relevant).
In the evaluated configuration, the Broker has limited security functionality.
2.3.3 webMethods Adapters
Adapters run on the Integration Server. They connect the back-end resources in an
enterprise (for example, a customer database, a Human Resources application, an inventory
system) to the webMethods Fabric. The nature of the connection created through an adapter
is that the Integration Server plays the role of client and initiates all transactions with the back-
end resource.
The adapter handles the low-level work of connecting to the resource, managing
communications, encoding and decoding data, and invoking processes via the resource’s API,
thus allowing the incorporation of a resource in an integration solution without having to build
Security Target V1.0 12 December 2005
6
complex custom code or understand the low-level details of the resource or its application
protocol.
An Integration Server requires an adapter for each type of resource with which it interacts.
While webMethods provides adapters for a broad range of databases and business systems,
the TOE contains adapters for JDBC and JMS only.
2.3.4 webMethods Developer
webMethods Developer is a graphical development tool that an Authorized Administrator uses
to build, edit, and test integration logic. It provides an integrated development environment in
which to develop the logic and supporting elements that carry out the work of an integration
solution. It also provides tools for testing and debugging solutions.
webMethods Developer lets an Authorized Administrator rapidly construct integration logic
with an implementation language called the webMethods Flow Language, or flow. Flow
provides a set of simple but powerful constructs that an Authorized Administrator uses to
specify a sequence of actions (steps) that the Integration Server will execute at run time.
Coupled with the Developer’s graphical user interface and its drag-and-drop data mapping
capability, flow allows an Authorized Administrator to quickly develop integration logic without
low-level coding.
Although an Authorized Administrator can implement most integration solutions using flow and
the Integration Server’s library of built-in services, an Authorized Administrator can also build
services using Java, C/C++, or Visual Basic (or any other COM/DCOM-based component) if
the solution requires specialized integration logic that the webMethods Fabric does not
provide out of the box. User built services are not included in the TOE. Only flow will be used
in testing the TOE.
Developer also provides specialized editors for creating logic for specific run-time components
and facilities. For example, it supplies the tools an Authorized Administrator uses to create
and manage:
• Adapter services — Services that invoke specific processes on a back-end resource
(for example, query an customer database, post a journal entry to a general ledger
application, or delete an item from an inventory system).
• Adapter notifications — Alerts that are issued by back-end systems and for which
the webMethods Fabric initiates an action after polling.
• Web service connectors — Proxy services that allow the webMethods Fabric to
invoke Web services located on remote servers (not included in the TOE, except as
required to support the Reverse Invoke Server (see Figure 2-4)).
• Adding Groups to ACL — The Developer is responsible for assigning ACL to the
appropriate resource or resource folder.
The TOE test configuration will include adapter services and adapter notifications created with
the supplied tools for the JDBC adapter and the JMS adapter.
Security Target V1.0 12 December 2005
7
Figure 2-1 – webMethods Architecture Diagram
2.4 TSF Physical Boundary and Scope of the Evaluation
Only the shaded parts of Figure 2-1 are included in the TOE. The TOE includes the following:
• Integration Server
• Broker
• Developer
• Adapters (selected JDBC and JMS)2
The evaluated configuration will be tested on the following platforms:
• Two instances of webMethods Integration Server 6.5 and Adapters running on a two
separate machines;
• webMethods Broker 6.5 running on a separate machine;
For purposes of testing, all three machines will be Intel or compatible hardware running a MS
Windows Operating System (OS). The Integration Server systems will use the IBM 1.3.1 JRE.
2
Adapters rely on 3rd
party software (drivers) which is not part of the TOE.
Security Target V1.0 12 December 2005
8
The webMethods Fabric is based on a distributed architecture, which allows the platform to
grow. Because the TOE relies on the IT environment to provide secure communications
(OE.ProtectComm), and it is not possible to predict which IT environment the end-user will
require, several TOE configurations are discussed.
The evaluated configuration will cover configurations with:
1) Two Integration Servers and a Broker with users physically segregated from the
webMethods Fabric platform and its associated servers (Figure 2-2). In this diagram,
only the left most Integration Server has an interface to external users, the Broker and
right most Integration Server are on a protected LAN.
2) Two Integration Servers and a Broker with users of the webMethods Fabric and its
associated servers procedurally segregated (e.g., through encryption or trust) from the
TOE (Figure 2-3). In this diagram the Broker and both Integration Servers are
externally visible. For this configuration, the IT environment would have to protect
network connections.
3) Two Integration Servers and a Broker running procedurally segregated users from
behind a VPN (Figure 2-4). The Reverse Invoke server shown in this diagram is not
part of the TOE. In this configuration, the TOE is accessed through a firewall and may
not be directly connected to by external users.
Figure 2-2 – Basic TOE Configuration with Physical Separation
Internal
Figure 2-3 – Basic TOE Configuration with Procedural Separation
Internal
Security Target V1.0 12 December 2005
9
Figure 2-4 – Reverse Invoke TOE Configuration
2.5 Logical Scope and Boundary
webMethods Fabric provides the following security features:
• Security audit - webMethods Fabric provides the ability to audit the events.
webMethods Fabric provides the ability for an Authorized Administrator to read the
audit logs.
• User data protection - webMethods Fabric enforces a information flow control policy
to control access to services and documents. The webMethods IS access control
policy is based on user roles and groups.
• Identification and Authentication - The TOE supports user identification and
authentication through the use of user accounts and passwords. webMethods Fabric
also integrates with the certificate-based authentication of external users provide by
the IT environment.
• Security Management – An administrator can authenticate with the TOE and monitor
and manage the interaction between end-users and TOE components. Two
administrative interfaces are provided, one for the Integration Server and one for the
Broker, but both interfaces are accessed by connection to the Integration Server.
• Partial protection of TSF (TOE) - webMethods Fabric protects its programs and data
from unauthorized access through its own interfaces. The TSF ensures that all
information that flows through it must flow through the policy enforcement
mechanisms.
2.6 TOE Exclusions:
• Third party relational database (Oracle, SQL Server, or DB2 via JDBC, JMS providers)
• The interface (drivers) of the third party relational database
• Transport standard HTTP, HTTPS, FTP and FTPS implementations
• Message format MIME and S/MIME implementations
• Underlying operating system (OS) software and hardware
• Java Virtual Machine (JVM)
• Third-party encryption software that is used to provide a trusted communication path
between external users and the TOE;
• Third-party encryption software that is used between TOE Components and the web
browser that is used to connect to the Integration Server for administration purposes,
Security Target V1.0 12 December 2005
10
• Web browser that is used to connect to the Integration Server for administration
purposes
• Clustered configurations
• Territories
• Reverse Invoke Server
LDAP and NIS servers are explicitly excluded from the evaluated configuration.
Product components that are not within the scope of the evaluation are listed in Table 2-2.
Packages corresponding to these components are not loaded in the evaluated configuration.
Table 2-2 Product Components not Included in the TOE
Component Type Description
Additional product run-time components include
webMethods Mainframe
webMethods Trading Networks and eStandard Modules
Run-Time
webMethods Workflow
Additional product design-time components include
webMethods Modeler
webMethods Workflow Designer
Design-Time
webMethods Trading Networks Console
Additional product administrative components include
webMethods Administrator (Administrative Server)
webMethods Monitor
Administrative and
Monitoring
webMethods Manager
Cryptographic Support - All network communications between webMethods Fabric
components are encrypted. Since third party software is used to provide confidentiality, the
encryption functions are not part of the TOE. The TOE relies on the IT environment to provide
cryptographic support. The TOE security environment can be categorized as follows:
• Entrust Authority Security Toolkit for Java 7.0 provides cryptographic services
for external users connecting to the IS and for the Developer to connect to the
IS.
• Spyrus SSL Toolkit provides cryptographic services connections between TOE
components where one of the components is a Broker Server (i.e., between
Broker and Integration Server), or when the Authorized Administrator connects
to the TOE remotely. This provides encryption to prevent disclosure of TSF
data.
webMethods Fabric relies upon support from the IT environment for:
• Reliable time stamps
• Support of Domain separation from the host OS
• Support of Non-bypassability from the host OS
• Protection of the webMethods Fabric hosts from other interference or
tampering.
Security Target V1.0 12 December 2005
11
• protection of data transfer between TOE components and for the trusted
communication path between authorized account holders and the TOE
(encryption software)
• for the web browser functionality needed for the GUI,
• for secure TSF data storage (specifically the TOE relies on the operating
system to prevent an attacker from accessing TSF data through the operating
system interfaces.)
• access to TOE configuration files.
Security Target V1.0 12 December 2005
12
3 TOE Security Environment
3.1 Introduction
This chapter identifies the following:
• Significant assumptions about the TOE’s operational environment.
• IT related threats to the organization countered by the TOE.
Using the above listing, this chapter identifies threats (T), assumptions (A).
3.2 Assumptions
This section contains assumptions regarding the security environment and the intended usage
of the TOE. The specific conditions listed in the following subsections are assumed to exist in
the TOE environment. These assumptions include both practical realities in the development
of the TOE security requirements and the essential environmental conditions on the use of the
TOE.
Table 3-1 Assumptions
Identifier Assumption
A.Admin The administrator is trusted to correctly configure and operate the TOE according to
the instructions provided by the TOE documentation.
A.Manage It is assumed that one or more administrators are assigned who are competent to
manage the TOE and the security of the information it contains, and who can be
trusted not to deliberately abuse their privileges so as to undermine security.
A.NoUntrusted It is assumed that there will be no untrusted software on the webMethods Integration
Server and Broker.
A.Physical The TOE components critical to the security policy enforcement will be protected
from unauthorized physical modification.
A.Users It is assumed that users will protect their authentication data.
A.IT The TOE relies upon the IT environment to support protected communications,
provide audit file protection, support partial domain separation, support non-
bypassability, provide reliable time-stamps, and to perform user authentication when
configured to do so.
3.3 Threats
Table 3-2 identifies the threats to the TOE. A strength of function level of SOF-basic,
consistent with a CC evaluated level of assurance of EAL2, counters an attack level of low;
the threat agents are users with public knowledge of how the TOE operates, with access to
only standard equipment. Since the TOE includes a public interface, an attacker is considered
to have access to the TOE. Mitigation to the threats is through the objectives identified in
Section 4, Security Objectives.
Security Target V1.0 12 December 2005
13
Table 3-2 Threats
Identifier Threat
T.Abuse An undetected compromise of the TOE may occur as a result of an authorized
user of the TOE (intentionally or otherwise) performing actions the individual is
authorized to perform.
T.Access An authorized user of the TOE may access information or resources without
having permission from the person who owns, or is responsible for, the information
or resource.
T.Bypass An unauthorised user may attempt to bypass the information flow control policy.
T.Intercept An unauthorized person on an internal network that connects TOE components
may intercept communications between the TOE components and attempt to
access and/or modify the data being transmitted.
T.Mismanage Authorized Administrators may make errors in the management of security
functions and TSF data. Administrative errors may allow attackers to gain
unauthorized access to resources protected by the TOE.
T.Tamper An attacker may attempt to modify TSF programs and data.
T.Transmit TSF data may be disclosed or modified by an attacker while being transmitted
between the TOE and its users.
T.Undetect Attempts by an attacker to violate the security policy may go undetected. If the
attacker is successful, TSF data may be lost or altered.
Security Target V1.0 12 December 2005
14
4 Security Objectives
4.1 Security Objectives for the TOE
The security objectives for the TOE are as follows:
Table 4-1 TOE Security Objectives
Identifier Objective
O.Access The TOE must allow authorized users to access only appropriate TOE
functions and data.
O.Admin The TOE must provide the functionality to enable authorized user(s) to
effectively manage the TOE and its security functions.
O.Attributes The TOE must be able to maintain user security attributes.
O.Audit The TOE must provide a means to record a readable audit trail of
security-related events, with accurate dates and times.
O.AuditProtection The TOE must provide the capability to protect audit information.
O.AuditReview The TOE must provide the functionality to enable authorized user(s) to
review the audit logs.
O.IDAuth The TOE must be able to identify and authenticate the users prior to
allowing access to TOE functionality.
O.NonBypass The TOE must ensure the TOE’s security functional policy is invoked and
succeeds before allowing another TOE function to proceed.
O.PartialSelfProtection The TSF will maintain a domain for its own execution that protects itself
and its resources from external interference, tampering or unauthorized
disclosure, through its own interfaces.
O.RemoteAdministration An identified and authorized remote administrator may manage identified
TSF entities from a remote client.
4.2 Security Objectives for the Environment
The security objectives for the IT environment are as follows:
Table 4-2 Security Objectives for the IT Environment
Identifier Objective
OE.Audit The IT environment must provide a means to record a readable audit trail of
security-related events, with accurate dates and times.
OE.AuditProtection The IT environment will provide the capability to protect audit information.
OE.IDAuth3
The IT environment must be able to identify and authenticate users prior to
allowing access to IT environment functions and data.
OE.NonBypass The IT environment must ensure the IT environment’s security functional
policy is invoked and succeeds before allowing another IT environment
function to proceed.
OE.PartialSelfProtection The IT Environment will maintain a domain for its own execution that
protects itself and its resources from external interference, tampering, or
unauthorized disclosure, through its own interfaces.
3
This applies only to Administrators who log into the IT environment directly through the system
console to perform administrative functions related to the product
Security Target V1.0 12 December 2005
15
Identifier Objective
OE.ProtectComm4
The IT environment must protect communications between the TOE and its
users, and between TOE components.
OE.Time The underlying operating system must provide reliable time stamps.
4.2.1 Security Objectives for Non-IT Security Environment
The Non-IT security objectives are as follows:
Table 4-3 Security Objectives for Non-IT Security Environment
Identifier Objective
ON.Install Those responsible for the TOE must ensure that the TOE is delivered and installed
in a manner that maintains IT security.
ON.NoUntrusted The administrator must ensure that there is no untrusted software on the
webMethods Integration Server and Broker.
ON.Operations The TOE will be managed and operated in a secure manner as outlined in the
supplied guidance.
ON.Person Personnel working as authorized administrators shall be carefully selected and
trained for proper operation of the system.
ON.Physical Those responsible for the TOE must ensure that those parts of the TOE critical to
the security policy are protected from any physical attack.
ON.ProtectAuth Users must ensure that their authentication data is held securely and not disclosed
to unauthorized persons.
4
Application Note: This objective may be met by the IT environment in a number of ways: The IS server
may be behind a firewall that implements a VPN through which external users communicate; The IS
server could require client to connect using HTTPS or FTPS; In a closed environment communication
could be protected via physical measures.
Security Target V1.0 12 December 2005
16
5 IT Security Requirements
This section provides the TOE security functional and assurance requirements. In addition,
the IT environment security functional requirements on which the TOE relies are described.
These requirements consist of functional components from Part 2 of the CC, assurance
components from Part 3 of the CC, and CCIMB Final Interpretations.
5.1 Formatting Conventions
The notation, formatting, and conventions used in this security target (ST) are consistent with
version 2.2 of the Common Criteria for Information Technology Security Evaluation. Font style
and clarifying information conventions were developed to aid the reader.
The CC permits four functional component operations: assignment, iteration, refinement, and
selection to be performed on functional requirements. These operations are defined in
Common Criteria, Part 1, Section 4.4.1.3.2 as:
• assignment: allows the specification of an identified parameter in a component;
• refinement: allows the addition of details or the narrowing of requirements;
• selection: allows the specification of one or more elements from a list; and
• iteration: allows a component to be used more than once with varying operations.
This ST indicates which text is affected by each of these operations in the following manner:
• Assignments and Selections specified by the ST author are in [italicized bold text].
• Refinements are identified with "Refinement:" right after the short name. Additions to
the CC text are specified in italicized bold and underlined text.
• Iterations are identified with a dash number "-#". These follow the short family name
and allow components to be used more than once with varying operations. “*” refers to
all iterations of a component. For clear identification purposes, the base component id
is used and a “: additional information” is after the component title. For example,
FPT_SEP.1-1 TSF domain separation: TOE.
• Application notes provide additional information for the reader, but do not specify
requirements. Application notes are denoted by italicized text.
• NIAP and CCIMB Interpretations have been reviewed. Relevant Interpretations are
included and are noted in Interpretation Notes. Interpretation Notes are denoted by
italicized text. The original CC text modified by the interpretation is not denoted nor
explained.
• Explicit SFR are identified by appending _EXP to the SFR name.
• Comments are provided as an aid to the reader and evaluation team. These items will
be deleted in the final version of the ST.
5.2 TOE Security Functional Requirements
The functional security requirements for the TOE consist of the following components derived
from Part 2 of the CC, CC interpretations, explicitly stated SFRs derived from the CC Part 2,
and NIAP interpretations as appropriate, summarized in the Table 5-1 below. This section
contains the TOE Functional components for the webMethods TOE. The TOE claims a
minimum strength level for the TOE security functions of SOF-basic.
Security Target V1.0 12 December 2005
17
Table 5-1 Functional Components
Component Component Name
FAU_GEN.1 Audit data generation
FAU_SAR.1 Audit review
FAU_SAR.2 Restricted audit review
FAU_SAR.3 Selectable audit review
FAU_SEL.1 Selective audit
FDP_ACC.1 Subset access control
FDP_ACF.1 Security attribute based access control
FIA_ATD.1 User attribute definition
FIA_SOS.1 Verification of secrets
FIA_UAU.5-1 Multiple authentication mechanisms
FMT_MOF.1 Management of Security Functions Behavior
FMT_MSA.1 Management of security attributes
FMT_MSA.3 Static attribute initialisation
FMT_MTD.1 Management of TSF data
FMT_SMF.1 Specification of management functions
FMT_SMR.1 Security roles
FPT_RVM_EXP.1-1 Non-bypassability of the TSP: TOE
FPT_SEP_EXP.1-1 TSF domain separation: TOE
5.2.1 Class FAU: Security Audit
FAU_GEN.1 Audit data generation
Hierarchical to: No other components.
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;
b) All auditable events for the [not specified] level of audit; and
c) [the following auditable events:
o Reading of information from the audit records
o Unsuccessful attempts to read information from the audit records
o Modification of the audit configuration that occur while the audit
collection functions are operating
o All requests to perform an operation on a package, folder, service,
flow service, specification, schema, document type, or trigger
o Rejection by the TSF of any tested secret
o Modification of the behaviour of the functions in the TSF
o Modification of the values of security attributes
o Modification of the default setting of permissive or restrictive rules
o Modification of the initial values of security attributes
Security Target V1.0 12 December 2005
18
o All modification of the values of TSF data
o Use of the management functions
o Modification of the group of users that are part of a role
]
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, 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: [none].
Dependencies: FPT_STM.1 Reliable time stamps
FAU_SAR.1 Audit review
Hierarchical to: No other components.
FAU_SAR.1.1 The TSF shall provide [an Authorized Administrator] with the capability to
read [all audit data] from the audit records.
FAU_SAR.1.2 The TSF shall provide the audit records in a manner suitable for the user to
interpret the information.
Dependencies: FAU_GEN.1 Audit data generation
FAU_SAR.2 Restricted audit review
Hierarchical to: No other components.
FAU_SAR.2.1 The TSF shall prohibit all users read access to the audit records, except those
users that have been granted explicit read-access.
Dependencies: FAU_SAR.1 Audit review
FAU_SAR.3 Selectable audit review
Hierarchical to: No other components.
FAU_SAR.3.1 The TSF shall provide the ability to perform [searches, ordering] of audit data
based on [the number of audit log entries to be displayed, oldest to newest starting
from the beginning, newest to oldest starting from the end].
Dependencies: FAU_SAR.1 Audit review
FAU_SEL.1 Selective audit
Hierarchical to: No other components.
FAU_SEL..1.1 The TSF shall be able to include or exclude auditable events from the set of
audited events based on the following attributes:
a) [level of logging].
Dependencies: FAU_GEN.1 Audit data generation
FMT_MTD.1 Management of TSF data
Security Target V1.0 12 December 2005
19
5.2.2 Class FDP: User Data Protection
FDP_ACC.1 Subset access control
Hierarchical to: No other components.
FDP_ACC.1.1 The TSF shall enforce the [webMethods IS Access Control SFP] on
[subjects:
connections on behalf of external users,
triggers on behalf of adapters
objects:
(port, IS element) pairs,
IS element,
where an IS element is one of: package, folder, service, flow service,
specification, schema, document type, or trigger
operations among subjects and objects covered by the SFP: execute, list, read, and
write.]
Application Note: This describes the access control mechanism that constrains an IS element
(object) to be accessed only via connections to specified ports and for a given operation,
without reference to subject security attributes (such as UID). The SFR identified two subjects
of this policy. An “external user” is a user that accesses the TOE through a network
connection. An adapter is a TOE component that provides a notification when a message
arrives from a specific monitored destination. If the notification is configured to publish a
document, an IS trigger can monitor for that document and invoke a flow or Java service
registered with the trigger. When a trigger associated with an adapter invokes a flow or Java
service, it does so with the privilege associated with a configured default UID.
Dependencies: FDP_ACF.1 Security attribute based access control
FDP_ACF.1 Security attribute based access control
Hierarchical to: No other components.
FDP_ACF.1.1 The TSF shall enforce the [webMethods IS Access Control SFP] to objects
based on the following: [
Subjects: connections on behalf of external users,
triggers on behalf of adapters:
Subject security attributes:
1. Default UID for Triggered objects
2. Real UID of an external user
3. Group Memberships
4. Presumed IP address
5. Port
Objects: (port, IS element) pairs
Object security attributes:
1. set of IP addresses allowed for the port,
Security Target V1.0 12 December 2005
20
2. set of services allowed for the port,
3. Access control list (ACL) on IS element.
Objects: IS element
Object security attributes:
Access control list (ACL) on IS element].
Application Note: If a user is permitted to invoke an object thru a given port (see
FDP_ACC.1), then the access control mechanism constrains an IS element (object) to be
accessed for a given subject’s security attributes and object security attributes (IP address,
service, and ACL).
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. A connection subject may access an object provided:
1. Presumed IP address of the subject is in the set of IP addresses allowed for
the port, and
2. When the IS element is a service, the service is in the set of services allowed
for the Listening Port, and
3. A Group Membership associated with the UID is allowed by the ACL for the
IS element, and
4. The operation is permitted by the ACL for the Group Membership on the IS
element]
B. A trigger subject may access an object provided:
1. Default UID for Triggered Services or event has a Group Membership that is
allowed by the ACL for the IS element
2. The execute operation is permitted by the ACL for the Group Membership on
the IS element]
FDP_ACF.1.3 The TSF shall explicitly authorise access of subjects to objects based on the
following additional rules: [None]
FDP_ACF.1.4 The TSF shall explicitly deny access of subjects to objects based on the
following rules: [no additional explicit denial rules].
Dependencies: FDP_ACC.1 Subset access control
FMT_MSA.3 Static attribute initialization
5.2.3 Class FIA: Identification and Authentication
FIA_ATD.1 User attribute definition
Hierarchical to: No other components.
FIA_ATD.1.1 The TSF shall maintain the following list of security attributes belonging to
individual users:
• [User Name,
• Group Memberships
Security Target V1.0 12 December 2005
21
• Password
• X.509 certificate attributes].
Dependencies: No dependencies.
FIA_SOS.1 Verification of secrets
Hierarchical to: No other components.
FIA_SOS.1.1 The TSF shall provide a mechanism to verify that secrets meet [the rules of the
password policy]
Dependencies: No dependencies.
FIA_UAU.5-1 Multiple authentication mechanisms
Hierarchical to: No other components.
FIA_UAU.5.1-1 –The TSF shall provide [password based authentication mechanisms] to
support user authentication.
FIA_UAU.5.2-1 – The TSF shall authenticate any user's claimed identity according to the
[following multiple authentication mechanism rules:
a) Reusable password in combination with Server Certificate based
authentication mechanism provided by the IT environment shall be used
for unauthenticated users sending information to or receiving information
from TOE using HTTPS or FTPS such that successful authentication must
be achieved before allowing any other TSF-mediated actions on behalf of
that user;
b) Reusable password based authentication mechanism shall be used for
unauthenticated users sending or receiving information to the TOE
through a external VPN gateway using HTTP or FTP such that successful
authentication must be achieved before allowing any other TSF-mediated
actions on behalf of that human user; ]
Dependencies: No dependencies
Application Note: Case a) applies to connections made by an external user (or another IS
external to the TOE) to the IS where the IT environment did not authenticate the client with
certificate based authentication. Case b) applies to clients connecting to the IS through a VPN
tunnel.
5.2.4 Class FMT: Security Management (FMT)
FMT_MOF.1 Management of Security Functions Behavior
Hierarchical to: No other components.
FMT_MOF.1.1 The TSF shall restrict the ability to [enable, disable, determine the behavior
of] the functions [the Operation in Table 5-2] to [the Authorized Administrator].
Dependencies: FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions (CCIMB 065)
Security Target V1.0 12 December 2005
22
Table 5-2 IS Management of Security Functions Behavior
Security
attribute
Operation Nominal
Authorized Role5
ACL option
setting
which direct the server to check or ignore a service’s ACL
when the service is internally invoked
Developers
element triggers by enabling or disabling them Administrators and
Developers (Internal
ACL)
events Of services by configuring and scheduling them to run in
response to events
Developers
package assign dependencies of packages Developers
package To: reload, enable ,disable, delete, recover and archive a
package
Administrators
package To assign, startup, shutdown replication services and to
perform replication of packages
Replicator
package. To: reload, delete and copy a package Developers
password To enable non administrative users to change their
passwords
Administrators
scheduled user
task
To: Cancel, temporarily suspend, view a list of and update
the scheduling options of a scheduled user task
Administrators
server To connect to a server Administrators
server To connect webMethods Developer to the server Developers
triggers To configure the user account used to execute services
invoked by triggers
Administrators
user To specify how the server authenticates users Administrators
FMT_MSA.1 Management of security attributes
Hierarchical to: No other components.
FMT_MSA.1.1 The TSF shall enforce the [webMethods IS Access Control SFP] to restrict
the ability to [query, modify, delete, [other operations as specified in Table 5-3]] the
security attributes [as specified in Table 5-3] to [the Authorized Administrator].
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 (CCIMB 065)
Table 5-3 IS Management of Security Attributes
Operation Security
attribute
Nominal
Identified
Role6
Associate and disassociate with IS elements an ACL Administrators
or Developers
Query and edit access specification associated with ACL. Developers
5
The various Administrative role nominally described in the product documentation (Administrator,
Broker Administrator, Developer, Replicator) are all treated as a single Administrative role.
6
The various Administrative role nominally described in the product documentation (Administrator,
Broker Administrator, Developer, Replicator) are all treated as a single Administrative role.
Security Target V1.0 12 December 2005
23
Operation Security
attribute
Nominal
Identified
Role6
Query and Edit groups in ACL. Administrators
Create and delete ACL that control access to elements Administrators
Create, remove, query and edit UID in a Group Administrators
Query and edit access mode and services for listening ports. Administrators
Query and edit IP access settings for listening ports. Administrators
Assign passwords to, create, list, enable, disable and delete UIDs. Administrators
FMT_MSA.3 Static attribute initialisation
Hierarchical to: No other components.
FMT_MSA.3.1 The TSF shall enforce the [webMethods IS Access Control SFP] to provide
[restrictive] default values for security attributes that are used to enforce the SFP.
FMT_MSA.3.2 The TSF shall allow the [Authorized Administrator] to specify alternative
initial values to override the default values when an object or information is created.
Dependencies: FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
FMT_MTD.1-1 Management of TSF data
Hierarchical to: No other components.
FMT_MTD.1.1-1 The TSF shall restrict the ability to [query, modify, delete, [and other
operations as specified in Table 5-4]] the [TSF Data as specified in Table 5-4] to [the
Authorized Administrator].
Table 5-4 IS Management of TSF Data
Operation TSF Data Nominal Identified
Role7
Query and edit primary setting of listening port Administrators
Configure, associate specific protocol, add, and enable listening ports Administrators
Create, assign version numbers package Developers
Configure, associate specific directory, add, remove,
enable, and disable
file polling ports Administrators
Change the primary port Administrators
Configure, enable, and disable proxy ports Administrators
Configure, enable, and disable registration ports Administrators
edit trigger settings. Developers
Set Audit level Administrators
Create, move and delete Audit logs Administrators
Create Document types Administrators
View Server
Information
Administrators
7
The various nominative Administrative roles described in the product documentation (Administrator,
Broker Administrator, Developer, Replicator) are all treated as a single Administrative role.
Security Target V1.0 12 December 2005
24
Dependencies: FMT_SMR.1 Security roles
FMT_SMF.1 Specification of management functions
FMT_SMF.1 Specification of management functions
Hierarchical to: No other components.
FMT_SMF.1.1 The TSF shall be capable of performing the following security management
functions: [
• Manage ACL,
• Manage Audit logs,
• Manage Sessions,
• Manage documents,
• Manage packages.
• Install folder, service, flow service, specification, document type, and
trigger,
• Assign ACL to folder, service, flow service, specification, and document
type
• Create document types,
• Manage events,
• Manage listening ports,
• Manage polling ports,
• Manage proxy ports,
• User management,
• Manage user tasks,
• Manage triggers,
• Connect to servers,
• View server information]
Dependencies: No Dependencies
FMT_SMR.1 Security roles
Hierarchical to: No other components.
FMT_SMR.1.1 The TSF shall maintain the roles [Authorized Administrator].
FMT_SMR.1.2 The TSF shall be able to associate users with roles.
Dependencies: FIA_UID.1 Timing of identification
Application note: The various Administrative roles described in the product documentation
(Administrator, Broker Administrator, Developer, Replicator) are all treated as a single security
Administrative role.
5.2.5 Class FPT: Protection of the TOE Security Functions
FPT_RVM_EXP.1-1 Non-bypassability of the TSP: TOE
Hierarchical to: No other components.
Security Target V1.0 12 December 2005
25
FPT_RVM_EXP.1.1-1 The TSF, when invoked by the underlying IT environment, shall ensure
that TSP enforcement functions are invoked and succeed before each function within the TSC
is allowed to proceed.
Dependencies: No dependencies.
FPT_SEP_EXP.1-1 TSF domain separation: TOE
Hierarchical to: No other components.
FPT_SEP_ EXP.1.1-1 The TSF, when invoked by the underlying host IT environment, shall
maintain a security domain that protects it from interference and tampering by untrusted
subjects in the TSC.
FPT_SEP_ EXP.1.2-1 The TSF, when invoked by the underlying host IT environment, shall
enforce separation between the security domains of subjects in the TSC.
Dependencies: No dependencies.
5.2.6 Strength of Function
The overall strength of function requirement is SOF-basic. The strength of function
requirement applies to FIA_SOS.1. The SOF claim for FIA_SOS.1 is SOF-basic. Strength of
the “secrets” mechanism is consistent with the objectives of authenticating users (O.IDAuth).
Strength of Function shall be demonstrated for the non-certificate based authentication
mechanisms to be SOF-basic, as defined in Part 1 of the CC. Specifically, the local
authentication mechanism must demonstrate adequate protection against attackers
possessing a low-level attack potential.
5.3 IT Environment Security Assurance Requirements
This section contains the Functional components for the webMethods IT environment. The
functional security requirements for the IT consist of the following components derived from
Part 2 of the CC, CC interpretations, explicitly stated SFRs derived from the CC Part 2, and
NIAP interpretations as appropriate, summarized in the Table 5-5 below.
The webMethods Servers require that the IT environment provide reliable time stamps, client
and server identification, and support TSF domain separation. The IT environment may
optionally be configured to provided certificate based authentication. Any cryptographic
functions are part of the IT environment, not part of the TOE.
A typical IT environment supporting an implementation of this TOE could be:
Broker Platform
SSL/TLS Toolkit
Host Operating System
Developer Platform:
Entrust Authority Security Toolkit for Java 7.0
Java Runtime Environment
Host Operating System
Integration Server Platform with Interface to external user
Entrust Authority Security Toolkit for Java 7.0
Java Runtime Environment
SSL/TLS Toolkit
Security Target V1.0 12 December 2005
26
Host Operating System
Integration Sever Platform without interface to external user
Java Runtime Environment
SSL/TLS Toolkit
Host Operating System
Table 5-5 IT Environment Functional Components
Component Component Name
FAU_STG.1 Protected audit trail storage
FIA_UAU.5-2 Multiple authentication mechanisms
FMT_MTD.1-2 Management of TSF data
FPT_RVM_EXP.1-2 Non-bypassability of the TSP: IT
FPT_SEP_EXP.1-2 TSF domain separation: IT
FPT_STM.1 Reliable time stamps
5.3.1 Class FAU: Security Audit
FAU_STG.1 Protected audit trail storage
Hierarchical to: No other components.
FAU_STG.1.1 Refinement: The IT Environment shall protect the stored audit records from
unauthorised deletion.
FAU_STG.1.2 Refinement: The IT Environment shall be able to [prevent] unauthorised
modifications to the audit records in the audit trail.
Dependencies: FAU_GEN.1 Audit data generation
5.3.2 Class FIA: Identification and authentication
FIA_UAU.5-2 Multiple authentication mechanisms
Hierarchical to: No other components.
FIA_UAU.5.1-2 – Refinement: The IT environment shall provide [Certificate based
authentication mechanisms] to support user authentication.
FIA_UAU.5.2-2 – Refinement: The IT environment shall authenticate any user's claimed
identity according to the [following multiple authentication mechanism rules:
a) Certificate based authentication mechanism, with Client and Server
certificates, shall be used for Broker Clients sending or receiving
information such that successful authentication must be achieved before
allowing any other TSF-mediated actions on behalf of that Broker Client;
b) Certificate based authentication mechanism, with Client and Server
certificates, shall be used for users sending information to or receiving
information from TOE using HTTPS or FTPS such that successful
authentication must be achieved before allowing any other TSF-mediated
actions on behalf of that human user;
Security Target V1.0 12 December 2005
27
c) Authentication of the Administrator with UID and reusable password at
the system console such that successful authentication must be
achieved before allowing any other TSF-mediated actions on behalf of
that human user;
Dependencies: No dependencies
Application Note: The webMethods Server relies on the identification that is provided by the IT
environment. The Broker Server require each user to be successfully identified via certificate
based authentication. The Integration Server minimally relies upon the IP address as a UID,
and may be configured to also require certificate based authentication. The webMethods
server will accept the UID supplied by the IT environment. Case a) applies to connections
made from the Integration Server to the Broker server. Case b) describes mutual certificate
based authentication by the client and server. Case c) describes authentication of the
authorized administrator.
5.3.3 Class FMT: Security management
FMT_MTD.1-2 Management of TSF data
Hierarchical to: No other components.
FMT_MTD.1.1-2 Refinement: The IT environment shall restrict the ability to [query, modify,
delete, create, and other operations as specified in Table 5-6] the [TSF Data as specified
in Table 5-6] to [the Authorized Administrator].
Table 5-6 TOE Management of TSF Data
TSF data Operation Identified Role
configuration files Query and edit Administrators
“.access” files Query and edit Administrators
Dependencies: FMT_SMR.1 Security roles
FMT_SMF.1 Specification of management functions
Application Note: The IT environment supports editing of TOE data. Some TOE data can only
be configured through the IT environment
FPT_RVM_EXP.1-2 Non-bypassability of the TSP
Hierarchical to: No other components.
FPT_RVM_EXP.1.1-2: The security functions of the IT environment shall ensure that IT
environment security policy enforcement functions are invoked and succeed before each
function within the scope of control of the IT environment is allowed to proceed.
Dependencies: No dependencies.
FPT_SEP_EXP.1-2 TSF domain separation: IT
Hierarchical to: No other components.
FPT_SEP_EXP.1.1-2 The security functions of the IT environment shall maintain a security
domain for its own execution that protects it from interference and tampering by untrusted
subjects in the scope and control of the IT environment.
Security Target V1.0 12 December 2005
28
FPT_SEP_EXP.1.2-2 The security functions of the IT environment shall enforce separation
between the security domains of subjects in the scope of control of the IT environment.
Dependencies: No dependencies.
FPT_STM.1 Reliable time stamps
Hierarchical to: No other components.
FPT_STM.1.1 Refinement: The IT environment shall be able to provide reliable time stamps
for its own use.
Dependencies: No dependencies
5.4 TOE Security Assurance Requirements
Table 5-7 EAL2 Assurance Requirements
Assurance
Component ID
Assurance Component Name Dependencies
ACM_CAP.2 Configuration items None
ADO_DEL.1 Delivery procedures None
ADO_IGS.1 Installation, generation, and start-up
procedures
AGD_ADM.1
ADV_FSP.1 Informal functional specification ADV_RCR.1
ADV_HLD.1 Descriptive high-level design ADV_FSP.1, ADV_RCR.1
ADV_RCR.1 Informal correspondence
demonstration
None
AGD_ADM.1 Administrator guidance ADV_FSP.1
AGD_USR.1 User guidance ADV_FSP.1
ATE_COV.1 Evidence of coverage ADV_FSP.1, ATE_FUN.1
ATE_FUN.1 Functional testing None
ATE_IND.2 Independent testing-sample ADV_FSP.1, AGD_ADM.1,
AGD_USR.1, ATE_FUN.1
AVA_SOF.1 Strength of TOE security function
evaluation
ADV_FSP.1, ADV_HLD.1
AVA_VLA.1 Developer vulnerability analysis ADV_FSP.1, ADV_HLD.1
AGD_ADM.1, AGD_USR.1
Security Target V1.0 12 December 2005
29
6 TOE Summary Specification
6.1 IT Security Functions
6.1.1 Security Audit Function
6.1.1.1 AU-1 Audit trail (FAU_GEN.1)
All administrative events audited by the TOE are mediated by built-in services residing on the
IS. In order for information to be recorded to support this SFR, the Service Logging Level must
be set to brief or verbose (see Table 6-1).
The Service log provides data about flow services and built-in services that run in Integration
Server. Log entries include Timestamp, User, Server Id (The ID can be DNSname:port or
IPaddress:port.), Service Name, Status (Started, Retried, Ended, or Failed), Duration, Error
Message, and Context information Monitor uses to connect related entries from different logs
(Root Context, Parent Context, Current Context).
Within each audited event, webMethods Servers records the following information: event, type
of event, subject identity, and the outcome
• Date and time of event,
• Type of event (the event type can be equated to the built-in Service called, for example
wm.server.query:getPartialLog is used to read audit data),
• Subject identity,
• Success or failure of event
The Integration Server maintains all logging data. By default, Integration Server stores audit
data in flat files, and although the product includes a capability to store certain types of logging
data into a database, this capability is not utilized in the TOE. Hence, none of the audit data
required for the CC evaluation is required to be in a database, but rather is stored in flat files.
The logging level setting determines the level of details and types of messages that are seen
in the Service Log. The Service Log contains two main types of information: server actions
(e.g., packages loaded & unloaded, start up & shutdown messages) and failures (e.g., access
failures, login failures). The Audit Log is similar to a traditional security audit trail, with the
exception of failure conditions.
Operationally, the audit logs are named auditYYYYMMDD.log while the service logs are
named serverYYYYMMDD.log.
Table 6-1 Service Logging Levels
Service Logging Setting
Disable service logging globally. off
Enable service-by-service logging. perSvc
Have the audit subsystem automatically write start and failure or success log entries
for every service every time the service is called, either directly (top-level) or by
another service (nested).
brief
Have the audit subsystem automatically write start and failure or success log entries
and the input pipeline every time the service is called, either directly (top-level) or by
another service (nested).
verbose
Security Target V1.0 12 December 2005
30
6.1.1.2 AU-2 Audit review (FAU_SAR.1)
From the Integration Server Administrative Interface, an authorized administrator8
can read
the service log data (called Audit Log in the GUI) generated by the TOE. Although there are
other types of audit logs supported by the product, only the service log is relevant to the
auditing functionality claimed in FAU_GEN.1. Hence, while other logs the IS generates do not
impede the secure administration of the TOE, they are not relevant to the secure
administration of the TOE either. Although the Developer is able to access services hosted on
the IS from the Developer platform, the services are audited on the platform where they are
hosted and execute (the IS) and not the platform from which they are invoked (in this example
the Developer). Hence all security relevant audit data that might be characterized as
“developer logging data” is actually recorded on the IS in the service log. The audit records
are provided in tabularized text suitable for the user to interpret the information.
6.1.1.3 AU-3 Restricted audit review (FAU_SAR.2)
The TSF prohibits all users read access to the audit records, except those users that have
been granted explicit read-access. Unauthorized users are not able to read the audit records
in the audit trail. The ACL check performed on the wm.server.query:getPartialLog service
supports this functionality.
6.1.1.4 AU-4 Selectable audit review (FAU_SAR.3)
In the Integration Server, the TSF provides the ability to perform the ordering of audit data
based on oldest to newest starting from the beginning and newest to oldest starting from the
end. The TSF provides the ability to search the audit data by customizing the number of log
entries displayed.
Dependencies: FAU_SAR.1 Audit review
6.1.1.5 AU-5 Selective audit (FAU_SEL.1)
The administrator can view the audit logs by going to the Logs > Session page to view
session logging data. The administrator can change the order of the entries and the number of
entries displayed using the Log display controls area on the log page, and include or exclude
auditable events from the set of audited events based on the level of logging
6.1.2 Access Control Policy
6.1.2.1 AC-1 Access control function (FDP_ACC.1) (FDP_ACF.1)
The Integration server provides two layers of access control on external users. The first is
enforced at the port through which access is granted to the TOE, and the second is enforced
at the layer of the object being accessed.
Controlling Access to a Element by Port
A port may provide access to one or more services. It may be configured to deny all services
except those allowed (called Deny by Default) or to allow all services except those denied
(called Allow by Default).
8
The Authorized Administrator role includes all of the administrative roles defined in the product - from
a security perspective, no distinction is made between the Integration Server Administrator, the Broker
Administrator, and the Developer roles provided by the product.
Security Target V1.0 12 December 2005
31
Access to elements through a port is determined as follows:
• If the port does not allow the source IP address (IP addresses may be filtered on using
wildcards both in the Domain Name and by wildcarding in dotted decimal notation),
then the server rejects the request.
• If the port is configured to require certificate based user authentication, the certificate
parameters are verified. Specifically, the issuing authority and certificate currency is
checked.
• If the port is configured as Deny by Default and the requested service is not included in
the list of services to be allowed, then the server rejects the request.
• If the port is configured as Allow by Default and the requested service is included in
the list of services to be denied, then the server rejects the request.
By default, the Integration Server provides a single port that allows all hosts (identified by their
IP addresses) to connect to it and allows access to all services through that port (unless
prohibited by an ACL). IP addresses may be filtered on using wildcards both in the Domain
Name and by wildcarding in dotted decimal notation.
Controlling Access to Resources with ACLs
ACLs control access to packages, folders, and other elements (such as services, document
types, and specifications) at the group level for a given UID. The UID is determined either
when an external user authenticates, or from the UID configured for a trigger when it
executes. An ACL identifies groups that are allowed to access an element (Allowed Groups)
and/or groups that are not allowed to access an element (Denied Groups). When identifying
Allowed Groups and Denied Groups, the Authorized Administrator selects from groups that
have previously defined. This is illustrated in Figure 6-1. and in Figure 6-2..
Access to elements is determined as follows:
• If an element does not have any ACLs specified, the server uses its inherited ACLs; if
no parent folder has any ACLs set, then the server uses the Default ACL.
• If the requested element has an ACL, then the server allows the request only if the
user is a member of at least one group listed on the ACL’s Allowed groups list and is
not a member of a group listed on the ACL’s Denied groups. The server denies the
request in all other cases.
An external user’s UID is determined either in the I&A process, or in the case of triggers, from
the UID assigned to the trigger.
Notes regarding Dynamic Server Pages (DSP)
If the element being accessed is a DSPs (or other file), access must be controlled for each
directory. There is no inheritance or override mechanism as there is with folders and services.
Access to DSPs is determined as follows:
• If the server does not allow the source IP address, then the server rejects the request.
• If the user making the request has not been authenticated, then the server processes
the request as the Default user. (In the evaluated configuration no unauthenticated
users are permitted to access the TOE).
• If the directory containing the DSP has a .access file and the .access file lists the
requested DSP, then the server allows the request if the user is a member of at least
Security Target V1.0 12 December 2005
32
one group listed on the ACL’s Allowed group and is not a member of any group on the
ACL’s Denied groups list.
• If the directory containing the DSP does not have a .access file, or if it has an .access
SP, then the server applies the Default ACL.
The relationship of users, groups, ACLs, folders, services, and listeners is summarized in
Figure 6-1. The relationship of users, groups, ACLs, .access files and DSPs is summarized in
Figure 6-2.
Figure 6-1 – Relationship of Users, Groups, ACLs, Folders, Services, and Ports
Figure 6-2 – Relationship of Users, Groups, ACLs, .access Files and DSPs
Specifically, an authorized administrator can control access to:
• Services clients can invoke - An authorized administrator can control which groups
(and therefore which users) can invoke a service. In addition to checking ACLs to
determine whether a client can invoke a service, the server performs a number of port
level checks.
• Special tools such as the Server Administrator, the Developer, and replicator
functions - These special abilities are granted by the Administrator, Developer, and
Replicator ACLs that are provided with the Integration Server.
Security Target V1.0 12 December 2005
33
• Elements that developers can see and use - An authorized administrator can fine tune
control over which developers have access to which packages, folders, and other
elements. For example, one development group might have access to create, update,
and maintain one set of services, while another development group has access to a
different set. ACLs can prevent one development group from accidentally updating or
damaging the work of another group.
• Files the server can serve. The server can serve files (for example .dsp and .htm files)
that reside in the pub directory for a package or a subdirectory of the pub directory. An
authorized administrator can control access to these files by assigning ACLs to them in
.access files.
There are four different kinds of access: List, Read, Write, and Execute. These are defined in
Table 6-2.
Table 6-2 Access Privileges
Access
Privilege
Description
List allows a user to see that an element exists. The element will be displayed on screens in
the Developer and the Integration Server Administrator. List access also allows you to
view an element’s metadata.
Read allows a user to view the main source of an element through the Developer and
Integration Server Administrator.
Write allows a user to edit an element. This access also allows a user to delete or lock an
element or to assign an ACL to it.
Execute allows a user to execute a service. This access also gives the user access to files the
server serves, such as .dsp and .htm files.
For an element, an ACL consists of two group lists: a list of groups that are allowed access,
and a second list of groups that are denied access. Each element can be associated with four
ACLs: one List, one Read, one Write, and one Execute. The same ACL for the List, Read,
Write, and Execute ACLs may be reused if desired. List, Read, and Write ACLs are used
mostly during development time by developers, and to some extent server administrators, who
need access to create, edit, and maintain services and other elements. Execute access is
used extensively in production environments. When a user tries to access an element, the
server checks the appropriate ACL (List, Read, Write, or Execute) associated with the
element.
Privileges to invoke a service or access files are granted and denied by ACLs that an
authorized administrator sets up. When an administrator creates ACLs, he or she identifies
groups that are allowed to access services and files and groups that are denied access to
services and files.
6.1.3 Identification and Authentication
6.1.3.1 IA-1 Security Attributes (FIA_ATD.1)
The TSF maintains the following user security attributes:
• User Name,
• Group Memberships
• Password
• X.509 certificate attributes (Distinguished Name, server private key, user certificate,
CA certificate)
Security Target V1.0 12 December 2005
34
6.1.3.2 IA-2 Password Policy (FIA_SOS.1)
The TOE provides a mechanism for specifying that users select password that meet minimum
strength criteria of SOF-basic. The default Password Policy is given in Table 6-3.
Table 6-3 Default Password Policy Rules
Requirement Default
Minimum number of characters (alphabetic characters, digits, and special characters
combined) the password must contain.
8
Minimum number of upper case alphabetic characters the password must contain. 2
Minimum number of lower case alphabetic characters the password must contain. 2
Minimum number of digits the password must contain. 1
Minimum number of special characters, such as asterisk (*), period (.), question mark (?), and
ampersand (&) the password must contain.
1
6.1.3.3 IA-3 User authentication (FIA_UAU.5-1)
Users must be identified and authenticated before they are allowed to perform any security-
relevant actions. The TSF is compatible with:
• external user authentication using UID and reusable password (The IT environment
provides protection during transmission for the re-usable password).9
The TOE can verify that a certificate is signed by a root certificate trusted by the IS. The IT
environment addresses all other aspects of certificate-based authentication in terms of
concepts of either the proof component (i.e., proof that the external user has the private key
that matches the certificate) and trusted certificate roots.
Once authenticated, the TOE associates the UID and corresponding user attributes (such as,
but not limited to, presumed IP address, group memberships and negotiated port) with each
network connection. External users are identified by presumed IP address before they are
able to access the TOE. If the IT environment authenticates the external user using certificate-
based authentication, the IT environment will also identify the user from certificate data, such
as Distinguished Name.
6.1.4 Security Management
6.1.4.1 SM-1 Management of Security Functions (FMT_MOF.1)
The Authorized Administrator may choose to configure TSF data through facilities provided by
the host OS, or the Authorized Administrator is able to obtain a visual display (HTML format)
populated with TSF data that is stored on the system hard drive. The HTML format interface
includes a GUI for configuration (external user authentication, allowable users, SSL
configuration, package management, system shutdown, logs) and for configuring the security
functions related to packages and associated attributes.
Before being able to manage the TOE, the user must be authorized through the identification/
authorization process. Ultimately, the administrator must verify that the security attributes
he/she assigns/sets are correct for their security policy.
9
Integration Server to Integration Server authentication is identical to IS to external user authentication
from the perspective of the TOE.
Security Target V1.0 12 December 2005
35
For a complete description of the Administrator Management functions interaction, including
configurable attributes and detailed information on managing specific policies see Table 5-2.
6.1.4.2 SM-2 Management of security attributes (FMT_MSA.1)
The Integration Server component of the TOE supports access control mechanism at the port
through which an external user accesses the TOE, and also at the level of the object that the
external user accesses. These mechanisms allow the administrator to establish parameters of
connections (i.e., HTTPS or HTTP), maintain UIDs and authenticators, and specify IP access
settings for listening ports. Administrators are also able to maintain ACL and establish the
relationship of ACL with elements controlled by the TOE.
The policy is discretionary in that authorized administrators have the capability to change the
access control attributes associated with some objects. Those access control attributes
determine a user’s access privilege.
Defining Groups
Administrator, replicator, and developer privileges are typically granted by adding a user to the
Administrators, Replicators, or Developers group, respectively. Alternatively, an authorized
administrator can create new groups and add them to the allow lists of the Administrators,
Replicators, or Developers ACLs.
Create groups that identify groups of users that will share the same privileges. When an
authorized administrator creates a group definition, a group name is specified and the
members of the group are assigned.
Group name - A group name is a unique name that identifies the group. Any name can be
used, for example, a name that defines a department (Marketing) or job function
(Programmers).
Members - List of user names that are members of the group.
Table 6-4 IS Default User to Default Group Assignment
Default user Group Assignments
Administrator Everybody, Administrators, and Replicators group.
Default Everybody and Anonymous group
Developer Everybody and Developers group
Replicator Everybody and Replicators group
Anonymous Anonymous Group
Everybody Everybody Group
Table 6-5 IS Default Group to ACL Mapping
Group Description Members
(User)
ACL
Administrators A user account that has administrator
privileges. You can use the Administrator user
account to access the Integration Server
Administrator to configure and manage the
server.
Administrator
user
See Administrators
ACL
See Internal ACL
See Replicators ACL
Default The server uses the information defined for the
Default user when the client does not supply a
user name and password.
Default user See Default ACL
See Anonymous
Security Target V1.0 12 December 2005
36
Group Description Members
(User)
ACL
Developers A user that can connect to the server from the
webMethods Developer to create, modify, and
delete services that reside on the server.
Developer user See Developers ACL
See Internal ACL
Replicator The user account that the server uses during
package replication.
Administrator
user, Replicator
user
See Replicator ACL.
Anonymous This group identifies users that have not been
authenticated.
Anonymous
user Default
user
See Anonymous ACL
Everybody All authenticated users are a member of this
group. Every new user is automatically added
to the Everybody group.
Administrator
user, Default
user, Developer
user, Replicator
user
Note: Customized groups can also be created.
Table 6-6 IS Default Access Control Lists
ACL
(Security Role)
Description
Administrators Allows users in the Administrators group, or any other group added to this ACL,
access to a package, folder, or other element and denies all other users. In
addition, you must make sure the user is not a member of a group that is denied
access by this ACL.
Default Allows all authenticated users access to a package, folder, or other element.
Developers Allows only users in the Developers group, or any other group added to this ACL,
access to a package, folder, or other element and denies all other users. In
addition, you must make sure the user is not a member of a group that is denied
access by this ACL.
Replicator Allows users in the Replicator group, or any other group added to this ACL,
replication privileges. In addition, you must make sure the user is not a member of
a group that is denied access by this ACL.
Anonymous Provides access to unauthenticated users (those that did not specify a valid UID).
Internal Allows only users in the Administrators and Developers groups access to a
package, folder, or other element and denies all other users. The server assigns
this ACL to built-in utility services shipped with the server, such as those in the
WmRoot and WmPublic folders. Normally not manually assigned to an element.
BrokerAdministrators Allows users to perform administrative functions on the Broker Server. (No user
is assigned to this groups by default)
BrokerUsers Allows users to be Broker Clients. (No user is assigned to this groups by
default)
Defining User Accounts
When a user account is created on the Integration Server the following is specified: user
name, password, and group membership.
User name - A user name is a unique name that identifies a client. An authorized
administrator can specify a user name that represents an actual person (e.g., “JDSmith” for
John D. Smith), or you can specify a user name to represent applications, job functions, or
organizations. For example, you might set up generically named user names such as
“MktgPurchAgent”, “MktgTimeKeeper,” and so forth, to represent job functions.
Security Target V1.0 12 December 2005
37
Group membership - The group membership identifies the groups to which a user belongs.
Access to the server’s resources is controlled at the group level:
• Only users that are members of the Administrators group can configure and
manage the server using the Integration Server Administrator.
• Only users that are members of the Developers group can connect to the
server from the webMethods Developer to create, modify, and delete services.
• The server protects access to services and files using Access Control Lists
(ACLs). An authorized administrator sets up ACLs that identify groups that are
allowed or not allowed to access a resource.
For a complete description reference Table 5-3
6.1.4.3 SM-3 Default Values of Security Attributes (FMT_MSA.3)
The configurable access control mechanisms that govern external users’ accessing the
Integration Server component of the TOE (via the webMethods IS Access Control SFP)
provides for a restrictive default access to all objects. An external user may not access the
TOE until the user has been granted access privileges by the Administrator. By default, object
access privileges defined in the ACL are restricted to the Administrator and Developer. The
TOE does not allow any user to specify alternative initial values for the ACL on an object to
override the default value.
webMethods comes to the consumer with an ACL option settings of do not check ACL when
internally invoked. Only the Administrator role is authorized to change the security attributes.
webMethods comes to the consumer with a default UID of Administrator for services invoked
by triggers. Both of these setting may be modified.
6.1.4.4 SM-4 Management of TSF Data (FMT_MTD.1-1)
The TSF restricts the ability to query, modify, delete, create, and other operations as specified
in Table 5-4 by restricting the ability to manage all TSF data to the Authorized Administrator.
Capabilities restricted to the Authorized Administrator also include management of
identification data, use of audit commands to select auditing levels and to query and review
audit records from the audit logs.
6.1.4.5 SM-5 Specification of Management Functions (FMT_SMF.1)
The TOE is capable of performing the following security management functions:
• determine the behavior of the functions listed in Table 5-2 to the authorized roles
identified in Table 5-2, or the Broker Administrator.
• query, modify, and delete the security attributes as specified in Table 5-3 to the
authorized roles identified in Table 5-3, or the Broker Administrator. (see
FMT_MSA.1),
• query, modify, delete, and create TSF Data as specified in Table 5-4 (See
FMT_MTD.1-1).
6.1.4.6 SM-6 Security Roles (FMT_SMR.1)
The TOE supports one security role:
• Authorized Administrator
Security Target V1.0 12 December 2005
38
The Authorized Administrator role has the ability to enable, disable, or modify the behavior of
all security functions. The TOE maintains this role and supports associating users to this role.
6.1.5 TSF Self-Protection
6.1.5.1 SP-1 Non-bypassability (FPT_RVM_EXP.1-1)
The TOE includes one network connection that must be considered in terms of non-
bypassability:
• External User to Integration Server
In combination with the IT environment, the TOE environment ensures all information from an
external client to an Integration Server or vice versa goes through the TSF. The TSF ensures
that all information must flow through the policy enforcement mechanisms.
In order for an external user to access a host, the client must use an encrypted connection
between the External user and the TSF. The encrypted connection is supported by the IT
environment. The TSF extracts packet header information revealing user attributes: IP source
address fields, negotiated port, and protocol. In addition the TSF may extract certificate based
authentication data to identify the external user. If certificate based authentication data is not
available, the external user must provide a UID and authenticator (password). Once the
external user is identified and authenticated, they cannot act without invoking an object that is
protected by the TSF. Based on the user attributes the external users access privilege is
determined for the invoked object. The TSF instantiates a separate object unique to the
specific external user and negotiated port, to mediate all communication between the External
user and the host. There is no communication path that passes the client information directly
to the host (or vice versa) except though the object dedicated to the specific authenticated
connection. Hence, the TSF ensures that all information must flow through the policy
enforcement mechanisms.
In order for a Broker Client to access a Broker, they must mutually authenticate via certificate-
based authentication. The TSF extracts packet header information revealing the IP source
address fields, negotiated port, and protocol. In addition, the TSF extracts certificate based
authentication data to identify the Broker Client. Once the Broker Client is identified and
authenticated, they cannot act except to access a document type, which is protected by the
TSF. Based upon user attributes and the operation the Broker Clients access privilege is
determined for the document type. If access is permitted, documents of the type accessed
may be exchanged. There is no communication path that passes the client information directly
to the Broker (or vice versa) except though the described process dedicated to the specific
authenticated connection. In combination with the IT environment, the TOE environment
ensures all information from a Broker Client to a Broker Server or vice versa goes through the
TSF. Hence, the TSF ensures that all information must flow through the policy enforcement
mechanisms.
6.1.5.2 SP-2 TSF domain separation (FPT_SEP_EXP.1-1)
With support from the IT environment, the TSF maintains a security domain for its own
execution that protects it from interference and tampering by untrusted subjects. webMethods
Fabric’s protected domain includes the webMethods software and all of its software
components.
There are two subjects of the TSF policy enforcement mechanisms: external users and Broker
Clients. Broker Clients are created by the Authorized Administrator, are exist internal to the
TOE, and operate across on the IS-Broker internal interface.
Security Target V1.0 12 December 2005
39
The servers that comprise the TOE reside on different machines. The Integration Server
resides on the machine where an external interface to external user services exists, and the
Broker Server resides on a machine internal to the TOE where documents are temporarily
stored pending delivery to Broker Clients.
No arbitrary code runs on the Integration Server. An extensive library of built-in services
installed on the Integration Server by the authorized administrator during system
configuration. The Integration Server component of the TOE ensures the isolation and
protection of services and arbitrates subject access to each service, which is associated with
an ACL and subject to the access control policies. The TSF enforces separation between the
security domains of subjects in the TSC by instantiation a separate object for each user
connection. The TSF relies on the UID and session parameters (negotiated port) to isolate
user sessions and maintain object separation.
No customer specific code resides on the Broker Server. External users are not permitted to
directly access the Broker Server; only Broker Clients executing on the Information Server on
behalf of the external users may access the Broker Server. Hence an external user has no
mechanism available with which to directly access the Brokers installed on the Broker Server.
In addition to the webMethods-specific software, other software files such as configuration
files are also stored on disk. For these files webMethods Fabric relies on the IT environment
to provide file access permissions and identification and authentication of users at the OS
level. An underlying assumption regarding the operation of webMethods Fabric is that it is
maintained in a physically secure environment. This is a needed assumption for maintaining a
security domain for TSF execution to provide protection from interference from untrusted
subjects.
6.2 Assurance Measures
The TOE satisfies CC EAL2 assurance requirements. Table 6-7 identifies the Configuration
Management, Delivery and Operation, Development, Guidance Documents, Testing, and
Vulnerability Assessment Assurance Measures applied by webMethods to satisfy the CC
EAL2 assurance requirements.
Table 6-7 EAL2 Assurance Requirements Measures
Assurance
Component
How requirement will be met Document Version
ACM_CAP.2
Configuration Items
The vendor provided
configuration management
documents and a Configuration
Item list.
webMethods Fabric 6.5 Configuration
Management, Version 0.5
ADO_DEL.1
Delivery
Procedures
The vendor provided delivery
procedures.
webMethods Version 6.5 Delivery
Procedures Version 0.3 Final
Security Target V1.0 12 December 2005
40
Assurance
Component
How requirement will be met Document Version
ADO_IGS.1
Installation,
Generation and
Startup procedures
The vendor provided secure
installation, generation and start
up procedures.
webMethods Broker Administrator’s Guide,
Version 6.5, Document ID: BR-AG-65-
20050615, webMethods Developer User’s
Guide, Version 6.5, DEV-UG-65-20050429,
webMethods Fabric Integration Platform Error
Message Reference, Document ID: PLAT-
EM-RF-601-20031201, webMethods
Integration Server Administrator’s Guide,
Version 6.5, Document ID: webM-IS-AG-65-
20050429, webMethods Integration Server
Built-In Services Reference, Version 6.5,
Document ID: IS-BIS-RF-65-20050330,
webMethods Installation Guide Version 6.5
and Version 6.5.1 Document ID: WEBM-IG-
65-20050930, webMethods Publish-
Subscribe Developer’s Guide Version 6.5
Document ID: DEV-PS-DG-65-20050429,
webMethods Logging Guide Version 6.5
Document ID: WEBM-LG-65-20050511,
webMethods JDBC Adapter User’s Guide,
Document ID: ADAPTER-JDBC-UG-603-
20040511, webMethods JMS Adapter
Installation Guide, Document ID: ADAPTER-
JMS-IG-61-20040213, webMethods JMS
Adapter User’s Guide, Document ID:
ADAPTER-JMS-UG-61-20040213
ADV_FSP.1
Informal functional
specification
The vendor provided an informal
function specification.
webMethods Fabric 6.5 Proprietary
Development Specification, Version 0.6
ADV_HLD.1
Descriptive high-
level design
The vendor provided a
descriptive high-level design
document.
webMethods Fabric 6.5 Proprietary
Development Specification, Version 0.6
ADV_RCR.1
Informal
correspondence
demonstration
The informal correspondence
demonstration is provided in the
design documentation. ST to
FSP in the FSP, FSP to HLD in
the HLD.
webMethods Fabric 6.5 Proprietary
Development Specification, Version 0.6
AGD_ADM.1
Administrator
Guidance
The vendor submitted a system
administration manual.
webMethods Fabric 6.5 Guidance
Documentation Version 0.3, also see
documents listed under ADO_IGS.1
AGD_USR.1 User
Guidance
The vendor submitted a user
guide.
There is no user role.
ATE_COV.1
Evidence of
coverage
The analysis of test coverage
was submitted in the evaluation
evidence.
webMethods Fabric 6.5 Test coverage
analysis, Version 0.4, webMethods Version
6.5 Server Regression Test Cases
ATE_FUN.1
Functional testing
The test evidence was
submitted to the CCTL.
webMethods Fabric 6.5 Test coverage
analysis, Version 0.4, webMethods Version
6.5 Server Regression Test Cases
Security Target V1.0 12 December 2005
41
Assurance
Component
How requirement will be met Document Version
ATE_IND.2
Independent testing
- sample
The laboratory used
development evidence
submitted by the vendor along
with functional testing evidence
as a baseline for an independent
test plan.
webMethods Fabric 6.5 Test coverage
analysis, Version 0.4, webMethods Version
6.5 Server Regression Test Cases
AVA_SOF.1
Strength of TOE
security function
evaluation10
The vendor submitted an
analysis of the SOF for the
password.
webMethods Version 6.5 Strength of
Function Analysis Version 0.3 Final
AVA_VLA.1
Developer
vulnerability
analysis
The vendor submitted
vulnerability analysis was
confirmed. The laboratory
conducted an independent
vulnerability assessment by
building on the vendor’s. The
laboratory conducted
penetration testing.
webMethods Fabric 6.5 Vulnerability Analysis
Version 0.3 Draft
10
Cryptographic analysis or certification is not required for the TOE since all cryptographic functions are
supported by the IT environment.
Security Target V1.0 12 December 2005
42
7 PP Claims
The Security Target was not written to address any existing Protection Profile.
Security Target V1.0 12 December 2005
43
8 Rationale
8.1 Security Objectives Rationale
8.1.1 Threats to Security
Table 8-1 shows that all the identified threats to security are countered by Security Objectives
for the TOE. Rationale is provided for each threat below the table.
Table 8-1 All Threats to Security Countered
Identifier Threat Security Objective
T.Abuse An undetected compromise of the TOE
may occur as a result of an authorized
user of the TOE (intentionally or
otherwise) performing actions the
individual is authorized to perform.
O.Access, O.Attributes, O.Audit,
O.AuditProtection, O.AuditReview,
O.IDAuth, OE.Audit, OE.AuditProtection,
OE.IDAuth, OE.Time, ON.Operations,
ON.Person
T.Access An authorized user of the TOE may
access information or resources without
having permission from the person who
owns, or is responsible for, the
information or resource.
O.Access, O.Attributes, O.Audit,
O.AuditProtection, O.AuditReview,
O.IDAuth, O.RemoteAdministration,
OE.AuditProtection, OE.IDAuth, OE.Time
T.Bypass An unauthorised user may attempt to
bypass the information flow control policy.
O.NonBypass, O.PartialSelfProtection,
OE.NonBypass, OE.PartialSelfProtection
T.Intercept An unauthorized person on an internal
network that connects TOE components
may intercept communications between
the TOE components and attempt to
access and/or modify the data being
transmitted.
OE.ProtectComm
T.Mismanage Authorized administrators may make
errors in the management of security
functions and TSF data. Administrative
errors may allow attackers to gain
unauthorized access to resources
protected by the TOE.
O.Admin, O.RemoteAdministration,
ON.Install , ON.Person
T.Tamper An attacker may attempt to modify TSF
programs and data.
O.PartialSelfProtection,
OE.PartialSelfProtection, ON.NoUntrusted,
ON.Operations, ON.Person, ON.Physical,
ON.ProtectAuth
T.Transmit TSF data may be disclosed or modified
by an attacker while being transmitted
between the TOE and its users.
O.PartialSelfProtection,
OE.PartialSelfProtection, OE.ProtectComm
T.Undetect Attempts by an attacker to violate the
security policy may go undetected. If the
attacker is successful, TSF data may be
lost or altered.
O.Audit, O.AuditProtection, O.AuditReview,
O.PartialSelfProtection, OE.Audit,
OE.AuditProtection,
OE.PartialSelfProtection, OE.Time,
ON.Physical
Rationale
Security Target V1.0 12 December 2005
44
T.Abuse Is countered by:
O.Access This objective counters this threat by providing access controls
that limit the actions an individual is authorized to perform.
O.Attributes This objective counters this threat by requiring the TOE to store
and maintain user attributes. These attributes associate users
with user roles and access rights, in conformance to the Access
Control SFP.
O.Audit This objective counters this threat by requiring the TOE to audit
attempts for data accesses and use of TOE functions.
O.AuditProtection This objective counters this threat by requiring the TOE to
provide protection of the audit interface.
O.AuditReview This objective counters this threat by giving authorized
administrators the ability to review the audit logs. This will help
in detecting data accesses and use of TOE functions.
O.IDAuth This objective provides for authentication of users prior to any
TOE data access
OE.Audit This objective counters this threat by requiring the IT
Environment to audit authentication to the OS and therefore who
had access to TOE configuration files.
OE.AuditProtection This objective counters this threat by requiring the IT
Environment to provide protection of the audit storage.
OE.IDAuth This objective provides for authentication of users prior to any
TOE data access
OE.Time This objective provides for a reliable way to correlate audit
records to reconstruct a potential compromise.
ON.Operations This objective provides for guidance documentation that explains
how to securely manage the TOE.
ON.Person This objective provides for qualified and trained authorized
administrators to manage the TOE.
T.Access Is countered by:
O.Access This objective counters this threat by providing access controls
that limit the actions an individual is authorized to perform.
O.Attributes This objective counters this threat by requiring the TOE to store
and maintain user attributes. These attributes associate users
with user roles and access rights, in conformance to the Access
Control SFP.
O.Audit This objective counters this threat by requiring the TOE to audit
attempts for data accesses and use of TOE functions.
O.AuditProtection This objective counters this threat by requiring the TOE to
provide protection of the audit interface.
O.AuditReview This objective counters this threat by giving authorized
administrators the ability to review the audit logs. This will help
in detecting data accesses and use of TOE functions.
O.IDAuth This objective provides for authentication of users prior to any
TOE data access
O.RemoteAdministratio
n
This objective provides for authorized administrators to perform
TOE functions that are essential to security through the remote
administrator client interface
OE.AuditProtection This objective counters this threat by requiring the IT
Environment to provide protection of the audit storage
OE.IDAuth This objective provides for authentication of users prior to any
TOE data access.
Security Target V1.0 12 December 2005
45
OE.Time This objective provides for a reliable way to correlate audit
records to reconstruct a potential compromise.
T.Bypass Is countered by:
O.NonBypass This objective counters this threat by ensuring the TOE’s
protection mechanisms cannot be bypassed, which requires that
TSF security functions not be bypassable. This is supported by
OE.NonBypass
O.PartialSelfProtection This objective supports addressing this threat by providing TOE
self-protection and separation between users. The TOE will
maintain separation between code executing on behalf of
different users
OE.NonBypass This objective supports countering this threat by ensuring the
TOE’s protection mechanisms cannot be bypassed, which
requires that IT environment security functions not be
bypassable.
OE.PartialSelfProtectio
n
This objective supports addressing this threat by providing TOE
self-protection and separation between users. The TOE will
maintain separation between code executing on behalf of
different users
T.Intercept Is countered by:
OE.ProtectComm This objective supports preventing data from being disclosed or
modified when it is being transmitted between client and server
components.
T.Mismanage Is countered by:
O.Admin This objective counters mismanagement through the functionality
that enables authorized user(s) to effectively manage the TOE
and its security functions.
O.RemoteAdministratio
n
This objective provides for authorized administrators to perform
TOE functions that are essential to security through the remote
administrator client interface
ON.Install This objective provides for secure installation and configuration
of the TOE.
ON.Person This objective provides for qualified and trained authorized
administrators to manage the TOE.
T.Tamper Is countered by:
O.PartialSelfProtection This objective addresses this threat by providing separation
between code executing on behalf of different users. In addition,
this objective addresses this threat by providing TOE self-
protection and separation between users.
OE.PartialSelfProtectio
n
This objective partially addresses this threat by protecting the IT
environment and the TOE and its data.
ON.NoUntrusted This objective provides for the protection of the TOE from
untrusted software.
ON.Operations This objective provides for guidance documentation that explains
how to securely manage the TOE.
ON.Person This objective provides for qualified and trained authorized
administrators to manage the TOE.
ON.Physical This objective provides for physical protection of the TOE
ON.ProtectAuth This objective provides for authorized users not sharing their
passwords with others
Security Target V1.0 12 December 2005
46
T.Transmit Is countered by:
O.PartialSelfProtection This objective addresses this threat by providing separation
between code executing on behalf of different users. In addition,
this objective addresses this threat by providing TOE self-
protection and separation between users.
OE.PartialSelfProtectio
n
This objective supports addressing this threat by protecting the
IT environment and the TOE and its data.
OE.ProtectComm This objective supports preventing data from being disclosed or
modified when it is being transmitted between client and server
components.
T.Undetect Is countered by:
O.Audit This objective counters this threat by requiring the TOE to audit
attempts for data accesses and use of TOE functions.
O.AuditProtection This objective counters this threat by requiring the IT
Environment to provide protection of the audit storage.
O.AuditReview This objective counters this threat by giving authorized
administrators the ability to review the audit logs. This will help
in detecting data accesses and use of TOE functions.
O.PartialSelfProtection This objective supports addressing this threat by providing
separation between code executing on behalf of different users.
In addition, this objective addresses this threat by providing TOE
self-protection and separation between users.
OE.Audit This objective counters this threat by requiring the IT
Environment to audit authentication to the OS and therefore who
had access to TOE configuration files..
OE.AuditProtection This objective supports countering this threat by requiring the IT
Environment to provide protection of the audit storage
OE.PartialSelfProtectio
n
This objective supports addressing this threat by protecting the
TOE and its data.
OE.Time This objective provides for a reliable way to correlate audit
records to reconstruct a potential compromise.
ON.Physical This objective provides for physical protection of the TOE
Table 8-2 Reverse Mapping of TOE Security Objectives to Threats
Identifier Threat
O.Access T.Abuse, T.Access
O.Admin T.Mismanage
O.Attributes T.Abuse, T.Access
O.Audit T.Abuse, T.Access, T.Undetect
O.AuditProtection T.Abuse, T.Access, T.Undetect
O.AuditReview T.Abuse, T.Access, T.Undetect
O.IDAuth T.Abuse, T.Access,
O.NonBypass T.Bypass
O.PartialSelfProtection T.Bypass, T.Tamper, T.Transmit, T.Undetect
O.RemoteAdministration T.Access, T.Mismanage
OE.Audit T.Abuse, T.Undetect
OE.AuditProtection T.Abuse, T.Access, T.Undetect
OE.IDAuth T.Abuse, T.Access
OE.NonBypass T.Bypass
Security Target V1.0 12 December 2005
47
Identifier Threat
OE.PartialSelfProtection T.Bypass, T.Tamper, T.Transmit, T.Undetect
OE.ProtectComm T.Intercept, T.Transmit
OE.Time T.Abuse, T.Access, T.Undetect
ON.Install T.Mismanage
ON.NoUntrusted T.Tamper
ON.Operations T.Abuse, T.Tamper
ON.Person T.Abuse, T.Mismanage, T.Tamper
ON.Physical T.Tamper, T.Undetect
ON.ProtectAuth T.Tamper
8.1.2 Assumptions
Table 8-3 shows that all of the secure usage assumptions are addressed by either security
objectives for the IT environment or Non-IT security objectives. Rationale for each
assumption is provided below the table.
Table 8-3 All Assumptions Addressed
Name Assumption Objective
A.Admin The administrator is trusted to correctly configure
and operate the TOE according to the
instructions provided by the TOE documentation.
ON.Install, ON.Operations
A.IT The TOE relies upon the IT environment to
support protected communications, provide audit
file protection, support partial domain separation,
support non-bypassability, and to perform user
authentication when configured to do so.
OE.AuditProtection, OE.IDAuth,
OE.NonBypass,
OE.PartialSelfProtection,
OE.ProtectComm
A.Manage It is assumed that one or more authorized
administrators are assigned who are competent
to manage the TOE and the security of the
information it contains, and who can be trusted
not to deliberately abuse their privileges so as to
undermine security.
ON.Person
A.NoUntrusted It is assumed that there will be no untrusted
software on the webMethods Integration Server
and Broker.
ON.NoUntrusted
A.Physical The TOE components critical to the security
policy enforcement will be protected from
unauthorized physical modification.
ON.Physical
A.Users It is assumed that users will protect their
authentication data.
ON.ProtectAuth
Rationale:
A.Admin is covered by:
ON.Install This objective provides for secure installation and configuration of the
TOE.
ON.Operations This objective provides for operation procedures to be in place.
A.IT is covered by:
OE.AuditProtection This objective provides for secure storage of the audit data.
Security Target V1.0 12 December 2005
48
OE.IDAuth This objective provides for authentication of administrators.
OE.NonBypass This objective provides support for the TOE’s non-bypassability.
OE.PartialSelfProtection This objective provides support for the TOE’s partial self protection.
OE.ProtectComm This objective provides support for the TOE’s protected communications
configuration features and also can be configured to provided certificate
based authentication.
A.Manage is covered by:
ON.Person This objective provides for competent personnel to administer the TOE.
A.NoUntrusted is covered by:
ON.NoUntrusted This objective provides for the protection of the TOE from untrusted
software.
A.Physical is covered by:
ON.Physical This objective provides for the physical protection of the TOE software.
A.Users is covered by:
ON.ProtectAuth This objective provides for users protecting their authentication data.
Table 8-4 Environment Objective to Threat or Assumption Mapping
Objective Threat or Assumption
OE.Audit T.Abuse, T.Undetect
OE.AuditProtection A.IT, T.Abuse, T.Access, T.Undetect
OE.IDAuth A.IT, T.Abuse, T.Access
OE.NonBypass A.IT, T.Bypass
OE.PartialSelfProtection A.IT, T.Bypass, T.Tamper, T.Transmit, T.Undetect
OE.ProtectComm A.IT, T.Intercept, T.Transmit
OE.Time T.Abuse, T.Access, T.Undetect
ON.Install A.Admin, T.Mismanage
ON.NoUntrusted A.NoUntrusted , T.Tamper
ON.Operations A.Admin, T.Abuse, T.Tamper
ON.Person A.Manage , T.Abuse, T.Mismanage, T.Tamper
ON.Physical A.Physical , T.Tamper, T.Undetect
ON.ProtectAuth A.Users, T.Tamper
Security Target V1.0 12 December 2005
49
8.2 Security Requirements Rationale
8.2.1 Functional Requirements
Table 8-5 shows that all of the security objectives of the TOE are satisfied. Rationale for each
objective is included below the table.
Table 8-5 All Objectives Met by Functional Components
Objective Objective Description SFR
O.Access The TOE must allow
authorized users to access
only appropriate TOE
functions and data.
FAU_SAR.2 Restricted audit review,
FDP_ACC.1 Subset access control,
FDP_ACF.1 Security attribute based access
control, FIA_UAU.5-1 Multiple authentication
mechanisms, FMT_MOF.1 Management of
Security Functions Behavior, FMT_MSA.1
Management of security attributes,
FMT_MTD.1-1 Management of TSF data
O.Admin The TOE must provide the
functionality to enable
authorized user(s) to
effectively manage the
TOE and its security
functions.
FAU_SAR.1 Audit review, FIA_ATD.1 User
attribute definition, FIA_UAU.5-1 Multiple
authentication mechanisms, FMT_MOF.1
Management of Security Functions Behavior,
FMT_MSA.1 Management of security
attributes, FMT_MSA.3 Static attribute
initialisation, FMT_MTD.1-1 Management of
TSF data, FMT_SMF.1 Specification of
management functions, FMT_SMR.1 Security
roles
O.Attributes The TOE must be able to
maintain user security
attributes.
FIA_ATD.1 User attribute definition
O.Audit The TOE must provide a
means to record a
readable audit trail of
security-related events,
with accurate dates and
times.
FAU_GEN.1 Audit data generation,
FAU_SAR.3 Selectable audit review,
FAU_SEL.1 Selective audit, FIA_ATD.1 User
attribute definition, FMT_MOF.1 Management
of Security Functions Behavior, FMT_MTD.1-1
Management of TSF data, FMT_SMF.1
Specification of management functions
O.AuditProtection The TOE must provide the
capability to protect audit
information.
FAU_SAR.2 Restricted audit review
O.AuditReview The TOE must provide the
functionality to enable
authorized user(s) to
review the audit logs.
FAU_SAR.1 Audit review, Audit review,
FAU_SAR.2 Restricted audit review,
FAU_SAR.3 Selectable audit review
O.IDAuth The TOE must be able to
identify and authenticate
the users prior to allowing
access to TOE
functionality.
FIA_ATD.1 User attribute definition,
FIA_SOS.1 Verification of secrets,
FIA_UAU.5-1 Multiple authentication
mechanisms, FMT_MSA.1 Management of
security attributes
Security Target V1.0 12 December 2005
50
Objective Objective Description SFR
O.NonBypass The TOE must ensure the
TOE’s security functional
policy is invoked and
succeeds before allowing
another TOE function to
proceed.
FPT_RVM_EXP.1-1 Nonbypassability of the
TSP: TOE
O.PartialSelfProtection The TSF will maintain a
domain for its own
execution that protects
itself and its resources
from external interference,
tampering or unauthorized
disclosure, through its own
interfaces.
FPT_SEP_EXP.1-1 TSF domain separation:
TOE
O.RemoteAdministration An identified and
authorized remote
administrator may manage
identified TSF entities from
a remote client.
FIA_UAU.5-1 Multiple authentication
mechanisms, FMT_SMR.1 Security roles
SFR rationale
O.Access The TOE must allow authorized users to access only appropriate
TOE functions and data.
FAU_SAR.2 Restricted audit review (TOE), which requires that access to audit data be
restricted to authorized users.
FDP_ACC.1 Subset access control (TOE), ensures there will be a DAC mechanism
present to protect objects on the Integration Server.
FDP_ACF.1 Security attribute based access control (TOE), which requires the TSF
enforce access controls based on specified security attributes.
FIA_UAU.5-1 Multiple authentication mechanisms (TOE), ensure that the system must
perform identification and authentication of all users.
FMT_MOF.1 Management of Security Functions Behavior (TOE), which restricts the
ability to disable enable and modify functions to authorized users.
FMT_MSA.1 Management of security attributes (TOE), which enforces the
Management of Security Attributes to restrict the ability to create query
modify and delete the specified security attributes to the authorized
account types.
FMT_MTD.1-1 Management of TSF data (TOE), which specifies the management of TSF
Data according to assigned roles.
O.Admin The TOE must provide the functionality to enable authorized user (s)
to effectively manage the TOE and its security functions.
FAU_SAR.1 Audit review (TOE), which requires that the authorized administrator be
able to read all audit records within the administrator’s scope of control.
FIA_ATD.1 User attribute definition (TOE), which requires that the TSF maintain
security attributes of users.
FIA_UAU.5-1 Multiple authentication mechanisms (TOE), Multiple authentication
mechanisms (TOE), ensure that the system must perform identification
and authentication of all users, including Administrators.
FMT_MOF.1 Management of Security Functions Behavior (TOE), which restricts the
ability to disable enable and modify functions to authorized users.
Security Target V1.0 12 December 2005
51
FMT_MSA.1 Management of security attributes (TOE), which enforces the
Management of Security Attributes to restrict the ability to create query
modify and delete the specified security attributes to the authorized
account types.
FMT_MSA.3 Static attribute initialisation (TOE), which requires the TSF enforce access
control for specified default values of security attributes.
FMT_MTD.1-1 Management of TSF data (TOE), which specifies the management of TSF
Data according to assigned roles in the Integration Server.
FMT_SMF.1 Specification of management functions (TOE), which requires the TSF be
capable of performing the specified security management functions.
FMT_SMR.1 Security roles (TOE), which requires that the TSF maintain multiple roles.
O.Attributes The TOE must be able to maintain user security attributes.
FIA_ATD.1 User attribute definition (TOE), which requires that the TSF maintain
security attributes of users.
O.Audit The TOE must provide a means to record a readable audit trail of
security-related events, with accurate dates and times.
FAU_GEN.1 Audit data generation (TOE), which requires the ability to audit specified
events.
FAU_SAR.3 Selectable audit review (TOE), ensures that the administrator can perform
searches of the audit data
FAU_SEL.1 Selective audit (TOE),
FIA_ATD.1 User attribute definition (TOE), which requires that the TSF maintain
security attributes of users.
FMT_MOF.1 Management of Security Functions Behavior (TOE), which restricts the
ability to disable enable and modify functions to authorized users.
FMT_MTD.1-1 Management of TSF data (TOE), which specifies the management of TSF
Data according to assigned roles.
FMT_SMF.1 Specification of management functions (TOE), which requires the TSF be
capable of performing the specified security management functions.
O.AuditProtection The TOE must provide the capability to protect audit information.
FAU_SAR.2 Restricted audit review (TOE), which requires that access to audit data be
restricted to authorized users.
O.AuditReview The TOE must provide the functionality to enable authorized user (s)
to review the audit logs.
FAU_SAR.1 Audit review (TOE), which requires that the authorized administrator be
able to read all audit records within the administrator’s scope of control.
FAU_SAR.2 Restricted audit review (TOE), which requires that access to audit data be
restricted to authorized users.
FAU_SAR.3 Selectable audit review (TOE), administrator to perform searches of the
audit data based on event date.
O.IDAuth The TOE must be able to identify and authenticate the users prior to
allowing access to TOE functionality.
FIA_ATD.1 User attribute definition (TOE), which requires that the TSF maintain
security attributes of users.
FIA_SOS.1 Verification of secrets (TOE), ensures the strength of secrets used as
authenticators in the TOE.
FIA_UAU.5-1 Multiple authentication mechanisms (TOE), Multiple authentication
mechanisms (TOE), ensure that the system must perform identification
and authentication of all users, including Administrators.
Security Target V1.0 12 December 2005
52
FMT_MSA.1 Management of security attributes (TOE), which enforces the
Management of Security Attributes to restrict the ability to create query
modify and delete the specified security attributes to the authorized
account types.
O.NonBypass The TOE must ensure the TOE’s security functional policy is invoked
and succeeds before allowing another TOE function to proceed.
FPT_RVM_EXP.1-1 Nonbypassability of the TSP: TOE (TOE), which requires that TSP
enforcement functions are invoked and succeed before a security-relevant
function is allowed to proceed.
O.PartialSelfProtection The TSF will maintain a domain for its own execution that protects
itself and its resources from external interference, tampering or
unauthorized disclosure, through its own interfaces.
FPT_SEP_EXP.1-1 TSF domain separation: TOE (TOE), This requires that the TOE provide
partial protection to maintain separation between code executing on behalf
of different users.
O.RemoteAdministration An identified and authorized remote administrator may manage
identified TSF entities from a remote client.
FMT_SMR.1 Security roles (TOE), which requires that the TSF maintain multiple roles.
FIA_UAU.5-1 Multiple authentication mechanisms (TOE), Multiple authentication
mechanisms (TOE), ensure that the system must perform identification
and authentication of all users, including Administrators.
Table 8-6 All Objectives Met by Functional Components Reversed
SFR Title Objective
FAU_GEN.1 Audit data generation O.Audit
FAU_SAR.1 Audit review O.Admin, O.AuditReview
FAU_SAR.2 Restricted audit review O.Access, O.AuditProtection,
O.AuditReview
FAU_SAR.3 Selectable audit review O.Audit, O.AuditReview
FAU_SEL.1 Selective audit O.Audit
FDP_ACC.1 Subset access control O.Access
FDP_ACF.1 Security attribute based
access control
O.Access
FIA_ATD.1 User attribute definition O.Admin, O.Attributes, O.Audit,
O.IDAuth
FIA_SOS.1 Verification of secrets O.IDAuth
FIA_UAU.5-1 Multiple authentication
mechanisms
O.Access, O.Admin, O.IDAuth,
O.RemoteAdministration
FMT_MOF.1 Management of Security
Functions Behavior
O.Access, O.Admin, O.Audit
FMT_MSA.1 Management of security
attributes
O.Access, O.Admin, O.IDAuth
FMT_MSA.3 Static attribute initialisation O.Admin
FMT_MTD.1-1 Management of TSF data O.Access, O.Admin, O.Audit
FMT_SMF.1 Specification of management
functions
O.Admin, O.Audit
FMT_SMR.1 Security roles O.Admin, O.RemoteAdministration
Security Target V1.0 12 December 2005
53
SFR Title Objective
FPT_RVM_EXP.1-1 Nonbypassability of the TSP:
TOE
O.NonBypass
FPT_SEP_EXP.1-1 TSF domain separation: TOE O.PartialSelfProtection
8.2.2 Dependencies
Table 8-7 shows the dependencies between the functional requirements. All dependencies
are satisfied. Dependencies that are satisfied by a hierarchical component are denoted by an
(H) following the dependency reference. If the TOE dependency is met by an SFR in the IT
environment an “E” will be next to the reference number.
Table 8-7 TOE Dependencies Satisfied
TOE Security Functional
Requirements
Dependencies How met
Class FAU: Security Audit
FAU_GEN.1 Audit data generation FPT_STM.1 Reliable time stamps FPT_STM.1
FAU_SAR.1 Audit review FAU_GEN.1 Audit data generation FAU_GEN.1
FAU_SAR.2 Restricted audit review FAU_SAR.1 Audit review FAU_SAR.1
FAU_SAR.3 Selectable audit review FAU_SAR.1 Audit review FAU_SAR.1
FAU_SEL.1 Selective audit FAU_GEN.1 Audit data generation,
FMT_MTD.1-1 Management of TSF
data
FAU_GEN.1,
FMT_MTD.1-1
Class FDP: User Data Protection
FDP_ACC.1 Subset access control FDP_ACF.1 Security attribute based
access control
FDP_ACF.1-1
FDP_ACF.1 Security attribute based
access control
FDP_ACC.1 Subset access control,
FMT_MSA.3 Static attribute initialization
FDP_ACC.1,
FMT_MSA.3
Class FIA: Identification and Authentication
FIA_ATD.1 User attribute definition No dependencies. N/A
FIA_SOS.1 Verification of secrets No dependencies. N/A
FIA_UAU.5-1 Multiple authentication
mechanisms
No dependencies. N/A
Class FMT: Security Management (FMT)
FMT_MOF.1 Management of Security
Functions Behavior
FMT_SMR.1 Security roles,
FMT_SMF.1 Specification of
management functions.
FMT_SMR.1,
FMT_SMF.1
FMT_MSA.1 Management of security
attributes
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 (CCIMB 065)
FDP_ACC.1,
FMT_SMR.1,
FMT_SMF.1
FMT_MSA.3 Static attribute
initialisation
FMT_MSA.1 Management of security
attributes, FMT_SMR.1 Security roles
FMT_MSA.1,
FMT_SMR.1
FMT_MTD.1-1 Management of TSF
data
FMT_SMR.1 Security roles,
FMT_SMF.1 Specification of
management functions
FMT_SMR.1,
FMT_SMF.1
Security Target V1.0 12 December 2005
54
TOE Security Functional
Requirements
Dependencies How met
FMT_SMF.1 Specification of
management functions
No Dependencies N/A
FMT_SMR.1 Security roles FIA_UID.1 Timing of identification FIA_UAU.5-1,
FIA_UAU.5-2
Class FPT: Protection of the TOE Security Functions
FPT_RVM_EXP.1-1 Non-bypassability
of the TSP: TOE
No dependencies N/A
FPT_SEP_EXP.1-1 TSF domain
separation: TOE
No dependencies N/A
Table 8-8 IT Environment Dependencies are Satisfied
IT Security Functional
Requirements
Dependencies How met
Class FAU: Security Audit
FAU_STG.1 Protected audit trail
storage
FAU_GEN.1 Audit data generation FAU_GEN.1
Class FIA: Identification and authentication
FIA_UAU.5-2 Multiple authentication
mechanisms
No dependencies. N/A
Class FMT: Security management
FMT_MTD.1-1 Management of TSF
data
FMT_SMR.1 Security roles,
FMT_SMF.1 Specification of
management functions
Procedural
exclusion of non-
administrative
users from IT
security functions,
FMT_SMF.1
Class FPT: Protection of the TSF
FPT_RVM_EXP.1-2 Non-bypassability
of the TSP
No dependencies N/A
FPT_SEP_EXP.1-2 TSF domain
separation
No dependencies N/A
FPT_STM.1 Reliable time stamps No dependencies N/A
8.2.3 Rationale why dependencies are not met
Several SFR have a dependency on FIA_UID.1, which is mapped to FIA_UAU.5. This
requirement is iterated in both the IT environment and in the TSF. In combination, both
iterations of FIA_UAU.5 cover all users and insure that all users are identified and
authenticated before any TSF mediated actions are permitted on the behalf of the user.
8.2.4 Strength of Function Rationale
Part 1 of the CC defines “strength of function” in terms of the minimum efforts assumed
necessary to defeat the expected security behavior of a TOE security function. There are
three strength of function levels defined in Part 1: SOF-basic, SOF-medium and SOF-high.
SOF-basic is the strength of function level chosen for this ST. SOF-basic states, “A level of
the TOE strength of function where analysis shows that the function provides adequate
protection against casual breach of TOE security by attackers possessing a low attack
Security Target V1.0 12 December 2005
55
potential.” The rationale for choosing SOF-basic was to be consistent with the assurance
requirements included in this ST; namely the environment is one where the potential attacker
is unsophisticated, with access to only standard equipment and public information about the
product, consistent with a Common Criteria Level of Evaluation of EAL2. Specifically,
AVA_VLA.1 requires that the TOE be resistant to an attacker with a low to moderate attack
potential, this is consistent with SOF-basic. Consequently, the metrics (password) chosen for
inclusion in this ST for this TOE were determined to be acceptable for SOF-basic and would
adequately protect information in a Basic Robustness Environment.
The one security function based on probabilistic methods is identified in Section 6.1.3.2 in
Table 6-3 and applies to FIA_SOS.1 (see Section 5.2.3). The specific “strength” required of
the methods used provide difficult-to-guess passwords.
8.2.5 Assurance Rationale
Evaluation Assurance Level EAL2 was chosen to provide a basic level of assurance due to
the value of the information assets and the low level threat of malicious attack potential,
including confidence that the TOE will not be tampered with during delivery. . Violation of the
information protection policy would cause minor damage to the security, safety, financial
posture, or infrastructure of the organization. The most capable threat agents are presumed to
be unsophisticated adversaries with only standard equipment and public information about the
product who are willing to take little risk, e.g., unsophisticated hackers.
8.2.6 Rationale that IT Security Requirements are internally Consistent
The IT Security Requirements are internally consistent. There are no requirements that
conflict with one another. When different IT security requirements apply to the same event,
operation, or data there is no conflict between the security requirements. The requirements
mutually support each other to apply to the configuration of the TOE, review of audit logs of
TOE configuration and IT environment operations, protection of the audit trail, protection of
TOE and user data transmitted between TOE components, authentication of users configuring
the TOE, and supporting domain separation and non-bypassability.
FAU_STG.1 Protected audit trail storage. The IT environment does not permit the deletion or
modification through the IT environment interface of the audit logs, except by an authorized
administrator.
FIA_UAU.5 Multiple authentication mechanisms, ensures that that the IT environment
minimally sets up an encrypted channel with all users prior before any action. Setting up the
encrypted channel also minimally identifies the client by presumed IP address. In the case
where the IT environment is configured to verify the user’s identify visa certificate based
authentication, the IT environment also associates certificate based security attributes with the
external user. Administrative users will be identified thorough a direct console connection.
FMT_SMR.1-2 Security roles. The TOE must support the Identification and authentication of
Administrative personnel who will configure certain TOE security parameters through the IT
environment interfaces.
FPT_RVM_EXP.1-2 Non-bypassability of the TSP. Each communication session from an
external client to the Integration server must go through an encryption process. An encrypted
connection from the IT Server platform to the client is always required. There is no way for
communication to flow between the client and the host without establishing this encrypted
connection, since the TOE or IT environment is configured to require this as a minimum. The
Security Target V1.0 12 December 2005
56
client can either be authenticated using certificate based authentication (implemented in the IT
environment), or via UID and password (implemented in the TOE). This combination of
encryption and user authentication ensures that the TSF functions are always invoked.
FPT_SEP_EXP.1-2 TSF domain separation, ensures that TSF executes in its separated
security domain, which is protected from interference and tampering by untrusted subjects.
External users are not permitted to access the IT environment components interfaces. Once
an external user is identified (and optionally authenticated using certificate based
authentication), his/her encrypted connection is passed to the TOE. If the encrypted
connection to the TOE is broken (i.e. the TOE crashes), the external user’s connection is
closed.
FPT_STM.1 Reliable time stamps. The IT environment provides reliable time stamps so that
audit logs contain reliable time stamps for each record. This dependency is not satisfied by
the TOE because the underlying operating system and hardware will provide the correct and
reliable time. The system administrator, among his duties in managing and maintaining the
security of the TOE, will keep the operating system time correct.
8.2.7 Requirements for the IT Environment
Table 8-9 shows that all of the security objectives for the IT environment are satisfied.
Rationale for each objective is included below the table.
Table 8-9 All Objectives for the IT Environment map to Requirements in the IT
environment
Identifier Objective SFR Rationale
OE.Audit The IT environment
must provide a means
to record a readable
audit trail of security-
related events, with
accurate dates and
times.
FMT_MTD.1-2
Management of TSF
data,
FPT_STM.1Reliable
time stamps
FMT_MTD.1-2 provides
that the IT environment
will audit authentication
through the operating
system., FPT_STM.1
provides for reliable
time stamps.
OE.AuditProtection The IT environment will
provide the capability to
protect audit
information.
FAU_STG.1 Protected
audit trail storage
FAU_STG.1 provides
that the IT environment
will prevent
unauthorized users
from assessing or
modifying the audit trail.
OE.IDAuth The IT environment
must be able to identify
and authenticate users
prior to allowing access
to IT environment
functions and data.
FIA_UAU.5-2 Multiple
authentication
mechanisms
FIA_UAU.5-2 provides
that users will be
identified before being
able to invoke the IT
environment’s
functions.
OE.NonBypass The IT environment
must ensure the IT
environment’s security
functional policy is
invoked and succeeds
before allowing another
IT environment function
to proceed.
FPT_RVM_EXP.1-2
Non-bypassability of
the TSP
FPT_RVM_EXP.1-2
provides that the IT
environment will
support the TOE’s non-
bypassability functions
Security Target V1.0 12 December 2005
57
Identifier Objective SFR Rationale
OE.PartialSelfProtection The IT Environment will
maintain a domain for
its own execution that
protects itself and its
resources from external
interference, tampering,
or unauthorized
disclosure, through its
own interfaces.
FPT_SEP_EXP.1-2
TSF domain separation
FPT_SEP_EXP.1-2
provides that the IT
environment will
support the TOE’s self
protection functions
OE.ProtectComm11
The IT environment
must protect
communications
between the TOE and
its users, and between
TOE components.
FIA_UAU.5-2 Multiple
authentication
mechanisms
FIA_UAU.5-2 provides
that users will be
identified as part of
setting up protected
communication
between the IS server
and the external user.
OE.Time The underlying
operating system must
provide reliable time
stamps.
FPT_STM.1 Reliable
time stamps
FPT_STM provides that
reliable time stamps
shall be provided.
8.3 TOE Summary Specification Rationale
8.3.1 IT Security Functions
Table 8-10 shows that the IT Security Functions in the TOE Summary Specification (TSS)
address all of the TOE Security Functional Requirements.
Table 8-10 Mapping of Functional Requirements to TOE Summary Specification
Functional
Component
Functional
Requirement
TSF
Ref.
No
TSF Ref. Title Rationale
FAU_GEN.1 Audit data
generation
AU-1 Audit trail Specifies the types of events to be
audited
FAU_SAR.1 Audit review AU-2 Audit review Specifies who has the capability to read
information from the audit records.
FAU_SAR.2 Restricted audit
review
AU-3 Restricted
audit review
Specifies that only specific users have
read access to the audit records.
FAU_SAR.3 Selectable audit
review
AU-4 Selectable
audit review
Specifies audit selection features for IS
Admin.
FAU_SEL.1 Selective audit AU-5 Selective audit Specifies audit events that can be
included or excluded from the audit logs
FDP_ACC.1 Subset access
control
AC-1 Access control
function
Specifies the subjects and objects
controlled under the Integration Server
Access Control SFP
11
The mapping does not address communication between TOE components. SFR (e.g.: FPT_ITT.1
and FDP_ITT.1) to support the protection of intra-TOE communication channels since the end user
could use physical means (as was shown in ), or isolation of the TOE (as was shown in
) as an alternative to IT means to support OE.ProtectComm.
Figure 2-2
Figure 2-4
Security Target V1.0 12 December 2005
58
Functional
Component
Functional
Requirement
TSF
Ref.
No
TSF Ref. Title Rationale
FDP_ACF.1 Security
attribute based
access control
AC-1 Access control
function
Specifies the Integration Server Access
Control SFP
FIA_ATD.1 User attribute
definition
IA-1 Security
Attributes
Specifies the security attributes
maintained for each user.
FIA_SOS.1 Verification of
secrets
IA-2 Password
Policy
Specifies the mechanism for secret
generation.
FIA_UAU.5-1 Multiple
authentication
mechanisms
IA-3 User
authentication
Specifies the authentication
mechanisms and that each user must
be authenticated being allowed any
other actions.
FMT_MOF.1 Management of
Security
Functions
Behavior
SM-1 Management
of Security
Functions
Specifies that the ability to manage the
behavior of security functions is
restricted to the Authorized
Administrator.
FMT_MSA.1 Management of
security
attributes
SM-2 Management
of security
attributes
Specifies that the ability to query,
modify, delete, or create the specified
security attributes is restricted to the
specified users
FMT_MSA.3 Static attribute
initialisation
SM-3 Default Values
of Security
Attributes
Specifies that restrictive default values
for security attributes are provided and
only the IS Administrator can specify
alternative initial values.
FMT_MTD.1-1 Management of
TSF data
SM-4 Management
of TSF Data
Specifies that the Integration Server
restricts the ability to access TSF data
to the Authorized Administrator.
FMT_SMF.1 Specification of
management
functions
SM-5 Specification of
Management
Functions
Specifies the security management
functions to determine the behaviour of
security functions, security attributes,
and TSF data.
FMT_SMR.1 Security roles SM-6 Security Roles Specifies the roles maintained in the
webMethods Servers.
FPT_RVM_EXP.1-1 Non-
bypassability of
the TSP: TOE
SP-1 Non-
bypassability
Specifies the TOE ensures that the
webMethods IS Access Control SFP is
invoked and succeeds before each
function is allowed to proceed.
FPT_SEP_EXP.1-1 TSF domain
separation:
TOE
SP-2 TSF domain
separation
Specifies that the TOE maintains a
security domain for its own execution
and enforces separation between
security domains of users.
8.3.2 Assurance Measures
Table 5-7 of this document identifies the Assurance Measures implemented by webMethods
to satisfy the assurance requirements of EAL2 as delineated in the table in Annex B of the
CC, Part 3. Table 6-7 maps the Assurance Requirements with the Assurance Requirement’s
Measures. The assurance measures rationale shows how all assurance requirements are
satisfied. The rationale is provided in Table 8-11. SAR dependencies identified in the CC
Security Target V1.0 12 December 2005
59
have been met by this ST as shown in Note: The actual documentation which satisfy the SAR,
for example Configuration Management, is referenced in Table 6-7.
Table 8-12.
Table 8-11 Assurance Measures Rationale
Assurance
Measure
Configuration
Management
Delivery
and
Operation
Development Guidance Test Vulnerability
Assessment
ACM_CAP.2 X
ADO_DEL.1 X
ADO_IGS.1 X
ADV_FSP.1 X
ADV_HLD.1 X
ADV_RCR.1 X
AGD_ADM.1 X
AGD_USR.1 X
ATE_COV.1 X
ATE_FUN.1 X
ATE_IND.2 X
AVA_SOF.1 X
AVA_VLA.1 X
Note: The actual documentation which satisfy the SAR, for example Configuration
Management, is referenced in Table 6-7.
Table 8-12 EAL2 SAR Dependencies Satisfied
Assurance
Component ID
Assurance Component
Name
Dependencies Satisfied
ACM_CAP.2 Configuration items None NA
ADO_DEL.1 Delivery procedures None NA
ADO_IGS.1 Installation, generation, and
start-up procedures
AGD_ADM.1 YES
ADV_FSP.1 Informal functional
specification
ADV_RCR.1 YES
ADV_HLD.1 Descriptive high-level design ADV_FSP.1, ADV_RCR.1 YES
ADV_RCR.1 Informal correspondence
demonstration
None YES
AGD_ADM.1 Administrator guidance ADV_FSP.1 YES
AGD_USR.1 User guidance ADV_FSP.1 YES
ATE_COV.1 Evidence of coverage ADV_FSP.1, ATE_FUN.1 YES
ATE_FUN.1 Functional testing None NA
Security Target V1.0 12 December 2005
60
Assurance
Component ID
Assurance Component
Name
Dependencies Satisfied
ATE_IND.2 Independent testing-sample ADV_FSP.1, AGD_ADM.1,
AGD_USR.1, ATE_FUN.1
YES
AVA_SOF.1 Strength of TOE security
function evaluation
ADV_FSP.1, ADV_HLD.1 YES
AVA_VLA.1 Developer vulnerability
analysis
ADV_FSP.1, ATE_HLD.1
AGD_ADM.1, AGD_USR.1
YES
8.4 PP Claims Rationale
Not applicable. There are no PP claims.
8.5 Explicitly Stated Requirements Rationale
The explicitly stated requirements FPT_RVM_EXP.1-1 Non-bypassability of the TSP: TOE,
FPT_SEP_EXP.1-1 TSF domain separation: TOE, FPT_RVM_EXP.1-2 Non-bypassability of
the TSP: IT environment, and FPT_SEP_EXP.1-2 TSF domain separation: IT environment,
were added because the TOE does not completely support either non-bypassability or domain
separation with out support from the IT environment.
Security Target V1.0 12 December 2005
61
9 Acronyms
Table 9-1 Acronyms
Acronym Definition
ACL Access Control Notes
CC Common Criteria [for IT Security Evaluation]
CCIMB Common Criteria Implementation Management Board
CCTL Common Criteria Testing Lab
DB2 Database 2
DSP Dynamic Server Page
EAL Evaluation Assurance Level
ebXML Electronic Business Extensible Markup Language
EDI Electronic Data Interchange
FTP File Transport Protocol
FTPS File Transport Protocol Secure sockets
GNU GNU
GUI Graphical User Interface
HTTP Hypertext Transfer Protocol (world wide web protocol)
HTTPS Hyper Text Transfer Protocol Secure sockets
ID Identifier
IETF Internet Mail Extensions
IS Integration Server
I&A Identification and Authentication
IT Information Technology
JDBC Java Database Connectivity
JMS Java Message Service
JRE Java Runtime Environment
JSP Java Server Page
JVM Java Virtual Machine
LDAP Light Weight Directory Access Protocol
MIME Multipurpose Internet Mail Extensions
NIS Network Information Services
OS Operating System
PP Protection Profile
RPC Remote Procedure Call
S/MIME Secure/Multipurpose IETF
SF Security Function
SFP Security Function Policy
SQL Structured Query Language (database query language)
SSL Secure Sockets Layer (web security protocol)
ST Security Target
TLS Transaction Layer Security
TOE Target of Evaluation
TSC TSF Scope of Control
Security Target V1.0 12 December 2005
62
Acronym Definition
TSF TOE Security Functions
TSFI TOE Security Functions Interface
TSP TOE Security Policy
TSS TOE Summary Specification
UID User Identifier
Security Target V1.0 12 December 2005
63
Security Target V1.0 12 December 2005
64
10 Bibliography
Common Criteria for Information Technology Security Evaluation Parts 1-3, CCIMB-2004-01-
001, 002 and 003, Version 2.2, Revision 256, January 2004
Common Methodology for Information Technology Security Evaluation, CCIMB-2004-01-004,
Version 2.2, Revision 256, January 2004
webMethods Broker Administrator’s Guide, Version 6.5, Document ID: BR-AG-61-
20040116BR-AG-65-20050615
webMethods Developer User’s Guide, Version 6.5, Document ID: DEV-UG-61-20040116
DEV-UG-65-20050429
webMethods Fabric Integration Platform Error Message Reference, Document ID: PLAT-EM-
RF-601-20031201
webMethods Integration Server Administrator’s Guide, Version 6.5, Document ID: webM-IS-
AG-20040116webM-IS-AG-65-20050429
webMethods Integration Server Built-In Services Reference, Version 6.5, Document ID: IS-
BIS-RF-61-20040116IS-BIS-RF-65-20050330
webMethods JDBC Adapter User’s Guide, Document ID: ADAPTER-JDBC-UG-603-20040511
webMethods JMS Adapter User’s Guide, Document ID: ADAPTER-JMS-UG-61-20040213