IBM WebSphere MQ 7.1

Transcription

1 National Information Assurance Partnership TM Common Criteria Evaluation and Validation Scheme Validation Report IBM WebSphere MQ 7.1 Report Number: CCEVS-VR-VID Dated: 30 January 2014 Version: 1.0 National Institute of Standards and Technology National Security Agency Information Technology Laboratory Information Assurance Directorate 100 Bureau Drive 9800 Savage Road STE 6940 Gaithersburg, MD Fort George G. Meade, MD

2 ACKNOWLEDGEMENTS Validation Team Mike Allen (Lead Validator) Jandria S. Alexander (Senior Validator) Aerospace Corporation Columbia, Maryland Common Criteria Testing Laboratory Science Applications International Corporation Columbia, Maryland ii

3 Table of Contents 1 Executive Summary 1 2 Identification Interpretations 4 3 Security Policy Access Control Security Audit Protection of the TSF 6 4 Assumptions and Clarification of Scope Assumptions Threats Organizational Security Policies Clarification of Scope 8 5 Architectural Information 9 6 Documentation 12 7 IT Product Testing Developer Testing Evaluation Team Independent Testing Penetration Testing 15 8 Evaluated Configuration 16 9 Results of the Evaluation Validator Comments/Recommendations Security Target Glossary Bibliography 21 List of Figures Figure 1: TOE Boundary and Components List of Tables Table 1: Evaluation Identifiers... 3 Table 2: TOE Security Assurance Requirements iii

4 1 Executive Summary This report is intended to assist the end-user of this product and any security certification Agent for that end-user in determining the suitability of this Information Technology (IT) product in their environment. End-users should review both the Security Target (ST), which is where specific security claims are made, in conjunction with this Validation Report (VR), which describes how those security claims were tested and evaluated and any restrictions on the evaluated configuration. Prospective users should carefully read the Assumptions and Clarification of Scope in Section 4 and the Validator Comments in Section 10 where any restrictions on the evaluated configuration are highlighted. This report documents the National Information Assurance Partnership (NIAP) assessment of the evaluation of the IBM WebSphere MQ 7.1. It presents the evaluation results, their justifications, and the conformance results. This Validation Report is not an endorsement of the Target of Evaluation (TOE) by any agency of the U.S. Government and no warranty of the TOE is either expressed or implied. This Validation Report applies only to the specific version and configuration of the product as evaluated and documented in the Security Target. The evaluation of the IBM WebSphere MQ 7.1 was performed by the Science Applications International Corporation (SAIC) Common Criteria Testing Laboratory (CCTL) in Columbia, Maryland, United States of America and was completed in January The information in this report is largely derived from the Security Target (ST), Evaluation Technical Report (ETR) and associated test report. The ST was written by IBM United Kingdom Limited, Hursley Park. The ETR and test report used in developing this validation report were written by SAIC. The evaluation was performed to conform to the requirements of the Common Criteria for Information Technology Security Evaluation, Version 3.1 R3, dated July 2009 at Evaluation Assurance Level 2 (EAL 2) augmented with ALC_FLR.2 and the Common Evaluation Methodology for IT Security Evaluation (CEM), Version 3.1 R3, dated July The product, when configured as specified in the installation guides, user guides, and Security Target satisfies all of the security functional requirements stated in the IBM WebSphere MQ 7.1 Security Target. The evaluation team determined the product to be both Part 2 extended and Part 3 augmented compliant, and meets the assurance requirements of EAL 2 augmented by ALC_FLR.3. All security functional requirements are derived from Part 2 of the Common Criteria. The TOE, the WebSphere MQ 7.1 is a Message-Oriented Middleware product that enables independent and potentially non-concurrent applications on a distributed system to communicate with each other. Applications use message queuing or message publication and subscription to participate in message-driven processing. In this way, applications can communicate across different platforms. For example, AIX and Oracle Solaris applications can communicate through WMQ, which shields the applications from the mechanics of the underlying communications. The TOE is available in the following operating system specific editions: WebSphere MQ for AIX 1

