The Latest

27 August 2021: Security flaw hunters at Wiz were able to obtain the security keys that control access to Microsoft’s Azure Cosmos DB, and demonstrate that it was possible to access customers’ Azure Cosmos DB.  

Why it’s Important.

This flaw is especially worrying, because all Cloud vendors and many independent security advisors, including IBRS, have been advocating that Cloud security is generally of a far higher standard than that achieved by most in-house data centre teams. IBRS stands by this claim. But this does not mean Cloud vendors will not make security mistakes. And when they do, they will impact large numbers of organisations.

There is no evidence that this security flaw - likely an operational oversight - has been exploited. Once it was identified by Wiz (on the 9th August) and flagged with Microsoft (on the 12th August), the existing keys were quickly re-secured. Unfortunately, the keys in question are fundamental security assets that Microsoft cannot change. Therefore, Microsoft emailed the customers (on the 26th Aug) requesting they create new keys, just in case the previous keys had fallen into the hands of bad actors. It is estimated that 3300 customers have been impacted. 

To mitigate this issue, Microsoft advises Cosmos DB customers to regenerate their Cosmos DB primary keys immediately.

Unfortunately, just because there is no evidence the flaw had been leveraged, organisations should assume the worst. It is well publicised that state-actors hoard such flaws for intelligence gathering. In this case, paranoia may be justified.

More importantly, the situation highlights the need to take a multi-level approach to security in the Cloud. Relying on security protocols to secure an essential asset places organisations at greater risk of these hyper-scale security flaws.  

For example, in this situation, organisations that have behavioural/usage pattern analytics monitoring the database would likely have been altered should any bad actor start to access the database, and remedial action would be triggered. Furthermore, data from such monitoring could be used to determine the likelihood that the security flaw had been exploited - something few Azure Cosmos DB customers can confirm at the moment. 

Another example is using encryption services, these services should be leveraged extensively. Assume data assets will leak and repositories (including databases) will be breached, base encryption strategies on the sensitivity of the data. 

A migration to the Cloud can often improve the security stance of an organisation, but only if security is treated as a multifaceted, ‘trust nothing’ (akin to zero trust) philosophy is taken.

Who’s impacted

  • CISO and security teams
  • Cloud architects
  • Cloud migration teams

What’s Next?

  • If you are an Azure Cosmos DB client or have instances in development teams, immediately regenerate the primary keys for these databases.
  • Review your Cloud solution designs - including those of ‘lift and shift’ of legacy systems - to identify where single points of security failure could occur. Consider remediation strategies using multi-facilitated security services risks. Such effort needs to be balanced against business risk and information sensitivity. 

Related IBRS Advisory

  1. Cloud Security Considerations – Lessons from the Frontline
  2. CyberArk launches AI-powered service to remove excessive Cloud permissions
  3. New generation IT service management tools Part 2: Multi-Cloud management