Strengthening Data Protection to Meet SEBI’s Encryption Mandates

Introduction to SEBI’s Encryption Mandates

India’s financial markets are currently in a supercharged state. With increasing participation from retail investors, the National Stock Exchange (NSE) reported daily trading volumes averaging around ₹45,000 cr in equities. A lot of these transactions involve sensitive data like payment details, transaction histories and personal identifiers, making it attractive for malicious actors attempting to gain unauthorized access. This is reflected by the Indian financial sector facing more than 13 lakh cyberattacks between January to October 2023, according to the RBI. 

If these attackers do happen to gain access, there could be serious ramifications, leading to both a loss in revenue and customer confidence. Therefore, there is a clear incentive for financial organizations like yours to have strong security measures to guarantee privacy, availability & integrity of financial data.

The Importance of Encryption in Financial Data Protection

One key measure is encryption, which is a crucial part of the Cybersecurity & Cyber Resilience Framework (CSCRF) issued by SEBI on August 20, 2024. CSCRF has numerous mandates for SEBI’s Regulated Entities (REs) – this blog will focus specifically on the framework’s encryption-centric requirements. Interestingly enough, there is not much mention of encryption in the released framework, because most of the groundwork for the same was laid out last year in a SEBI circular titled ‘Framework for Adoption of Cloud Services by SEBI Regulated Entities’ on March 6, 2023.

Encryption secures data by converting it into ciphertext that is indecipherable for unauthorized persons. This is done using cryptographic keys, which are are random strings of bits generated to encrypt and decrypt. CSCRF dictates that all REs secure their data-at-rest and data-in-transit, with the further mandate of securing data-in-use for only Market Infrastructure Institutions (MIIs) and Qualified REs,

Securing Data-at-rest

CSCRF dictates that data-at-rest encryption has to be done with strong encryption algorithms, featuring a mix of data object encryption, file level encryption and tokenization in addition to the encryption provided at platform level.

So, what type of encryption works best for your data? The answer will be extremely clear after undertaking a thorough risk assessment that identifies your most sensitive data. It is important to note that encrypting all your data is infeasible and may open up additional attack vectors, so this first step is crucial.

One categorization for types of encryption can be based on the cryptography:

• Symmetric encryption is a basic encryption technique where the same key is used to encrypt & decrypt data. With it, you can achieve efficiency in processing large amounts of data while maintaining privacy. Some examples of this are Advanced Encryption Standard (AES) and Data Encrytion Standard (DES). CSCRF prescribes the use of AES, preferably 256 bit.
• Asymmetric encryption uses a key pair of a public key distributed publically for users to encrypt data, and a private key kept secret within your web server. Only this key has the power to decrypt data. It is generally more secure than symmetric encryption while also being slower. Some techniques include Rivest-Shamir-Adleman (RSA), Elliptic Curve Cryptography (ECC) and the Diffie-Hellman key exchange. CSCRF mandates the use of RSA.
• Hybrid encryption combines the two aforementioned encryption types, combining the high performance of symmetric with the security of asymmetric. An example for the same is using AES for data payload encryption, and RSA for key exchange.

Another categorisation is based on what you’re encrypting. In this comes full disk encryption (FDE) and file based encryption (FBE). FDE encrypts all the data in a complete drive, while FBE encrypts specific files or directories. CSCRF mandates using a mix of both, and that particular mix will be dependent on the classification of your sensitive data. Here are some key differences between the two:

Ultimately, despite the encryption mix you choose, a lot of different cryptographic keys will be generated. And for data-at-rest to be safely stored, key management procedures must be followed. 

Key Management and Hardware Security Module (HSM) for CSCRF Compliance

To that end, CSCRF demands implementation of a dedicated hardware security module (HSM) that has complete control of key management, including generating, storing, exchanging and managing keys. Key rotation and stringent access restrictions are essential for success. It is critical to identify the right personnel in charge of the keys, as well as the right methodologies for storing them – any compromise to each will render the entire encryption process useless. Additionally, your HSM should be designed in fault tolerance mode to ensure that potential failure of the system doesn’t have any impact on data retrieval and processing.

(Note: CSCRF mandates that REs retain complete ownership of their encryption keys, so if you choose us as an encryption partner, we will take care of all the processes while the keys secretly reside in your systems.)

Securing data-in-transit

This includes data in your cloud. CSCRF mandates a mix of session encryption and data object encryption in addition to the encryption provided at the platform level, whenever sensitive data is in transit.

Here are some things to keep in mind for the same:

• When an application transmitting sensitive data communicates over the Internet with the REs systems (ex. IBT communication from client’s web browser), it should be done over a secure, encrypted channel using a strong transport encryption mechanism like Transport Layer Security (TLS). The asymmetric public key cryptography used in TLS helps prevent Man in the Middle (MITM) attacks.
• For applications carrying sensitive data served as web pages over the Internet, a valid, properly configured TLS certificate on that web server is mandatory. The transport channel, in this case, becomes HTTP(S), shown through the padlock sign on your browser.
• Instead of using insecure protocols like File Transfer Protocol (FTP), use secure protocols like FTP(S), SSH and VPN tunnels.

Additionally, for MIIs and qualified REs, data-in-use must be secured using confidential computing solutions. 

Simplifying CSCRF Encryption Compliance with iValue

That’s a lot of requirements to keep in mind for encryption, which is in itself a small but important cog in the CSCRF machine. The last thing you want is to incorporate a bunch of different solutions that makes it extremely difficult to keep track of it all.

To that end, we suggest you opt for iValue’s state-of-the-art suite that gives you full visibility into all your CSCRF requirements.

Here are the solutions in our suite that fit your CSCRF encryption requirements:

• Full Disk Encryption through our partnerships with Thales and Entrust. Thales, in particular, focuses on tokenization, which is a crucial component in CSCRF’s data-in-use encryption mix.
• File Based Encryption through our partnerships with Fortanix and Ultimaco. Both provide maximum security – Fortanix Filesystem Encryption, for example, is FIDS 140-2 Level 3 certified.
• Key Management Solutions through our associations with Google KMS, Entrust and Thales. Entrust KeyControl automates the entire key lifecycle, including key storage, backup, distribution, rotation and key revocation. 
• Facilitation of secure, most recent TLS certificates for your webpages.

These solutions work in sync to help fortify your data, and a centralized dashboard gives you complete oversight at all times. If that’s something that interests you, click here to set up a meeting so we can go about finding your ideal encryption mix!