May 26, 2022

Multiassocaition Letter in Response to CERT-In Security Directive

Dr. Sanjay Bahl,

The undersigned associations represent a broad cross-section of industry, spanning businesses of different sizes, different sectors and from countries including the EU, UK, and the U.S. Collectively, the billions of dollars of resources that they commit to cybersecurity and the expertise that they provide are at the forefront of industry efforts to promote a free, open, and secure cyberspace to protect end users and society at large. We write to you regarding the recent directive issued by the Indian Computer Emergency Response Team (“CERT-In”) relating to Information security practices, procedure, prevention, response and reporting of cyber incidents for Safe & Trusted Internet (“the Directive”). While we share CERT-In’s objective of ensuring the resilience of critical infrastructure entities, we are concerned that the Directive, as written, will have a detrimental impact on cybersecurity for organizations that operate in India, and create a disjointed approach to cybersecurity across jurisdictions, undermining the security posture of India and its allies in the Quad countries, Europe, and beyond. The onerous nature of the requirements may also make it more difficult for companies to do business in India. We recognize that CERT-In recently released a set of FAQs related to the Directive aimed at addressing questions that stakeholders have raised with regard to implementation. However, given the FAQs do not carry the force of law, they do not offer enough assurance to businesses operating in India. We continue to have concerns with the mandatory reporting of cybersecurity incidents within a 6-hour timeline, the overbroad definition of reportable incidents, the requirement that companies furnish sensitive logs to the CERT-In, the requirement that companies take action to respond to an incident as mandated by CERT-In, the requirement for Virtual Service Providers (VSP), Cloud Service Providers (CSP), and the requirement that Virtual Private Network (VPN) Providers to record certain subscriber information for at least 5-years after service cancellation. If left unaddressed, these provisions will have a significant adverse impact on organizations that operate in India with no commensurate benefit to cybersecurity .Our technical concerns are outlined in greater detail below. Finally, we are concerned with the absence of stakeholder engagement by CERT-In before releasing such a significant cybersecurity proposal. As the Organization for Economic Cooperation and Development outlines:

2 Stakeholder engagement is a crucial element of regulatory policy. It helps to ensure that regulations are in the public interest by involving those that are affected by regulations ,including citizens, businesses, civil society and other community members. Stakeholder engagement improves the quality of rule making by collecting ideas, expertise and evidence from stakeholders about policy problems to be solved and possible solutions to address them. It also ensures that regulation is user-centered and responds to the needs of those governed. By consulting all affected parties, stakeholder engagement enhances the inclusiveness of policies and supports the development of a sense of ownership of regulations. This in turn strengthens trust in government, social cohesion and compliance with regulations.1This is particularly relevant in highly technical and impactful areas of policymaking such as cybersecurity. We look forward to engaging with you further regarding these concerns and respectfully encourage you to delay the effective date of the Directive and the associated implementation requirements for the underlying provisions until further consultations with stakeholders have taken place. Connection to NTP servers (part i)The requirement that “all service providers, intermediaries, data centres, body corporate and Government organisations shall connect to the NTP servers [of Indian labs and other entities] for synchronization of all their ICT systems clocks” is very concerning because it could negatively affect companies’ security operations as well as the functionality of their systems, networks, and applications, amongst other reasons. While the FAQs note that organizations are allowed to use a standard time source other than the National Physical Laboratory and National Informatics center “as long as the accuracy of time is maintained by ensuring that the time source used conforms to time provided by NTP Servers of NPL and NIC,” this could still be problematic if the NTP servers are not synced with everyone else’s. We urge CERT-In to remove this provision entirely.6-hour reporting timeline (part ii)We recognize that incident notification is a priority for India and other governments around the world. However, we believe that a 6-hour timeline is too short. CERT-In has not provided any rationale as to why the 6-hour timeline is necessary, nor is it proportionate or aligned with global standards. Such a timeline is unnecessarily brief and injects additional complexity at a time when entities are more appropriately focused on the difficult task of understanding, responding to, and remediating a cyber incident. Entities will also unlikely have sufficient information to make a reasonable determination of whether a cyber incident has in fact occurred that would warrant the triggering of the notification. We encourage CERT-In to establish feasible incident reporting timelines of at least 72 hours, commensurate with incident severity levels in alignment with global best practices. Doing so will ensure that companies are able to focus on responding to an incident and that any information provided to the government is properly contextualized and as substantively thorough, complete, and accurate as possible at the time of notification. Mandatory action (part iii)1 See OECD Government at a Glance 2017 here: https://www.oecd-ilibrary.org/sites/gov_glance-2017-55-en/index.html?itemId=/content/component/gov_glance-2017-55-en