5 WebSphere MQ for HP-UX IA64 WebSphere MQ for Linux x86 WebSphere MQ for Linux x86_64 WebSphere MQ for Linux PPC WebSphere MQ for Linux zseries WebSphere MQ for Oracle Solaris SPARC WebSphere MQ for Oracle Solaris x86_64 WebSphere MQ for Windows. Each of these editions can support the following components, which are included within the TOE: WebSphere MQ server, which includes the queue manager WebSphere MQ C Client. In addition, WebSphere MQ for Windows supports WebSphere MQ XMS.NET/.NET/WCF clients. Each of the operating system specific editions can also support WebSphere MQ classes for JMS and WebSphere MQ classes for Java clients, but these are not included within the TOE because the underlying JVM security software is not Common Criteria EAL2 certified. In addition to the above components, there are tools and utilities to enable third party development of applications. These applications are typically referred to as WebSphere MQ Applications. These also are not within the scope of the evaluation. Similarly excluded from the scope of the evaluation are user exits, which are application or 3rd party vendor software that are invoked by WebSphere MQ as extensions to the basic product function. The validation team monitored the activities of the evaluation team, provided guidance on technical issues and evaluation processes, and reviewed the individual work units and successive versions of the ETR. The validation team found that the evaluation showed that the product satisfies all of the functional requirements and assurance requirements stated in the Security Target (ST). Therefore the validation team concludes that the testing laboratory s findings are accurate, the conclusions justified, and the conformance results are correct. The conclusions of the testing laboratory in the evaluation technical report are consistent with the evidence produced. The SAIC evaluation team concluded that the Common Criteria requirements for Evaluation Assurance Level (EAL 2 augmented with ALC_FLR.2) have been met. 2

6 2 Identification The CCEVS is a joint National Security Agency (NSA) and National Institute of Standards and Technology (NIST) effort to establish commercial facilities to perform trusted product evaluations. Under this program, commercial testing laboratories called Common Criteria Testing Laboratories (CCTLs) using the Common Evaluation Methodology (CEM) for Evaluation Assurance Level (EAL) 1 through EAL 4 in accordance with National Voluntary Laboratory Assessment Program (NVLAP) accreditation conduct security evaluations. The NIAP Validation Body assigns Validators to monitor the CCTLs to ensure quality and consistency across evaluations. Developers of information technology (IT) products, desiring a security evaluation, contract with a CCTL and pay a fee for their product s evaluation. Upon successful completion of the evaluation, the product is added to NIAP s Validated Products List. Table 1 provides information needed to completely identify the product, including: The Target of Evaluation (TOE): the fully qualified identifier of the product as evaluated; The Security Target (ST), describing the security features, claims, and assurances of the product; The conformance result of the evaluation; The Protection Profile to which the product is conformant (if any); and The organizations and individuals participating in the evaluation. Item Evaluation Scheme Table 1: Evaluation Identifiers Identifier United States NIAP Common Criteria Evaluation and Validation Scheme Target of Evaluation IBM WebSphere MQ Protection Profiles None. Security Target IBM WebSphere MQ 7.1 EAL2 Security Target, Version 0.19, 19 February, 2013 Dates of evaluation November 2011 through January 2014 Evaluation Technical Report Conformance Result Common Criteria version Common Evaluation Methodology (CEM) version Sponsor Developer Common Criteria Testing Lab Evaluators Validation Team Evaluation Technical Report for the IBM WebSphere MQ 7.1 Part 1 (Non- Proprietary), Version 0.1, 10 April 2013 Evaluation Technical Report for the IBM WebSphere MQ 7.1 Part 2 (SAIC and IBM Proprietary), Version 0.2, 5 June 2013 Part 2 extended conformant and EAL2 Part 3 augmented with ALC_FLR.2 Common Criteria for Information Technology Security Evaluation Version 3.1R3, July 2009 and all applicable NIAP and International Interpretations effective on November 14, 2011 CEM version 3.1R3 dated July2009 and all applicable NIAP and International Interpretations effective on November 14, 2011 IBM United Kingdom Limited Hursley Park Winchester Hants SO21 2JN IBM United Kingdom Limited Hursley Park Winchester Hants SO21 2JN SAIC Inc., 6841 Benjamin Franklin Drive, Columbia, MD Anthony J. Apted, Neal Haley and Dawn Campbell Jandria S. Alexander and Mike Allen of the Aerospace Corporation 3

