In re LightYear Dealer Technologies d/b/a DealerBuilt
The Federal Trade Commission (FTC) announced this week it took action against one of the B2B vendors that operate in the shadow economy largely unknown to the public. LightYear Dealer Technologies LLC (d/b/a DealerBuilt) (“DealerBuilt”), which provides software and data processing services to car dealerships nationwide, found itself in the FTC’s crosshairs over its data security practices. As part of its services, DealerBuilt collected information including names, social security numbers, driver’s license numbers, and other personal information. It also collected bank account information for its customers’ employees.
According to the FTC, in April 2015, DealerBuilt connected an unsecured backup device to its network. DealerBuilt allegedly failed to perform vulnerability scanning, penetration testing, or maintain a device inventory, which prevented it from discovering that the storage device maintained an open port to the Internet. In 2016, hackers used this port to access the personal information of millions of consumers and download sensitive personal information of almost 70,000 consumers. This breach was only discovered when a car dealership contacted DealerBuilt to determine why the dealership’s customers’ data was available on the Internet.
In the complaint, the FTC alleged that DealerBuilt violated both Section 5 of the FTC Act by engaging in unfair practices and the Gramm-Leach-Bliley Act’s Safeguards Rule by failing to have implemented a comprehensive information security program. DealerBuilt agreed to settle the matter through a proposed consent order that requires DealerBuilt to establish a comprehensive information security program with the following minimum components:
- written documentation of the program;
- submission of the documentation to its board of directors annually;
- designation of a responsible employee to maintain the program;
- annual risk assessments;
- implementation of adequate security controls;
- an annual assessment of the adequacy of those security controls;
- annual penetration testing;
- vulnerability testing every four months;
- vendor management with contractual requirements; and
- regular program maintenance.
Continuing a recent trend, the FTC also required DealerBuilt to adopt specific security controls, including the training of all DealerBuilt employees, network and system monitoring, data access controls, encryption of certain data, and device inventories. Although these controls address the specific issues that led to DealerBuilt’s security incident, companies should take note as they show the controls the FTC finds important.
The FTC has also recently increased its ability to monitor compliance with its consent orders. In addition to implementing a comprehensive information security program, DealerBuilt must:
- have an independent third party assess its security posture biennially;
- certify its compliance with the consent order to the FTC annually;
- report data security incidents within 10 days;
- create certain records for 20 years; and
- permit the FTC to request additional information or interview anyone affiliated with DealerBuilt in order to ensure compliance.
Many of these requirements look familiar, but the FTC has recently increased its ability to monitor compliance and impose accountability, which it continues in this proposed order. For instance, although biennial assessments have been a requirement for years, now the FTC is requiring DealerBuilt to agree that “[n]o documents may be withheld on the basis of a claim of confidentiality, proprietary or trade secrets, work product protection, attorney client privilege, statutory exemption, or similar claim.” Further, annual certifications to the FTC must be made by “a senior corporate manager” instead of a corporate representative.
So what does this mean? First, companies that operate in the shadow economy will not escape the FTC’s scrutiny. The FTC identifies economic sectors that deserve special attention and then, in order to get the sector’s attention, brings an enforcement action against an entity in that sector. As noted above, these companies offer ancillary services and often are invisible to the public. Consumer-facing companies rebrand and customize these services – including website chat windows, mobile banking apps, loyalty reward programs, and turnkey management services – so that consumers do not realize that they are sharing their personal information with a third party. And because some of the participants in this shadow economy collect information from all of the businesses that they service, they are a data buffet for hackers. For example, when 7.ai, a company that develops website chat functionality, was breached in 2017, hackers were able to obtain data from companies as diverse as Delta Airlines, Sears, and Best Buy.
Second, it’s not just companies in the shadow economy that should take note. The FTC has stressed vendor security for years, and an alleged data security incident within this shadow economy provided the FTC with an opportunity to both address this economic sector and highlight the need for vendor security. Vendor management is critical for all companies. Companies should inventory their vendors, assess risk for all of their vendors (even if the vendor lack access to sensitive data), and impose adequate security controls through contracts on those vendors that have access to PII. For high-risk vendors, companies should validate the vendor’s information security program. All of these tasks should be reflected in a documented information security program.
Third, companies developing comprehensive information security programs before an enforcement action have historically had some latitude in determining appropriate security controls. Now, the FTC is showing increased interest in dictating which security controls are appropriate through enforcement actions, at least for the target entity.
If the FTC does investigate, it is critical to have sufficient documentation to defend your security program. Many companies that end up settling with the FTC lack such documentation. For a discussion on how to build a defensible security program, see our ongoing blog series.