Axway API Gateway Security Guide

Axway API Gateway Security Guide
 SECURITY GUIDE
Axway API Gateway
Version 7.4.1
14 March 2016
Copyright © 2016 Axway
All rights reserved.
This documentation describes the following Axway software:
Axway API Gateway 7.4.1
No part of this publication may be reproduced, transmitted, stored in a retrieval system, or translated into any human or computer language, in any form or by any means, electronic, mechanical, magnetic, optical, chemical, manual, or otherwise, without the prior written permission of the copyright owner, Axway.
This document, provided for informational purposes only, may be subject to significant modification. The descriptions and information in this document may not necessarily accurately represent or reflect the current or planned functions of this product. Axway may change this publication, the product described herein, or both. These changes will be incorporated in new versions of this document. Axway does not warrant that this document is error free.
Axway recognizes the rights of the holders of all trademarks used in its publications.
The documentation may provide hyperlinks to third-party web sites or access to third-party content. Links and access to these sites are provided for your convenience only. Axway does not control, endorse or guarantee content found in such sites. Axway is not responsible for any content, associated links, resources or services associated with a third-party site.
Axway shall not be liable for any loss or damage of any sort associated with your use of third-party content.
Contents
Preface
7
Who should read this guide
7
How to use this guide
7
API Gateway documentation set
8
API Gateway documentation
8
API Manager and API Portal documentation
9
Related documentation
9
Support services
9
Training services
10
Accessibility
11
Screen reader support
11
Support for high contrast and accessible use of colors
11
What's new
Changes in version 7.4.1
12
12
1 Secure Development Lifecycle
13
2 Certifications and compliance
14
Compliance
14
Appliance compliance
14
FIPS-140-2
14
NIST Suite B
15
3 Security features
16
Secure connections
16
Password management features
17
Certificate management features
17
PassPort certificate management
17
Certificate storage, validation, and revocation
18
Identity and access management features
18
PassPort access management
18
When not using PassPort
18
Other security features
4 Identity and access management
19
21
The RBAC model
21
Available resources and actions
22
Axway API Gateway 7.4.1
Security Guide 3
Predefined privileges and roles
5 Configuration
22
24
Security architecture
24
Security configuration
25
Inbound SSL configuration
25
Outbound SSL configuration
25
Import certificates and keys to the trusted certificate store
26
Configure certificates for internal SSL channels
26
Axway PassPort integration
26
Authentication
27
Authorization
27
OAuth and OpenID Connect
27
Message-level encryption and integrity
27
Certificate validation
28
Entity Store passphrase
28
Set Entity Store passphrase for automated startup
28
Password policy
28
Signing the audit trail
29
HSM integration
29
API firewalling configuration
29
Policy Studio SSL settings
29
Policy Studio Node Manager credentials
30
Set administrator password during installation
30
Appliance Web Administration Interface SSL certificate
30
FIPS mode
30
FIPS compliance validation
31
NIST SuiteB and SuiteB Top Secret compliance validation
31
Advisory banner
31
API keys
31
Audit events
31
External audit offload
32
Secure by default configuration
32
Product certificates
33
6 Security best practices
35
Secure connections
35
Sample certificates
35
Self-signed certificates
35
Privileged access user list
36
Internet access limitation
36
Correct upgrade procedure
36
Generic or anonymous users
36
Password policy
37
Axway API Gateway 7.4.1
Security Guide 4
Default authentication account
37
Remote connections
37
Logging, audit, and alerts rules
38
Sensitive files and databases
38
Appendix A: Compliant configuration settings for Policy Studio
41
Abbreviations
41
HTTPS interface, SMTP interface, ICAP server, Connection filter, Connect to URL filter
42
FIPS
42
Suite B
43
Suite B TS
44
JMS service – Active MQ
44
JMS service – IBM MQ
45
Embedded Active MQ
45
PGP Encrypt and Sign
45
Suite B and Suite B TS
46
XML Encryption filter, XML Encryption Settings filter, XML Decryption, XML Decryption Settings filter
46
FIPS
46
Suite B and Suite B TS
46
XML Signature Generation filter
47
FIPS
47
Suite B and Suite B TS
47
XML Signature Verification filter
47
FIPS
47
Suite B and Suite B TS
47
KeyInfo configuration
48
Create Thumbprint filter
48
FIPS
48
Suite B
48
Suite B TS
48
SMIME Encrypt filter
48
SMIME Decrypt filter
50
SMIME Sign filter
50
FIPS
50
Suite B and Suite B TS
50
SMIME Verify filter
50
HTTP Digest Authentication filter
50
Scripting filter
50
WS-Security Username Authentication
51
Kerberos settings
51
FIPS
51
Suite B and Suite B TS
51
Kerberos Service Authentication
Axway API Gateway 7.4.1
51
Security Guide 5
FIPS
51
Suite B and Suite B TS
51
SiteMinder SMHost configuration
52
FIPS
52
Suite B and Suite B TS
52
Database Authentication Repository
52
FIPS
52
Suite B and Suite B TS
52
Axway API Gateway 7.4.1
Security Guide 6
Preface
This guide provides instructions and recommendations to help you strengthen the security of API Gateway. Security descriptions include:
l How the product was developed in a secure way
l A list of main security features
l Secure configuration parameters, including the Secure by Default configuration
l Identity and access management in this product
l Best practices to use this product in a secure way
Who should read this guide
This guide is targeted at the following audiences:
l Security teams in charge of auditing the security of the product
l Global network engineers
l Product administrators
How to use this guide
This guide should be used in conjunction with the other guides in the API Gateway documentation set.
Before you begin using API Gateway, review this guide thoroughly. The following is a brief description of the contents of each section:
Secure Development Lifecycle on page 13 – Describes how API Gateway was implemented using a Secure Development Lifecycle (SDL).
Certifications and compliance on page 14 – Describes API Gateway security certifications and compliance.
Security features on page 16 – Describes the security features of API Gateway.
Identity and access management on page 21 – Describes the identity and access management features of API Gateway.
Configuration on page 24 – Describes the security architecture and configuration for API Gateway.
Security best practices on page 35 – Describes best practices for securing API Gateway.
Axway API Gateway 7.4.1
Security Guide 7
Preface
API Gateway documentation set
Go to Axway Sphere at https://support.axway.com to find all documentation for this product version.
API Gateway documentation
The API Gateway documentation set includes the following guides:
l API Gateway Installation Guide
Describes how to install API Gateway components on all platforms and how to upgrade API Gateway versions.
l API Gateway Concepts Guide
Provides an overview of the API Gateway components, tools, and architecture.
l API Gateway Administrator Guide
Describes how to configure and manage an API Gateway domain.
l API Gateway Policy Developer Guide
Describes the main API Gateway features (for example, all policies, filters, configuration options and so on), and how to configure them using the Policy Studio graphical tool.
l API Gateway Deployment and Promotion Guide
Describes how to promote and deploy API Gateway configuration between different environments (for example, development, testing, and production).
l API Gateway OAuth User Guide
Describes how to configure API Gateway for OAuth 2.0 and OpenID Connect.
l API Gateway Developer Guide
Describes how to extend, leverage, and customize API Gateway.
l API Gateway Key Property Store User Guide
Describes how to use the Key Property Store (KPS) to configure and manage data referenced from policies running on API Gateway.
l API Gateway PassPort Interoperability Guide
Describes how to configure API Gateway and Axway PassPort to work together.
l API Gateway Sentinel Interoperability Guide
Describes how to configure API Gateway and Axway Sentinel to work together.
l API Gateway Validation Authority Interoperability Guide
Describes how to configure API Gateway and Axway Validation Authority to work together.
l API Gateway Appliance Installation and Administration Guide
Describes how to install, configure, and administer the API Gateway Appliance.
Axway API Gateway 7.4.1
Security Guide 8
Preface
l API Gateway Security Guide
Describes how to strengthen the security of API Gateway.
API Manager and API Portal documentation
The API Manager and API Portal documentation set includes the following guides:
l API Manager API Management Guide
Describes how to use the API management features available separately in API Manager. API Manager is an additional licensable layered product running on API Gateway.
l API Portal User Guide
Describes how to install, customize, and use the client application developer features available separately in API Portal. API Portal is an additional licensable layered product running on API Gateway. Related documentation
The Axway 5 Suite documentation set includes the following documents:
l Axway 5 Suite Overview
Provides an introduction to Axway 5 Suite and describes how the products in the suite can be used in reference solutions to solve integration problems and govern the flow of data.
l Axway 5 Suite Supported Platforms
Lists the different operating systems, databases, browsers, and thick client platforms supported by each product in Axway 5 Suite.
Axway 5 Suite reference solution guides provide conceptual information about the reference solution, as well as guidance on installing, configuring, and managing it.
l Accounting Integration Concepts Guide
l B2B Integration Implementation Guide l Financial Integration Implementation Guide
l Managed File Transfer Implementation Guide
Note
All Axway documentation is available on Axway Sphere at https://support.axway.com.
Support services
The Axway Global Support team provides worldwide 24 x 7 support for customers with active support agreements.
Email [email protected] or visit Axway Sphere at https://support.axway.com.
Axway API Gateway 7.4.1
Security Guide 9
Preface
See "Troubleshoot your API Gateway installation" in the API Gateway Administrator Guide for the information that you should be prepared to provide when you contact Axway Support.
Training services
Axway offers training across the globe, including on-site instructor-led classes and self-paced online learning. For details, go to:
http://www.axway.com/support-services/training
Axway API Gateway 7.4.1
Security Guide 10
Accessibility
Axway strives to create accessible products and documentation for users. This documentation provides the following accessibility features:
l Screen reader support on page 11
l Support for high contrast and accessible use of colors on page 11
Screen reader support
l Alternative text is provided for images whenever necessary. l The PDF documents are tagged to provide a logical reading order.
Support for high contrast and accessible use
of colors
l The documentation can be used in high-contrast mode.
l There is sufficient contrast between the text and the background color.
l The graphics have the right level of contrast and take into account the way color-blind people perceive colors. Axway API Gateway 7.4.1
Security Guide 11
What's new
This guide includes the following documentation changes.
Changes in version 7.4.1
l Updates to Security configuration on page 25:
o Password policy
o Advisory banner
o API keys
o Audit events
o External audit offload
l Updates to Security best practices on page 35:
o Password policy
Axway API Gateway 7.4.1
Security Guide 12
Secure Development
Lifecycle
1 Axway implements a Secure Development Lifecycle (SDL) in the development of its main products. This SDL is similar to the one defined by Microsoft. A dedicated team, the Product Security Group (PSG), in association with the product development teams, is in charge of managing this SDL.
The secure development lifecycle consists of standardized process flows during the development lifecycle. The SDL process is a spiral development model. Axway works within this model and with an Agile development model to deliver the required security artifacts for the SDL. The following depicts the simplified Microsoft SDL model.
Axway implements many SDL process and control points. Some important steps along the path to secure product delivery include the creation of both security and design requirements as well as the associated design-time threat models. These steps ensure that products meet initial specifications and that the posited security designs pass all the threat model criteria established both within the security community and with the Axway PSG.
At Axway, there are a broad suite of tools associated with the implementation and verification phases of the SDL. Both static and dynamic analysis tools are run to identify potential code weaknesses and to discover security issues potentially exposed at runtime. Suites of attack surface tools and penetration testing tools are run to ensure the deployed products on the target platforms meet gated criteria in the SDL and criteria provided by the internal PSG. Axway provides tool suite information and our customized usage profiles upon customer request. Well-known security industry-standard tools are used as well as many other enhanced test scenarios required by our most security-conscious customers.
The new product introduction (NPI) process at Axway requires a final security review with associated development and testing artifacts. This NPI process supports the release of new products or major product revisions. The NPI also ensures the SDL is started early in development to optimize the delivery of secured products for you, our customer.
Axway API Gateway 7.4.1
Security Guide 13
2 Certifications and
compliance
This section describes the certifications the product has received and the standards it is compliant with.
Compliance
This section contains information about the standards with which the product is compliant.
Appliance compliance
The API Gateway appliance form factor conforms to a number of industry standards and specifications. For more information, see the API Gateway Appliance documentation.
FIPS-140-2
The current version of this product (7.4.1) is Federal Information Processing Standards (FIPS) 1402 compliant when running in FIPS mode on the following platforms:
l Windows
l OEL Linux
l Solaris SPARC
l Appliance (SUSE Linux Enterprise Server)
When operating in FIPS mode, the following FIPS-certified cryptographic modules are enabled and invoked for all FIPS-compliant cryptographic algorithms:
Cryptographic module
FIPS 140-2 certificate
number
Entrust Authority™ Security Toolkit for the Java® Platform v8.0
1839
OpenSSL FIPS Object Module
1747
The ability to run API Gateway in FIPS mode is a licenseable option of the standard version and must be specifically ordered. It is possible to enable or disable FIPS mode as required. For more information on running API Gateway in FIPS mode, see the API Gateway Administrator Guide.
Axway API Gateway 7.4.1
Security Guide 14
2 Certifications and compliance
You can run the FIPS Compliance Validation Tool from Policy Studio to check that a configuration is FIPS compliant. This tool is available from the Tools > Check Security Constraints > FIPS menu option. For more information on running the tool, see the API Gateway Policy Developer Guide. For guidance on compliant settings for Policy Studio filters, see Compliant configuration settings for Policy Studio on page 41.
NIST Suite B
You can run the National Institute of Standards and Technology (NIST) Suite B and Suite B Top Secret Compliance Validation Tools from Policy Studio to ensure that a configuration is Suite B or Suite B Top Secret compliant. These tools are available from the Tools > Check Security
Constraints > SuiteB and the Tools > Check Security Constraints > SuiteBTS menu options. For more information on running these tools, see the API Gateway Policy Developer Guide. For guidance on compliant settings for Policy Studio filters, see Compliant configuration settings for Policy Studio on page 41.
Axway API Gateway 7.4.1
Security Guide 15
3 Security features
This product contains the following security features:
Secure connections
16
Password management features
17
Certificate management features
17
Identity and access management features
18
Other security features
19
Secure connections
The following secure connections are available:
l Connections between all product components – API Gateway, Node Manager, and Policy Studio – are SSL-secured by default. l Connections to databases and LDAP servers can be SSL-secured.
l Connections made to audit servers can be made over SSL.
l Connections to other Axway products (for example, PassPort) can be SSL secured. l All inbound connections to API Gateway can be configured to be received over one-way or twoway SSL.
l All outbound connections made by API Gateway to destination web services can be made over one-way or two-way SSL where the destination supports SSL. l Inbound and outbound FTP connections can be made secure by using either FTPS or SFTP.
l SMTP and POP connections can be made over SSL or TLS.
l API Gateway can send messages to an Internet Content Adaptation Protocol (ICAP) server for content adaptation over a mutually authenticated SSL connection. l In all cases where API Gateway is delegating authentication and authorization decisions to a third party identity management (IM) server, the connection to that server can be made over SSL/TLS where it is supported by the server.
Axway API Gateway 7.4.1
Security Guide 16
3 Security features
Password management features
The following passwords are stored securely by the product:
l Administrator user passwords
The administrator user passwords are stored in the INSTALL_
DIR/apigateway/conf/adminUsers.json file as a base64-encoded salted hash of the plain text password. The salt is a 16 byte value generated using the SHA1PRNG pseudo-random number generator algorithm. The algorithm used is provided by JCE and is PBKDF2 with HMAC SHA1 using a key length of 256 bits. The algorithm repeats the digest of the password along with the salt for 1024 iterations.
Note
A new salt is used for each password hash, which results in different password hashes for the same password.
l Passwords stored in the Entity Store:
All sensitive data – local user store passwords, private keys and their passwords, and passwords required to connect to third party services – can be encrypted in the Entity Store using PBE with the Entity Store passphrase. The password and a random 8-byte salt are converted using the PKCS#12 mechanism to a key and IV for the encryption algorithm. The encryption algorithm used is 3DES, EDE, 3 key, with the SHA1 digest used for generating the IV and key material.
You can change the Entity Store passphrase at any time using Policy Studio. For more information, see the API Gateway Administrator Guide.
Certificate management features
Certificate management can either be performed internally in the product or using Axway PassPort.
PassPort certificate management
API Gateway can integrate with Axway PassPort to authenticate users against the PassPort certificate store. The connection between API Gateway and PassPort requires that communication is performed over a secure connection using two-way SSL authentication. This means that the PassPort server must be able to identify and trust the client connection and this trust is established by registration.
The first connection from API Gateway to PassPort initiates registration. A public-private key pair is created and a Certificate Signing Request (CSR) is submitted to PassPort. While the CSR is pending, the repository is unable to process any requests. However, registration is a one off event, and when complete, it does not need to be repeated.
For more information on PassPort integration, see the API Gateway PassPort Interoperability Guide.
Axway API Gateway 7.4.1
Security Guide 17
3 Security features
Certificate storage, validation, and
revocation
The following features are available:
l The product can validate certificates using CRL, OCSP, and XKMS.
l It is also possible to validate the thumbprint, attributes, and chain of a given certificate using the out-of-the-box filters.
l Local private keys can be stored in the local certificate store and can be encrypted with the Entity Store passphrase using the PBE with SHA and 3DES (for example, pbeWithSHAAnd3_
KeyTripleDES_CBC) algorithm. You can change this passphrase at any time using Policy Studio.
l The local private keys can also be stored in a Hardware Security Module (HSM), for example, Thales nShield Solo or Safenet Luna SA. For more information on storing certificates and keys on a HSM, see the API Gateway Administrator Guide. Identity and access management features
Identity and access management (IAM) can be performed internally in the product using Axway PassPort or a range of other third party Identity Management products.
PassPort access management
The following PassPort access management features are available:
l An RBAC (Role-Based Access Control) is used.
l The users and associated passwords can be stored in a PassPort database. Alternatively, they can be retrieved from an LDAP directory or from Active Directory. l An SSO option is available. PassPort includes a reverse proxy and a token manager to provide an SSO option only for Axway products.
l The product can authenticate and authorize users for specific resources against PassPort.
l See the Axway PassPort documentation, available from Axway Sphere at https://support.axway.com, for a complete list of features in this product.
When not using PassPort
The following features are available:
l Users can be stored locally in the local user store.
l Alternatively, users can be stored in databases, LDAP directories, or Key Property Stores (KPS).
Axway API Gateway 7.4.1
Security Guide 18
3 Security features
l The product can integrate with a whole range of third party Identity Management products in order to authenticate and authorize users, including: CA SiteMinder, CA SOA Security Manager, Entrust GetAccess, Oracle Access Manager, Oracle Entitlements Server, RADIUS servers, RSA Access Manager, Sun Access Manager, and Tivoli.
l The product also supports authentication and authorization of users with SAML, WS-Security Username Tokens, WS-Trust, and other WS-* standards.
l Other authentication and authorization schemes include HTTP basic and HTTP digest authentication, cookie-based sessions, HTML form authentication, SSL, Kerberos, X.509 certificate attribute authorization, XACML, OAuth 2.0 and OpenID Connect, and RBAC authorization against an LDAP directory.
Other security features
The following features are available:
l The product supports the following security standards: OAuth 2.0, OpenID Connect, Kerberos, XML Signature, XML-Encryption, SAML, WS-Trust, SMIME encryption/decryption, SMIME signing/verification, PGP signature/verification and encryption/decryption, WS-Trust, XACML, and WS-Policy.
l API Gateway can scan for viruses using the ClamAV, Sophos, and McAfee anti-virus scanners.
l Other security features include IP address validation, message throttling, XML complexity, content-type validation, regexp-based input validation, XML schema validation, JSON validation, and timestamp validation. For more information on these features, see the API Gateway Policy Developer Guide.
The following physical security features are available for API Gateway when shipped as a hardware appliance:
Security
feature
Description
Cover latch
A tooled latch is integrated in the side cover to secure it to the rack chassis.
Bezel
An optional metal bezel is mounted to the chassis front to provide the Dell ID. A lock on the bezel is used to protect unauthorized access to hard drives. System status is viewable on the LCD screen when the bezel is installed.
Poweroff security
BIOS has the ability to disable the power button function.
Intrusion alert
An internal switch is used to detect chassis intrusion.
Axway API Gateway 7.4.1
Security Guide 19
3 Security features
Security
feature
Description
Secure mode
BIOS has the ability to enter a secure boot mode through system setup. This mode includes the option to lock out the power and NMI switches on the control panel, or set up a system password.
For more information on the appliance, see the API Gateway Appliance Installation and Administration Guide.
Axway API Gateway 7.4.1
Security Guide 20
Identity and access
management
4 This section describes the identity and access management features of the product.
The RBAC model
API Gateway uses Role-Based Access Control (RBAC) to restrict access to authorized users based on their assigned roles in a domain. Permissions to perform specific system operations are assigned to specific roles, and system users are granted permission to perform specific operations only through their assigned roles. This simplifies system administration because users do not need to be assigned permissions directly, but instead acquire them through their assigned roles.
For example, the default administrator user (for example, admin) has the following user roles:
l Policy Developer
l API Gateway Administrator
l KPS Administrator
The following diagram illustrates the RBAC model.
Axway API Gateway 7.4.1
Security Guide 21
4 Identity and access management
The following is a description of the diagram:
l Clients initiate management service requests via the Admin Node Manager.
l The Admin Node Manager uses RBAC to determine if the user has permission to access the requested service.
l If the user has permission, the request can be completed. Otherwise, the request is denied.
For a more detailed explanation of RBAC in API Gateway, see the API Gateway Administrator Guide.
Available resources and actions
The Admin Node Manager component exposes a number of REST management services, which are all protected by RBAC. For example, the exposed services and the associated tools that use them include the following:
Protected
resource
Tool
Description
Traffic Monitoring Service
API Gateway Manager
Displays HTTP, HTTPS, JMS, and FTP message traffic processed by API Gateway.
Configuration Service
API Gateway Manager
Adds and removes tags on API Gateway.
Topology API
API Gateway Manager
Accesses and configures API Gateway domains.
Static Content Resources
API Gateway Manager
Manages UI elements in a browser.
Deployment API
Policy Studio
Deploys configurations to API Gateway.
KPS Service
Policy Studio
Manages a Key Property Store.
Predefined privileges and roles
User roles have specific tools and privileges assigned to them. These roles define who can use which tools to perform what tasks. The user roles provided with API Gateway assign the following privileges to administrator users with these roles:
Role
Tool
Privileges
Policy Developer
Policy Studio
Download, edit, deploy, version, and tag a configuration.
Axway API Gateway 7.4.1
Security Guide 22
4 Identity and access management
Role
Tool
Privileges
API Gateway Administrator
API Gateway Manager
Read/write access to API Gateway Manager.
API Gateway Operator
API Gateway Manager
Read-only access to API Gateway Manager.
Deployer
Deployment scripts Deploy a new configuration.
KPS Administrator KPS Web UI Perform create, read, update, delete (CRUD) operations on data in a Key Property Store (KPS).
Axway API Gateway 7.4.1
Security Guide 23
5 Configuration
This section contains information on:
Security architecture
24
Security configuration
25
Secure by default configuration
32
Product certificates
33
Security architecture
The following diagram shows the product architecture from a security perspective. The legend explains the security level on connections (SSL by default, always SSL, can be SSL, and so on) and on data storage (signed or encrypted).
The diagram includes the following components:
l ES Conf: Entity Store Configuration, which is a file-based store for all policy data.
l Domain Creds: Salted hash of administrator user credentials. Axway API Gateway 7.4.1
Security Guide 24
5 Configuration
l LDAP/IDM: Identity Management products, such as authentication or authorization servers.
l Domain: An administrative entity comprising at least one Admin Node Manager and at least one API Gateway. These logical components can be located on the same physical or virtual host or separated across multiple physical or virtual hosts as required.
For more detailed information on API Gateway architecture, see the API Gateway Concepts Guide.
Security configuration
The following sections describe the primary security configurations that can be applied to API Gateway. Inbound SSL configuration
API Gateway supports mutual SSL connections on most inbound interfaces, such as HTTPS interfaces, SMTP services, FTP pollers, and JMS services. Each of these interfaces allows an administrator to configure the server certificate, the list of certificates that are considered trusted to validate the client certificate, and the cipher suite to use in SSL connections.
The primary interface on API Gateway is the HTTPS interface, where it is possible to configure a number of HTTP/SSL specific options, including SSL server name identification, ciphers, SSL session cache size, SSL protocol version, and ephemeral Diffie Hellman parameters.
Note
By default the HTTPS interface:
l Enables FIPS compliant cipher suites only
l Explicitly blocks cipher suites that require SSLv3
l Forces the use of TLSv1.2 only
l Blocks unauthenticated ciphers
For more information on configuring these interfaces, see the API Gateway Policy Developer Guide.
Outbound SSL configuration
As well as receiving messages over SSL-enabled interfaces, API Gateway can also route messages over a mutually authenticated channel to back-end services. The primary means of doing this is with either the Connect to URL filter or the Connection filter. Both of these filters allow you to configure trusted CA certificates, client certificates, and client preferences for SSL cipher suites.
Similarly, other filters allow you to make outbound connections over SSL, for example, File
Upload and File Download filters, SMTP filter, Read from JMS filter, and Send to JMS filter.
For more information on these filters, see the API Gateway Policy Developer Guide.
Axway API Gateway 7.4.1
Security Guide 25
5 Configuration
Import certificates and keys to the trusted
certificate store
Certificates and key pairs can be imported into the API Gateway's trusted certificate store so that they can be used in trusted channel communications, signing and verifying data, encrypting and decrypting data, and so on.
Note
All private keys stored in the certificate store can be encrypted with the Entity Store passphrase.
For more information on the certificate store, see the API Gateway Policy Developer Guide. Certificates and keys can also be stored in a Hardware Security Module (HSM), for example, Thales nShield Solo or Safenet Luna SA. For more information on storing certificates and keys on a HSM, see the API Gateway Administrator Guide. API Gateway can also trust certificates in a Java keystore by adding the following line to the /system/conf/jvm.xml file:
<VMArg name=”-Djavax.net.ssl.trustStore=cacerts/jks"/>
Configure certificates for internal SSL
channels
After installing API Gateway, it is necessary to run the managedomain utility to create a topology (for example, groups and instances) in which the API Gateways will run. As part of this process, when instances are created, a number of certificates are created to use in mutually authenticated SSL channels between internal components (for example, Admin Node Manager and API Gateway instances).
Rather than using the default auto-generated certificates (that are signed by a domain-level CA certificate), you can use alternative, custom certificates that have been generated out of band using a PKI, for example.
The API Gateway Administrator Guide explains how to do this using the managedomain utility.
Axway PassPort integration
API Gateway can authenticate users against Axway PassPort, which provides a centralized, identity broker for enterprise solutions. For more information, see the API Gateway PassPort Interoperability Guide, and the Axway PassPort documentation available on Axway Sphere at https://support.axway.com.
Axway API Gateway 7.4.1
Security Guide 26
5 Configuration
Authentication
API Gateway supports a large range of authentication mechanisms and protocols, including HTTP basic and digest authentication, HTML form-based authentication, SSL, session-based authentication, SAML, WS-Security UsernameToken, Kerberos, and many more. For more information on these filters, see the API Gateway Policy Developer Guide.
API Gateway can also integrate with a number of third party Identity Management products to authenticate users, such as Axway PassPort, Entrust GetAccess, Oracle Entitlements Server, Oracle Access Manager, CA SiteMinder, RADIUS, RSA Access Manager, Sun Access Manager, Tivoli repositories, LDAP, database, Key Property Store (KPS), and the local user store. For more information on authentication repositories, see the API Gateway Policy Developer Guide.
Authorization
API Gateway also integrates with a number of third party Identity Management products to provide authorization services for end users. API Gateway can authorize clients against Axway PassPort, RSA Access Manager, CA SOA Security Manager, CA SiteMinder, Oracle Access Manager, Oracle Entitlements Server, Entrust GetAccess, Tivoli, and Sun Access Manager.
It also supports standard authorization schemes, including LDAB RBAC, SAML, SAML PDP, XACML, and X509 certificate attributes. OAuth 2.0 and OpenID Connect are also supported, and are discussed in the following section.
For details on how to configure these authorization services, see the API Gateway Policy Developer Guide.
OAuth and OpenID Connect
API Gateway can act as an OAuth authorization server by exposing OAuth token management endpoints, which are used by trusted clients to obtain access tokens. Resources exposed by the API Gateway can then use token validation filters to ensure calls can only be performed by authorized clients.
API Gateway can also expose OpenID Connect User Info standard endpoints and supports the generation of OpenID tokens when the openid scope is present in the OAuth token request.
See the API Gateway OAuth User Guide for more information on OAuth and OpenID Connect.
Message-level encryption and integrity
There are a number of different encryption filters available in API Gateway, for example, XML
Encryption, PGP Encrypt and Sign, and SMIME Encryption. Similarly, API Gateway can sign and verify messages using XML signature, SMIME, or PGP.
More information on these features is available in the API Gateway Policy Developer Guide.
Axway API Gateway 7.4.1
Security Guide 27
5 Configuration
Certificate validation
While the API Gateway's SSL stack will implicitly check the validity of a certificate in terms of its trusted certificate chain and expiry date, it is also possible to validate client certificates against a CRL, OCSP responder, or XKMS server. These additional validation mechanisms are especially useful in cases where the certificate is extracted from the message itself, rather than the SSL session.
See the API Gateway Policy Developer Guide for more information on these certificate validation mechanisms.
Entity Store passphrase
Sensitive data, such as passwords, private keys, and tokens, can be encrypted using the Entity Store passphrase. The data is encrypted using PBE with SHA1 and 3DES in CBC mode. To change the passphrase at any time, right-click on the Group in Policy Studio and select the Change
Passphrase option. For more information, see the API Gateway Administrator Guide.
Set Entity Store passphrase for automated
startup
If you are using an Entity Store passphrase and are starting API Gateway automatically as a service, you must store the passphrase in certain configuration files (see Sensitive files and databases on page 38).
It is crucial to maintain strict privileges so that only the user that installed API Gateway (or some other specific administrator user) can manually edit the Entity Store passphrase in the files. For more information on how to edit these files, see the API Gateway Administrator Guide.
Password policy
You can configure a password policy for administrator users in API Gateway Manager. You can configure the following rules for API Gateway administrator user passwords:
l Restrictions on account user name in password
l Restrictions on password length
l Restrictions on using passwords that are similar to passwords used previously
l How long a password is valid for
l The minimum number of uppercase, lowercase, numeric, and special characters a password must contain
For more details, see the API Gateway Administrator Guide. Axway API Gateway 7.4.1
Security Guide 28
5 Configuration
Signing the audit trail
An important aspect of maintaining the integrity of the product audit trail is the ability to sign audit records. API Gateway can sign audit data written to text files, XML files, and databases. For more details on how to sign transaction logs, see the API Gateway Administrator Guide.
HSM integration
API Gateway can offload private key storage and operations to a hardware security module (HSM) that has been installed on the host machine. Please refer to the following section in the product documentation for more details:
For more information on storing certificates and keys on a HSM, see the API Gateway Administrator Guide.
API firewalling configuration
API Gateway embeds Apache ModSecurity to protect the API traffic that goes through the API Gateway against common HTTP attacks, such as cross-site scripting, SQL injection, command injection, cross site request forgery, and many others. Apache ModSecurity is a toolkit for real-time HTTP traffic monitoring, logging, and access control.
For more information on configuring API firewalling, see the API Gateway Administrator Guide and the API Gateway Policy Developer Guide.
Policy Studio SSL settings
If Policy Studio is required to make outbound SSL connections, it must trust the server certificate for the SSL session to be established. For example, if Policy Studio must retrieve WSDLs over SSL, test database connections over SSL, and test a connection to an LDAP directory over SSL, it is necessary to trust the server certificate by importing it into Policy Studio's trusted certificate store.
For security reasons, Policy Studio will warn users about the following potential issues with the server's SSL certificate:
l Host name verification issues where the subjectAltName (SAN) or common name (CN) of the certificate does not match the host name in the requested URL.
l Where the certificate is self-signed
l Where the key size is less than 2048 bits
l Where the certificate has either expired or is not yet valid
Caution
It is strongly recommended that the administrator addresses these issues as soon as possible to prevent potential man-in-the-middle, spoofing, or eavesdropping attacks.
Axway API Gateway 7.4.1
Security Guide 29
5 Configuration
You can access the SSL settings by selecting the Window > Preferences > SSL Settings option in Policy Studio. For more information, see the API Gateway Policy Developer Guide.
Policy Studio Node Manager credentials
To ensure that only an administrator user can push policies to API Gateway instances, a configurable setting forces the administrator to enter a password every time a policy package is deployed. This setting is turned on by default, but can be turned off by selecting Window > Preferences >
Node Manager Credentials in Policy Studio. For more information, see the API Gateway Policy Developer Guide.
Set administrator password during
installation
In line with security best practices, the d efault behavior of the API Gateway installer is to force the user to set an administrator password during the installation process. See the API Gateway Installation Guide for more information.
Appliance Web Administration Interface SSL
certificate
The appliance can be configured remotely via the Web Administration Interface web-based interface, which is available at the following secure URL:
https://[APPLIANCE_HOST]:10000/
The server-side SSL certificate used here is only intended as a temporary certificate and is not recommended for use in a production environment. For more information on how to change this certificate, see the API Gateway Appliance Installation and Administration Guide.
FIPS mode
When running in FIPS mode, all cryptographic operations are performed by the embedded OpenSSL FIPS Object Module and the Entrust Authority™ Security Toolkit. Furthermore, the API Gateway runtime will disable cryptographic algorithms that are not FIPS compliant, such as DES and MD5.
The ability to operate in FIPS mode is determined by the type of license used for API Gateway. If a FIPS-enabled license is used, API Gateway can be configured to run in FIPS mode or standard mode. For more details on running API Gateway in FIPS mode, see the API Gateway Administrator Guide.
It is also possible to operate Policy Studio in FIPS mode. This enables FIPS-certified cryptographic modules and ensures that all cryptographic operations (for example, SSL) are performed by these modules. To enable FIPS mode, select Window > Preferences > FIPS Mode in Policy Studio.
Axway API Gateway 7.4.1
Security Guide 30
5 Configuration
FIPS compliance validation
You can check an API Gateway configuration for FIPS compliance using the FIPS Validation Tool in Policy Studio. It is available from the Tools > Check Security Constraints > FIPS menu option. For more information on running the tool, see the API Gateway Policy Developer Guide.
NIST SuiteB and SuiteB Top Secret
compliance validation
You can check an API Gateway configuration for Suite B and Suite B Top Secret compliance using the SuiteB/SuiteBTS Validation Tools in Policy Studio. These tools are available from the Tools >
Check Security Constraints > SuiteB and the Tools > Check Security Constraints >
SuiteBTS menu options. For more information on running these tools, see the API Gateway Policy Developer Guide.
Advisory banner
You can enable an advisory banner in API Gateway Manager, which displays when a user logs in to API Gateway Manager or Policy Studio.
For more information, see the API Gateway Administrator Guide.
API keys
API Manager enables you to generate and store API keys for client applications. API keys are stored in a Key Property Store (KPS) and can be managed using the API Manager web UI or the kpsadmin tool. Alternatively, you can also generate and store API keys for client applications using the Client Application Registry.
For more information on API key generation and storage, see the API Manager API Management Guide. For more information on the kpsadmin tool, see the API Gateway Key Property Store User Guide.
Audit events
API Gateway exposes an interface in API Gateway Manager that allows you to enable or disable different types of events, including authentication, SSL session establishment, external audit offload, and so on.
For more information, see the API Gateway Administrator Guide.
Axway API Gateway 7.4.1
Security Guide 31
5 Configuration
External audit offload
API Gateway offers the ability to offload domain and transaction logs to a remote audit server periodically.
For more information, see the API Gateway Administrator Guide. Secure by default configuration
Security best practices recommend that products are shipped secure-by-default to ensure that an out-of-the-box installation is not vulnerable to attacks. The following measures have been taken to ensure that API Gateway is secure-by-default:
l The default behavior of the API Gateway installer is to force the user to set an administrator password during installation.
l Administrator passwords are stored as a salted hash using 1024 iterations of PBKDF2 with HMACSHA1. The iterations and algorithm are not configurable.
l The installer sets permissions on the image so that only the user that installed the product can modify API Gateway files (for example, logs, traces, configuration, and so on).
l HTTPS interfaces are configured with secure cipher suites by default, for example, TLSv1.2 only, block SSLv3, FIPS compliant cipher suites only, no unauthenticated ciphers, an so on.
l All connections between internal server-side components (API Gateway and Node Manager) are secured by two-way SSL.
l Connections between Policy Studio and the Node Manager are secured by SSL.
l By default, the administrator user must enter a password for every policy package deployment. This can be turned off in the Policy Studio preferences.
l API Gateway seeds itself from /dev/random for all cryptographic operations, which is cryptographically more secure than using /dev/urandom.
Unless otherwise specified, all of these options can be turned off by an administrator user. For more information, see the API Gateway Policy Developer Guide and the API Gateway Administrator Guide.
Caution
Turning off secure-by-default configuration effectively makes API Gateway less secure.
Axway API Gateway 7.4.1
Security Guide 32
5 Configuration
Product certificates
The Windows installer for the product has been signed using the private key associated with the following certificate:
Owner
Issuer
Expiry
Owner: CN=Axway Inc, OU=Product Development, O=Axway Inc, L=Phoenix, ST=Arizona, C=US
Issuer: CN=Thawte Code Signing CA - G2, O="Thawte, Inc.", C=US
Valid from: Fri Dec 12 00:00:00 GMT 2014 until: Mon Dec 11 23:59:59 GMT 2017
The product ships with its own JCE provider for interfacing to hardware security modules (HSMs) in a generic manner. This provider is signed with the private key that corresponds to the public key in the following certificate:
Owner
Issuer
Expiry
Owner: CN=Axway, OU=Java Software Code Signing, O=Sun Microsystems Inc
Issuer: CN=JCE Code Signing CA, OU=Java Software Code Signing, O=Sun Microsystems Inc, L=Palo Alto, ST=CA, C=US
Valid from: Tue Feb 12 00:53:53 GMT 2013 until: Fri Feb 16 00:53:53 GMT 2018
The following table lists the sample certificates with private keys that are shipped with the product. These certificates are for test purposes only and must be replaced with production-ready certificates for a production environment.
Sample certificate CN
Issuing CA
Expires
Change this for production
Change this for production
1st October, 2037
Samples Test CA
Samples Test CA
10th January, 2037
Samples Test Certificate
Samples Test CA
10th January
The following table lists the product-specific CA certificates that ship with the API Gateway's trusted certificate store. The other default CA certificates in the certificate store are populated from the cacerts trust store in the JRE that is bundled with the product.
CA common name
Issuing CA
Expires
AxwayRootCA
AxwayRootCA
23rd August, 2042
To authenticate the product using SSL with other internal components, a domain certificate is generated using the managedomain utility. This certificate is then used to sign the auto-generated per-instance certificates used in SSL communications between internal components, for example, an API Gateway instance and an Admin Node Manager. Axway API Gateway 7.4.1
Security Guide 33
5 Configuration
While not necessary, you can change these certificates to more suitable enterprise level CA-signed certificates, where available. The API Gateway Administrator Guide describes how to use the managedomain utility to do this.
The following output shows the process whereby an initial domain-level key pair is generated for the Admin Node Manager: Generating domain private key and certificate...
Generating private key...
Generating CSR for key...
Signing certificate for CSR...
Converting PEM files to P12...
Generating Node Manager private key and certificate...
Generating private key...
Generating CSR for key...
Signing certificate for CSR...
Converting PEM files to P12...
New Node Manager SSL certificate details:
dname: CN=nodemanager-1,OU=group-1,DC=host-1
expires: Sat Sep 22 12:13:04 BST 2114
thumbprint: 7A:FE:7F:C0:D2:81:C6:39:F8:6C:FC:15:69:27:B9:E6:B1:ED:DC:09
issuer dname: CN=Domain
issuer thumbprint: FD:E9:7B:7C:DC:47:9E:A6:6A:93:C2:A2:52:CE:3A:46:3C:CE:0C:A8
Completed successfully.
You may now start the Node Manager on your newly registered host.
The system has placed your domain private key into directory 'C:\nightly\15_10_
14\apigateway\groups\certs\private'. Plea
se backup and protect the contents of this directory.
Whenever a new API Gateway instance is created (using the create_instance command), the instance’s SSL certificate is signed by the domain level Admin Node Manager's SSL certificate that was generated in the sequence shown above.
> create_instance name Server1 group Group1
Requesting CSR from Admin Node Manager...
CSR received from Admin Node Manager.
Requesting signed certificate from Admin Node Manager...
Signed certificate received from Admin Node Manager.
Requesting Admin Node Manager to create new API Gateway...
New API Gateway SSL certificate details:
dname: CN=instance-1,OU=group-2,DC=host-1
expires: Sat Sep 22 12:20:13 BST 2114
thumbprint: 67:76:D5:F7:A2:C5:64:10:40:75:85:4D:97:F5:CF:1A:8E:43:B0:CE
issuer dname: CN=Domain
issuer thumbprint: FD:E9:7B:7C:DC:47:9E:A6:6A:93:C2:A2:52:CE:3A:46:3C:CE:0C:A8
The new API Gateway 'Server1' in group 'Group1' has been successfully created and
installed
For a more detailed explanation of the options available with the managedomain utility, including how to use your own certificates for internal SSL/TLS channels between internal components, see the API Gateway Administrator Guide.
Axway API Gateway 7.4.1
Security Guide 34
6 Security best practices
When using this product, follow these security best practices.
Secure connections
As stated earlier, all connections between internal components (API Gateways and Node Managers) are secured by mutual authentication. Best practices would recommend securing all connections to external networks with mutual authentication, where that is supported by the back-end service.
Similarly, where API Gateway is receiving messages over various protocols, it makes a lot of sense to ensure that these connections are mutually authenticated where possible.
Policy Studio has a configurable setting that determines whether or not the administrator must enter a password on every deploy action. This option is enabled by default and it is recommended to leave it this way. Sample certificates
Axway provides sample certificates with the product. These sample certificates and key pairs can be found in the API Gateway's trusted certificate store and should be used for test purposes only. As soon as the product goes live, or as soon as real data is managed by the product, you must use your own certificates. Using sample certificates is a security risk as all API Gateway customers have the same certificates with the same private keys.
Self-signed certificates
Using self-signed certificates may also be a security risk for many reasons, including:
l Anyone can generate his own certificate and you need a very secure process to receive/send these certificates to make sure they are coming from the right partner. When using CA-signed certificates, you can rely on the CA.
l If self-signed certificates are not securely stored, anyone can change them. CA-signed certificates also must be securely stored, but no one can change them.
l There is no way to revoke self-signed certificates.
Axway API Gateway 7.4.1
Security Guide 35
6 Security best practices
Privileged access user list
The API Gateway installer sets access rights on its files so that only the user that installed the image can read or modify files. This means that only the API Gateway itself can access its log, trace, and configuration files.
Care must be taken to maintain and limit the users that have privileged access to the machine on which API Gateway is running. At a minimum, maintain a list of administrators and a list of users with access to multiple functions.
Internet access limitation
As much as possible, limit the number of internet access points. Do not open useless Internet connections and limit interconnections with external networks as much as possible. This limits the product’s attack surface and reduces the risk of external attacks and makes it easier to audit the product.
For a list of default ports that are opened by the product components, see the API Gateway Installation Guide.
Correct upgrade procedure
In the event of a possible vulnerability discovered in the product, you must be able to apply the patch or new Service Pack as soon as possible. Make sure you have the correct procedure to complete the upgrade. Always use the latest version of the product, if possible, as it contains fixes to known vulnerabilities.
System level patches for the appliance are typically made available on a zypper repository, while software updates are usually distributed via support channels.
For more information on upgrade procedures, see the following documents:
l API Gateway Appliance: API Gateway Appliance Installation and Administration Guide
l API Gateway software: API Gateway Installation Guide
Generic or anonymous users
The term “generic users” means that the password is shared among multiple specific users. This makes it easier for an attacker to retrieve this password. In addition, the procedure to change shared passwords can be complicated and risky. In case of an incident, these generic or anonymous users make it impossible to determine who completed the erroneous action.
Axway API Gateway 7.4.1
Security Guide 36
6 Security best practices
In cases where multiple administrator users are responsible for configuring policies (via Policy Studio) to run on API Gateway, it makes a lot of sense to create distinct users for each administrator user. Password policy
In line with security best practices, you can configure a password policy for administrator users in API Gateway Manager. Password policy refers to the size and complexity of the password, as well as to all the rules to manage the password. For more information on setting the password policy for administrator users, see the API Gateway Administrator Guide.
It is also possible to take certain actions when a configurable number of invalid authentication attempts has occurred via HTTP basic, HTTP digest, and HTML form-based authentication. For example, you can lock a user account, or ban an IP address if a certain number of invalid passwords have been submitted to API Gateway.
Note
This password policy only applies to administrator user account passwords that are managed by API Gateway. These passwords are encrypted using the Entity Store passphrase, which uses PBE with SHA1 and 3DES in CBC mode. In some cases, API Gateway must store passwords in order to connect to third party Identity Management products, databases, LDAP servers, and so on. The responsibility for implementing password policy in these cases rests on the administrator of the third party product. Default authentication account
The default behavior of the software version of the product is to force you to set an administrator password during installation.
With the appliance version, a new administrator user must be created the first time the managedomain script is run to create the domain. For more instructions on how to do this, see the API Gateway Appliance Installation and Administration Guide.
Remote connections
You should limit your remote connections in the following ways:
l If no one needs to access the product remotely, make sure that the UI ports are closed in your firewall.
l If someone needs to connect remotely only occasionally, set a procedure to open the port only on demand.
l Do not turn off the secure-by-default measures already taken for the internal components of the product, for example, API Gateway, Admin Node Manager, and Policy Studio.
Axway API Gateway 7.4.1
Security Guide 37
6 Security best practices
Logging, audit, and alerts rules
An important aspect of security is to be notified when something wrong occurs, and to be able to investigate it. Therefore, it is important to define the right level of logging and audit, and to set the right alerts.
API Gateway can log audit and monitoring data to the following locations:
l Axway Sentinel
l Local text file
l Local XML file
l Database l Local syslog
l Remote syslog
l System console
l Apache Access log file
Events can be audited at different levels, for example, success, failure, or abort. The audit trails written to the local text file, local XML file, and database can all be signed to ensure integrity.
The product can also send the following types of alerts under certain configurable error conditions:
l Email messages
l OPSEC alerts
l SNMP trap
l Local and remote syslog
l Windows event log
l Amazon SNS
l Twitter feed
See the API Gateway Administrator Guide for more information on configuring logging and alerting in API Gateway.
Sensitive files and databases
You must ensure that the default protection mechanisms on sensitive files used by API Gateway remain in place. For example, the product’s files are installed with read, update, and delete privileges such that only the product can access them by default. There should be no reason to change these privileges.
The following files are deemed sensitive from a security perspective, where GROUP and INSTANCE placeholders represent the identifiers (for example, group-2, instance-1, and so on) of the group in a multigroup and a multi-instance domain, respectively.
Axway API Gateway 7.4.1
Security Guide 38
6 Security best practices
Node Manager Entity Store
The files located in the following directory comprise the configuration for the Node Manager:
/conf/fed
API Gateway Entity Store
The files in the following directory, where [ID] represents the policy package ID, make up the main configuration for API Gateway. /groups/[GROUP}/conf/[ID]
As stated earlier, an encryption passphrase can be used to encrypt sensitive data in the Entity Store, including private keys, passwords, and tokens.
Administrator passwords
The following file contains the hashed passwords of administrator users that have the ability to configure the product. /conf/adminUsers.json
The passwords are stored as a salted hash derived from 1024 iterations of the PBKDF2 algorithm with Hmac SHA-1. Each password uses a different salt so that identical passwords result in different stored hashes.
Key Property Store
If you have configured the product to store data in a Key Property Store (KPS), the files located in the following directory must be protected:
/groups/[GROUP]/[INSTANCE]/Communion/kps
Automated startup files
In cases where API Gateway must be started automatically without manual intervention it is necessary to store the Entity Store encryption passphrase (when used) in certain configuration files, which are as follows:
/groups/[GROUP]/[INSTANCE]/conf/service.xml
/system/conf/nodemanager.xml
/skel/service.xml
If you configure a password executable file for use with managedomain (see the API Gateway Administrator Guide for details), it is important to protect the following file:
/conf/managedomain.props
You should also protect the password executable file specified by the password_exec parameter in the managedomain.props file.
Axway API Gateway 7.4.1
Security Guide 39
6 Security best practices
API firewalling rule set
API Gateway embeds Apache ModSecurity; a toolkit for real-time HTTP traffic monitoring, logging, and access control; to help companies mitigating application-level threats on their APIs. The embedded ModSecurity engine looks for threat protection rules configuration in the /system/conf/threat-protection/default directory. This directory and the files within it must be protected.
Audit, trace, and log files
In terms of audit trail data written out by the API Gateway, it is important to protect the following files and directories from modification or deletion:
/logs
/trace
/groups/[GROUP]/[INSTANCE]/logs
/groups/[GROUP]/[INSTANCE]/trace
You should also protect any custom logging files if a non-default location has been configured.
In general, it is good practice to limit the number of administrators with access to the product. For the API Gateway Appliance in particular, it makes sense to restrict the number of users with SSH access to the physical device.
Axway API Gateway 7.4.1
Security Guide 40
Appendix A: Compliant
configuration settings for Policy
Studio
Policy Studio ships with a useful tool that allows you to scan a configuration and identify items that do not comply with the FIPS, Suite B, and Suite B Top Secret security standards. For example, if you have a large configuration where the non-FIPS algorithm MD5 has been selected, you can run the FIPS Compliance Validation Tool to identify all occurrences of this algorithm. You can click on the warning message in the report to jump directly to the offending configuration item. Using the details in this topic, you can quickly enter or select a compliant algorithm or cipher suite to be FIPS compliant.
While running in FIPS mode, the runtime blocks any attempts to use non-FIPS compliant algorithms. The Compliance Validation Tool should be used before a configuration is deployed to identify potential problems at configuration time rather than waiting to diagnose runtime errors.
Abbreviations
Abbreviation
Meaning
FIPS
Federal Information Processing Standards
SB S
Suite B Secret
SB TS
Suite B Top Secret
NIST
National Institute of Standards and Technology
Axway API Gateway 7.4.1
Security Guide 41
Appendix A: Compliant configuration settings for Policy Studio
HTTPS interface, SMTP interface, ICAP server,
Connection filter, Connect to URL filter
The following ciphers are compliant.
Field
FIPS
Suite B
Suite B TS
Ciphers (Advanced SSL Tab)
FIPS
ECDHE-ECDSA-AES128-GCMSHA256:ECDHE-ECDSA-AES128SHA256:ECDHE-ECDSA-AES128SHA
ECDHE-ECDSA-AES256-GCMSHA384:ECDHE-ECDSA-AES256SHA384:ECDHE-ECDSA-AES256SHA
ECDHE-ECDSA-AES128-GCMSHA256:ECDHE-ECDSA-AES128SHA256
ECDHE-ECDSA-AES256-GCMSHA384:ECDHE-ECDSA-AES256SHA384
FIPS:!SSLv3
FIPS:!SSLv3:!aNULL
FIPS
Note
The default ciphers macro of “FIPS:!SSLv3:!aNULL”:
l Enables FIPS-compatible cipher suites only
l Explicitly blocks cipher suites that require SSLv3 or lower l Forces the use of TLSv1.2 only
l Forbids unauthenticated cipher suites
The following table shows the SSL/TLS protocol version, key exchange, authentication, encryption, and MAC algorithms that are used by each supported cipher suite.
Cipher Suite
SSL
Kx
Auth
Enc
MAC
ECDHE-RSA-AES256-GCM-SHA384
TLSv1.2
ECDH
RSA
AESGCM(256)
AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 ECDH
ECDSA
AESGCM(256)
AEAD
ECDHE-RSA-AES256-SHA384 TLSv1.2
ECDH
RSA
AES(256)
SHA384
ECDHE-ECDSA-AES256-SHA384 TLSv1.2
ECDH
ECDSA
AES(256)
SHA384
DHE-DSS-AES256-GCM-SHA384 TLSv1.2
DH
DSS
AESGCM(256)
AEAD
DHE-RSA-AES256-GCM-SHA384
TLSv1.2
DH
RSA
AES(256)
SHA256
DHE-RSA-AES256-SHA256 TLSv1.2
DH
RSA
AES(256) SHA256
DHE-DSS-AES256-SHA256 TLSv1.2
DH
DSS
AES(256)
SHA256
Axway API Gateway 7.4.1
Security Guide 42
Appendix A: Compliant configuration settings for Policy Studio
Cipher Suite
SSL
Kx
Auth
Enc
MAC
ECDH-RSA-AES256-GCM-SHA384 TLSv1.2
ECDH/RSA
ECDH
AESGCM(256)
AEAD
ECDH-ECDSA-AES256-GCM-SHA384 TLSv1.2
ECDH/ECDSA
ECDH
AESGCM(256)
AEAD
ECDH-RSA-AES256-SHA384 TLSv1.2
ECDH/RSA
ECDH
AES(256)
SHA384
ECDH-ECDSA-AES256-SHA384 TLSv1.2
ECDH/ECDSA
ECDH AES(256)
SHA384
AES256-GCM-SHA384 TLSv1.2
RSA
RSA AESGCM(256)
AEAD
AES256-SHA256 TLSv1.2
RSA
RSA
AES(256) SHA256
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2
ECDH
RSA
AESGCM(128)
AEAD
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2
ECDH
ECDSA
AESGCM(128)
AEAD
ECDHE-RSA-AES128-SHA256 TLSv1.2
ECDH
RSA
AES(128)
SHA256
ECDHE-ECDSA-AES128-SHA256 TLSv1.2
ECDH/ECDSA
ECDH
AES(128)
SHA256
DHE-DSS-AES128-GCM-SHA256 TLSv1.2
DH
DSS
AESGCM(128)
AEAD
DHE-RSA-AES128-GCM-SHA256 TLSv1.2
DH
RSA
AESGCM(128)
AEAD
DHE-RSA-AES128-SHA256 TLSv1.2
DH
RSA
AES(128)
SHA256
DHE-DSS-AES128-SHA256 TLSv1.2
DH
DSS
AES(128)
SHA256
ECDH-RSA-AES128-GCM-SHA256
TLSv1.2
ECDH/RSA
ECDH
AESGCM(128)
AEAD
ECDH-ECDSA-AES128-GCM-SHA256
TLSv1.2
ECDH/ECDSA
ECDH
AESGCM(128)
AEAD
ECDH-RSA-AES128-SHA256
TLSv1.2
ECDH/RSA
ECDH
AES(128)
SHA256
ECDH-ECDSA-AES128-SHA256
TLSv1.2
ECDH/ECDSA
ECDH
AES(128)
SHA256
AES128-GCM-SHA256 TLSv1.2
RSA
RSA
AESGCM(128)
AEAD
AES128-SHA256 TLSv1.2
RSA
RSA
AES(128)
SHA256
Suite B
The following cipher suites are Suite B compliant.
Axway API Gateway 7.4.1
Security Guide 43
Appendix A: Compliant configuration settings for Policy Studio
Cipher Suite
SSL
Kx
Auth
Enc
MAC
ECDHE-ECDSA-AES128-GCM-SHA256
TLSv1.2
ECDH
ECDSA
AESGCM(128)
AEAD
ECDHE-ECDSA-AES128-SHA256 TLSv1.2 ECDH
ECDSA
AES(128)
SHA256
ECDHE-ECDSA-AES128-SHA SSLv3
ECDH
ECDSA
AES(128)
SHA1
The Validation Tool will consider the following cipher strings as compliant:
l ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256
l ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES128SHA
Note
The ECDHE-ECDSA-AES128-SHA cipher suite uses the SSLv3 protocol and is therefore not recommended.
Suite B TS
The following cipher suites are Suite B TS compliant.
Cipher Suite
SSL
Kx
Auth
Enc
MAC
ECDHE-ECDSA-AES256-GCM-SHA384
TLSv1.2
ECDH
ECDSA
AESGCM(256)
AEAD
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 ECDH
ECDSA
AES(256)
SHA384
ECDHE-ECDSA-AES256-SHA SSLv3
ECDH
ECDSA
AES(256)
SHA1
The Validation Tool will consider the following cipher strings as compliant:
l ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384
l ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256SHA
Note
The ECDHE-ECDSA-AES256-SHA cipher suite uses the SSLv3 protocol and is therefore not recommended.
JMS service – Active MQ
It is possible to select any number of the ciphers listed in the FIPS column, which means that JMS service supports all the selected ciphers.
Axway API Gateway 7.4.1
Security Guide 44
Appendix A: Compliant configuration settings for Policy Studio
Field
FIPS
Suite B
Suite B TS
Cipher suite
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
Not compliant as all ciphers in CBC mode.
Not compliant as all ciphers in CBC mode.
SSL_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_DHE_
DSS_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_
ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHATLS_ECDHE_
ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS_
ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_
ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA TLS_
ECDH_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA TLS_RSA_
WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
JMS service – IBM MQ
The IBM MQ provider only allows you to select one of the following FIPS-compliant ciphers.
Field
FIPS
Suite B
Suite B TS
Cipher suite
SSL_RSA_WITH_3DES_EDE_CBC_SHA
Not compliant as all ciphers in CBC mode.
Not compliant as all ciphers in CBC mode.
SSL_RSA_WITH_AES_128_CBC_
SHA256SSL_RSA_WITH_AES_256_CBC_
SHA256
Embedded Active MQ
See JMS service – Active MQ on page 44.
PGP Encrypt and Sign
The following symmetric key encryption and hash algorithms are compliant.
Axway API Gateway 7.4.1
Security Guide 45
Appendix A: Compliant configuration settings for Policy Studio
Field
FIPS
Suite B
Suite B TS
Symmetric Key Algorithm
AES128
N/A
N/A
SHA256
SHA384
AES192
AES256
CAST5
TRIPLE_DES
HASH Algorithm
SHA1
SHA224
SHA256
SHA384
SHA512
Suite B and Suite B TS
Despite the fact that the PGP Encrypt filter supports the Suite B and Suite B TS symmetric block ciphers AES256 and AES384, the PGP specification mandates the use of CFB (Cipher FeedBack) mode for symmetric encryption. Since the NIST recommendation states that GCM is the preferred mode, the PGP Encrypt filter cannot be Suite B compliant.
XML Encryption filter, XML Encryption
Settings filter, XML Decryption, XML
Decryption Settings filter
FIPS
All algorithms available on the XML Encryption Settings filter are FIPS compliant.
Suite B and Suite B TS
The XML Encryption filter supports the XML Encryption 1.0 specification, which only supports symmetric ciphers in CBC (Cipher Block Chaining) mode, whereas Suite B requires GCM (Galois Counter Mode). The XML Encryption support is, therefore, not Suite B compliant. Axway API Gateway 7.4.1
Security Guide 46
Appendix A: Compliant configuration settings for Policy Studio
XML Signature Generation filter
FIPS
All algorithms available on the XML Signature Generation filter are FIPS compliant.
Suite B and Suite B TS
Symmetric signatures are not Suite B compliant because the required key wrap algorithms use 3DES or AES in CBC mode.
The following asymmetric Signature Methods are compliant.
Field
Suite B
Suite B TS
Signature Method
EcdsaSha256
EcdsaSha384
Digest Algorithm
Sha256
Sha384
XML Signature Verification filter
FIPS
The filter is FIPS compliant for verification of all XML Signatures.
Suite B and Suite B TS
The XML Signature Verification filter uses the WS-SecurityPolicy-based Algorithm Suite configuration setting to mandate the crypto algorithms used on the XML Signature it is verifying. These algorithms are not compliant because:
l Suite B requires the Signature Method to be ECDSAwithSHA256 or ECDSAwithSHA384, but only RsaSha1 is supported by the WS-SecurityPolicy algorithms.
l Only the SHA1 and SHA256 digest algorithms are supported by the Algorithm Suites, neither of which are Top Secret compliant.
l The algorithm suites mandate the use of KwRsa15 or KwRsaOaep, which both use 3DES or AES in CBC mode.
Axway API Gateway 7.4.1
Security Guide 47
Appendix A: Compliant configuration settings for Policy Studio
KeyInfo configuration
The KeyInfo configuration is available on several filters, for example, XML Signature Generation, XML Encryption Settings, SAML Attribute/Authentication/Authorization Assertion Validation filters.
The following Security Token Reference mechanisms all use SHA1 and are not Suite B or Suite B TS compliant: l EncryptedKeySHA1
l ThumbprintSHA1
l Kerberosv5APREQSHA1
Create Thumbprint filter
FIPS
All available digest algorithms are FIPS compliant.
Suite B
You must select SHA-256 to be compliant.
Suite B TS
You must select SHA-384 to be compliant.
SMIME Encrypt filter
Any one of the following ciphers can be entered in the Cipher field to be compliant.
Axway API Gateway 7.4.1
Security Guide 48
Appendix A: Compliant configuration settings for Policy Studio
Field
FIPS
Suite B
Suite B TS
Cipher (Advanced Tab)
AES-128-CBC
id-aes128-GCM
id-aes256-GCM
AES-128-CFB
aes-128-gcm
aes-256-gcm
AES-128-CFB1
AES-128-CFB8
AES-128-CTR
AES-128-ECB
AES-128-GCM
AES-128-OFB
AES-128-XTS AES-192-CBC
AES-192-CFB
AES-192-CFB1
AES-192-CFB8
AES-192-CTR
AES-192-ECB
AES-192-GCM
AES-192-OFB
AES-256-CBC
AES-256-CFB
AES-256-CFB1
AES-256-CFB8
AES-256-CTR
AES-256-ECB
AES-256-GCM
AES-256-OFB
AES-256-XTS
AES128 AES192
AES256
DES-EDE3
DES-EDE3-CBC
DES-EDE3-CFB
DES-EDE3-CFB1
DES-EDE3-CFB8
DES-EDE3-OFB
DES3 id-aes128-GCM
id-aes192-GCM
id-aes256-GCM
Axway API Gateway 7.4.1
Security Guide 49
Appendix A: Compliant configuration settings for Policy Studio
SMIME Decrypt filter
It is not possible to tell at configuration time if this filter is not compliant because the algorithm used to encrypt the message is encapsulated in a PKCS#7 structure as the value of the keyEncryptionAlgorithm parameter. It is important to note that the API Gateway runtime will block any non FIPS compliant algorithms. See the table in the SMIME Encrypt filter on page 48 for a complete list of compliant algorithms.
SMIME Sign filter
FIPS
The SMIME Sign Filter uses SHA-1 internally to sign messages. This algorithm is not configurable, but is FIPS compliant.
Suite B and Suite B TS
Because SHA-1 is not Suite B compliant and this algorithm is not configurable, the SMIME Sign filter is not Suite B or Suite B TS compliant.
SMIME Verify filter
The SMIME Verify filter assumes the use of SHA-1 and so is FIPS compliant, but not Suite B or Suite B TS compliant.
HTTP Digest Authentication filter
The HTTP Digest Authentication specification mandates the use of MD5 to digest the user name and password sent up in the HTTP Authorization header. Therefore, it is not FIPS, Suite B, or Suite B TS compliant.
Scripting filter
Custom scripting code is not covered by this tool and must be scanned manually.
Axway API Gateway 7.4.1
Security Guide 50
Appendix A: Compliant configuration settings for Policy Studio
WS-Security Username Authentication
The WSS Username specification mandates the use of SHA-1 to digest the user’s password.
Section 3.1 Usernames and Passwords states:
Passwords of type PasswordDigest are defined as being the Base64 encoded, SHA-1 hash value, of the UTF8 encoded password (or equivalent). However, unless this digested password is sent on a secured channel or the token is encrypted, the digest offers no real additional security over use of wsse:PasswordText. Kerberos settings
FIPS
If the krb5.conf file contains a default_tgs_enctypes property with any of the following values, it is not FIPS compliant:
l des-cbc-md5
l des-cbc-crc
l rc4-hmac
Suite B and Suite B TS
Kerberos encryption algorithms are not Suite B or Suite B TS compliant.
Kerberos Service Authentication
FIPS
It is not possible to tell at configuration time if a Kerberos Service Authentication configuration item is FIPS compliant since it depends on the algorithms negotiated at runtime.
Suite B and Suite B TS
No Kerberos Service Authentication configuration is Suite B compliant because the required algorithms are not supported.
Axway API Gateway 7.4.1
Security Guide 51
Appendix A: Compliant configuration settings for Policy Studio
SiteMinder SMHost configuration
FIPS
If the SiteMinder SMHost.conf file contains one of the following prefixes on the value of the sharedsecret property, it is not FIPS compliant:
l {RC4}
l {RC2}
l {DES}
Suite B and Suite B TS
The SiteMinder configuration is not Suite B compliant since the required algorithms are not supported.
Database Authentication Repository
FIPS
The Hash Algorithm (used to hash the client's password) cannot be set to MD5 since this algorithm is not FIPS compliant.
Suite B and Suite B TS
The Database Authentication Repository is not Suite B compliant if you have elected to hash passwords by checking the Hash client password radio button since neither MD5 or SHA1 are Suite B compliant.
Axway API Gateway 7.4.1
Security Guide 52
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement