Shortly after the new year, the Federal Trade Commission filed suit in the Northern District of California against D-Link Corporation, a Taiwan-based maker of wireless routers, Internet Protocol (IP) cameras, and software used in consumer electronics (such as baby monitors). The complaint alleges that D-Link failed to reasonably secure its products from hackers. Notably, the FTC has not alleged that D‑Link products were exploited by hackers or that a data breach or cyberattack resulted from any alleged security vulnerabilities. Rather, the action is based squarely on security vulnerabilities that “potentially compromis[ed] sensitive consumer information, including live video and audio feeds from D-Link IP cameras” and marketing statements made by D-Link that touted the products’ security features.
This case is a poignant reminder that regulators not only investigate data breaches but also security flaws that could expose consumer information. While there are no specified security standards or prescriptive requirements that immunize a company from FTC enforcement, there are several key takeaways from D-Link that inform how companies should design and execute their security programs. This is particularly true for devices like D-Link’s routers and cameras—and other “Internet of Things” (IoT) products—that provide for online connectivity/interactivity with physical hardware. Although both the Department of Homeland Security (DHS) and the National Institute of Standards and Technology (NIST) have attempted to develop security guidance for IoT, the reality is that a regulation in this space may not see the light of day, given the Trump administration’s recent executive order requiring that for every one new regulation, two must be rescinded.
The FTC’s complaint cites advertising claims made on D-Link’s website that promoted the router’s security-related features, including materials with headlines such as “EASY to SECURE” and “ADVANCED NETWORK SECURITY.” D-Link also posted a “Security Event Response Policy” on its product support page stating, among other things, that “D-Link prohibits at all times . . . any intentional product features or behaviors which allow unauthorized access to the device or network.”
Despite these representations, the FTC alleged that D-Link failed to reasonably address “well-known” and “easily preventable security flaws,” such as:
- “hard-coded” login credentials integrated into D-Link camera software—such as the username “guest” and the password “guest”—that could allow unauthorized access to the cameras’ live feed;
- a software flaw known as “command injection” that could enable remote attackers to take control of consumers’ routers by sending unauthorized commands to the routers over the Internet;
- the mishandling of a private key code used to sign into D-Link software, such that it was openly available on a public website for six months; and
- leaving users’ login credentials for D-Link’s mobile app unsecured in clear, readable text on their mobile devices, even though there is free software available to secure the information.
The import of these security vulnerabilities, according to the FTC’s press release, is that hackers can exploit them to “obtain consumers’ tax returns or other files stored on the router’s attached storage device” or “use the router to attack other devices on the local network.” In addition, “by using a compromised camera, an attacker could monitor a consumer’s whereabouts in order to target them for theft . . . or watch and record their personal activities and conversations.”
It is worth noting that the D-Link complaint is not the FTC’s first foray into data privacy and data security related to Internet-of-Things devices. The FTC has been focused on the data privacy and data security aspects of the IoT for some time. In the past several years, the FTC brought two significant cases involving security vulnerabilities in IoT devices. In 2014, the FTC obtained a consent decree from TRENDnet, a maker of home video cameras designed to allow consumers to remotely monitor their homes, based on allegations that its SecurView home and baby cameras were insecure, resulting in a hacker publicly posting links to live feeds of nearly 700 cameras in 2012. More recently, ASUSTeK Computer (ASUS) settled FTC allegations that critical security flaws in its routers and insecure cloud services put hundreds of thousands of customers at risk and led to the compromise of consumers’ connected storage devices. In 2015, the FTC Staff Report, Internet of Things: Privacy and Security In A Connected World, noted concerns about the lack of transparency and lack of meaningful consumer control in some IoT devices and called for Congress to enact broad-based data security legislation applicable to IoT as well as to traditional technologies. That, however, has not happened.
The D-Link case is particularly noteworthy because there is no allegation of any hacker having actually exploited the alleged security vulnerabilities to perpetrate identify theft, fraud, or to otherwise harm consumers. Instead, the FTC relied on D-Link’s alleged deceptive statements about data security and claimed that the risk caused by D-Link’s alleged failure to take reasonable steps to secure the software for their routers and cameras was “likely to cause substantial injury to consumers” and was an unfair practice.
Companies should be thoughtful in incorporating the learnings from D-Link and how the issue of “security vulnerabilities” impacts compliance and risk-mitigation programs.
- Companies should identify “well-known” or “easily preventable” security flaws through security‑by-design processes. Even though the FTC does not have an articulated list of, or guidelines for, adequate data security processes, it frequently calls out companies for failures to implement readily available fixes for well-known security flaws. In the 2015 guide, Start With Security, the FTC identified more than a dozen such cases. “There is no way to anticipate every threat,” it says, but the FTC’s history of enforcement indicates that it expects companies to anticipate widely known threats and to take reasonable steps to mitigate or avoid them. Just last year, then-FTC Chairwoman Edith Ramirez announced that “failure to patch vulnerabilities known to be exploited by ransomware might violate the FTC Act.” Companies are thus well-advised to consider “security-by-design” processes that cover the planning/design, implementation, testing and deployment phases of product development—particularly where IoT devices are involved. These processes can help to identify weaknesses, gaps and other vulnerabilities that should be addressed upfront before going to market.
- Set a game plan for responding to third-party security researchers. While internal security-by-design processes are important, there is a growing community of so-called “security researchers” that independently assess vulnerabilities and communicate them to companies—often to earn monetary compensation. Companies must be aware of the risks and rewards associated with ignoring or engaging with these researchers—who can be academic researchers, independent (benign or “white hat”) hackers, activists, or even “black hat” hackers who will resort to extortion if their demands for payment are not met. Many news stories, regulatory enforcement actions (including the ASUS matter), and even litigated cases have been sparked by third parties who publicly exposed security flaws inherent in newly developed technology. Accordingly, corporate incident response plans should account for security-researcher engagement, whether, how and when they will be compensated, who will be involved in the decision-making process, and even whether a formal “bug bounty” program makes sense.
- Coordinate with your sales and marketing teams. As in D-Link, FTC investigations and enforcement actions invariably include allegations regarding unsubstantiated public statements about security. Such statements have related to the type, strength, and even presence of, security measures deployed in relation to the company’s services. And the offending statements have appeared in a variety of contexts, including privacy policies, terms of service, marketing materials and even investor-related disclosures. Counsel and compliance teams are well-advised to review all consumer-facing statements to confirm that they accurately represent the company’s or product’s security and, if not, to modify them appropriately.
UPDATE: D-Link Challenges Unfair Claims
This fight is just getting started. On January 31, D-Link moved to dismiss, arguing that (a) the “unfairness” prong of the FTC Act does not give fair notice of what is considered reasonable security (i.e., the Wyndham argument); (b) the FTC’s “unfairness” authority does not extend to IoT; and (c) there is no evidence of actual or likely consumer injury, and “unfairness” liability cannot be based on “unspecified and hypothetical” risk of future harm. How receptive the court will be to these arguments is hard to say at this juncture. But regardless, the FTC has once again put companies on notice that it intends to use the unfair prong of Section 5 to uphold at least a baseline of reasonable data security, and companies in the design and testing phase for IoT, as well as other technologies, would be well-counseled to take note.
 See e.g., In the Matter of Snapchat, Docket No. C-4501, File No. 132 3078 (Fed. Trade Comm’n Dec. 31, 2014) (misleading description of the nature of “disappearing” messages); In the Matter of Credit Karma, Docket No. C-4480, File No. 132 3091 (Fed. Trade Comm’n Aug. 13, 2014) (failure to implement SSL technology, despite assuring users that company followed “industry leading security precautions” including the use of SSL); In the Matter of TRENDnet, Inc., Docket No. C-4426, File No. 122 3090 (Fed. Trade Comm’n Jan. 17, 2014)(failure to implement reasonable and readily available security technologies to secure sensitive data, despite marketing materials conveying the secure nature of the product, which included stickers on the product packaging in the shape of a padlock and repeated use of the trade name “SecurView”).