Attacks/Breaches

9/25/2015
10:30 AM
Jason Straight
Jason Straight
Commentary
Connect Directly
LinkedIn
RSS
E-Mail vvv
0%
100%

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
Comments
Newest First  |  Oldest First  |  Threaded View
RyanSepe
50%
50%
RyanSepe,
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.
Jason.straight@unitedlex.com
50%
50%
[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?

 

 
RyanSepe
50%
50%
RyanSepe,
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?
Crowdsourced vs. Traditional Pen Testing
Alex Haynes, Chief Information Security Officer, CDL,  3/19/2019
BEC Scammer Pleads Guilty
Dark Reading Staff 3/20/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Well, at least it isn't Mobby Dick!
Current Issue
5 Emerging Cyber Threats to Watch for in 2019
Online attackers are constantly developing new, innovative ways to break into the enterprise. This Dark Reading Tech Digest gives an in-depth look at five emerging attack trends and exploits your security team should look out for, along with helpful recommendations on how you can prevent your organization from falling victim.
Flash Poll
The State of Cyber Security Incident Response
The State of Cyber Security Incident Response
Organizations are responding to new threats with new processes for detecting and mitigating them. Here's a look at how the discipline of incident response is evolving.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-4035
PUBLISHED: 2019-03-22
IBM Content Navigator 3.0CD could allow attackers to direct web traffic to a malicious site. If attackers make a fake IBM Content Navigator site, they can send a link to ICN users to send request to their Edit client directly. Then Edit client will download documents from the fake ICN website. IBM X...
CVE-2019-4052
PUBLISHED: 2019-03-22
IBM API Connect 2018.1 and 2018.4.1.2 apis can be leveraged by unauthenticated users to discover login ids of registered users. IBM X-Force ID: 156544.
CVE-2019-9648
PUBLISHED: 2019-03-22
An issue was discovered in the SFTP Server component in Core FTP 2.0 Build 674. A directory traversal vulnerability exists using the SIZE command along with a \..\..\ substring, allowing an attacker to enumerate file existence based on the returned information.
CVE-2019-9923
PUBLISHED: 2019-03-22
pax_decode_header in sparse.c in GNU Tar before 1.32 had a NULL pointer dereference when parsing certain archives that have malformed extended headers.
CVE-2019-9924
PUBLISHED: 2019-03-22
rbash in Bash before 4.4-beta2 did not prevent the shell user from modifying BASH_CMDS, thus allowing the user to execute any command with the permissions of the shell.