FTP Server PCI Compliance
Serv-U MFT Server meets the inbound/outbound traffic and data at rest requirements in PCI DSS 2.0 through the use of an architecture that utilizes Serv-U Gateway as a reverse proxy. It also meets other PCI DSS 2.0 requirements as detailed below.
Serv-U Gateway meets
PCI DSS 2.0 requirements.
Serv-U Gateway is
Serv-U’s reverse proxy.
Both Serv-U and Serv-U
Gateway can be clustered for HA.
Serv-U PCI DSS 2.0 Guide
Use this guide to deploy Serv-U when it will be in scope of PCI audit. Many PCI DSS items are related to your policy and procedures (and have thus been omitted here) but many are applicable to software to such as Serv-U.
Req #1: Install and maintain a firewall configuration to protect cardholder data
1.1 - Plan and document the firewall and router configuration
1.2 - Restrict connections between untrusted networks
- Use Serv-U Gateway to terminate inbound connections in the DMZ and avoid any inbound connections to the internal network.
1.3 - Prohibit direct access from the Internet
- Use Serv-U Gateway to avoid direct access between the Internet and system components in the internal cardholder network, and to avoid exposure of internal IP addresses.
Req #2: Do not use vendor-supplied defaults for system passwords and other security parameters
2.1 - Change vendor defaults
- Serv-U only uses vendor defaults during unattended installations, and these can be changed after installation.
2.2 - Apply hardening to system components, isolate/minimize functionality
- Serv-U supports systems hardened to specifications from CIS, ISO, SANS and NIST
- Serv-U’s tiered architecture isolates interface (e.g., FTPS or HTTPS), application and data layers using Serv-U Gateway, Serv-U and a back-end database or Active Directory.
- Though it provides web services, Serv-U does not use IIS, Apache, Tomcat or any other general-purpose application server.
2.3 - Encrypt all remote administrative access
- Serv-U uses HTTPS secured by 128- to 256-bit SSL/TLS to secure its administrative interface.
Req #3: Protect stored cardholder data
3.1 - Enforce data retention and disposal
- Use Serv-U event-driven automation to delete files as soon as they are downloaded.
- Use Serv-U’s FTP Voyager JV to manually locate data that exceeds requirements defined in your data retention policy.
3.2 - Avoid storing sensitive information
3.5 - Protect cryptographic keys
- Serv-U keys are stored in encrypted format.
3.6 - Implement good key management procedures
- Serv-U permits the creation of 2048 and 4096 bit keys.
Req #4: Encrypt transmission of cardholder data across open, public networks
4.1 - Use strong cryptography and security protocols to safeguard sensitive data during transmission
- Serv-U supports several secure protocols including FTPS, SFTP and HTTPS.
- Serv-U uses FIPS 140-2 validated cryptography to ensure fidelity
4.2 - Never send sensitive data by end-user messaging technologies
- Serv-U uses email but only for “file arrived” and similar notifications (and not data transmission).
Req #5: Use and regularly update anti-virus software and programs
5.1 - Deploy antivirus software
- Serv-U works with all major antivirus software packages to catch files before, during or just after transmission.
Req #6: Develop and maintain secure systems and applications
6.1 - Stay up to date on your patches
- Serv-U’s standard updates and support contract, included for one or two years with all new purchases, provides unlimited access to Serv-U patches. See our Recent Features page for our release policy and recent velocity.
- RhinoSoft is committed to isolating and releasing a supported patch to any confirmed Serv-U security vulnerability in real time. (Serv-U security patches take top development priority.)
6.3 - Develop software in accordance to PCI DSS and industry best practices
- RhinoSoft staff hold CISSP, CCSK and GSNA certification.
- Serv-U is developed with PCI DSS and industry best practices in mind.
6.4 - Use separate test and production elements and promote through change control
- Serv-U permits the import/export of configuration elements such as users between test and production environments.
6.5 - Develop based on secure coding guidelines, test against common vulnerabilities
- RhinoSoft staff hold CISSP, CCSK and GSNA certification.
- Serv-U architecture was completely redesigned in 2008 with secure coding in mind.
- Serv-U code is developed to prevent and tested against common vulnerabilities.
Req #7: Restrict access to cardholder data by business need to know
7.1 - Limit access to specific individuals through automation
- Serv-U integrates with your Active Directory domain and other authentication infrastructure to ensure that provisioning and deprovisioning activities apply immediately to Serv-U as well.
7.2 - Use fine grained access control and “deny all”
- Serv-U provides a fine-grained access control system with separate read, write, list and delete rights plus extra quota, bandwidth and alerts for all, groups of users or specific users.
Req #8: Assign a unique ID to each person with computer access
8.1 - Assign unique IDs
- Serv-U can support anonymous (shared user) access, but it is disabled by default.
8.2 - Use passwords or strong authentication
- Serv-U supports both single-factor and multi-factor authentication using passwords, and client keys.
8.3 - Use two-factor authentication for remote access
- Serv-U supports two-factor authentication using passwords plus a client key.
8.4 - Send and store passwords securely
- Serv-U uses secure protocols like FTPS, FTPS and HTTPS to securely exchange credentials.
- Serv-U stores keyed password hashes, not passwords, to prevent cleartext storage.
8.5 - Enforce proper user management and use automation when available
- Serv-U enforces password strength, retention and resets.
- Serv-U can automatically age, send notifications about and shut down old user accounts.
- Serv-U permits customization of banners to communicate authentication procedures and policies.
- Serv-U automatically locks out nuisance clients after too many attempts.
Req #9: Restrict physical access to cardholder data
Req #10: Track and monitor all access to network resources and cardholder data
10.2 - Implement automated audit trails
- Serv-U logs are extensive and every activity generates an entry.
10.3 - Ensure user ID, event type, timestamp, success/failure, origination and target ID appear in log entries.
- These elements appear in Serv-U log entries.
10.4 - Synchronize clocks on multiple systems
- Serv-U supports time synchronization performed by local Windows and Linux operating systems.
10.7 - Retain logs for a certain amount of time
- Serv-U includes automatic log rotation and retention settings for each domain.
Req #11: Regularly test security systems and processes
11.5 - Use file integrity utilities
- Serv-U installation files and executables are signed with an X.509 certificate to help detect unauthorized modifications or deployment of compromised software. See our Unauthorized Use page for more information.
- Serv-U software uses additional internal integrity checks to ensure that files it depends on are valid.
- Serv-U uses FIPS 140-2 cryptography, which, in part, means that an internal “self test” is performed during initialization of cryptography components to detect and prevent tampering.
Req #12: Maintain a policy that addresses information security for all personnel.
Appendix A: Additional PCI DSS Requirements for Shared Hosting Providers
A.1 - Protect each entity’s hosted environment and data
- Serv-U supports and is frequently deployed as a multi-homed system, where separate groups of administrators control their own domains (users, folders, permissions, etc.), and each domain is a separate logical unit.
- Serv-U also supports virtualization technology such as VMware where operating system units are used to separate different business units, partners or customers.
- Ask a Question