Security Ranch Security Ranch

PCI DSS v3

            Payment Card Industry Data Security Standard (PCI DSS) is the credit card industries self regulated system of rules and regulations that provide for better information security.  The standard was created in September 2006 by the five major credit card brands; Visa, MasterCard, Discover Financial Services, JCB International, and American Express.  Prior to the creation of the first PCI DSS standard there was a need to get standard in place that all merchants could use to help them keep Personnel Identifiable Information (PII) secure.  Before it was more difficult to comply with requirements from the different credit card vendor because each vendor had their own standard and they did not match each other.  Because of this confusion the five major vendors created the Payment Card Industry Security Standards Council (PCI SSC).  The PCI SSC brought together all of the requirements from vendors and created the first standard known as PCI DSS v1 (What is PCI SSC).

A important note for the PCI DSS standard is that it was created by the credit card vendors and not necessarily an entity itself.  If you had questions or wanted to change something about the standard you could not change it from the PCI SSC.  You would have to go through one of the credit card vendors to get your questions answered because the Council is made up of the vendors and not a separate body (What is PCI SSC).

The purpose of this paper is to identify what the PCI DSS v3 standard is and if this is the right standard to have as an industry.  To begin we will discuss what is required to be compliant.

The basic frame work of the PCI DSS is six categories that are further subdivided into twelve basic requirements.  The figure below describes the basic overview of the standard.

