By 
In a recent notification from the Maine Attorney General, Fidelity Investments disclosed another data breach affecting over 77,000 individuals. This marks the second significant incident for the company in 2024 for one of the world’s largest financial services providers.
The breach, occurring between August 17-19, 2024, exposed sensitive information including names, Social Security numbers, financial account data, and drivers license details. Fidelity has stated that customer financial data remained secure and no Fidelity customer accounts were directly compromised. This incident follows an earlier breach in 2024 that impacted Fidelity Investments Life Insurance Company, which was attributed to a third-party provider, Infosys McCamish System.
However, going back to the incident, the personal information leak is still a major concern for those affected. There isn’t even up to debate that this fact, while the company did stated something that is true: the accounts were not compromised, financial data on the platform is intact, therefore “there is nothing to see here folks, move along”.
However in a positive turn of events, Fidelity notified affected consumers in October and offered 24 months of identity theft protection through Transunion.
Analysis
The details of this breach are particularly concerning. Two unauthorized accounts gained access to information about 77,000 customers, suggesting either a potential vulnerability in Fidelity’s access control systems, or access from within the firm. A large number of breaches are really social engineering, so we cannot exclude this option completely.
This incident raises several red flags, that makes us wonder about the security measures for this firm:
- Scale of Impact. The breach, involving only two fraudulent accounts, accessed data from over 77,000 customers. If the software has a ‘masters’ account, accessing this large number of accounts should be closely monitored and protected under multi factor authentication. If there is a breach from within, it’s another critical problem.
- Delayed Detection. It took two days for Fidelity to detect the breach, and this fact is troublesome in regards to real-time monitoring of systems.
- Recurring Incidents. Even if previous issues were due to third-party provider, it still affected a small part of the existing users.
How to avoid these types of breaches
Proper or actual threat monitoring
We wouldn’t like to even assume that the company did not had monitoring in place, so our assumption is the detection went unnoticed.
This can be attributed due to information overload, in leanest term, the monitoring tool shows too much, or in extreme cases too little. But our assumption is on the overload part.
However in any case this points to a a weak security infrastructure the software possessing security gaps that cybercriminals can exploit.
Ensure Compliance
It’s no secret that the EU is criticized for its strict compliance and data protection laws. While we can blame the EU for many things, we can appreciate the Euro-zone for these regulations. We admit it’s not an easy task to review, assess, and learn the required compliance. In our day-to-day jobs, when we assess companies for security gaps or possible vulnerabilities, we also offer compliance assessments.
Ensure your software doesn’t have security gaps
A possible flaw in Fidelity’s access control mechanisms can be inferred from this breach. This, or improper segregation of data within their internal systems, allowed these accounts to view large sets of personal information, including Social Security numbers and driver’s licenses.
In a utopia of software development, these large amounts of viewing and altering should raise alerts, and the actions need to be under multi-factor triggers.
There is also a possibility the software is not respecting the principle of least privilege (PoLP). This principle explicitly states that a user or entity should only have access to the specific data, resources, and applications needed to complete a required task. For cases of large volume access, GDPR compliance should have been in place. We cannot really think of reasons to be able to batch download Social Security numbers.
There is no need to invoke here the zero trust architecture; it’s clearly not in the company’s focus.
Ensuring your software doesn’t have any critical vulnerability is something that an external party should be able to assess, while internal teams are a huge bonus. Someone from the outside can do proper penetration testing and vulnerability assessment. Nowadays, ethical hacking groups can even mimic threat actors and try various techniques that may give a broader picture of your company’s vulnerability. We’re talking here even about social engineering.