Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Risk

6/25/2010
06:40 PM
George V. Hulme
George V. Hulme
Commentary
50%
50%

FTC Security Smackdown And Twitter's Hollow Excuses

The social networking site Twitter has settled with the U.S. Federal Trade Commission regarding charges that it failed to properly safeguard the data of its users.

The social networking site Twitter has settled with the U.S. Federal Trade Commission regarding charges that it failed to properly safeguard the data of its users.The FTC argued that "serious lapses in the company's data security allowed hackers to obtain unauthorized administrative control of Twitter, including access to non-public user information, tweets that consumers had designated private, and the ability to send out phony tweets from any account including those belonging to then-President-elect Barack Obama and Fox News, among others."

I'm not surprised. Rare is the company that provides more than lip service to information security and privacy until it is absolutely forced by circumstances, its customers, the government, or industry regulators.

The press statement went on:

"When a company promises consumers that their personal information is secure, it must live up to that promise," said David Vladeck, Director of the FTC's Bureau of Consumer Protection. "Likewise, a company that allows consumers to designate their information as private must use reasonable security to uphold such designations. Consumers who use social networking sites may choose to share some information with others, but they still have a right to expect that their personal information will be kept private and secure."

The FTC said that in early 2009 hackers gained administrative control of Twitter on two separate incidents. The first incident, in January 2009, an attacker gained access by using a brute-force password attack tool, and after "submitting thousands" of guesses onto Twitter's logon page, they gained access. The FTC contends that the password was a weak, lowercase dictionary word. After they gained access the fun began:

Using the password, the hacker reset several passwords, and posted some of them on a website, where other people could access them. Using these fraudulently reset passwords, other intruders sent phony tweets from approximately nine user accounts. One tweet was sent from the account of then-President-elect Barack Obama, offering his more than 150,000 followers a chance to win $500 in free gasoline. At least one phony tweet was sent from the account of Fox News.

In the second, and separate, incident, an attacker guessed the administrative password of an employee at Twitter, after compromising the employee's personal e-mail account where similar passwords were stored in the clear. The attacker used that information to gain access to private tweets and nonpublic information.

In his news story, Twitter, Feds Settle Security Charges, Antone Gonsalves provides more detail.

If you are familiar with even the most rudimentary of security precautions, you'd conclude that Twitter didn't bother to take the steps a Web design intern would know to take. The FTC concluded essentially the same. According to the FTC's complaint, Twitter was vulnerable to these attacks because it failed to prevent unauthorized administrative control of its system, including reasonable steps to:

• require employees to use hard-to-guess administrative passwords that they did not use for other programs, websites, or networks; • prohibit employees from storing administrative passwords in plain text within their personal e-mail accounts; • suspend or disable administrative passwords after a reasonable number of unsuccessful login attempts; • provide an administrative login webpage that is made known only to authorized persons and is separate from the login page for users; • enforce periodic changes of administrative passwords, for example, by setting them to expire every 90 days; • restrict access to administrative controls to employees whose jobs required it; and • impose other reasonable restrictions on administrative access, such as by restricting access to specified IP addresses.

What's the outcome for all of this hullaballoo? Essentially Twitter will be under watch by the FTC for the next twenty years. And the FTC will (hopefully) ensure that Twitter doesn't make any claims regarding security and privacy that it can't back up. Also, the company will have to take the security precautions necessary to avoid such mishaps in the future. It must also put into place a comprehensive security program, and endure assessments by an independent security auditor every other year for a decade.

Too bad Twitter didn't put a security policy in place when they launched. And it's a shame they took the same tact as most companies do in their reaction: they made excuses and they minimized what happened. Here's a part of their short blog post on the incidents:

Early in 2009, when Twitter employed less than 50 people, we faced two different security incidents that impacted a small number of users. Put simply, we were the victim of an attack and user accounts were improperly accessed. There were 45 accounts accessed in a January incident and 10 that April for short periods of time. In the first incident, unauthorized joke tweets were made from nine accounts and attackers may have accessed nonpublic information such as email addresses and mobile phone numbers. In the second, nonpublic information was accessible and at least one user's password was reset.

Within hours of the January breach, we closed the security hole and notified affected account holders. We posted a blog post about it on the same day. In the April incident, within less than 18 minutes of the hack we removed administrative access to the hacker and we quickly notified affected users. We also posted this blog item about the incident within a few days of first learning about it.

Having less than 50 employees at the time of the breach is a completely irrelevant and a hollow excuse. The standard is how many customers, or users they had at the time, and the promises they made to those users about the level of security and privacy they are provided. And the fact that only small number of their users were affected is also bogus. Their subpar security precautions placed all of their users at risk, and that fact shouldn't be so readily minimized.

Really, if I had $1 for every breached record from every company that claimed only a small percentage of their customers were affected by a breach, I'd have about $1 billion dollars by now.

Too often, such as in this case, government or industry regulators need to step in and force security on companies because companies have a lax attitude toward security. We've seen this with businesses and privacy with the Gramm-Leach-Bliley Act. We saw it again with health care providers and the Health Insurance Portability and Accountability Act. Again with Sarbanes-Oxley and public companies with their financial records, and once again with retailers and the Payment Card Industry Data Security Standard.

So unless you've been living (literally) in a cave for the past 20 years you'd now that there are cyber-criminals and illicit hackers that aim to grab access to accounts, snoop and steal data, and do whatever they want if you design systems with shoddy and lazy security technology and processes.

Twitter also downplayed the significance of the actions by the attackers. Remember, viruses and network hacking started out with hobbyists and curiosity seekers. These incidents could had of been much more serious. These attackers could have easily infiltrated a corporate executive's or CEO's account for some devious gain: such as tweeting damaging news about a company to temporarily game a stock price. Maybe a politician's account to start and fuel a rumor during an election day, or as part of a serious smear campaign. You get the idea. Twitter making a point to highlight the fact that these were "joke" tweets is another attempt at minimization.

It's not 1995 anymore. Companies, whether they have 50 employees or 50,000, need to consider these things. And when they don't we all pay the price.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 5/28/2020
Stay-at-Home Orders Coincide With Massive DNS Surge
Robert Lemos, Contributing Writer,  5/27/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-11844
PUBLISHED: 2020-05-29
There is an Incorrect Authorization vulnerability in Micro Focus Service Management Automation (SMA) product affecting version 2018.05 to 2020.02. The vulnerability could be exploited to provide unauthorized access to the Container Deployment Foundation.
CVE-2020-6937
PUBLISHED: 2020-05-29
A Denial of Service vulnerability in MuleSoft Mule CE/EE 3.8.x, 3.9.x, and 4.x released before April 7, 2020, could allow remote attackers to submit data which can lead to resource exhaustion.
CVE-2020-7648
PUBLISHED: 2020-05-29
All versions of snyk-broker before 4.72.2 are vulnerable to Arbitrary File Read. It allows arbitrary file reads for users who have access to Snyk's internal network by appending the URL with a fragment identifier and a whitelisted path e.g. `#package.json`
CVE-2020-7650
PUBLISHED: 2020-05-29
All versions of snyk-broker after 4.72.0 including and before 4.73.1 are vulnerable to Arbitrary File Read. It allows arbitrary file reads to users with access to Snyk's internal network of any files ending in the following extensions: yaml, yml or json.
CVE-2020-7654
PUBLISHED: 2020-05-29
All versions of snyk-broker before 4.73.1 are vulnerable to Information Exposure. It logs private keys if logging level is set to DEBUG.