Retail brokerage firm Scottrade has exposed the information of some 20,000 users, marking the second data compromise for the company in 18 months.
The compromise came when an MSSQL database containing sensitive information was inadvertently left exposed to the public. The file contained commercial loan application information of a small B2B unit within Scottrade Bank, including non-public information of individuals and businesses.
The database was discovered by MacKeeper researcher Chris Vickery on March 31, in the course of searching for random phrases on the domain s3.amazonaws.com.
“It's as bad as I expected,” he tweeted. “Bank-related. Plaintext passwords. Big name company. I've reached out to them.” The next day he tweeted, “Bank-related find is verified as secured now. Agreed not to name entity for 3 days. Allowing log investigation and PR prep time."
The culprit, the firm said, was not Scottrade’s own systems but an "isolated human error" by third-party vendor Genpact. Third-party vectors are endemic—and famously highlighted in the Target breach, where hackers broke in via heating and air conditioning subcontractor Fazio.
In this case, Genpact had uploaded a data set to one of its cloud servers that did not have all security protocols in place.
"The data breach at Scottrade exemplifies the one-strike law for security in the cloud,” said Zohar Alon, Dome9 CEO, via email. “In the public cloud, a single vulnerability, security or process lapse is all it takes to expose highly sensitive private data to the world and get data-jacked. Even with strict security controls in place, breaches such as this still occur due to very basic process failures."
Upon being alerted to the issue, Scottrade said that Genpact immediately secured that information, and traced the issue to a configuration error on their part while uploading the file.
“Genpact works exclusively with the B2B bank unit and has no access to any other information at our firm,” Scottrade said in a notice. “This appears to be a case of isolated human error by the vendor in handling the data set. It is important to note that we hold all of our third-party vendors to rigorous information security standards. The vendor has acknowledged responsibility for this incident. This is a discrete issue with no link to any other aspect of our business. Our own systems remain secure and were not involved in this matter.”
Nonetheless, some researchers said the third-party aspect doesn’t let the firm off the hook.
“[The] numerous third party vendors that organizations partner with undeniably expand the threat surface, exposing companies to increased and unknown risk,” said Joe Fantuzzi, CEO of RiskVision. “In short, your security and risk posture is only as good as your partners’. Your infrastructure may be secure and compliant, but if your partners fail to comply to your standards, your risk posture is in jeopardy. Organizations need to perceive their third-party vendors as extensions of their own environment. Consequently, it’s imperative that they automate the necessary steps to assess third parties and conduct deep due diligence to ensure that their most critical assets are prioritized and appropriately protected.”
Tim Erlin, vice president of product management and strategy for Portland, Ore.-based Tripwire noted the company’s data responsibility: “Inadvertently exposed databases with sensitive information are not a new problem,” he said, via email. “In any large enterprise, change is a constant and ensuring that systems are configured securely is a significant challenge. Organizations must monitor their environments for insecure configurations and for changes in configurations that might expose data or create risk. Any organization that collects and stores sensitive data needs to be able to keep track of where that data is and how that data is exposed. It’s vitally important to encrypt sensitive data at rest, but encryption alone isn’t sufficient. Even encrypted data is designed to be accessed by applications and authorized personnel. Organizations have to protect the access methods, in addition to encryption, in order to protect data.”
Scottrade is not new to data issues. In Oct. 2015, the Missouri-based financial services firm revealed a breach of nearly five million customers, with the leak of client names and contact information, and Social Security numbers, email addresses and other sensitive data not ruled out as being compromised.
“It seems they have not learned from that experience and still keep plain-text passwords in one of their databases,” said Nick Bilogorskiy, senior director of threat operations at Cyphort, said via email. “This does not bode well for the $4 billion acquisition of Scottrade by TD AmeriTrade, that has not closed yet and was expected to be complete by September 30, 2017.”
Bilogorskiy also said that the organization’s security concerns don’t stop with databases. “I am a Scottrade customer and have been one since 2010,” he said. “It is unfortunate that while other banks and brokerages added two-factor authentication as an option, Scottrade still relies on passwords alone for authentication and on ‘security questions’ for password recovery.”