Recent statistics have shown that 42% of consumers feel that credit cards are the safest payment option to protect cardholder data for their online purchases. With more consumers focusing on purchasing online rather than via brick and mortar retailers, this means that online retailers must take extra care in monitoring their network resources as they pertain to their cardholder data. Consumers are well within their entitlement to expect that their credit card transaction is secure once it has been processed. However, that expectation might fall short if the pathways that the payment company develops does not securely transmit their cardholder data once the transaction goes through. It is for this reason (and many others) that securing access to network resources for any organization that processes and/or stores credit card payments is critical.
In this article, we will address three (3) of the twelve (12) Payment Card Industry Data Security Standards PCI-DSS requirements (3, 7, and 10). Following the completion of this article, your organization will be well equipped to adequately monitor network access to logs that include cardholder data as they pertain to the PCI DSS requirements.
PCI DSS Requirements
After years of credit card fraud in the 1990s, American Express, MasterCard, and Visa began developing their own individual standards for payment processing systems. Visa took the plunge first in 2001 and started the first Cardholder Information Security Program standard with the other companies creating and implementing their own company-specific security standards shortly afterwards. Each companys standards resulted in eye-opening results that concluded that merchants and POS terminals were ill-equipped to handle the massive threat of fraud that still ravished the credit card industry at that time.
Shortly after these results were accumulated, Visa, MasterCard, American Express, Discover and JCB created a joint venture to tackle these major DSS compliance issues. The initiation of the joint venture began as these payment card organizations released version 1.0 of the Payment Card Industry Data Security Standards (PCI DSS) in December 2004. The PCI DSS is administered and managed by the PCI Security Standards Council (SSC) which was launched on September 7, 2006 to manage the innovation of the PCI Data Security Standard (DSS) for which there are twelve (12) unique PCI-DSS requirements that help protect the safety of that data. The PCI DSS 12 requirements are as follows:
- Install and maintain afirewallconfiguration to protect cardholderdata.
- Do not use vendor-supplieddefaultsfor systempasswordsand other security parameters.
- Protectstored cardholder data.
- Encrypttransmission of cardholder data across open, public networks.
- Use and regularly updateantivirus software.
- Develop and maintain secure systems and applications.
- Restrict access to cardholder data by businessneed-to-know.
- Assign a unique ID to each person with computer access.
- Restrict physical access to cardholder data.
- Track and monitor all access to network resources and cardholder data.
- Regularly test security systems and processes.
- Maintain a policy that addresses information security.
Although the PCI SSC (The Council) oversees the long-term development of the 12 PCI Data Security Standards, it is still up to the payment brands and acquirers to be responsible for enforcing their own compliance. The Council does mandate that any organization that handles payment cards at the POS (including debit and credit cards) must comply with the 12 requirements directly or through a compensating control. The varying levels of compensating controls can only be allowed based on criteria that must be approved on a case-by-case basis by a PCI Qualified Security Assessor (QSA).
There are four (4) levels of vulnerability compliance standards, as outlined in the chart below. Each level is determined by the number of e-commerce transactions your organization processes per year. All merchants fall into one of the four levels based on their Visa transaction volume over a 12-month period. A merchants calculated transaction volume is based on the aggregate number of Visa transactions (inclusive of credit, debit and prepaid) from a merchant Doing Business As (DBA). Below is a chart that was developed to help merchants understand which level their organization falls under for compliance purposes:
PCI DSS 3.2 Levels |
||
| Level |
Affected Businesses |
Compliance Requirements |
| 1 |
More than 6 million annual transactions across all channels including e-commerce. |
Annual on-site PCI security assessments and quarterly network scans |
| 2 |
1 million to 5,999,999 annual transactions |
Annual security self-assessment and quarterly network scans |
| 3 |
20,000 to 1 million annual transactions |
Annual security self-assessment and quarterly network scans |
| 4 |
Fewer than 20,000 annual e-commerce transactions and all merchants across channel up to 1 million annual transactions. |
Annual security self-assessment and quarterly network scans |
There are cases where a single merchant has more than one DBA. For those instances, Visa acquirers must consider the aggregate volume of transactions stored, processed or transmitted by the corporate entity to determine the validation level. A PCI Qualified Security Assessor is responsible for validating a merchants current level of compliance and ascertain whether they have correctly implemented the required security controls, procedures, and policies per the PCI DSS requirements. When the time comes for a PCI QSA audit to commence, it is best that the merchant is currently compliant with the appropriate PCI DSS requirements as specified in the following subheadings.
Requirement 3
Requirement 3 pertains to the protection of stored cardholder data which applies only to those merchants who are actively storing cardholder data. Once a merchant begins storing cardholder data, it increases their risk of a data breach exponentially, hence the need for them to comply with this requirement. To be allowed to store cardholder data, a merchant must have a legitimate business reason for doing so. Once the reason for PCI cardholder data storage has been validated by the Council, the merchant can then only use certified PIN entry devices and payment applications in cardholder transactions.
Once data security compliance with PCI DSS requirement 3 has been achieved, the merchant should focus on developing a data retention and storage policy that limits storage amount and retention time for cardholder data. The cardholder data that can be stored would be that of the cardholders name, Primary Account Number (PAN), expiration date, and service code if they receive an adequate amount of security in accordance with PCI DSS requirements.
If a merchant can store cardholder data, it is best practice that they render their stored PAN unreadable with some type of cryptography solution. Another solution would be to fully encrypt the entire disk that the cardholder data is being stored on which ensures that the stored cardholder data can only be accessed natively through the internal operating system access controls. Using encrypted keys for these measures is best as well to document any access to the cardholder data and protect it from unintentional disclosure or misuse.
Requirement 7
PCI DSS Requirement 7 is put in place 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. The process of restricting access to cardholder data environments is critical. Most solutions pertaining to the restriction of controls focus on the development of Role-Based Access Controls (RBACs). This process limits access to only individuals with job titles that the merchant deems appropriate for accessing cardholder data. Any individual that is not on the list of authorized users is denied access on the spot.
If a merchant would rather not restrict access entirely, they could implement controls to merely limit access to authorized individuals on a need to know basis. This requires the merchant to not only define roles for access purposes but also update the job title when it is pertinent for the individual to be provided with or restricted from accessing cardholder data. Staying on top of these changes is of paramount importance to ensure that unintentional changes are not implemented that may lead to unauthorized access to a user account. Lastly, Requirement 7 requires merchants to develop and document security policies and procedures that allow all involved parties to review who is restricted to access to cardholder data at all times.
Requirement 10
The goal of PCI DSS Requirement 10 is to determine the who, what, where and when of users accessing your data processing resources, ensuring identity and access management. Implementing the specific data security standard processes allows the merchant to ascertain who is currently accessing their network and what their purpose for access is. If, for instance, cardholder data were to go missing, this critical could be utilized to pinpoint what data had been accessed and if foul play should be suspected as the reason for the breach. Overall, Requirement 10 covers many different sub-requirements that cover a variety of topics pertaining to ensuring individual access to cardholder data:
|
PCI DSS Requirement |
Notes |
| 10.1 |
Establish a process for linking all access to system components (especially access done with administrative privileges such as root) to each individual user. |
| 10.2 |
Implement automated assessment trails for all system components to reconstruct the following events: |
| 10.2.1 |
All individual user accesses to cardholder data. |
| 10.2.2 |
All actions taken by any individual with root or administrative privileges. |
| 10.2.4 |
Invalid logical access attempts. |
| 10.2.6 |
Initialization of the assessment logs. |
| 10.2.7 |
Reports on Audit Logs Cleared. |
| 10.5 |
Secure assessment trails so they cannot be altered. |
| 10.5.1 |
Limit viewing of assessment trails to those with a job-related need. |
| 10.5.2 |
Protect assessment trail files from unauthorized modifications. |
Requirement 10 demands that the merchant establish a process for linking all access to system components to each individual user. This can be difficult when some payments are made via non-digital means (i.e. telephone or mail). This requires specific internal controls be in place to provide authorization to those employees that require override access to safely authorize payment if they wish to access credit cards via that method.
If the merchant is unable to properly factor in all internal and external users into its logging mechanism, it can leave them unable to track the events of a breach timeline and/or pinpoint the responsibility for the breach. Understanding the specific actions that are being performed on the network via all administrative users must be done through a process that tracks and logs that individuals unique movements. When logs are implemented in the cardholder data environment (CDE), it allows the merchant to thoroughly track and analyze security breaches and be alerted when one occurs.
Before the implementation of PCI DSS, user logs were regarded as meticulous time wasters by most organizations because they did not consider it to be integral to the protection of cardholder data. These merchants instead opted to implement the most technologically advanced information systems without any understanding of how to log and monitor events that took place within that CDE. Without a process to track and monitor system activity logs, it became near impossible to determine the cause of compromise when one arose. Once PCI DSS was released on the payment card industry, merchants found that the development of these defined, wellstructured policies, procedures and practices allowed them to more easily track and audit events that were essential to the sustainability of their cardholder data environment.
Closing Thoughts
For more information on our PCI DSS compliance and other cybersecurity solutions, contact RSI Security today.
Download Our PCI DSS Checklist
Assess where your organization currently stands with being PCI DSS compliant by completing this checklist. Upon filling out this brief form you will receive the checklist via email.