Here are the influential voices leading the conversations where nonprofits and technology overlap.
The Payment Card Industry Data Security Standard (PCI DSS) was created to reduce credit and debit card fraud by improving information security controls at businesses, government agencies and other organizations that accept credit and debit card payments. However, the PCI DSS standard involves more than the security of card information.
It was developed with the understanding that keeping card information secure necessarily means securing the networks and systems that are logically connected to the systems directly processing or storing credit and debit card information. The standards were also designed to ensure that security measures protect against both intentional and inadvertent (human error) breaches.
Before the PCI DSS, security standards were specific to particular card brands, which meant that an organization accepting payments for different brands had to adhere to several different security standards. Accordingly, PCI DSS was developed to provide a single standard for the major card brands: Visa, MasterCard, American Express, Discover and JCB International.
The companies behind these brands, along with other industry leaders, formed the PCI Security Standards Council (SSC), which focuses on creating, disseminating and maintaining security standards related to payment cards and applications. The original version of the PCI DSS took effect in 2005.
PCI DSS v.2.0 is valid only through the end of 2014. Because the PCI SSC recently changed to a three-year standards development lifecycle for the standard, PCI DSS v.3.0 will be the current version through at least the end of 2016. Organizations that haven’t already started migrating to the new standard will have to do so in the coming months.
PCI DSS has the typical components of a technical standard: It defines common terminology, provides some overall guidelines for using the standard and then describes the technical requirements organizations must adhere to. PCI DSS v.3.0 has six major security control areas, with 12 top-level requirements directly under those six areas and hundreds of detailed technical requirements in a hierarchy under the top-level requirements.
The areas and top-level requirements defined in the PCI DSS Requirements and Security Assessment Procedures Version 3.0 document cover the following areas:
Design, implement and maintain secure systems and networks
Protect cardholder data through firewall rule sets (Note: Cardholder data is formally defined by PCI DSS as the primary account number or PAN, cardholder name, expiration date [and] service code.)
Change default passwords and other security settings
Safeguard cardholder data
Safeguard cardholder data stored on systems
Safeguard cardholder data in transit on external networks
Maintain anti-malware controls for all systems
Ensure that the design, implementation and operation of systems and their applications are secure
Implement access control
Limit logical access to cardholder data
Uniquely identify users and authenticate them before granting access to systems
Limit physical access to cardholder data
Manage systems and networks
Monitor access to systems and networks, including cardholder data
Test security controls
Develop and regularly update information security policy
A relatively simple example of a detailed technical requirement under requirement 3 is: “3.5.1 Restrict access to cryptographic keys to the fewest number of custodians necessary.”
Accompanying this requirement is a testing procedure: “Examine user access lists to verify that access to keys is restricted to the fewest number of custodians necessary.” The requirement also has guidance listed for it: “There should be very few who have access to cryptographic keys (reducing the potential for rending cardholder data visible by unauthorized parties), usually only those who have key custodian responsibilities.” So each lower-level requirement in PCI DSS also provides information on how to verify that the requirement is being met, as well as a rationale for having the requirement.
Want to learn more? Check out CDW’s white paper, “Evolving Security Efforts to Meet PCI DSS v.3.0.”