It has been reported that the San Francisco Employees’ Retirement System (SFERS) said it suffered a data breach after an unauthorised person gained access to a database hosted in a test environment. In a data breach notification filed yesterday, SFERS stated that one of their vendors had set up a test environment that included a database containing the information for approximately 74,000 SFERS members. While SFERS states that no Social Security Numbers or bank account information was contained in the breach, there was enough personal information exposed that could be used by threat actors in attacks. The leaked information for all members includes a member’s name, address, date of birth, and beneficiary information.
This incident highlights the vital importance of data ownership and supply chain security.
An organisation can have the best information security to ensure that centrally held data is managed and stored safely but the moment that data is shared it becomes vulnerable.
Since the sharing of data is fundamental to business practice in the digital economy it should be incumbent upon every business to ensure that customers, suppliers, contractors and service providers can demonstrate that they have sufficient security measures in place before data is shared and business is done.
Take a look at the Target data breach in 2013 and learn from it.
It’s simply not enough to secure your own data any more. You need to encourage and ensure that everyone on your business network is doing it too.
Test environments are usually not secured or monitored to the same level as production environments, and it is never advisable to use real data in test cases. Rather, dummy data, or heavily redacted data should be used so that even if it is leaked or breached, it does not impact any real customers.
Anyone impacted by this breach should keep a close eye on their credit rating, and be wary of unsolicited emails which may appear to originate from official bodies relating to this breach.
A breach like this is interesting, both because it leads to almost guaranteed identity theft (if the information actually was accessed and downloaded), since it’s a treasure trove of financial information, identifying information, and security questions. Security questions, in particular, typically uses information that people *feel* is non-public, even if it usually is; wife’s name, where you met, etc., are often accessible with a quick social media search. But for an attacker to have those at their fingertips, along with all of the other information, is incredibly dangerous from an identity theft perspective. Additionally, because beneficiary information was accessed, it is also likely to lead to targeted spear phishing attacks, where an attacker spoofs an email as if it were coming from one of those beneficiaries. The retired employees of San Francisco need to be extremely careful and verify, personally, through existing contact info they already had, that their beneficiaries actually sent an email, should the retirees receive one.
The breach itself is also interesting from a technical perspective, as this was a bit of careless planning; one of the main considerations when building a testing or stage environment is to ensure it does not have access to any production systems or data. We do this because it prevents exactly this sort of breach. Staging and test environments, almost by definition, are much more prone to bugs and vulnerabilities than a production environment. In testing is where those issues are found, and where they are fixed, before it gets pushed out to something the world can see. Those testing environments *should* be separated from the production environments, and ideally inaccessible outside the corporate network, but it’s also important to ensure that a test environment uses mock data rather than production data. There are generators for most frameworks that will produce fake (or “mock”) data in order to fill up your database with real-looking information that is actually just computer-generated, and those are important to use; this breach is a perfect lesson as to why.
The SF Employee’s Retirement System breach is a good reminder that even applications on test systems need to be secured against threats, whether they are internal (bad actors in the organization and its partners) or external (coming from hackers trying to exploit vulnerabilities). Vulnerabilities, misconfigured servers, and misused credentials are among the top reasons systems get breached.