White Paper on The New Generation of Invisible Bot Attacks. Download Now.
Back to posts

What To Ask Your Information Security Providers About The CCPA

November 22, 2019
  • Ido Safruti
  • Ido Safruti
  • CTO & Co-Founder

As originally published in Forbes

What To Ask Your Information Security Providers About The CCPA

On January 1, 2020, the California Consumer Privacy Act (CCPA) goes into effect. Authored by the California state government, it has been described by some as “almost GDPR in the U.S.“ CCPA is the strongest consumer privacy legislation mandated at the state level, and it gives significantly more power to consumers to demand accountability and transparency for how their private data is handled. The CCPA also puts in place costly penalties against organizations that collect data and fail to protect it.

CCPA is, in effect, a national and global law. It covers any security and data problems that happen in the state of California and impact companies conducting business in California. So, for example, a German company that does business in California could find itself liable for costly fines if its website is breached and California customers are affected.

Not Understanding The CCPA Could Cost You Big

The good news? If your organization already complies with the EU’s General Data Protection Regulation, you are 95% of the way toward reaching CCPA compliance. A less-known but critically important piece of the CCPA is that liability for breaches extends to third-party services that web application publishers and operators use. This includes information security companies, payment processors, chatbot operators and any other provider of third-party services.

A little-known area of big risk is third-party JavaScript libraries and services that run on nearly all websites. Those JavaScript attacks may not breach company databases, but they can hijack user data by illegally modifying a web application. In those situations, companies could face fines in the hundreds of millions of dollars. This has already happened under GDPR in the European Union when massive fines were taxed on British Airways due to JavaScript attacks launching from its sites and on Marriott due to a cyberattack that exposed 383 million guest records.

This is a big deal. In a survey of 230 businesses with a median employee size of roughly 1,000, 32.2% said that 50% of their site code was from third parties, and 22.8% said that 70% of their site code was from third parties. A shocking 8.3% said they had no idea how much of their site code was coming from third parties.

Large CCPA Risk From Third-Party JavaScript

Here’s the rub. Your organization may be responsible not only for security problems and breaches affecting your own code, but also for code that is not even operating on your site. This is true as long as that third-party code is included in your user experience or exposed to your users in the web application. Nearly all web applications (including web, mobile web and hybrid mobile applications) use third-party JavaScript libraries and services to add functionality and improve performance.

Unfortunately, third-party code makes it much, much harder to police and audit for CCPA vulnerabilities and risks. This is true at multiple levels, including for your third-party information security providers that may be capturing personal information or may control key parts of your site infrastructure, such as digital certificates and DNS records.

If those security providers are operating a SaaS, they may well use JavaScript to add security functionality that also allows them to access user data as it crosses your site. In our survey, 42% of respondents did not have a viable way to verify that their site code was not changing without proper authorization.

Third-party JavaScript obfuscates true risks because the code is not under your control, so it’s hard to know when it’s compromised or changes. If the code is available under open source, then you will need to put in place additional steps to monitor and test that code. If it is not open source, then you will have to ask the company that makes the code to provide you with details about how the code is secured and how the code works.

Questions to Ask Your Third-Party Service Providers

To protect yourself from liability, ask all third-party service providers for detailed answers to the following questions.

  • Do you capture any of our user data?

  • How, where and when? Please explain the mechanism.

  • If you do capture our user data, what is your own CCPA policy and database access structure?

  • Can you provide an easy mechanism for us to access any user data you collect and provide it to our end users as part of a comprehensive CCPA report?

  • What are you doing to monitor data privacy laws that other states are likely to enact?

Aside from these questions, there are a number of other steps you can take. First, demand certification information and make it a condition of ongoing business. For SaaS companies, SOC 2 Compliance and/or ISO 270001 is the gold standard. Next, ask them to run a simulated CCPA request process with you. This will help you assess their readiness.

Finally, make sure your security stance for all your public-facing applications is audited and up to date with proper configurations. This will mean not only internal firewalls on databases and malware protection on every user’s device, but also technology specific to guarding web applications. Web application firewalls are table stakes. Make sure they are tuned appropriately.

Most organizations also run static code analysis (SCA). This is crucial to block potential insertion points for breaches. You should also run SCA against any third-party libraries that are open source that you use. For your live applications, consider using newer forms of AI-based anomaly detection to spot when your site has been hijacked and is harvesting user data without you realizing it’s going on.

The good news is that CCPA preparation enforces good basic security hygiene and best practices — and that will result in better protection for your users, your infrastructure and your bottom line.

Back to posts comments powered by Disqus