The Secure Times

An online forum of the ABA Section of Antitrust Law's Privacy and Information Security Committee


Leave a comment

Windows XP End of Life Poses Risks to the Significant Percentage of Companies Still Tied to the Platform

On April 8, Microsoft officially ended all support and ceased providing updates for their Windows XP operating system. This “end of life” (EOL) announcement is not uncommon with software platforms, where continued support of aging software (XP is over 12 1/2 years old) becomes too expensive or too impractical, and the user is thus encouraged to upgrade to a newer version of that software. This all makes sense on the surface. As we’ve seen time and time again, software–especially large, complex pieces of software like operating systems–tends not to age well. Due to the sheer complexity of systems like XP, retrofitting patches to fix errors and vulnerabilities can be quite difficult, and may even lead to unintended consequences (i.e., more bugs). Thus, over time, software companies may urge their customers to migrate to the (relatively) clean slate provided by upgraded versions of their software.

The XP EOL announcement came as no surprise. Microsoft has been urging customers to start planning for upgrades since it terminated all retail sales of the operating system in 2008. But according to recent statistics provided by Net Applications, nearly 28% of Internet users are still running some version of Windows XP. Even worse, this number does not include those computers running XP that aren’t use for web browsing, e.g., servers, point-of-sale (POS) systems, medical systems, industrial systems, security systems, and ATMs. This number includes large organizations such as banks and governments which, due mainly to their size and conservative technology adoption policies, take more time to migrate away from software platforms, especially those that provide core services, such as operating systems. This has led to multi-million dollar agreements between these organizations and Microsoft in order to provide continued support for the short term.

But what about those companies and organizations who don’t necessarily have the wherewithal to negotiate individual support contracts with Microsoft? In addition, these smaller companies too often don’t have the depth of IT support required to keep up with these updates, and some organizations may not even be aware they’re still running XP within their network. For these companies, the fact that Microsoft will no longer be providing public patches for future vulnerabilities could prove to be a serious problem.

The first example of this problem showed up this week. On Monday, a new “zero-day” vulnerability in Microsoft’s Internet Explorer (IE) web browser was announced. This vulnerability is quite serious, as it could allow for remote code execution on a user’s computer, and had already been detected as an attack being used in the wild. Technology news sources were referring to this bug as the first sign of the “XPocalypse,” where users and organizations still running the unsupported platform would be left to the wolves, so to speak.

Yesterday, Microsoft took the unusual step of issuing a patch for this IE vulnerability for all of its platforms, including the “unsupported” Windows XP. While this step may have averted disaster for XP users–at least for the time being–many technology experts are warning that providing retroactive support for EOL platforms will not solve the larger problem of a significant number of users running aging, vulnerable software. This should concern not only the companies still running XP, but the entire Internet ecosystem, since compromised computer systems are often repurposed as platforms for further attacks.

It’s still too early to tell whether any of the dire predictions presented by the so-called XPocalypse will come to pass. Some cynics have pointed out that we are not likely to see a sudden surge of attacks on XP, since XP has been quite vulnerable to attack for some time, even when it was supported. Either way, companies would do well to make software security a priority, from the C-Suite on down. Companies are coming to realize that many (or most) of them are actually in the software business, as so much of their operation depends on the software that sits behind the scenes. There may come a time that the FTC views the unsupported use of XP as failing to take reasonable security measures. Adopting a wait-and-see approach to software security is bound to make a potentially bad situation even worse.

Advertisements


Leave a comment

2014 Verizon Data Breach Report Paints a Sobering Picture of the Information Security Landscape

The 2014 Verizon Data Breach Investigations Report (DBIR) was released on April 22, providing just the sort of deep empirical analysis of cybersecurity incidents we’ve come to expect from this annual report. The primary messages of this year’s DBIR are the targeting of web applications, continued weaknesses in payment systems, and nine categories of attack patterns that cover almost all recorded incidents. Further, despite the attention paid to last year’s enormous data breach at Target, this year’s data shows that attacks against point of sale (POS) systems are actually decreasing somewhat. Perhaps most importantly, the underlying thread that is found throughout this year’s DBIR is the need for increased education and application of digital hygiene.