3

We have concerns about the unprecedented approach that India proposes in the Directive, which would mandate that impacted companies either ‘take action’ or ‘provide information’ as directed by CERT-In. Our companies operate advanced security infrastructures with high-quality internal incident management procedures, which will yield more efficient and agile responses than a government directed instruction regarding a third-party system that CERT-In is not familiar with. CERT-In should

revise the Directive to remove this provision. A more appropriate approach might be asking that providers demonstrate that their incident and risk management procedures meet international standards, such as those contained in ISO 27000 certifications .Incident definition (Annexure I)The current definition of reportable incidents, to include activities such as probing and scanning, is far too broad given probes and scans are everyday occurrences. Although the FAQs attempt to narrow the scope of incidents that are to be reported within 6-hours by adding language like ‘incidents of a severe nature,’ we believe that the definition remains too broad to be practically implementable. What constitutes a severe incident is left up to interpretation, and the rest of the categories of ‘incident’ that are included in Annexure I, when taken together, will result in companies reporting incidents that have not resulted in actual disruption or loss of service. It will not be useful for companies or CERT-In to spend time gathering, transmitting, receiving, and storing such a large volume of insignificant information. This would force companies to misallocate already scarce security budgets to produce data that cannot be effectively consumed by any security regulator and would likely be deemed of little consequence were it to be analyzed. CERT-In’s existing process for reporting incidents further exacerbates this problem, since it relies upon outdated methods, rather than machine-readable formats such as STIX and TAXII. Logging requirements (part iv)Although we appreciate that the FAQs document has clarified that logs are not required to be stored in India, as referenced at the outset, if this is actually the case, CERT-In should revise the Directive to reflect that. Even if this change is made, however, we have concerns about some of the types of log data that the Indian government is requiring be furnished upon request, as some of it is sensitive and if accessed, could create new security risk by providing insight into an organization’s security posture. Additionally, a requirement to furnish this volume of log data (or to furnish log data at all) goes beyond what has typically been included in incident reporting policy proposals elsewhere and is out of step with global best practices. Finally, this will impose a huge burden on organizations’ security teams in an environment where security resources (including personnel) are at a premium. VSP, CSP, and VPN Providers Subscriber Information (part v)Although ISPs commonly collect the customer information described in part v, extending these obligations to VSP, CSP and VPN providers is burdensome and onerous. For example, enterprise customers purchase internet connections from their ISP and the ISP is the party responsible for providing that customer with their IP address. A data center provider does not assign IP addresses. It will be an onerous task for the data center provider to collect and record all IP addresses assigned to their customers by ISPs. This could be a nearly impossible task when IP addresses are dynamically assigned. Further, storing the data locally for the lifecycle of the customer and thereafter for five years will require storage and security resources for which the costs must be passed on to the customer, who notably has4not asked for this data to be stored after their service termination. And, perhaps more importantly, this requirement creates a security threat for the sensitive data stored. Given the concerns stated above, we strongly encourage CERT-In to:1. Delay the implementation of the Directive to allow time to conduct further stakeholder consultations and address technical and other concerns2. Launch a broad stakeholder consultation to ensure that the Directive can be effectively implemented in a revised format, including that CERT-In open a detailed technical consultation for public reply3. Revise the Directive to address concerns with regard to the NTP server connection requirements, incident reporting timelines, the requirement that companies take response or remediation action as directed by CERT-In, the definition and scope of covered incidents, the logging requirements, and the requirements pertaining to subscriber information of VSP, CSP and VPN Providers We thank you for your consideration of these comments and look forward to further engagement with you to effectively promote the security and resilience of critical infrastructure in India.

Sincerely,

Asia Securities Industry & Financial Markets Association (ASIFMA)Bank Policy Institute BSA | The Software Alliance Coalition to Reduce Cyber Risk (CR2) Cybersecurity Coalition Digital Europe Information Technology Industry Council (ITI) tech UK U.S. Chamber of Commerce U.S.-India Business Council U.S.-India Strategic Partnership Forum