SBI cybersecurity lapse in which sensitive customer data was hacked and sent into the Dark Web

Deposits Are Safe in Banks, But What About Customer Data?

An advantage of traditional financial institutions (TradFi), like banks, is that the risk of customer deposits being stolen is very low compared to the risk of deposits being stolen from a vulnerable smart contract vault in a DeFi protocol.

This is due to the mode of holding deposits: in Web3, deposits are on-chain, while banks maintain deposits in ledger accounts with regulated system security and physical security. These deposits also have legal safeguards, which offer protection to account holders.

Yet, similar threat vectors that exist in Web3 also exist for banks when it comes to data security, as sensitive customer data is vulnerable to being hacked from their servers.

Applications used to enter and access customer data can be exploited through code vulnerabilities. Main application and server access credentials can also be hacked.

The recent cybersecurity breach that involved personally identifiable information (PII) belonging to 3,897 customers being extracted from the State Bank of India (SBI) system and published on the dark web highlights the need for banks to adopt data storage standards intended to preserve customer data confidentiality.

Cyberattack hits SBI; nearly 4k customers’ data leaked to dark web

Sensitive Information of SBI Customers Found on the Dark Web

Consider this —

This cybersecurity breach at India’s largest public-sector bank, SBI, involved records belonging to 3,897 customers, and possibly more, being stolen. The investigation was ongoing, with another 375,000 records on the dark web being scrutinised, so the possibility of more customer records being affected remains.

Banks should protect Customer Data like they safeguard Customer Deposits

The personally identifiable information (PII) of customers stolen from SBI’s system and made available on the dark web included names, addresses, phone numbers, gender, email addresses and dates of birth (DOB).

Alongside this, details of customers’ bank branches, Customer Information File numbers (CIFs), Lead IDs, loan and loan-lead-related metadata, and related documents were exposed.

Customers Whose Data Is Exposed Are Vulnerable to Being Targeted by Cybercriminals

This is a lot of information available on the dark web that cybercriminals can use to target these customers.

These SBI customers are likely to become targets of scams and other types of attacks aimed at stealing funds from their bank accounts.

Personal Data leak is a frightening prospect as it’s poses a real threat to customer’s safety

Some likely cyberattack methods include the following:

Fake Bank Loan Calls

A cyberthief now has enough details to call a customer for loan support while impersonating an SBI bank employee. Making a pitch armed with customer details, such as loan application information and the bank branch address, makes the impersonating caller sound convincing. Customers may be more likely to believe in the authenticity of the caller and be convinced to share their OTP or ATM PIN details with the fraudster, resulting in their funds being stolen.

Email and Phone Message Phishing

Armed with customer details, fraudsters can send more customised emails or mobile messages that appear relevant to the customer. For example, a message might concern a loan the customer is looking to obtain or contain a link to check the status of a loan taken by the customer.

The embedded fake link may direct the customer to a fraudulent website designed to steal login credentials or other sensitive information. Alternatively, it may install a virus that captures customer credentials by spying on online login processes and files stored on the customer’s system.

SIM Forgery

Cybercriminals have customers’ registered mobile number details, along with other personal information. It is possible that a cyberthief could use these details to obtain a duplicate SIM card and intercept OTP messages intended for the customer. If successful, the thief could use the intercepted OTP to authorise a transaction that the customer did not approve, resulting in stolen funds.

Violent Encounters with Criminal Gangs

With customer details such as names, addresses and phone numbers exposed, a criminal gang could potentially stalk a customer or intrude into the victim’s home to coerce them into handing over money or valuables.

This is dangerous, and that is why the breach of SBI customer details is a serious issue, even if customer funds in the bank remain protected. The safety of customers is indirectly compromised.

It is unsettling for any bank customer to have their PII on the dark web, available for criminal forces to evaluate.

(Scream!! It’s a scary thought!!)

Storing Data Smartly in a Privacy-Engineered Framework

This made me ponder the need for banks to adopt data storage standards designed to safeguard customer data privacy.

These privacy-engineered data storage practices should be adopted by any online entity that collects and stores customer data, including e-commerce websites.

Weak data storage mechanisms can result in your name, email ID and mobile number, used to register on these websites, being leaked onto the dark web.

Let’s return to Indian banks, as these regulated entities are required to collect and store important customer documents to comply with Know Your Customer (KYC) and Anti-Money Laundering (AML) norms.

These may include copies of PAN cards, Aadhaar documents, driving licences, income statements, rental agreements and utility bills as proof of residence, proof of identity, and proof of employment by an organisation and income.

These documents contain sensitive personal details, so such documents and other personal identity information should be stored in a robust, privacy-engineered framework.

