How PCI DSS Requirements Addressed with EFT

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. (Updated for PCI DSS v3.2)

Refer to the PCI Security Standards website for official documentation of the standard . You can download the PCI DSS Security Audit Procedures from https://www.pcisecuritystandards.org.

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 a Firewall Configuration to Protect Cardholder Data

PCI DSS Requirement		How Requirement is Addressed with EFT
1.1 Establish and implement firewall and router configuration standards.		Requires measures external to EFT.
1.2 Build firewall and router configurations that restrict connections between untrusted networks and any system components in the cardholder data environment.		Requires measures external to EFT; however EFT also provides a robust set of IP access filters to control access to EFT and/or the DMZ Gateway. EFT Arcus doesn't use DMz Gateway because Azure tools/infrastructure already provide equivalent security. The architecture uses a single point entry at an Azure Load balancer, steering inbound traffic, via NAT and protocol specific inbound rules, to the cluster of EFT servers. The private network is further insulated by Azure Network Security Groups.
1.3 Prohibit direct public access between the Internet and any system component in the cardholder data environment.		Storing cardholder in the DMZ or other untrusted network is expressly prohibited by PCI DSS (1.3.7). And for security best practices you should not allow inbound connections to originate from untrusted into trusted zones. EFT Arcus doesn't use DMZ Gateway because Azure tools/infrastructure already provide equivalent security. The architecture uses a single point entry at an Azure Load balancer, steering inbound traffic, via NAT and protocol specific inbound rules, to the cluster of EFT servers. The private network is further insulated by Azure Network Security Groups.
	1.3.1 Implement a DMZ to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports.	EFT in combination with the DMZ Gateway module facilitates compliance with this requirement. EFT Arcus doesn't use DMZ Gateway because Azure tools/infrastructure already provide equivalent security. The architecture uses a single point entry at an Azure Load balancer, steering inbound traffic, via NAT and protocol specific inbound rules, to the cluster of EFT servers. The private network is further insulated by Azure Network Security Groups.
	1.3.2 Limit inbound Internet traffic to IP addresses within the DMZ.	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.
	1.3.3 Implement anti-spoofing measures to detect and block forged source IP addresses from entering the network.	The need for inbound connections between the DMZ and the internal network is eliminated when using EFT in combination with the DMZ Gateway module. EFT Arcus doesn't use DMZ Gateway because Azure tools/infrastructure already provide equivalent security. The architecture uses a single point entry at an Azure Load balancer, steering inbound traffic, via NAT and protocol specific inbound rules, to the cluster of EFT servers. The private network is further insulated by Azure Network Security Groups.
	1.3.4 Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet.	Requires measures external to EFT.
	1.3.5 Permit only "established" connections into the network.	EFT can be configured* to use the DMZ Gateway as a SOCKS5 proxy for outbound traffic. Offloading files using EFT though the DMZ Gateway means your internal IP address won’t be exposed (1.3.48). Additional steps may be required to fulfill this requirement, such as DLP and deep content inspection tools, before files are submitted to EFT for offloading. EFT Arcus doesn't use DMZ Gateway because Azure tools/infrastructure already provide equivalent security. The architecture uses a single point entry at an Azure Load balancer, steering inbound traffic, via NAT and protocol specific inbound rules, to the cluster of EFT servers. The private network is further insulated by Azure Network Security Groups.
	1.3.6 Place system components that store cardholder data (such as a database) in an internal network zone, segregated from the DMZ and other untrusted networks.	EFT, when combined with the DMZ Gateway, eliminates the need to store data in the DMZ. EFT Arcus doesn't use DMZ Gateway because Azure tools/infrastructure already provide equivalent security. The architecture uses a single point entry at an Azure Load balancer, steering inbound traffic, via NAT and protocol specific inbound rules, to the cluster of EFT servers. The private network is further insulated by Azure Network Security Groups.
	1.3.7 Do not disclose private IP addresses and routing information to unauthorized parties.	Your internal IP addressing scheme is never exposed when EFT is used in combination with the DMZ Gateway. EFT Arcus doesn't use DMZ Gateway because Azure tools/infrastructure already provide equivalent security. The architecture uses a single point entry at an Azure Load balancer, steering inbound traffic, via NAT and protocol specific inbound rules, to the cluster of EFT servers. The private network is further insulated by Azure Network Security Groups.
1.4 Install personal firewall software on any mobile and/or employee-owned computers		Requires measures external to EFT.
1.5 Document policies and procedures		Requires measures external to EFT.

Requirement 2: Do Not Use Vendor-Supplied Defaults for System Passwords and Other Security Parameters

