Overview of PCI DSS
You don’t have to look far to find news of a breach affecting payment card information. Breaches happen every day, largely due to cyberattacks or, more likely, to the loss, theft or careless handling of computers, USB drives, and paper files that contain unsecured payment data. Once this data gets into the hands of a malicious actor, it can be used to commit fraud by making illicit purchases or money withdrawals. In response to increased threats to payment card data, the five major payment brands American Express, Discover, MasterCard, Visa, and JCB formed the Payment Card Industry Security Standards Council (PCI SSC) in 2004.
Their goal was to control the burgeoning levels of payment card fraud and to enhance payment card security. The PCI SSC developed the Payment Card Industry Data Security Standard (PCI DSS) as a detailed and comprehensive standard set of minimum security requirements for cardholder data. While PCI is not a law, any merchant or service provider that handles payment card data must meet PCI requirements in order to accept payment cards. The industry regulations took effect in June 2005 and apply to organizations all around the world.
PCI DSS is an actionable framework for building and maintaining security around covered entities’ payment system environments and the data they process and store. The payment card brands themselves enforce compliance with the security standard for the merchants and service providers that accept their branded forms of payment. Penalties for non-compliance vary – especially in the face of a breach – but can include fines, increased scrutiny of computer systems, potential suspension or expulsion from card processing networks, and liability for fraud charges and related costs.
What organizations PCI applies to
PCI applies to all organizations or merchants, regardless of size or number of transactions, that accept, transmit, process or store any cardholder data. This includes companies or organizations that accept payment cards in person, online, over the phone, or on printed forms.
The extent to which an organization needs to implement, maintain, and verify PCI DSS controls depends on the number of card transactions it handles in a year. There are four “merchant levels,” ranging from Level 4, which includes organizations that process a very small number of transactions annually, to Level 1, which handles multiple millions of transactions or more each year. (The merchant level definitions vary by card brand.)
The top requirements of PCI DSS
The PCI Data Security Standard is a multifaceted security standard that includes requirements for security management, policies, procedures, network architecture, software design, and other critical protective measures. PCI DSS is comprised of 12 general requirements designed to build and maintain a secure network and systems; protect cardholder data; ensure the maintenance of vulnerability management programs; implement strong access control measures; regularly monitor and test networks; and ensure the maintenance of information security policies.
Build and maintain a secure networks system
1. Install and maintain a firewall configuration to protect cardholder data
All systems must be protected from unauthorized access from untrusted networks, whether entering the system via the Internet as e-commerce, employee Internet access through desktop browsers, employee email access, dedicated connections such as business-to-business connections, via wireless networks, or via other sources. Often, seemingly insignificant paths to and from untrusted networks can provide unprotected pathways into key systems. Firewalls are a key protection mechanism for any computer network.
2. Do not use vendor-supplied defaults for system passwords and other security parameters
Malicious individuals (external and internal to an entity) often use vendor default passwords and other vendor default settings to compromise systems. These passwords and settings are well known by hacker communities and are easily determined via public information.
Protect cardholder data
3. Protect stored cardholder data
Protection methods such as encryption, truncation, masking, and hashing are critical components of cardholder data protection. If an intruder circumvents other security controls and gains access to encrypted data, without the proper cryptographic keys, the data is unreadable and unusable to that person. Other effective methods of protecting stored data should also be considered as potential risk mitigation opportunities. For example, methods for minimizing risk include not storing cardholder data unless absolutely necessary, truncating cardholder data if full PAN is not needed, and not sending unprotected PANs using end-user messaging technologies, such as email and instant messaging.
4. Encrypt transmission of cardholder data across open, public networks
Sensitive information must be encrypted during transmission over networks that are easily accessed by malicious individuals. Misconfigured wireless networks and vulnerabilities in legacy encryption and authentication protocols continue to be targets of malicious individuals who exploit these vulnerabilities to gain privileged access to cardholder data environments.
Maintain a vulnerability management program
5. Protect all systems against malware and regularly update anti-virus software or programs
Malicious software, commonly referred to as “malware”—including viruses, worms, and Trojans—enters the network during many business-approved activities including employee email and use of the Internet, mobile computers, and storage devices, resulting in the exploitation of system vulnerabilities. Anti-virus software must be used on all systems commonly affected by malware to protect systems from current and evolving malicious software threats. Additional anti-malware solutions may be considered as a supplement to the anti-virus software; however, such additional solutions do not replace the need for anti-virus software to be in place.
6. Develop and maintain secure systems and applications
Unscrupulous individuals use security vulnerabilities to gain privileged access to systems. Many of these vulnerabilities are fixed by vendor-provided security patches, which must be installed by the entities that manage the systems. All systems must have all appropriate software patches to protect against the exploitation and compromise of cardholder data by malicious individuals and malicious software.
Implement strong access control measures
7. Restrict access to cardholder data by business need-to-know
To ensure critical data can only be accessed by authorized personnel, systems and processes must be in place to limit access based on need to know and according to job responsibilities. “Need to know” is when access rights are granted to only the least amount of data and privileges needed to perform a job.
8. Identify and authenticate access to system components
Assigning a unique identification (ID) to each person with access ensures that each individual is uniquely accountable for their actions. When such accountability is in place, actions taken on critical data and systems are performed by, and can be traced to, known and authorized users and processes.
9. Restrict physical access to cardholder data
Any physical access to data or systems that house cardholder data provides the opportunity for individuals to access devices or data and to remove systems or hardcopies, and should be appropriately restricted.
Regularly monitor and test networks
10. Track and monitor all access to network resources and cardholder data
Logging mechanisms and the ability to track user activities are critical in preventing, detecting, or minimizing the impact of a data compromise. The presence of logs in all environments allows thorough tracking, alerting, and analysis when something does go wrong. Determining the cause of a compromise is very difficult, if not impossible, without system activity logs.
11. Regularly test security systems and processes
Vulnerabilities are being discovered continually by malicious individuals and researchers, and being introduced by new software. System components, processes, and custom software should be tested frequently to ensure security controls continue to reflect a changing environment.
Maintain an information security policy
12. Maintain a policy that addresses information security for all personnel
A strong security policy sets the security tone for the whole entity and informs personnel what is expected of them. All personnel should be aware of the sensitivity of data and their responsibilities for protecting it.
Source: PCI Security Standards Council
Encryption requirements for PCI DSS
PCI is one regulation that explicitly calls for encryption of cardholder data and the communication paths the data will travel over. PCI DSS is very specific and detailed about the required use of encryption in the cardholder data environment (CDE) as well as the proper rotation of encryption keys. Consult the document Requirements and Security Assessment Procedures, Version 3.1, April 2015 in the PCI Documents Library for full details.
Tokenization is another data masking technique that is commonly used for PCI compliance. Tokens are used in place of primary account numbers (PANs) in situations such as storing card-related information after a transaction is complete. Tokens provide the added benefit of reducing the CDE such that the annual PCI audit process is easier to complete.
Disclaimer: McAfee products and services may provide features that support and enhance your industry’s Payment Card Industry Data Security Standard compliance obligations however, they are neither designed nor intended as Payment Card Industry Data Security Standard compliance solutions. The information provided herein is for information purposes only and does not constitute legal advice or advice on how to meet your compliance obligations.
Security and encryption requirements for GLBA
Section 501 of the GLBA, “Protection of Nonpublic Personal Information,” requires financial institutions to establish appropriate standards related to the administrative, technical, and physical safeguards of customer records and information. The scope of these safeguards is defined in the GLBA Data Protection Rule, which states that financial institutions must:
- Ensure the security and confidentiality of customer data
- Protect against any reasonably anticipated threats or hazards to the security or integrity of such data
- Protect against unauthorized access to, or use of, such data that would result in substantial harm or inconvenience to any customer
Many federal agencies oversee financial institutions, and the Federal Financial Institutions Examination Council (FFIEC) designs and supervises audits for the majority of them. The FFIEC publishes the IT Examination Handbook, which provides guidance for the IT security controls that can or should be used to protect nonpublic information under GLBA.
According to the IT Examination Handbook, financial institutions should employ encryption to mitigate the risk of disclosure or alteration of sensitive information in storage and transit. Encryption implementations should include:
- Encryption strength sufficient to protect the information from disclosure until such time as disclosure poses no material risk
- Effective key management practices
- Robust reliability
- Appropriate protection of the encrypted communication’s endpoints
Disclaimer: McAfee products and services may provide features that support and enhance your industry’s Gramm-Leach-Bliley Act compliance obligations however, they are neither designed nor intended as Gramm-Leach-Bliley Act compliance solutions. The information provided herein is for information purposes only and does not constitute legal advice or advice on how to meet your compliance obligations.