7 2.1 Interpretations None. 4

8 3 Security Policy This section summaries the security functionality of the TOE: 1. Access Control 2. Security Audit 3. User data protection 4. Identification and authentication 5. Secure Management 6. Protection of the TSF 7. TOE access 8. Intrusion Prevention Services 3.1 Access Control The TOE controls access to objects within its scope of control. Access to an object is only given to a process acting on behalf of a user, if the user and group identifiers associated with the user have been granted permission to access that object. The user and group identifiers are obtained from the operational environment and cached in memory for subsequent access requests. The user identifier is contained within the message descriptor, which is used to confirm the user and group permissions. Permission is confirmed by checking that either the user identifier (UID) or group identifier (GID) is contained within the object s Access Control List (ACL), or that of a recursive parent in a topic hierarchy. Only administrators are able to modify the ACL or delete event messages. Administrators are users that belong to the mqm or administrator groups within the operational environment. On creation of an object, the queue manager sets default values for that object such that only the identifier associated with the process creating the object and the administrator are able to access that object. This is done by adding the creator s and administrator s UID and GIDs to the ACL of that object. Once an object has been created, then the administrator can update the ACL to grant or revoke access via the command line interface. 3.2 Security Audit The TOE can be configured to generate event messages to record various significant security auditing events. There are four different types of security auditing event message, as follows: authorization failure events channel events command events configuration events Each type of event message is put onto a different event queue. 5

9 An event queue behaves in the same manner as all other queues and like other queues has an ACL list, with access only given to the administrator (i.e. members of the mqm or administrator group). Only a user that has been granted the appropriate MQ authorization by an MQ administrator can define, delete or put-inhibit queues. All audit event messages contain the following information: Date and time Type of event Type of application that caused the event User identity The date and time information is retrieved from the operational environment each time an event message is created. The User identity is obtained from the process message descriptor. 3.3 Protection of the TSF The TOE ensures channels from WMQ clients to a WMQ server, or between two WMQ servers, are established using Transport Layer Security (TLS). The TLS support provided by WMQ provides authentication, message integrity checking, and data encryption for transmitted data. WMQ relies on IBM Global Security Kit (GSKit), version or later being present in the operational environment to provide support for TLS communications. 6

10 4 Assumptions and Clarification of Scope The assumptions, threats and policies in the following paragraphs were considered during the evaluation of the IBM WebSphere MQ Assumptions The ST identifies the following assumptions about the use of the product: It is assumed that the operating system of each system within the TOE, including any failover backup servers and any shared resources such as remote filesystems, has been configured in accordance with the manufacturer s installation guides and where applicable, in its evaluated configuration. It is securely configured such that the operating system protects the TOE from any unauthorised users or processes. It is assumed that all software and hardware, including peripheral devices, have been approved for the transmittal of protected data. Such items are to be physically protected against threats to the confidentiality and integrity of the data. It is assumed that there are one or more competent individuals that are assigned to manage the TOE and the security of the information it contains. Such personnel are assumed not to be careless, wilfully negligent or hostile. 4.2 Threats The ST identifies the following threats that the Target of Evaluation (TOE) and its operational environment are intended to counter: An authorised user of the TOE gains access to an object without the correct authority to access that object. Unauthorised attempts to access objects for which the user has no authority go undetected. An unidentified user gains access to the TOE and its objects. Data transferred between platforms is disclosed to, or modified by unauthenticated users or processes, either directly or indirectly. A non-privileged user gains administrative privileges. The operating system on which the TOE is installed becomes compromised. 4.3 Organizational Security Policies The ST identifies the following organizational security policies that the TOE and its operational environment are intended to fulfill: The right to access a specific object is determined on the basis of: o the identity of the subject attempting to access the object o or membership of a group that has access rights to the object. 7

