You might be aware of the Payment Card Industry (PCI) Data Security Standard (DSS) for credit card processors and merchants. Maybe you’re already in compliance with it—or perhaps you’re working toward compliance and wondering what the recent PCI DSS 1.1 update means for your efforts. If you’re unfamiliar with PCI DSS, you might want to know whether and how it affects your organization.
First, who has to comply with PCI DSS? If your company accepts or processes credit cards in any part of its business, the standard affects you as the systems administrator. PCI DSS is an effort by banks and other institutions that issue and process credit cards, debit cards, and other kinds of electronic payment forms to require companies that process payment through these institutions to maintain a minimum standard of data security for cardholders’ information. PCI DSS establishes a standard for electronic security and requires member firms and their customers to comply with this standard.
Identity fraud has reached epidemic proportions. Every day, network breaches occur that involve the theft or loss of massive amounts of personal customer information, usually including credit card numbers or other financial information. In response to public outcry, Congress and various state governments have discussed passing laws regulating the credit card industry and its customers. PCI DSS began as a partnership between major credit card providers and the issuing banks as an effort to prevent identity fraud and avoid government involvement. The standard used to be voluntary—merely a set of guidelines and suggestions. However, when CardSystems, one of the world’s largest credit card processors, went bankrupt after a huge security leak allowed the theft of more than 40 million credit cards, the big players in the industry realized that tougher and mandatory standards were necessary. Thus, a consortium of credit card providers revised PCI DSS, and compliance is now a part of their contracts. PCI DSS now applies to issuing banks, middlemen providing clearing services, and merchants using the system to process charges. Even individuals with small Web sites that use e-commerce are contractually obligated to comply with the standard and keep their networks secure.
Depending on your role in this process and your organization’s volume of charges, the standard requires different levels of compliance and verification. If you process a sufficient level of charges, you must obtain a third-party scan of your network to verify its security. The lowest-volume merchants aren’t required to verify their compliance. However, according to most card merchant contracts, even Grandma selling her paintings from her tiny Web site can be held liable if a breach occurs and she isn’t PCI DSS compliant.
PCI DSS 1.1 Requirements
Many PCI DSS elements are general and represent steps you should already be taking to maintain a secure network. However, some of the requirements are quite specific and involve verification for certain providers either through onsite audits or electronic scans. PCI DSS has the following 12 requirements, grouped into 6 logical groups called control objectives.
- Build and Maintain a Secure Network
1. Install and maintain a firewall configuration to protect cardholder data
2. Don’t use vendor-supplied defaults for system passwords and other security parameters - Protect Cardholder Data
3. Protect stored cardholder data
4. Encrypt transmission of cardholder data across open, public networks - Maintain a Vulnerability Management Program
5. Use and regularly update antivirus software
6 . Develop and maintain secure systems and applications - Implement Strong Access Control Measures
7. Restrict access to cardholder data by business need-to-know
8. Assign a unique ID to each person with computer access
9. Restrict physical access to cardholder data - Regularly Monitor and Test Networks
10. Track and monitor all access to network resources and cardholder data
11. Regularly test security systems and processes - Maintain an Information Security Policy
12. Maintain a policy that addresses information security
The following sections highlight these groups and the individual requirements within each group. I summarize each requirement and offer strategies for how your company can comply with the standard. For a complete summary of PCI DSS, go to the PCI Security Standards Council Web site (https://www.pcisecuritystandards.org/tech/download_the_pci_dss.htm).
Build and Maintain a Secure Network
Requirement 1: Install and maintain a firewall configuration to protect cardholder data. On the surface, this requirement seems obvious. However, the requirement is rather complicated when you try to determine what it means to “protect cardholder data.” Standard firewall rules aren’t strong enough; the requirement details specify more restrictive rules relating to Web sites and payment card systems. If you use a third-party Web site such as Yahoo Merchant Solutions to clear transactions, that Web site’s online security probably covers you. However, you might still need to submit a copy of the security audit or scan report to provide proof of the Web site’s compliance. If you manage the firewall between your payment application and the Internet, you need to tightly limit outside connections other than on the necessary ports (e.g., HTTP, HTTPS). Shut down non–Web-related ports, especially unsafe ones such as Telnet and FTP. If you must use these protocols, be prepared to justify their use. Consider setting up a machine on your demilitarized zone (DMZ) as a go-between, to allow access to these protocols only from inside the firewall. Also, if you don’t have sales in certain parts of the world, you can block huge sets of IP addresses assigned to international sites. See the Internet Assigned Numbers Authority ( IANA) Web site (http://www.iana.org) for a list of IP address blocks. For more information about IP address blocking, see “Geo-IP Blocking with IP Tables: Some Common Sense Firewall Rules,” at http://www.samag.com/documents/s=9367/sam0511c/0511c.htm.
Requirement 2: Don’t use vendor-supplied defaults for system passwords and other security parameters. This requirement is elementary; anyone who is using vendor passwords on a Web-facing system has probably already been hacked. However, you can take the requirement to a higher level and apply it to other network devices inside your firewall and on the same network as your Web server, such as switches and routers. Hackers can use this exploit to launch a Denial of Service (DoS) attack on your system. You need to change all your wireless default settings because wireless security is an important part of the standard. The SNMP service often has default community strings, which are akin to passwords and can leak sensitive information about your network. Another big security risk is database applications such as Microsoft SQL Server. SQL Server servers can be installed with the default sa account, which allows top-level access. You need to lock down these important applications both externally and internally.
Protect Cardholder Data
Requirement 3: Protect stored cardholder data. Although this requirement seems vague, the standard addresses ways to protect stored data—specifically, how you encrypt important parts of your database and how you handle the data. Data that requires special attention includes the primary account number (PAN), security code (i.e., the three- or four-digit number that online retailers often ask for), expiration date, and user’s ZIP code. Most providers encrypt these fields in their database so that card data isn’t lost if the database is compromised. Another trick is to use separate logical and physical databases for the card numbers and security codes. The card number and security code together are like gold for an online thief; separating them prevents thieves from using the information they steal.
Requirement 4: Encrypt transmission of cardholder data across open, public networks. This requirement is obvious. If you aren’t using Secure Sockets Layer (SSL) for your Web site, you need to be banished back to 1994. But even if you are, you need to check your certificates to ensure they’re correct and up-to-date, and you need to check the version of SSL you’re running—some early versions have flaws that hackers can easily exploit; a security scan by a reputable vendor will highlight these vulnerabilities. PCI DSS also requires you to secure and rotate your encryption keys. The typical set-and-forget practice isn’t acceptable.
Maintain a Vulnerability Management Program
Requirement 5: Use and regularly update antivirus software. You should already be using antivirus software that you update regularly—if not, you’re probably too busy fighting viruses to read this article. Additional protection that you need includes network-based virus and attachment interdiction. PCI DSS 1.1 adds section 5.11 to the antivirus requirement, mandating the supplementary use of antispam and antispyware software. This software might be included with your antivirus package, or you can use a separate product such as Microsoft Windows Defender or GFI MailEssentials. Freeware packages such as Lavasoft’s Ad-Aware and PepiMK Software’s Spybot Search & Destroy are also available; however, these options lack the manageability and scalability of the integrated packages.
Requirement 6: Develop and maintain secure systems and applications. Parts of this requirement don’t apply to you if you aren’t developing your e-commerce application inhouse. However, you aren’t totally off the hook. All companies must comply with some of this requirement’s elements—for example, section 6.2 requires that you maintain a patch management program and section 6.4 requires a strong change control policy. If you do develop inhouse, you must follow several specific requirements. PCI DSS 1.1 adds section 6.6, which requires that you have all code independently reviewed for vulnerabilities. Adding an application-level firewall in front of your Web server lets you sidestep this requirement. Because having all code independently reviewed can be costly and unpredictable, most companies opt for the firewall. Web application layer firewalls are readily available from several vendors and the open-source community (e.g., NetContinuum’s Web Application Firewall, Breach Security’s ModSecurity). They’re much cheaper than they used to be, and they’re now relatively easy to configure.
Implement Strong Access Control Measures
Requirement 7: Restrict access to cardholder data by business need-to-know. This requirement is tricky to comply with and calls for strong internal controls and information asset classifications. Basically the requirement stipulates that your card databases shouldn’t be accessible to everyone in the company. You can use Active Directory (AD) Group Policy to create granular access groups. Dual control is also a good idea for database access and modification so that developers and network administrators don’t have too much power.
Requirement 8: Assign a unique ID to each person with computer access. This rule is all too often the exception when multiple people use a machine or perform a job. However, violating this rule can destroy the audit trail if a problem occurs. But even systems administrators shouldn’t be exempt from this requirement. Create a separate ID for each systems administrator, and have each administrator use his or her ID for day-to-day administrator duties. Closely control the top-level administrator account and use it only in urgent cases. Apply your standard password policies to both administrator and regular user accounts. For the highest degree of security, consider using AD delegation to implement least privilege rather than giving anyone domain administrator authority.
Requirement 9: Restrict physical access to cardholder data. This requirement involves maintaining strong physical and environmental security for your database servers—which you’re probably already doing. If you store your servers at a co-location facility, that facility’s physical security probably covers your servers. However, PCI DSS 1.1 Appendix A specifies that your hosting providers meet certain requirements. If you host your own servers, you need to store them in a safe, cool area that has limited access and is away from regular work areas.
Regularly Monitor and Test Networks
Requirement 10: Track and monitor all access to network resources and cardholder data. The key to complying with this requirement is to keep accurate logs and review them on a regular basis. Too many administrators let their logs grow indefinitely without ever reviewing them because they’re intimidated by the huge cryptic files. Several programs are available to help you wade through your log files and make sense of the data (e.g., GFI EventsManager, Prism Microsystems’ EventTracker, RippleTech’s LogCaster, TNT Software’s Event Log Manager—ELM). In addition, running a network intrusion detection system (IDS) inside your network is a good defense-in-depth measure that protects against firewall breaches and internal bad guys.
Requirement 11: Regularly test security systems and processes. This requirement means that some providers must submit to independent network testing. To find an approved scanning vendor (ASV), see the PCI Security Standards Council ASV document (https://www.pcisecuritystandards.org/pdfs/pci_asv_list.pdf). Providers also need to run their own internal tests—and more importantly, they need to remediate the problems they find. Too often, companies don’t act on test results because they don’t have the time or resources to fix the problems. You must deal with security problems on a timely basis even if you need to bring in outside help. Partially complying with this requirement is as bad as ignoring it altogether.
Maintain an Information Security Policy
Requirement 12: Maintain a policy that addresses information security. Many small organizations don’t adhere to this common-sense requirement. A sound security policy is the backbone of a successful security program, and a simple security policy helps inform your vendors, employees, and upper management of your security approach and requirements. For more information about creating a secure environment, see Charles Cresson Wood, Information Security Policies Made Easy (Information Shield).
Even if your own networks are tight, outside organizations that connect to your networks can be your Achilles’ heel. PCI DSS 1.1 adds section 12.10, which says that you must ensure the security of connected entities. This section has several subsections that might cause a lot of work for some companies—specifically, the section states that you must:
- Maintain a list of entities that are network connected to the organization
- Perform the proper due diligence on these entities before allowing them to connect
- Ensure that any connected entities are also PCI DSS compliant
- Have a process for connecting and disconnecting entities
- Have employees read and sign that they understand the security policy and will comply with it
Stay Out of the News
Complying with PCI DSS might seem daunting. However, the standard includes many requirements that you’re probably already following. You might just need some additional documentation or better protection in a particular area. But whether adhering to PCI DSS means small network changes or a whole new way of doing business, complying with the standard is no longer optional. You need to keep abreast of the standard’s updates and manage your network accordingly. Following PCI DSS will make your e-commerce business run more smoothly and will ensure that it stays out of the headlines.
