Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


02:00 PM
Connect Directly
E-Mail vvv

CCPA: Cut From the Same Cloth as PCI DSS

Finally, some good news about CCPA: If you've built your security infrastructure to PCI DSS standards, you may be already covered by California's new data protection rules

Feeling a little frantic about implementing the California Consumer Privacy Act (CCPA)? The good news is that you may already be in compliance since many of the same protections are already embedded in the PCI DSS law enacted in 2006.

Effective Jan. 1, CCPA applies to any organization that collects and processes personal data on California residents. The CCPA conveys new rights regarding personal information and imposes new data protection responsibilities on organizations operating in the state, or those conducting business that involve California citizens. 

It is highly likely that you are already conducting business that involves California residents, which makes CCPA compliance mandatory. Microsoft, for one, has pledged its obedience to the law, and will be using CCPA as a framework across all US operations.

But depending on your line of business, your organization may have already implemented data privacy and protection regulations and practices that satisfy certain CCPA requirements. Here are two aspects of CCPA that focus on privacy of personal information and data protection that are comparable to PCI DSS:

  • CCPA describes personal information as any data that directly or indirectly identifies a particular person or household, while PCI DSS focuses primarily on payment cardholder data.
  • CCPA compels organizations to implement and maintain "reasonable security procedures and practices" to protect the personal information. PCI DSS provides more depth, such as rendering the cardholder data unreadable anywhere it’s stored and encrypting the transmission of cardholder data across networks (both are considered reasonable best practices by IT security professionals).

If these are not addressed, serious fines could be handed out by California regulators, or the company could be taken to court by the affected consumers. This is because the CCPA allows consumers to institute civil action against businesses when their personal information is left unprotected, and is subjected to unauthorized access as a result of failure to implement those "reasonable security procedures and practices." Consumers who believe their privacy rights have been violated can give notice to a company, which then has 30 days to respond and fix the potential violation and avoid a class action suit.

That's why it's critical to gain visibility into where sensitive data is stored, how it is being processed and the means in which it is being collected. When it comes to securing this data, the regulation stipulates the use of pseudonymization to preserve the information and keep it private. With other US states looking to establish their own data regulations, it’s best to ensure compliance is being met with CCPA, so this can lay down the foundation to help with other privacy legislations.

How does PCI DSS come in to play?
Developed by the Payments Card Industry Standards Security Council (PCI SSC) in 2014, the Data Security Standard (DSS) aims to protect sensitive cardholder data. Organizations failing to meet the 12 requirements may be required to cease accepting card payments issued by one of the four major credit card brands (Visa, MasterCard, American Express, or Discover). Since its inception, it has been continually amended to account for modern threats to cardholder data.

Under its current edition, PCI DSS dictates primary account numbers (PANs) which must be unreadable anywhere they are located and when being transmitted over public networks. If stored in databases and files, security technology using cryptography, such as tokenization and encryption, are recommended. PCI requirements are deemed "reasonable security practices and procedures" by most professionals in the payments industry. 

Consequently, applying the key data security requirements from PCI DSS to CCPA, to include personal information beyond payment card data, may help fulfill the data security responsibilities in CCPA. 

We are seeing a trend where companies that process payments, like payments services providers (PSPs) and payment processors, are increasing their overall card data security program. Data security tokenization -- not to be confused with payment tokens -- is increasingly deployed within these organizations who need to anonymize card data. Data security tokenization allows organizations to remove the actual credit card or debit card number (aka PAN). As a result, if an attacker steals the data from databases or files, the data is worthless to them because they took tokenized data instead of the original PANs.

Compliance regulations like PCI DSS mandate this level of card data protection, so these organizations are saving themselves from paying out-of-compliance fines. Companies are also extending the use of data security tokenization to handle cross-regulatory requirements for handling personal data, which address GDPR, HIPAA, and others.

Looking at recent breaches and an ever-increasing attack surface, classic perimeter defenses are becoming increasingly vulnerable. A best practice employed by many highly conscious IT professionals focuses on protecting the sensitive data itself, rather than focusing on the systems or infrastructure in which the data resides. Data-centric security, as it is often referred to, provides the last line of defense against attackers, because it renders the sensitive data to be worthless to anyone who plans to exploit the data. With data in constant transit, security needs to move with it in order to reduce the potential threat of a cyberattack. 

Companies that are already investing in CCPA and PCI DSS compliance data privacy today are perfectly aligned with the will of the consumers and they should capitalize on it. All other organizations should start looking at a data-centric security strategy and organizational measures to ensure transparency and confidence to customers when it comes to their personal data. As we know, compliance isn’t equal to security – so organizations should start with the data itself, rather than try to build walls around entire infrastructures in a banal attempt to prevent data breaches.

Related Content:

Check out The Edge, Dark Reading's new section for features, threat data, and in-depth perspectives. Top story: "The Y2K Boomerang: InfoSec Lessons Learned from a New Date-Fix Problem."

Jonathan Deveaux is Head of Enterprise Data Protection at comforte AG. He has served the information technology community for more than 25 years. Jonathan started in banking and payments processing, gained experience in systems management supporting business critical ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Strategist
6/28/2020 | 8:33:23 AM
Only your CDE
This may be true, but only for the Card Data Environment because companies focus the more stringent requirements of PCI-DSS only to the environment which is in scope. They intentionally segment that environment (processes, data, and network) from the rest of their network. If you are a service provider or a card or a payment brand, this may already be in place, but if not, you have the concept and would need to apply to the rest of your environment, processes, and data - which is not a simple matter.
COVID-19: Latest Security News & Commentary
Dark Reading Staff 9/25/2020
Navigating the Asia-Pacific Threat Landscape: Experts Dive In
Kelly Sheridan, Staff Editor, Dark Reading,  9/25/2020
Startup Aims to Map and Track All the IT and Security Things
Kelly Jackson Higgins, Executive Editor at Dark Reading,  9/22/2020
Register for Dark Reading Newsletters
White Papers
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-09-27
XSS exists in the MobileFrontend extension for MediaWiki before 1.34.4 because section.line is mishandled during regex section line replacement from PageGateway. Using crafted HTML, an attacker can elicit an XSS attack via jQuery's parseHTML method, which can cause image callbacks to fire even witho...
PUBLISHED: 2020-09-27
An issue was discovered in the FileImporter extension for MediaWiki before 1.34.4. An attacker can import a file even when the target page is protected against "page creation" and the attacker should not be able to create it. This occurs because of a mishandled distinction between an uploa...
PUBLISHED: 2020-09-27
An issue was discovered in MediaWiki 1.34.x before 1.34.4. On Special:Contributions, the NS filter uses unescaped messages as keys in the option key for an HTMLForm specifier. This is vulnerable to a mild XSS if one of those messages is changed to include raw HTML.
PUBLISHED: 2020-09-27
In MediaWiki before 1.31.10 and 1.32.x through 1.34.x before 1.34.4, Special:UserRights exposes the existence of hidden users.
PUBLISHED: 2020-09-27
In MediaWiki before 1.31.10 and 1.32.x through 1.34.x before 1.34.4, XSS related to jQuery can occur. The attacker creates a message with [javascript:payload xss] and turns it into a jQuery object with mw.message().parse(). The expected result is that the jQuery object does not contain an <a> ...