How EFT Addresses PCI DSS Requirements

EFT facilitates enforcing high security and compliance with the PCI Data Security Standard (PCI DSS), which provides detailed security compliance guidelines that can be used to provide hardened security for EFT, no matter which rules or standards by which your organization is measured. Each requirement and a description of how EFT helps comply with the requirements is described below.

Refer to the PCI Security Standards website for official documentation of the standard.

Compensating Controls

From the PCI DSS Security Auditing Procedures document:

Compensating controls may be considered for most PCI DSS requirements when an entity cannot meet a requirement explicitly as stated, due to legitimate technical or documented business constraints, but has sufficiently mitigated the risk associated with the requirement through implementation of other, or compensating, controls.

When EFT warns you of a non-compliant setting, you will be given the choice to fix the problem or proceed with the non-compliant setting. If you choose to proceed in violation of the PCI DSS, you will be asked to specify a compensating control, i.e. an alternate hardware, software, or internal policy that satisfies the requirement in some other way (ref. "Compensating Controls" in the PCI DSS for more information). The controls you document will appear in the PCI DSS Compliance report, which you can provide to Qualified Security Assessors (QSAs) and Approved Scanning Vendors (ASVs), individuals who are certified by the PCI Security Standards Council as being qualified to validate compliance to the PCI DSS.

PCI DSS Requirements Addressed

EFT facilitates compliance with applicable PCI DSS requirements. The PCI DSS requirements related to physical security and cardholder database security are not applicable to EFT; however, you should place the Server computer in a secured area, such as a locked server room or network operations center.

Requirement 1: Install and Maintain Network Security Controls

  • Storing cardholder in the DMZ or other untrusted network is expressly prohibited by PCI DSS. And for security best practices you should not allow inbound connections to originate from untrusted into trusted zones.

  • EFT provides a robust set of IP access filters to control access to EFT and/or the DMZ Gateway.

  • When EFT is used in combination with the DMZ Gateway, no internal inbound ports need be opened into the trusted network, hence all inbound traffic will be restricted to IP addresses within the DMZ.

  • Your internal IP addressing scheme is never exposed when EFT is used in combination with the DMZ Gateway.

Requirement 2: Apply Secure Configurations to All System Components

  • When you create a "strict security" site, EFT monitors and warns:

  • It is up to the administrator to determine whether an enabled protocol is necessary. No protocol is enabled by default.

  • It is up to the administrator to remove any scripts, custom commands, Advanced Workflows or similar user-created files that are no longer in use.

Requirement 3: Protect Stored Account Data

  • EFT provides a scheduled, automatic Clean-up Action. Deleted files can be purged by writing over the initial data using encrypted and/or pseudorandom data (PCI DSS 9.8). Disk quotas can be set to limit data storage.

  • Encrypt PAN or other sensitive data using EFT’s optional OpenPGP encryption module or third-party encryption utilities.

  • EFT will detect and warn if Microsoft Encrypting File System (EFS) is being used.

  • Access to keys through the administrator interface is limited to administrator roles with Site or Server access only.

  • EFT will disallow creation of 512 or lesser certificate /key bit lengths. Default bit-length is set to 2048 bits for new keys. When importing SSL or SFTP keys, a warning will appear if a weak key is imported.

Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks

  • Secure protocols such as SSL, TLS, and SFTP (SSH2) are provided for data transmission. Secure data transmission is enforced* by automatically redirecting  incoming HTTP traffic to HTTPS.

Requirement 5: Protect All Systems and Networks from Malicious Software

  • Requires measures external to EFT, such anti-virus software

Requirement 6: Develop and Maintain Secure Systems and Software

  • Globalscape has formal processes for dealing with potential security vulnerabilities discovered in EFT, including an escalation process, a risk assessment that includes Common Vulnerability Scoring System (CVSS) risk ranking, and a process for notifying customers of critical patches or workarounds.

  • The latest version of EFT is always available from the Globalscape website. Customers are automatically notified upon critical patch availability. It is up to the customer to install the patch within the designated one-month window.

  • Globalscape takes a number steps to develop secure software, as documented here: https://kb.globalscape.com/KnowledgebaseArticle11061.aspx.

  • Globalscape also performs routine third-party security scans of EFT’s public-facing web interfaces as part of its quality assurance process.

Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need-to-Know

  • EFT provides complete control administrator and user access to resources, with administrator accounts completely segregated from user accounts

  • Segregation and control of user access is achieved using unique accounts, permission groups, virtual folders, and settings templates Segregation and control of administrator access is accomplished via delegated, role-based administrator accounts.

Requirement 8: Identify Users and Authenticate Access to System Components

  • EFT enforces unique usernames for both users and administrators, provides granular administrative controls over user provisioning and authorization, allows user and administrator account revocation, provides automatic removal of inactive users after 90 days, includes controls for temporarily enabling /disabling users, auto-locks users after six failed login attempts , either for a period of time or permanently until the administrator unbans, and automatically expires sessions after 15 minutes of inactivity.

  • EFT supports various combinations of password, certificate, two-factor, and public-key authentication mechanisms, secures passwords during transmission (assumes SSL or SSH), and storage (with a one way [uniquely salted] hash), verifies identity before allowing password reset or lost username retrieval according to OWASP guidelines, includes minimum length and a number of complexity options, expires and forces password change after 90 days, disallows password re-use, internal dictionary match, or username match, and can force first-time use password reset.

  • Although EFT supports 2FA, this requirement is about network access, such as what is normally done over a VPN. You should disable remote (non-console) administrator access.

  • The "Anonymous" password type is disallowed on a high-security-enabled Site. To comply, you will need to create unique accounts for service provider access, should there ever be a need to provide such access.

  • EFT provides granular controls over which administrators can access EFT’s reports from within the EFT Server console; however controls over access to the database (including the data itself) requires measures external to EFT.

Requirement 9: Restrict Physical Access to Cardholder Data

  • EFT includes a data-wiping algorithm for sanitizing deleted data on disk.

Requirement 10: Log and Monitor All Access to System Components and Cardholder Data

  • Preconfigured reports of all activity (including administrator actions*) within EFT can be generated on demand with the Auditing and Reporting Module (ARM).

  • EFT will audit* all user access to data, and all administrator changes** to configuration settings. Access to audit trails, invalid logical access, authentication mechanisms, object creation, and initialization of audit logs is managed at the database server.

  • EFT audits* user identity, type of transaction, date and time of transaction, transaction result, remote and local IP, and objects affected. *Requires ARM

  • Audited data integrity depends on the chosen database solution and authentication architecture. EFT supports auditing to a central SQL or Oracle server.

  • A daily PCI DSS Compliance report can be generated by EFT and sent via email to the appropriate recipient(s). Administrators can also attach any other canned or administrator created report to the daily email.

  • EFT logs and reports audit EFT-specific systems; auditing of other network systems requires measures external to EFT.

Requirement 11: Test Security of Systems and Networks Regularly

  • Requires measures external to EFT.

Requirement 12: Support Information Security with Organizational Policies and Programs

  • Requires measures external to EFT