DEVOPSdigest

Recently, Nissan North America confirmed a data breach at a third-party service provider. Details of the breach were highlighted in a notification(link is external) that was filed with the Office of the Maine Attorney General on January 16, 2023. Here's what was learned from the report:

■ A software development vendor alerted Nissan of the breach in June 2022.

■ Nissan provided the vendor with customer data, which it used to develop and test software solutions.

■ The data was inadvertently exposed due to a poorly configured cloud-based public repository.

■ The breach impacted close to 18,000 customers.  

As for the automobile giant's response, Nissan acted quickly, securing the exposed repository and launching an internal investigation. Through this review, Nissan determined the incident was most likely the result of an unauthorized person accessing the data, which includes full names, dates of birth, and Nissan account numbers. The company's investigation also found no evidence that credit card information or Social Security numbers were exposed, or that this information had been misused.

While the latter point is good news, there are still lessons to be learned from this incident. The first, is the importance of securing repository access such as GitHub, GitLab, Bitbucket, and more. Nissan is not alone. There are many other repository-related incidents like this. One example is the breach of Slack's GitHub repositories. After conducting its investigation, Slack tied the breach to stolen Slack employee tokens, which were then used to download private Slack code repositories.

In most cases, the issue comes down to a simple directive — businesses must take all the necessary actions to ensure that private repositories used for developing and testing remain private. I'm not saying they cannot utilize open repositories. Those are great for things such as sharing back to the community. For businesses with both, the onus is on security teams to regularly monitor and evaluate these repositories and identify those that are open and who should have access. When changes in the visibility of a repository occur, they must be alerted, logged, and evaluated by the security team.

A second lesson learned involves the use of real customer data for development and testing purposes. There is always a risk when introducing customer data into a sandbox, especially where the focus is building and testing, that security takes a backseat. This is precisely why introducing customer data is extremely dangerous.

From my experience, the main reason that businesses don't prioritize security in these environments is simple — they don't believe it's as important to secure and maintain the same levels of good configuration hygiene in test environments as in a production environment. Instead, they apply minimum security and safeguards, a practice that prevails despite the growing number of incidents where real data is leaked.

To stop the bleeding, remove real data from the sandbox and use synthetic data. Since sandboxes are typically used to test changes in configurations, processes, flows and more, they do not require real data. Any data that uses the same format is sufficient.

A failure to take these steps into account open businesses to a breach, the impact of which can be significant. In the case of Nissan, consumer confidence can soften after sensitive customer data is stolen. For affected customers, Nissan is providing free one-year identity protection services from Experian. But breaches like this can have long-term impacts on the brand. Nissan had to go public by sending out notifications and reporting them to the Office of the Maine Attorney General.

While awareness of these attacks continues to grow, there is little chance that incidents will abate unless organizations take action. Start by securing repositories and making sure that those which need to remain private stay that way. Next, ensure that your teams treat test environments the same as they do production environments when it comes to security. When done correctly, and with the aid of automatic tools, these steps can keep your organization and its customer data secure, while allowing teams to continue playing safely in the sandbox.