The main purpose of this article series is to survey the research that have been done in areas of PCI DSS compliance and recent developments of cloud computing. It gives an overview of basics of cloud computing, PCI DSS and specific compliance issues when dealing with outsourcing applications and infrastructure to third parties.
Nowadays many companies changed the way they doing business with the development of cloud computing. An ability to outsource application or entire infrastructure to the third parties allows businesses to take advantage of rapid and highly scalable deployment of services with little or no information technology expertise. Unfortunately, many enterprises are slow to adopt cloud computing because of information security compliance issues. Companies are skeptical about moving their sensitive information outside their own control perimeter, and see their main obstacle as an inability to check whether outsourced infrastructure and applications are in conflict with existing rules and regulations, such as PCI DSS.
The Payment Card Industry Data Security Standard (PCI DSS)
Payment Card Industry Data Security Standard (PCI DSS) is a standard that organizations must follow if their business involves processing, storing, and transmitting cardholder data. The main purpose of this standard is to provide requirements to ensure security of payment card data
1. Overview and history
PCI DSS was developed by PCI Security Standards Council, an open global forum formed in 2006 by American Express, Discover Financial Services, JCB International, MasterCard Worldwide, and Visa Inc. [1].
Historically, the companies in this forum developed their own programs, but because they shared similar goals they decided to align their requirements and created PCI DSS.
The birth of PCI DSS created many discussions in the industry.
For example, PCI Council General Manager Bob Russo thinks that PCI DSS gives stakeholders “the opportunity and flexibility to work with Qualified Security Assessors (QSA) to determine appropriate security controls within their environment that meet the intent of the PCI standards.” [2]
Furthermore, Bruce Schneier says that, “Regulation – SOX, HIPAA, GLBA, the credit-card industry’s PCI, the various disclosure laws, the European Data Protection Act, whatever – has been the best stick the industry has found to beat companies over the head with. And it works. Regulation forces companies to take security more seriously, and sells more products and services.” [3]
2. PCI DSS requirements compliance
PCI DSS consists of on six high-level objectives and twelve requirements (Table 1) [4]
| Build and maintain a secure network | 1. Install and maintain a firewall configuration to protect cardholder data |
| 2. Do not use vendor supplied defaults for system passwords and other security parameters | |
| Protect card holder 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 or programs |
| 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 and information security policy | 12. Maintain a policy that addresses information security for all personnel. |
Table 1 – PCI DSS Requirements and Security Assessment Procedures [4]
Compliance with PCI DSS requirements is enforced through contract agreements and may include fines and higher processing fees. To ensure compliance of services providers and merchants with PCI DSS requirements, special assessments are carried out. Such assessments usually utilize a sampling methodology to demonstrate compliance in target systems.
However, assessment procedure depends on the level of the merchant (it may require the completion of a Self-Assessment Questionnaire or on-site assessment) (Table 2) [5]
| Category | Criteria | Requirements |
| Level 1 | Any merchant that has suffered a hack or an attack that resulted in an account data compromise Any merchant having more than six million total combined MasterCard and Maestro transactions annually Any merchant that MasterCard, in its sole discretion, determines should meet the Level 1 merchant requirements to minimize risk to the system |
Annual Onsite Assessment Quarterly Network Scan |
| Level 2 | Any merchant with more than one million but less than or equal to six million total combined MasterCard and Maestro transactions annually | Annual Self-Assessment Onsite Assessment at Merchant Discretion Quarterly Network Scan |
| Level 3 | Any merchant with more than 20,000 combined MasterCard and Maestro e-commerce transactions annually but less than or equal to one million total combined MasterCard and Maestro e-commerce transactions annually | Annual Self-Assessment Quarterly Network Scan |
| Level 4 | All other merchants | Annual Self-Assessment Quarterly Network Scan |
Table 2 – Merchant Level and Validation Requirements (MasterCard version) [5]
PCI DSS requirements assessment procedure depends on merchant’s annual number of transactions and past breach history.
3. Implementing the PCI DSS
Companies face many challenges and difficulties when implementing PCI DSS requirements. According to Michael Jones, CIO of Michaels’ Stores, PCI DSS requirements “are very expensive to implement, confusing to comply with, and ultimately subjective, both in their interpretation and in their enforcement. It is often stated that there are only twelve ‘Requirements’ for PCI compliance. In fact there are over 220 sub-requirements; some of which can place an incredible burden on a retailer and many of which are subject to interpretation.” [6]
Rees identifies the following challenges of PCI DSS compliance [7]:
– Understanding scope
– Understanding of card data flow
– Organizational
– Technological
– Third party management
Bonner, O’ Raw and Curran in their paper [8] present a good analysis of application adherence with PCI DSS requirements. Researchers address such issues as maintaining legacy systems and their difficulties to implement PCI DSS requirements properly. They discuss several existing solutions such as using web services to “wrap” older legacy systems [9]. However, in their opinion, neither of these approaches directly addresses the problem of PCI DSS compliance.
The authors developed a prototype (Figure 1) and showed how to implement controls to achieve PCI DSS compliance in the application.
Figure 1 -. Experimental System Overview [8]
The researchers thoroughly describe their prototype, present some experiments, and tackle the problems of masking payment card data and cryptographic key management while storing such data.
However, in their research they focus solely on adherence with requirements of developed application, completely ignoring environment in which this piece of software operates.
Despite the fact that this paper contributes to the field of secure software development, and emphasizes some application PCI DSS compliance issues, one should remember that environment plays an important role in achieving compliance for business overall
References
[1] PCI Security Standards Council https://www.pcisecuritystandards.org/
[2] Russo (2009). “Letter to NRF”. PCI Council. https://www.pcisecuritystandards.org/pdfs/statement090615_letter_to_nrf.pdf
[3] Schneier (2008) “Bruce Schneier reflects on a decade of security trends”. http://www.schneier.com/news-049.html
[4] PCI DSS Requirements and Security Assessment Procedures, Version 2.0 p. 5
[5] Merchant Level and Validation Requirements (MasterCard version) http://www.mastercard.com/us/company/en/whatwedo/determine_merchant.html
[6] Jones (2009). “Testimony of Michael Jones before the emerging threats cybersecurity and science and technology subcommittee “. Congress of the United States.
Click to access 20090331142012-77196.pdf
[7] Rees (2010) “Computer Fraud & Security” Volume 2010, Issue 12, p. 14–116
[8] Bonner, O’ Raw, Curran (2011) “Implementing the Payment Card Industry (PCI) Data Security Standard (DSS)”.
[9] Steed (1996) “Encapsulating Legacy Software for Use in Client/Server Systems”. Proceedings of the Third Working Conference on Reverse Engineering. Monterey, CA: p.104-119
Cyber Security Leadership 