Each year’s DBIR is compiled based on data from breaches and incidents investigated by Verizon, law enforcement organizations, and other private sector contributors. This year, Verizon condensed their analysis to nine attack patterns common to all observed breaches. Within each of these patterns, Verizon cites the software and vectors attackers are exploiting, as well as other important statistics such as time to discovery and remediation. The nine attack patterns listed in the DBIR are POS intrusions, web application attacks, insider misuse, physical theft/loss, miscellaneous errors, crimeware, card skimmers, denial-of-service (DoS) attacks, and cyber-espionage. Within industry verticals, most attacks can be characterized by only three of the nine categories.

Attacks on web applications attacks were by far the most common threat type observed last year, with 35% of all confirmed incidents linked to web application security problems. These numbers represents a significant increase over the three-year average of 21% of data breaches from web application attacks. The DBIR states that nearly two thirds of attackers targeting web applications are motivated by ideology, while financial incentives drive another third. Attacks for financial reasons are most likely to target organizations from the financial and retail industries. These attacks tend to focus on user interfaces like those at online banking or payment sites, either by exploiting some underlying weakness in the application itself or by using stolen user credentials. To mitigate the use of stolen credentials, the DBIR advised companies to consider implementing some form of two-factor authentication, a recommendation that is made to combat several attack types in this year’s report.

The 2014 DBIR contains a wide array of detailed advice for companies who wish to do a better job of mitigating these threats. The bulk of this advice can be condensed into the following categories:

  • Be vigilant: Organizations often only find out about security breaches when they get a call from the police or a customer. Log files and change management systems can give you early warning.
  • Make your people your first line of defense:  Teach staff about the importance of security, how to spot the signs of an attack, and what to do when they see something suspicious.
  • Keep data on a ‘need to know basis’: Limit access to the systems staff need to do their jobs. And make sure that you have processes in place to revoke access when people change role or leave.
  • Patch promptly: Attackers often gain access using the simplest attack methods, ones that you could guard against simply with a well-configured IT environment and up-to-date anti-virus.
  • Encrypt sensitive data: Then if data is lost or stolen, it’s much harder for a criminal to use.
  • Use two-factor authentication: This won’t reduce the risk of passwords being stolen, but it can limit the damage that can be done with lost or stolen credentials.
  • Don’t forget physical security. Not all data thefts happen online. Criminals will tamper with computers or payment terminals or steal boxes of printouts.

These recommendations are further broken down by industry in the DBIR, but they largely come down to a liberal application of “elbow grease” on the part of companies and organizations. Executing on cyber security plans requires diligence and a determination to keep abreast of continual changes to the threat landscape, and often requires a shift in culture within a company. But with the FTC taking a more aggressive interest in data breaches, not to mention the possibility of civil suits as a response to less-than-adequate data security measures, companies and organizations would do well to make cyber security a top priority from the C-Suite on down.


Leave a comment

FTC v. Wyndham Update, Part 3

In earlier updates, we’ve provided background and tracked the progress (and the unique circumstances) of FTC v. Wyndham Worldwide Corp., et al. On April 7, a highly anticipated opinion was issued by New Jersey District Court Judge Esther Salas in a case that will likely have broad implications in the realms of privacy and data security. Through a motion to dismiss, Wyndham argued that the FTC had no authority to assert a claim in the data security context, that the FTC must first formally promulgate data security regulations before bringing such a claim, and that the FTC’s pleadings of consumer harm were insufficient to support their claims. The Wyndham court sided with the FTC on all of these arguments, and dismissed Wyndham’s motion to dismiss.

Continue reading


1 Comment

FTC v. Wyndham Update, Part 2

Update (April 10, 2014): For a more recent update on this case, please see this post.

Since our last update, there has been some interesting activity in the matter concerning the Federal Trade Commission’s (FTC) complaint against Wyndham Worldwide, currently pending before the U.S. District Court for the District of New Jersey, and I thought this might be a good time for an update on these proceedings. This case has drawn considerable attention, mainly due to Wyndham’s challenge of the FTC’s authority to bring a data security enforcement action on unfairness grounds under Section 5 of the FTC Act. The outcome in this matter may very well have a profound effect on the FTC’s ability to regulate data security.

When we last discussed this matter, Wyndham’s motions to dismiss the FTC’s complaint, asserting, inter alia, that the FTC lacked the legal authority to enforce data security standards for private businesses, were before the court. On November 7, 2013, Judge Esther Salas heard oral argument on these motions. Wyndham opened by citing FDA v. Brown & Williamson Tobacco Corp., 529 U.S. 120 (2000), as support for their proposition that the FTC’s data security standards exceeded the agency’s authority. Judge Salas remained skeptical during the hearing, stating that she thought Brown & Williamson was distinguishable.

