Every day we are becoming more and more a cashless society.
Plastic is the preferred method of payment for most North American businesses, and we even see a significant shift into virtual payment systems and direct-to-consumer banking.
In the modern world of digital currency, e-commerce, and fast-moving transactions, how can your business make sure that it is safely handling customer data?
Do you want to end up as the next headline splashed across the news as another company that has mishandled thousands of sensitive customer records?
If your business is accepting credit card payments and either stores, processes, or transmits cardholder data, then you are required to adhere to Payment Card Industry Data Security Standard compliance standards, otherwise known as PCI DSS.
The latest iteration of the standards is PCI DSS 3.2, as published by the Payment Card Industry Security Standards Council, with version 3.1 was entirely replaced as of October 2016.
This guide is a strong starting point for companies looking to maintain a strong security infrastructure. It also sets a clear and specific standardization of what is expected of companies that handle cardholder data.
What is PCI DSS Compliance?
PCI stands for “payment card industry” and refers to the Payment Card Industry Security Standards Council (PCI SSC).
The Counsel is a compromise between five proprietary data security and operations programs from major credit card companies: Visa, MasterCard, American Express, Discover, and JCB.
These companies aligned their policies to form the PCI DSS standard. This standard means that your company can pass validation of compliance from a Quality Security Assessor (QSA) from a firm-specific Draft Internal Security Assessor.
PCI validation methods culminate in an audit of PCI security standards controls. If the controls are found to be valid, a Report of Compliance (ROC) is issued. When a QSA conducts the audit, an Attestation of Compliance (AOC) is also issued. These are the accepted processes set by the PCI Security Standards Council.
Identify the 6 Most Prevalent Risk Factors in Data Security
Who do PCI DSS 3.2 Requirements Apply To?
Any company or private entity that can process, transmit or store consumer information from any of the five major credit card companies are subject to DSS compliance.
Credit card companies maintain merchant compliance levels depending on the number of annual transactions that a company completes:
- Level 1 – Merchants with more than 6 million yearly sales added across all channels. However, global merchants that identify as Level 1 in any region maintain that distinction in all areas.
- Level 2 – Merchants that conduct between 1 and 6 million transactions on an annual basis across all channels.
- Level 3 – Online Merchants that conduct e-commerce between 20K and 1 million transactions on an annual basis across all channels.
- Level 4 – Online Merchants that conduct e-commerce of fewer than 20K transactions on an annual basis across all channels, and merchants processing no more than 1 million yearly transactions across all channels.
Transactions may not be included in the merchant total if they are processed through local merchant locations instead of through the corporate entity.
The credit card companies also state that they maintain the sole right to define a Level 1 Merchant.
What Is the Timeline for the PCI DSS 3.2 Update?
As stated directly from the PCI Council:
“PCI DSS 3.1 will retire on October 31st, 2016, and after this time all assessments will need to use version 3.2. Between now and 31 October 2016, either PCI DSS 3.1 or 3.2 may be used for PCI DSS assessments. The new requirements introduced in PCI DSS v3.2 are considered best practices until January 31st, 2018. Starting February 1st, 2018 they are effective as requirements and must be used.”
What To Expect from the PCI 3.2 requirements Update?
The most critical changes that companies can expect from the update to the 3.2 standards are as follows.
Multi-factor authentication – This is different from two-factor authentication, or 2FA. Multi-factor authentication includes all processes that have at least two authentication factors. Every employee who has administrative access control to the cardholder data environment (CDE) must process through multifactor authentication. Previous PCI DSS standards only required 2FA and just remote administrators that were considered “untrusted” were required to verify themselves this way. This is one of the most significant expansions of the authentication requirement standards in the history of published PCI DSS.
SAQ Changes – All Self Assessment Questionnaires (SAQs) added many requirements outside of SAQ B and SAQ P2PE. SAQ B stayed the same as its previous iteration. SAQ P2PE took away two of its obligations. These requirements had to do with emailing and masking PAN data that was not encrypted.
Network segmentation and scoping – Systems outside of the CDE may now be included within the scope of PCI compliance. Many systems that connect to the CDE may also need to be added due to lack of segmentation.
Service providers – There are multiple changes for merchants and service providers including changes in penetration testing and the establishment of responsibilities for data and annual PCI compliance. There are also changes to the personal reviews performed on a quarterly basis, timeliness of reporting and detection of problems and cryptographic architecture.
Deprecation of SSL and Early TLS – All uses of SSL and TLS 1.0 within your CHE must be removed by June 30, 2018. However, TLS 1.1 is allowed though it is highly recommended to upgrade to TLS 1.2.
How Do The Updated Requirements Affect Your Organization?
The change from 3.1 to 3.2 is considered a non-major release and should not impact organizations significantly.
The depreciation of SSL and early TLS will be a challenge for many organizations but is a much-needed rule. SSL and TLS 1.0 have been exploitable for a significant amount of time and businesses are doing themselves a favor by upgrading. Many TLS and SSL exploits have caused many companies problems, including the exploits known as BEAST and POODLE. The National Institute of Standards and Technology (NIST) report that there are currently no patches that can provide a full repair for these TLS and SSL exploits.
How Can You Prepare for Your Next PCI DSS 3.2 Assessment?
Ordering Compliance Efforts Through the 6 Step Prioritized Approach
PCI DSS has identified six security measures that are most important in assessing and protecting against the most prevalent risk factors in business data security. These steps are meant to provide a company with a roadmap that can help to prioritize time and resources towards a fully compliant organization. The process is also intended to improve morale towards an environment of full compliance by creating a pragmatic approach that creates ultimate successes.
This prioritized approach also helps to promote consistency in compliance assessments along with operational and financial planning. Following the steps in order will also help a company to protect its cardholder data environment more quickly than haphazardly applying compliance standards. The approach was cultivated through an assessment of past breaches and feedback from forensic investigators and QSAs.
The six steps are as follows:
- The removal of authentication data that may be sensitive and the limitation of data retention – in short, companies should delete all data that they do not need. This is especially true of authentication data and other personal and financial information that may be sensitive. If this data is deleted from the system, its ability to be used to compromise the system is greatly reduced.
- The protection of networks and systems through constant vigilance in preparation for a breach – Companies should identify the most common point(s) of access for a breach or security compromise(s). The company should then identify and begin to prep the processes by which it will respond to these challenges.
- Securing all applications of payment card information – Weaknesses in application processes, servers, and controls for applications are straightforward ways for hackers to compromise company systems. This event should be considered on its own because of the importance of securing payment card applications.
- Monitoring who has physical access to company systems and controlling data access – Companies should implement a tiered system that limits the access of administrators to information that is outside of their jurisdiction. This system should be monitored, and all processes for the security of the system fully documented.
- The protection of cardholder data that is stored within the system – First, companies must determine whether they need to store highly sensitive information such as Primary Account Numbers. If a company has made this determination through a complete assessment of its internal processes, then it must create protection measures for that data.
- Ensuring that all protection controls are fully operational and finalizing any extra compliance efforts – By the time that milestone six is completed, all PCI DSS 3.2 requirements should be fulfilled. Additionally, any related processes, policies, and procedures that relate in any way to PCI DSS compliance should be fully operational as well.
Here are 10 best practices to prepare for your next PCI assessment.
Consistent Monitoring of Security Controls
Because of the speed with which malicious hackers improve their techniques, companies must continuously monitor their security controls. Part of being compliant with PCI DSS v3.2 is determining if a company can protect itself between assessments. If it cannot, then the assessment itself may not serve as an adequate deterrent for hackers looking for a weak target. It is also a requirement to review your PCI controls on a quarterly basis (if not monthly).
Timely Identification and Response to Failures of Security Controls
If a security control fails, then specific processes must be invoked within a timely manner to remain compliant. These processes include identification of why the control failed, identifying security issues that occurred during failure, full restoration of the control, the creation of procedures to ensure the failure doesn’t happen again, and the implementation of a monitoring strategy to verify operation of the control.
Determination of Changes Made before Upgrades Can be Completed
If any system is to be added into a PCI DSS environment, the impact of that system must be assessed. This system can be entirely new or modified from an existing system. Any part of a company’s infrastructure that connects to the addition must be evaluated for its compliance with PCI DSS 3.2. The company is responsible for identifying that new compliance requirements are met for all systems and networks modified by the change. The scope of the PCI DSS must be updated, and all new security controls required must be implemented and penetration tested.
Changes to the Organizational Structure Must be Reviewed
All employees must have privileged security access management controls that are relevant to his or her responsibilities and job description within the company. This structure should be reviewed from multiple scopes, including the individual and group levels.
Companies Should Initiate Consistent Reviews
A company should perform a regular review of its compliance measures to ensure that all requirements are implemented and up-to-date. These reviews must be conducted, at a minimum, quarterly to remain compliant. A company should also check to make sure that its processes have been properly updated as suggested by PCI 3.2. These internal reviews should include all company locations and all system components. A company has some leeway to determine how often these reviews should be completed, based upon the size and complexity of its infrastructure.
A main focus of these reviews should be to verify that appropriate records are being kept to maintain and prove PCI DSS v3.2 compliance efforts.
Regular Documentation of Both Software and Hardware Technologies
The vendor must fully support all equipment that is used within the company. All equipment must also meet the PCI DSS version 3.2 security requirements of the client. The company should immediately take action if any hardware is not vendor supported or the requirements are not met.
The same level of scrutiny should be applied to all software that the company is using. Software that is out of compliance accounted for 44% of data breaches in 2018.
Ensuring Accountability for Security Notifications
Five new requirements are introduced with 3.2 dealing specifically with the need for companies to notify customers of problems promptly.
The changes deal with detection of critical security systems and control mechanisms as well as cryptographic architecture. The amendments also require that a company perform quarterly reviews to vet all internal security personnel. The timely notification of severe issues to customers was found to be one of the aspects of security most lacking in companies, even those compliant with past iterations of the PCI DSS.
Ensuring the Proper Masking of Primary Account Numbers
To remain compliant with PCI DSS 3.2, a company must mask all instances of primary account numbers. At a maximum, only the last four digits or the first six digits may be shown. Any employee who is allowed to see more than this maximum must be accounted for. A company must create a list of these employees, including their roles within the company and the reasoning behind allowing them to see more than the masked primary account number.
Going Over the Designated Entities Supplemental Validation (DESV)
Because payment brands have the power to require service providers to fulfill additional DESV validations, companies should go over these requirements from the beginning of the compliance process. These requirements are covered in Appendix 3 and only will be penetration tested when instructed by an acquirer or a payment brand. PCI DSS 3.2 has the Designated Entities Supplemental Validation process as an appendix, including all new requirements that service providers will be expected to follow. These updated requirements include interviewing personnel to ensure documentation of cryptographic architecture. Additionally, companies are expected to implement a full change management process that keeps up with all system changes that may impact any system that is within the auspices of the PCI DSS.
Properly Scoping the Affected Environment
Evaluating the company environment is one of the most critical steps that you can take towards compliance and implementation of PCI DSS version 3.2.
To begin the process of scoping, a company should identify every component of the system that is either connected to or located within the CDE. The PCI SSC has given suggestions for compliance. Currently, there is a process to assess, report and remediate all data within the scope of the PCI DSS.
The Future Importance Of PCI Compliance
No one is quite sure exactly how malicious hackers will attack ecommerce in the coming years. There is a consensus, however, when you discuss data breaches in general. The problem is not going away.
Unprotected companies can almost expect to be targeted. Having a data security standard is essential to protecting your company and the information of the people who trust you. Take the above PCI compliance guide into account, consider PCI Compliant Web Hosting to bolster your security controls.
