Two Engineering and Transparency Lessons from the suspected India COVID portal leak

As of this morning a significant data leak of the India CoWIN platform is being debated. Apparently a the leak was facilitated through a Telegram bot that allowed access to sensitive details without requiring the One Time Password (OTP) verification normally required.

The exposed information includes names, dates of birth, phone numbers, gender, passport numbers, and Aadhaar numbers (unique IDs issued to residents and expats).

Interestingly enough, the government institutions of India - namely the National Health Authority and The Health Ministry have pushed back on the data leak and post three claims, which we need to discuss in detail:

1. The CoWIN platform is fully secured, with implemented best practices, firewalls, web application filters etc.
2. There are no public APIs allowing data retrieval without OTP but certain APIs shared with trusted third parties have the capability to share data without requiring OTP. Supposedly, those APIs are connected only to whitelisted systems.
3. The government institutions assert that the exposed data through teh bot originates from a threat actor database, potentially comprised of previously breached or stolen data

What can we make of these claims?

1. The claim that the CoWIN platform is fully secured with listing all defensive mechanisms is moot in the context of a data leak. Most companies that suffer a data breach or data leak have these same mechanisms already installed. Yet data leaks and data breaches still occur - either by exploiting a misconfiguration or vulnerability of these mechanisms, or by completely bypassing them and exploiting a human error through phishing or unsecured internal interface.
   • Which brings us to the second claim...
2. The internal API which isn't OTP authenticated is fully secure via whitelisting - but can we trust the whitelisted party?  Whitelisting of a third party to access an API as a security control is a very poor security practice since there is a third party who we trust to be as secure as our system. A compromise in the systems of the third party suddenly exposes our back door. The Indian authorities provide no details about this vector of data egress.
   • But what if it's an old data breach?
3. The claim that the exposed data is from an old data leak is still a MASSIVE DATA BREACH incident for the government of India. Regardless whether the data is exposed this moment or the data was exposed previously, the real data of real people that was in the custody of government institutions is exposed and accessible on the wild internet to be abused.

Two lessons learned as Engineers and Security Officers

1. When designing your API, ALWAYS design it with the assumption that it will be exposed to the internet. Authentication mechanisms commensurate to the value of the exposed data is a must. Throttling and alerting of excessive data access is also to be considered to stop anyone from breaching data once authenticated. Whitelisting of servers, IPs or anything else is a huge assumption and a huge mistake.
2. When handling of data breach incidents, be transparent and address the key pain of the individuals - their data is exposed so everyone can learn and prevent future incidents. It doesn't matter whether the data is exposed now or some months ago. It's still an incident. Investigate it thoroughly, provide clear and unambiguous information of what really happened and what is exposed and discuss lessons learned. Only through facing the mistakes that were made can one improve the security of future services.