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

9/14/2007
05:33 PM
Keith Ferrell
Keith Ferrell
Commentary
50%
50%

Don't Do As TD Ameritrade Does -- And Don't Do As They Say, Either

The security breach that let spammers get hold of as many as 6.3 million TD Ameritrade customer names, phone numbers and e-mail addresses is being spun as a "Well, they didn't get Social Security numbers, account numbers, PINs or other confidential info; still we apologize for any inconvenience or annoyance," sort of problem. Mistake. Big mistake.

The security breach that let spammers get hold of as many as 6.3 million TD Ameritrade customer names, phone numbers and e-mail addresses is being spun as a "Well, they didn't get Social Security numbers, account numbers, PINs or other confidential info; still we apologize for any inconvenience or annoyance," sort of problem. Mistake. Big mistake.Company response to the TD Ameritrade hack -- which bears a certain resemblance to the recent Monster.com fiasco -- is starting to look like a textbook case of what not to say when company data of any sort gets compromised.

Take a look, for example, at this statement from Joe Moglia, TD Ameritrade's CEO:

"While the financial assets our clients hold with us were never touched, and there is no evidence that our clients' Social Security numbers were taken, we understand that this issue has increased unwanted SPAM, which is annoying and inconvenient for them. We sincerely apologize for that and any added concern this may have caused."

Who wrote that statement? Is no one looking out for Mr. Moglia's crisis-management demeanor and the message he's sending to customers and the press? Evidently not. To wit:

"... while there is no evidence that our clients' Social Security numbers were taken..."

Which sends the message, not deliberately, I'm sure, that there's also no evidence yet that SS numbers were not taken. That's surely not what Mr. Moglia intended to say, and it's just as surely not the message he -- or his Mar/Com handlers -- intended to send, but there it is.

Onward:

"We understand that this issue has increased unwanted SPAM, which is annoying and inconvenient for them."

It's more than that -- as the compromised names and numbers get shared and spread, and re-shared and more widely spread, every bit of junkmail will remind the recipient that their address got grabbed from a compromised TD Ameritrade database. That's more than an annoyance, and lot more than an inconvenience, and Mr. Moglia should have acknowledged that.

This from Mr. Moglia's statement, strikes me as putting bad icing on a bad cake:

"This issue is not unique to TD AMERITRADE. It's something that all companies involved in e-commerce should be aware of and prepared to address. We participate in industry peer groups to share information on these types of threats in the interest of protecting all clients."

Which tells clients only that a) we're not the only ones not doing a good enough job of keeping our databases safe, and b) the information being shared among the peers isn't good enough, deep enough, effective enough.

Note: I'm not saying that Mr. Moglia is wrong in what he's saying, only that the way he's saying it is wide open to misinterpretation by already "annoyed and inconvenienced" (and then some!) customers.

His video statement also includes this next comment, which has the advantage of being both accurate and true, but again doesn't seem to me to go far enough for a CEO whose company has been compromised:

"This is an issue for global e-commerce that will be with us for the rest of our lives."

As stated, it's hard to argue with -- but from a business perspective it would have been far more effective for Mr. Moglia to make a commitment right there, pledging a certain percentage of company revenue or profits or whatever to taking the lead in coordinating and invigorating the levels of information shared among participating "industry peer groups."

Couple of final points.

As I write this late in the afternoon, EST, TD Ameritrade's welcome page includes a soft yellow notice bar "regarding the recently reported SPAM investigations" and is otherwise business as usual, including the an unfortunate (in present circumstances) We Promise Protection section.

Worse, when you follow the link to the SPAM investigations page, you get a page that is anything but assertive in putting information about the compromised data upfront and accessible. Scroll past the "Helping independent minded investors be successful" sel--copy and you'll eventually find a Special Client Announcement section beneath which the compromise is covered through press releases, video statements and so on.

Look: Joe Moglia is absolutely right about the nature of this problem -- it will be with us forever. And I'm just as sure that his comments and his company's damage-control materials were put together carefully and thoughtfully.

Too carefully and too thoughtfully, I think. In the event of a breach, your customers and clients are going to be mad as hell, and they had better know that, on their behalf and on behalf of your company, you are, too.

If your company network and customer/client information gets hacked or compromised, you have got to be more aggressive -- much more aggressive, I think -- in confronting an issue which will, fairly or unfairly, be perceived as a failure of your business's security procedures and technology.

Your communications with your clients and customers, and with the wider public and press through your statements and Web site had better send the message that you are as "annoyed" by the situation as they are -- otherwise you're going to have a bunch of "annoyed and inconvenienced" customers getting angrier by the moment at your spin, and spinning themselves and their business away from your company to somebody else's.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Commentary
What the FedEx Logo Taught Me About Cybersecurity
Matt Shea, Head of Federal @ MixMode,  6/4/2021
Edge-DRsplash-10-edge-articles
A View From Inside a Deception
Sara Peters, Senior Editor at Dark Reading,  6/2/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
The State of Cybersecurity Incident Response
In this report learn how enterprises are building their incident response teams and processes, how they research potential compromises, how they respond to new breaches, and what tools and processes they use to remediate problems and improve their cyber defenses for the future.
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-34682
PUBLISHED: 2021-06-12
Receita Federal IRPF 2021 1.7 allows a man-in-the-middle attack against the update feature.
CVE-2021-31811
PUBLISHED: 2021-06-12
In Apache PDFBox, a carefully crafted PDF file can trigger an OutOfMemory-Exception while loading the file. This issue affects Apache PDFBox version 2.0.23 and prior 2.0.x versions.
CVE-2021-31812
PUBLISHED: 2021-06-12
In Apache PDFBox, a carefully crafted PDF file can trigger an infinite loop while loading the file. This issue affects Apache PDFBox version 2.0.23 and prior 2.0.x versions.
CVE-2021-32552
PUBLISHED: 2021-06-12
It was discovered that read_file() in apport/hookutils.py would follow symbolic links or open FIFOs. When this function is used by the openjdk-16 package apport hooks, it could expose private data to other local users.
CVE-2021-32553
PUBLISHED: 2021-06-12
It was discovered that read_file() in apport/hookutils.py would follow symbolic links or open FIFOs. When this function is used by the openjdk-17 package apport hooks, it could expose private data to other local users.