2020 will go down in infamy for many reasons, but as millions of people have struggled with a pandemic throughout the past year, organizations have had their own crises to deal with. With more activity in the cloud than ever before, data breaches have affected everyone from small businesses to Fortune 500 companies. In this four part series, we look back on notable breaches from 2020 and discuss how SecureCloudDB could have been employed as part of a layered defense strategy to alleviate, if not prevent, incidents like them.
Part two covers the Microsoft breach.
250 Million Customer Support Records Leaked
Near the beginning of 2020, Microsoft disclosed a breach affecting 250 million records related to support case analytics with details including emails, IP addresses, and support tickets.
According to Comparitech, which discovered the leak, the records contained logs spanning a 14-year period and were housed on five Elasticsearch servers that were left accessible to anyone with a web browser, with no password or other authentication needed. The records were left publicly accessible for nearly a month. While Microsoft had redacted much of the personal information from the records, there were certain cases in which data was not redacted meaning some personally identifiable information was exposed.
Ultimately, the cause of this breach was due to misconfigured security rules within their environment leaving the database open to potential attackers.
How SecureCloudDB Can Help - Security Rules
SecureCloudDB’s security rules inventory keeps track of an organization’s rules (including old and new versions) allowing you to tag them by cloud provider, service, severity and more. You’re able to see if any instances in the environment are in violation of each rule and remediation details for each rule. Additionally, users are able to create Lambda functions to enable automated remediation using CloudFormation templates.
Out of the box we offer upwards of 100 different rules pertaining to services including SQL Server, Elasticsearch, AWS RDS, and more. Rules are based on AWS benchmarks, CIS benchmarks and other authoritative sources.
The proprietary rules engine identifies vulnerabilities that could be exploited as well as misalignment with security and compliance requirements. For example, our Elasticsearch rules inform as to whether data is encrypted at rest, patches are deployed to the AWS instance, the domain is not publicly accessible and much more.
SecureCloudDB proprietary rules engine accessible by selecting "Foundational Security" in the main menu then "Security Rules".
Sample Security Rule: Ensure the 'sa' Login Account is set to 'Disabled'
Protecting Data At the Source Has Never Been More Critical
We all want to believe that our environment is impenetrable, but history has shown that no organization is immune from threats. Whether it’s poorly configured databases, weak passwords/encryption or a rogue employee, events have shown us that being ahead of the threat is key to countering it. Failure to combat an attack no matter how small can lead to outages as well as financial and reputational consequences.
The monitoring and assessment of database environments is crucial. With SecureCloudDB, putting safeguards in place to help prevent public cloud database breaches in 2021 and beyond has never been easier.