The PCI DSS V3.2 Requirements: SSL And Early TLS Migration
The Payment Card Industry Data Security Standards is a standard of Information Security Security for organizations that handle branded Credit Cards from the vital card schemes. The card brands authorize the PCI Standard and are administered by the Payment Card Industry Security Standards Council. The motive behind creating this standard was to increase controls around cardholder data to reduce Credit-card fraud. The validation of this compliance is performed once in a year, either by some External Quality Security Assessor (QSA) or by a Firm-Specific Internal Security Assessor that creates a Report on Compliance for Organizations that handles large volumes of transactions, or by Self-Assessment Questionnaire (SAQ) for companies that control a small number of transactions. The first version 1.0 of Payment Card Industry Data Security Standards was released on December 15, 2004, and the latest version 3.2 was released by Payment Card Industry Security Standards Council in April 2016.
PCI DSS V3.2
In April 2014 the National Institute of Standards and Technology declared SSL and TLS version 1.0 as unsafe and recommended all the organizations related to Information Security to Migrate to TLS Version 1.1 or 1.2. The previous versions of SSL and TLS are no longer considered efficient security controls by the Payment Card Industry Data Security Council (PCI DSC). The latest version of PCI DSS v3.2 was launched in April 2016 which includes the detailed measures that should be taken to migrate from SSL and TSL previous version to TLS Version 1.1 or 1.2. However, PCI DSC recommends migrating to TSL Version 1.2 because it is considered the most secure version of TLS to date and should be selected above all previous versions wherever possible. The TLS versions 1.1 and 1.2 are recommended because they are following National Institute of Standards and Technology (NIST) guidelines. The last date for migration is June 2018. Risks of Using SSL / Early TSL The moment the National Institute of Standards and Technology announced previous versions of SSL / TLS to be unsafe they have become a risk for everyone involved in Information Security. It is considered a massive risk because SSL / TLS is used widely, and most connections rely on previous SSL / TLS. As it is used extensively, so it became easier for attackers to target the connections and gain all the data by exploiting some of the severe vulnerabilities in SSL / TLS previous versions. There are three categories of vulnerabilities involved in SSL / TLS previous versions.
- The primary category relates to cryptographic vulnerabilities in either the SSL/TLS protocol itself or in how cryptographic algorithms are used. A prominent case of the vulnerability of this type is the way SSL version 3 utilizes Cipher Block Chaining (CBC) mode. This vulnerability has been effectively corrupted by POODLE, a man-in-the-middle assault that lets the attacker decrypt information in the SSL channel.
- The second category relates to the implementation of the SSL/TLS convention. For instance, HEARTBLEED is a bug in the OpenSSL software library; it isn’t a design defect in the SSL/TLS convention itself. An attacker can exploit this bug to analyze the memory of systems secured by the vulnerable versions of the OpenSSL software, in this way compromising the secret keys used to recognize the service providers and to encrypt the transmission of the information.
- The third category relates to the configuration of the SSL/TLS convention. Examples in this category would incorporate the utilization of weak cipher suites or key sizes. For example, the LOGJAM attack exploits systems that help feeble export-grade cryptography. An effective LOGJAM attack permits a man-in-the-middle attacker to downgrade vulnerable TLS connections to 512-piece trade review cryptography. The aggressor can at that point read and change any information that is transmitted over the connection. While it is possible to execute counter-measures against some of the attacks on the TLS protocol, the main dependable technique for protection that is right now available is to migrate to TLS version 1.1 or 1.2. ‘NIST Special Publication 800-52 Revision 1’ gives valuable rules on how to configure TLS securely.
Do the PCI DSS requirements apply to only huge businesses? No, the PCI requirements apply to all associations that transmit, process, or store information, including those that have a limited number of transactions. Even though outsourcing a few or all of your payment processes may simplify them and lessen what is in scope for PCI compliance, you can’t ignore it. You need to have policies and procedures set up to secure cardholder information when you get it, and when you process charge-backs and refunds. Your payment card issuer may likewise expect you to guarantee that suppliers’ applications and card payment terminals are PCI compliant. While the payment card issuers at first focused enforcement efforts on Level 1 vendors, they have increased enforcement for Level two through four merchants in the previous couple of years.
What happens to small businesses when they do not know enough about PCI DSS and suffer a breach? Small businesses need to comprehend PCI consistency compliance, not merely to protect their clients but also to secure their business. Although numerous small companies don’t have security expertise or committed in-house resources, they should, in any case, comply with PCI measures. At the point when a small business is compromised, it might quickly be dealt with as a Level 1 merchant by the payment card brands and in this way subject to more prominent levels of examination and evaluations, including hiring a QSA to direct a PCI evaluation and issuing a Report on Compliance (ROC). It might confront increased fines from the payment brands or their acquirer, be required to submit to a detailed forensic investigation, and lose the client’s trust, any of which may make it bankrupt. Regardless of whether it is commercially sensitive data or intellectual property designs that culprits are after, any size of association can be targeted. Smaller firms may likewise be focused on getting to partners, for example, larger organizations with a greater store of financial details.
Merchant and Service Provider Levels and Validation Requirements
| Levels | Criteria | Annual QSA Audit | Annual SAQ | Quarterly ASV Scan | |
| Merchants | 1. | 6,000,000+ transactions per year or compromised in the past year. | P | P | |
| 2. | 1 million to 5 million transactions per year. | P | P | ||
| 3. | 20,000 to I million e-commerce transactions per year. | P | P | ||
| 4. | Less than 20,000 e-commerce transactions per year and all other merchants processing up to 1 million transactions per year. | P | P | ||
| Service Providers | 1. | All VisaNet processors (member and non-member), and all payment gateways. | P | ||
| 2. | Any service provider that is not in Level 1 and stores, processes, or transmits more than 1,000,000 Visa accounts/transactions annually | P | |||
| 3. | Any service provider that is not in Level 1 and stores, processes, or transmits less than 1,000,000 Visa accounts/transactions annually | P | P |
If payment processes are done via a third-party, or an e-commerce platform, do I still have to worry about PCI compliance?
Yes, you do. Though outsourcing some or all of your payment processes could reduce your risk of breach or what’s in scope for PCI compliance, you can’t ignore it.