By Splunk October 29, 2007
Facebook is getting a lot of flak in the press (latest in the Register) about reports on a gossip blog about some pretty serious privacy holes:
1. anyone that works there can look at anyone’s private profile
2. anyone who works there can look at logs of what other profiles any user has seen.
If Facebook wants to turn their act around, or any other social networking site wants to avoid being in their position, they’d better pay attention to some best practices around securing and reviewing IT data.
Here’s what best practice would say about Facebook’s two problems.
The first problem – anyone can look at any customer’s data – is classically the kind of thing that has brought on regulations in other industries, such as PCI-DSS, which was introduced by VISA to ensure that merchants processing credit cards keep consumer financial info private. Like credit cards, a lot of the information people post to their private profiles is a goldmine for identity thieves – Information Week made this argument about Faceboook even before the latest flap. If I know your birthdate and mother’s name I’m a lot further along in social engineering an unwitting customer support rep into believing I’m you. And yes, identity thieves do have insiders – ask Ford Motor Credit.
A major measure that organizations who are following best practices for privacy are supposed to take is to lock down this private information to only insiders with a need-to-know – obviously Facebook’s not doing that. But once they do put the right access controls in place, they’re going to need to put in a review procedure to watch privileged employees. Facebook’ security or privacy staff should be reviewing logs of who has accessed private info and ensuring that there was a valid business reason for each access. The review should include:
- logs generated by Facebook’s application itself to see employees with admin access coming in the front door
- audit tables for the back end databases to be sure that the database admins who manage the database back-end aren’t bypassing the application’s permissions and doing manual queries to see what they shouldn’t
- filesystem audit logs, to be sure that server or storage admins aren’t bypassing both the database and the app to look at the data on the filesystem itself
The second problem – that any employee can look at logs of what users have done – is a bit less well understood privacy issue. It’s probably particularly bad on a social networking site – do you really want your ex knowing you’re watching their profile? But you may not want every Amazon employee being able to see what items you’re browsing, so it’s an issue that affects almost any site to some degree.
To address the second issue, logs themselves need to be securely captured into a system that provides appropriate access controls to the logs themselves as well as an audit trail of who’s looked at the logs – which the security team should be reviewing proactively. Unfortunately, access logs are hardly ever considered to have privacy implications inside large sites. As evidenced by last year’s infamous publication of AOL search records.
Keeping these logs around that show who looked at what is going to be important too – law enforcement could subpoena Facebook for logs if unauthorized access by their employees is suspected to be a part of a criminal act. Facebook won’t want to be in a position where they can’t produce the logs.
The biggest reason Facebook should take this seriously? An overzealous plaintiff’s attorney somewhere is probably salivating over all the cash they raked in from Microsoft and figuring out how to sue Facebook for cash damages if a Facebook privacy breach leads to financial losses or serious personal harm, using the argument that by not following the same standard as other sites they’ve not met their “duty of care.” Think they can’t do it? TJ Maxx is getting sued right now on similar grounds.