Governance, Risk, Compliance

Managed File Transfer Compliance

Businesses today have a requirement to share critical business information within their organisation and with 3rd parties outside their organisation.

The information may be sensitive customer data, financial information, patient or citizen records or strictly confidential intellectual property.

In addition many companies need to comply with a myriad of regulations such as PCI DSS, GCsX, Food and Drug Administration (FDA), SOX, FIPs, HIPAA or simply a framework for best practise such as ISO2700x.

Notwithstanding the issues of Legal discovery and the need to follow simple good business sense.

This creates a challenge: How to transfer data from one person or company to another in a secure, auditable, reliable, compliant and easy to use manner?

With regard to secure managed file transfer solutions, the IT department must balance the need to supply a workable file transfer solution that addresses security and compliance needs whilst enabling the business to operate under normal work processes and working practices.

THE RISKS OF INSECURE DATA TRANSFER

Companies have traditionally relied on tape back up, DVDs, network storage, FTP, email and instant messaging to move data between partners, branches and customers. These methods are convenient but fail to deliver security, efficiency or reliability.

Tapes, DVDs, and laptops can be stolen or lost, compromising the data they contain, particularly if the data is unencrypted. Standard FTP does not include strong authentication or encryption capabilities, which opens the door to the potential for hackers to access sensitive data. While email and instant messaging lack scalability and use server resources inefficiently, the larger problem with these methods involves their lack of encryption and data integrity.

In addition, following the receipt of records, neither email nor IM have processes for workflow, data integrity verification to make sure the entire transmission arrived untouched and uncompromised, or the ability to enforce business rules to control access to those records.

PCI DSS

The Payment Card Industry (PCI) Data Security Standard (DSS) are intended for use by merchants, financial processors, point-of-sale vendors, and banks, credit unions and other financial institutions that transmit, process and/or store credit cardholder data.

PCI DSS consists of twelve critical data security requirements, organized into six sections.

To discuss meeting PCI DSS requirements please contact us.

The following sections of this requirement are applicable to MFT products.


PCI DSS	SECTION APPLICABLE TO MFT PRODUCTS
BUILD AND MAINTAIN A SECURE NETWORK
1.1.5: These deal with specific protocols allowed under the standards.	File transfer functions should use SFTP and FTPS.
2: Do not use vendor-supplied defaults for system passwords and other security parameters.	The installer/administrator to set their own usernames and passwords during setup and configuration. An function to force strong passwords should be considered.
2.2.1: This section says that only one primary function be implemented on each server.	Look for a solution which can be deployed in a tiered architecture across a segmented network with primary functions distributed across several servers.
2.2.2, 2.2.3 and2.2.4: This section is about locking down or “hardening” server platforms	Ensure a server can be hardened, for example locking down windows settings.
2.3: This section requires that all (non-console) administrative access must be encrypted.	Access should be via a Web browser using HTTP/S – SSL encryption.
PCI DSS: PROTECT CARDHOLDER DATA
3: Protect stored cardholder data.	Control exactly who can login, and what they can see and do in regards to commands, files, folders, logs and other users. A system should have built-in authentication, access control, and cryptographic systems.
3.1: Data Disposal.	A system should carry out scheduled, automatic and secure deletion of old files and folders
3.4: Protection of Stored Data. This section states that strong encryption must be used to protect credit card numbers (a.k.a. “Primary Account Number” or PAN) when storing such data.	Ensure either a native ability to encrypt or a 3rd use 3rd party encryption such as PGP.
3.5 and3.6: Cryptographic Key Storage.	These sections deal with very technical key storage elements.
4: Encrypt transmission of cardholder data across open, public networks.	As a minimum FPS and SFTP should be used, if using web transfers then HTTPS. In addition if required AS” and AS3 are appropriate.
5: Maintain a Vulnerability Management Program	Consider integrated antivirus checking and auditing of files. Consider tamper evident audit logs, look for FIPS 140-2 modules
6: Develop and maintain secure systems and applications.
6.5: Web Application Development Security. This section states that the development of web applications should be based on secure coding guidelines (such as those issued by the Open Web Application Security Project), involve the review of custom application code to identify coding vulnerabilities, and cover prevention of common coding vulnerabilities in software development processes	All of the solutions listed on this side adhere to this.
6:6: All public-facing web applications are subject to either: 1) reviews of applications via manual or automated vulnerability assessment tools or methods or 2) installing an application-layer firewall in front of public-facing web applications	The vendor should post regular security updates and alerts. All of the solutions listed on this side adhere to this.
7: Restrict access to cardholder data by business need-to-know.	Choose a product that allows the specific assignment of folder permissions, protocol access restrictions, IP address restrictions and other limited rights. Also the software should permit the delegation of authority so that an “administrator” need not have control over the entire system, but rather only over a subset of folders, transfer tasks, or a group of users.
8: Assign a unique ID to each person with computer access.	Ensure the ability to rights to overlapping resources which means people use their own credentials rather than a more powerful “shared” account.
8.2: Authentication Credentials Beyond Username and Password.	For example Client Keys and Client Certificates
8.3: Two Factor Authentication.	This section focuses more on network access than file transfer; whilst not necessary you may wish to ensure a system is fully capable of implementing two factor authentication.
8.4: Credential Protection.	Securely protect stored passwords and keys
8.5: Password and User Rules.	The solution should have configurable password and user policies: 8.5.1: Control addition, deletion, and modification of user IDs, credentials, and other identifier objects. 8.5.2: Verify user identity before performing password resets. 8.5.3: Set first-time passwords to a unique value for each user and change immediately after the first use. 8.5.4: Immediately revoke access for any terminated users. 8.5.5: Remove/disable inactive user accounts at least every 90 days. 8.5.6: Enable accounts used by vendors for remote maintenance only during the time period needed. 8.5.7: Communicate password procedures and policies to all users who have access to cardholder data. 8.5.8: Do not use group, shared, or generic accounts and passwords. 8.5.9: Change user passwords at least every 90 days. 8.5.10: Require a minimum password length of at least seven characters. 8.5.11: Use passwords containing both numeric and alphabetic characters. 8.5.12: Do not allow an individual to submit a new password that is the same as any of the last four passwords he or she has used. 8.5.13: Limit repeated access attempts by locking out the user ID after not more than six attempts. 8.5.14: Set the lockout duration to a minimum of 30 minutes or until administrator enables the user ID. 8.5.15: If a session has been idle for more than 15 minutes, require the user to re-enter the password to reactivate the terminal. 8.5.16: Authenticate all access to any database containing cardholder data. This includes access by applications, administrators, and all other users.
9: Restrict Physical Access to Cardholder Data.	Whilst File Transfer is not strictly relevant to this, if the files are encrypted at rest then the cardholder data is secure.
PCI DSS: REGULARLY MONITOR AND TEST NETWORKS
10: Track and Monitor All Access to Network Resources and Cardholder Data.	Comprehensive Logging Facilities Log Data Security. Administrative Log Data.

Security and compliance considerations

SOX requires that business processes are auditable.

HIPAA requires that companies prove that only the intended information was shared or exchanged.

The FDA requires that administrative controls are in place when electronic systems and records are used in place of paper or manual systems.

Payment Card Industry Data Security Standard (PCI DSS)

Safeguard payment cardholder data and sensitive card authentication information.

GCSX stands for Government Connect Secure Extranet. It is a secure private Wide-Area Network (WAN) which enables secure interactions between connected Local Authorities and organisations.

Approved protocols are http, https, ftp (PASSIVE), ftps, ssh, sftp