1. Install and maintain a firewall configuration to protect card holder data.  This is the first requirement of the PCI DSS.  The basic premise is to install a firewall onto your network that prevents any unauthorized users from gaining access to the network and also to allow all authorized users to have access to that same network.  A firewall must be installed and configured between all untrusted and trusted portions of the network.  Implicit to this is that a Demilitarized Zone (DMZ) must be established that allows the public to view a web server but be denied access to database servers that reside on the same network.  For an effective firewall an inventory of the entire network to include all nodes, protocols, and applications must be accounted for so that only the ports and protocols needed can be allowed on the network.  Care must also be taken to ensure that no PII data is stored between the DMZ on the web servers.  The overall goal is to keep unauthorized users from gaining access to the trusted networks where the PII data resides and to ensure no PII data is stored on untrusted networks (PCI DSS requirements)
2. Do not use vendor supplied defaults for system passwords and other security parameters. This is a basic security function but unfortunately is often overlooked.  The basic sub-requirements are to change or remove all default passwords and account user names.  For example for administrative accounts the user name should not be “admin”.  Most of the default passwords and user names are all public information that is often easily discover but using the Internet.  Implicit to this requirement is to restrict servers to one role only.  If you have a web server it should only be a web server.  Not a web server and a database server.  The purpose of these steps are to reduce the attack surface of each server.  Care should also be taken to remove and features or applications that are not needed.  This also reduces the attack surface and follow the basic security principal of least privilege.  Using encrypted protocols is another requirement.  Instead of using FTP use SFTP or https for http.  This keeps the data in transit secure (PCI DSS requirements).
3. Protect stored card holder data.  This requirement essentially protects card holder data at rest.  A robust Encryption Key Management System (EKMS) must be in place that manages encryption keys, how they are stored, how they are disposed of, enforcement of cryptoperiods.  Policies should be put in place to replace passwords for card holders and employee accounts when known data breeches occur or when encryption keys are weakened in any way.  Specific policies must be in place to decide what card holder data is stored, how long, and for what purpose.  If card holder data is not needed to verify the transaction or id then it should not be collected or stored.  The CVV code that is located on the back of most credit cards also must not be stored.  Following the principal of least privilege you should limit the number of employees that have access to card holder data or encryption keys.
4. Encrypt transmissions of card holder data across open, public domains.  The use of encryption and secure protocols must be used with data in transit.  This is closely related to the second requirement but also includes the data that interacts with the Point of Sales (POS) terminals and the servers.   Secure protocols such as IPSec, TLS/SSL, and SSH must be used and only trusted certificates must be accepted.  This requirement includes all types of networks to include wireless.  Only WPA2 or WPA can be used.  WEP is prohibited because it is too easily broken with todays technology (PCI DSS requirements).
5. Protect all systems against malware and regularly update anti-virus software    or programs.  Plan and policies must be put in place to regularly update and scan all servers, workstations, and POS systems for malware and viruses.  Anti-virus software must be able to identify, quarantine, and remove any malware that is identified.  IT departments must also monitor for new exploits and vulnerabilities that are discovered by security researches and anti-virus software vendors (PCI DSS requirements).  Depending on the size of your business it might be smart to run two or more different anti-virus application because each vendor uses a different virus definition database and they update the database at different times (Solomon 2011).
6. Develop and maintain secure systems and applications.  Consistently monitoring software applications for updates and actually updating them will be known vulnerabilities to a minimum.  Also keeping your Operating System (OS) updated will reduce the number of known exploits from being used for an attack.  If custom software applications are used then they must be tested for any vulnerabilities.  Known best practices in software programming must be used to keep buffer overflow, cross-site scripting (XSS), error handling etc. at bay.  While programming and testing the testing data must be removed from the application to prevent the data from being used in an exploit.  At least annually known vulnerabilities must be patched to keep applications free from exploits n(PCI DSS requirements)
7. Restrict access to card holder data by business need to know.  This is a basic security principal.  The principal of least privilege is the process of identifying what access employees or users need and only giving them the minimum access and permissions for them to do their job.  At the employment level all positions must have active roles, permissions, and access rights defined and documented.  Using Microsoft Windows Active Directory makes this process pretty easy.  You can also create profiles using the Group Policy Object (GPO) Management editor to create group permission and access rights depending on what the employee’s jobs are (Solomon 2011).   Periodically these rights must be audited and verified that they are correct and that excess rights were not issued.  If extra rights are given they must also be given an expirations date.  Access Control List (ACL) must be documented with the default setting on employee accounts set to deny.  This helps control the least privilege principal and makes the IT department have to grant permissions instead of having to specifically deny permissions (PCI DSS requirements).  A good practice for administrative accounts would also be to restrict privileged accounts from having access to the Internet and possibly email.  This would require all IT personnel to have two or more accounts but it would help improve the least privilege principal.  For example if an admin account is compromised by an attacker they would have all of the access rights granted to that admin employee.  If the admin account never had access to the Internet or email it would be more difficult to exploit (Solomon 2011).
8. Identify and authenticate access to system components.  This requirement pertains mostly to employee.  For any employee accounts there needs to be an employee id issued.  This will allow for better audit tracking.  Policies must be put in place by the IT department to ensure employees use strong passwords.  In Windows this can be regulated by the GPO Management editor (Solomon 2011).  Security Policies must also be put in place to revoke any and all rights to employees that are terminated as soon as the decision is made to terminate them.  Other policies must control the number of unsuccessful attempts to access privileged area of the network or data with the account being locked out for a certain time period or by unlocking the account by IT staff.   For employees who work remotely two-factor authentication or better must be used to gain access to network resources.  For external vendors account must be set up specifically for them with the minimum number of permissions granted to allow them to do their job as vendors.  The vendor accounts should not have access rights to card holder data (PCI DSS requirements).
9. Restrict physical access to card holder data.  This sets up requirements for the physical locations of where the servers that contain card holder data lie.  Despite all of the security policies or restrictions we put in place if an attacker gain physical access to a server they could install malware physically on the server or copy data from the server.  To prevent this servers and physical copies of card holders data must be physically secured from access by employees that are not authorized.  Servers must be secure by lock and key preferably in a server room or closet.  I remote camera or video camera must be installed at the access points with the goal of recording anyone who enters the room with the data being recorded and kept for at least three month unless restricted by local or state laws.  Network jacks in public area that connect to the network must be disconnected or turned off to restrict unused network ports from being used.  Physical access to Wireless Access Points (WAP) should be restricted from the public or located where the public can not gain physical access to them.  For vendor a easily identifiable way to recognize them must be developed to ensure employees know they have permission to be in non public areas.  When visitors check in their identities must be verified by calling the vendor and confirming who the employee is or verifying the vendors id through an id card or other credentials (PCI DSS requirements).  This is an important step to prevent attacks by social engineering (Hadnagy 2011).
10. Track and monitor all access to network resources and card holder data.  This requirement sets up the requirements for auditing.  Minimum requirements for the data that the audits track are who accessed card holder data, who accesses audit logs, any access by employees with root or administrative access, unsuccessful login attempts, pausing stopping or changing audit logs, and who creates or deletes system logs.  Other audit logs must record  the user identification, Date and time, type of event, event origins, and success of failed attempts.  For auditing purposes all audits and events must use the same standard of time recording.  If the different audit logs all use different standards of time tracking the audit process will be more difficult if an attack occurs and you want to find out what happened.  Updating and verifying of accurate timing must use industry accepted methods.  Access to time data must be protected to prevent anyone from tampering with the time on the servers or workstations to prevent time discrepancies that would be auditing difficult.  Audit logs and trails must be prevented from being altered.  Often attacks will delete or change audit logs to hide evidence of their actions.  Audit logs must be reviewed daily to ensure they are working properly and that they are recording data correctly.  Any anomalies must be followed up to verify that there have not been any breeches or data or protocol (PCI DSS requirements).
11. Regularly test security systems and processes.  WAP must be tested for there presents and whether or not the security protocols are working.  If guest accounts are presents the accounts must be tested to ensure that they have the proper access permissions given to them and that they are restricted from card holder data.  Network scans using Microsoft Baseline Security Analyzer (MBSA) or Nessus must be used at least quarterly or as needed if the network infrastructure changes.  Procedures must be put in place for regular penetration testing using industry standards.  If during the penetration testing any exploitable vulnerabilities are found they must be fixed and verified that they are corrected with another test (PCI DSS requirements).
12. Maintain a policy that addresses information security for all personnel.  This requirement focuses on employees and there knowledge of information security.  Regular and consistent training and education is essential for the security process to be effected.  Security policies must be established, published, maintained, and employees must be made aware of them. Employees should review and sign an Acceptable Use Policy (AUP) prior to an employee account being created (Solomon 2011).  To reduce risk from an insider attack background checks should be required before employees gain account access to privilege card holder data (PCI DSS requirements).