PCI DSS Requirement		How Requirement is Addressed with EFT
2.1 Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network.		When you create a high security-enabled Site, EFT detects whether any default values are specified for administrator login port (1100), DMZ Gateway port (44500), FTP banner message, or SFTP banner message, and will prompt you to change them. No default passwords, usernames, certificates, or keys are used.
2.2 Develop configuration standards for all system components.		Refer to the specific sub-requirements below.
	2.2.1 Implement only one primary function per server	EFT’s primary function is File Transfer. It is up to the administrator to segregate servers.
	2.2.2 Enable only necessary services, protocols, daemons, etc., as required for the function of the system.	It is up to the administrator to determine whether an enabled protocol is necessary. No protocol is enabled by default.
	2.2.3 Implement additional security features for any required services, protocols, or daemons that are considered insecure.	Any unsecure protocols such as plaintext FTP or HTTP are automatically detected* and you are prompted to change them or present a compensating control.
	2.2.4 Configure system security parameters to prevent misuse.	EFT monitors and warns when User login credentials persisted in memory beyond the absolute minimum time necessary (some configurations require this when reusing credentials for secondary connections) Flood and DoS prevention settings set too low FTP Anti-timeout prevention scheme disabled or FXP (site-to-site) permitted
	2.2.5 Remove all unnecessary functionality	It is up to the administrator to remove any scripts, AWE workflows or similar user-created files that are no longer in use.
2.3 Encrypt all non-console administrative access using strong cryptography.		The status of non-console (remote) access settings are monitored and you are warned if SSL is not enabled and given the option to either disable remote administration or enable SSL.
2.4 - 2.6 Inventory maintenance, policy documentation and enforcement, and shared hosting requirements		Requires measures external to EFT.

Requirement 3: Protect Stored Cardholder Data

PCI DSS Requirement		How Requirement is Addressed with EFT
3.1 Keep cardholder data storage to a minimum by implementing data retention and disposal policies, procedures and processes.		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.
3.2 Do not store sensitive authentication data after authorization (even if encrypted).		3.2.1-3 Refers to card sensitive authentication data (SAD), which should never be stored on the server. Use a third-party DLP or similar tool to detect and prevent SAD storage.
3.3 Mask PAN when displayed		Not applicable to EFT, because EFT cannot display that data.
3.4 Render PAN, at minimum, unreadable anywhere it is stored.		Encrypt PAN or other sensitive data using EFT’s optional OpenPGP encryption module or third-party encryption utilities.
	3.4.1 If disk encryption is used, logical access must be managed independently of native operating system authentication and access control mechanisms.	EFT will detect and warn if Microsoft Encrypting File System (EFS) is being used.
3.5 Document and implement procedures to protect keys		Mostly requires measures external to EFT; however access to keys through the administrator interface is limited to administrator roles with Site or Server access only.
3.6 Fully document and implement all key management processes and procedures		Mostly requires measures external to EFT; however, per 3.6.1 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.
3.7 Document policies and procedures		Requires measures external to EFT.

Requirement 4: Encrypt Transmission of Cardholder Data across Open, Public Networks

PCI DSS Requirement	How Requirement is Addressed with EFT
4.1 Use strong cryptography and security protocols	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.
4.2 - 4.3 Never send unprotected PANs by end-user messaging technologies; document security policies and procedures	Requires measures external to EFT.

Requirement 5: Use and Regularly Update Anti-Virus Software

PCI DSS Requirement	How Requirement is Addressed with EFT
5.1 - 5.4 Anti-virus requirements.	Requires measures external to EFT

Requirement 6: Develop and Maintain Secure Systems and Applications

PCI DSS Requirement		How Requirement is Addressed with EFT
6.1 Establish a process to identify security vulnerabilities		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.
6.2 Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor-supplied security patches. Install critical security patches within one month of release.		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.
6.3 Develop internal and external software applications securely.		Globalscape takes a number steps to develop secure software, as documented here: https://kb.globalscape.com/KnowledgebaseArticle11061.aspx.
	6.3.1 Removal of custom application accounts, user IDs, and passwords before applications become active or are released to customers	Only applies to Professional Services engagements and should be verified prior to deployment.
	6.3.2 Review of custom code prior to release to production or customers in order to identify any potential coding vulnerability.	Only applies to Professional Services engagements and should be verified prior to deployment.
6.4 Follow change control procedures for all changes to system components.		Requires measures external to EFT.
6.5 Address common coding vulnerabilities in software-development processes		Globalscape takes a number steps to develop secure software, as documented here: https://kb.globalscape.com/KnowledgebaseArticle11061.aspx.
6.6 For public-facing web applications, address new threats and vulnerabilities on an ongoing basis.		Requires customer to run a security scan. However, Globalscape also performs routine third-party security scans of EFT’s public-facing web interfaces as part of its quality assurance process.
6.7 Document policies and procedures		Requires measures external to EFT.

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

PCI DSS Requirement	How Requirement is Addressed with EFT
7.1 Limit access to system components and cardholder data to only those individuals whose job requires such access.	EFT provides complete control administrator and user access to resources, with administrator accounts completely segregated from user accounts.
7.2 Establish an access control system for systems components with multiple users that restricts access based on a user’s need to know, and is set to "deny all" unless specifically allowed.	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
7.3 Document policies and procedures.	Requires measures external to EFT.

Requirement 8: Assign a Unique ID to Each Person with Computer Access