11 4.4 Clarification of Scope All evaluations (and all products) have limitations, as well as potential misconceptions that need clarifying. This text covers some of the more important limitations and clarifications of this evaluation. Note that: 1. As with any evaluation, this evaluation only shows that the evaluated configuration meets the security claims made, with a certain level of assurance (EAL 2 augmented with ALC_FLR.2 in this case). 2. This evaluation only covers the specific version identified in this document, and not any earlier or later versions released or in process. 3. As with all EAL 2 evaluations, this evaluation did not specifically search for, nor seriously attempt to counter, vulnerabilities that were not obvious or vulnerabilities to objectives not claimed in the ST. The CEM defines an obvious vulnerability as one that is easily exploited with a minimum of understanding of the TOE, technical sophistication and resources. 4. The TOE relies on the operational environment in which it operates for the following security and other functionality: The operational environment will include an audit tool, available only to administrators, to review the audit trail. The operational environment will ensure that all users are identified. The GSKit component in the operational environment provides the TLS protocol support necessary to ensure that data transferred between platforms is secured from disclosure to or tampering by unauthenticated users. The operational environment is able to associate users with roles and maintain an administrator role. The operational environment will ensure that the clock is accurate and reliable. The operational environment will provide protection to the TOE and its assets from external interference, tampering, and disclosure. 5. Each of the operating system specific editions in the evaluated configuration can support WebSphere MQ classes for JMS and WebSphere MQ classes for Java clients, but these are not included within the TOE because the underlying JVM security software is not Common Criteria EAL2 certified. 6. The IBM WebSphere MQ product includes tools and utilities to enable third party development of applications. These applications are typically referred to as WebSphere MQ Applications. These are not within the scope of the evaluation. Similarly excluded from the scope of the evaluation are user exits, which are application or 3rd party vendor software that are invoked by WebSphere MQ as extensions to the basic product function. 8

12 5 Architectural Information Figure 1 depicts the TOE and its components, showing its relationship to the WMQ product as a whole as well as its relationship to its operational environment. The thick black line represents the TOE boundary while the shaded boxes are the components of the TOE, comprising the MQ Server and WMQ C Client. The MQ Server components comprise: Common Services Layer provides an operating system-independent, external interface to services in the operational environment that are needed by other TOE components. Queue Manager (QM) provides queuing and messaging services to applications. It offers an application programming interface (API) enabling applications to add messages to queues, retrieve messages from queues, publish messages to topics, and subscribe to receive messages from topics. It also provides system management functions allowing administrators to create queues and topics, modify attributes of queues and topics, and control the operation of the QM. The QM itself consists of the following components: o Channel Authentication Records (CHLAUTH) performs checks of inbound connection requests against Channel Authentication Records configured by the authorized administrator. Channel Authentication Records can allow or block incoming connection requests based on: the channel name; the Subject Distinguished Name of the remote personal certificate; a remote client application user ID; a remote Queue Manager name; the remote IP address of the connection. o Object Authority Manager (OAM) controls access to TOE objects and authorizes MQI calls and use of commands. o Application Interface (AI) provides an external interface to the TOE. It is responsible for accepting calls from an application and performing simple syntax checks on the parameters. o Data Abstraction and Persistence (DAP) holds the attributes of objects, such as process definitions, queues and topics, and the messages on the queues or topicbased storage. o QM Kernel responsible for implementing the detail of the AI, such as name resolution and triggering. It issues calls to the DAP component to query or alter the state of MQ objects. It is responsible for keeping track of the connections between applications and the QM and for notifying applications when messages become available. The QM kernel also generates event messages, written to the system's event queues. o Publish/Subscribe (P/S Engine) implements the TOE s publish/subscribe capabilities. It calls the OAM to perform underlying access control checks against topic objects. Command Line Interface allows an authorized administrator to configure and manage the QM. 9

13 Message Channel Agent (MCA) transfers messages from one QM to another by transmitting messages from a transmission queue to a communication link or from a communication link to a destination queue. A message channel is a one-way link with respect to the flow of messages. MQI Channel connects a WMQ C Client to a QM. It provides a two-way link and is used mainly for the transfer of MQI calls and responses. TCP/IP Listener waits for inbound socket connections from MCA and MQI Channel components on remote servers and clients, respectively. The TOE requires IBM s Global Security Kit (GSKit) version or later to be present in the operational environment to provide security of communications between MQ Servers and between an MQ Server and WMQ C Client, using TLS. 10