Wyndham further argued that the FTC’s informal data security guidelines are insufficient, and do not provide fair notice of what is required under Section 5. Wyndham questioned both the FTC’s authority as well as their expertise in this area. The FTC countered by asserting that its data security guidelines, which include best practices and past consent decrees, put businesses on notice of what is required to meet a standard of reasonableness.

Following oral argument, Judge Salas denied Wyndham’s motion to stay discovery proceedings, but did not immediately address Wyndham’s other pending motions to dismiss. On December 27, Judge Salas ordered the parties to submit a supplemental, joint letter brief to the Court, addressing the two outstanding motions to dismiss. The parties filed their joint letter brief on January 21.

In the brief, Wyndham once again argued that the FTC lacks the statutory authority to regulate data security practices for every American company. Wyndham pointed out that Congress has limited the FTC’s data security power to only certain, well-defined areas, citing the Fair Credit Reporting Act (FCRA), Gramm-Leach-Bliley Act (GLBA), and the Children’s Online Privacy Protection Act (COPPA) as evidence of these boundaries. Wyndham dismissed the FTC’s argument that FCRA, GLBA, and COPPA merely supplement the FTC’s existing data security authority as “revisionist history.”

In addition, Wyndham refuted the theory first raised by the FTC at oral argument, that Congress “understood Section 5 to provide the FTC with general police power over data-security matters,” but enacted FCRA, GLBA, and COPPA “for the limited purpose of freeing the Commission from the need to prove substantial consumer injury in specific contexts” as “a far-fetched reconstruction” of Congressional intent. Wyndham cited the context and legislative history of the FCRA, GLBA, and COPPA as further proof that the FTC is exceeding its authority, stating that Congress enacted these statutes “precisely because it believed that data security was not covered by existing statutory provisions, including Section 5 of the FTC Act.” (emphasis in original).

Finally, Wyndham reasserted that, even if the FTC is correct in its understanding of the statutes, they have not provided businesses fair notice required by the Due Process Clause. Wyndham points out that the “FTC has not published any rules, regulations, or guidelines explaining to businesses what data-security protections they must employ to comply with the FTC’s interpretation of Section 5 of the FTC Act.” This has been a growing concern among U.S. businesses, which face a daily struggle against data breaches and other related information security incidents, and are unsure of what “reasonable data security practices” might mean.

In its section of the brief, the FTC responded by asserting that “Section 5 of the FTC Act applies by its terms to all unfair commercial practices,” and “is not susceptible to a ‘data security’ exception.” The FTC highlighted the recent LabMD and Verizon decisions as supporting their argument for statutory authority.

The FTC also reiterated its position that the FCRA, GLBA, and COPPA permit the FTC to enforce these statutes using “additional enforcement tools,” which differentiate them from the FTC Act. Further, the FTC argues that where the FTC Act “merely authorizes,” the FCRA, GLBA, and COPPA “affirmatively compel the FTC to use its authority in particular ways” in certain contexts, which does not “divest the [FTC] of its preexisting and much broader authority to protect consumers against ‘unfair’ practices.”

Finally, the FTC pointed out that, while the court did not request additional briefing on the due process question, they felt obliged to respond to Wyndham’s claim on this point. The FTC asserted that to follow Wyndham’s argument would “undermine 100 years of FTC precedent,” and would “crash headlong” into Supreme Court precedent regarding Section 5 of the FTC Act.

Of note, the FTC has also been making similar arguments before Congress, where the FTC has expressed its support for new data security legislation. In hearings held before House Energy and Commerce Committee, the FTC emphasized its ongoing efforts to promote data security through civil law enforcement, education, and policy initiatives.

The court accepted parties’ brief and submissions of supplemental authority on January 23, and granted Wyndham’s request to submit a five-page letter brief in order to respond to the substantive issues raised by the FTC’s inclusion of the LabMD and Verizon decisions. Wyndham filed this brief on January 29, citing multiple negative responses to these decisions in the press as evidence of a breach of the “fundamental principles of fair notice” that “imposes substantial costs on business.”

Judge Salas has not yet responded to these arguments, but we will certainly be keeping a very close eye on these proceedings and its implications for the FTC regulation of data security standards.