PCI DSS Requirement	How Requirement is Addressed with EFT
8.1 Define and implement policies and procedures to ensure proper user identification management	EFT enforces unique usernames for both users and administrators (8.1.1), provides granular administrative controls over user provisioning and authorization (8.1.2), allows user and administrator account revocation (8.1.3), provides automatic removal of inactive users after 90 days (8.1.4), includes controls for temporarily enabling/disabling users (8.1.5), auto-locks users after six failed login attempts (8.1.6), either for a period of time or permanently until the administrator unbans (8.1.7), and automatically expires sessions after 15 minutes of inactivity (8.1.8)
8.2 In addition to assigning a unique ID, ensure proper user authentication.	EFT supports various combinations of password, certificate, two-factor, and public-key authentication mechanisms (8.2), secures passwords during transmission (assumes SSL or SSH), and storage (with a one way [uniquely salted] hash)(8.2.1), verifies identity before allowing password reset or lost username retrieval according to OWASP guidelines (8.2.2), includes minimum length and a number of complexity options (8.2.3), expires and forces password change after 90 days (8.2.4), disallows password re-use, internal dictionary match, or username match (8.2.5), and can force first time use password reset (8.2.6).
8.3 Incorporate two-factor authentication for remote network access. NOTE: EFT does not provide multifactor authentication for remote (non-console) administrator access.	Although EFT supports 2FA, this requirement is about network access, such as what is normally done over a VPN. For compliance with PCI DSS v3.2, you should disable remote (non-console) administrator access. From the PCI DSS v3.2, "Multi-factor authentication is not required at both the system-level and application-level for a particular system component. Multi-factor authentication can be performed either upon authentication to the particular network or to the system component."
8.4 Document and communicate authentication procedures and policies	Requires measures external to EFT.
8.5 Do not use group, shared, or generic IDs, passwords, or other authentication methods	The "Anonymous" password type is disallowed on a high-security-enabled Site. To comply with 8.5.1 you will need to create unique accounts for service provider access, should there ever be a need to provide such access.
8.6 Requirements for unique and controlled access using non-standard authentication mechanisms.	Requires measures external to EFT as most of these are physically provisioned to the user.
8.7 All access to any database containing cardholder data is restricted.	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.
8.8 Document policies and procedures.	Requires measures external to EFT

Requirement 9: Restrict Physical Access to Cardholder Data

PCI DSS Requirement	How Requirement is Addressed with EFT
9.1 - 9.7 Requirements related to physical access to the cardholder environment.	Requires measures external to EFT.
9.8 Destroy media when it is no longer needed for business or legal reasons. Cardholder data on electronic media must be rendered unrecoverable via a secure wipe program	EFT includes a data-wiping algorithm for sanitizing deleted data on disk.
9.9 Protect devices that capture payment card data via direct physical interaction	Requires measures external to EFT
9.10 Document policies and procedures.	Requires measures external to EFT

Requirement 10: Track and Monitor All Access to Network Resources and Cardholder Data

PCI DSS Requirement	How Requirement is Addressed with EFT
10.1 Implement audit trails to link all access to system components to each individual user	Preconfigured reports of all activity (including administrator actions*) within EFT can be generated on demand with the Auditing and Reporting Module (ARM).
10.2 Implement automated audit trails for all system components	EFT will audit* all user access to data (10.2.1), and all administrator changes** to configuration settings (10.2.2). Access to audit trails, invalid logical access, authentication mechanisms, object creation, and initialization of audit logs (10.2.3-2.7) is managed at the database server.
10.3 Record audit trail entries for all system components	EFT audits* user identity (10.3.1), type of transaction (10.3.2), date and time of transaction (10.3.3), transaction result (10.3.4), remote and local IP (10.3.5), and objects affected (10.3.6). *Requires ARM
10.4 Synchronize critical system clocks and times	Requires measures external to EFT.
10.5 Secure audit trails so that they cannot be altered.	Audited data integrity depends on the chosen database solution and authentication architecture. EFT supports auditing to a central SQL server.
10.6 Review log sand security events for all system components (10.6.1) at least daily	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.
10.7 Retain audit trail history for at least one year	Requires measures external to EFT.
10.8 Implement a process for the timely detection and reporting of failures of critical security control systems	EFT logs and reports audit EFT-specific systems; auditing of other network systems requires measures external to EFT.
10.9 Document policies and procedures	Requires measures external to EFT

Requirement 11: Regularly Test Security Systems and Processes

PCI DSS Requirement	How Requirement is Addressed with EFT
11.1 - 11.6 Requirements relating to regular testing of security systems and processes.	Requires measures external to EFT.

Requirement 12: Maintain a Policy that Addresses Information Security

PCI DSS Requirement	How Requirement is Addressed with EFT
12.1 - 12.10 Maintain a policy that addresses information security for all personnel	Requires measures external to EFT

Copyright © Fortra, LLC and its group of companies.
All trademarks and registered trademarks are the property of their respective owners.
v8.1.1.16 | 202410010335 | October 2024