The following specifies what you can and can't do with FTP (Link is from the PCI SSC site - FAQ section):
http://selfservice.talisma.com/display/2n/index.aspx?c=58&cpc=MSdA03B2IfY15uvLEKtr40R5a5pV2lnCUb4i1Qj2q2g&cid=81&cat=&catURL=&r=0.577978789806366 Is it permissible to use FTP if proper security measures are implemented? PCI DSS requirement 1.1.7 states that any risky protocols such as FTP must have documentation in place that defines the business justification for use and that appropriate security measures must be implemented. For example, secure FTP should be used, and FTP passwords and TELNET passwords used for non-console administrative access should be encrypted in transmission and in storage as prescribed in PCI DSS requirement 8.4 and 2.3 respectively. The documentation as well as implemented security measures should be reviewed by a Qualified Security Assessor (QSA) to ensure full effectiveness. The QSA will determine, among other things, that the selected approach is robust enough to withstand common attacks. For questions about whether a specific implementation is consistent with the standard or is "compliant" with a requirement, please contact a Qualified Security Assessor (QSA). A list of QSAs can be found at www.pcisecuritystandards.org/pdfs/pci_qsa_list.pdf<http://www.pcisecuritystandards.org/pdfs/pci_qsa_list.pdf>. As Rob Schramm noted, FTP is called out in the PCI DSS 1.2.1 Standard: Requirement 1.1.5, and Test 1.1.5b 1.1.5.b Identify insecure services, protocols, and ports allowed; and verify they are necessary and that security features are documented and implemented by examining firewall and router configuration standards and settings for each service. An example of an insecure service, protocol, or port is FTP, which passes user credentials in clear-text. Requirement 2.2.2 and Test 2.2.2 2.2.2 For a sample of system components, inspect enabled system services, daemons, and protocols. Verify that unnecessary or insecure services or protocols are not enabled, or are justified and documented as to appropriate use of the service. For example, FTP is not used, or is encrypted via SSH or other technology. More generally however, its ALL of Requirement 4 of the standard applies: Requirement 4: Encrypt transmission of cardholder data across open, public networks e.g. Requirement 4.1 and Test 4.1.a 4.1.a Verify the use of encryption (for example, SSL/TLS or IPSEC) wherever cardholder data is transmitted or received over open, public networks * Verify that strong encryption is used during data transmission * For SSL implementations: * Verify that the server supports the latest patched versions. * Verify that HTTPS appears as a part of the browser Universal Record Locator (URL). * Verify that no cardholder data is required when HTTPS does not appear in the URL. * Select a sample of transactions as they are received and observe transactions as they occur to verify that cardholder data is encrypted during transit. * Verify that only trusted SSL/TLS keys/certificates are accepted. * Verify that the proper encryption strength is implemented for the encryption methodology in use. (Check vendor recommendations/best practices.) -- ...phsiii Phil Smith III p...@voltage.com Voltage Security, Inc. www.voltage.com (703) 476-4511 (home office) (703) 568-6662 (cell) ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
