Axway API Gateway v7.7 Security Target November 2021 Version 2.7 Reference : API_CC_ST_01 Document prepared by & Axway Security Target Page 2 of 70 Document History Version Date Author Description 0.1 October 15, 2019 Ken Brennock Initial draft. 0.2 November 15, 2019 Olivier MARY Inclusion of additional security objectives (Audit, Crypto) Minor changes 0.3 December 2, 2019 Olivier MARY Remarks from THALES. Remarks from AXWAY 0.4 December 12, 2019 Olivier MARY Rational added and minor consistency modifications 1.0 December 19, 2019 Olivier MARY Remarks from THALES Remarks from AXWAY 2.0 June 2020 Olivier MARY Remarks from OPPIDA after first evaluation 2.1 October 22, 2021 Mark Denihan Corrections to cryptographic details in section 6.5 2.2 Feb 5, 2021 Clive Quinn Updates 2.3 June 8, 2021 Ken Brennock Updates to section 4.2 page 23. 2.4 June 28, 2021 Ken Brennock Update to 3.2.2, page 18, A.Policy. 2.5 Sept 22, 2021 Ken Brennock Updated 1.2 version of TOE. Page 61 removed P.Key_Erase and OE.KEY_Erase, as not in scope. 2.6 Oct 18, 2021 Ken Brennock Updated section 6.2, clarifying roles. 2.7 Nov 8, 2021 Ken Brennock Updated version and patches that are used for TOE. Axway Security Target Page 3 of 70 Table of Contents 1 Introduction ................................................................................................................................. 4 1.1 Overview.......................................................................................................................... 4 1.2 Identification..................................................................................................................... 4 1.3 Conformance Claims ....................................................................................................... 4 1.4 Terminology..................................................................................................................... 6 2 TOE Description.......................................................................................................................... 7 2.1 Type................................................................................................................................. 7 2.2 Usage .............................................................................................................................. 7 2.3 Physical Scope ................................................................................................................ 9 2.4 Logical Scope ................................................................................................................ 10 2.5 Policy Filters .................................................................................................................. 11 3 Security Problem Definition....................................................................................................... 19 3.1 TOE users...................................................................................................................... 19 3.2 Assets ............................................................................................................................ 19 3.3 Threats........................................................................................................................... 19 3.4 Organizational Security Policies .................................................................................... 21 3.5 Assumptions .................................................................................................................. 21 4 Security Objectives ................................................................................................................... 23 4.1 Objectives for the Operational Environment.................................................................. 23 4.2 Objectives for the TOE .................................................................................................. 23 5 Security Requirements.............................................................................................................. 26 5.1 Conventions................................................................................................................... 26 5.2 Extended Components Definition .................................................................................. 26 5.3 Functional Requirements............................................................................................... 27 5.4 Assurance Requirements .............................................................................................. 48 6 TOE Summary Specification..................................................................................................... 50 6.1 Access Control Policy Definition.................................................................................... 50 6.2 Access Control Policy Enforcement .............................................................................. 55 6.3 Policy Security ............................................................................................................... 56 6.4 Security Audit................................................................................................................. 56 6.5 Robust Administrative Access ....................................................................................... 57 6.6 Continuity of Enforcement ............................................................................................. 58 6.7 Protected Communication ............................................................................................. 59 7 Rationale................................................................................................................................... 61 7.1 PP Conformance Claim ................................................................................................. 61 7.2 Security Objectives Rationale........................................................................................ 61 7.1 Security Requirements Rationale .................................................................................. 65 7.2 TOE Summary Specification Rationale ......................................................................... 68 Axway Security Target Page 4 of 70 1 Introduction 1.1 Overview The Axway API Gateway is an enterprise security management solution that provides management in a centralized location for access control over web services and related resources. The Axway API Gateway is a comprehensive platform for managing, delivering, and securing Web APIs. It provides integration, acceleration, governance, and security for API and SOA-based systems. This Security Target (ST) defines the Axway API Gateway v7.7 Target of Evaluation (TOE) for the purposes of Common Criteria (CC) evaluation. Whilst the Axway API Gateway offers a wide range of features, the TOE is constrained to the security features identified in section 2.3. 1.2 Identification Table 1: Evaluation identifiers Target of Evaluation Axway API Gateway v. 7.7 Version 7.7.20210530 with APIGateway_7.7.20210530_Patch24803_6b68457e_allOS_BN20210708, APIGateway_7.7.20210530_Patch24985_c185313c_allOS_BN20210723, APIGateway_7.7.0_Patch25454_95d32974_linux-x86-64_BN20211028, APIGateway_7.7.0_Patch25644_c6c4d330_allOS_BN20211019 Security Target Axway API Gateway 7.7 - Security Target – Nov. 2021 – Version 2.7 1 Evaluation Level EAL4+ (AVA_VAN.4 and ALC_FLR.3) 1.3 Conformance Claims a. Common Criteria for Information Technology Security Evaluation, Part 2: Security Functional Components; Version 3.1, Revision 5, CCMB-2017-04-002; extended (Conformant) b. Common Criteria for Information Technology Security Evaluation, Part 3: Security Assurance Components; Version 3.1, Revision 5, CCMB-2017-04-003; (Conformant) c. This document is conformant to EAL4 and the activities extra for ‘plus’ (ALC_FLR.3 & AVA_VAN.4) d. RGS ANSSI : Annexe B1 Mécanismes cryptographiques Règles et recommandations concernant le choix et le dimensionnement des mécanismes cryptographiques Version 2.03 du 21 février 2014 1 Based on API Gateway Version 7.7.20210530 with APIGateway_7.7.20210530_Patch24803_6b68457e_allOS_BN20210708, APIGateway_7.7.20210530_Patch24985_c185313c_allOS_BN20210723, APIGateway_7.7.0_Patch25454_95d32974_linux-x86-64_BN20211028, APIGateway_7.7.0_Patch25644_c6c4d330_allOS_BN20211019 including API Gateway, Policy Studio and API Gateway Manager software Axway Security Target Page 5 of 70 e. RGS ANSSI : Annexe B2 Gestion des clés cryptographiques Règles et recommandations concernant la gestion des clés utilisées dans les mécanismes cryptographiques Version 2.00 du 8 juin 2012 f. The ST is based on the following Protection Profiles but no conformance is claimed: i) Standard Protection Profile for Enterprise Security Management Access Control v2.1, dated October 24, 2013. Axway Security Target Page 6 of 70 1.4 Terminology Table 2: Terminology Term Definition API Application Programming Interface CC Common Criteria EAL Evaluation Assurance Level ESM Enterprise Security Management PP Protection Profile SOA Service-Oriented Architecture SOAP Simple Object Access Protocol ST Security Target TOE Target of Evaluation Axway Security Target Page 7 of 70 2 TOE Description 2.1 Type The TOE is a comprehensive platform for managing, delivering, and securing APIs allowing for centralized enterprise security management solutions. The TOE controls how APIs and web services are exposed to and accessed by external client applications. 2.2 Usage The TOE comprises the Axway API Gateway v7.7 software. The API Management architecture is as follows: a. The API provider is the enterprise that makes the virtualized APIs for back-end applications available for API clients to consume. The API provider runs API Gateway and Policy Studio. For example, the API provider could be a credit card company that provides payment services to various customers. b. The API clients are the end-user customer and partner organizations that consume the APIs made available by the API provider. For example, these could be specific hotel and retail organizations that enable their customers to make payments by credit card. Axway Security Target Page 8 of 70 Figure 1: API Gateway Architecture Figure 2: TOE usage scenario Figure 2 shows the following non-TOE components: a. Outer Firewall b. Inner Firewall c. Service Consumer d. Service Producer The TOE provides the following core functionality: Axway Security Target Page 9 of 70 Identity Mediation. Through its support for a wide range of security standards, Axway API Gateway enables identity mediation between different identity schemes. For example, the API Gateway can authenticate external clients by username and password, but then issue SAML tokens that are used for identity propagation to application servers. API Management. The API Gateway enables you to secure Web APIs against attack and abuse. It also enables you to govern and meter access to and usage of Web APIs. The API Gateway provides support for API management security standards such as OAuth. This enables you to share private resources with thirdparty websites without needing to provide credentials. Application-level Networking. The API Gateway routes data based on sender identity, content, and type. This enables messages to be sent to the appropriate application in a secure manner. It also enables service virtualization, where services are exposed to clients with virtual addresses to mask their actual addresses for security and application delivery. In this way, the API Gateway acts as an important control point for network traffic by shielding endpoint services from direct access. Audit Trail. The API Gateway satisfies audit requirements by enabling service transactions to be archived in a tamper-proof store for subsequent audit. Axway also facilitates privacy compliance support by allowing sensitive information, such as customer names, to be encrypted or stripped out of message traffic. Policy Definition. Policy Studio provides a tool for developing policies that are enforced by one or more instances of API Gateway. When several instances of API Gateway are organized into groups they are managed via a Node Manager which ensures that the same policies are deployed on all the API Gateway instances in the group, and all group members enforce the same policies and virtualize the same API and web services. 2.3 Physical Scope The TOE comprises the Axway API Gateway v7.7 software which includes Axway API Gateway v7.7 core service pack (SP2). The TOE is deployed as a software component comprised of three main components for policy definition and policy consumption as follows: a) Policy Studio. A GUI application that provides the user with the primary administrative interface to the Gateway. Policy Studio is used to construct policies and administer the TOE. Policy Studio pushes policies to multiple gateway instances; it submit the policies to the admin node manager which propagate new policies to all the node managers in the enterprise. b) API Gateway. One or more instances of the API Gateway software that enforce policies to control web services. Basic configuration is performed using the Policy Studio to virtualize APIs and develop policies (for example, to enforce security, compliance, and operational requirements). Each Gateway instance has a corresponding node manager on the same host; it is part of the API Gateway server. One Node Manager is designated as the admin node manager. A simple TOE deployment is depicted in Figure 2. c) API Gateway Manager. A web-based interface for monitoring Gateway traffic in real-time and for configuring global password policy, audit events, audit offload, and other such events Axway Security Target Page 10 of 70 2.3.1 Guidance Documents The guidance documents are available at https://docs.axway.com/bundle/axway- open-docs/ 2.3.2 Non-TOE Components The TOE operates with the following components in the environment: a. DHCP Server. The TOE can utilize a Dynamic Host Configuration Protocol (DHCP) server to acquire automatically assign an IP address. b. Time Server. The TOE can utilize a Network Time Protocol (NTP) server to synchronize its system clock with a central time source. c. Web Browser. The remote administrator can use a web browser to access the Web GUI interface (API Gateway Manager). See below for supported browsers. d. LDAP Server – Used for external Identification and Authentication for administrators and client service users. e. Audit Server – Used for external audit storage. The API Gateway TOE component operates on the following operating system: i) Redhat Enterprise Linux 7 The Policy Studio TOE component operates on the same operating systems as the API Gateway and Linux and Solaris it requires also xWindows environment and GTK+2. The API Gateway Manager TOE component runs on the following web browsers: a. Internet Explorer 11 b . Chrome 78 The installation and guidance documentation specify any specific security settings for the web browsers. 2.4 Logical Scope The logical scope of the TOE comprises the following security functions: Access Control Policy Definition - This security function refers to the access control policy definition capabilities of the API Gateway. Policy Studio and API Gateway Manager are the Policy Management tools that are used to configure and define access control policies for Axway API Gateway, which is the compatible Access Control product. Access Control Policy Enforcement - The API Gateway enforces polices defined by the Policy Studio (see section 6.1 for policy types). In the evaluated configuration, the Gateway may only consume policies created and deployed from the Axway Policy Studio. Policy Security - Policy Studio transmits policies to the Gateway when they are explicitly deployed by the policy developer. A trusted channel (TLS) is established between Policy Studio and the Gateway to protect the transmission of policy data. Security Audit - The TOE generates the audit events identified in Table 18. The TOE may store logs locally on the file system or remotely on an external audit server. Axway Security Target Page 11 of 70 Communication with the external audit server is secured using TLS (refer to section 6.7 for detail). Robust Administrative Access - Access to the TOE can be achieved via the Policy Studio application and the web-based API Gateway Manager interface. Users must authenticate prior to being granted access. Users may authenticate via username and password. Continuity of Enforcement - The Gateway continues policy enforcement in the event of a loss of connectivity with Policy Studio by enforcing the last policy received. Continuous connectivity with the Policy Studio is not expected or required. Protected Communication: The TOE uses TLS to provide trusted channels for communication between its separate components; between itself and an external LDAP server and between itself and an external HTTP-based audit server. It provides a trusted path via HTTPS for remote administrators to access the TOE external interfaces. 2.5 Policy Filters The core functionality of the Axway API Gateway is its ability to define and enforce policies to protect APIs and web services. To achieve this, the Axway API Gateway utilizes security policies comprising message filters where each filter processes the message in a certain way. For example, authentication filters extract user credentials from the message in order to authenticate the sender. Similarly, authorization filters use the extracted credentials to authorize the user against a number of 3 rd party Identity Management servers to ensure that the user has permissions to access the requested resource. The API Gateway also ships with a whole range of other content-based, routing, conversion and other types of filters that are not directly related to access control or security. In order to clarify the relationship between policy filters and the scope of evaluation, the following table classifies each policy filter as one of the following: a) Enforcing. Filters that enforce the TOE security policy and are the focus of this evaluation. b) Unevaluated Functional. Filters that facilitate product functionality and may be present in the evaluated configuration but that do not interfere with the security functions of the TOE. Such filters have not been evaluated. c) Unevaluated Security. Filters that are security related but have not been evaluated. Table 3: Policies (ESM Policy Manager PP) Filter Enforcing Unevaluated functionality Unevaluated security Authentication Filters HTTP Basic Authentication X HTTP Digest Authentication X Axway Security Target Page 12 of 70 Filter Enforcing Unevaluated functionality Unevaluated security SSL (HTTPS Interface with mutual authentication) X Attribute Authentication X Authenticate API Key X CA SOA Security Manager X Check Session X Create Session X End Session X HTML Form-based Authentication X HTTP Header X IP Address X Insert SAML Authentication Assertion X Insert Timestamp X Insert WS-Security Username Token X Kerberos Client X Kerberos Service X SAML Authentication X SAML PDP Authentication X Security Token Service Client X WS-Security Username Token Authentication X Authorization Filters LDAP RBAC X SAML Authorization X RSA Access Manager X Attribute Authorization X Axway PassPort Authorization X CA SOA Security Manager X Certificate Attributes X Axway Security Target Page 13 of 70 Filter Enforcing Unevaluated functionality Unevaluated security Entrust GetAccess X Insert SAML Authorization Assertion X SAML PDP Authorization X Tivoli X XACML PEP X Content Filtering Filters Content Type X Content Validation X JSON Schema Validation X XML Schema Validation X Message Size X Threatening Content X Validate Timestamp X XML Complexity X ClamAV Anti-virus X McAfee Anti-virus X Sophos Anti-virus X ICAP X Throttling X Validate Selector Expression X Validate HTTP Headers X Validate Query String X Validate REST Filter X WS-Security Policy Layout X Integrity Filters XML Signature Generation X XML Signature Verification X Axway Security Target Page 14 of 70 Filter Enforcing Unevaluated functionality Unevaluated security SMIME Sign X SMIME Verify X Encryption Filters XML Encryption Settings X XML Encryption X XML Decryption Settings X XML Decryption X SMIME Encrypt X SMIME Decrypt X PGP Encrypt and Sign X PGP Decrypt and Verify X Generate Key X Certificate Filters CRL (Dynamic) X CRL (in LDAP) X CRL (static) X CRL Responder X Certificate Chain X Certificate Validity (i.e. Expired) X Create Thumbprint X Extract Certificate Attributes X Find Certificate X OCSP Client X Validate Server’s Certificate Store X XKMS X Cache Filters Cache Attribute X Axway Security Target Page 15 of 70 Filter Enforcing Unevaluated functionality Unevaluated security Create Key X Is Cached? X Remove Cached Attribute X Monitoring Filters Alert X Log Message Payload X SLA Filter X Axway Sentinel Event X Axway Sentinel Link Event X Attribute Filters Compare Attributes X Extract REST Request Attributes X Extract WSS Header Block X Extract WSS Timestamp X Extract WSS Username Token X Get Cookie X Insert SAML Attribute Assertion X JSON Path X Retrieve from Directory Server X Retrieve from HTTP Header X Retrieve from SAML Attribute Assertion X Retrieve from SAML PDP X Retrieve from Tivoli X Retrieve from Message X Retrieve from or Write to Database X Retrieve from User Store X Routing Filters Axway Security Target Page 16 of 70 Filter Enforcing Unevaluated functionality Unevaluated security Connect to URL X Connection X Dynamic Router X Static Router X Extract Path Parameters X File Upload X File Download X HTTP Redirect X HTTP Status Code X Insert WS-Addressing X Read WS-Addressing X Read from JMS X Rewrite URL X SMTP X Save to File X Send to JMS X TIBCO Rendezvous X Utility Filters Time Filter X Check Group Membership X Management Services RBAC X Scripting Language Filter X Copy/Modify Attributes X CA SiteMinder Filters Authentication X Authorization X Certificate Authentication X Axway Security Target Page 17 of 70 Filter Enforcing Unevaluated functionality Unevaluated security Logout X Session Validation X Fault Filters SOAP Fault X Generic Error X JSON Error X Oracle Access Manager Filters Authentication X Authorization X Log in with Certificate X Log out Session X SSO Token Validation X Oracle Entitlements Server Filters 10g Authorization X 10g Get Roles X 11g Authorization X Sun Access Manager Filters Authentication X Authorization X Log Out Session X Retrieve Attributes X SSO Token Validation X X.509 Certificate Authentication X WS-Trust Filters Create WS-Trust X Consume WS-Trust X Web Service Filters X Axway Security Target Page 18 of 70 Filter Enforcing Unevaluated functionality Unevaluated security Security Services Filters X Resolver Filters X OpenID Connect Filters X OAuth 2.0 Filters X OAuth 2.0 Client Filters X Conversion Filters X Amazon Web Services Filters X Axway Security Target Page 19 of 70 3 Security Problem Definition 3.1 TOE users  Administrators : individuals that perform administrative operation on the ToE.  Operators : individuals that have non-administrative access to the ToE. They can have restriction on operation according to the security policy defined for non administratives users.  Service consumers or providers : applications that interact with the ToE using filters defined in chapter 2.5. 3.2 Assets 3.2.1 Assets that are in the ToE environment Table 4: Threats (ESM Policy Manager PP) Identifier Description A.ENDUSER_DATA Flows of information that are sent across the Gateway by end-users of the solution. End users can be a individual or a process running on a machine. Security needs : integrity 3.2.2 Assets of the ToE Table 5: Threats (ESM Policy Manager PP) Identifier Description A.POLICY Access control policy that is defined in the Policy Manager and sent to the Gateway in order to be enforced Security needs :availability. A.AUDIT_TRAIL Security events that are generated by the Gateway or by Policy Manager. Security needs : integrity, availability. A.CREDENTIALS Login and password that are used by users of the ToE (administrators, operators,…) Security needs : confidentiality A.CIPHEINRG_KEYs Keys that are used to establish secure communication or to store sensitive information inside the ToE. Security needs : confidentiality, integrity, authenticity 3.3 Threats 3.3.1 Threat Actors Attackers that could affect the security of the ToE are: End-users of the ToE (individual or process running on a machine) could alter/forge information flows that are sent to the ToE in order to bypass the security policy. Users of the ToE with non-administrative access, can try to alter their privileges in order to modify the behavior of the ToE. Axway Security Target Page 20 of 70 Malicious individuals can try to gain access to the ToE or forge malicious information flows. 3.3.2 List of threats Table 6 identifies the threats drawn from the ESM Policy Manager PP. Table 6: Threats (ESM Policy Manager PP) Identifier Description T.ADMIN_ERROR An administrator may unintentionally install or configure the TOE incorrectly, resulting in ineffective security mechanisms. T.CONDTRADICT A careless administrator may create a policy that contains contradictory rules for access control enforcement. T.EAVES A malicious user could eavesdrop on network traffic to gain unauthorized access to TOE data. T.FORGE A malicious user may exploit a weak or nonexistent ability for the TOE to provide proof of its own identity in order to send forged policies to an Access Control product. T.UNAUTH A malicious user could bypass the TOE’s identification, authentication, or authorization mechanisms in order to illicitly utilize the TOE’s management functions. T.WEAKPOL A Policy Administrator may be incapable of using the TOE to define policies in sufficient detail to facilitate robust access control, causing an Access Control product to behave in a manner that allows illegitimate activity or prohibits legitimate activity. T.WEAKIA A malicious user could be illicitly authenticated by the TSF through brute-force guessing of authentication credentials. Table 7 identifies the threats drawn from the ESM Access Control PP. Table 7: Threats (ESM Access Control PP) Identifier Description T.DISABLE A malicious user or careless user may suspend or terminate the TOE’s operation, thus making it unable to enforce its access controls upon the environment or TOE-protected data. T.FALSIFY A malicious user can falsify the TOE’s identity, giving the Policy Management product false assurance that the TOE is enforcing a policy. T.MASK A malicious user could bypass the TOE’s identification, authentication, or authorization mechanisms in order to illicitly utilize the TOE’s management functions. T.NOROUTE A malicious or careless user may cause the TOE to lose connection to the source of its enforcement policies, adversely affecting access control behaviors. Axway Security Target Page 21 of 70 Identifier Description T.OFLOWS A malicious user may attempt to provide incorrect Policy Management data to the TOE in order to alter its access control policy enforcement behavior. Another Threat should be considered regarding the Policy : T.BYPASS_POLICY An attacker tries to send malicious or unauthorized information through the Policy enforced by the ToE. He/she also can try to bypass the policy. 3.4 Organizational Security Policies Table 8 identifies the Organizational Security Policies (OSPs) drawn from the ESM Policy Manager PP that are addressed by the TOE. Table 8: OSPs from ESM Policy Manager PP Identifier Description P.BANNER The TOE shall display an initial banner describing restrictions of use, legal agreements, or any other appropriate information to which users consent by accessing the system. Table 9 identifies the Organizational Security Policies (OSPs) drawn from the ESM Access Control PP that are addressed by the TOE. Table 9: OSPs from ESM Access Control PP Identifier Description P.UPDATEPOL The organization will exercise due diligence to ensure that the TOE is updated with relevant policy data. An OSP defined specifically defined for the ToE is : P.KEY_ERASE : The organization will exercise due diligence to ensure that cryptographic keys are erased in a secure manner when no more used. 3.5 Assumptions Table 10 identifies the assumptions drawn from the ESM Policy Manager PP. Table 10: Assumptions (ESM Policy Manager PP) Axway Security Target Page 22 of 70 Identifier Description AS.SYSTIME The TOE will receive reliable time data from the Operational Environment AS.USERID The TOE will receive identity data from the Operational Environment. AS.MANAGE There will be one or more competent individuals assigned to install, configure, and operate the TOE. Table 11 identifies the assumptions drawn from the ESM Access Control PP. Table 11 Assumptions (ESM Access Control PP) Identifier Description AS.POLICY The TOE will receive policy data from the Operational Environment. AS.INSTALL There will be a competent and trusted administrator who will follow the guidance provided in order to install the TOE. Axway Security Target Page 23 of 70 4 Security Objectives 4.1 Objectives for the Operational Environment Table 12 identifies the objectives for the operational environment drawn from the ESM Policy Manager PP. Table 12: Operational environment objectives (ESM Policy Manager PP) Identifier Description OE.ADMIN There will be one or more administrators of the Operational Environment that will be responsible for managing the TOE. OE.INSTALL Those responsible for the TOE shall ensure that the TOE is delivered, installed, managed, and operated in a secure manner. OE.PERSON Personnel working as TOE administrators shall be carefully selected and trained for proper operation of the TOE. OE.SYSTIME The Operational Environment will provide reliable time data to the TOE. OE.USERID The Operational Environment shall be able to identify a user requesting access to the TOE. Table 13 identifies the objectives for the operational environment drawn from the ESM Access Control PP. Table 13: Operational environment objectives (ESM Access Control PP) Identifier Description OE.POLICY The Operational Environment will provide the definition of a policy that the TOE will generate and enforce. The definition of the policy is considered as accurate and provided by skilled administrators. An objective is defined for the environment of ToE concerning the secure erasing of cryptographic keys. OE.KEY_ERASE : the Operationnel Environment will provide procedures to erase cryptographics keys when no longer used. 4.2 Objectives for the TOE Table 14 identifies the security objectives for the TOE drawn from the ESM Policy Manager PP. Table 14: Security objectives (ESM Policy Manager PP) Identifier Description Axway Security Target Page 24 of 70 O.ACCESSID The TOE will contain the ability to validate the identity API Gateway prior to distributing data (i.e policies) to them. O.AUDIT The TOE will provide measures for generating and recording security relevant events that will detect access attempts to TOE-protected resources by users. The TOE must provide a means to record a readable audit trail of information flows through the TOE and for authorized administrator use of security functions related to audit, with accurate dates and times, and a means to search and sort the audit trail based on relevant attributes. Also, the TOE must prevent unauthorized users from accessing the audit trail. O.AUTH The TOE will provide a mechanism to securely validate requested authentication attempts and to determine the extent to which any validated subject is able to interact with the TSF. O.BANNER The TOE will display an advisory warning regarding use of the TOE. O.CONSISTENT The TSF will provide a mechanism to identify and rectify contradictory policy data. O.DISTRIB The TOE will provide the ability to distribute policies to trusted IT products using secure channels. O.INTEGRITY The TOE will contain the ability to assert the integrity of end- users data to be transferred to the ToE, while the policy data integrity will be managed via the file system. O.MANAGE The TOE will provide the ability to manage the behavior of trusted IT products using secure channels. O.POLICY The TOE will provide the ability to generate policies that are sufficiently detailed to satisfy the Policy Filter defined in chapter 2.5 and selected as “Enforcing”. O.PROTCOMMS The TOE will provide protected communication channels or administrators, other parts of a distributed TOE, and authorized IT entities. O.ROBUST The TOE will provide mechanisms to reduce the ability for an attacker to impersonate a legitimate user during authentication. O.CRYPTO The TOE must provide cryptographic means including generation and validation of digital signatures, generation and validation of XML signatures, XML payload encryption and decryption, and encryption and decryption of messages during processing of information flow control. Table 15 identifies the security objectives for the TOE drawn from the ESM Access Control PP. Table 15: Security objectives (ESM Access Control PP) Identifier Description O.DATAPROT The TOE will protect data (Policies and End users data) from unauthorized modification by enforcing an access control policy produced by a Policy Management product. Axway Security Target Page 25 of 70 O.MAINTAIN The TOE will be capable of maintaining access control policy enforcement if it is unable to communicate with the Policy Management product which provided it the policy. O.MNGRID The TOE will be able to identify and authorize a Policy Management product prior to accepting policy data from it. O.MONITOR The TOE will monitor the behavior of itself for anomalous activity (e.g., provide measures for generating and recording security relevant events that will detect access attempts to TOE-protected resources by users). O.OFLOWS The TOE will be able to recognize and discard invalid or malicious input provided by users. O.RESILIENT The TOE shall not allow to perform an operation that would disable or otherwise modify the behavior of the TOE unless performed by an authorized user. O.SELFID API gateway will be able to confirm its identity to the Policy Studio while sending receipt of a new policy arrival. Axway Security Target Page 26 of 70 5 Security Requirements 5.1 Conventions This document uses the following font conventions to identify the operations defined by the CC: a. Assignment. Indicated with italicized text. b. Refinement. Indicated with bold text and strikethroughs. c. Selection. Indicated with underlined text. d. Assignment within a Selection: Indicated with italicized and underlined text. e. Iteration. Indicated by appending the iteration number in parenthesis, e.g., (1), (2), (3). Explicitly stated SFRs are identified by having a label ‘EXT’ after the requirement name for TOE SFRs. 5.2 Extended Components Definition Table 16 identifies the extended components which are incorporated into this ST. All extended components are reproduced directly from the ESM PM and the ESM AC protection profiles and therefore no further definition is provided in this document. Table 16: Extended Components Component Title Source ESM_ACD.1 Access Control Policy Definition ESM Policy Management PP ESM_ACT.1 Access Control Policy Enforcement ESM Policy Management PP ESM_ATD.1 Object Attribute Definition ESM Policy Management PP ESM_ATD.2 Subject Attribute Definition ESM Policy Management PP ESM_EAU.2 Reliance on Enterprise Authentication ESM Policy Management PP ESM_EID.2 Reliance on Enterprise Identification ESM Access Control PP FAU_SEL_EXT.1 External Selective Audit ESM Policy Management PP FAU_STG_EXT.1 External Audit Trail Storage ESM Policy Management PP ESM Access Control PP FCS_HTTPS_EXT.1 HTTPS ESM Policy Management PP ESM Access Control PP FCS_TLS_EXT.1 TLS ESM Policy Management PP ESM Access Control PP FMT_MOF_EXT.1 External Management of Functions Behavior ESM Policy Management PP FMT_MSA_EXT.5 Management of Security Attributes ESM Policy Management PP FPT_APW_EXT.1 Protection of Stored Credentials ESM Policy Management PP ESM Access Control PP FPT_FLS_EXT.1 Failure of Communications ESM Access Control PP FPT_SKP_EXT.1 Protection of Secret Key Parameter ESM Policy Management PP ESM Access Control PP Axway Security Target Page 27 of 70 5.3 Functional Requirements Table 17: Summary of SFRs Component Title Source ESM_ACD.1 Access Control Policy Definition ESM Policy Management PP ESM_ACT.1 Access Control Policy Enforcement ESM Policy Management PP ESM_ATD.1 Object Attribute Definition ESM Policy Management PP ESM_ATD.2 Subject Attribute Definition ESM Policy Management PP ESM_EAU.2 Reliance on Enterprise Authentication ESM Policy Management PP ESM_EID.2 Reliance on Enterprise Identification ESM Access Control PP FAU_GEN.1 Audit Data Generation ESM Policy Management PP ESM Access Control PP FAU_SEL.1 Selective Audit ESM Access Control PP FAU_SEL_EXT.1 External Selective Audit ESM Policy Management PP FAU_STG.1 Protected Audit Trail Storage (Local Storage) ESM Access Control FAU_STG_EXT.1 External Audit Trail Storage ESM Policy Management PP ESM Access Control PP FAU-SAR.1 Audit review FAU_SAR.3 Selectable audit review FCO_NRR.2 Enforced proof of receipt ESM Access Control PP FCS_HTTPS_EXT.1 HTTPS ESM Policy Management PP ESM Access Control PP FCS_TLS_EXT.1 TLS ESM Policy Management PP ESM Access Control PP FDP_ACC.1 Access Control Policy (Host Based) ESM Access Control PP FDP_ACF.1 Access Control Function ESM Access Control PP FDP_IFC.1 Subset information flow control FDP_IFF.1 Simple Security attributes FIA_AFL.1 Authentication Failure Handling ESM Policy Manager PP FIA_SOS.1 Verification of Secrets ESM Policy Manager PP FIA_USB.1 User-Subject Binding ESM Policy Management PP FMT_MOF.1(1) Management of Functions Behavior ESM Access Control PP FMT_MOF.1(2) Management of Functions Behavior ESM Access Control PP FMT_MOF_EXT.1 External Management of Functions Behavior ESM Policy Management PP FMT_MSA.1 Management of Security Attributes ESM Access Control PP FMT_MSA.3 Static Attribute Initialization ESM Access Control PP FMT_MSA_EXT.5 Management of Security Attributes ESM Policy Management PP FMT_SMF.1 Specification of Management Functions ESM Access Control PP ESM Policy Management PP FMT_SMR.1 Security Roles ESM Policy Management PP ESM Access Control PP FMT_MTD.1 Management of TSF Data FPT_APW_EXT.1 Protection of Stored Credentials ESM Policy Management PP ESM Access Control PP FPT_FLS_EXT.1 Failure of Communications ESM Access Control PP FPT_RPL.1 Replay Detection ESM Access Control PP Axway Security Target Page 28 of 70 Component Title Source FPT_SKP_EXT.1 Protection of Secret Key Parameter ESM Policy Management PP ESM Access Control PP FPT_TDC Inter-TSF basic TSF Data Consistency FRU_FLT.1 Degraded Fault Tolerance ESM Access Control PP FTA_SSL.3 TSF-initiated Termination ESM Policy Management PP FTA_SSL.4 User Initiated Termination ESM Policy Management PP FTA_TAB.1 TOE Access Banner ESM Policy Management PP FTP_ITC.1 Inter-TSF Trusted Channel ESM Policy Management PP ESM Access Control PP FTP_TRP.1 Trusted Path ESM Policy Management PP FCS_CKM.1 Key generation FCS_CKM.2 Key distribution FCS_COP.1(ENC) Cryptographic operation FCS_COP.1(MAC) Cryptographic operation FCS_COP.1(MD) Cryptographic operation FCS_COP.1(SGN) Cryptographic operation 5.3.1 Subjects, objects, attributes and operations Subjects: 5.3.1.1  users  API and/or Web Service Clients (Source: external users)]  requesting application Objects: 5.3.1.2  APIs and/or Web Services (Source: TOE published APIs and services];  APIs and Web services:  URLs  Files  CGI Scripts  Forms Operations: 5.3.1.3  Operations exposed by the web service/API  Request  Response  Access via HTTP operations  Open | Download  Execute  Enable | Disable  HTTP GET | HTTP POST Axway Security Target Page 29 of 70 Attributes 5.3.1.4  :[ Username,  PolicyName,  path.  Policy ID  filter name  Authentication credentials  Username/Group,  Role  [event type]; and  [date and time].  IP source address  IP destination address  TCP port  request URL  XML Schema Definition  XML signature  message content  size of message 5.3.2 Class ESM: Enterprise Security Management (ESM) 5.3.1.1 ESM_ACD.1 Access Control Policy Definition Hierarchical to: No other components. ESM_ACD.1.1 The TSF shall provide the ability to define access control policies for consumption by one or more compatible Access Control products. ESM_ACD.1.2 Access control policies defined by the TSF shall be capable of containing the following: Subjects: [API and/or Web Service Clients (Source: external users)]; and Objects: [[APIs and/or Web Services (Source: TOE published APIs and services]; and Operations: [Operations exposed by the web service/API]; and Attributes:[ Username, and PolicyName, path.)] ESM_ACD.1.3 The TSF shall associate unique identifying information with each policy. Dependencies: No dependencies 5.3.1.2 ESM_ACT.1 Access Control Policy Transmission ESM_ACT.1.1 The TSF shall transmit policies to compatible and authorized Access Control products under the following circumstances: [immediately following creation of a new or updated policy]. 5.3.1.3 ESM_ATD.1.1 Object Attribute Definition Hierarchical to: No other components Axway Security Target Page 30 of 70 ESM_ATD.1.1 The TSF shall maintain the following list of security attributes belonging to individual objects: [Object: APIs and Web services: Attributes: Policy ID, filter name. ESM_ATD.1.2 The TSF shall be able to associate security attributes with individual objects. Dependencies: No Dependencies. 5.3.1.4 ESM_ATD.2 Subject attribute definition Hierarchical to: No other components. ESM_ATD.2.1 The TSF shall maintain the following list of security attributes belonging to individual subjects: [Subject: API and Web Service Clients Attributes: Authentication credentials, Username/Group, Role] ESM_ATD.2.2 The TSF shall be able to associate security attributes with individual subjects. Dependencies: No dependencies 5.3.1.5 ESM_EAU.2 Reliance on Enterprise Authentication Hierarchical to: No other components. ESM_EAU.2.1 The TSF shall rely on [external LDAP service and API Gateway] for subject authentication. ESM_EAU.2.2 The TSF shall require each subject to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that subject. Dependencies: ESM_EID.2 Reliance on Enterprise Identification 5.3.1.6 ESM_EID.2 Reliance on Enterprise Identification Hierarchical to: No other components. ESM_EID.2.1 The TSF shall rely on [external LDAP service and API Gateway] for subject identification. ESM_EID.2.2 The TSF shall require each subject to be successfully identified before allowing any other TSF-mediated actions on behalf of that subject. Dependencies: No dependencies. Axway Security Target Page 31 of 70 5.3.3 Class: Security Audit (FAU) 5.3.2.1 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; and b) All auditable events identified in table 16 for the [not specified] level of audit; and c) All administrative actions; FAU_GEN.1.2 The TSF shall record within each audit record at least the following information: a) Date and time of the event, type of event, subject identity (if applicable), and the outcome (success or failure) of the event; and b) For each audit event type, based on the auditable event definitions of the functional components included in the PP/ST, [information specified in column three of Table 16]. Dependencies: FPT_STM.1 Reliable Time Stamps Table 18 – Auditable Events Component Event Additional Information ESM_ACD.1 Creation or modification of policy Unique policy identifier ESM_ACT.1 Transmission of policy to Access Control products Destination of policy ESM_ATD.1 Definition of object attributes Identification of the attribute defined ESM_ATD.2 Association of attributes with objects Identification of the object and the attribute ESM_EAU.2 All use of the authentication mechanism None FAU_SEL.1 All modifications to audit configuration None FAU_SEL_EXT.1 All modifications to audit configuration None FAU_STG_EXT.1 Establishment and disestablishment of communications with audit server Identification of audit server FAU_STG.1 Archiving of audit trail (audit- log file) to audit backup trail. Deletion of audit backup trail with the identity of the administrator performing the operation. FCO_NRR.2 The invocation of the non-repudiation service Identification of the information, the destination, and a copy of the evidence provided Axway Security Target Page 32 of 70 FCS_HTTPS_EXT.1 Failure to establish a session, establishment/termination of a session Non-TOE endpoint of connection (IP address), reason for failure (if applicable) FCS_TLS_EXT.1 Failure to establish a session, establishment/termination of a session Non-TOE endpoint of connection (IP address), reason for failure (if applicable) FDP_ACC.1 Any changes to the enforced policy or policies Identification of Policy Management product making the change FDP_ACF.1 All requests to perform an operation on an object covered by the SFP Subject identity, object identity, requested operation FIA_AFL.1 The reaching of an unsuccessful authentication attempt threshold, the actions taken when the threshold is reached, and any actions taken to restore the normal state. Action taken when threshold is reached FIA_SOS.1 Rejection or acceptance by the TSF of any tested secret None FIA_SOS.1 Identification of any changes to the defined quality metrics The change made to the quality metric FIA_USB.1 Successful and unsuccessful binding of user attributes to a subject None FMT_MOF.1 (1) All modifications to TSF behavior None FMT_MOF.1 (2) All modifications to TSF behavior None FMT_SMF.1 Use of the management functions Management function performed FMT_SMR.1 Modifications to the members of the management roles None FPT_FLS_EXT.1 Failure of communication between the TOE and Policy Management product Identity of the Policy Management product, reason for the failure FPT_RPL.1 Detection of replay Action to be taken based on the specific actions FTP_ITC.1 All use of trusted channel functions Identity of the initiator and target of the trusted channel Component Event Additional Information FTP_TRP.1 All attempted uses of the trusted path functions Identification of user associated with all trusted path functions, if available 5.3.2.2 FAU_SEL.1 Selective Audit (Access Control PP) Hierarchical to: No other components. FAU_SEL.1.1 The TSF shall be able to select the set of events to be audited from the set of all auditable events based on the following attributes: a. [event type]; and b. [date and time]. Axway Security Target Page 33 of 70 Dependencies: FAU_GEN.1 Audit Data Generation FMT_MTD.1 Management of TSF Data 5.3.2.3 FAU_SEL_EXT.1 External audit trail storage (Policy Manager PP) Hierarchical to: No other components. FAU_SEL_EXT.1.1 The TSF shall be able to select the set of events to be audited by an [an ESM Access Control product] from the set of all auditable events based on the following attributes: a) event type; and 5) date and time. Dependencies: FAU_GEN.1 Audit data generation FMT_MTD.1 Management of TSF data Application Note: The ESM Access Control product in the SFR refers to API Gateway component. 5.3.2.4 FAU_STG.1 Protected Audit Trail Storage (Local Storage) Hierarchical to: No other components. FAU_STG.1.1 The TSF shall protect stored audit records in the audit trail from unauthorized deletion. FAU_STG.1.2 The TSF shall be able to [prevent] unauthorized modifications to the stored audit records in the audit trail. Dependencies: FAU_GEN.1 Audit data generation 5.3.2.5 FAU_STG_EXT.1 External audit trail storage Hierarchical to: No other components FAU_STG_EXT.1.1 The TSF shall be able to transmit the generated audit data to a HTTP-based audit server and TOE-internal storage. FAU_STG_EXT.1.2 The TSF shall ensure that transmission of generated audit data to any external IT entity uses a trusted channel defined in FTP_ITC.1. FAU_STG_EXT.1.3 The TSF shall ensure that any TOE-internal storage of generated audit data: a) protects the stored audit records in the TOE-internal audit trail from unauthorized deletion; and b)prevents unauthorized modifications to the stored audit records in the TOE-internal audit trail. Dependencies: FAU_GEN.1 Audit data generation FTP_ITC.1 Inter-TSF Trusted Channel. 5.3.2.6 FAU_SAR.1 Audit Review Hierarchical to: No other components FAU_SAR.1.1 The TSF shall provide administrators with the capability to read information from the audit records.. FAU_SAR.1.2 The TSF shall provide the audit records in a manner suitable for the user to interpret the information. Dependencies: FAU_GEN.1 Audit data generation. Axway Security Target Page 34 of 70 5.3.2.7 FAU_SAR.3 Selectable Audit review Hierarchical to: No other components FAU_SAR.3.1 The TSF shall provide the ability to apply [ordering or selection] of audit data based on [event type , date and time].. Dependencies: FAU_SAR.1.Audit review. 5.3.4 Class: Communication (FCO) FCO_NRR.2 Enforced proof of receipt 5.3.4.1 Hierarchical to: FCO_NRR.1 Selective proof of receipt FCO_NRR.2.1 The TSF shall enforce the generation of evidence of receipt for received [policies] at all times. FCO_NRR.2.2 The TSF shall be able to relate the [stored authentication credentials] of the recipient of the information, and the [policy ID] of the information to which the evidence applies. FCO_NRR.2.3 The TSF shall provide a capability to verify the evidence of receipt of information to [originator] given [within 30 seconds]. Dependencies: FIA_UID.1 Timing of identification 5.3.5 Class: Cryptographic Support (FCS) FCS_HTTPS_EXT.1 HTTPS 5.3.5.1 Hierarchical to: No other components. FCS_HTTPS_EXT.1.1 The TSF shall implement the HTTPS protocol that complies with RFC 2818. FCS_HTTPS_EXT.1.2 The TSF shall implement HTTPS using TLS as specified in FCS_TLS_EXT.1. Dependencies: FCS_TLS_EXT.1 TLS FCS_TLS_EXT.1 TLS 5.3.5.2 Hierarchical to: No other components. FCS_TLS_EXT.1.1 The TSF shall implement one or more of the following protocols [TLS 1.2 (RFC 5246) TLS 1.3 (RFC8446)] supporting the following ciphersuites: for TLS 1.2 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 4096) TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 4096) TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 4096) TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 4096) TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) Axway Security Target Page 35 of 70 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) For TLS 1.3 TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256 Dependencies: FCS_COP.1 Cryptographic key generation (FCS_CKM.1) 5.3.5.3 FCS_CKM.1.1 The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm [ ● SSH-2: generation of encryption keys and MAC keys ● TLS v1.2 and TLS v1.3: generation of encryption keys and MAC keys ● XML encryption: generation of ephemeral keys ] and specified cryptographic key sizes [ ● SSH-2: ❍ AES keys: 128, 192, and 256 bits ● TLSv1.2 and TLS 1.3: ❍ AES keys: 128 and 256 bits ❍ HMAC keys: 256 bits ● XML encryption: ❍ AES keys: 128, 192 and 256 bits ❍ ] that meet the following: [ ● SSH-2: conformant to [RFC4253]☝ ● TLS v1.2: conformant to [RFC5246]☝ ● TLS v1.3 conformant to [RFC8446] ● XML encryption: conformant to [W3CXMLENC]☝ ]. Cryptographic key distribution (FCS_CKM.2) 5.3.5.4 FCS_CKM.2.1 The TSF shall distribute cryptographic keys in accordance with a specified cryptographic key distribution method [ ● SSH-2: ❍ Diffie-Hellman key agreement method (diffie-hellman-group- exchange-sha1, diffie-hellman-group14-sha1, diffie-hellman-group1-sha1) Axway Security Target Page 36 of 70 ● TLS v1.2 and TLS v1.3: ❍ Key exchange using RSAES-PKCS1-v1_5 ● XML encryption: ❍ key transport using RSAES-PKCS1-v1_5 and RSAES-OAEP ❍ symmetric key wrap using AES ] that meets the following: [ ● SSH-2: conformant to [RFC4253]☝ ● TLSv1.2: conformant to [RFC5246]☝ ● ● TLS v1.3 conformant to [RFC8446] ● XML encryption: conformant to [W3CXMLENC]☝ ]. Application Note: This SFR covers the key establishment in the TLS and SSH protocols, and key transport for XML encryption. Cryptographic operation (FCS_COP.1(ENC)) 5.3.5.5 FCS_COP.1.1 The TSF shall perform [ encryption and decryption ] in accordance with a specified cryptographic algorithm [ ● SSH-2: ● ❍ TLS v1.2 and TLS v1.3 ❍ RSA Encryption Scheme with PKCS#1 v1.5 (RSAES-PKCS1-v1_5) ❍AES (CBC and CTR modes) with key sizes 128, 192, and 256 bits) ● XML encryption: ❍ RSA Encryption Scheme with OAEP (RSAES-OAEP) ❍ RSA Encryption Scheme with PKCS#1 v1.5 (RSAES-PKCS1-v1_5) ❍ AES (CBC mode) ❍ ] and cryptographic key sizes [ ● SSH-2: AES (CBC and CTR modes) with key sizes 128, 192, and 256 bits ● TLSv1.2 and TLS v1.3: ❍ RSAES-PKCS1-v1_5: 1024, 2048, and 4096 bits ● XML encryption: ❍ RSAES-OAEP and RSAES-PKCS1-v1_5: 1024, 2048, and 4096 bits ❍ AES: 128, 192 and 256 bits ❍ ] that meet the following: [ ● SSH-2: conformant to [RFC4253]☝ and [RFC4344]☝ ● TLS v1.2: conformant to [RFC5246]☝ ● TLS v1.3 conformant to [RFC8446] ● XML encryption: conformant to [W3CXMLENC]☝ ● RSAES-OAEP and RSAES-PKCS1-v1_5: conformant to [RFC3447]☝ Axway Security Target Page 37 of 70 ● AES: algorithm processing conformant to [FIPS197]☝, conformant to [SP800-38A]☝ (CBC and CTR modes) Cryptographic operation (FCS_COP.1(MAC)) 5.3.5.6 FCS_COP.1.1 The TSF shall perform [ message authentication code generation ] in accordance with a specified cryptographic algorithm [ ● SSH-2: ❍hmac-sha2-256 hmac-sha2-512 ● TLSv1.2 and TLS v1.3: ❍ HMAC-SHA-256 ● XML signature: ❍ HMAC-SHA-256 ] and cryptographic key sizes [ 256 bits ] that meet the following: [ ● SSH-2: conformant to [RFC4253]☝ ● TLS v1.2: conformant to [RFC5246]☝ ● TLS v1.3 conformant to [RFC8446] ● XML signature: conformant to [W3CXMLSIG]☝ ● HMAC: conformant to [RFC2104]☝ ● SHA-256: conformant to [FIPS180-4]☝ ]. Application Note: This SFR covers message integrity for the TLS, SSH and XML signature protocols. Cryptographic operation (FCS_COP.1(MD)) 5.3.5.7 FCS_COP.1.1 The TSF shall perform [ message digest generation ] in accordance with a specified cryptographic algorithm [ ● SSH-2: ❍ SHA-256 ● TLSv1.2 and TLS v1.3: ❍ SHA-256 ● XML signature: ❍ ❍ SHA-256 ❍ SHA-384 ❍ SHA-512 ● XML encryption: ❍ ❍ SHA-256 ❍ SHA-384 ❍ SHA-512 ] and cryptographic key sizes [ none ] that meet the following: [ Axway Security Target Page 38 of 70 ● SSH-2: conformant to [RFC4253]☝ ● TLSv1.2: conformant to [RFC5246]☝ ● TLS v1.3 conformant to [RFC8446] ● XML signature: conformant to [W3CXMLSIG]☝ ● XML encryption: conformant to [W3CXMLENC]☝ ● SHA-256, SHA-384, SHA-512: conformant to [FIPS180-4]☝ ]. Cryptographic operation (FCS_COP.1(SGN)) 5.3.5.8 FCS_COP.1.1 The TSF shall perform [ digital signature generation and verification ] in accordance with a specified cryptographic algorithm [ ● SSH-2: ❍ ❍ RSA Signature Scheme with Appendix PKCS#1 v1.5 (RSASSA-PKCS1-v1_5) with SHA256 ● TLSv1.2 and TLS v1.3: ❍ RSASSA-PKCS1-v1_5 with SHA-256 ● XML signature: ❍ DSA with SHA-1 ❍ RSASSA-PKCS1-v1_5 with,SHA-256,SHA-384andSHA-512 ] and cryptographic key sizes [ ● SSH-2: ❍RSASSA-PKCS1-v1_5: 1024, 2048, and 4096 bits ● TLSv1.2 and TLS v1.3: ❍ RSASSA-PKCS1-v1_5: 1024, 2048, and 4096 bits ● XML signature: ❍❍RSASSA-PKCS1-v1_5: 1024, 2048, and 4096 bits ] that meet the following: [ ● SSH-2: conformant to [RFC4253]☝ ● TLSv1.2: conformant to [RFC5246]☝ ● TLS v1.3 conformant to [RFC8446] ● XML signature: conformant to [W3CXMLSIG]☝ ● RSASSA-PKCS1-v1_5: conformant to [RFC3447]☝ ● SHA-256, SHA-384, SHA-512: conformant to [FIPS180-4]☝ ]. 5.3.6 Class: User Data Protection (FDP) Access Control Policy (Web Based Access Control) (FDP_ACC.1) 5.3.6.1 Hierarchical to: No other components. FDP_ACC.1.1 The TSF shall enforce the [access control Security Function Policy (SFP)] on [ • Subjects: API and Web Service clients; and Axway Security Target Page 39 of 70 • Objects: APIs, Web Services, data stores, and • Operations: all permitted operations on the API/Web Service. Dependencies: FDP_ACF.1 Security Attribute Based Access Control Access Control Functions (Web Based Access Control) (FDP_ACF.1) 5.3.6.2 Hierarchical to: No other components. FDP_ACF.1.1 The TSF shall enforce the [access control SFP] to objects based on the following: [all operations between users and objects based upon the attributes defined in Table 19 below]. Table 19 FDP Requirement Table for Web-Based Access Control Subject Object Operation User URLs Access via HTTP operations Files Open | Download CGI Scripts Execute Enable | Disable Forms HTTP GET | HTTP POST FDP_ACF.1.2 The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: [rules received from an authorized and compatible Policy Management product]. FDP_ACF.1.3 The TSF shall explicitly authorize access of subjects to objects based on the following additional rules: [no additional rules]. FDP_ACF.1.4 The TSF shall explicitly deny access of subjects to objects based on the following additional rules: [no additional rules]. Dependencies: FDP_ACC.1 Subset Access Control FMT_MSA.3 Static Attribute Initialization Subset information flow control (FDP_IFC.1) 5.3.6.3 FDP_IFC.1.1 The TSF shall enforce the [ Information Flow Control Policy ] on [ a) Subjects: requesting application b) Information: ● messages transported by the protocols shown in the first table below and with payload formats shown in the second table below 2; c) Operations: request, response Message Format Reference JSON RFC4627 XML W3CXML SOAP W3CSOAP Protocol Mode Conformance HTTP server and client (listens for RFC2616 with HTTP Basic Authentication Axway Security Target Page 40 of 70 requests and forwards) HTTPS server and client (listens for requests and forwards) RFC2818 with HTTP Basic Authentication FTP server and client (server listens for requests, client polls) RFC0959 and the following FTP commands can be disabled -> REIN, APPE, ALLO, ABOR, SYST, HELP, NOOP. FTP Over SSL server and client (server listens for requests, client polls) RFC0959 and RFC4217 and the following FTP commands can be disabled: REIN, APPE, ALLO, ABOR, SYST, HELP, NOOP. SFTP server and client (server listens for requests, client polls) SFTP with no restrictions Dependencies: FDP_IFF.1 Simple Security Attribute Simple security attributes (FDP_IFF.1 ) 5.3.6.4 FDP_IFF.1.1 The TSF shall enforce the [ Information Flow Control Policy ] based on the following types of subject and information security attributes: [ a) Subject security attributes: ● requesting application b) Information security attributes: ● IP source address ● IP destination address ● TCP port ● request URL ● XML Schema Definition according to [W3CXSD]☝ ● XML signature according to [W3CXMLSIG]☝ ● Identity assertions: ❍ FTP username and password conformant to [RFC0959]☝, ❍ SFTP username/password and public key conformant to [SFTP]☝ and [RFC4252]☝, ❍ credentials from HTTP Basic Authentication header conformant to [RFC2617]☝, ❍ LTPA token from HTTP cookie conformant to [LTPA]☝, ❍ SSL client certificate conformant to [RFC5280]☝ and [RFC5246]☝, ❍ The following WS-Security tokens: ➤ Username Token conformant to [OASIS-WSS]☝ ➤ X.509 Certificate Token conformant to [OASIS-WSS]☝ ➤ SAML v2.0 Token conformant to [OASIS-SAML20]☝ ● message content with format according to Table 12 ● size of message Axway Security Target Page 41 of 70 ]. FDP_IFF.1.2 The TSF shall permit an information flow between a controlled subject and another controlled information subject via a controlled operation if the following rules hold: [ a) Subjects on an internal network can cause information to flow through the TOE to another connected network if: ● all the information security attribute values are permitted by the information flow security policy rules, where such rules may be composed from all possible combinations of the values of information flow security attributes, created by authorized administrators according to the Domain Access Control Policy; ● the presumed address of the source subject, in the information, translates to an internal network address; and ● the presumed address of the destination subject, in the information, translates to an address on the other connected network. b) Subjects on the external network can cause information to flow through the TOE to another connected network if: ● all the information security attribute values are permitted by the information flow security policy rules, where such rules may be composed from all possible combinations of the values of the information flow security attributes, created by authorized administrators according to the Domain Access Control Policy; ● the presumed address of the source subject, in the information, translates to an external network address; and ● the presumed address of the destination subject, in the information, translates to an address on the other connected network ]. FDP_IFF.1.3 The TSF shall enforce the [ no additional information flow control SFP rules ]. FDP_IFF.4 The TSF shall explicitly authorise an information flow based on the following rules: [ a) The TOE shall accept requests if the IP source address matches the list of allowed IP addresses. ]. FDP_IFF.5 The TSF shall explicitly deny an information flow based on the following rules: [ a) The TOE shall reject requests for access or services where the information arrives on an external TOE interface, and the presumed address of the source subject is an external IT entity on an internal network. b) The TOE shall reject requests for access or services where the information arrives on an internal TOE interface, and the presumed address of the source subject is an external IT entity on the external network. Axway Security Target Page 42 of 70 c) The TOE shall reject requests for access or services where the information arrives on either an internal or external TOE interface, and the presumed address of the source subject is an external IT entity on a broadcast network. d) The TOE shall reject requests for access or services where the information arrives on either an internal or external TOE interface, and the presumed address of the source subject is an external IT entity on the loopback network. e) The TOE shall reject requests if the IP source address matches the list of denied IP addresses. f) For application protocols supported by the TOE according to Table 11, the TOE shall deny any access or service requests that do not conform to its associated published protocol specification or when authentication using the extracted identity assertion fails. This shall be accomplished through protocol filtering proxies that are designed for that purpose. g) The TOE shall reject malformed JSON messages that do not conform to [RFC4627]☝. h) The TOE shall reject malformed SOAP messages that do not conform to [W3CSOAP]☝. i) The TOE shall reject malformed XML messages (wellformedness as well as schema validation). j) The TOE shall reject messages with malicious XML (node size, element depth, attribute count, external reference handling). k) The TOE shall reject messages with invalid XML signatures according to [W3CXMLSIG]☝, [W3CXMLC14N]☝ and [W3CXMLEXCC14N]☝. l) The TOE shall reject messages received at a rate over an administrator-defined threshold (indicating DOS). m) The TOE shall reject oversized messages. Dependencies: FDP_IFC.1 Subset information flow control FMT_MSA.3 Static Attribute Initialization 5.3.7 Class: Identification and Authentication (FIA) 5.3.6.1 FIA_AFL.1 Authentication Failure Handling Hierarchical to: No other components Dependencies : FIA_UAU.1 Timing of authentication FIA_AFL.1.1 The TSF shall detect when [6] unsuccessful authentication attempts occur related to [login to Policy Studio and API Gateway Manager]. Axway Security Target Page 43 of 70 FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts has been [surpassed], the TSF shall [lock user account for 30 minutes]. 5.3.6.2 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 following: 5) For environmental password-based authentication, the following rules apply: 5. Passwords shall be able to be composed of a subset of the following character sets: [printable ASCII character set] that include the following values [All printable ASCII characters, including 26 uppercase letters, 26 lowercase letters, 10 numbers, and 32 special characters “~”, “!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(“, “)”, “- “, “_”, “=”, “+”, “\”, “|”, “[“, “{“, “}”, “]”, “;”, “:”, “’”, “””, “,”, “<”, “.”, “>”, “/”, “?”]; and 2. Minimum password length shall settable by an administrator, and support passwords of 16 characters or greater; and 3. Password composition rules specifying the types and numbers of required characters that comprise the password shall be settable by an administrator; and 4. Passwords shall have a maximum lifetime, configurable by an administrator; and 5. New passwords shall contain a minimum of an administrator-specified number of character changes from the previous password; and 6. Passwords shall not be reused within the last administrator-settable number of passwords used by that user; 5) For non-password-based authentication, the following rules apply: The probability that a secret can be obtained by an attacker during the lifetime of the secret is less than 2-20. Dependencies: No dependencies. 5.3.6.3 FIA_USB.1 User-Subject Binding Hierarchical to: No other components. Axway Security Target Page 44 of 70 FIA_USB.1.1 The TSF shall associate the following user security attributes with subjects acting on the behalf of that user: [username,groups, roles]. FIA_USB.1.2 The TSF shall enforce the following rules on the initial association of user security attributes with subjects acting on the behalf of users: [Username in the credentials is looked up against an internal file to determine the roles that have been assigned to that user.]. FIA_USB.1.3 The TSF shall enforce the following rules governing changes to the user security attributes associated with subjects acting on the behalf of users: [Rules take effect immediately]. Dependencies: FIA_ATD.1 User Attribute Definition 5.3.8 Class: Security Management (FMT) 5.3.7.1 FMT_MOF.1 (1) Management of Functions Behavior (Access Control PP) Hierarchical to: No other components. FMT_MOF.1.1 (1) The TSF shall restrict the ability to [determine the behavior of, modify the behavior of] the functions[: audited events, repository for trusted audit storage, access control SFP, policy being implemented by the TSF, access control SFP behavior to enforce in the event of communications outage, [assignment: No other functions]] to [an authorized and compatible Policy Management product]. Dependencies: FMT_SMF.1 Specification of Management Functions FMT_SMR.1 Security Roles 5.3.7.2 FMT_MOF.1 (2) Management of Functions Behavior (Policy Manager PP) FMT_MOF.1.1 (2) The TSF shall restrict the ability to [determine the behavior of] the functions: [manage admin users, view real-time traffic data, view logs] to [an authorized and compatible Enterprise Security Management product]. Dependencies: FMT_SMF.1 Specification of Management Functions FMT_SMR.1 Security Roles 5.3.7.3 FMT_MOF_EXT.1 External Management of Functions Behavior Hierarchical to: No other components. FMT_MOF_EXT.1.1 The TSF shall restrict the ability to query the behavior of, modify the functions of Access Control products: audited events, repository for audit storage, Access Control SFP, policy version being implemented, Access Control SFP behavior to enforce in the event of communications outage, [query the behavior of, modify the functions of the API Gateway Access Control product: audited events, repository for audit storage, Access Control SFP, policy version being implemented, addition of users and assigning roles to those users] to [Policy Developer can download, edit, deploy, version, and tag a configuration; an API Gateway administrator has read/write access to API Gateway Axway Security Target Page 45 of 70 Manager; an API Gateway Operator has read-only access to the API Gateway Manager]. Dependencies: FMT_SMF.1 Specification of Management Functions FMT_SMR.1 Security Roles 5.3.7.4 FMT_MSA.1 Management of Security Hierarchical to: No other components. FMT_MSA.1.1 The TSF shall enforce the [access control SFP] to restrict the ability to [change_default, query, modify, delete, [no other operations]] the security attributes [access control policies, access control policy attributes, implementation status of access control policies] to [an authorized and compatible Policy Management product]. Dependencies: FDP_ACC.1 Subset Access Control FMT_SMF.1 Specification of Management Functions FMT_SMR.1 Security Roles 5.3.7.5 FMT_MSA.3 Static Attribute Initialization Hierarchical to: No other components. FMT_MSA.3.1 The TSF shall enforce the [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 and compatible Policy Management product] 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 5.3.7.6 FMT_MSA_EXT.5 Consistent Security Attributes Hierarchical to: No other components. FMT_MSA_EXT.5.1 The TSF shall [identify the following internal inconsistencies within a policy prior to distribution: [circular dependencies, policies with no “Start” filter]. FMT_MSA_EXT.5.2 The TSF shall take the following action when an inconsistency is detected: [issue a prompt for an administrator to manually resolve the inconsistency, block a policy package deployment until the issue has been resolved.]]. Dependencies: FMT_MOF_EXT.1 External Management of Functions Behavior 5.3.7.7 FMT_SMF.1 Specification of Management Functions Hierarchical to: No other components. FMT_SMF.1 The TSF shall be capable of performing the following management functions: configuration of audited events, Axway Security Target Page 46 of 70 configuration of repository for trusted audit storage, configuration of Access Control SFP, querying of policy being implemented by the TSF, management of Access Control SFP behavior to enforce in the event of communications outage, manage users, manage the cryptographic materials. Dependencies: No dependencies. 5.3.7.8 FMT_SMR.1 Security Roles Hierarchical to: No other components. FMT_SMR.1.1 The TSF shall maintain the roles [Policy Developer, API Gateway Administrator, and API Gateway Operator , Gateway Manager Deployer]. FMT_SMR.1.2 The TSF shall be able to associate users with roles. Dependencies: FIA_UID.1 Timing of Identification 5.3.7.9FMT_MTD.1 Management of TSF Data Hierarchical to: No other components. FMT_MTD.1.1 The TSF shall restrict the ability to change_default, query, modify, delete, clear, the cryptographic keys, digital certificates, certification revocation list (CRL) to API Gateway Administrator. Dependencies: FMT_SMR.1 Security Roles FMT_SMF.1 Specification of Management function 5.3.9 Class: Protection of the TSF (FPT) FPT_APW_EXT.1 Protection of Stored Credentials 5.3.9.1 Hierarchical to: No other components. FPT_APW_EXT.1.1 The TSF shall store credentials in non-plaintext form. FPT_APW_EXT.1.2 The TSF shall prevent the reading of plaintext credentials. Dependencies: No dependencies. FPT_FLS_EXT.1 Failure of Communication 5.3.9.2 Hierarchical to: No other components. FPT_FLS_EXT.1.1 The TSF shall maintain policy enforcement in the following manner when the communication between the TSF and the Policy Management product encounters a failure state: [enforce the last policy received, [failure policy]]. Dependencies: No dependencies 5.3.8.3 FPT_RPL.1 Replay Detection Hierarchical to: No other components. Axway Security Target Page 47 of 70 FPT_RPL.1.1 The TSF shall detect replay for the following entities: [TSF data]. FPT_RPL.1.2 The TSF shall perform [reject the data] when replay is detected. Dependencies: No dependencies. 5.3.8.4 FPT_SKP_EXT.1 Protection of Secret Key Parameters Hierarchical to: No other components. FPT_SKP_EXT.1.1 The TSF shall prevent reading of all pre-shared keys, symmetric keys, and private keys. 5.3.8.5 FPT_TDC.1 Hierarchical to: No other components. FPT_TDC.1.1 The TSF shall provide the capability to consistently interpret public keys, digital certificates, certificate revocation list when shared between the TSF and another trusted IT product. FPT_TDC.1.2 The TSF shall use openssh-pubkey format as defined in [RFC4716], standard X.509 as defined in [RFC5280] when interpreting the TSF data from another trusted IT product. Dependencies: No dependencies. 5.3.10 Class Resource Utilization (FRU) 5.3.9.1 FRU_FLT.1 Degraded Fault Tolerance Hierarchical to: No other components. FRU_FLT.1.1 The TSF shall ensure the operation of [enforcing the most recent policy] when the following failures occur: [restoration of communications with the Policy Management product after an outage]. Dependencies: FPT_FLS.1 Failure with Preservation of Secure State 5.3.11 Class TOE Access (FTA) 5.3.10.1 FTA_SSL.3 TSF-initiated Termination Hierarchical to: No other components. FTA_SSL.3.1 Refinement: The TSF shall terminate a remote interactive session after an [Authorized Administrator-configurable time interval of session inactivity]. Dependencies: No dependencies. 5.3.10.2 FTA_SSL.4 User-initiated Termination Hierarchical to: No other components. FTA_SSL.4.1 Refinement: The TSF shall allow Administrator-initiated termination of the Administrator’s own interactive session. Dependencies: No dependencies. Axway Security Target Page 48 of 70 5.3.10.3 FTA_TAB.1 TOE Access Banner Hierarchical to: No other components. FTA_TAB.1.1 Refinement: Before establishing a user session, the TSF shall display a configurable advisory warning message regarding unauthorized use of the TOE. Dependencies: No dependencies 5.3.12 Class Trusted Paths/Channels (FTP) 5.3.11.1 FTP_ITC.1 Inter-TSF Trusted Channel Hierarchical to: No other components. FTP_ITC.1.1 Refinement: The TSF shall use [TLS/HTTPS] to provide a trusted communication channel between itself and authorized IT entities that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from modification and disclosure. FTP_ITC.1.2 The TSF shall permit [the TSF] to initiate communication via the trusted channel. FTP_ITC.1.3 Refinement: The TSF shall initiate communication via the trusted channel for transfer of policy data, [Policy Studio initiates communication via the trusted channel for the transfer of policy data. API Gateway Manager initiates communication via a trusted channel to manage users, view audit/domain logs, view system performance metrics, and manage server instances (i.e. start/stop/etc)]. Dependencies: No dependencies. 5.3.11.2 FTP_TRP.1 Trusted Path Hierarchical to: No other components. FTP_TRP.1.1 Refinement: The TSF shall use [TLS/HTTPS] to provide a trusted communication path between itself and [remote] users that is logically distinct from other communication channels and provides assured identification of its end points and protection of the communicated data from [modification, disclosure]. FTP_TRP.1.2 The TSF shall permit [remote users] to initiate communication via the trusted path. FTP_TRP.1.3 Refinement: The TSF shall require the use of the trusted path for initial user authentication, execution of management functions. Dependencies No dependencies 5.4 Assurance Requirements Assurance requirements correspond to the EAL4 level augmented by ALC_FLR3 and AVA_VAN.4. Axway Security Target Page 49 of 70 Table 20: Assurance Requirements Assurance Class Components Description Development ADV_FSP.4 Complete Functional Specification ADV_ARC.1 Securiy Architecture definition ADV_IMP.1 Implementation ADV_TDS.3 Basic modular design Guidance Documents AGD_OPE.1 Operational User Guidance AGD_PRE.1 Preparative User Guidance Tests ATE_IND.2 Independent Testing - Sample ATE_COV.2 Analysis of coverage ATE_DPT.1 Testing: basic design ATE_FUN.1 Functional testing Vulnerability Assessment AVA_VAN.4 Focused vulnerability analysis Life Cycle Support ALC_CMC.1 Labelling of the TOE ALC_CMS.1 TOE CM Coverage ALC_DEL.1 Delivery procedures ALC_DVS.1 Identification of security measures ALC_LCD.1 Developper defined life-cycle model ALC_TAT.1 ALC_FLR.3 Systematic flaw remediation Axway Security Target Page 50 of 70 6 TOE Summary Specification 6.1 Access Control Policy Definition Related SFRs: ESM_ACD.1, ESM_ATD.1, ESM_ATD.2, ESM_ACT.1, FMT_MSA.1, FMT_MSA.3, FMT_MSA_EXT.5, FMT_SMF.1 , FMT_MTD.1, FMT,SMR.1, FPT_TDC.1 This security function refers to the access control policy definition capabilities of the API Gateway. Policy Studio and API Gateway Manager are the Policy Management tools that are used to configure and define access control policies for Axway API Gateway, which is the compatible Access Control product. A summary of the policy definition capability is provided below, however an entire manual – Axway API Gateway Policy Developer’s Guide – is dedicated to this topic and should be referenced for detailed information. A policy defines restrictions for the consumption of a published Gateway-protected service. Policies are identified using a Policy Name and Policy ID. At the highest layer of abstraction, the attributes used in policy definition are as defined in ESM_ACD.1. Details for included policy filters are provided in sections 6.1.1, 6.1.2 and 6.1.3 below. Policies are transmitted to the API Gateway immediately after they are created or when a service client is newly registered with the API Gateway. In Policy Studio, a service policy includes message filters that determine the authentication method, identity credentials, transport method, and routing method for the protected API or web service. The specific types of filters, their relative location, and the other filters determine the properties and validity of a policy. During processing, the Gateway executes each message filter sequentially according to its position in the policy, assigning a 'success', 'failure', or ‘abort’ outcome to each. API Gateway Manager is a web-based interface for configuring global password policy, administrator users and their corresponding roles, audit events, audit offload and other global configuration. Furthermore, it can be used to provide a real-time, graphical view of API Gateway transactions. It can also be used to view various audit logs and trace files in order to diagnose run-time problems. 6.1.1 Access Control The following subsets of filters are evaluated: a. HTTP Basic Authentication. The API Gateway authenticates clients using HTTP basic authentication against an LDAP directory. This filter is used in conjunction with a HTTPS Interface to ensure that the client username and password are always passed over a TLS 1.3 encrypted channel. Direct authentication is supported, where the client submits the “Authorization” header on the first request. Furthermore, a challenge-response mechanism is supported, where the client does not submit the “Authorization” header in the first request, which forces the API Gateway to return a “challenge” to the client in the form of a HTTP 401 response code. The client must then submit the “Authorization” header on the subsequent request. Retries are supported in cases where the user enters incorrect (or no) credentials in the browser. The browser allows the user to “retry” their credentials for a number of times, which is configurable in the browser. If the user supplies invalid credentials more than 6 times in a 5 minutes time period, the user will be locked out for 30 minutes. The format of the credentials can be configured to be one of the following, depending on what is configured in the LDAP directory: Axway Security Target Page 51 of 70 i) Username: applicable ii) X.509 Distinguished Name: Not applicable There is an option to remove the “Authorization” header in a post processing step, but is not relevant to access control decisions. For more information on the HTTP Basic Authentication filter, please refer to the HTTP basic authentication section of the Policy Developer Guide. b. HTML Form-based Authentication. User credentials are passed to the API Gateway in a HTML form and authenticated using HTML form-based authentication against an LDAP directory. The filter is used along with a HTTPS Interface that enforces the use of TLS 1.3 to secure the client credentials. It is possible to configure the form fields used to contain the username and password. The format of the credentials can be configured to be one of the following, depending on what is configured in the LDAP directory: i) Username: applicable ii) X.509 Distinguished Name: Not applicable As with HTTP Basic authentication, if the user submits an incorrect username and/or password more than 6 times in a 5 minutes interval, that user will be locked out for 30 minutes. With form-based authentication, the following attributes are validated on the user’s session: Session Expiry: By default the session expires after 60 seconds. Secure Flag: The filter can be configured to restrict the use of the session to secure channels only. HTTP Only: Sets the HttpOnly attribute on the cookie to restrict access to the cookie from client-side script. In order for the session expiry flag to work, the Session Check filter must be included in the policy. The Secure Flag check also has a dependency on the Compare Attributes Filter c. HTTP Header Authentication: This filter is used in cases where the API Gateway receives end-user authentication credentials in an HTTP header. When the API Gateway receives the message, it authenticates the sender of the message and extracts the end-user identity from the token in the HTTP header for use in subsequent authorization filters. This filter has the following configurable fields: Name: appropriate name of the filter HTTP Header Name: The name of the Http header that contains the end-user credentials. HTTP Header type: the type of credentials that are passed in the named HTTP header. The following are supported: X.509 Distinguished name; certificate; username. Axway Security Target Page 52 of 70 d. Mutual TLS 1.2 and 1.3 Authentication. A HTTPS Interface is configured to require clients to present their certificates during the TLS 1.2 or TLS 1.3 handshake. The CA cert that issued the client certificate must be explicitly trusted by the HTTPS Interface. The HTTPS Interface is configured to require client certificates and to trust a certificate chain on the client certificate of up to 2 certificates.The HTTPS Interface by default uses a cipher string to ensure strong tls encryption and disable known weak protocols. A check is performed to ensure that the server SSL certificate’s Common Name resolves to a network address. SSL Server Name Identifier (SNI) is not applicable for the evaluated configuration. e. LDAP Attribute Authorization. This filter enables authorization of an authenticated client for a backend service based on user roles stored in an LDAP directory. User attributes are read from the selected LDAP directory, and compared against some known values. The filter can be configured to succeed if only 1 comparison succeeds or if all comparisons succeed. There are various types of matching rules that can be used in the comparison: i) Applicable: contains, doesn’t contain, is and is not ii) Not Applicable: matches regular expression, doesn’t match regular expression, ends with, is, is not, starts with The advanced settings on this filter include the ability to cache retrieved attributes for use by successive filters and how to process multi-valued attributes. However these settings are not relevant to the access control decision that the filter enforces. f. SAML Authentication. The API Gateway extracts a SAML 2.0 authentication assertion from a WS-Security block in the SOAP Header. Once the assertion has been extracted, the following validation is performed: i) Ensure that the assertion is using the SAML 2.0 namespace. ii) Check the Created and Expires assertions to ensure that the assertion is still valid, taking into account the configured drift time to allow for discrepancies between the machine on which the assertion was generated and the Gateway’s machine. iii) Make sure that the Issuer of the assertion matches one of the Trusted Issuers configured in the filter. For more information on this filter, please refer to the SAML Authentication section of the Policy Developer Guide. g. XML filters i) XML Schema Validation ii) XML Signature Generation iii) XML Encryption Settings Axway Security Target Page 53 of 70 iv) XML Encryption v) XML Decryption Settings vi) XML Decryption h. XML Signature Verification. XML Signature Verification is used to verify the integrity of an XML Signature embedded within a WS-Security block with a specified SOAP actor/role. The following types of XML Signatures are supported: • Asymmetric • Symmetric • Enveloped • Enveloping The public key to use to validate the signature can be extracted from the KeyInfo section of the XML Signature using one of the following key referencing mechanisms: i) Not applicable: Public key is embedded in the message. ii) Not applicable: Public key included in a certificate that is contained within an attachment iii) Applicable: Security Token Reference For the purposes of this evaluation, the key will be referenced using one of the following applicable Security Token Reference methods: i) Applicable: X509v3, EncryptedKey, EncryptedKeySHA1, Issuer DName and Serial Number, ThumbprintSHA1, X509SubjectKeyIndentifier ii) Not Applicable: GSS_Kerberosv5_AP_REQ, GSS_Kerberosv5APREQSHA1, Key Identifier with x509v3, PKCS7, SAMLAssertionID, SAMLID, SecurityContextToken, X509PKIPathv1, X509v1 The nodes that must be signed by the XML Signature can be configured using the pre-configured Node Locations options (e.g. SOAP 1.2 Body). The XML Signature must be signed with algorithms that comply with the WSSecurityPolicy AlgorithmSuite of Basic256. The filter will block messages that do not contain an XML Signature. For more information on this filter, please refer to the XML Signature Verification section of the Policy Developer Guide. h. IP Address Authentication. The API Gateway restricts access based on the client’s IP address. Filtering can be done based on a specific IP address or on a range of IP addresses. Please refer to the IP Address Authentication section of the Policy Developer Guide for more information on this filter. Axway Security Target Page 54 of 70 i. Certificate Validity Filter: This filter performs a simple check on a certificate to ensure that the validitiy period of an X.509 certificate has not expired. By default this filter searches for the X.509 certificate in the certificate message attribute which must be set by a predecessor filter in the policy (SSL Authentication filter). Configuration fields for this filter includes the ‘Certificate Selector Expression’ field which specifies where to obtain the certificate (for example, form a message attribute). The filter checks the validity of the specified certificate. If no certificate is found, the filter returns an error. j. Log Message Payload: Logs the request and/or response message payload to the audit trail. k. SOAP Fault. The SOAP Fault filter is used to return a SOAP 1.1 or 1.2 Fault to the client when an error occurs. l. Certificate Attributes Authorization: This filter is used to authorize access to a web service based on the X.509 attributes of an authenticated client’s certificate. This filter checks the attribute values in the Dname of the client to which the certificate belongs and succeed only if all the attribute values are matched to configured attribute values. m. Time Filter. This filter enforces time-based access control to APIs and Web Services. The filter can be configured to either block or allow requests during a configurable time period. The time period is defined using one of the following options: • User-defined period using configurable “from” and “to” times • Days of the week • Cron Expression For more information on these configuration options, refer to the Allow or block messages at certain times section of the Policy Developer Guide. 6.1.2 Policy Logic Policies implicitly support logical OR and AND operations in the way that they are composited. A succession of filters placed on success paths must all succeed in order for the policy to pass, while a succession of filters placed on failure paths can test for multiple conditions (i.e. logical OR) so that if any of them succeed, a common success path can be followed. Please refer to the Policy Development Guide for explanations on the logic of sample policies. Policy Studio implicitly guards against building faulty logic in policies. A warning is displayed if a policy developer attempts to build a circular dependency in the policy invocation path. A warning is also displayed if a policy developer attempts to deploy a policy with no start filter. Axway Security Target Page 55 of 70 6.2 Access Control Policy Enforcement Related SFRs: FDP_ACC.1, FDP_ACF.1, FDP_IFC.1, FDP_IFF.1,FMT_MOF.1(1), FMT_MOF.1(2), FMT_MOF_EXT.1, FMT_MSA.1, FMT_MSA.3, FMT_MSA_EXT.5, FMT_SMF.1, FMT_SMR.1, FMT_MTD.1 ESM_EID.2 , FCS_CKM.1 FCS_CKM.2 FCS_COP.1(ENC) FCS_COP.1(MAC) FCS_COP.1(MD) FCS_COP.1(SGN) The Gateway enforces polices defined by the Policy Studio (see section 6.1 for policy types). In the evaluated configuration, the Gateway may only consume policies created and deployed from the Axway Policy Studio. The Gateway authenticates users logging in from Policy Studio using HTTP basic authentication over TLS (refer to section 6.7 for TLS details). Administrators logging in from the web-based API Gateway Manager are authenticated using Form-based authentication over TLS. The Gateway performs the following message processing for a typical policy: a) Service request arrives. b) Request is resolved to a specific policy based on the incoming path c) Request is run through the policy filters in order. Typically authentication filters are run first followed by authorization filters and then content-based filters d) If all filters in the policy execute successfully, the request will be routed on to the protected API or service. e) If the policy has been configured to process the response message, the response message filters are executed at this point. f) If all of the response filters execute successfully, the response from the API or service is sent back to the client. If an error occurs at any stage, an appropriate SOAP (or other) fault can be returned to the client. Policies comprise of 1 or more message filters connected together using success and failure paths to form a logical circuit. If a filter executes successfully, the next filter on the success path from will be executed. If the filter fails, the next filter on the failure path will be invoked. If the filter aborts due to a condition that prevents the filter from running, the Fault Handler for that policy will be invoked. By combining filters, success paths, failure paths, and fault handlers using simple drag-and-drop methods, it is possible to build up extremely powerful and flexible policies. When all filters on the success path execute successfully, the service requestor receives an appropriate response message. However, if a filter fails (and it has no success path filters configured), the service requestor receives an error message. The TOE enforces a default policy of denying all access to protected services. When a new service is created an associated policy must be defined for the service with a relative path configured for the policy. If no policy is mapped to a service, the default policy is invoked for all message request to access the service. Initial Gateway topology configuration is performed using the Gateway’s managedomain script, described in Chapter 2 of the Axway API Gateway Administrator Guide. Subsequent to initial setup, configuration is performed by Policy Studio and API Gateway Manager. The TOE restricts the ability to manage security attributes in accordance with section 5.3.7. Policy values are restrictive by default – access to objects is denied unless the administrator defines a policy to enable access. A user may terminate their interactive session at Policy Studio and API Gateway Manager using the logout functionality. The following roles can be assigned to users created in API Gateway Manager: Axway Security Target Page 56 of 70 Role Tool Privileges API Gateway Administrator API Gateway Manager, Policy Studio Read/Write access to Manager, Download, edit, deploy, a configuration Policy Studio API Gateway Operator API Gateway Manager Read-only access to Manager Policy Developer Policy Studio Download, edit, deploy Deployer Policy studio Download, edit, deploy KPS Administrator KPS Admin Perform create, read, update, delete (CRUD) operations on data in a Key Property Store (KPS) 6.3 Policy Security Related SFRs: ESM_ATD.1, ESM_EAU.2, FCO_NRR.2, FIA_SOS.1, FPT_RPL.1, FTP_ITC.1, FTP_TRP.1, FCS_CKM.1 FCS_CKM.2 FCS_COP.1(ENC) FCS_COP.1(MAC) FCS_COP.1(MD) FCS_COP.1(SGN) , FPT_TDC.1 Policy Studio transmits policies to the Gateway when they are explicitly deployed by the policy developer. The policy developer admin selects the gateway servers to deploy on by selecting the gateway server name on the deployment screen. A trusted channel (TLS) is established between Policy Studio and the Gateway to protect the transmission of policy data. TLS provides replay detection and will reject the replayed packets and generate an audit event when detection occurs. Access to Policy Studio and API Gateway Manager requires user identification and authentication (username & password) as described in section 6.5. Policy Studio is a thick client Java application executed on a general purpose operating system. Remote access to Policy Studio is not supported. The API Gateway Manager is a web-based interface than can be accessed from the browser. The TOE uses OpenSSL in the operational environment for TLS. Refer to section 6.7 for TLS details. When a policy developer admin deploys a new policy to the admin node manager, the policy deployment windows shows in the process of the deployment up to completion. . In addition, the API Gateway server generates an audit record when a policy is received from Policy Studio, providing proof of receipt. The API Gateway Manager is used to view generated audit records. As documented above, the channel between the API Gateway Manager and the Gateway is secured with HTTP basic authentication over TLS. The ‘node’ field of the receipt identifies the name of the Gateway to which the policy was applied. 6.4 Security Audit Related SFRs: FAU_GEN.1, FAU_SEL.1, FAU_SEL_EXT.1, FAU_STG.1, FAU_STG_EXT.1, FAU_SAR.1, FAU_SAR.3 The TOE generates the audit events identified in Table 16. Audit records contains date and time of events, type of events, subject identity (where applicable) and outcome of events, audit records also contains the additional information identified on table 16. The TOE may store logs locally on the file system or remotely on an external audit server. Communication with the external audit server is secured using TLS (refer to section 6.7 for detail). Axway Security Target Page 57 of 70 Authorized users may view all available audit events via the API Gateway Manager. All Audit events can be enabled and disabled on the API Gateway Manager interface. The domain audit log captures management changes in the API Gateway domain that are written by the Admin Node Manager and by API Gateway instances. This includes details such as API Gateway configuration changes, log in/log out, deployments, user, or topology changes. For example, user Joe deployed a new configuration, admin user created a new group, or user Jane has read deployment data. The domain audit log is enabled by default. However, you can configure filtering options such as the number of events displayed, time interval, and event type. The domain log has the following defaults: 50 files, each 5Mb in size. To view domain audit log events in the API Gateway Manager web console, perform the following steps: 1. In the API Gateway Manager, select Logs > Domain Audit. 2. Configure the number of events displayed in the Max results per server field on the left. Defaults to 1000. 3. Configure the Time Interval for events. Defaults to 1 day. 4. Click the Filter button to add more viewing options (Event Type or Groups and Servers). 5. Click Apply when finished. The transaction log is used to stored audit records describing how the API Gateway processes business traffic. By default, the Gateway stores up to 20 transaction files, each of which is 1GB in size. The defaults can be configured in Policy Studio. The audit files are only accessible to the admin that installed API Gateway. When the audit storage capacity has been reached, the TOE will overwrite the oldest audit files. In addition, the TOE offloads audit data files to an external audit server every 5 minutes; this is a TOE feature that is always present, but it just need to be configured with the external server settings. The TOE relies on the underlying operating system to provide it with a reliable time stamp for use in the audit records. The TOE does not maintain its own time. 6.5 Robust Administrative Access Related SFRs: FIA_AFL.1, FIA_SOS.1, FTA_SSL.3 FTA_SSL.4, FIA_USB.1, FMT_MSA.1(1), FMT_SMR.1, FMT_SMF.1, FMT_MTD.1, FTP_TRP.1, FTA_TAB.1, FPT_SKP_EXT.1, FPT_APW_EXT.1; FMT_MOF_EXT.1 , FCS_CKM.1 FCS_CKM.2 FCS_COP.1(ENC) FCS_COP.1(MAC) FCS_COP.1(MD) FCS_COP.1(SGN) Access to the TOE can be achieved via the Policy Studio application and the web-based API Gateway Manager interface. Users must authenticate prior to being granted access. Users may authenticate via username and password. When authenticating with Policy Studio, HTTP basic authentication over TLS is used. When authenticating with API Gateway Manager, HTML formbased authentication over TLS is used. The TOE determines the username from the credentials presented at authentication and associates the defined role with the corresponding username. If the user role is changed while the user is logged in, the change takes effect immediately. For example: an admin user is logged in as ‘operator’ he is clicking through the pages on the interface to view traffic dashboard and other details viewable by that user. An API Gateway admin logs in to API Gateway Manager on another session and change the role of the ‘Operator’ user to Policy Developer role. This change Axway Security Target Page 58 of 70 will take effect immediately, when the user clicks on a page that is not viewable by the policy developer, the action will be blocked. The TOE administrative user store is maintained internally. Client services user store is maintained on an external LDAP server. The TOE administrative users passwords are stored in a file as a base-64 encoded salted hash of the plaintext password. The salt is a 16-byte value generated using the SHA1PRNG pseudo-random number generator algorithm. A new salt is used for each password hash, which results in different password hashes for the same password. The algorithm used is provided by the JCE and is PBKDF2 with HMAC SHA512 using a key length of 512 bits. The algorithm repeats the digest of the password along with the salt for 102400 iterations. All sensitive data (local user store, private keys and their passwords, and passwords required to connect to third-party services) are encrypted in the Entity Store using PBE with the entity store passphrase. In order to encrypt data at rest, a key hierarchy approach is used. Firstly, a high entropy master key(MK) of size 32 bytes is created using PBKDF2 with inputs of the entity store passphrase, a 16 byte salt generated using a pseudo random number generator(PRNG) and a 100,000 iteration count. Master Key (MK) = PBKDF2(HMAC-SHA512, passphrase, unique salt, iteration count, master key length) This master key is not used for encryption but instead is used as key material input into the generation of a data protection key (DPK). The data protection key of size 32 bytes is derived from the master key again using PBKDF2, unique random salt and master key(MK). Data Protection Key (DPK) = PBKDF2(HMAC-SHA512, Master Key, unique salt, iteration count, data protection key length) The number of iterations is 2 for the data protection key generation to maintain acceptable performance in the runtime environment. To encrypt plaintext we generate a cipher using AES/GCM encryption and the DPK as the secret key and we store the unique salt with the cipher text. Pre-shared keys, symmetric keys, and private keys stored in the entity store cannot be viewed through an interface designed specifically for that purpose. The Entity Store Passphrase can be changed using Policy Studio.The TOE detects when a defined threshold of 6 unsuccessful authentication attempts has occurred in a 5 minutes time frame and will lock the associated account for 30 minutes. The TOE depends on its operational environment to provide cryptographic functionality that it uses. The TOE allows specification of a password policy in accordance with FIA_SOS.1 and terminates inactive sessions at the web-based API Gateway Manager after an administrator defined period of inactivity. Users may also terminate their own session. For configuration details refer to the API Gateway Settings Reference section of the Administrator Guide. The TOE displays an administrator defined banner at logon to the Policy Studio and API Gateway Manager interfaces. For configuration details, refer to the Configure an advisory banner section of the Administrator Guide. 6.6 Continuity of Enforcement Related SFRs: FPT_FLS_EXT.1, , FRU_FLT.1 Axway Security Target Page 59 of 70 The Gateway continues policy enforcement in the event of a loss of connectivity with Policy Studio by enforcing the last policy received. Continuous connectivity with the Policy Studio is not expected or required. When policy is restored after a loss of connectivity, the Gateway will continue to enforce the last policy received until a new policy is deployed. 6.7 Protected Communication Related SFRs: FTP_ITC.1, FTP_TRP.1, FCS_TLS_EXT.1, FCS_HTTPS_EXT.1 , FCS_CKM.1 FCS_CKM.2 FCS_COP.1(ENC) FCS_COP.1(MAC) FCS_COP.1(MD) FCS_COP.1(SGN) 6.7.1 TLS Details This section provides additional detail regarding the TOE’s usage of TLS provided by the operational environment. All Gateway cryptographic operations for TLS use cases covered within the scope of this evaluation are performed by the OpenSSL FIPS Object Module. The API Gateway is configured to uses FIPS Approved algorithms (CAVP certificate numbers AES: #4127; RSA: #2237; ECDSA: #945; SHA: #3396; DRBG: #1247; HMAC: #2700; Component Test: #936). 6.7.1.1 TLS The TOE makes use of TLS in the following ways: a) Between service clients and the Gateway – in this case the TOE is a TLS server. b) Between Policy Studio and the Gateway – in this case the TOE is both a TLS client (Policy Studio) and TLS server (Gateway). c) Between API Gateway Manager and the Gateway – in this case the TOE is just a TLS server, because the client in this case is the browser, which is not part of the TOE. d) Between the Gateway and the audit server – in this case the TOE is a TLS client. e) Between the Gateway and the LDAP server – in this case the TOE is a TLS client. The TLS implementation has the following characteristics when configured in accordance with the Secure Installation Guide: a) TLS 1.2 (RFC 5246) and TLS 1.3 (RFC 8446) are supported without extensions. b) Client authentication is supported (i.e. if configured the client must submit a trusted certificate to the server). c) When acting as either client or server, the TOE is configured to negotiate the following cipher suit. If a listed cipher suite is not supported by the other party then the connection will be refused: The TOE supports the following ciphersuites for communications with remote administrators and communications with remote audit and LDAP servers: for TLS 1.2 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 4096) TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 4096) TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 4096) TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 4096) TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) Axway Security Target Page 60 of 70 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) For TLS 1.3 TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256 Axway Security Target Page 61 of 70 7 Rationale 7.1 PP Conformance Claim Although this ST is based on two PPs, no conformance is claimed. 7.2 Security Objectives Rationale The following table presents the rational for assumptions that are covered by objectives for the environment Table 21 : Assumptions vs Objectives for the environment Assumption Objectives for the environment AS.SYSTIME OE.SYSTIME AS.USERID OE.USERID AS.MANAGE OE.PERSON , OE.ADMIN, OE.INSTALL AS.POLICY OE.POLICY AS.INSTALL OE.INSTALL The following table presents the rational for threats that are covered by security objectives Table 22 : Threats and OSP vs Objectives Threats Security objectives & assumptions covering the threat T.ADMIN_ERROR O.CONSISTENT O.MONITOR O.RESILIENT O.AUDIT OE.INSTALL OE.PERSON OE.ADMIN T.CONTRADICT O.MNGRID O.CONSISTENT O.MONITOR OE.INSTALL OE.PERSON T.EAVES O.MNGRID O.DISTRIB O.PROTCOMMS O.CRYPTO OE.KEY_ERASE T.FORGE O.ACCESSID O.MANAGE O.SELFID O.INTEGRITY O.PROTCOMMS O.CRYPTO OE.KEY_ERASE T.UNAUTH O.DATAPROT O.AUTH O.MANAGE O.PROTCOMMS O.BANNER O.AUDIT OE.USERID O.CRYPTO OE.KEY_ERASE T.WEAKIA O.AUTH O.AUDIT O.ROBUST O.CRYPTO T.WEAKPOL O.CONSISTENT O.MONITOR O.POLICY T.DISABLE O.RESILIENT O.MONITOR O.AUDIT OE.ADMIN OE.PERSON Axway Security Target Page 62 of 70 T.FALSIFY O.ACCESSID O.SELFID O.PROTCOMMS O.MAINTAIN O.MNGRID O.OFLOWS O.CRYPTO O.INTEGRITY T.MASK O.MONITOR O.AUTH O.AUDIT O.ROBUST O.CRYPTO OE.SYSTIME T.NOROUTE O.MAINTAIN T.OFLOWS O.MNGRID O.OFLOWS O.CRYPTO OE.KEY_ERASE T.BYPASS_POLICY O.DATAPROT OE.POLICY P.BANNER O.BANNER P.UPDATEPOL O.SELFID P.KEY_ERASE O.CRYPTO OE.KEY_ERASE Axway Security Target Page 63 of 70 The following table presents the objectives that are covered by threats/OSP/assumptions Table 23 : rational for objectives covered by threats/OSP/assumptions Threats OSP Assumptions T.ADMIN_ERROR T.CONDTRADICT T.EAVES T.FORGE T.UNAUTH T.WEAKPOL T.WEAKIA T.DISABLE T.FALSIFY T.MASK T.NOROUTE T.OFLOWS T.BYPASS_POLICY P.BANNER P.UPDATEPOL P.KEY_ERASE AS.SYSTIME AS.USERID AS.MANAGE AS.POLICY AS.INSTALL Security Objectives O.DATAPROT X X O.MAINTAIN X X O.MNGRID X X X O.MONITOR X X X X X O.OFLOWS X X O.RESILIENT X X O.SELFID X X X O.ACCESSID X X O.AUDIT X X X X X O.AUTH X X X O.BANNER X X O.CONSISTEN T X X X O.DISTRIB X O.INTEGRITY X X O.MANAGE X X O.POLICY X O.PROTCOM MS X X X X X O.ROBUST X X O.CRYPTO X X X X X X X X OE.ADMIN X X X OE.INSTALL X X X X OE.PERSON X X X X OE.SYSTIME X X OE.USERID X X OE.POLICY X X OE.KEY_ERASE X X X X X Axway Security Target Page 64 of 70 The following table presents the objectives that are implemented by the SFRs Table 24 : Implementation of objectives by SFrs O.ACCESSID FTP_ITC.1 O.AUDIT FAU_GEN.1 FAU_SEL.1 FAU_SEL_EXT.1 FAU_STG.1 FAU_STG_EXT.1, FAU_SAR.1, FAU_SAR.3 O.AUTH FIA_AFL.1 FIA_SOS.1 FIA_USB.1 FTA_SSL.3 FTA_SSL.4 FPT_APW_EXT.1 O.BANNER FTA_TAB.1 O.CONSISTENT FMT_MSA_EXT.5 O.DISTRIB FTP_ITC.1 FTP_TRP.1 FPT_RPL.1 FCO_NRR.2 ESM_ACT.1 O.INTEGRITY FTP_ITC.1 FTP_TRP.1 FPT_RPL.1 O.MANAGE FTP_ITC.1 FTP_TRP.1 FPT_RPL.1 O.POLICY ESM_ACD.1 ESM_ATD.1 ESM_ATD.2 FMT_MOF.1(1) FMT_MOF.1(2) FMT_MOF_EXT.1 FMT_MSA.1 FMT_MSA.3, FDP_ACC.1,, FDP_ACF.1, FDP_IFF.1, FDP_IFC.1, O.PROTCOMMS FTP_ITC.1 FTP_TRP.1 FPT_RPL.1, FPT_TDC.1 O.ROBUST FIA_AFL.1 FIA_SOS.1 FIA_USB.1 O.CRYPTO FCS_HTTPS_EXT.1 FCS_TLS_EXT.1 FCS_CKM.1 FCS_CKM.2 FCS_COP.1(ENC) FCS_COP.1(MAC) FCS_COP.1(MD) FCS_COP.1(SGN) FPT_TDC.1, FMT_MTD.1, , FPT_SKP_EXT.1 O.DATAPROT FMT_SMR.1 FMT_MOF_EXT.1 FMT_MSA.1 FMT_MTD.1, O.MAINTAIN FRU_FLT.1 FPT_FLS_EXT.1 O.MNGRID ESM_EAU.2 ESM_EID.2 O.MONITOR FAU_GEN.1 FMT_MOF.1(1) O.OFLOWS ESM_ACD.1 ESM_ATD.1 ESM_ATD.2 FMT_MOF.1(1) FMT_MOF.1(2) FMT_MOF_EXT.1 FMT_MSA.1 FMT_MSA.3 Axway Security Target Page 65 of 70 O.RESILIENT FMT_MOF_EXT.1 O.SELFID ESM_EID.2 7.1 Security Requirements Rationale The following table presents the rational for SFRs dependencies. Table 25 SFRs dependencies rational SFR Dependencies Respected dependencies ESM_ACD.1 None ESM_ACT.1 None ESM_ATD.1 None ESM_ATD.2 None ESM_EAU.2 ESM_EID.2 ESM_EID.2 ESM_EID.2 None FAU_GEN.1 FPT_STM.1 Covered by AS.SYSTIME FAU_SEL.1 FAU_GEN.1 FMT_MTD.1 FAU_GEN.1 FMT_MTD.1 is covered by FMT_MOF_EXT.1 FAU_SEL_EXT.1 FAU_GEN.1 FMT_MTD.1 FAU_GEN.1 FMT_MTD.1 is covered by FMT_MOF_EXT.1 FAU_STG.1 FAU_GEN.1 FAU_GEN.1 FAU_STG_EXT.1 FAU_GEN.1 FTP_ITC.1 FAU_GEN.1 FTP_ITC.1 FAU_SAR.1 FAU_GEN.1 FAU_GEN.1 FAU_SAR.3 FAU_SAR.1 FAU_SAR.1 FCO_NRR.2 FIA_UID.1 Covered by ESM_EID.2 FCS_HTTPS_EXT.1 FCS_TLS_EXT.1 FCS_TLS_EXT.1 FCS_TLS_EXT.1 FCS_COP.1 FCS_COP.1(ENC) FCS_COP.1(MAC) FCS_COP.1(MD) FDP_ACC.1 FDP_ACF.1 FDP_ACF.1 FDP_ACF.1 FDP_ACC.1 FMT_MSA.3 FDP_ACC.1 FMT_MSA.3 FDP_IFC.1 FDP_IFF.1 FDP_IFF.1 FDP_IFF.1 FDP_IFC.1 FMT_MSA.3 FDP_IFC.1 FMT_MSA.3 FIA_AFL.1 FIA_UAU.1 Covered by Axway Security Target Page 66 of 70 ESM_EAU.2 FIA_SOS.1 None FIA_USB.1 FIA_ATD.1 Covered by ESM_ATD.1 and ESM_ATD.2 FMT_MOF.1(1) FMT_SMF.1 FMT_SMR.1 FMT_SMF.1 FMT_SMR.1 FMT_MOF.1(2) FMT_SMF.1 FMT_SMR.1 FMT_SMF.1 FMT_SMR.1 FMT_MOF_EXT.1 FMT_SMF.1 FMT_SMR.1 FMT_SMF.1 FMT_SMR.1 FMT_MSA.1 FDP_ACC.1 FMT_SMF.1 FMT_SMR.1 FDP_ACC.1 FMT_SMF.1 FMT_SMR.1 FMT_MSA.3 FMT_MSA.1 FMT_SMR.1 FMT_MSA.1 FMT_SMR.1 FMT_MSA_EXT.5 FMT_MOF_EXT.1 FMT_MOF_EXT.1 FMT_SMF.1 None FMT_SMR.1 FIA_UID.1 Covered by ESM_EID.2 FMT_MTD.1 FMT_SMF.1 FMT_SMR.1 FMT_SMF.1 FMT_SMR.1 FPT_APW_EXT.1 None FPT_FLS_EXT.1 None FPT_RPL.1 None FPT_SKP_EXT.1 None FPT_TDC.1 None FRU_FLT.1 FPT_FLS_EXT.1 FTA_SSL.3 None FTA_SSL.4 None FTA_TAB.1 None FTP_ITC.1 None FTP_TRP.1 None FCS_CKM.1 [FCS_CKM.2 or FCS_COP.1] FCS_CKM.4 FCS_CKM.2 FCS_COP.1 (ENC) FCS_COP.1 (MAC) FCS_COP.1 (MD) FCS_COP.1 (SGN) FCS_CKM.4 is not implemented by the ToE. Erase of key are performed by organizational procedures FCS_CKM.2 [FDP_ITC.1 or FCS_CKM.1 Axway Security Target Page 67 of 70 FDP_ITC.2 or FCS_CKM.1] FCS_CKM.4 FCS_CKM.4 is not implemented by the ToE. Erase of key are performed by organizational procedures FCS_COP.1(ENC) [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1] FCS_CKM.4 FCS_CKM.1 FCS_CKM.4 is not implemented by the ToE. Erase of key are performed by organizational procedures FCS_COP.1(MAC) [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1] FCS_CKM.4 FCS_CKM.1 FCS_CKM.4 is not implemented by the ToE. Erase of key are performed by organizational procedures FCS_COP.1(MD) [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1] FCS_CKM.4 FCS_CKM.1 FCS_CKM.4 is not implemented by the ToE. Erase of key are performed by organizational procedures FCS_COP.1(SGN) [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1] FCS_CKM.4 FCS_CKM.1 FCS_CKM.4 is not implemented by the ToE. Erase of key are performed by organizational procedures Axway Security Target Page 68 of 70 7.2 TOE Summary Specification Rationale Table 22 provides a coverage mapping showing that all SFRs are mapped to the security functions described in the TSS. Table 26: Map of SFRs to TSS Security Functions SFR ESM_ACD.1 X ESM_ACT.1 X ESM_ATD.1 X X ESM_ATD.2 X ESM_EAU.2 X ESM_EID.2 X FAU_GEN.1 X FAU_SEL.1 X FAU_SEL_EXT.1 X FAU_STG.1 X FAU_STG_EXT.1 X FAU_SAR.1 X FAU_SAR.3 X FCO_NRR.2 X FCS_HTTPS_EXT.1 X FCS_TLS_EXT.1 X FDP_ACC.1 X FDP_ACF.1 X FDP_IFC.1 X Axway Security Target Page 69 of 70 SFR FDP_IFF.1 X FIA_AFL.1 X FIA_SOS.1 X X FIA_USB.1 X FMT_MOF.1 X FMT_MOF.1(1) X FMT_MOF.1(2) X FMT_MOF_EXT.1 X X FMT_MSA.1 X X X FMT_MSA.3 X X FMT_MSA_EXT.5 X X X FMT_SMF.1 X X X FMT_SMR.1 X X X FMT_MTD.1 X X X FPT_APW_EXT.1 X X FPT_FLS_EXT.1 X FPT_RPL.1 X FPT_SKP_EXT.1 X FPT_TDC.1 X X FRU_FLT.1 X FTA_SSL.3 X FTA_SSL.4 X FTA_TAB.1 X Axway Security Target Page 70 of 70 SFR FTP_ITC.1 X X FTP_TRP.1 X X X FCS_CKM.1 X X X X FCS_CKM.2 X X X X FCS_COP.1(ENC) X X X x FCS_COP.1(MAC) X X X x FCS_COP.1(MD) X X X X FCS_COP.1(SGN) X X X X