LinkedIn: The Breach That Isn't but Is

Image: Photo by Nahel Abdul Hadi on Unsplash

The definition of a data breach seems to be reasonably straightforward and easy to understand — but that isn’t always the case. LinkedIn is back in the news thanks to a dataset containing profile information for 700 million records being traded among the darker actors on the internet. But LinkedIn is very clear about how they view this situation:

This was not a LinkedIn data breach and our investigation has determined that no private LinkedIn member data was exposed.

This statement is sufficiently unambiguous, but that fact remains that data about their members are being traded freely. So, is this a breach or not?

What is a data breach? #

According to Wikipedia, it’s “the intentional or unintentional release of secure or private/confidential information to an untrusted environment.” Though this doesn’t answer the question as there’s the question of what’s secure or private/confidential information. ISO 27040 gives us the definition as “compromise of security that leads to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to protected data transmitted, stored or otherwise processed.” This doesn’t exactly answer the question either.

Perhaps the right way to define a data breach is to craft a new definition that is a bit more clear: the release of information that is expected to remain private or otherwise restricted. I think most people would agree that this aligns with their mental model of a data breach.

A Data Breach or Not? #

It’s being reported that according to the attacker, the data was scraped using a LinkedIn API, leveraging that API to collect as much information as possible (though LinkedIn has stated that it’s a combination of their data and data from other sources). The data contains various information, such as email, name, phone number, geolocation data, Facebook profile, and more. All of this is data that users have provided to LinkedIn to build their profiles. In addition, LinkedIn provides this data to others, from third parties using their integration products to other users.

This raises the question, did users have a reasonable expectation that LinkedIn would protect this data? When data is provided to a social media company, most users aren’t aware of how it will be used or exposed. This can result in a situation where a user’s expectations don’t accurately align with what’s actually happening.

In this case, there is data that LinkedIn is knowingly making available, which has been collected and enhanced with data from other sources; this isn’t a breach in that the information is public, not protected, or otherwise private. So while users may see this as a breach, both of data and trust, it likely doesn’t meet the definition.

LinkedIn did clarify that this type of data scraping is a violation of their terms of service; relying on a legal document that almost no one reads to prevent their data from being used in illegal attacks doesn’t seem to be the most effective strategy. However, that’s the hill they’ve decided to make a stand on.

Distinction without Difference #

However, something that should be acknowledged is that it likely doesn’t matter if this is technically a breach or not; the impact to users is essentially the same. Data has been exposed that can be leveraged to simplify spearphishing, social engineering, and other attacks; it can also be further enriched in the future to enable new attacks.

So even though LinkedIn’s position that there wasn’t a breach is likely correct (from a technical point of view), it’s also wrong in that it’s a distinction without a difference. Making an argument from a technical perspective discounts the impact to users for the sake of protecting their brand does a disservice to the very users that have made them successful.

Adam Caudill

Security Done Wrong: Leaky FTP Server

Update: I’ve just spoken to AMI, and received some very important information; so here are the key points and clarifications: To clarify, the ‘vendor’ I refer to is a customer of AMI; it is this customer’s public FTP server that exposed this information. Per AMI, the signing key included in the ‘Ivy Bridge’ archive is a default test key; AMI instructs customers to change the key before building for a production environment.

Win by Building for Failure

Systems fail; it doesn’t matter what the system is. Something will fail sooner or later. When you design a system, are you focused on the happy path, or are you building with the possibility of failure in mind? If you suffered a data breach tomorrow, what would the impact be? Does the system prevent loss by design, or does it just fall apart? Can you easily minimize loss and damage, or would an attacker have free rein once they get in?

The (Questionable) Future of YAWAST

The last release of YAWAST was on January 1, 2020; while the release history was sometimes unpredictable, the goal was a new release each month with new features and bug fixes. I intentionally took January off from the project. In February, I left the company I was at; the team of penetration testers there had helped to inspire new features while looking for ways to make them more productive. But something else happened in February, an issue was opened – something that appeared to be simple, but in fact, made me realize that the entire project was in doubt.

Dezinformatsiya

I recently wrote a review on Active Measures by Thomas Rid – which helped me to solidify my thoughts on social media, and the impact it has on society. While Active Measures is focused on disinformation campaigns, it also speaks to the vulnerabilities in humans that allow these campaigns to work. Disinformation is a substantial issue today, and not just in terms of election interference, public health, or international relations – but also in much smaller scale unorganized efforts to alter perception.

Checklist: Starting a Security Consulting Firm

Recently a friend of mine asked for input on what would be needed to launch a new security consulting company, to help him out I drafted a detailed list of what would need to be done for a successful launch. Here is an expanded version of that list, hopefully others will find this useful as well. This isn’t the simplest route to setting up a new business, but is intended to set the business up for long-term success.