These are the twelve requirements of PCI DSS.  They have not change since its exception but the sub requirement have change with each new version.  Individually, each requirement is a good idea and would enhance the overall security of any network.  These are  good basic security policies.  However there are some criticisms to the PCI DSS standard.   Common complaints are that it distracts from the IT departments job (Rothke 2009).  The counter to this argument is that when looked at individually and as a whole each requirement is a good idea and often considered a “best practice” for information security.  Another criticism is in the way that it is implemented.  Mathew J. Schwartz interviewed John P. Pironti the president of risk and information security for IP Architects and is quoted as saying:

“Security by compliance, doesn’t do a company any favors, especially because attackers can reverse-engineer the minimum security requirements dictated by a standard to look for holes in a company’s defense.” (A near scam)

Looking at the requirements of PCI DSS it would be easy to disagree with him.  For example the task of changing all of the default passwords.  Reverse-engineering passwords would be more difficult if left in default.  If the PCI DSS standards are only implemented in a check in the box fashion and never looked at again then it is easy to understand.  But even the PCI SSC website understands that the PCI DSS is only the basics for information security.  It was not meant to be the “be all, end all”  of data security.  These are minimum standards that will help companies from being held liable for data breeches and data loss.  Another complaint about the PCI DSS standard is that it is too costly to implement.  The counter to this argument is that there are four different levels of PCI DSS compliance.  Level 4 is 20,000 transactions or less per year.  Level 3 is for businesses that have anywhere from 20,000 to 1,000,000 transactions with any of the credit card vendors per year.  Level 2 is from 1,000,000 to 6,000,000 and Level 1 is 6,000,000 or more transactions per year.  Each level requires more actions then the previous and with that incurs more cost.  However, if a businesses has a security mindset and cares about customer data these actions wouldn’t be as expensive and would probably be implemented anyway (PCI DSS requirements)

