The San Francisco Employees’ Retirement System (SFERS) this week disclosed a data breach that impacted over 70,000 of its members.
The incident, SFERS reveals, involved 10up Inc., one of the vendors the retirement program works with to provide SFERS members with online access to their account information.
On March 21, the vendor discovered that an unknown party accessed a server that contained, among others, a database with information on approximately 74,000 SFERS member accounts, as of August 29, 2018.
10up Inc. shut the server down immediately and launched an investigation. According to the vendor, while it has no evidence that any data pertaining to SFERS members was removed from the server, it cannot confirm that the perpetrators did not access or copy the data.
Although no social security numbers (SSN) and bank account numbers were stored on the server, a large amount of other data was exposed, with both active and retired SFERS members impacted, the retirement system announced.
The breached database contained the following data of active SFERS members: full name and home address, date of birth, and the full name, date of birth, and relationship to the designated beneficiary. If the member was registered on the SFERS website, their username and security questions and answers were also breached.
For retired members, exposed data includes full name and home address, date of birth, the full name, date of birth, and relationship to the designated beneficiary, IRS Form 1099R information, and bank ABA (routing) number for those with direct deposit. The username and security questions and answers of those with accounts on the SFERS website were also exposed.
“Within hours of discovering the potential data breach, 10up locked the server. SFERS has implemented a password reset requirement for all members logging in to the SFERS website,” the retirement system also notes.
“There is no evidence that SFERS data was accessed or downloaded,” a 10up spokesperson said, responding to a SecurityWeek inquiry. “10up takes security extremely seriously, so we felt obligated to report unauthorized access to a server that made it technologically *possible* for some older SFERS data to be accessed by that unauthorized party. We know with high certainty that SFERS were not the target of the party accessing the server, and downloading existing data from the server does not seem to have been the purpose or part of the access.”
*updated with statement from 10up