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?
COVID-19: Latest Security News & Commentary
Dark Reading Staff 8/3/2020
Pen Testers Who Got Arrested Doing Their Jobs Tell All
Kelly Jackson Higgins, Executive Editor at Dark Reading,  8/5/2020
New 'Nanodegree' Program Provides Hands-On Cybersecurity Training
Nicole Ferraro, Contributing Writer,  8/3/2020
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Changing Face of Threat Intelligence
The Changing Face of Threat Intelligence
This special report takes a look at how enterprises are using threat intelligence, as well as emerging best practices for integrating threat intel into security operations and incident response. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-08-07
An issue was discovered in PassMark BurnInTest through 9.1, OSForensics through 7.1, and PerformanceTest through 10. The driver's IOCTL request handler attempts to copy the input buffer onto the stack without checking its size and can cause a buffer overflow. This could lead to arbitrary Ring-0 code...
PUBLISHED: 2020-08-07
An issue was discovered in PassMark BurnInTest through 9.1, OSForensics through 7.1, and PerformanceTest through 10. The kernel driver exposes IOCTL functionality that allows low-privilege users to map arbitrary physical memory into the address space of the calling process. This could lead to arbitr...
PUBLISHED: 2020-08-07
Spring Cloud Netflix, versions 2.2.x prior to 2.2.4, versions 2.1.x prior to 2.1.6, and older unsupported versions allow applications to use the Hystrix Dashboard proxy.stream endpoint to make requests to any server reachable by the server hosting the dashboard. A malicious user, or attacker, can se...
PUBLISHED: 2020-08-07
SecurEnvoy SecurMail 9.3.503 allows attackers to upload executable files and achieve OS command execution via a crafted SecurEnvoyReply cookie.
PUBLISHED: 2020-08-07
In Mahara 19.04 before 19.04.6, 19.10 before 19.10.4, and 20.04 before 20.04.1, certain places could execute file or folder names containing JavaScript.