The High Security module (HSM) 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 Server, no matter which rules or standards by which your organization is measured. Each requirement and a description of how the HSM helps comply with the requirements is described in PCI DSS Requirements Addressed, below.
You can download the PCI DSS Security Audit Procedures from https://www.pcisecuritystandards.org.
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 Server 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. Appendix B: 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.
EFT Server facilitates compliance with applicable PCI DSS requirements. The PCI DSS requirements related to physical security and cardholder database security are not applicable to EFT Server; however, you should place the Server computer in a secured area, such as a locked server room or network operations center.
PCI DSS Requirement |
How Requirement is Addressed with EFT Server |
|
1.1 Establish firewall and router configuration standards. |
Requires measures external to EFT Server. |
|
1.2 Build a firewall configuration that restricts connections between untrusted networks and any system components in the cardholder data environment. |
EFT Server HSM's IP access filter lets you grant or deny access to specific IP addresses or ranges of IP addresses. |
|
1.3 Prohibit direct public access between the Internet and any system component in the cardholder data environment. |
Storing cardholder in the DMZ where it is publicly accessible or storing the data internally but allowing inbound connections between the perimeter and internal firewalls in a "west-to-east" fashion violates this security best practice. How can a company make its cardholder data available for business partners while protecting it from publicly accessible systems or networks? EFT Server’s optional DMZ Gateway Server module solves this problem through brokering of communications between the DMZ and the internal network. |
|
|
1.3.1 Implement a DMZ to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports. |
EFT Server in combination with the DMZ Gateway module facilitates compliance with this requirement. |
|
1.3.2 Limit inbound Internet traffic to IP addresses within the DMZ. |
When EFT Server is used in combination with the DMZ Gateway, no internal inbound ports need be opened, hence all inbound traffic will be restricted to IP addresses within the DMZ. |
|
1.3.3 Do not allow any direct connections inbound or outbound for traffic between the Internet and the cardholder data environment. |
The need for inbound connections between the DMZ and the internal network is eliminated when using EFT Server in combination with the DMZ Gateway module. |
|
1.3.4 Do not allow internal addresses to pass from the Internet into the DMZ. |
Your internal IP addressing scheme is never exposed when EFT Server is used in combination with the DMZ Gateway. |
|
1.3.5 Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet. |
EFT Server can be configured* to use the DMZ Gateway as a SOCKS5 proxy for outbound traffic. Offloading files using EFT Server though the DMZ Gateway means your internal IP address won’t be exposed (1.3.4). Additional steps may be required to fulfill this requirement, such as DLP and deep content inspection tools, before files are submitted to EFT Server for offloading. *Requires DMZ Gateway. |
|
1.3.6 Implement stateful inspection, also known as dynamic packet filtering. |
Requires measures external to EFT Server. |
|
1.3.7 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 Server, when combined with the DMZ Gateway, eliminates the need to store data in the DMZ. |
|
1.3.8 Do not disclose private IP addresses and routing information to unauthorized parties. |
EFT Server permits IP masquerading (for FTPS), and can be placed behind the DMZ Gateway proxy (thus hiding private IP addresses). |
1.4 Install personal firewall software on any mobile and/or employee-owned computers |
Requires measures external to EFT Server. |
PCI DSS Requirement |
How Requirement is Addressed with EFT Server |
|
2.1 Always change vendor-supplied defaults before installing a system on the network. |
With the HSM and a PCI DSS Site, EFT Server detects whether any default values are specified for Admin 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 (for example, web servers, database servers, and DNS should be implemented on separate servers) |
EFT Server’s primary function is File Transfer. It is up to the administrator to segregate servers. |
|
2.2.2 Enable only necessary and secure services, protocols, daemons, etc., as required for the function of the system. |
Any unsecure protocols such as plaintext FTP or HTTP are automatically detected* and you are prompted to change them or present a compensating control per PCI DSS requirement 1.1.5: "Documentation and business justification for use of all services, protocols, and ports allowed, including documentation of security features implemented for those protocols considered to be insecure." *Requires HSM and creation of a PCI DSS Site. |
|
2.2.3 Configure system security parameters to prevent misuse. |
With the HSM and a PCI DSS Site, EFT Server monitors and warns when:
|
|
2.2.4 Remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers. |
Requires measures external to EFT Server. |
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. *Requires HSM and creation of a PCI DSS Site |
|
2.4 Shared hosting providers must protect each entity’s hosted environment and cardholder data. |
Please contact GlobalSCAPE for more information relating to PCI DSS compliance and EFT Server hosted services (Managed Information eXchange). |
PCI DSS Requirement |
How Requirement is Addressed with EFT Server |
|
3.1 Keep cardholder data storage to a minimum by implementing data retention and disposal policies, procedures and processes. |
EFT Server provides a scheduled, automatic Clean-up Action*. Deleted files can be purged** by writing over the initial data using encrypted and/or pseudorandom data. Disk quotas can be set to limit data storage. *Requires EFT Server Enterprise. **Requires HSM |
|
3.2 Do not store sensitive authentication data after authorization (even if encrypted). |
Authentication data is only persisted in memory for the duration of the session. |
|
3.3 Mask PAN when displayed |
Not applicable to EFT Server. |
|
3.4 Render PAN, at minimum, unreadable anywhere it is stored. |
Encrypt PAN or other sensitive data using EFT Server’s optional OpenPGP encryption module or 3rd-party disk encryption utilities. |
|
|
3.4.1 If disk encryption is used (rather than file- or column-level database encryption), logical access must be managed independently of native operating system access control mechanisms. |
EFT Server will detect and warn if Microsoft Encrypting File System (EFS) is being used. *Requires HSM and creation of a PCI DSS Site |
3.5 Protect any keys used to secure cardholder data against disclosure and misuse. |
Only sub-administrators who have been specifically granted access can create, access, or manage PGP key pairs, SSL certificates, and SSH public keys. NOTE: Limited administrator roles available to EFT Server standard version |
|
3.6 Document and implement all key management processes and procedures |
Requires measures external to EFT Server. (Exception 3.6.1 below) |
|
|
3.6.1 Generation of strong cryptographic keys |
EFT Server 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. *Requires HSM and creation of a PCI DSS Site. |
|
3.6.2 - 3.6.8 Various key management requirements. |
Requires measures external to EFT Server. |
PCI DSS Requirement |
How Requirement is Addressed with EFT Server |
4.1 Use strong cryptographic ciphers for transport protocols |
Secure protocols such as SSL, TLS, and SFTP (SSH2) are provided for data transmission. For PCI DSS-enabled sites, SSL is restricted* to versions v3 or higher, and ciphers to minimum of 128 bits. Secure data transmission is enforced* by automatically redirecting incoming HTTP traffic to HTTPS. *Requires HSM |
4.2 Never send unencrypted PANs by e-mail. |
Requires measures external to EFT Server. |
PCI DSS Requirement |
How Requirement is Addressed with EFT Server |
5.1 Deploy anti-virus software on all systems commonly affected by malicious software. |
Requires measures external to EFT Server; however EFT Server can integrate with most AV tools. |
5.2 Ensure that all anti-virus mechanisms are current, actively running, and capable of generating audit logs. |
Requires measures external to EFT Server. |
PCI DSS Requirement |
How Requirement is Addressed with EFT Server |
|
6.1 Ensure that all system components and software are protected from known vulnerabilities by having the latest vendor-supplied security patches installed. Install critical security patches within one month of release. |
The latest version of EFT Server is always available made available online. |
|
6.2 Establish a process to identify and assign a risk ranking to newly discovered security vulnerabilities. |
GlobalSCAPE has formal processes for dealing with potential security vulnerabilities discovered in EFT Server, including an escalation process, a risk assessment that includes Common Vulnerability Scoring System (CVSS) risk ranking, and a process for notifying customers of patches or workarounds. |
|
6.3 Develop software applications (internal and external, and including web-based administrative access to applications) in accordance with PCI DSS. |
EFT Server when bundled with the HSM was designed to comply with relevant PCI DSS and FIPS 140-2 requirements. 6.3.1 and 6.3.2 only apply to Professional Services engagements and should be verified prior to deployment. |
|
|
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 Server. |
|
6.5 - 6.5.9 Develop all web applications based on secure coding guidelines, such as Open Web Application Security Project Guidelines. Review custom application code to identify coding vulnerabilities. Cover prevention of common coding vulnerabilities in software development processes. |
EFT Server is constantly evaluated and tested for security vulnerabilities and exploits. Any problems found are ranked, remediated, and where applicable, communicated to our customers. Internal and external security standards and guidelines (such as OWASP) are referenced when developing new functionality. |
|
6.6 For public-facing web applications, address new threats and vulnerabilities on an ongoing basis… |
Requires customer to run security scan; however GlobalSCAPE also performs routine 3rd party security scans of EFT Server’s web (public facing) interfaces as part of its quality assurance process. |
PCI DSS Requirement |
How Requirement is Addressed with EFT Server |
7.1 Limit access to system components and cardholder data to only those individuals whose job requires such access. |
The EFT Server administrator is given complete control over managing which resources can be accessed by users or sub-administrators. |
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 permission groups, virtual folders, and settings templates. Delegated administrators or help-desk users can be granted varying levels of control over server settings and resources. |
PCI DSS Requirement |
How Requirement is Addressed with EFT Server |
|
8.1 Assign all users a unique ID before allowing them to access system components or cardholder data. |
EFT Server always enforces unique usernames. |
|
8.2 In addition to assigning a unique ID, employ at least one of the following methods to authenticate all users:
|
EFT Server supports various combinations of password, certificate, and public-key authentication mechanisms. EFT Server Enterprise adds two-factor authentication including RADIUS and RSA SecurID. |
|
8.3 Incorporate two-factor authentication for remote access. |
EFT Server Enterprise supports two-factor authentication including RADIUS and RSA SecurID. |
|
8.4 Render all passwords unreadable during transmission and storage on all system components using strong cryptography. |
All user authentication passwords are stored as a one-way, non-reversible, salted hash. Authentication credentials for recurring automated sessions are stored using strong encryption. |
|
8.5 Ensure proper user identification and authentication management for non-consumer users and administrators on all system components as follows: |
See sub-requirements for specific implementation. |
|
|
8.5.1 Control addition, deletion, and modification of user IDs, credentials, and other identifier objects |
Only privileged sub-administrators are permitted to add and remove users and set user permissions. |
|
8.5.2 Verify user identity before performing password resets |
User authentication is required prior to a user-initiated password reset*. *Requires HSM |
|
8.5.3 Set passwords for first-time use and resets to a unique value for each user and change immediately after the first use. |
EFT Server can force users to change their passwords to a unique value upon initial login. *Requires HSM |
|
8.5.4 Immediately revoke access for any terminated users |
When a Server account is disabled, expired, or removed, the user can no longer access EFT Server. |
|
8.5.5 Remove/disable inactive user accounts at least every 90 days. |
EFT Server can disable or remove inactive users after a specified period of time (set to 90 days by default). *Requires HSM |
|
8.5.6 Enable accounts used by vendors for remote access only during the time period needed. Monitor vendor remote access accounts when in use. |
User accounts can be configured to automatically expire on any specified date. |
|
8.5.7 Communicate authentication procedures and policies to all users who have access to cardholder data. |
User’s credentials can be automatically emailed to a specified email address. The default text of the message can be customized to include your organization’s password policies and procedures. |
|
8.5.8 Do not use group, shared, or generic accounts and passwords, or other authentication methods. |
The “Anonymous” password type is disallowed when running in PCI DSS mode. *Requires HSM |
|
8.5.9 Change user passwords at least every 90 days |
Automatic expiration* of passwords can be enabled for administrators and users. Automatic email reminder* for pending expiration also provided. *Requires HSM |
|
8.5.10 Require a minimum password length of at least seven characters |
Complex passwords can be enforced using multiple criteria, including minimum length, definition of alphanumeric sub-options, disallowing words contained in a dictionary file, disallowing the username as the password, disallowing cyclical passwords and others. |
|
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. |
EFT Server prevents the reuse of prior passwords for administrators and users (compares hash values, not actual passwords). |
|
8.5.13 Limit repeated access attempts by locking out the user ID after not more than six attempts. |
Repeated access attempts can be limited by locking out a user or an administrator. The settings for lockout—the number of failed attempts and the elapsed time between failed attempts—are fully customizable. The lockout duration can be set to 30, 60 or 90. EFT Server will warn* if these limits are disabled or set to a non-compliant value. *Requires HSM |
|
8.5.14 Set the lockout duration to thirty 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-authenticate to re-activate the terminal or session. |
An idle timeout setting is applied across all connection protocols supported, for both users and administrators. |
|
8.5.16 Authenticate all access to any database containing cardholder data. This includes access by applications, administrators, and all other users. Restrict user direct access or queries to databases to database administrators. |
Requires measures external to EFT Server. |
PCI DSS Requirement |
How Requirement is Addressed with EFT Server |
|
9.1 - 9.9 Use appropriate facility entry controls to limit and monitor physical access to systems that store, process, or transmit cardholder data. |
Requires measures external to EFT Server. |
|
9.10 - 9.10.1 Destroy media when it is no longer needed for business or legal reasons. |
Primarily deals with physical media, except for sub-requirement 9.10.2 |
|
|
9.10.2 Render cardholder data on electronic media unrecoverable so that cardholder data cannot be reconstructed. |
EFT Server includes a data-wiping algorithm for sanitizing deleted data on disk. *Requires HSM |
PCI DSS Requirement |
How Requirement is Addressed with EFT Server |
10.1 Establish a process for linking all access to system components (especially access done with administrative privileges such as root) to each individual user. |
Preconfigured reports of all activity (including administrator actions*) within EFT Server can be generated on demand with the Auditing and Reporting Module (ARM) *Requires ARM and HSM. |
10.2 Implement automated audit trails for all system components to reconstruct the following events: |
EFT Server 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. *Requires ARM and HSM |
10.3 Record at least the following audit trail entries for all system components |
EFT Server 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 Server. |
10.5 Secure audit trails so that they cannot be altered. |
Audited data integrity depends on the chosen database solution and authentication architecture. EFT Server supports auditing* to a central SQL or Oracle** server. *Requires ARM **Requires EFT Server Enterprise |
10.6 Review logs for all system components at least daily… |
A daily PCI DSS Compliance report* can be generated and sent via email to the appropriate recipient(s). This report details the PCI DSS compliance status of each security element monitored by the HSM. The report includes the recorded reason (compensating control) for any non-compliant setting. *Requires both ARM and HSM |
10.7 Retain audit trail history for at least one year… |
Requires measures external to EFT Server. |
PCI DSS Requirement |
How Requirement is Addressed with EFT Server |
11.1 - 11.5 Requirements relating to regular testing of security systems and processes. |
Requires measures external to GlobalSCAPE High Security Module defined by your organizational policy. |
PCI DSS Requirement |
How Requirement is Addressed with EFT Server |
12.1 - 12.9 These requirements have to do with maintaining a policy that addresses information security for all personnel. |
Requires measures external to GlobalSCAPE High Security Module defined by your organizational policy. |