Endpoint //

Privacy

8/4/2017
10:00 AM
Hadar Blutrich
Hadar Blutrich
Commentary
Connect Directly
LinkedIn
RSS
E-Mail vvv
50%
50%

Are Third-Party Services Ready for the GDPR?

Third-party scripts are likely to be a major stumbling block for companies seeking to be in compliance with the EU's new privacy rules. Here's a possible work-around.

Like a maelstrom on the horizon, GDPR — the European Union's General Data Protection Regulation — is coming, and companies both inside and outside the EU are scrambling to comply with its many rules. Among those rules is a requirement for companies that have access to user data to protect it by any means necessary. If they don't or can't, they pay — in cash, with hefty fines imposed on companies that fail to fulfill their obligations. And the EU means business; it imposed a $2.7 billion fine on Google in June over what officials said was Google's misuse of its data power.

Companies, of course, are doing everything they can to comply with the EU's cybersecurity rules, including the implementation of collaboration and information-sharing between relevant institutions (government, banks, regulators) regarding attacks and defense systems, education efforts to ensure that employees don't admit malware into the network, and appointing an officer who will be in charge of ensuring that user data remains safe. And the rules apply to all companies and organizations, anywhere, if an EU citizen can connect to their site.

Every company that does business on the Web is now busy ensuring that its security systems are up to the EU's standards. But there are data issues beyond the control of any organization in the form of the data collected by third-party scripts, which are processed and stored in databases belonging to the third-party script provider. And organizations can't do without these scripts; they provide the services that users have gotten used to and demand — such as social media, ecommerce, comment services, advertising, content distribution, site analytics, and much more — as part of their Web experience. Without these scripts, there basically is no World Wide Web as we know it, and without those services, the level of engagement on sites is likely to fall considerably.

The Security Factor
There's no way of knowing how secure the scripts are. We know that there have been numerous examples of third-party scripts being taken over by cybercrooks to pull off some spectacular hacks. There was, for example, the Stegano exploit, which compromised the computers of millions of users around the world. Stegano, which has been around since at least 2014, came into new prominence last fall when it was used to cleverly hijack readers of "popular news sites," according to ESET Research, which first published details of the exploit. Hackers used ad networks to distribute malicious scripts to run an exploit via an image's invisible alpha channel (a layer of an image meant to store data but that has no visual representation in the image).

The exploit — which didn't change the banner ad at all, making it almost impossible for a user to detect that anything was wrong — checked to see if any security software, sandboxes, etc., were present; if they were not, the exploit would redirect to a page that downloaded a payload and used regsvr32.exe or rundll32.exe to install it. The point of the exploit was to install malware that would steal user data from the webpage itself — login and password combinations or credit card numbers if they were entered into a box on the webpage — or to divert their clicks to other servers that served the needs of hackers or their clients.

In either case, the data of users was compromised — a sad story for them, and certainly a black mark on the news sites that were victimized — but under the new rules, sadness and loss of reputation are the least of the problems of the organizations whose sites were compromised. Had GDPR been in effect when the exploit was going full blast, the news sites would likely have been fined, if not prosecuted. That's how tough the EU rules are, and nearly all sites that use third-party scripts are potential victims.

What can they do to protect themselves? First of all, sites have to even out the equation and find a way to take back control of their websites. In that sense, their experience is similar to administrators who run mail servers — and whose users are plagued with endless amounts of phishing emails that seek to tempt recipients to click on a rogue link or contaminated attachment. Despite the best efforts of administrators, who have tried lecturing, hectoring, threatening, and begging users not to click on suspicious-looking links and attachments, the problem gets worse every year, with more attacks and more opened messages leading to more successes for hackers.

If lecturing, hectoring, threatening, and begging don't work, what will? One idea is separation — setting up a sort of sandbox between the mail server and the user's inbox that can examine the contents of a message. If something appears suspicious, either in the attachment or the message itself, the message can be "cleansed" of bad elements, or dumped altogether. If it works for email — and, indeed, for any Web connection — why not for third-party scripts? With sandbox-type solutions, companies can regain control of their websites while retaining the third-party services their users demand. Sites would be able to protect themselves from the unknown threats presented by third-party scripts, ensuring that not only is user data protected but that organizations are protected from the threat of big EU fines and penalties if something goes wrong.

Related Content:

Hadar Blutrich is the CEO of Source Defense. He was formerly the Chief Solution Architect at LivePerson and has led projects with many industry giants, including Bank of America, Chase, and Verizon, among others. View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Why Cybersecurity Must Be an International Effort
Kelly Sheridan, Associate Editor, Dark Reading,  12/6/2017
NIST Releases New Cybersecurity Framework Draft
Jai Vijayan, Freelance writer,  12/6/2017
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
The Year in Security: 2017
A look at the biggest news stories (so far) of 2017 that shaped the cybersecurity landscape -- from Russian hacking, ransomware's coming-out party, and voting machine vulnerabilities to the massive data breach of credit-monitoring firm Equifax.
Flash Poll
New Best Practices for Secure App Development
New Best Practices for Secure App Development
The transition from DevOps to SecDevOps is combining with the move toward cloud computing to create new challenges - and new opportunities - for the information security team. Download this report, to learn about the new best practices for secure application development.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2017-0290
Published: 2017-05-09
NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

CVE-2016-10369
Published: 2017-05-08
unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

CVE-2016-8202
Published: 2017-05-08
A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version...

CVE-2016-8209
Published: 2017-05-08
Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

CVE-2017-0890
Published: 2017-05-08
Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.