by Staff at the Federal Trade Commission’s Office of Technology

Federal Trade Commission

For more than two decades, the FTC has been bringing enforcement actions for violations of national consumer protection laws due to companies’ poor security practices. These poor practices have included failure to encrypt sensitive data, storing credentials in source code, failing to test for common vulnerabilities, and failure to use multi-factor authentication, among others. To remedy these practices, the orders the FTC has obtained in these enforcement actions have required companies to improve their security practices. Last year FTC staff published a blog post on how the agency’s orders incorporate modern security best practices that take inspiration from research into the causes of risk in complex systems. This post is a continuation on the theme of effectively addressing risks in complex systems.

As we described then, the best way to address the risk of security vulnerabilities in products is systematically, not in ad-hoc or one-off ways. In the same way that “human error” is not an appropriate diagnosis for the cause of a successful credential phishing attack – given the availability of phishing-resistant multifactor authentication methods – it’s also not an appropriate diagnosis for many of the other types of vulnerabilities and system security issues that occur. This is consistent with the Cybersecurity and Infrastructure Security Agency’s (CISA) Secure by Design Alert Series: “The Series urges technology manufacturers to build security into products from the beginning to eliminate classes of vulnerability, or product defects, that impact the safety of their customers.” Among their tactics for how to build Secure by Design software, CISA wrote that, “Manufacturers should perform root-cause analysis of discovered vulnerabilities and, to the greatest extent feasible, take actions to eliminate entire vulnerability classes.” The FTC’s Start with Security guide similarly observes that, “some vulnerabilities are commonly known and reasonably foreseeable. In more than a dozen FTC cases, businesses failed to adequately assess their applications for well-known vulnerabilities.”

For many of the most prevalent types of vulnerabilities, there are known approaches to addressing them systemically and preemptively, either entirely preventing them or dramatically reducing the likelihood of them occurring. Approaches like these can play an important element of building software in a way that minimizes the risks of vulnerabilities.

• Cross Site Scripting (XSS) is one of the most common vulnerability types, and it occurs when content controlled by an attacker is directly incorporated into an HTML page. XSS vulnerabilities can be effectively addressed by using template rendering systems that default to escaping output, rather than requiring developers to correctly mark every variable that’s rendered as unsafe.
• SQL injection is another common vulnerability that occurs when attacker-controlled content is directly incorporated into a database SQL query. SQL injection vulnerabilities can be effectively addressed with query builders and other APIs that clearly delineate between attacker-controlled data and the structure of a query, rather than requiring developers to studiously ensure they never use their programming language’s native string formatting functionality for constructing SQL queries. Code scanning tools can enforce that code that doesn’t follow these practices doesn’t make it into production or to customers.
• Buffer overflows and use-after-free vulnerabilities are both issues in how software manages memory, and occur when memory is accessed at invalid locations or after a program has already said it was finished with it. Buffer overflows and use-after-free vulnerabilities can be effectively addressed through the use of memory-safe programming languages, rather than using memory-unsafe programming languages and requiring developers to diligently ensure they never access an array without performing a bounds check or use memory after it’s been freed. Many memory-safe programming languages allow incremental migration from unsafe languages, which facilitates easier adoption.

As the FTC has said before, companies can and should always be taking reasonable steps to make their systems and devices secure. In addition to these approaches, CISA’s Secure by Design Alert Series highlights many additional ways that companies can protect their systems, and users of their systems, from design issues that CISA has observed lead to security incidents in practice. Taken together, these provide numerous opportunities for companies to fundamentally improve the security of their products and protect consumers’ personal information.

For more than two decades the FTC’s enforcement actions have made clear that companies have a legal obligation to effectively protect consumers’ data. For example, unfair or deceptive data security practices violate the FTC Act. Additionally, financial institutions, companies that use consumer reports, and companies collecting children’s data must comply with applicable laws relating to securing consumer information or disposing of information securely. Approaches such as the ones described here can form a critical element of a security program that effectively protects consumers’ data.

This post first appeared on the FTC’s Technology Blog. The Staff at the Federal Trade Commission’s Office of Technology would like to thank Alex Gaynor, Simon Fondrie-Teitler, Mike Tigas, and Mark Eichorn for contributing to the post.

The views, opinions and positions expressed within all posts are those of the author(s) alone and do not represent those of the Program on Corporate Compliance and Enforcement (PCCE) or of the New York University School of Law. PCCE makes no representations as to the accuracy, completeness and validity or any statements made on this site and will not be liable any errors, omissions or representations. The copyright of this content belongs to the author(s) and any liability with regards to infringement of intellectual property rights remains with the author(s).