Managed File Transfer

Multi-factor authentication (MFA) is a cybersecurity best practice that requires a user (or entity) present two or more pieces of evidence prior to being granted access to a website or application. These factors must distinctly meet at least two of three criteria: knowledge (something only the user knows), possession (something only the user has), and inheritance (something only the user is). Multi-factor authentication is a required within various legislation and regulations:

• Payment Card Industry Data Security Standard (PCI DSS) requires MFA for both remote network access to Card Data Environment (CDE) and administrative access to CDE
• S. Homeland Security Presidential Directive 12 (HSPD-12) includes requirement of MFA to access sensitive IT resources
• S. Federal Financial Institutions Examination Council (FFIEC) requires MFA for remote access of online financial services

The IBM Sterling B2B collaboration suite of products – B2B Integrator, File Gateway, and Connect:Direct – leverage IBM Sterling Secure Proxy and IBM Sterling External Authentication Server to implement multi-factor authentication. Sterling Secure Proxy (SSP) is a DMZ-based software proxy enabling secure and high-speed data movement over the internet.¹ Sterling External Authentication Server (SEAS) implements extended authentication and validation services for IBM products.²

Multi-factor authentication can be implemented via various approaches using  IBM Sterling B2B Collaboration products. Below are some common approaches for multi-factor or two-factor authentication adopted by several IBM customers for file transfer via common protocols:

• For​ traffic via SFTP the two factors can be ID/password and SSH key. 
• For HTTPS and FTPS traffic, the two factors can be an ID/password and a digital certificate validation. Additional certificate authentications within Secure Proxy include:
  • Certificate Revocation List (CRL) check
  • Common namecheck or subject name lookup to validate that the certificate is issued to a trusted trading partner, by looking up the name at your LDAP server
  • Binary comparison which compares certificate to public certificate
  • IP binding of a certificate to a specific IP address
  • Custom Exit in which the certificate is transmitted to a java program to interface with internal certificate validation routines

Some of the more advanced approaches include leveraging external identity provider (IDP) which will provide additional factors of authentication. Secure Proxy can be configured to use an external logon portal to accept SAML 2.0 tokens from an external Identity provider and authenticate users based on those tokens. In such case the external identity provider would provide multifactor authentication services before generating SAML assertions and redirecting back to SSP. There are several combinations here, with many security authentication applications to choose from. An example of this are Time based One-time password (TOTP), tokens, biometrics such as facial or retinal scans, text or email code, etc.

Another example involves implementing one time password (OTP) via SEAS custom exit where a plugin from an external provider enables the OTP through text messages. This is similar to the RSA authentication where you get a pin that you must submit to the authenticator. Biometrics can also be implemented via a custom exit, assuming you have a provider that enables it. Some might prefer sending the OTP to corporate email ID instead of mobile number or personal email address to ensure that if an employee from a trading partner leaves the organization, he will not be able to authenticate even if he has username/password.

Some companies use a security zone as a factor, so that they can then implement normal user and password for everything in that zone.  This approach leverages information like IP zone, network or geography alongside other authentication factors to decide, if other authentication factors are necessary or not. For example, an authentication request originating from within the organization may be authenticated only with user password, since he is identified as an internal user from his coordinates.

Traditionally, the approaches mentioned above are implemented for external facing applications within the Sterling suite, however they can also be extended to internal access by deploying another SSP instance behind the trusted zone.

In summary, IBM clients rely on Sterling Secure Proxy and SEAS to achieve multifactor authentication capabilities. MFA approaches can be complex with so many unique factors to choose from IP to retinal scans.  It’s important to get clarity on requirements, make choices of the right identity provider based on those requirements, and flexibly configure SSP and SEAS to meet your needs. With SSP you can configure additional security features like IP/userID block-listing, virus scanning and others, providing highest level of protection against threats looming on the internet. 

Visit this web page to learn more about Sterling Secure Proxy.

¹ IBM Sterling Data Sheet: IBM Sterling Secure Proxy

² IBM Secure External Authentication Server V6.0.0 Knowledge Center