In its latest blog post titled “Project Strobe: Protecting your data, improving our third-party API, and sunsetting consumer Google+,” announced were the findings of Project Strobe Google data breach. Described as a “root-and-branch review of third-party developer access to Google account and Android device data, and of our philosophy around apps’ data access” the blog post outlines four “Findings” and associated “Actions” based on the project audit.
The first Finding and Action are the most important.
“Finding 1: There are significant challenges in creating and maintaining a successful Google+ product that meets consumers’ expectations.
Action 1: We are shutting down Google+ for consumers.”
Many of us who work in development probably had a similar reaction to the Finding: “Duh, you did not need an audit to know that! There are significant challenges in the creation and maintenance of any product with a consumer base, especially one for social media!”
However, what looks like a simple attempt at stating the obvious actually masks a very serious announcement of a security data breach that was found as part of the review. Seven paragraphs in, Google admits:
- The bug was found in March 2018 and was immediately patched
- The bug left sensitive information such as user names, email addresses, occupation, gender and age exposed
- 438 applications had used the API
- Up to 500,000 Google+ Profiles were impacted
- Google cannot tell which users were impacted by the bug because they only kept the API log data for two weeks
The blog goes on to say, “Our Privacy & Data Protection Office reviewed this issue, looking at the type of data involved, whether we could accurately identify the users to inform, whether there was any evidence of misuse, and whether there were any actions a developer or user could take in response. None of these thresholds were met in this instance.”
If you have an information security mindset and are aware of various regulations and standards related to sensitive personal information (also known as Personally Identifiable Information, or PII), you are probably stunned at this point. In the last month, we have seen security-related announcements from Facebook, Twitter (who announced late last month a bug that sent unauthorized developers the direct messages and protected tweets of some users), and now, Google. All have one thing in common….
The bug was in an Application Programming Interface (API) that was in production!
It is another perfect reminder of why secure coding is vital to the security stature of a company. If you have a development team, whether in-house, remote, or contracted, you need to have a secure coding standard that has gateways, reviews and sign-offs at every step. It does not matter which software development lifecycle (SDLC) methodology you use (Agile, Waterfall, Prototype, Rapid, Extreme, etc.). All SDLCs support having a secure coding framework being placed side-by-side. Your goal is to avoid common bugs and flaws, and to always to find bugs as early in the process as possible. The industry standard in support of secure coding is the OWASP Top 10.
It is also important that your organization is aware of the various industry standards and protocols related to data security and privacy. This announcement from Google would have triggered an avalanche of activity and costs under many of these standards, including HIPAA (if healthcare information was exposed), FERPA (if student data was exposed), and PCI (if cardholder data was exposed).
Finally, you may be wondering why the Google data breach was announced on such a specific date – March 2018 – for this possible data breach and remediation. It comes down to four simple letters: GDPR. Google has already been hit this year with a huge $5 billion anti-trust fine from the European Union (EU). Had Google announced this issue after May 25, 2018, when the General Data Protection Regulation came into effect, the impact to the company would have been substantial and the fine could have been close to another $5 billion due to the number of user records impacted and the type of data exposed. Also, Google would not have been able to wait almost eight months to announce the security breach, nor would their Privacy & Data Protection Office been allowed to make the decisions it did.
What a perfect storm! What are the key takeaways from this incident?
This can happen to anyone, no matter how large or small the organization
Realize that APIs have just as many data security concerns as web applications or websites
You need a secure coding framework in place NOW
You need a comprehensive training program at all levels of your organization which addresses the responsibilities of various teams/groups
Unfortunately, none of this is going to get any easier! Development is getting more complex, as are the associated security and privacy regulations. The rules are changing and you must keep up. As in basketball and military combat, your best defense is a good offense when it comes to data security.