Endpoint
4/19/2017
03:00 PM
Mike Baukes
Mike Baukes
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

Google Won't Trust Symantec and Neither Should You

As bad as this controversy is for Symantec, the real damage will befall the company and individual web sites deemed untrustworthy by a Chrome browser on the basis of a rejected Symantec certificate.

News that Google may be imposing a series of restrictions in Chrome against digital certificates issued by Symantec is but the latest and most remarkable salvo in a dispute that stretches back years. Google is leveraging its prominence to force companies to confront their cyber risk - a vital advance in fostering proactive digital resilience. How Symantec responds will have relevance far beyond any one corporate conflict.

Claiming Symantec was far too lax and borderline negligent in issuing its certificates, Google recently announced a proposal to gradually reject them, as well as any authorities tied to the Symantec root certificates. Any certificate authorities that derive their key chain from Symantec’s root will also face the same restrictions; some major names fall into this category, such as VeriSign and Thawte.

Despite the nonchalance of Symantec’s response, this is a potentially monumental step taken by Google. Browsers gatekeep the Internet to some degree: Chrome, Firefox, Safari, Edge/Explorer; Google, Mozilla, Apple, Microsoft. These are the applications and companies that determine how people interface with the Internet. Furthermore, they determine when a security problem takes on enough risk to be unilaterally rejected in the interest of their users. We’ve seen this before with encryption strength, cipher suites, even plugins like Flash and Java. These four companies hold the keys, as it were, for big picture technological evolution-- and the future of technology is resilience.

With this proposal, Google thus sets up the first real roadblock for Symantec’s business model. Google Chrome has about 60% of the browser market share. When Google drops support for an application or certificate for security purposes, it affects the browsing habits of the majority of Internet users. Symantec certificates, and those from its subsidiaries, will have demonstrably less value in Chrome once these restrictions start being enforced. This acute depreciation in the usefulness of a Symantec certificate, should, and probably will, cause en masse replacement with less problematic certificates. As the sole purpose of a certificate is to provide a trusted source verifying that the site is valid, secure, and private, such a public rebuke of Symantec’s integrity could be a crushing blow.

Insecure practices such as the certificate problems Symantec had are not just academic examples of bad technology, but possibilities for real world damage. It should be apparent now that the digital economy is the economy. There is no retrograde motion left to us as a society when it comes technology and its integration into daily life. As such, only resilient digital services can survive. Those which impose too much risk or cannot weather the attacks, outages, breaches, and problems of the digital landscape will lose the trust of the people, and of the other companies who rely upon those services to function.

Doing the Right Thing
Wouldn’t Symantec want to issue certificates in the most secure way possible - not merely to avoid Google’s wrath, but to do right by the enterprise customers who purchase their certificates? It seems not. Imagine the administrative overhead, cost, and time it would take for Symantec to change a system which, according to Google, has been broken for years. With no apparent pressing need to break from standard operating procedure, Symantec has not made those changes, even after earning nasty press about how shoddy their issuance practices really are.

This begs the question: How does enterprise technology evolve from here, without the prodding of a tech conglomerate? In a digital ecosystem of interdependent parts, large scale changes are slow and usually painful, as different parts change and grow at different speeds, leaving others behind to catch up or fade away. Google’s decision to restrict certificates issued by Symantec and its subsidiaries acts as a catalyst for this evolution, because Google is directly impacting Symantec’s business as a certificate authority by imposing security measures that their certificate process does not meet.

Businesses who rely on websites to drive revenue will not want to worry about whether their Symantec-issued certificate will cause problems for some 60% of their visitors. There are reasonably priced alternatives readily available, issued by firms able to provide an actual trustworthy certificate to their customers. These business decisions will ultimately affect Symantec’s bottom line, perhaps providing an impetus for them to take seriously the security problems they have brushed off for years.

As bad as this is for Symantec, the real problems will affect those companies and individuals relying on the company’s certificates. Google’s rebuke will repel potential visitors who use the Chrome browser from visiting sites using Symantec certificates, while also calling the businesses’ reputations into question, as Chrome identifies them as untrustworthy sites. This is an unfortunate result for those trying to avoid this very fate by buying certificates from Symantec in the first place.

Imagine this very plausible scenario: your company uses Chrome and relies on a web application hosted on a server using a Symantec certificate to conduct business.  Chrome stops trusting that server, such that in the blink of an eye, none of your co-workers can access the website without jumping through some serious hoops. Some percentage of Chrome users will likely alter their browsing habits, and some percentage of websites will likely trade out their Symantec certificates for another brand.

In the bigger picture, we should expect to see more private-sector driven enforcement of security practices. The public interest lies in every component of our digital environment being as resilient as possible, so that we can all use services without taking on an undue amount of risk. But when a private company has no profit motive to reduce their cyber risk, and instead chooses to knowingly continue bad practices, how can this public good be achieved? In order for real digital resilience to be kindled and spread, companies will need to become proactive - not wait for the death knell of a war with Google to begin changing their ways.

[Check out the two-day Dark Reading Cybersecurity Crash Course at Interop ITX, May 15 & 16, where Dark Reading editors and some of the industry's top cybersecurity experts will share the latest data security trends and best practices.]

Related Content:

 

Mike Baukes is co-founder and co-CEO of UpGuard, a cyber resilience company based in Mountain View, California. View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
tjmatch
50%
50%
tjmatch,
User Rank: Apprentice
4/21/2017 | 9:35:25 AM
SSL Certificate
I found this post to be super valuable. However, when is your website going to upgrade to using an SSL certificate (not issued by Symmantec obviously) to better protect your readers?
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Security Operations and IT Operations: Finding the Path to Collaboration
A wide gulf has emerged between SOC and NOC teams that's keeping both of them from assuring the confidentiality, integrity, and availability of IT systems. Here's how experts think it should be bridged.
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.
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-7445
Published: 2015-10-15
The Direct Rendering Manager (DRM) subsystem in the Linux kernel through 4.x mishandles requests for Graphics Execution Manager (GEM) objects, which allows context-dependent attackers to cause a denial of service (memory consumption) via an application that processes graphics data, as demonstrated b...

CVE-2015-4948
Published: 2015-10-15
netstat in IBM AIX 5.3, 6.1, and 7.1 and VIOS 2.2.x, when a fibre channel adapter is used, allows local users to gain privileges via unspecified vectors.

CVE-2015-5660
Published: 2015-10-15
Cross-site request forgery (CSRF) vulnerability in eXtplorer before 2.1.8 allows remote attackers to hijack the authentication of arbitrary users for requests that execute PHP code.

CVE-2015-6003
Published: 2015-10-15
Directory traversal vulnerability in QNAP QTS before 4.1.4 build 0910 and 4.2.x before 4.2.0 RC2 build 0910, when AFP is enabled, allows remote attackers to read or write to arbitrary files by leveraging access to an OS X (1) user or (2) guest account.

CVE-2015-6333
Published: 2015-10-15
Cisco Application Policy Infrastructure Controller (APIC) 1.1j allows local users to gain privileges via vectors involving addition of an SSH key, aka Bug ID CSCuw46076.

Dark Reading Radio
Archived Dark Reading Radio
In past years, security researchers have discovered ways to hack cars, medical devices, automated teller machines, and many other targets. Dark Reading Executive Editor Kelly Jackson Higgins hosts researcher Samy Kamkar and Levi Gundert, vice president of threat intelligence at Recorded Future, to discuss some of 2016's most unusual and creative hacks by white hats, and what these new vulnerabilities might mean for the coming year.