Our Privacy, Cyber & Data Strategy Team highlights the increasingly specific cybersecurity controls identified by regulators, explains why these enhanced cybersecurity controls have become the focus of regulators, and shares practical tips for companies navigating this rapidly evolving territory.
- At the state and federal levels, regulators expect companies to adopt phishing-resistant multi-factor authentication
- Regulators’ training requirements are shifting from standard “off the shelf” security awareness programs to multifaceted models that include role-based training
- Going forward, one of the more challenging enhanced controls for companies is to develop and maintain a comprehensive, up-to-date asset and software inventory
In recent years, U.S. state and federal regulators have increasingly emphasized, both through guidance and enforcement actions, cybersecurity controls that are more prescriptive and rigorous to reflect the evolving cyber-threat landscape and technological advancements.
The days of regulators requiring companies to have basic security controls in place, such as antivirus software, a written information security program, annual security awareness training, and general updates to the board on the cybersecurity program, are long gone. Now, federal and state regulators alike, such as the Federal Trade Commission (FTC), Federal Communications Commission, U.S. Department of Health and Human Services (HHS), the New York Department of Financial Services (NYDFS), and the Office of the Attorney General of the State of New York (NYOAG), to name just a few, have signaled heightened expectations.
Some of the new prescriptive cybersecurity requirements these regulators have started to require include implementing phishing-resistant multi-factor authentication (MFA), developing and maintaining a comprehensive, up-to-date asset and software inventory (including tracking any end-of-life (EOL) products), reporting on the cybersecurity program to the board more frequently and with greater specificity, mandatory encryption of personal information, developing and maintaining a data map, and enhanced logging and monitoring measures on not just the company’s information systems but also its third-party service providers’ or vendors’ information systems.
Phishing-Resistant Multi-Factor Authentication
If there is one specific cybersecurity control that regulators universally endorse and require, it is MFA. This is not new; cyber-regulators have continuously emphasized the need for MFA to mitigate cybersecurity events. MFA, at its core, requires at least two authentication factors to successfully authenticate the user, and those factors typically involve: (1) something you know (such as a password); (2) something you have (such as a token); and (3) something you are (such as biometric features, like your fingerprint or facial scan). MFA comes in different forms, though, and each presents unique risks, particularly under the traditional MFA model.
For example, a possession factor (i.e., something you have) could require a user to enter a token, which could take the form of a one-time password (OTP) generated by a hardware or software device or sent to an individual via SMS or email. OTPs can be vulnerable to SIM-swapping, which allows a criminal to steal a victim’s phone number and then steal any MFA codes delivered to the victim’s phone.
Alternatively, a possession factor could require a user to approve a push notification via an on-screen prompt, such as through a mobile application on the user’s mobile phone (push-based MFA). Push-based MFA can be particularly susceptible to human error because inattentive users may accept the push notification on their phone inadvertently or, sometimes, intentionally when they feel bothered by multiple push requests. In fact, cyber-criminals such as Scattered Spider have used tactics such as “push bombing” to bypass MFA protocols. Push bombing involves an unauthorized party obtaining the user’s username and password and using those credentials to cause the MFA push notification to occur multiple times until the legitimate user approves the request. By then bypassing MFA, the unauthorized party can access the company’s systems.
Recognizing push-based MFA’s vulnerabilities, the NYDFS released guidance indicating that they have seen “several [c]ybersecurity [e]vents where inattentive users allowed cybercriminal[s] to gain access to the user’s account.” As cyber-criminals become more sophisticated, these traditional forms of MFA may continue to become less effective and more prone to phishing attacks.
Due to these potential vulnerabilities (just as the public has gotten used to MFA as the “new normal”), regulators are increasingly pushing companies to shift to phishing-resistant MFA, which typically involves the possession and inherence factors and aims to eliminate or minimize the use of the knowledge factor, which is generally considered the most susceptible factor. The goal of phishing-resistant MFA is preventing the attacker from easily bypassing MFA to gain access to a user’s account – even if the user was socially engineered into clicking a malicious link or file in a phishing email.
To highlight the enhanced security of phishing-resistant MFA, consider the “possession” factor – specifically, this example uses hardware security keys.
Under traditional MFA, a hardware security key generates an OTP (think of the old RSA SecureID key fobs). Users can be tricked into providing the OTP because actual possession of the key by the unauthorized party is not required as part of the authentication process.
In contrast, a hardware security key under the phishing-resistant MFA model relies on cryptographic authentication (such as FIDO2) that cannot be phished or intercepted and requires actual possession of the hardware device. FIDO2, for example, uses public key cryptography to authenticate users, a public key is stored on the service provider’s server, and the private key is stored on the user’s device. So, if the attacker gains access to the service provider’s server, they would not be able to replicate the private key and thus gain access to the user’s account. And even if the attacker obtained physical possession of the FIDO2 device, most FIDO2 devices require the user to physically interact with the key – for example, by providing a fingerprint or entering a PIN. In fact, a FIDO2 key that incorporates a fingerprint scanner for authentication is a strong example of phishing-resistant MFA. So, in this example, the user would first plug their FIDO2 device (typically via USB) into their workstation or tap the FIDO2 key to the NFC-enabled device (possession factor) and then provide their fingerprint on the FIDO2 key (inherence factor).
A major shift toward phishing-resistant MFA was seen in 2022 in a memorandum by the Office of Management and Budget (OMB). In that memorandum, all government agency staff, contractors, and partners were required to implement phishing-resistant MFA. The OMB indicated that phishing-resistant MFA is necessary because these identified users “are among the most valuable targets for phishing” and the problem can be “mitigated by providing users with phishing-resistant tokens.”
Further, in a recent proposed settlement between the FTC and GoDaddy Inc., the FTC required the domain registry company to implement at least one MFA method for all employees, staff of contractors, and third-party affiliates. However, the implemented MFA cannot be standard, but instead, the MFA “must be resistant to phishing attacks” and cannot include authentication methods based on telephone calls or SMS. Similarly, in both In the Matter of Chegg Inc. and In the Matter of Drizly LLC, the FTC required the companies to implement phishing-resistant MFA as part of its orders.
More recently, the FTC’s Office of Technology and Division of Privacy and Identity Protection highlighted ways to deter and reduce systemic risks related to digital security. According to FTC staff, “requiring phishing-resistant multifactor authentication for employees, such as security keys instead of numeric codes or push notifications” can mitigate security risks. These actions and statements from the FTC, as well as other statements from agencies such as the CISA, demonstrate a shift from encouraging organizations to use standard MFA tools to now encouraging, or in some instances requiring, the use of enhanced, phishing-resistant MFA tools. Although not required by any specific statutory authority, organizations should take note and consider implementing phishing-resistant MFA tools when appropriate.
Just like OTP and push-based MFA, phishing-resistant MFA is not foolproof, and we are already seeing cyber-criminals get around these enhanced authentication controls. For example, deepfakes, which are highly realistic synthetic media generated by artificial intelligence (AI), can be used to create fake biometric data that minimizes the usefulness of the inherence factor. As deepfakes are becoming more sophisticated, it is increasingly difficult for systems to distinguish the deepfake from the genuine identity.
Security Awareness Training
Companies have come to realize the importance of conducting routine security awareness training for all employees. However, as we see a continued evolution of cybersecurity threats based on social engineering, it is not unexpected that cyber-training may need to evolve as well. Indeed, regulators are shifting away from requiring standard security awareness training to requiring a multifaceted training model that includes exercises that go into greater depth, as well as tailored trainings based on the employee’s role.
For example, the NYDFS has implemented in its new regulations multiple new security awareness training requirements. One of these new requirements includes providing “cybersecurity training that includes social engineering.” (NYDFS § 500.14). This demonstrates a shift from basic training modules to more-in-depth simulation-based training. The NYDFS recently emphasized the importance of cybersecurity training, specifically simulated phishing training exercises, to help cybersecurity personnel understand how attackers are using AI in social engineering attacks, as we discussed in our October 24, 2024 advisory.
To cite another example, pursuant to NYDFS § 500.10, covered entities must provide sufficient training addressing the relevant cybersecurity risks to all cybersecurity personnel. Requiring “role-based” employee training demonstrates another move from the one-size-fits-all training approach that many companies currently conduct. In addition to these new requirements from the NYDFS, the NYOAG entered into an assurance of discontinuance (AOD) with a large insurance company after the insurance company experienced a cybersecurity event. Pursuant to the AOD, the insurance company is required to provide specific training to “personnel within [the insurance company]’s corporate family who develop software used by or on behalf of [the insurance company]” that covers “Private Information, how such information can be used for fraud, and [the insurance company]’s procedures, guidelines, and standards for protecting such information.”
To be sure – companies should still be providing security awareness training to all employees regardless of the employees’ roles. However, companies may want to consider requiring more advanced training modules as well as evaluate the level of unique risk various roles within the company presents and adjust the security awareness training to correspond to that level of risk. Indeed, it is not uncommon in regulatory investigations for the regulator to seek specific details on cybersecurity training, including whether particular groups (such as developers) receive role-specific training beyond the standard cybersecurity training and its relative rate of completion across the enterprise.
Asset Inventory and End-of-Life Management
One of the more challenging requirements that regulators are increasingly expecting is maintaining a comprehensive, up-to-date asset and software inventory. As staked out by the regulators, for a company to protect its information systems and data, it’s critical that the company understands the full scope of assets, where they are located, the type of asset, and the data it maintains or has access to. In particular, by maintaining a comprehensive inventory, a company can know exactly where its assets and software reside, which in turn allows a company to protect their systems appropriately. If a company is not aware of certain assets being part of its network, it would be difficult to apply appropriate security controls to those systems.
Additionally, maintaining an inventory allows a company to properly manage EOL products, which are those being discontinued and no longer supported by the manufacturer. However, developing and maintaining an updated inventory of hardware and software is much easier said than done since companies’ networks are fluid and hardware and software are frequently changing, whether through acquisition, licensing, or otherwise. It can be particularly challenging for large, multinational organizations, given the volume of assets and software, inherent geographic diversity of the organization, and the number of individuals needed to comply with and effectuate an asset inventory policy.
In another recent AOD, with a biotechnology company, the NYOAG required the company, in part, to “maintain and regularly update an inventory that appropriately identifies all assets containing Consumer Personal Information.” The connection between these data inventory requirements and the specific facts of the incident is not immediately apparent from the face of the AOD, suggesting the NYOAG may be staking out new territory in its position of what it expects companies to be doing going forward.
Further, these new inventory requirements are now being proposed within the health care sector as well. HHS has proposed a new rule requiring covered entities to “maintain an accurate and thorough written inventory … of the … electronic information systems and all technology assets that may affect the confidentiality, integrity, or availability of electronic protected health information.” The proposed rule extends the inventory requirement of covered entities to include assets used by business associates to “create, receive, maintain or transmit [electronic protected health information].” Thus, a business associate’s assets must be included in the network map and/or inventory of the covered entity.
Certainly, one benefit to maintaining these inventories is the ability to better manage EOL assets and software. Other than EOL products causing system performance issues, according to the CISA, “continued use of EOL software poses consequential risk to [an organization’s] system that can allow an attacker to exploit security vulnerabilities.” The CISA, for instance, recommends that users and administrators retire all EOL products. Regulators seem to agree with the CISA’s assertions because both the NYOAG and FTC recently required respondents to replace or disconnect assets and software that are categorized as EOL.
In Marriot International’s final order with the NYOAG, Marriott not only agreed to implement and maintain scanning or equivalent tools to regularly inventory and classify IT assets, the company additionally agreed to either timely replace any software reaching its EOL or implement compensating controls. Similarly, in the FTC’s proposed settlement with GoDaddy, GoDaddy is required to disconnect all EOL hardware assets and software, and if it is infeasible to do so, temporarily implement appropriate controls to mitigate threats and document a plan to disconnect the EOL assets or software.
In addition to the NYOAG and the FTC, the NYDFS requires covered entities to address EOL management. Pursuant to 23 NYCRR 500.3(c), a covered entity’s cybersecurity policies and procedures must address, at a minimum and among other things, an “asset inventory, device management and end of life management.” Notably, the NYDFS does not elaborate on the exact method for conducting EOL management. In fact, the NYDFS is not requiring covered entities to develop and maintain inventories until November 1, 2025, which is the latest date of effect of any of the new provisions within the department’s revisions to its cybersecurity regulation. This later date may indicate an understanding of how great an undertaking it could be for companies to develop inventories.
Although it appears that regulators are shifting toward requiring entities to maintain various inventories, this is no simple task. Developing and maintaining asset and software inventories can be quite challenging for all companies, regardless of size, but may be more challenging for companies with dynamic IT environments and complex networks. When a company has an evolving IT environment or a complex network, it is not difficult to see how maintaining inventories to demonstrate the current status of the ever-changing or complex environment would be onerous at best. Another potential factor that may impact a company’s ability to develop and maintain an adequate inventory is the diversity of the asset pool. Most companies have a multitude of different assets such as virtual and physical servers, cloud-based assets, laptops, BYOD devices, desktops, and different network connections, making it a monumental (and sometimes seemingly impossible) task to map all assets out into a single inventory. In addition to a company having an already difficult time keeping track of all the assets and software knowingly used by the company, employees also may be using “shadow IT,” which includes any software or hardware used by employees without the IT department’s approval or knowledge. These factors are just a few that may cause difficulties in implementing and developing such inventories.
Logging and Monitoring
As in other areas, regulators are becoming increasingly demanding about the level of monitoring and logging they expect to see from companies, regardless of size or complexity. For instance, in the AOD with the biotechnology company, the NYOAG required the company to log and monitor “all security and operational activity related to [the company’s] networks, systems, and assets” and maintain a system that provides for centralized logging with aggregation of logs. On the one hand, centralized logging of all logs for large enterprises could be exceptionally difficult (and expensive) to maintain given the volume alone, not to mention the diversity of logs needed to be ingested into a company’s centralized logging tool, such as a security information and event management (SIEM) tool. On the other hand, for smaller companies, the cost of a centralized logging system could be prohibitive (or unnecessary) if there are relatively few systems that the company monitors. This new requirement outlined by the NYOAG’s AOD with the biotechnology company likewise presents a number of questions, including what types of logs – network logs, operating system logs, firewall logs, authentication logs, activity logs, etc. – are required to be ingested into the SIEM and monitored.
As regulators’ expectations of cybersecurity controls expand, companies should consider staying abreast of regulatory actions and guidance and key areas of focus for regulators, and, in turn, enhancing cybersecurity controls and practices, as appropriate.
