Summary of 4 May meeting to discuss the new CERT-In policy and compliance and implementation challenges for Indian businesses

Introduction

Recently, the Indian Computer Emergency Response Team (CERT-In) released the Directions under sub-section (6) of section 70B of the Information Technology Act, 2000 relating to information security practices, procedure, prevention, response and reporting of cyber incidents for Safe & Trusted Internet.

The mandate of CERT-In has been to provide recommendations, guidance and support in the area of cyber security and cyber infrastructure.

However, a number of suggestions in the policy will lead to compliance challenges, operational complexities and increase in the costs of doing business in India, especially for small and medium sized organisations. Rootconf and Privacy Mode held a meeting with practitioners on May 4 to understand their concerns. Practitioners applauded the intention of bringing body corporates under this policy and holding them accountable for data breaches and data leaks, this being a good move. But many of them pointed out that this policy also puts all companies under a constant scanner of criminal liability. This is a psychological hazard, especially for small companies with one or two decision-makers.

Below is a summary of some of the key concerns that were discussed in the meeting:

The vagueness and breadth of information to be stored and provided.
Lack of specificity for whom the rules apply and exactly how the process will work.
The technical challenges that lead to exorbitant compliance and engineering costs incurred in conforming to these rules.

Summary

The main concerns from a business and implementation perspective are:

Validating names, addresses, contact numbers

Privacy concerns
Requires external validation services
Validation of foreign customers is ambiguous

‘Ownership pattern’ of customers

No definition of ‘ownership pattern’

IP addresses allotted to/being used by members

IP addresses are not fixed and can change for certain services

Mandate of maintaining 180 days of logs.

Requires either external providers/in-house solutions, so compliance is costly
Maintenance of logs is technically complex, especially at scale
Raw logs could have identifiable information. Data governance concern around access and leaks

Main Concerns: Cost, complexity, privacy

Policy points which are vague:

Types of companies.
Jurisdiction with regards to foreign companies and customers.
Prevention of clashes with privacy protection.
Verification of authentic requests.
Specificity with respect to incidents to be reported.

Main concerns: operational, legality

General Recommendations

Account for the size of business and change policy accordingly.
Use specific directive phrases which make it easy to build implementation procedures and operational processes.

Detailed Concerns

Concerns with respect to the information to be registered by data centres, VPS providers, VPN providers, and other such entities:

Multiple entities with different functions are grouped together under one umbrella and are regulated similarly with a broad brush.
There are seven data points to be registered by all entities about their customers. Some of the problems with them are:

Validating names of subscribers / customers using their services : Third-party entities such as digio.in are required to validate these details, creating additional costs for the enterprise.
Validating address and contact numbers of users : For global digital businesses, this is a prohibitive cost. Since customers can be international, the question of how to validate information is ever present. The customers themselves could be resellers/sub-customers of other companies, adding more complications.
Ownership pattern of the subscribers/customers hiring services : There is no explanation or definition given for what 'ownership pattern' means. It is unclear if this is a separate form of data to be recorded, or a part of the KYC norms.
IPs allotted to/being used by members : For modern cloud services, this is a complicated matter as IPs are usually rotated between customers every few minutes.

Businesses also expressed concerns that the costs of doing such a KYC exercise will be prohibitive.
Maintenance of logs for 180 days for Information and Communications Technology (ICT) systems is difficult. The term 'ICT systems' is too broad and there are certain parts of any system that cannot be accessed by the company because of company policies and technological reasons.

Lack of clarity on regulation and application

There is a lack of specificity for whom the rules apply and exactly how the process will work. For example:

Do these rules only apply to companies registered in India or companies with customers in India?
What are the limits to the information that CERT-In can have access to? How does this policy resolve clashes with privacy laws and privacy protection?
How does one verify the authenticity of requests from CERT-In without any judicial involvement?
What would the actual audit and enforcement process look like?
The incidents that are to be reported to CERT-In are very broad and aren't specific in their terminology. Below are anecdotes provided by senior engineers:
- For any publicly hosted service there are always attempts to attack or breach on a day to day basis. Most of such attempts are based on brute force simple methods. The policy does not make it clear whether all such attacks which were prevented using good security practices would also need to be part of the reporting package.
- Botnets are a daily aspect of work. The idea of security is to raise the cost of infiltration. However, the policy demands a raise in the cost of defence.
- To quote a senior engineer, "There's always someone trying to access the admin page. Do we have to go and report everything to CERT-In via an email?"
With respect to incident reporting, one practical issue is that emails to CERT-In are known to bounce back. This makes compliance practically challenging.
Mandatory connection to NTP servers (or traceable to them) of NIC or NPL for synchronised time across all servers.
- Companies that currently use Microsoft, Apple or other public Internet Time servers will have to ensure compliance for very little gain.
- Businesses directly running Stratum 1 NTP servers might be in violation of this rule.
- This is a side effect of the lack of policy regarding digital time in India. (Read: 'Traceable Time' for more context)

Technical implementation challenges with log data requirement

Cost
- Text processing at scale is hard, and even more so for searchable text logs. They can use external service providers (such as datadog), however, this increases cost enormously given the amount of data to store (90 days of logs). There are some solutions, but they vary from platform to platform and cannot be standardized.
- For Small and Medium Enterprises (SMEs) who cannot afford external providers, in-house solutions can be developed. However, in-house solutions add to engineering costs and rapidly become complex as the amount of data to store increases.
Complexity
- Once 180 days of logs are complete, there is a question of how much data should be archived and readable, and a question of the acceptable time delay to produce said documents.

In modern systems, logs are stored as document models rather than text files. This increases the complexity of the IT architecture required to sustain.
- Having just 90 days worth of readable and searchable logs is an incredibly complex task. Offloading that complexity to every single small business would be a disaster as most do not have the scale, resources nor budget to justify such a cost.

Scale
- Each organization will work with multiple microservices (around 30-40) and large organisations can sometimes use upwards of 500 microservices. The amount of log data to be generated and stored from all these services is incredibly huge.

Policy Reviews

{{ gettext('Draft') }}