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
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?
7 Truths About BEC Scams
Ericka Chickowski, Contributing Writer,  6/13/2019
DNS Firewalls Could Prevent Billions in Losses to Cybercrime
Curtis Franklin Jr., Senior Editor at Dark Reading,  6/13/2019
Can Your Patching Strategy Keep Up with the Demands of Open Source?
Tim Mackey, Principal Security Strategist, CyRC, at Synopsys,  6/18/2019
Register for Dark Reading Newsletters
White Papers
Current Issue
Building and Managing an IT Security Operations Program
As cyber threats grow, many organizations are building security operations centers (SOCs) to improve their defenses. In this Tech Digest you will learn tips on how to get the most out of a SOC in your organization - and what to do if you can't afford to build one.
Flash Poll
The State of IT Operations and Cybersecurity Operations
The State of IT Operations and Cybersecurity Operations
Your enterprise's cyber risk may depend upon the relationship between the IT team and the security team. Heres some insight on what's working and what isn't in the data center.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2019-06-20
A vulnerability in the web-based management interface of Cisco Prime Service Catalog Software could allow an unauthenticated, remote attacker to conduct a cross-site request forgery (CSRF) attack on an affected system. The vulnerability is due to insufficient CSRF protection mechanisms on the web-ba...
PUBLISHED: 2019-06-20
A vulnerability in the web-based management interface of Cisco Prime Service Catalog could allow an authenticated, remote attacker to conduct a cross-site scripting (XSS) attack against a user of the web-based interface. The vulnerability is due to insufficient validation of user-supplied input by t...
PUBLISHED: 2019-06-20
A vulnerability in the HTTPS proxy feature of Cisco Wide Area Application Services (WAAS) Software could allow an unauthenticated, remote attacker to use the Central Manager as an HTTPS proxy. The vulnerability is due to insufficient authentication of proxy connection requests. An attacker could exp...
PUBLISHED: 2019-06-20
A vulnerability in the Cisco Discovery Protocol (CDP) implementation for the Cisco TelePresence Codec (TC) and Collaboration Endpoint (CE) Software could allow an unauthenticated, adjacent attacker to inject arbitrary shell commands that are executed by the device. The vulnerability is due to insuff...
PUBLISHED: 2019-06-20
A vulnerability in the CLI of Cisco Integrated Management Controller (IMC) could allow an authenticated, local attacker to inject arbitrary commands that are executed with root privileges. The vulnerability is due to insufficient validation of user-supplied input at the CLI. An attacker could exploi...