Data Privacy Through Privacy-Engineered Database Design That Reveals Minimal Data

Privacy-engineered data storage frameworks are designed to reveal less personal information about a customer. This makes it more difficult to build a full customer profile even if a database is hacked.

Encryption of Stored Personal Identity Documents

ID documents should be stored in encrypted format — so they are hidden from view to unauthorized actors

Personal identity documents, such as PAN cards and the other documents discussed above, can be stored in encrypted form.

Furthermore, such files should remain encrypted when being exported within systems.

Encrypted storage should be combined with the privacy-engineered data storage methods outlined below.

Pseudonymisation

Instead of recording a customer’s name in the main database, the customer can be assigned a pseudonymous reference, such as CUST-7X29. Another database with strict access controls should contain the customer’s name linked to that pseudonymous reference.

This way, when a hacker accesses the main database, there is no customer name to connect with the other fields.

Other fields can also be obscured in the main database so that the hacker cannot build a full customer profile from the acquired details.

Data Generalisation

Instead of the main database containing a customer’s exact DOB, the customer could be categorised into an age range, such as 24–26 years. This way, the customer’s exact date of birth would not be available in the main database.

A hacker would therefore have less specific information about the customer that could be useful in conducting a cyberattack.

Data Minimization and Compartmentalization

Datasets should be stored in different databases according to the functional requirements of the applications that use them.

For example, a general account-operation process does not require access to a loan database that may contain additional personal information.

Personnel handling general account operations should have access only to the database that provides the customer information required for their work.

Likewise, sensitive data should be stored in a privacy-engineered manner in separate databases, preferably in encrypted form and with restricted access.

There are several other methods to minimise the exposure of data in databases. For example, instead of displaying a customer’s actual income, a token can be used.

The token can be mapped to the actual income record, but the database containing that record should be accessible only to authorised personnel. This method is called tokenisation.

Organisations should make efforts to design databases in a smart, privacy-engineered way so that if a hacker gains access to one database, the related information remains protected, requiring the hacker to work harder to obtain unauthorised access to other files.

Smartly Engineered Databases Designed to Reveal Minimal Data Through Access Controls

The main room contains data, but not every piece of information is available in that room.

Some information is strategically linked to hidden pieces of data in inner chambers, whose doors are locked and access is restricted.

Whole Customer Data is not easily available for view in a Privacy Engineered Database

This is compartmentalisation.

By breaking through the main door, a cyberthief cannot automatically retrieve the entire dataset or even a complete set of information, as only representations of certain data are available in the main database. To obtain the complete information, the inner database must also be accessed.

For example, as discussed earlier, the main database of an application can represent a customer’s name using a pseudonymous reference such as CUST-7X29, with an access-controlled inner database holding the customer’s actual name linked to that reference.

For a hacker, additional work is required to gain unauthorised access to the inner database. This approach can protect customer data to a significant extent, as multiple layers of databases and access controls must be overcome to obtain the customer’s complete dataset.

As mentioned, databases should be smartly engineered, with sensitive data held in compartments and access restricted.

Each database should contain only the datasets required for the operational needs of a particular application.

Database Structures Engineered to Prevent the Exposure of Customers’ Entire Dataset

The cyberattack on SBI succeeded in exposing a substantial set of customer information, including names, ages, gender, dates of birth, residential addresses, bank branch details and related documents containing personal information.

I do not know the details of SBI’s database structure. However, privacy-engineered database designs aim to prevent cybercriminals from obtaining all these datasets by hacking a single database. Such information should not be readily available in the main database; access-controlled inner chambers should protect the additional data.

The Importance of Banks Guarding Customers’ Personal Data as Carefully as They Safeguard Their Funds

Customers are safe when their sensitive details is not revealed to villain elements

This article covers some practical privacy-engineering methods that banks and other organisations can use to design their databases and system architecture to ensure that, if a database is hacked, the amount of customer data exposed to the hacker is minimised.

Focus should also be placed on application and system security, using industry-standard code and server infrastructure that is difficult for hackers to exploit.

Systems should be monitored, and security audits should be conducted regularly to identify vulnerabilities and patch them.

Monitoring and response systems should also be proactive, with SBI notifying affected customers that their data has been breached and is available on the dark web. This would help affected customers remain cautious, avoid falling victim to scams through phone calls, messages and emails, and take precautions in their other activities.

Unfortunately, data that has entered the dark web cannot simply be erased. It may remain in circulation even after the bank patches the vulnerabilities that allowed the breach to occur.

Customer Details on Dark web keep them vulnerable to be targeted by villain elements!

This is why the focus should be on preventing such data breaches in the first place.

Resource Credits -:

All posted images created with Chatgpt.

Also published on: Hive | Medium