As we previously reported, in September 2016 the New York Department of Financial Services (the “DFS”) proposed a regulation that would require banks, insurance companies and other financial services institutions regulated by the DFS to adopt broad cybersecurity protections (the “Proposal”). The comment period for the Proposal closed in mid-November.
A number of financial industry groups (the “Industry Groups”) filed public comments to the DFS regarding the Proposal in a letter dated November 14, 2016 criticizing many of the requirements imposed by the Proposal (the “Letter”).
The Industry Groups expressed concern that the Proposal would introduce standards and requirements that are already covered by existing cybersecurity requirements. The Industry Groups advised that the Proposal should complement and be consistent with existing cybersecurity requirements, such as the National Institute of Standards and Technology (“NIST”) Cybersecurity Framework, which is widely used by financial firms as well as other businesses and organizations.
The Industry Groups argued that the definitions of “Nonpublic Information,” “Information System,” and “Cybersecurity Event” are so broad that they cover, respectively, almost all information maintained by a firm, any firm information system, and any event, successful or unsuccessful, that may involve an attempt to access information without authorization. Additionally, the Proposal’s requirements apply to Covered Entities (defined to include DFS-registered and -licensed entities) yet some DFS-registered and -licensed entities do not maintain any Information Systems and do not possess any Nonpublic Information.
A recurring theme in the Letter is the recommendation that the Proposal should take an approach based on assessments of the level of risk, which permits firms to target resources and controls based on a number of factors, instead of imposing one-size-fits-all requirements.
The Letter provides examples and criticisms of such one-size-fits-all requirements, including:
- Notification to the DFS within 72 hours of any Cybersecurity Event that has a reasonable likelihood of affecting the “normal operations” of a Covered Entity or “affects” Nonpublic Information: There may be millions of daily unsuccessful attacks against a firm which would need to be reported to the DFS. Imposing a requirement to provide notice to the DFS within 72 hours could (a) prevent a firm from devoting its resources fully to responding to a threat and (b) require firms to provide notice based on unconfirmed information about the incident. The notification requirement also lacks a provision allowing for a delay in notification if a law enforcement agency determines that the notification would impede a criminal investigation, which appears in many states’ security breach notification laws, including New York’s;
- Encryption of all nonpublic data that is linked or linkable to a person or otherwise constitutes Nonpublic Information, both in transit and at rest: Implementation of this requirement would require a great deal of resources, personnel time and technical expertise as well as result in enormous delays in data processing and increase the likelihood of data corruption. Implementing this requirement would also make it harder for a firm to adopt new technologies that could protect systems and data more effectively than encryption (such as tokenization). In addition, the requirement to encrypt nearly all data at rest or in transit may weaken security controls by (a) requiring broad distribution of encryption keys to allow applications to access such data, which would increase vulnerability points through which the information could be hacked, and (b) blocking surveillance of such data to detect intruders. Moreover, requiring all vendors to encrypt almost all data would be extremely impractical to administer and cause processing delays;
- Maintenance of audit trails (logs used to track activity) for nearly every financial transaction, as opposed to in accordance with a Covered Entity’s assessments of the level of risk posed by types of financial transactions and other activities;
- Performing annual risk assessments that cover nearly all technologies used by a firm: If these assessments are not made explicitly risk-based (meaning, based on the firm determining whether a given technology poses a level of risk that would necessitate an assessment), such a requirement would make it difficult for cybersecurity personnel to prioritize sensitive or vulnerable information systems and significant threats;
- Third-party monitoring requirements that apply to nearly every vendor and service provider and do not prioritize higher-risk entities;
- Multi-factor authentication (requiring a user to provide multiple methods of authentication – for example, a password and a temporary code texted to the user’s phone) for (a) virtually every information system and (b) access to virtually all types of data maintained by firms: Requiring multi-factor authentication to this extent could result in noncompliance and ad hoc workarounds;
- Annual penetration testing (testing to find vulnerabilities) for nearly all technologies used by a firm, including low-risk systems;
- Data mapping (the process of identifying organizational data flows and specifying how one information set relates to another) of all Nonpublic Information even where it is not the best method of achieving awareness of the location of sensitive information; and
- Limitation of access privileges that might require firms to limit access privileges to every system, regardless of its use or risk profile.
The Letter also identified implementation impracticalities and unintended consequences that could result from certain requirements, such as:
- The requirement to conduct penetration testing annually and vulnerability assessments quarterly could extend to nearly every piece of technology operated by a firm; additionally, since the level of testing and assessment is not based on a firm’s assessment of risks and vulnerabilities, it would be prohibitively expensive and difficult to administer;
- The across-the-board six-year retention period for audit trail data is burdensome and does not materially improve cybersecurity;
- Data deletion requirements apply to commingled data (where data of one kind is mixed with data of another kind) and cannot be implemented without significant resources, changes and new technologies;
- Since the annual certification form required to be submitted to the DFS by the Covered Entity lacks a mechanism to report areas that are not in complete compliance at the time of certification (but will be prioritized for compliance going forward), the required certification could (a) result in a paper exercise of downstream certifications to shield senior management from liability, and (b) even result in criminal liability if the program is found to be noncompliant;
- Requiring Covered Entities to obtain representations and warranties from vendors that the service or product provided is free of vulnerabilities is in conflict with many third-party engagements where firms face liability waivers with respect to these issues. For smaller Covered Entities, requiring that contractual language be revised to include such representations and warranties (as well as audit rights) may not be possible when negotiating with larger third parties, which may force such Covered Entities to use less reputable vendors. Moreover, some third parties that engage in penetration testing force firms to disclaim liabilities associated with such tests; and
- The requirement that a Covered Entity designate a CISO (a) does not accommodate other titles that might already exist within a firm that fulfill the same functions as a CISO and (b) does not recognize how certain firms have information systems governed by the CISO of an affiliate or a subsidiary. Additionally, the requirement that the CISO present a report bi-annually to the Covered Entity’s board (and if no such board exists, to a senior officer responsible for the Covered Entity’s cybersecurity program), and to the DFS superintendent upon request, may necessitate creation of a new team to comply with this requirement.
We will continue to monitor and report on developments concerning the Proposal.