How to Create a PCI DSS 3.2.1 Compliant MFT Solution
As of May 2018, payment merchants and other credit card handling organisations will need to have familiarised themselves and have implemented the latest iteration of the PCI-DSS (Payment Card Industry - Data Security Standard). Version 3.2.1 expands on what is already a comprehensive and well-known standard by adapting to the rapidly changing climate of data protection, privacy and vulnerability management.
In particular, this blog focuses on how version 3.2.1 affects managed file transfer solutions and how you can ensure your MFT solution stays compliant.
Requirement 1: Install and maintain a firewall configuration to protect cardholder data
PCI-DSS considers everything outside of the CDE (Card Data Environment) to be "external" and therefore have boundary controls in place, such as a firewall; and with it requirements such as period reviews of rules, lists of approved protocols, creation of a DMZ (Demilitarised Zone) and segregated administration roles.
Where a managed file transfer solution is required in a card data environment and that solution requires interactivity with the external network, you will need to focus on requirements 1.3 and 1.3.1. These two requirements stipulate that there should be no direct connection between the card data environment and an external network; and that card data should never be directly accessible from external networks. Instead, where connectivity is a requirement, a DMZ should be created and a proxy created inside of the DMZ to handle connections using only authorised and documented secure protocols.
Most managed file transfer solutions will include an optional gateway or proxy solution which can be placed into a DMZ and buffer or proxy connections. So long as this uses secure protocols and does not store any card data in the DMZ, you will meet the requirements above; and requirement 1.3.6 which prohibits storing card data in the DMZ.
Requirement 2: Do Not Use Vendor-Supplied Defaults for System Passwords and Other Security Parameters
This one is relatively self explanatory. Requirement 2.1 specifically requires that any vendor-supplied solution have all default passwords replaced. Some solutions will randomise the creation of passwords, allow passwords to be determined by the IT team at installation or provide the ability to change them afterwards. In all cases, ensure they are not default values.
Where your managed file transfer solution is installed or hosted on commercial operating systems and software, you will need to pay attention to requirement 2.2. Which broken down into four sub-requirements stipulates that secure configuration standards and baselines such as CIS, ISO, SANS and NIST must be adopted. Each of these organisations publish instructions on how best to harden and secure various operating systems and network devices.
For those who have multi-tasked managed file transfer workflows, for example a collection website for files and an automated transfer of files between systems on a schedule. Requirement 2.2.1 expects these tasks to be separated onto different servers. This is to limit each server to a primary function. Most managed file transfer solutions are modularised and should be able to support such deployment requirements.
Finally, both requirements 2.2.3 and 2.3 require additional security in places where there may be inherent insecurity or heightened risk. In particular the use of non-encrypted transfer protocols. Readers should beware that in PCI-DSS 3.2.1, the use of SSL or early TLS has been depreciated due to significant vulnerabilities and that only TLS 1.2 or above should be used for HTTPS or FTPS.
Requirement 3: Protect Stored Cardholder Data
The core of PCI-DSS exists in requirements section three, which lists expectations around the storage of card data in the card data environment.
Requirement 3.1 requires that card data storage must be kept to a minimum and that strict retention policies be adhered to. Managed file transfer solutions often have automated clean-up or archiving functions which can remove unused files and documents after a specified time period. In addition to this, some solutions offer secure deletion capabilities, such as those published in NIST SP 800-88.
For authentication into a managed file transfer solution, use a centralised user repository, where possible. For example, Microsoft Active Directory. This limits the authentication data being stored on the solution as required in requirement 3.2. Where local accounts are being used, ensure you have turned on; or are using strong encryption.
Where card data or the PAN (Primary Account Number) is being stored by the managed file transfer solution, you must ensure appropriate cryptographic controls are in place to protect it, in accordance with requirement 3.4. For some managed file transfer solutions, encryption-at-rest might be an option which needs to be turned on. Consider using AES 256-bit as a minimum, FIPS 140-2 validation is not a requirement but as a NIST secure standard, works towards the spirit of requirement 2.2.
How keys for encryption are handled and stored are listed in requirement 3.5. You will need to take a look at your vendor documentation to assess your own solution. As an example, Progress MOVEit Transfer re-encrypts all encrypting keys and stores them in a tamper-evident database, to comply with this requirement.
Requirement 4: Encrypt transmission of cardholder data across open, public networks
While there are numerous requirements in section four, the core principle is the protection of card data being transmitted between systems across open networks, such as WiFi.
Managed file transfer solutions can and should be configured to only used secure transfer protocols, such as HTTPS, SFTP, FTPS and ASx. This will ensure a base level of protection during transmission. Also consider using file encryption in parallel to double-thwart any accidental or intentional disclosure.
Requirement 5: Protect all Systems Against Malware and Regularly Update Antivirus Software or Programs
Requirement 5.1 and its sub-requirements detail the need for up-to-date antivirus signatures and capabilities, which can detect and remove any malware threats. Where possible, your managed file transfer solution should be configured to interop or leverage antivirus capabilities in the card data environment, to scan incoming and transferred files for infection.
Where infections are detected, the file should be rejected and the infection logged or alerted on.
Requirement 6: Develop and Maintain Secure Systems and Applications
If using a commercially, off-the-shelf managed file transfer solution, ensure to ask your vendor how they test for and ensure their software is resilient to the following types of attacks:
- Requirement 6.5.1 - SQL injection.
- Requirement 6.5.2 - Buffer overflows.
- Requirement 6.5.3 - Insecure cryptographic storage.
- Requirement 6.5.4 - Insecure communications.
- Requirement 6.5.5 - Improper error handling.
- Requirement 6.5.7 - Cross-site scripting (XSS).
- Requirement 6.5.8 - Improper access control.
- Requirement 6.5.9 - Cross-site request forgery (CSRF).
- Requirement 6.5.10 Broken authentication and session management.
Progress MOVEit Transfer is a managed file transfer which is has been helping clients be PCI-DSS ready for more than a decade. Would you like to see a live demo of the solution? - Click here to book a meeting.
Requirement 7: Restrict Access to Cardholder Data by Business Need to Know
To summarise requirement 7.1 and its sub-requirements, the security standard requires that access to card data be restricted to only those who require access as part of their job role. A managed file transfer will often have the ability to create logical folders and storage spaces with differing levels of permission.
This can be made simpler through the creation of roles or groupings which can automatically define permissions and access rights for each user.
Requirement 8: Identify and Authenticate Access to System Components
Requirements 8.1 and 8.2 list a number of requirements such as unique usernames or system IDs, revocation capabilities for account access, automated removal of inactive accounts and minimum password security. Managed file transfer solutions should have no problem implementing these controls and may inherit some of them from any centralised user repository systems it may have been paired with.
A long standing requirement of PCI-DSS is the use of multi-factor authentication in requirement 8.3. Which was once only required if connecting to a connecting to a card data environment from an external network; but is now required in any case where non-console access is required. Some managed file transfer solutions can interop with multi-factor authentication solutions using RADIUS, others have included it into their solution without a third-party.
|
