Bug Spells Doom for Nearly-Vacant Google+ Network

Did you ever have a Google Plus account? Neither did we, but a few people did, and most of their information just got leaked in a bug that affected 500,000 people. As a result, the search giant has shut their social media experiment down. Gone doesn’t mean forgotten however, and it turns out that even though Google Plus has been deleted, Google itself has been facing scrutiny about what led to the bug that finally killed it.

Examining what’s going on around Google Plus is going to lead us to two teachable moments:

  • First of all, half a million users might be a drop in the bucket for Google, but not for you. How can you prevent your own platform-killing bug from exposing your users?
  • Second, Google has found itself in a rather large amount of hot water, compliance-wise, subsequent to the revelation of the Google Plus bug. If one of the world’s largest companies can’t manage their own compliance, do you have a chance?

Here’s our guide to understanding what went wrong with Google Plus, as well as the lessons you should take from its demise.

Google Plus – What Went Wrong?

First of all, we stress that it was a bug – not a breach – that killed Google Plus. Google often monetizes its applications by letting developers pay to harvest user information from them via an API connection. Google Plus was no different, except that its API contained an unintended error. Here’s how it worked:

The social network stored two kinds of personal data – public and private. Public data was intended to be shared with the API, and private was not. The API bug meant that some data not intended to be public, such as email addresses, could be shared via the API.

In order to take advantage of the bug, a developer would have had to have been aware that it existed, and then reconfigured their integration with Google Plus to pull data from the network. There’s no evidence that any developer had knowledge of the bug, however, and there’s no evidence that any user lost information. Since the bug was patched as soon as it was discovered, there’s no harm and no foul – right?

It’s the Coverup, Not the Crime

Here’s the problem: The breach was discovered and patched in March 2018, but not revealed until October. Regulators on both sides of this Atlantic are very skeptical about this timeline.

In the United States, three senators have called for hearings asking why Google failed to report their breach until their hand was forced by a Wall Street Journal article on October 8th. This article both revealed the existence of a breach and pointed to a memo advising executives to cover up the breach or else risk increased regulatory pressure.

Meanwhile, in the European Union, Google’s bug came just weeks before the full activation of the GDPR. That means that they aren’t subject to the 72-hour reporting deadline that the GDPR mandates. On the other hand, this kind of incident is unlikely to improve the company’s chances as they begin to appeal a $5 billion anti-trust fine.

Google Plus Reminds Us to Keep an Eye on Compliance

APIs are tricky. Tools designed to make sharing data easier have also made it harder to avoid sharing data accidentally – who knew? If Google can’t understand how personal data from its users might be shared with developers without an extensive audit, you probably won’t either.

Meanwhile, the actions that Google took to conceal the Google Plus bug were shady. Furthermore, the advent of the GDPR and the reaction of the US Senate show that there’s no viable path for burying news of a data breach anymore. Information about the breach will leak, and there will be consequences.

How can Safe-T help you out? We can make it so that when potential data breaches occur in your platform, they get flagged immediately. Our Secure Application Access product moderates the data exchange between two or more applications. In addition to preventing insecure access between applications, Safe-T makes it easy to place DLP in line with your apps, letting you detect the inadvertent exchange of personal information before it becomes an issue.

Want to learn more about Safe-T and how we can prevent bugs, breaches, and compliance violations? Contact us and sign up for a free demo today
Software Defined Access

*** This is a Security Bloggers Network syndicated blog from Safe-T Blog authored by Eitan Bremler. Read the original post at:

Cloud Workload Resilience PulseMeter

Step 1 of 8

How do you define cloud resiliency for cloud workloads? (Select 3)(Required)