14 External interface to the operating system External interface to applications (via MQI or base Java or JMS bindings API) MQ Server A TOE boundary Queue Manager OAM Common Services IT1 P/S Engine DAP AI CHLAUTH QM Kernel IT1 IT3 IT4 MCA IT6 IT8 GSKit IT5 Command line interface TCP/IP Listener TLS MQI Channel from MQ Client IT2 IT2 TLS Message Channel from MQ Server GSKit GSKit IT6 IT7 IT7 IT6 MQI Channel MCA Queue Manager MQ Server B Application Administrator WMQ C Client Figure 1: Figure 1: TOE Boundary and Components 11

15 6 Documentation The guidance documentation examined during the course of the evaluation and delivered with the TOE is as follows: IBM InfoCenter MQ 7.1, 5 Jan 2013 this is an online interface for finding technical information about the TOE, including help on planning, installation, configuration, usage, tuning, monitoring, trouble shooting and maintenance. It also provides reference material including product commands, parameters and system values, and specific instructions for configuring the TOE in its evaluated configuration. In addition to being delivered and installable with the TOE, InfoCenter MQ 7.1 is accessible over the Internet. IBM WebSphere MQ Version 7.1 Quick Start Guide, Part Number CF3A8ML. The physical delivery of the TOE includes CDs for the following products and documentation that are not part of the TOE and were not included within the scope of the evaluation: WebSphere MQ File Transfer Edition version 7.0.4, including: WebSphere MQ File Transfer Edition Server DVD WebSphere MQ File Transfer Edition Clients DVD WebSphere MQ File Transfer Edition Documentation and Tools DVD WebSphere MQ File Transfer Edition Quick Start Guide IBM WebSphere MQ Advanced Message Security for Multiplatforms, version , including: WebSphere MQ Advanced Message Security Quick Start Guide 12

16 7 IT Product Testing This section describes the testing efforts of the developer and the Evaluation Team. It is derived from information contained in the Evaluation Team Test Report for IBM WebSphere MQ 7.1. Testing took place in December 2012 at the SAIC CCTL in Columbia, MD. Vendor test engineers attended the testing and assisted the evaluation team in establishing and configuring the test environment to be equivalent to the test environment at the vendor testing site, and also in running vendor tests. Further team testing was conducted in response to validator comments received during the Test VOR in January Developer Testing The developer utilizes a highly automated test infrastructure to support functional and security testing of the TOE in each of its operating system-specific editions. The developer s test approach is to test the security functionality of the TOE at its TSFI as described in the functional specification. This includes tests of the command line interface and API. The actual test results generated by the developer for each tested platform indicate that all tests were run on each platform and that all tests produced the expected test results. The developer provided test results for WebSphere MQ on the following platforms: AIX V6.1 HP-UX IA64 (V11.31) Linux for System p: RHEL V5 Linux for System x: RHEL V6 (64 bit) Linux for System x: SUSE Linux Enterprise Server V11 (32 bit) Linux for System z: RHEL V5 Oracle Solaris V10 (SPARC) Oracle Solaris V10 (x86_64) Windows Server 2003 Standard x64 Edition Windows XP Professional. The developer supplied equivalence rationale for not testing all versions of each supported operating system. Correct Common Criteria-compliant operation on untested platforms is assumed on the basis that: the same product code is used in all cases the same product has been tested successfully on at least one substantially similar operating system (i.e., a different version of the same operating system). For example, AIX V7.1 is claimed on the basis that the same WebSphere MQ 7.1 product code was successfully tested with AIX V6.1 and that there is no substantial difference between the two AIX releases in the underlying operating system services used by WebSphere MQ. 13

