FTC: What Are Reasonable Safeguards To Protect Users’ Information?.

A couple of weeks ago, RockYou settled with the FTC on the “charges that, while touting its security features, it failed to protect the privacy of its users, allowing hackers to access the personal information of 32 million users.” (ftc.gov).  This is not the first time that FTC has brought charges against a company for promising more than it did when it comes to data security and data privacy.

Most overseeing bodies don’t require that an organization — be it a for-profit company or otherwise — provide complete, fail-proof security that will prevent data breaches one hundred percent of the time.  Ask any security professional worth his or her mettle; they’ll tell you it cannot be done.  It’s like trying to reach perfection: 99.9999% is good, extremely good, but not perfection if it’s not 100%.

However, it is expected for these same companies to provide reasonable safeguards.  So, what types of solutions and actions are included under the term “reasonably safe”?

It might surprise you.

Reasonable Safeguards: RockYou

According to the FTC complaint regarding RockYou’s practices (my emphases):

Contrary to its representations that it provided reasonable safeguards to protect its users’ information, Defendant failed to take reasonable measures to do so by, among other things:

  1. unnecessarily collecting personal information from consumers in the form of  email address passwords;

  2. storing user’s  RockYou passwords, with associated email addresses, in clear text;

  3. failing to segment its servers; once a hacker entered Defendant’s network he or she was able to access all information on the network, including consumers’ email addresses and RockYou passwords;

  4. not protecting its website from such commonly known or reasonably foreseeable attacks from third parties attempting to obtain access to customer information stored in Defendant’s databases.  Defendant failed, for example, to address vulnerabilities in its system to web-based application attacks such as “Structured Query Language” (SQL) injection attacks and “Cross-Site Scripting” (XSS) attacks.  During the relevant period, SQL injection and XSS attacks were well-known and well-publicized forms of hacking attacks, and solutions to prevent such attacks were readily-available and inexpensive.

Does the above surprise you?  It should.  I mean, storing passwords in clear text is stupid, but one wouldn’t think of it as illegal.  But the FTC is essentially saying that it is by singling out the storage of passwords in plaintext when filing the complaint.  Likewise for database segmentation and protection against SQL injection attacks.

Well, not technically, as the helpful note below shows (again, my emphasis):

NOTE: The Commission authorizes the filing of a complaint when it has “reason to believe” that the law has been or is being violated, and it appears to the Commission that a proceeding is in the public interest. The complaint is not a finding or ruling that the defendants have actually violated the law. This consent decree is for settlement purposes only and does not constitute an admission by the defendants of a law violation. Consent decrees have the force of law when signed by the District Court judge.

I guess that, technically, these are just accusations, and one needs to have it hashed out in court to see if they’re illegal practices.  (Personally, I don’t see them being classified as such).

Regardless of actual legal status, we can take a cue on what the FTC frowns upon and match data security policies and practices as necessary.

Related Articles and Sites:

Comments (0)

Let us know what you think