The Target of Evaluation (TOE) is the Fortra’s GoAnywhere Managed File Transfer v6.8 (MFT). The TOE is a software application that provides secure file transfer services over HTTPS, TLS, and SSH. GoAnywhere MFT is a secure managed file transfer solution that streamlines the exchange of data between systems, employees, customers, and trading partners. It provides centralized control with extensive security settings, detailed audit trails, and helps process information from files into XML, CSV, and JSON databases.
","evaluation_configuration":"The TOE has been evaluated on the following host platforms:
\r\n· CentOS 7 on ESXi 6.7 with Intel Xeon E5-4620v4 (Broadwell)
\r\n· Windows Server 2016 on ESXi 6.7 with Intel Xeon E5-4620v4 (Broadwell)
\r\nNote: The TOE is the application software only. The host platforms are not part of the evaluation.
\r\nThe TOE supports (sometimes optionally) secure connectivity with several other IT environment devices as described below.
\r\n| \r\n Environment | \r\n\r\n Required \r\n | \r\n\r\n Usage/Purpose Description \r\n | \r\n
| \r\n Web Browser \r\n | \r\n\r\n Yes \r\n | \r\n\r\n Remote administration and User file access over HTTPS/TLSv1.2. \r\n | \r\n
| \r\n Database Server \r\n | \r\n\r\n Yes \r\n | \r\n\r\n MySQL, PostgreSQL, MS SQL Server, Oracle, or DB2/400 for storing settings. The server must support TLSv1.2 to enable secure access by the TOE. \r\n | \r\n
| \r\n LDAP/AD Server \r\n | \r\n\r\n No \r\n | \r\n\r\n Remote authentication server supporting TLSv1.2. \r\n | \r\n
| \r\n Mail Server \r\n | \r\n\r\n No \r\n | \r\n\r\n Mail server supporting SMTP over TLSv1.2 for sending notifications. \r\n | \r\n
| \r\n File Server \r\n | \r\n\r\n No \r\n | \r\n\r\n Remote file server for storing user files: \r\n· AS2, AS4, or WebDAV servers supporting HTTPS/TLSv1.2 \r\n· SFTP or SCP servers supporting SSHv2 \r\n· FTP/s servers supporting TLSv1.2 \r\n· Amazon S3 or Azure Blob Storage supporting HTTPS/TLSv1.2 \r\n· REST, SOAP, or generic HTTPS/TLSv1.2 server \r\n | \r\n
| \r\n File Transfer Client \r\n | \r\n\r\n No \r\n | \r\n\r\n Client allowing users to store and retrieve files from the TOE: \r\n· AS2 or AS4 clients supporting HTTPS/TLSv1.2 \r\n· SFTP or SCP clients supporting SSHv2 \r\n· FTP/s client supporting TLSv1.2 \r\n | \r\n
| \r\n Java Runtime Environment \r\n | \r\n\r\n Yes (on CentOS) \r\n | \r\n\r\n Platform-provided Java SE 8 Java Runtime Environment (JRE). \r\nNote: The Windows platform does not provide a JRE, so the Windows version of the TOE includes the required JRE. \r\n | \r\n
","security_evaluation_summary":"
The evaluation was carried out in accordance with the Common Criteria Evaluation and Validation Scheme (CCEVS) process and scheme. The criteria against which the Fortra’s GoAnywhere Managed File Transfer v6.8 was evaluated are described in the Common Criteria for Information Technology Security Evaluation, Version 3.1 rev 5.The evaluation methodology used by the evaluation team to conduct the evaluation is the Common Methodology for Information Technology Security Evaluation, Version 3.1 rev 5.Acumen Security determined that the evaluation assurance level (EAL) for the product is EAL 1.The product, when configured as identified in the Fortra’s GoAnywhere Managed File Transfer v6.8 AGD, satisfies all of the security functional requirements stated in the Common Criteria Configuration Guide for Fortra’s GoAnywhere Managed File Transfer v6.8 Security Target. The project underwent CCEVS Validator review.The evaluation was completed in April 2023.Results of the evaluation can be found in the Common Criteria Evaluation and Validation Scheme Validation Report prepared by CCEVS.
","environmental_strengths":"The TOE provides the security functionality required by [SWAPP], [TLS-PKG], and [SSH-EP].
\r\nThe TOE utilizes the GoAnywhere MFT Bouncy Castle FIPS Java API cryptographic library version 1.0.2. This library implements all of the cryptographic algorithms required for SSH and TLS, drawing entropy from the platform RBG.
\r\nThe cryptographic services provided by the TOE are described below:
\r\n| \r\n Cryptographic Protocol \r\n | \r\n\r\n Use within the TOE \r\n | \r\n
| \r\n SSHv2 Client \r\n | \r\n\r\n File server transfers using SFTP or SCP \r\n | \r\n
| \r\n SSHv2 Server \r\n | \r\n\r\n User file transfers using SFTP or SCP \r\n | \r\n
| \r\n HTTPS/TLSv1.2 Client \r\n | \r\n\r\n File server transfers using AS2, AS4, WebDAV, FTP/s, Amazon S3, Azure Blob Storage, REST, SOAP, or HTTPS; Check for updates \r\n | \r\n
| \r\n HTTPS/TLSv1.2 Server \r\n | \r\n\r\n HTTPS Remote administration; HTTPS file access; AS2 or AS4 clients \r\n | \r\n
| \r\n TLSv1.2 Client \r\n | \r\n\r\n Database server; Authentication Server; Mail Server; \r\n | \r\n
| \r\n TLSv1.2 Server \r\n | \r\n\r\n User file transfers using FTP/s \r\n | \r\n
Table 3 TOE Provided Cryptography
\r\nEach of these cryptographic algorithms have been validated for conformance to the requirements specified in their respective standards, as identified below.
\r\n| \r\n SFR \r\n | \r\n\r\n Algorithm in ST \r\n | \r\n\r\n CAVP Alg. \r\n | \r\n\r\n CAVP Cert # \r\n | \r\n
| \r\n FCS_CKM.1 \r\n | \r\n\r\n RSA schemes using cryptographic key sizes of 2048-bit or greater that meet the following: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.3 \r\n | \r\n\r\n RSA KeyGen (n = 2048, 3072) \r\n | \r\n\r\n C1876 \r\n | \r\n
| \r\n ECC schemes using “NIST curves” [selection: P-256, P-384, P-521] that meet the following: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.4 \r\n | \r\n\r\n ECDSA KeyGen (Curve = P-256, P-384, P-521) \r\n | \r\n\r\n C1876 \r\n | \r\n|
| \r\n FFC Schemes using Diffie-Hellman group 14 that meet the following: RFC 3526, Section 3 \r\n | \r\n\r\n NIAP Policy Letter #5, Addendum #2, states “No NIST CAVP, CCTL must perform all assurance/evaluation activities”. \r\n | \r\n\r\n Vendor Affirmed. \r\n | \r\n|
| \r\n FCS_CKM.2 \r\n | \r\n\r\n RSA-based key establishment schemes that meet the following: RSAES-PKCS1-v1_5 as specified in Section 7.2 of RFC 8017, “Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1” \r\n | \r\n\r\n NIAP Policy Letter #5, Addendum #2, states “No NIST CAVP exists, must be described in TSS – See FIPS 140-2 I.G. D.4: Vendor Affirmation”. \r\n | \r\n\r\n Vendor Affirmed. \r\n | \r\n
| \r\n Elliptic curve-based key establishment schemes that meet the following: NIST Special Publication 800-56A Revision 2, “Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography” \r\n | \r\n\r\n KAS-ECC \r\n(Curve = P-256, P-384, P-521) \r\n | \r\n\r\n C1876 \r\n | \r\n|
| \r\n Key establishment scheme using Diffie-Hellman group 14 that meets the following: RFC 3526, Section 3 \r\n | \r\n\r\n NIAP Policy Letter #5, Addendum #2 does not provide any guidance for this selection. \r\n | \r\n\r\n Vendor Affirmed. \r\n | \r\n|
| \r\n FCS_COP.1/ DataEncryption \r\n | \r\n\r\n AES used in [CBC, GCM] mode and cryptographic key sizes [128 bits, 256 bits] \r\n | \r\n\r\n AES-CBC (128-bit, 256-bit) \r\nAES-GCM (128-bit, 256-bit) \r\n | \r\n\r\n C1876 \r\n | \r\n
| \r\n FCS_COP.1/ SigGen \r\n | \r\n\r\n For RSA schemes: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 5.5, using PKCS #1 v2.1 Signature Schemes RSASSA-PSS and/or RSASSA-PKCS1v1_5; ISO/IEC 9796-2, Digital signature scheme 2 or Digital Signature scheme 3 \r\n | \r\n\r\n RSA SigGen (n = 2048, 3072) \r\n | \r\n\r\n C1876 \r\n | \r\n
| \r\n For ECDSA schemes: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 6 and Appendix D, Implementing “NIST curves” [P-256, P-384, P-521]; ISO/IEC 14888-3, Section 6.4 \r\n | \r\n\r\n ECDSA SigGen \r\nECDSA SigVer \r\n(Curve = P-256, P-384, P-521) \r\n | \r\n\r\n C1876 \r\n | \r\n|
| \r\n FCS_COP.1/ Hash \r\n | \r\n\r\n [SHA-1, SHA-256, SHA-384, SHA-512] and message digest sizes [160, 256, 384, 512] bits \r\n | \r\n\r\n SHA-1 \r\nSHA2-256 \r\nSHA2-384 \r\nSHA2-512 \r\n | \r\n\r\n C1876 \r\n | \r\n
| \r\n FCS_COP.1/ KeyedHash \r\n | \r\n\r\n [HMAC-SHA-1, HMAC-SHA- 256, HMAC-Sha-384, HMAc-SHA-512] and cryptographic key sizes [256-bits, 160-bits, 384-bits, 512-bits] and message digest sizes [160, 384, 512] bits \r\n | \r\n\r\n HMAC-SHA-1 \r\nHMAC-SHA2-256 \r\nHMAC-SHA2-384 \r\nHMAC-SHA2-512 \r\n | \r\n\r\n C1876 \r\n | \r\n
| \r\n FCS_RBG_EXT.1 \r\n | \r\n\r\n CTR_DRBG (AES) \r\n | \r\n\r\n Counter DRBG (AES) \r\n | \r\n\r\n C1876 \r\n | \r\n
Table 4 CAVP Algorithm Testing References
\r\nThe TOE relies on the underlying platform to encrypt sensitive data at rest.
\r\nThe TOE uses X.509v3 certificates as defined by RFC 5280 to authenticate the TLS connection to the external TLS servers. The TOE validates the X.509 certificates using the certificate path validation algorithm defined in RFC 5280.
\r\nThe TOE authenticates users using a username/password combination or X.509 TLS Client Certificates.
\r\nThe TOE allows the configuration of users, file servers, file transfer services, keys and certificates, and cryptographic protocols.
\r\nThe TOE does not transmit Personally Identifiable Information (PII) over the network.
\r\nThe TOE employs several mechanisms to ensure that it is secure on the host platform. The TOE only allocates a limited amount of memory with both write and execute permission to support just-in-time compiling. The TOE supports ASLR, stack-based overflow protections, and platform security mechanisms (Windows Defender and SELinux).
\r\nThe TOE is distributed as a Microsoft .EXE file (Windows) or a RPM (CentOS). The installers are signed by Fortra so their integrity can be verified by the platform.
\r\nThe TOE protects all data in transit using TLSv1.2 or SSHv2.
\r\n","features":[]}