17 7.2 Evaluation Team Independent Testing The evaluation team executed the developer test suite per the evaluated configuration as described in the WebSphere MQ 7.1 EAL2 Security Target. The tests were run on a test configuration established in the CCTL that was equivalent to the developer test environment described in the developer s test evidence. This included the developer s test framework, which provides a capability to execute tests locally or across a network to a remote machine. The actual test environment established at the SAIC CCTL for evaluation team testing comprised: WebSphere MQ Server installed on the following platforms: o Windows Server 2003 Standard (32-bit) (with Service Pack 2) o Oracle Solaris V10 (x86_64) o Red Hat Enterprise Linux V5.0 (32-bit). WebSphere MQ C Client installed on a second Windows Server 2003 Standard platform. Server-to-server tests were run on the Windows Server platform, communicating with the Linux platform. The developer test suite was partitioned into three sets, one for each of the three platforms listed above. In this manner, the evaluation team was able to run every test in the developer s test suite. The evaluation team devised and performed additional functional test activities covering: Audit record storage and protection this evaluation team test confirmed users that are not a member of the mqm group cannot access event queues. Audit record generation and content this evaluation team activity confirmed the TOE is able to generate audit records of each of the auditable events specified in the ST, and the generated records include the required information. Audit storage exhaustion this evaluation team test confirmed that after the space configured for an event queue is filled, no further events are written to it, though the TOE continues to operate. Command level security this evaluation team activity confirmed only administrators have the capability to successfully execute control commands CHLAUTH behavior this evaluation team activity confirmed: o MQI applications which use the AI server bindings are not subject to CHLAUTH processing, so the OS user ID is used to identify the application for the purposes of OAM authority checks. o CHLAUTH records always override a client user ID sent over the network by an MQI client application. 14

18 Protected communication between TOE components this evaluation team test confirmed that communications established using TOE components use TLS with approved ciphersuites. 7.3 Penetration Testing The evaluation team performed a search of public vulnerability databases. Analysis and testing confirmed the evaluated version of the TOE is not subject to vulnerabilities identified for earlier versions of WebSphere MQ and does not use a vulnerable version of GSKit 15

19 8 Evaluated Configuration The evaluated version of the TOE is IBM WebSphere MQ The TOE is a middleware solution that allows application programs to use message queuing or message publication and subscription to participate in message-driven processing. Application programs can communicate across different platforms by using WMQ. For example, AIX and Oracle Solaris applications can communicate through WebSphere MQ. The applications are shielded from the mechanics of the underlying communications 16

20 9 Results of the Evaluation The evaluation was conducted based upon version 3.1 of the CC and the CEM. A verdict for an assurance component is determined by the resulting verdicts assigned to the corresponding evaluator action elements. The evaluation team assigned a Pass, Fail, or Inconclusive verdict to each work unit of each assurance component. For Fail or Inconclusive work unit verdicts, the evaluation team advised the developer of issues requiring resolution or clarification within the evaluation evidence. In this way, the evaluation team assigned an overall Pass verdict to the assurance component only when all of the work units for that component had been assigned a Pass verdict. The validation team agrees with the conclusion of the evaluation team, and recommended to CCEVS management that an EAL2 augmented with ALC_FLR.2 certificate rating be issued for IBM WebSphere MQ 7.1. The details of the evaluation are recorded in the Evaluation Technical Report (ETR), which is controlled by the Leidos (formerly SAIC) CCTL. The security assurance requirements are listed in the following table. Table 2: TOE Security Assurance Requirements Assurance Component ID ADV_ARC.1 ADV_FSP.2 ADV_TDS.1 AGD_OPE.1 AGD_PRE.1 ALC_CMC.2 ALC_CMS.2 ALC_DEL.1 ALC_FLR.2 ATE_COV.1 ATE_FUN.1 ATE_IND.2 AVA_VAN.2 Assurance Component Name Security architecture description Security-enforcing functional specification Basic design Operational user guidance Preparative procedures Use of a CM system Parts of the TOE CM coverage Delivery procedures Flaw reporting procedures Evidence of coverage Functional testing Independent testing - sample Vulnerability analysis 17

