GDPR and CCPA, An Update
A look at the compliance picture 3 months into the international year of privacy
Now that we’re a few months into 2019 it’s worth taking another look at the impact of recent sweeping privacy bills, in particular the EU’s General Data Protection (GDPR) regulatory regime, and California’s looming GDPR-inspired Consumer Privacy Act (CCPA).
GDPR has been in effect since May of last year, while CCPA comes into effect on January 1st, 2020. In both cases there have been significant developments.
Approaching a year of GDPR
One of the biggest questions swirling around GDPR in the run-up to its launch was how aggressively regulators would pursue and punish infractions – particularly given some of the ambiguities around how it’s tougher provisions could be enabled technically.
Well now we know, as well-known companies start to feel the EU’s wrath in the aftermath of cybersecurity breaches.
In the UK, cell phone retailer Dixons Carphone suffered a cyber-attack in 2018 that compromised some 1.2 million customer records, including names, as well as postal and email addresses. Under GDPR, companies face hefty fines if they fail to comply with provisions for handling customer data. For Dixons Carphone that could have meant a maximum penalty of 20 million EURO USD, however it appears they will face a smaller £500,000 fine in this case as the breach occurred before GDPR had come into force.
Regulators are understood to be looking for more high-profile test cases however, and it appears they could be spoiled for choice as GDPR has also had the effect of forcing breaches out into the open.
A recent study by global law firm DLA Piper has shown that over 59,000 personal data breaches have been reported across Europe since GDPR arrived. UK organizations have been hit by over 10,000 data breaches. Germany reported 12,600 breaches while the Netherlands had the top spot at 15,400.
The stumbling block for many seems to be GDPR’s requirement for identification and protection of Personally Identifiable Information or (PII). Companies that have been able to map where its PII is located, understand how it is used, and maintain a detailed library of data assets, may have actually benefited from new GDPR-driven efficiencies. This is both from having its data organized and catalogued, as well as minimizing fines and other losses from data breaches.
CCPA gets tougher – before its even come into force
The California Consumer Privacy Act is making its presence felt on the national legislative agenda even before it lands on New Year’s day 2020. Like GDPR, CCPA requires organizations to protect the personally identifiable information it holds on individuals.
But CCPA’s protections are even more stringent. For example, a host of biometric information is covered, as is any record of an individual’s browsing history or other interactions with a company website or app. Companies don't have to be based in California or have a physical presence there to fall under the law. They don't even have to be based in the United States.
CCPA’s wide-ranging requirements seem to have kicked off a biometric bandwagon at the state level, as more and more legislatures move to regulate the collection, use, and retention of biometric data.
In addition to CCPA’s arrival in 2020, Illinois , Texas , and Washington already have biometric privacy laws in place, while Arizona, Florida, and Massachusetts have recently proposed laws that will address biometric privacy. Washington State has also passed a new Washington Privacy act that borrows heavily from both the CCPA and GDPR. Other states are likely to join in.
Class Action Targets
Meanwhile legislators in California are already trying to make CCPA tougher. Under a proposed amendment to the law introduced in February, companies that gather and store personal data could find themselves the target of class-action lawsuits at the state level if they fall foul of CCPA’s provisions. Another proposal calls for data brokers to register with the California privacy authority, and for companies to disclose the value of their user data.
That opens up the possibility of user-driven lawsuits against the likes of Facebook, Google or Amazon for cash damages if they are found to have broken the law. Backed by the California Attorney General, the measure would turn up the heat on companies operating in the still emerging digital economy, and likely influence the shape of new federal regulations being considered by Congress.
Learning the lessons of GDPR?
Perhaps another link between GDPR and CCPA is the level of readiness companies report in the run-up to implementation. The tech and security press were running stories like this one on a regular basis prior to GDPR’s day zero, signalling fears about a compliance crash-out as a large percentage of organizations seemed blasé about the impending deadline.
In that sense a recent study by security vendor TrustArc has a ring of deju vu about it, suggesting that more than 80% of US businesses affected by CCPA are still not prepared.
The adoption of the US National Institute of Standards and Technology (NIST) cybersecurity framework or CSF is seen by many to be a stepping stone that will make CCPA compliance easier.
President Donald Trump issued an executive order in May of 2017 instructing all federal agencies to use the CSF. Italy, Israel, and Japan have also adopted the CSF in legislation, while companies that have implemented it include Microsoft, Boeing, Intel, and JP Morgan Chase.
Data Security & Source Code Protection
As far as sensitive data goes, few pieces of information rank higher then program source code.
Source code is highly sensitive proprietary information, making up the program instructions for any application in their original form.
The More Sensitive, the Bigger the Risk
For years, security experts have been pointing to the risks of exposed source code.
Two elements in particular make source code a major potential liability. The first and more obvious is the intellectual property element. Creators stand to lose the investment in producing programs as well as all potential future profits if source code is lost.
The second factor is that source code can be manipulated. Not only can changes be made to the software’s functions and tools, but malicious elements such as Trojans and backdoors can be inserted as well. These compromised code sets are then used to mass produce the software in machine code form, i.e. the form in which they're purchased by the common user.
Surprisingly, many developers still use primitive security measures, despite the many examples of stolen or maliciously modified programs.
The Conventional Approach and its Holes
Today, the market has produced several source code repositories, many of them open source. Hosts such as Assembla, Microsoft’s Azure DevOps, and the increasingly popular GitHub are just a few of the options out there.
Unfortunately, the run-of-the-mill source code host has its downsides.
First off, many of these platforms leave issues in tracking and locating code once the code is uploaded. Some even require the downloading of external apps to search for code sets. For organizations that need fast reliable access to stored code, the way in which many hosts are structured can prove to be a liability.
In addition to the logistical setbacks, IT professionals have also pointed to the security vulnerabilities of common source code hosts. For one, many sites are made vulnerable by the errors of their administrators, which can in turn potentially compromise the entire platform. Additionally, there is often no way to track and classify access to code stored on the hosts. Developers and other team members are able to freely access code and even execute changes to it. The lack of policy and enforcement protocols exponentializes the insider threat and the risk of data exfiltration.Protect my source code Now