The New York DFS Issues Guidance on Multifactor Authentication

On December 7, 2021, the New York Department of Financial Services (“DFS”) released new guidance on multifactor authentication (“MFA”), indicating that it is increasing its review of MFA during examinations, with a particular emphasis on probing for the common MFA failures discussed below. The DFS issued the Guidance in response to rising cybersecurity threats and exploitation by threat actors of inadequate MFA controls.

Growing Importance of MFA to Cybersecurity Compliance

According to the DFS, MFA weaknesses are the most common cybersecurity gap exploited at financial services companies. From January 2020 to July 2021, 64% of entities regulated by DFS that reported a cybersecurity incident had some sort of gap in MFA, and over 18.3 million consumers were impacted by cybersecurity incidents reported to the DFS by companies with MFA failures.

Section 500.12(b) of the DFS Part 500 Cybersecurity Regulation (“Part 500”) requires covered entities to implement MFA for any individual accessing the covered entity’s internal networks from an external network unless the covered entity’s CISO has approved in writing the use of reasonably equivalent or more secure access controls. Part 500.1 defines MFA as authentication through verification of at least two of the following types of authentication factors:

1. knowledge factors such as a password;
2. possession factors such as a token or text message on a mobile phone; or
3. inherence factors such as a biometric characteristic.

As we discussed earlier this year, the DFS has imposed significant penalties against companies for failing to implement MFA. MFA for remote access is also top priority for other regulators including the SEC and the FTC.

Common MFA Violations and How to Prevent Them

The Guidance highlights five common MFA failures that the DFS views as violations of Section 500.12(b):

1. Legacy Systems That Do Not Support MFA: Some applications and systems either do not support MFA or allow traditional non-MFA authentication. Companies that have migrated from traditional authentication to MFA must remember to disable their legacy authentication systems. Companies should consider keeping inventories of all IT assets so that outdated systems are appropriately decommissioned.
2. Remote Access Coverage Failures: Although most virtual private network (“VPN”) services require MFA, some applications and cloud-based O365 and G-Suite services do not require MFA for remote access. Companies should ensure that applications and systems that can be remotely accessed without authenticating through a VPN have MFA in place.
3. Third-party Access to Internal Networks: The Guidance notes that many companies with third-party portals and applications have fallen victim to credential stuffing and phishing attacks because the companies did not require third parties to use MFA when accessing their internal networks. Companies should require MFA (or the use of reasonably equivalent controls) for all third parties accessing their networks. This includes independent insurance agents who have access to sensitive consumer information provided to the company.
4. Incomplete MFA Rollout: Care must be taken during MFA rollouts to ensure full compliance. When MFA setup is left to individual users, some never enable it. Also, attackers have exploited MFA “self-setup” to enable MFA that they control. Regulated entities should track and enforce compliance with the MFA requirements. In addition, if there are long gaps in MFA coverage during rollouts or transitions, compensating controls should be implemented.
5. Unjustified MFA Exceptions: The Guidance notes that some cyber incidents resulted from exceptions to MFA policies that were granted to select users, such as senior executives, who did not want the hassle of having to use MFA. The Guidance provides that MFA exceptions should be granted sparingly, tracked, and last only as long as necessary, and that “exceptions should not be granted based on the seniority or unwillingness of the user.” Under Section 500.12(b), covered entities must require MFA for remote access unless their CISO has approved in writing the use of reasonably equivalent or more secure access controls.

Other MFA Considerations

In addition to the violations discussed above relating to remote access under Section 500.12(b), the Guidance provides additional considerations for companies using MFA as part of other risk-based access controls required by Sections 500.12(a) and 500.3 of Part 500.

• MFA for Privileged Accounts: The Guidance notes that in every case where cybercriminals escalated privileges during an incident reported to the DFS, the privileged account lacked MFA. As discussed in the Ransomware Guidance that it released in June, the DFS believes that all logins to privileged accounts, whether remote or internal, should require MFA because it provides a highly effective way of blocking privilege escalation via password cracking. The DFS Ransomware Guidance also urged companies to disable Remote Desktop Protocol (“RDP”) access from the Internet wherever possible, noting that, if after assessing the risk, RDP access is deemed necessary, then access should be restricted to only approved (whitelisted) originating sources and require MFA as well as strong passwords.  Similarly, the FBI and the Cybersecurity & Infrastructure Security Agency (“CISA”) recently issued guidance recommending that businesses implement MFA for administrative accounts to defend against cyberattacks during the holiday season.
• Best Practices for MFA Controls: The Guidance also notes that some forms of MFA provide better protection than others. The DFS seems to prefer token-based MFA, where a device generates a one-time passcode that the user has to manually type into a browser or app. Push-based MFA, by contrast, merely requires a user to press a button in response to an on-screen prompt or an automated phone call. The DFS has seen inattentive users give cybercriminals access to their accounts by thoughtlessly authenticating push-based MFA. The Guidance also notes that text-based MFA is vulnerable because cybercriminals can switch a user’s phone number to a device controlled by the attacker (referred to as “SIM-swapping”), which enables the attacker to steal MFA codes sent to the phone number.
• The Need for Oversight: Finally, the Guidance provides that DFS-regulated entities should test their MFA implementation through audits, penetration tests, and vulnerability scans to verify the scope and strength of MFA controls, and that material weaknesses must be reported to the Board.

To subscribe to the Data Blog, please click here.

The authors would like to thank Debevoise Law Clerk Jacob Apkon for his contribution to this blog post.