This is the second post in our series of deep dives on the proposed NYDFS Cybersecurity Rule revisions (the “Proposal”). If you missed them, our launch post on the series is here, and our post on how the rules would alter your risk assessments is here.

The NYDFS proposed rules focus on your written policies and procedures and how they are approved. In a nutshell, NYDFS has expanded written policy and procedure coverage requirements to include end of life management, remote access, and vulnerability and patch management. In addition, as NYDFS makes clear in Section 500.3, high-level policies will no longer suffice. Rather, your team will have to record the details of what needs to be done, and how, in written procedures for the 15 required areas.

Importantly, Section 500.3 requires policies and procedures to be approved by the “senior governing body.”  This means the Board of Directors, unless the covered entity does not have a board of directors.  We will discuss the corporate implication of this requirement, as well as additional requirements of the Board and officers in a separate post. There are also technical requirements in the Proposal that we will discuss below.

New Policy and Procedure Requirements

In Section 500.5, covered entities are required to “develop and implement written policies and procedures for vulnerability management that are designed to assess the effectiveness of its cybersecurity program.” This wording is unusual.  How vulnerability management policies and procedures will be designed to “assess the effectiveness” of a cybersecurity program is unclear. Although this is discussed here under policies and procedures, implementing these requirements may require covered entities to procure new technologies or services in order to meet the specific requirements. The required vulnerability management policies and procedures must require that covered entities at a minimum (i) conduct penetration testing (both inside and outside their systems) by qualified personnel, (ii) periodically, and after major system changes, conduct automated scans of systems, and if automated scans do not cover certain systems, manual scans, (iii) have monitoring processes to promptly inform the covered entity of the emergence of new security vulnerabilities, (iv) prioritize and timely remediate vulnerabilities, and (v) document and report material issues found during testing to the Board of Directors and senior management.

Section 500.13 requires detailed policies and procedures for asset management. For each asset, the following information must be tracked: “(i) owner; (ii) location; (iii) classification or sensitivity; (iv) support expiration date; and (v) recovery time requirements.” Many companies do not track the internal “owner” of data, software or systems. Recovery time requirements will link to the business continuity and disaster recovery requirements detailed in Section 500.16 discussed below.  Most importantly, NYDFS in the EyeMed Consent Order, tied asset management to data minimization. They consider the requirement to appropriately manage assets to mean that data that is no longer needed must be securely destroyed.

Technical Requirements

Section 500.7 addresses Access Privileges. Aside from Business Continuity and Disaster Recovery, Access Privileges have the most significant new technical requirements. Note that while the requirements below are primarily technical, 500.7(b) requires the development and implementation of a password policy and procedures – unless the covered entity does not use passwords.  Covered entities must: (i) limit user access privileges, (ii) limit the number of privileged accounts (a definition of privileged accounts has also been added), (iii) limit the use of privileged accounts to only when performing functions requiring privileged access, (iv) at least annually, review user access privileges, (v) disable or securely configure remote device control protocols, and (vi) promptly terminate access following departures.  Class A companies are required to implement sophisticated privileged access management solutions and automated blocking of commonly used passwords for all accounts. Note that (iii) above may effectively require privileged access management systems, as smaller covered entities may not have easily feasible technical solutions.

Section 500.12 addresses Multifactor Authentication (“MFA”).  It is important to note that in Section 500.19(a), the exclusion of 500.12 for exempt entities has been removed.  This means that the full MFA requirements will apply to all covered entities.  MFA is one of the most important NYDFS requirements.  Numerous NYDFS consent orders cite the lack of MFA on systems.  Section 500.12 does recognize that alternatives to MFA may be implemented if they are reasonably equivalent or more secure.  In practice, NYDFS is skeptical of equivalents, and if the control fails, will likely claim that the compensating control was not adequate.  Additionally, NYDFS has made explicit that MFA is required for: “(1) remote access to the covered entity’s information systems; (2) remote access to third-party applications, including but not limited to those that are cloud based, from which nonpublic information is accessible; and (3) all privileged accounts.”

Section 500.14 adds a requirement for controls “that protect against malicious code, including those that monitor and filter web traffic and electronic mail to block malicious content.”  Additionally, security awareness training must include phishing training.  Class A companies are also required to implement endpoint detection and centralized logging and security event alerting.

Section 500.16 originally covered incident response plans.  In the proposal, it is being expanded to “plans that contain proactive measures to investigate and mitigate disruptive events and ensure operational resilience, including but not limited to incident response, business continuity and disaster recovery plans.”  When reading Section 500.16 , think of ransomware and other availability and integrity attacks.  Covered entities are going to need sophisticated business continuity and disaster recovery personnel or consultants.  Recovery time objectives (RTOs) and recovery point objectives (RPOs) will be needed, along with a keen understanding and documentation of risk appetite in order to design solutions that will demonstrate regulatory compliance – especially after an attack.  Technical solutions that enable the covered entity to recover from sophisticated integrity and availability attacks (think ransomware, but not only ransomware) must be implemented and regularly tested.  This will all be very complicated and expensive.  It will take a long time to implement and test.  Even though the Proposal has not been finalized, covered entities would do well to focus on compliance with this Section now.

If you have any questions about how your policies and procedures will need to change under the revised NYDFS Regulation, or questions about other privacy and data security issues, contact Rick Borden at (212) 705-4884 or rborden@fkks.com, Daniel Goldberg at (310) 579-9616 or dgoldberg@fkks.com, Saphya Council at (212) 826-5575 or scouncil@fkks.com, or any other member of the Frankfurt Kurnit Privacy & Data Security Group.