21 10 Validator Comments/Recommendations The validation team s observations support the evaluation team s conclusion that the IBM WebSphere MQ 7.1 meets the claims stated in the Security Target. The validation team also wishes to point to the Clarification of Scope (Section 4.4) for key limitations on the evaluated configuration of the product. It is important to note that the IBM WebSphere MQ 7.1 evaluated configuration relies heavily on the environment in which it is deployed. This is particularly the case for security audit and secure communications. Note that: Should the TOE lose access to the external audit storage and the local storage become full, the TOE will continue to operate without capturing audit data. If security requirements dictate no loss of audit data is permitted, this security requirement can not be satisfied. Secure communications relies on the GSKit for TLS implementation. GSKit is available in an evaluated form and shoud be configured accordingly. It is important to note which features of the product that were not evaluated and should not be used if the customer wishes to operate the product in the evaluated configuration. Each of the operating system specific editions can also support WebSphere MQ classes for JMS and WebSphere MQ classes for Java clients, but these were not included within the TOE because the underlying JVM security software is not Common Criteria EAL2 certified. In addition to the above components, there are tools and utilities to enable third party development of applications. These applications are typically referred to as WebSphere MQ Applications. These also were not within the scope of the evaluation. Similarly excluded from the scope of the evaluation are user exits, which are application or 3rd party vendor software that are invoked by WebSphere MQ as extensions to the basic product function. 18

22 11 Security Target The Security Target for this product s evaluation is WebSphere MQ v7.1 EAL2 Security Target, Version 0.19, dated February 19,

23 12 Glossary The following definitions are used throughout this document: Common Criteria Testing Laboratory (CCTL). An IT security evaluation facility accredited by the National Voluntary Laboratory Accreditation Program (NVLAP) and approved by the CCEVS Validation Body to conduct Common Criteria-based evaluations. Conformance. The ability to demonstrate in an unambiguous way that a given implementation is correct with respect to the formal model. Evaluation. The assessment of an IT product against the Common Criteria using the Common Criteria Evaluation Methodology to determine whether or not the claims made are justified; or the assessment of a protection profile against the Common Criteria using the Common Evaluation Methodology to determine if the Profile is complete, consistent, technically sound and hence suitable for use as a statement of requirements for one or more TOEs that may be evaluated. Evaluation Evidence. Any tangible resource (information) required from the sponsor or developer by the evaluator to perform one or more evaluation activities. Feature. Part of a product that is either included with the product or can be ordered separately. Target of Evaluation (TOE). A group of IT products configured as an IT system, or an IT product, and associated documentation that is the subject of a security evaluation under the CC. Validation. The process carried out by the CCEVS Validation Body leading to the issue of a Common Criteria certificate. Validation Body. A governmental organization responsible for carrying out validation and for overseeing the day-to-day operation of the NIAP Common Criteria Evaluation and Validation Scheme. 20

24 13 Bibliography The Validation Team used the following documents to produce this Validation Report: [1] Common Criteria Project Sponsoring Organisations. Common Criteria for Information Technology Security Evaluation: Part 1: Introduction and General Model, Version 3.1 R3, July [2] Common Criteria Project Sponsoring Organisations. Common Criteria for Information Technology Security Evaluation: Part 2: Security Functional Requirements, Version 3.1 R3, July [3] Common Criteria Project Sponsoring Organisations. Common Criteria for Information Technology Security Evaluation: Part 3: Security Assurance Requirements, Version 3.1 R3, July [4] Common Criteria Project Sponsoring Organisations. Common Methodology for Information Technology Security Evaluation, Version 3.1 R3, July [5] Common Criteria, Evaluation and Validation Scheme for Information Technology Security, Guidance to Validators of IT Security Evaluations, Scheme Publication #3, Version 2.0, September 8, [6] Science Applications International Corporation. Evaluation Team Test Report For IBM WebSphere MQ 7.1, (SAIC and IBM Proprietary), Version 0.1, 19 September [7] Science Applications International Corporation. Evaluation Technical Report for the IBM WebSphere MQ 7.1 Part 1 (Non-Proprietary), Version 0.1, 10 April [8] Science Applications International Corporation. Evaluation Technical Report for the IBM WebSphere MQ 7.1 Part 2 (Proprietary), Version 0.2, 5 June [9] IBM WebSphere MQ 7.1 EAL 2 Security Target, Issue 0.19, February 19,