Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


10:30 AM
Jason Straight
Jason Straight
Connect Directly
E-Mail vvv

FTC v. Wyndham: ‘Naughty 9’ Security Fails to Avoid

The Federal Trade Commission's fair trade suit against Wyndham hotels offers insight into the brave new world of cybersecurity regulation of consumer data.

“Release the hounds!” Rumor has it that this refrain could be heard reverberating through the halls of the Federal Trade Commission following the Third Circuit Court of Appeals decision affirming the FTC’s ability to sue companies it believes failed to diligently protect consumer information. Well… maybe not.  But there is little doubt that the Court’s decision in FTC v. Wyndham will embolden the FTC’s efforts to regulate corporate cybersecurity practices. So how could the decision impact your company? Let’s take a closer look.

Since part of the FTC’s mandate is to protect consumers, the first question to ask is whether your company could be subjected to enforcement under Section 5 of the FTC Act for “unfair” or “deceptive” trade practices. With the Wyndham decision, the FTC has been cleared to assert violations against companies that it believes have misled consumers about the level of protection the company would apply to their sensitive information, or failed to implement a reasonably prudent set of protections that the average consumer would expect the company to provide. Perfectly, clear, right? Hardly. So let’s break it down a little further.

It’s important to understand that the Wyndham case revolves around data breach incidents dating back to 2008 and 2009. One of the challenges Wyndham faces is to ensure that it is being judged based on what level of protection was “reasonable” in 2008 – which, given the rapid evolution of cyber threats since then, is practically the Stone Age. To illustrate, let’s look at the core set of specific security failures the FTC has alleged as part of its claim. I call them the FTC’s “Naughty Nine” (paraphrased for clarity and brevity):

  1. Failed to employ “readily available” protections, such as firewalls to limit access between the corporate network and the Internet
  2. Stored sensitive payment card data in clear, readable text (i.e. unencrypted)
  3. Failed to remedy “known security vulnerabilities” caused by using out-of-date operating systems, and failing to patch properly
  4. Used easily obtainable default log-in credentials on devices connected to the corporate network
  5. Failed to require complex passwords for access to the corporate network
  6. Failed to maintain an accurate hardware inventory of devices connected to the corporate network
  7. Failed to employ reasonable measures to detect and prevent unauthorized access to its computer network or to conduct security investigations
  8. Failed to follow proper incident response procedures
  9. Failed to adequately restrict third-party access to the corporate network “such as by restricting connections to specified IP addresses, or granting temporary or limited access”

The FTC alleges that the combination of these failures facilitated three data breach incidents that exposed more than 600,000 payment cards and led to more than $10 million in fraudulent charges.  As an aside, the impact numbers are almost quaint by today’s standards, where breaches exposing tens of millions of cards at a time have occurred.

Looking at the FTC’s list of Wyndam’s alleged failures, ask yourself whether your company could be tagged with any of the same allegations. If you say ‘yes’ or ‘I don’t know’, don’t be too hard on yourself. Companies with mature cybersecurity operations can likely check off all the boxes above. But for many mid-sized companies with whom we conduct incident response and risk assessments, we observe at least one of these failures almost on a daily basis – and many with several failures all at once. Moreover, as we’ve seen in breaches over the past two years, attackers are getting better at defeating even mature cybersecurity defenses to obtain payment and other sensitive consumer information. So the bar is constantly being raised. 

I think few would argue that employing firewalls is a fundamental component of a basic cybersecurity program, but do companies now have an obligation to purchase and deploy “next generation” firewalls, or other “readily available” technologies? Although most companies have a policy requiring complex passwords, how many strictly enforce this – with no exceptions (even for the CEO)? How many of you are 100% certain that you are not running any network devices that still use the same access credentials they had coming out of the box? I can guarantee that many of you are not confident you have an accurate inventory of the hardware (let alone software) running on your network. Even with the added attention being paid to third-party risk, many companies still fail to appropriately restrict vendor access beyond what is minimally necessary.

[More on Cybersecurity Under FTC Authority from Tom Kellerman, chief cybersecurity officer at Trend Micro]

So what should you do?  Focusing on the “Naughty Nine” is a good place to start assessing whether you may draw the ire of the FTC in the event of a breach and to determine if you can defensibly articulate how you are meeting these standards. Companies with a more mature security infrastructure should attempt to determine what the FTC’s naughty list might look like today. Unless you already have a framework of choice, I’d recommend the SANS 20 Critical Security Controls as an excellent starting point. Picture sitting across the table from an FTC lawyer or in front of a judge and explaining how your company satisfies each of the control standards. Make a note of where you start to stammer, sweat or feel nauseous – that’s probably where you need to focus some attention.

