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

10/2/2015
05:15 PM
50%
50%

Scottrade Breach Hit 4.6 Million Customers, Began 2 Years Ago

Social Security numbers might have been exposed, but the main target appears to have been contact information.

Today, Scottrade Inc. announced a breach of 4.6 million customer contact information records (and possibly Social Security numbers), resulting from an attack that occurred between late 2013 and early 2014. 

Scottrade told customers in an email that it had "not seen any fraudulent activity as a result of this incident." However, the company also stated that it learned about the breach from the FBI, which was investigating a rash of breaches involving financial services firms. The company says it has no reason to believe its trading platforms or client funds were compromised, and that the focus appears to have been contact data, possibly to facilitate stock scams.

"A concerning lack of detective capabilities must not have been in place to have missed data exfiltration to the tune of 4.6 million records," says Stewart Draper, director of insider threat at Securonix. "The timeline specified was a particularly sensitive time in this sector with hacktivist and criminal groups regularly targeting financial companies. Federal authorities should not be the avenue with which companies are discovering they may have been breached.  In 2014 Scottrade was fined for failure to provide complete trade logs, blamed on an internal IT error from a migration. Accountability for these mistakes need to be taken at the highest levels of the organization to help drive awareness and improvement in security defense."

"The FBI is unlikely to explain in detail why notification of this breach took so long, but it's not uncommon for an ongoing investigation to delay notification so that criminals aren't tipped off," Tim Erlin, director of IT security and risk strategy at Tripwire.

A Scottrade representative told Wired that the FBI informed them of the breach in August but did ask them to withhold the information from customers until last Friday while they completed a part of the investigtion.

"Cyber criminals behave more like an infestation than the usual metaphor of a burglar," says Erlin. "Once they're inside, it takes more than a rolled-up newspaper to get rid of them."

"Scottrade customers are in the dark about exactly what was taken (the names and addresses were provided by Federal law enforcement), and don’t yet know where the data was taken from," says Trey Ford, global security strategist at Rapid7. "What we do know is that the data appears to have been taken 18-24 months ago. Few, if any, organizations store log data reaching that far back and it’s no wonder Scottrade cannot definitively state what data was taken for this reason."

See more at Scottrade's notice, at KrebsOnSecurity and Wired.

Dark Reading's Quick Hits delivers a brief synopsis and summary of the significance of breaking news events. For more information from the original source of the news item, please follow the link provided in this article. View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
prospecttoreza
0%
100%
prospecttoreza,
User Rank: Strategist
10/5/2015 | 9:54:38 AM
Scottrade breach
With all these breaches, it seems that there are more accounts stolen than people in US.

One could argue that by this time, there is almost nothing new to be stolen aside from info on kids just entering their credit lives.

So, what is the point of all these breaches? And do they even matter, if everyone is ultimately affected?
Blog Voyage
50%
50%
Blog Voyage,
User Rank: Strategist
10/3/2015 | 9:16:38 AM
Nice
What a drop ! Hoping the best for them
COVID-19: Latest Security News & Commentary
Dark Reading Staff 6/1/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
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-13757
PUBLISHED: 2020-06-01
Python-RSA 4.0 ignores leading '\0' bytes during decryption of ciphertext. This could conceivably have a security-relevant impact, e.g., by helping an attacker to infer that an application uses Python-RSA, or if the length of accepted ciphertext affects application behavior (such as by causing exces...
CVE-2020-13758
PUBLISHED: 2020-06-01
modules/security/classes/general.post_filter.php/post_filter.php in the Web Application Firewall in Bitrix24 through 20.0.950 allows XSS by placing %00 before the payload.
CVE-2020-9291
PUBLISHED: 2020-06-01
An Insecure Temporary File vulnerability in FortiClient for Windows 6.2.1 and below may allow a local user to gain elevated privileges via exhausting the pool of temporary file names combined with a symbolic link attack.
CVE-2019-15709
PUBLISHED: 2020-06-01
An improper input validation in FortiAP-S/W2 6.2.0 to 6.2.2, 6.0.5 and below, FortiAP-U 6.0.1 and below CLI admin console may allow unauthorized administrators to overwrite system files via specially crafted tcpdump commands in the CLI.
CVE-2020-13695
PUBLISHED: 2020-06-01
In QuickBox Community Edition through 2.5.5 and Pro Edition through 2.1.8, the local www-data user has sudo privileges to execute grep as root without a password, which allows an attacker to obtain sensitive information via a grep of a /root/*.db or /etc/shadow file.