@JamieXML pinged me about the @18F breach that I completely missed. I quickly googled it and found this article.
IG report:18F’s unauthorized Slack use caused breach of 100 GSA Google Drives
It refers to “MANAGEMENT ALERT REPORT:GSA Data Breach” [JE16-004], which is a very strange report.
It says “over 100 GSA Google Drives were reportedly accessible by users both inside and outside of GSA”. However, it does not state how it was possible to access those files from outside of GSA.
What data breach?
Unless there is a security hole in Slack, the files does not go outside of the 18F group. What happened seems to be the indexing of drives by Slack and providing of previews, which potentially have shown a part of the file that should not be shown to another person in 18F. From the personal data point of view, Slack is a data processor, so I would not characterize the files being shared to Slack a data breach in a conventional sense: an unauthorized data transfer to a third party that becomes a data controller upon receipt of the data. Instead, it is an access control policy violation within the organization, 18F in this case. From the personal data protection point of view, access control is used to achieve Data Minimization. So, it can be characterized as Data Minimization breach.
In addition, it is not in compliance with their policies. Apparently, according to JE16-004, neither Slack nor OAuth 2.0 were approved technology for them to use. Thus, it is clearly a policy compliance breach.
So, I see two breaches here. Data minimization breach and the internal policy breach. IMHO, these aspects should be communicated better instead of labeling it bluntly as “Data Breach”. It causes misunderstandings among the readers. Combined with the statement “accessible by users both inside and outside of GSA” in JE16-004 paragraph 1, it is easy to misunderstand that the data went out in the wild. This can be evidenced by the tweet that such a savvy person like @JamieXML making:
If Jamie read it as “wide open”, then I gather that 99% of people would read the same.
Other peculiarities that I found
There are couple of other peculiarity of JE16-004 that I noticed.
Treating a protocol and service in the same bucket of “technology” causes confusion
JE16-004 seems to treat OAuth 2.0 and Slack in the same bucket, but they are really different kind of things. OAuth 2.0 is a protocol, while Slack is a service. It is like grouping a knife and a restaurant as “food industry”. If it were a knife and a restaurant, most people would be able to figure out the difference in the nuances. However, most people probably does not know OAuth 2.0 and thus will have no ability to detect the difference.
Allowing Google Drive and not allowing OAuth 2.0 is a touch strange
JE16-004 states that OAuth 2.0 is not approved technology while Google Drive is an approved technology. That begs a question: what is the authorization protocol used by the Google Drive client and the server? I did a quick search, but I could not find it, apart from the fact that it is using an HTTPS based protocol. So, I went onto installing the Google Drive client on my machine. After installation, I have to log in. The login screens looks exactly like other Google sign-ins. Google sign-in uses OpenID Connect, that uses OAuth 2.0 as an underlying framework. So, this suspiciously looks like Google Drive client is using OAuth 2.0. Maybe it is just the user interface, but … . From a security point of view, if it were not using OAuth 2.0 and using stored password to get file access, it is much worse.
OAuth 2.0 is not authentication process
JE16-004 says: ” In order to permit the sharing of files from GSA Google Drive with team members in Slack, 18F uses OAuth 2.0, an authentication and authorization process.” I keep preaching this. OAuth 2.0 is not an authentication process/protocol. It can be used to construct an authentication process/protocol, but OAuth 2.0 is not. A government document writing that OAuth 2.0 an authentication process would cause many people to use raw OAuth 2.0 as authentication process causing a lot of security holes and data breaches, so, IMHO, such document should be more careful in delineating authentication and authorization.
Oops. It is now 3:40am here in Frankfurt. I am clearly in violation of my internal policy of being in bed by 2:00am unless I am having a overseas conference call. I should quickly rectify the situation.
One last thing: Read ISO/IEC 29100 Privacy Framework. It will help you a lot.