Lastly, there is one item among the “Naughty Nine” that remains a persistent challenge for most companies:  incident response and investigation. We maintain that a defensible and well-defined incident response process is the single most important piece of an information security program because no matter how good your intrusion prevention technologies may be, a sophisticated or lucky attacker is going to get in sooner or later. You need to be ready to respond with confidence. A good incident response plan involves more than just basic detection, investigation, containment, eradication and recovery. It also includes minimizing legal liability, reputational impact and employee morale issues that can result from a breach. Today’s incident response plan is a living document with multiple stakeholders as owners. Legal, HR, Finance, PR in addition to IT and Security functions must be involved in creating, maintaining and, when necessary, executing the plan. 

None of these approaches will make you immune to the FTC’s enforcement efforts but they will put you in a more defensible position if you do draw their unwanted attention. With the Wyndham decision on the books, now is a good time to take a closer look at your security posture.

Jason Straight<http://www.unitedlex.com/about-us/jason-straight.php> is the Senior Vice President and Chief Privacy officer at UnitedLex<http://www.unitedlex.com/>. He has more than a decade of experience assisting clients in managing information security risks, ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Ninja
9/29/2015 | 12:28:13 PM
Re: Point 3
I am all for the nuclear option...unfortunately I don't think the business side will be on board.
[email protected],
User Rank: Apprentice
9/28/2015 | 6:36:43 PM
Re: Point 3
The nuclear option (i.e. stop using Java) has been recommended by some security pros and is the only one i am aware of that will truly solve this problem, but that is probably not the response you're looking for.  I'll let the IT security ops folks weigh in on this but Java seems to occupy its own special island in the patch management world for exactly the reasons you highlight.  It's a classic situation of balancing security against business needs - you can patch aggressively (and even automatically) and risk breaking apps and disrupting business or you can continue rolling the dice by not patching in a timely fashion.  The middle ground might be to try to assess the risk and potential impact of each newly disclosed Java vulnerability in YOUR environment and make prioritizing decisions on a patch-by-patch basis. 

If I had a better idea, I would sell it to Oracle and buy my own special island!

Anyone else have suggestions?


User Rank: Ninja
9/28/2015 | 3:04:08 PM
Point 3
Its amazing the amount of organizations that are heavily tech-ified not having an efficient patching process. There are gaps unfortunately even with efficient patching processes when it comes to legacy apps.

IE: When an app is coded for a specific version of Java, even though all Java versions are backwards compatible of each, it will not perform as intended due to the hardcoding. Due to this, older versions that are vulnerable will remain on the network. How could this best be handled to avoid the one of the Naughty 9?
FluBot Malware's Rapid Spread May Soon Hit US Phones
Kelly Sheridan, Staff Editor, Dark Reading,  4/28/2021
7 Modern-Day Cybersecurity Realities
Steve Zurier, Contributing Writer,  4/30/2021
How to Secure Employees' Home Wi-Fi Networks
Bert Kashyap, CEO and Co-Founder at SecureW2,  4/28/2021
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-05-06
The &quot;gitDiff&quot; function in Wayfair git-parse &lt;=1.0.4 has a command injection vulnerability. Clients of the git-parse library are unlikely to be aware of this, so they might unwittingly write code that contains a vulnerability.
PUBLISHED: 2021-05-06
Exim 4 before 4.94.2 has Execution with Unnecessary Privileges. By leveraging a delete_pid_file race condition, a local user can delete arbitrary files as root. This involves the -oP and -oPX options.
PUBLISHED: 2021-05-06
Jellyfin is a free software media system that provides media from a dedicated server to end-user devices via multiple apps. Verions prior to 10.7.3 vulnerable to unauthenticated Server-Side Request Forgery (SSRF) attacks via the imageUrl parameter. This issue potentially exposes both internal and ex...
PUBLISHED: 2021-05-06
Mixme is a library for recursive merging of Javascript objects. In Node.js mixme v0.5.0, an attacker can add or alter properties of an object via 'proto' through the mutate() and merge() functions. The polluted attribute will be directly assigned to every object in the program. This will put the ava...
PUBLISHED: 2021-05-06
Improper input validation of octal strings in Python stdlib ipaddress 3.10 and below allows unauthenticated remote attackers to perform indeterminate SSRF, RFI, and LFI attacks on many programs that rely on Python stdlib ipaddress. IP address octects are left stripped instead of evaluated as valid I...