Image via CrunchBase
As the clouds continues to roll in, (Sorry, I had to…), we are learning of more attacks being successful against organizations such as Google, Facebook, and others. The latest is from a security researcher, Christian Heinrich, located in Australia. He reverse engineered the algorithm Facebook uses to access your personal photos. Since Facebook is a massively distributed application, items such as photos and larger files are placed into a content distribution network (CDN) such as that provided by Amazon, Akamai, and others in order to reduce the load on Facebook’s servers. The thing is, the CDNs don’t integrate into Facebook’s authentication framework since the CDN just stores files and serves them to anyone that requests the proper filename. Guess the filename of the private photos for a person on Facebook, send the request to the CDN, and you get the photo in return.
And that is what led to an arrest and charges for a privacy breach. During his presentation, Heinrich demonstrated this vulnerability at Flickr, Facebook, and MySpace. He demonstrated how we could access the private photos of his fellow researcher, Chris Gatford’s, wife. One example showed a picture of Chris Gatford’s wife and child. The Queensland Police responded to a complaint, although we don’t know who filed the complaint, about Heinrich’s breach of Chris Gatford’s wife’s privacy caused by the demonstration. The Police responded by arresting a reporter for the Sidney Morning Herald, who had interviewed Heinrich about his presentation, and seized the reporter’s iPad.
Is this really Facebook’s or Flickr’s problem or the CDN’s? It most definitely is the content producer’s problem. The CDN network could provide authentication and more advanced security controls but that lowers performance by 30% or more for each transaction.
Ah, the old security versus performance argument. That age old argument is why this little and perhaps unknown arrest in Australia affects your organization whether you are using a CDN or not. When the performance versus security argument comes up during your career, the focus must be on the data type being discussed. Usually, the data type(s) being discussed including different types of data that need to be enhanced for performance to increase. It is likely that as you dive in deeper, many of pieces of data will not be private or confidential, but if they are you must stick to your security guns and only allow authenticated and authorized access to that data. The other data you can push out and optimize all the organization wants.
Your argument back to IT or development about the perceived performance gains they believe they can achieve by optimizing the data is one of analysis. You must ask to analyze the estimated increase in performance of only allowing the non-confidential data to be accessed without security controls. Meeting them halfway by only optimizing the non-confidential data results in them having to accept a 15% or 20% increase in performance, which may be less than what they were estimating, but it is better than no increase at all.
I just released a report for Dark Reading on how to build a multi-enterprise vulnerability management program. If you are dealing with outsourced vendors, or an outsourced supply chain, you should definitely give the article a read.
To summarize the article:
I offer many more details and tips within the article but step #1 is so critical that an entire article should be dedicated to just that!
Verizon Business Christian Moldes as a great post about Plane Crashes and Security Breaches and how they are very similar. He hits it right on the head! During our engagement wrap-up meetings where we explain the various potential scenarios an attacker can use to break into a client’s network we are always asked to put a specific ranking on a specific risk. I argue that that almost doesn’t matter because normally the big breaches are not from a single vulnerability but many chained together.
Christian quotes Malcom Gladwell, and says:
The typical [plane] accident involves seven consecutive human errors.
When we work with clients we normally see that breaches are caused by a chaining of at least three errors: exploitation of a vulnerability, then a mis-configuration is used to find a privileged account user name and password, and then data is found on the network somewhere it wasn’t supposed to be that the privileged account has access too.
Even with many controls in place you cannot always prevent a security breach. This is the exact reason why we recommend that incident response policies and processes (Which should be tested like you test your Disaster Recovery processes!) should be the FIRST THING you implement when building a security program at an organization followed by detective controls such as logging to detect a breach as soon as possible.
