Data Breach Hits Microsoft Customer Service Database

Over the last twelve months, we’ve heard reports from companies of all shapes and sizes that have suffered from data breaches.

Many of them were caused by an act of carelessness on the part of an employee that accidentally left an important database exposed to the world. It raises eyebrows though, to hear that Microsoft was the target of such an action.

Surprising or not, Microsoft recently disclosed that a total of five servers storing a variety of customer support analytics were accidentally exposed online in December 2019.

Credit goes to Bob Diachenko, a researcher with Security Discovery. He found the leaky database, which consisted of a cluster of five ElasticSearch servers. According to Diachenko, all five servers stored the same data, appearing to be mirrors of each other.

The servers contained nearly 250 million entries that included IP addresses, email addresses and support case details. Upon learning of the incident, Microsoft responded quickly. They secured the servers in question and made an announcement, which also reassured users that “as part of Microsoft’s standard operating procedures, data stored in the support case analytics database is redacted using automated tools to remove personal information.”

After conducting an in-depth investigation, the company concluded that the data had not been copied or maliciously used by third parties. The leak was caused by a misconfiguration of the Azure security rules it deployed on December 5th, 2019.

The company made the following changes and now:

• Audits the established network security rules for internal resources
• Has expanded the scope of the mechanisms that detect security rule misconfigurations
• Has added additional alerting to service teams when security rule misconfigurations are detected
• Has begun implementing additional redaction automation
• No company is immune, not even Microsoft. Kudos to the company for their rapid response and deft handling of the issue. That’s how it’s done.

Used with permission from Article Aggregator