Bruce Schneier, a popular security professional looks at regulation this way:

“Regulation–SOX, HIPAA, GLB, 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.” (Schneier 2008)

Industry self-regulation works and is much more advantageous then government regulations.  The changes that can be made will be quicker to implement in order to keep up with the changing security environment.  If any changes are made that effect the credit cards bottom line they can introduce new changes or go back to older standards.  If companies choose not to comply with the PCI SSC standards they could choose not to accept credit cards and accept cash only.  However more and more companies are doing business online and with that the need for industry standards are a must to protect card holder data.

In the podcast Wh1t3Rabbit the speakers make a good point in stating that “information security is a process not a product” (Jardine 2015).  Some of the criticisms come from thinking that if they pay a Qualified Security Assessor (QSA) to assess their business and help get them into compliance that everything will be OK and nothing bad will happen.  But this thinking is counter to the basic security process.  A first principal that should be considered during the security process is continuous improvement (Smith 2013).  Once a company become PCI compliant they shouldn’t stop the process until the next time they get assessed.  They should always be checking for improvements in how they operate and how they secure there data.

In conclusion the PCI DSS is the right process to keeping card holder data secure.  Implementing the twelve security requirement to bring a company into compliance will help that company from being held liable and getting sue by card holders.  This is also a credit card industry standard created by the credit card vendors.  If data and identities are stolen and that leads to money loss for customers the credit card vendors are the ones that have to deal with returning the stolen money to the card holders.  It is only right that if the credit card vendors are liable to their customer then they can require businesses to take certain steps to protect the data and their customers.

References

PCI Security Standards Council, LLC. (Nov 2013). PCI DSS Requirements and Security Assessment Procedures Version 3.0 Retrieved from https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf

Jardine, Rafal. Santarcangelo, Michael. Man, Jeff. (January 5, 2015).  PCI DSS and Security (Yes, really).  Retrieved from http://podcast.wh1t3rabbit.net/dtsr-episode-124-pci-dss-and-security-yes-really

Klemic, Kane.  (2012).  Payment Card Industry Standards and the Sony Data Breach.  Retrieved from http://www.armaedfoundation.org/pdfs/Klemic_Payment_Card_industry_2012.pdf

Schneier, Bruce (2008)  Bruce Schneier reflect on a decade of security trends. https://www.schneier.com/news/archives/2008/01/bruce_schneier_refle.html

Smith, Richard E.  (2013).  Elementary Information Security.  Burlington, MA:  Jones & Bartlett Learning.

PCI Security Standards Council, LLC (n.d.).  What is the PCI Security Standards Council?.  Retrieved from https://www.pcisecuritystandards.org/security_standards/role_of_pci_council.php

Solomon, Michael G. (2011).  Security Strategies in Windows Platforms and Applications.  Sudbury, MA:  Jones & Bartlett Learning.

Hadnagy, Chrisopher. (2011).  Social Engineering:  The Art of Human Hacking.  Indianapolis, IN:  Wiley Publishing, Inc.

Rothke, Ben.  (2009 Apr).   PCI Shrugged: Debunking Criticisms of PCI DSS.  Retrieved from http://www.csoonline.com/article/2123972/compliance/pci-shrugged–debunking-criticisms-of-pci-dss.html

No Author.  (2013 July).  “A near scam”-  Criticisms of the Payment Card Industry Data Security Standard.  Retrieved from http://wemakewebsites.com/blog/a-near-scam-criticisms-of-the-payment-card-industry-data-security-standard