Leave a comment

White House Begins Review of Big Data Privacy Issues

As part of President Obama’s review of government data collection in light of privacy and liberty interests, the White House has asked the President’s Council of Advisors on Science and Technology (PCAST) to conduct a detailed study of big data analytics and its potential effect on privacy. This review will be led by John Podesta, special advisor to the president, who will focus on the relationship between government and citizens, as well as input and innovation from public and private sectors.

In the first 90 days of the study, Mr. Podesta’s team will consult with industry, civil liberties groups, technologists, privacy experts, international partners, and other national and local government officials to better identify technological changes to keep an eye on, and whether these changes require further action or research.

The catalyst behind this and other related actions by the White House appear to stem from the disclosures last summer by Edward Snowden regarding the National Security Agency’s (NSA) broad surveillance projects. While the documents revealed by Mr. Snowden did not directly address the impact of big data analytics on privacy interests, they have spurred a growing awareness among citizens and businesses of privacy issues in general. This general awareness has led to calls for reform of NSA collection practices, as well as a national conversation about technology and privacy.

Mr. Podesta stated that

[w]e are undergoing a revolution in the way that information about our purchases, our conversations, our social networks, our movements, and even our physical identities are collected, stored, analyzed and used. The immense volume, diversity and potential value of data will have profound implications for privacy, the economy, and public policy. The working group will consider all those issues, and specifically how the present and future state of these technologies might motivate changes in our policies across a range of sectors.

Any recommendations that follow from the PCAST review will likely have traction within the White House, but it remains to be seen whether any new legislation is possible in near term. Either way, this exercise is sure to further the national conversation on privacy matters, and may provide an opportunity to frame future debate on this important topic.


1 Comment

The Adobe Data Breach and Recurring Questions of Software Liability

In recent weeks, news and analysis of the data breach announced by Adobe in early October has revealed the problem to be possibly much worse than early reports had estimated. When Adobe first detected the breach, its investigations revealed that “certain information relating to 2.9 million Adobe customers, including customer names, encrypted credit or debit card numbers, expiration dates, and other information relating to customer orders” had been stolen through a series of sophisticated attacks on Adobe’s networks. Adobe immediately began an internal review and notified customers of steps they could take to protect their data. Security researchers have since discovered, however, that more than 150 million user accounts may have been compromised in this breach. While I make no assertions regarding any potential claims related to this breach, I believe the facts of this incident can help convey the difficulties inherent in the ongoing debate over liability in cybersecurity incidents.

The question of whether software companies should be held liable for damages due to incidents involving security vulnerabilities or software bugs has been kicked around by scholars and commentators since the 1980s—centuries ago in Internet time—with no real resolution to show for it. Over the past month, Jane Chong has written a series of articles for the New Republic which revives the debate, and argues that software vendors who do not take adequate precautions to limit defects in their code should bear a greater share of the liability burden when these defects result in actual damages. This argument may seem reasonable on its face, but a particular aspect of the recent Adobe data breach illustrates some of the complexities found in the details that should be considered a crucial part of this debate. Namely, how do we define “adequate” or “reasonable” when it comes to writing secure software?

As Adobe correctly pointed out in their initial announcement, the password data stolen during the data breach was encrypted. For most non-programmers, this would appear to be a reasonable measure to protect sensitive customer data. The catch here lies in two core tenets of information security: First, cryptography and information security are not the same thing, and second, securing software of any complexity is not easy.

When Adobe encrypted their customer passwords, they used a well-known encryption algorithm called Triple DES (3DES) in what is called ECB mode. The potential problem is not in the encryption algorithm, however, but in its application. Information security researchers have strongly discouraged the use of cryptographic algorithms like 3DES—especially in the mode Adobe implemented—for encrypting stored passwords, since it uses a single encryption key. Once a hacker cracks the key, all of the passwords become readable. In addition, since 3DES in ECB mode will always give the same encrypted text when using the same plain text, this enables hackers to use guessing techniques to uncover certain passwords. These techniques are made easier by users who use easily guessed passwords like “123456” (used by two million Adobe customers). When you consider that many Adobe customers use the same password for multiple different logins, which may include banks, health care organizations, or other accounts where sensitive information may be accessed, one can see the value of this Adobe customer data to hackers.

