Nissan North America is informing customers of a data breach that occurred at a third-party service provider. The security incident was reported to the Office of the Maine Attorney General on January 16, 2023, and it was disclosed that almost 18,000 customers were affected by the breach. According to the notification, Nissan received notice of the data breach from one of its software development vendors on June 2022. The vendor had received customer data from Nissan to use in developing and testing software solutions, which was inadvertently exposed due to a poorly configured cloud-based public repository.
Nissan took immediate action to secure the exposed repository and launched an internal investigation. It was determined that an unauthorized person had likely accessed the data. The exposed data includes full names, dates of birth, and Nissan account numbers, but does not include credit card details or Social Security numbers. Nissan says that to this date, there has been no evidence that any of this information has been misused.
There are two key lessons to learn from the incident. The first is the recurring lesson about the importance of securing repository access (such as GitHub, GitLab, Bitbucket, and more). Just last week we published a blog post covering the breach of Slack’s GitHub repositories. In the case of the 3rd party vendor Nissan used, the issue is even simpler than the previous ones –- organizations must make sure that private repositories used for code development and testing stay private, and only open repositories (such as sharing back to the community) should be public. Security teams must constantly monitor and evaluate which repositories are open, and who should have access to other repositories. Any changes to the visibility of a repository should be alerted, logged, and evaluated by the security team.
Figure 1. Changing repository settings in Github
The second is the use of real customer data for development and testing purposes. This should be discouraged, and instead, use synthetic data mimicking the real data. In my previous blog post, Not All Sandboxes Are for Children: How to Secure Your SaaS Sandbox this was discussed in depth. The main problem is that many times, for no good reason, test environments are not considered as important to secure and keep good configuration hygiene compared to a production environment. But time and time again this is shown to be an Achilles’ heel. Many times real data is used in such environments and combined with low security and minimum safeguards, leads to data leakage.
The impact of such a breach is considerable. Not only was sensitive customer data stolen, but Nissan needed to publicly send out notifications, report it to the Office of the Maine Attorney General, and also gave all the affected customers a one-year membership of identity protection services through Experian for free.
You can protect your organization by securing your repository and making sure all repositories that need to be private stay private. Additionally, treat test environments just like production environments from a security standpoint. These are measures that, if done correctly, and with the aid of automatic tools, can keep your organization and customer data secure.
About the writer