From an Adobe customer’s perspective, it may seem reasonable that Adobe bear some of the liability for any damages that might result from this incident. After all, the customer might reason, Adobe’s network was breached, so Adobe did not do enough to protect customer data. On the other hand, Adobe could justifiably point out that it had taken reasonable precautions to protect their networks, including encrypting the sensitive data, and it was only due to a particularly sophisticated attack that the data was stolen. Further, Adobe could argue, if a customer used an easily guessed password for multiple logins, there is nothing Adobe can do to prevent this behavior—how could it be expected to be liable for digital carelessness on the part of its customers?

These questions will not be answered in a few paragraphs here, of course, but it is clear that any discussion of software liability is not necessarily analogous to product liability theories in other industries, like airlines or cars. Rather, software engineering has its own unique considerations, and we should be careful not to slip too easily into convenient metaphors when considering questions of software liability. Secure software development can be difficult; we should expect no less for questions of law related to this industry.


1 Comment

FTC v. Wyndham Update

Edit (Feb. 5, 2014): For a more recent update on this case, please see this post.

On November 1, Maureen Ohlhausen, a Commissioner at the Federal Trade Commission (FTC), held an “ask me (almost) anything” (AMAA) session on Reddit. There were no real surprises in the questions Commissioner Ohlhausen answered, and the AMAA format is not well-suited to lengthy responses. One interesting topic that did arise, however, was the FTC’s complaint against Wyndham Worldwide Corporation, and Wyndham’s subsequent filing of a motion to dismiss the FTC action against them. Commissioner Ohlhausen declined to discuss the ongoing litigation, but asserted generally that the FTC has the authority to bring such actions under Section 5 of the FTC Act, 15 U.S.C. § 45. While there were no unexpected revelations in the Commissioner’s response, I thought it presented an excellent opportunity to bring everyone up to speed on the Wyndham litigation.

On June 26, 2012, the Federal Trade Commission (FTC) filed a complaint in Arizona Federal District Court against Wyndham Worldwide Corporation, alleging that Wyndham “fail[ed] to maintain reasonable security” on their computer networks, which led to a data breach resulting in the theft of payment card data for hundreds of thousands of Wyndham customers, and more than $10.6 million in fraudulent charges on customers’ accounts.  Specifically, the complaint alleged that Wyndham engaged in deceptive business practices in violation of Section 5 of the FTC Act by misrepresenting the security measures it undertook to protect customers’ personal information. The complaint also alleged that Wyndham’s failure to provide reasonable data security is an unfair trade practice, also in violation of Section 5.

On August 27, 2012, Wyndham  responded by filing a motion to dismiss the FTC’s complaint, asserting, inter alia, that the FTC lacked the statutory authority to “establish data-security standards for the private sector and enforce those standards in federal court,” thus challenging the FTC’s authority to bring the unfairness count under the FTC Act. In their October 1, 2012 response, the FTC asked the court to reject Wyndham’s arguments, stating that the FTC’s complaint alleged a number of specific security failures on the part of Wyndham, which resulted in two violations of the FTC Act. The case was transferred to the Federal District of New Jersey on March 25, 2013, and Wyndham’s motions to dismiss were denied. On April 26, Wyndham once again filed motions to dismiss the FTC’s complaint, again asserting that the FTC lacked the legal authority to legislate data security standards for private businesses under Section 5 of the FTC Act.

At stake in this litigation is the FTC’s ability to bring enforcement claims against companies that suffer data breach due to a lack of “reasonable security.” What is unique in this case is Wyndham’s decision to fight the FTC action in court rather than make efforts to settle the case, as other companies have done when faced with similar allegations by the FTC. For example, in 2006, the FTC hit ChoicePoint Inc. with a $10 million penalty over data breach where over 180,000 payment card numbers were stolen. The FTC has also gone after such high-profile companies as Twitter, HTC, and Google based on similar facts and law. These actions resulted in out-of-court settlements.

If Wyndham’s pending motions to dismiss are denied, and the FTC ultimately prevails in this case, it is likely that the FTC will continue to bring these actions, and businesses will likely see an increased level of scrutiny applied to their network security. If, however, Wyndham succeeds and the FTC case against them is dismissed, public policy questions regarding data security will likely fall back to Congress to resolve.

Oral argument for the pending motions to dismiss are scheduled for November 7. No doubt many parties will be following these proceedings with great interest.