Updates and supplemental material to Chapter 9

Federal Cybersecurity Regulations and Guidelines

UPDATES TO SECOND EDITION

9.1 The NIST Framework

On February 26, 2024, NIST published version 2.0 of its Cybersecurity Framework

9.2 Sector-Specific Regulations and Guidelines

On November 7, 2024, the Transportation Security Administration published a major notice of proposed rulemaking to impose cyber risk management requirements on certain pipeline and rail owner/operators and a more limited requirement, on certain over-the-road bus (OTRB) owner/operators, to report cybersecurity incidents. Comments are due by February 5, 2025. The proposed rule would supersede the post-Colonial Pipeline directives described in the book.

9.2.4 Defense Contractors—Department of Defense 

On October 9, 2024, the DoD published a final rule adding to 32 C.F.R. (the DoD’s title in the C.F.R.) a new part 170 (re)establishing the Cybersecurity Maturity Model Certification (CMMC) Program (“the CMMC Program rule”).  As explained in the book, the goal of CMMC is to verify that DoD contractors and subcontractors have implemented required security measures to safeguard Federal Contract Information (FCI) and Controlled Unclassified Information (CUI).  An earlier effort to implement CMMC floundered over contractor opposition. This version is likely to stick.

As indicated in the rule’s preface, the beginnings of CMMC start with the November 2010, Executive Order 13556, Controlled Unclassified Information.  The intent of that order was to establish a uniform program for managing federal government information that was unclassified but still required safekeeping. That then led to a program of requiring contractors to protect FCI and CUI information when they receive it for purposes of performing government contracts. Initially, DoD contractors were required to self-attest to their security. In 2019, DOD outlined CMMC as a system of “assessments” based on a tiered model of security controls. In the interim years, CMMC evolved into a four tiered system, now embodied in 32 C.F.R. Part 170. Contractors at Tier 1 and “Tier 2 (Self)” will be required to self-assess their adherence to certain cybersecurity controls, those at “Tier 2 (C3PAO)” will be required to undergo an assessment by a third party (known as a CMMC Third-Party Assessment Organization (C3PAO)), and those at Tier 3 will be assessed by the government itself, through the Defense Contract Management Agency (DCMA) Defense Industrial Base Cybersecurity Assessment Center (DIBCAC). Once CMMC is implemented, the required CMMC level and assessment type will be specified in the solicitation and resulting contract. The DoD estimates that 8350 medium and large entities will be required to meet CMMC Level 2 C3PAO assessment requirements. The program will be implemented over a 4 year period. Part 170 details out how the system of self- and third-party assessments will work.

The CMMC Program rule was published in the Federal Register on October 15, 2024, which means it takes effect on December 16, 2024. However, full implementation of CMMC (beginning with the designation of what tier of controls and assessment is required for any given contract) cannot begin until the DoD finalizes a second rule, a new Part 204 (“the CMMC Acquisition rule”), to be added to 48 C.F.R., the Defense Federal Acquisition Regulation Supplement (DFARS). A draft of that amendment to 48 C.F.R. was published in August, 2024. The August proposal had two major parts: proposed amendments to 48 C.F.R. Part 204, defining policies and procedures for including CMMC level requirements in DoD contracts (thus telling DoD contracting officers when and how they must use Clause 252.204-7021), and proposed amendments to Clause 252.204-7021, Contractor Compliance with the Cybersecurity Maturity Model Certification Level Requirements, which would actually bind contractors (telling contractors what they must do as a condition of contract award). Comments on the 48 C.F.R. proposal were due on October 15, 2024.

Recall that DFARS clause 252.204-7012, Safeguarding Covered Defense Information and Cyber Incident Reporting, which levies cybersecurity requirements on contractors based on NIST SP 800-171, has been in effect since 2017. Until the rulemaking process for CMMC is finalized, covered defense contractors are still required to self-assess compliance with 800-171.

In May, 2024, the National Institute of Standards and Technology issued an updated version of 800-171, in two publications: Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations (NIST Special Publication [SP] 800-171, Revision 3), and its companion, Assessing Security Requirements for Controlled Unclassified Information (NIST SP 800-171A, Revision 3). As before, the requirements in 800-171r3 are derived from the controls in NIST SP 800-53. The third revision added some new controls, removed others, and combined some. Superficially, it reduced the total number of controls from 110 in Revision 2 to 97 in Revision 3. However, because of the way multiple requirements are combined under one “control,” the number of requirements in revision 3 actually increased. A major change with Revision 3 is the introduction of “organization-defined parameters” (ODPs), which are bracketed items where contracting entities must fill in their own specifics. For example, Control 03.01.01.h, on account management, provides that contractors must “Require that users log out of the system after [Assignment: organization-defined time period] of expected inactivity or when [Assignment: organization-defined circumstances],” meaning that the procuring entity (delimited at what level remains to be seen) must fill in the details.

Since DFARS clause 252.204-7012 normally requires contractors to comply with the version of NIST SP 800-171 in effect at the time the solicitation is issued, meaning that Revision 3 would have taken effect immediately, DoD issued a “class deviation” allowing contractors to continue complying with NIST SP 800-171 Revision 2 until further notice.

9.2.10.4 Consumer Financial Protection Bureau [New Subchapter]

On October 22, 2024, the CFPB issued a detailed final rule intended to spur development of an “open banking” system as contemplated under Section 1033 of the Consumer Financial Protection Act. The rule is intended to allow consumers to more easily move their banking and other financial data—and their financial services business—from one provider to another, including through the use of third-party intermediaries. The rule includes data security clauses that extend the GLBA safeguards rule of the Federal Trade Commission to any “data provider” or third party. Data provider is defined as a financial institution, as defined in Regulation E, 12 CFR 1005.2(i); a card issuer, as defined in Regulation Z, 12 CFR 1026.2(a)(7); or any other person that controls or possesses information concerning a covered consumer financial product or service that the consumer obtained from that person, such as a digital wallet provider. As a result, some entities not previously covered by GLBA may now become subject to the FTC safeguards rule.

 9.2.11 Government Contractors, Federal—Federal Acquisition Regulation

See update to 9.2.4 for links to the revised NIST SP 800-171 and 800-171A, which apply to civilian as well as DoD contracts.

On March 11, 2024, CISA and the Office of Management and Budget (OMB) released the Secure Software Development Attestation Form, required under the OMB’s September 2022 memorandum and EO 14028 for companies selling software products to the U.S. government. Executive Order 14028, “Improving the Nation’s Cybersecurity,” required OMB to create an attestation process for software procured by the federal government. The process was further defined by OMB Memorandum M-22-18, “Enhancing the Security of the Software Supply Chain through Secure Software Development Practices,” as amended by OMB Memorandum M-23-16, “Update to Memorandum M-22-18, Enhancing the Security of the Software Supply Chain through Secure Software Development Practices.”

In September 2023, the Department of Defense, the General Services Administration, and the National Aeronautics and Space Administration proposed amendments to the FAR intended to implement sections of President Biden’s May 2021 EO 14028, Improving the Nation’s Cybersecurity, by strengthening and standardizing contract requirements for cybersecurity and by providing mechanisms to help ensure that entities or individuals that knowingly put U.S. information or systems at risk, by violating these cybersecurity requirements, are held accountable. The proposed rule would also implement OMB Memorandum M-21-07, Completing the Transition to Internet Protocol Version 6 (IPv6), dated November 19, 2020. https://public-inspection.federalregister.gov/2023-21328.pdf

9.2.12 Health Care Industry—Department of Health and Human Services

In December of 2023, HHS released a Department-wide cybersecurity strategy for the health care sector. Among other things, it indicated that HHS, through CMS, would impose cybersecurity requirements on hospitals reeiving payments under Medicare and Medicaid. Under the proposed provisions, hospitals will be required to establish a cybersecurity program and take proven steps to assess internal and external cybersecurity risks, use defensive techniques and infrastructure, implement measures to protect their information systems from unauthorized access or other malicious acts, and take actions to prevent cybersecurity events before they happen.

9.2.12.1 The HIPAA Security Rule

In February 2024, the HHS Office for Civil Rights (OCR) and the National Institute of Standards and Technology (NIST) issued Special Publication (SP) 800-66 Revision 2, Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule: A Cybersecurity Resource Guide 

In January 2024, HHS issued voluntary performance goals to enhance cybersecurity across the health sector. The publication provides an overview of the HIPAA Security Rule, strategies for assessing and managing risks to electronic protected health information (ePHI), suggestions for cybersecurity measures and solutions that HIPAA covered entities and business associates might consider as part of an information security program, and resources for implementing the Security Rule. Specific topic areas include:

  • Explanations of the HIPAA Security Rule’s Risk Analysis and Risk Management requirements.

  • Key Activities to consider when implementing Security Rule requirements.

  • Actionable steps for implementing security measures.

  • Sample questions to determine adequacy of cybersecurity measures to protect ePHI.

In addition to the publication itself, NIST has also provided supplementary content on its website to further assist HIPAA-covered entities and business associates with strategies to improve their cybersecurity in specific areas including:

  • Telehealth/Telemedicine

  • Mobile Device Security

  • Ransomware & Phishing

  • Medical Device Security

  • Cloud Services

  • Internet of Things Used in Healthcare

  • Application Security

  • Supply Chain

NIST also updated its Cybersecurity and Privacy Reference Tool (CPRT). The CPRT shows HIPAA Security Rule regulations with links to additional NIST tools.

OCR also maintains information on its website to assist regulated entities with their obligations to protect ePHI including HIPAA Security Rule Guidance Material and Cybersecurity Guidance Material.

9.2.14 Nuclear Power Plants—Nuclear Regulatory Commission

In February 2023, the U.S. Nuclear Regulatory Commission issued Revision 1 to Regulatory Guide (RG) 5.71, “Cyber Security Programs for Nuclear Power Reactors.” It provides NRC licensees with guidance on meeting the cyber security requirements described in section 73.54 of title 10 of the Code of Federal Regulations (10 CFR), “Protection of digital computer and communication systems and networks.”

9.2.18.1 Broker-Dealers, Investment Companies, and Investment Advisers

9.2.18.1.1 Securities and Exchange Commission

On May 16, 2024, the Securities and Exchange Commission finalized and adopted the amendments to Regulation S-P previewed in the book, covering broker-dealers (including funding portals), investment companies, registered investment advisers, and transfer agents (collectively, “covered institutions”). The amendments require covered institutions to develop, implement, and maintain written policies and procedures for an incident response program that is reasonably designed to detect, respond to, and recover from unauthorized access to or use of customer information.

The amendments also require that the response program include procedures for, with certain limited exceptions, covered institutions to provide notice to individuals whose sensitive customer information was or is reasonably likely to have been accessed or used without authorization. The amendments require a covered institution to provide notice as soon as practicable, but not later than 30 days, after becoming aware that an incident has occurred or is reasonably likely to have occurred. The notice must include details about the incident, the breached data, and how affected individuals can respond to the breach to protect themselves.

The amendments will become effective August 2, 2024 (60 days after publication in the Federal Register). Larger entities will have 18 months after the date of publication in the Federal Register to comply with the amendments, and smaller entities will have 24 months.

9.2.22 Telecommunications—Federal Communications Commission

In November 2023, the FCC adopted regulations designed to address two fraudulent practices bad actors use to take control of consumers’ cell phone accounts. In the Matter of Protecting Consumers from SIM Swap and Port-Out Fraud, Report and Order and Further Notice of Proposed Rulemaking (released Nov. 16, 2023). In the first type of scam, a bad actor convinces a victim’s wireless provider to transfer the victim’s mobile service and number from the victim’s cell phone to a cell phone in the bad actor’s possession. This is called “SIM swapping” because it involves an account being fraudulently transferred (or “swapped”) from a device associated with one subscriber identity module (SIM) to a device associated with a different SIM. In the second type of scam, the bad actor, posing as the victim, opens an account with a wireless provider other than the victim’s current provider. The bad actor then arranges for the victim’s phone number to be transferred (or “ported out”) to the account with the new wireless provider controlled by the bad actor. After completing either scam, the bad actor can use the phone to wreak havoc on a person’s financial and digital life. In response, the FCC revised its Customer Proprietary Network Information (CPNI) and Local Number Portability (LNP) rules to require wireless providers to adopt secure methods of authenticating a customer before redirecting a customer’s phone number to a new device or provider. See 47 C.F.R. § 64.2010. Safeguards on the disclosure of customer proprietary network information, and 47 C.F.R. § 52.37, Number Portability Requirements for Wireless Providers.  The Commission also required wireless providers to immediately notify customers whenever a SIM change or port-out request is made on customers’ accounts, and to offer all customers, at no cost, the option to lock or freeze their account to stop SIM changes and port-outs.

9.2.25 Welfare and Pension Benefit Plans—Department of Labor

In September 2024, the Employee Benefits Security Administration (EBSA) confirmed that the cybersecurity guidance referenced in the book, issued by EBSA in April 2021, generally applies to all employee benefit plans, including health and welfare plans. EBSA had found that health and welfare plan service providers were telling fiduciaries and EBSA investigators that the 2021 guidance only applied to retirement plans. Hence the September 2024 guidance, clarifying that the cybersecurity guidance applies to all types of ERISA plans, including health and welfare plans and all employee pension benefit plans.

____________________________________________________________________

SUPPLEMENTAL MATERIAL TO THE SECOND EDITION

9.2.10.1 Financial Institutions—FTC Safeguards Rule

The Safeguards Rule adopted by the FTC under GLBA, 16 C.F.R. Part 314, requires financial institutions to “develop, implement and maintain a comprehensive information security program.” 16 C.F.R. § 314.3. Section 314.4 goes on to specify that, in order to develop, implement, and maintain such a plan, entities shall:

(a) Designate a qualified individual to oversee, implement and enforce the information security program.

(b) Base the program on a risk assessment that identifies reasonably foreseeable internal and external risks to the security, confidentiality, and integrity of customer information and assesses the sufficiency of any safeguards in place to control these risks.

(c) Design and implement information safeguards to control the risks identified through the risk assessment. These must include access controls to authenticate and permit access only to authorized users; protect by encryption all customer information or use effective alternative compensating controls; implement multi-factor authentication unless the qualified individual overseeing the program has approved in writing the use of reasonably equivalent or more secure access controls; and implement policies, procedures, and controls designed to monitor and log the activity of authorized users and detect unauthorized access or use of, or tampering with, customer information. 

(d) Regularly test or otherwise monitor the effectiveness of the safeguards’ key controls, systems, and procedures. The monitoring and testing shall include continuous monitoring or periodic penetration testing and vulnerability assessments.

(e) Ensure that personnel are able to enact the information security program by, among other things, providing personnel with security awareness training that is updated as necessary and utilizing qualified information security personnel to manage information security risks and to perform or oversee the information security program.

(f) Oversee service providers, by:

(1) Taking reasonable steps to select and retain service providers that are capable of maintaining appropriate safeguards for the customer information at issue;

(2) Requiring your service providers by contract to implement and maintain such safeguards; and

(3) Periodically assessing service providers based on the risk they pose and the adequacy of their safeguards.

(g) Evaluate and adjust the information security program in light of the results of the testing and monitoring required by paragraph (d); any material changes to the entity’s operations or business arrangements; or any other circumstances that you know or have reason to know may have a material impact on your information security program.

(h) Establish a written incident response plan.

(i) Require the qualified individual to report in writing, at least annually, to the board of directors.

(j) Notify the FTC about acquisition of unencrypted customer information without the authorization of the individual to which the information pertains.

9.2.12.1 The HIPAA Security Rule

HHS has issued a number of guides and reports that, while non-binding, indicate what the agency expects of HIPAA-covered entities. The problem is there are many of them, compiled on at least three different webpages:

The HHS materials include:

  • HHS, Office of the National Coordinator for Health Information Technology, Security Risk Assessment Tool (version 3.2, 2020) https://www.healthit.gov/topic/privacy-security-and-hipaa/security-risk-assessment-tool, archived at https://perma.cc/JDK9-6Q6Q. The HIPAA Security Rule requires that covered entities conduct a risk assessment of their organizations. To assist covered entities in conducting such assessments, HHS developed a risk assessment tool. An updated version of the tool was released in September 2020. The tool diagrams HIPAA Security Rule safeguards and a framework that entities can use to document how they are implementing those safeguards to mitigate identified risks. 

  • Guidance on HIPAA and Cloud Computing (2016), https://www.hhs.gov/hipaa/for-professionals/special-topics/cloud-computing/index.html, archived at https://perma.cc/Z2WP-KTWH. In response to the widespread adoption of cloud computing, this guidance advises HIPAA-covered entities (including cloud services providers that may be covered business associates) how they can take advantage of cloud computing while complying with their HIPAA obligations to protect electronic health information.

  • Fact Sheet: Ransomware and HIPAA (undated) https://www.hhs.gov/sites/default/files/RansomwareFactSheet.pdf?language=es, archived at https://perma.cc/B4EL-YGHY.

  • OCR Cyber Awareness Newsletters. The OCR, which enforces HIPAA, issues a periodic newsletter to help HIPAA covered entities and business associates remain in compliance with the HIPAA Security Rule by identifying emerging or prevalent issues and highlighting best practices to safeguard PHI.

This can be quite overwhelming for providers seeking some definitive statement of what is legally required under the HIPAA Security Rule. To compound the problem, guidelines can become obsolete without express disavowal. For example, one of the HHS resources pages points to a HIPAA Security Toolkit Application, but upon navigating there one is informed that “the Toolkit is no longer supported, and is provided here only for historical purposes.” Where does that leave entities that previously relied on the toolkit? What has superseded it?

9.2.13 Medical Devices—Food and Drug Administration

The FDA has issued multiple documents containing cybersecurity guidance.

This guidance was influenced by EO 13636, which directed government agencies to work with industry stakeholders to enhance the cybersecurity and resilience of critical infrastructure, including the Healthcare and Public Health Critical Infrastructure Sector. The guidance specifically encourages the adoption and use of the voluntary NIST Framework for Improving Critical Infrastructure Cybersecurity, issued under EO 13636. An appendix specifically details how to align the five core functions of the NIST framework to management of cybersecurity in medical devices.

The guidance notes that the FDA’s Center for Devices and Radiological Health has entered into a Memorandum of Understanding with the National Health Information Sharing and Analysis Center in order to assist in the creation of an environment that fosters stakeholder collaboration and communication. The guidance states “The Agency considers voluntary participation in an ISAO [Information Sharing and Analysis Organization] a critical component of a medical device manufacturer’s comprehensive proactive approach to management of post-market cybersecurity threats and vulnerabilities and a significant step towards assuring the ongoing safety and effectiveness of marketed medical devices. For companies that actively participate in such a program, and follow other recommendations in this guidance, the Agency does not intend to enforce certain reporting requirements of the Federal Food, Drug, and Cosmetic Act (FD&C Act).”

The guidance also establishes a risk-based framework for assessing when changes to medical devices for cybersecurity vulnerabilities require reporting to the agency and outlines circumstances in which the FDA does not intend to enforce reporting requirements under 21 C.F.R. Part 806. (21 C.F.R Part 806 requires device manufacturers or importers to report promptly to FDA certain actions concerning device corrections and removals.)

  • Guidance for Industry: Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software (2005), archived at https://perma.cc/L9ZA-LAYG. From the introduction: “A growing number of medical devices are designed to be connected to computer networks. Many of these networked devices incorporate off-the-shelf software that is vulnerable to cybersecurity threats such as viruses and worms. These vulnerabilities may represent a risk to safe and effective operation of networked medical devices and typically require an ongoing maintenance effort throughout the product life cycle to assure an adequate degree of protection. The FDA is issuing this guidance to clarify how existing regulations, including the Quality System (QS) Regulation [21 C.F.R. Part 820], apply to such cybersecurity maintenance activities.” As part of QS (or “QSR”) design controls, a manufacturer must “establish and maintain procedures for validating the devices design,” which “shall include software validation and risk analysis, where appropriate.” 21 CFR § 820.30(g).

    The guidance is actually quite short, just 10 questions and answers. It emphasizes that device manufacturers need to be vigilant and responsive to cybersecurity vulnerabilities and that software changes to address cybersecurity vulnerabilities are design changes that must be validated before approval and issuance. It recommends that manufacturers develop a single cybersecurity maintenance plan.

In addition to these guidance documents, the FDA has issued other materials intended to assist industry. It is unclear whether the FDA would cite these in an enforcement action. See, for example, MITRE, Medical Device Cybersecurity Regional Incident Preparedness and Response Playbook (Oct. 2018) https://www.mitre.org/publications/technical-papers/mitre-creates-playbook-on-medical-device-cybersecurity, archived at https://perma.cc/B7GK-E38B. The playbook, prepared by The MITRE Corporation under contract with the FDA, outlines a framework for health delivery organizations and other stakeholders to plan for and respond to cybersecurity incidents around medical devices, ensure effectiveness of devices, and protect patient safety. It bears a caveat stating that “the views, opinions, and findings contained in this playbook do not constitute agency guidance, policy, or recommendations or legally enforceable requirements. Following the recommendations in this Playbook does not constitute compliance with any requirements of the Federal Food, Drug, and Cosmetic Act, or any other applicable law.”

9.2.18.1.1 Securities and Exchange Commission

SEC resources include:

  • Cybersecurity and Resiliency Observations (January 2020). Based on thousands of examinations of broker-dealers, investment advisers, clearing agencies, national securities exchanges and other SEC registrants, the SEC offered these “observations” on governance and risk management, access rights and controls, data loss prevention, mobile security, incident response and resiliency, vendor management, and training and awareness.

  • In April 2019, the SEC issued a Risk Alert providing a list of compliance issues related to Regulation S-P that had been identified in recent examinations of investment advisers and broker-dealers. SEC, Office of Compliance Inspections and Examinations, Investment Adviser and Broker-Dealer Compliance Issues Related to Regulation S-P—Privacy Notices and Safeguard Policies (Apr. 16, 2019) https://www.sec.gov/files/OCIE%20Risk%20Alert%20-%20Regulation%20S-P.pdf, archived at https://perma.cc/TY4J-U6TQ. The Risk Alert noted that some registrants did not have written policies and procedures as required under the Safeguards Rule and that others had written policies and procedures that contained numerous blank spaces. (!) The Risk Alert listed 10 areas in which deficiencies had been found:

°    Personal devices.

°    Electronic communications.

°    Training and monitoring.

°    Unsecure networks.

°    Outside vendors.

°   PII inventory.

°    Incident response plans.

°    Unsecure physical locations.

°    Login credentials.

°    Departed employees.

Critically, the Risk Alert focused not only on written policies, but also on implementation, indicating that SEC examinations would look behind the paper record to actual practices (for example, “the firm failed to monitor if the policies were being followed by employees,” “staff observed registrants that failed to require outside vendors to contractually agree to keep customers’ PII confidential,” “instances where former employees of firms retained access rights after their departure”).

  • In May 2019, the OCIE issued another Risk Alert focused on security risks associated with the storage of electronic customer records and information by broker-dealers and investment advisers in various network storage solutions, including those leveraging cloud-based storage. SEC, Office of Compliance Inspections and Examinations, Safeguarding Customer Records and Information in Network Storage—Use of Third Party Security Features (May 23, 2019) https://www.sec.gov/files/OCIE%20Risk%20Alert%20-%20Network%20Storage.pdf, archived at https://perma.cc/M24E-FMCH. In particular, the OCIE identified three concerns: misconfigured network storage solutions; inadequate oversight of vendor-provided network storage solutions; and insufficient data classification policies and procedures. The alert also provided examples of effective configuration management programs, data classification procedures, and vendor management programs.

  • A 2017 Risk Alert highlighted three practices that may be particularly relevant to smaller registrants in relation to the ransomware: cyber risk assessments; penetration tests; and sys­tem maintenance, including the installation of software patches. SEC, Office of Compliance Inspections and Examinations, Cybersecurity: Ransomware Alert (May 17, 2017) https://www.sec.gov/files/risk-alert-cybersecurity-ransomware-alert.pdf, archived at https://perma.cc/QFL5-F9LT.

  • After a number of public companies across numerous industries fell victim to business email compromise scams, losing millions of dollars each, the SEC’s Division of Enforcement investigated whether the firms may have violated the federal securities laws by failing to have a sufficient system of internal accounting controls. Report of Investigation Pursuant to Section 21(a) of the Securities Exchange Act of 1934 Regarding Certain Cyber-Related Frauds Perpetrated Against Public Companies and Related Internal Accounting Controls Requirements (October 16, 2018) https://www.sec.gov/litigation/investreport/34-84429.pdf, archived at https://perma.cc/UM6U-QQ8B. The commission decided not to pursue enforcement actions, but it issued a report on its investigation to make issuers and other market participants aware that these cyber-related threats of spoofed or manipulated electronic communications exist and should be considered when devising and maintaining a system of internal accounting controls as required by the federal securities laws.

9.2.22 Telecommunications - Federal Communications Commission

ARCHIVED UPDATES TO THE FIRST EDITION (last updated: December 7, 2022), INCORPORATED INTO THE SECOND EDITION

In August 2022, the Federal Trade Commission took the first major step towards adoption of a general cybersecurity regulation. See updates to Chapter 10 adding a new Chapter 10.4.10.

9.1 NIST Framework

Although, as the book states, the NIST framework is voluntary for private sector entities, President Trump’s May 2017 executive order on strengthening the cybersecurity of federal networks and critical infrastructure, EO 13800, required that, effective immediately, each agency head shall use the framework to manage the agency’s cybersecurity risk. 

9.2.1 Automobiles—National Highway Traffic Safety Administration

In September 2022, the U.S. Department of Transportation’s National Highway Traffic Safety Administration released Cybersecurity Best Practices for the Safety of Modern Vehicles, an update to its 2016 guidance. The non-binding document describes NHTSA’s guidance to the automotive industry for improving vehicle cybersecurity for safety.

[New subchapter:] 9.2.1A Bus Operators - Transportation Security Administration

In December 2021, TSA issued voluntary guidance for “Over-The-Road-Bus” owner/operators. Over-the-Road Bus means a bus characterized by an elevated passenger deck located over a baggage compartment. TSA, Surface Transportation IC 2021-01, Enhancing Surface Transportation Cybersecurity.

9.2.4 Defense Contractors—Department of Defense

The book describes a 2020 DoD initiative to move towards requiring contractors to obtain third-party certification of compliance with specific cybersecurity criteria, embodied in a system called Cybersecurity Maturity Model Certification (CMMC). In November 2021, in response to extensive contractor complaints, the DoD announced the broad outlines of a recalibration of the program. The revised program, CMMC 2.0, will –

  • reduce the number of security tiers from five to three;

  • reduce the number of security controls required of many companies and limit the controls to those in NIST SP 800-171 and its supplement SP 800-172 (CMMC 1.0 had augmented the 110 controls in SP 800-171 with an additional 61 controls);

  • allow all entities in the lower tier and some in the middle tier to self-assess compliance (as opposed to requiring all covered contractors to undergo third-party assessment);

  • for entities in the top tier, require governmental assessment rather than third-party assessment;

  • allow companies, under certain limited circumstances, to make Plans of Action & Milestones (POA&Ms) to achieve certification;

  • allow waivers to CMMC requirements under certain circumstances.

In December 2021, DoD published a revised CMMC Model Overview and Scoping Guidance and Assessment Guides for Levels 1 and 2. Further details and full implementation will await publication of amendments to Title 32 of the Code of Federal Regulations and the DFARS (Title 48 of the C.F.R.), which DoD said could take anywhere from 9 months to two years.

When initially announced in 2020, CMMC was not to be fully implemented until October 2025. While the November 2020 interim rule launching the program allowed inclusion of certification requirements in contracts before full implementation in 2025, it does not appear that CMMC third-party certification was ever included as a requirement in a solicitation or contract. (In other words, I don’t think clause 252.204-7021 was ever used.) The November 2021 announcement made it clear that no elements of the CMMC process will be included in any contracts until the rulemaking process is completed.

In terms of what controls are required, CMMC 2.0, like CMMC 1.0, relies on NIST SP 800-171, which specifies 110 security practices or controls. At the lowest level (Level 1), CMMC 1.0 and 2.0 are the same: they both incorporate the 17 controls drawn from SP 800-171 that are in FAR 52.204-21. (FAR 52.204-21 has 15 subsections, but one of them combines three controls; these were broken out separately in the CMMC, yielding 17 controls at the basic level in both 1.0 and 2.0.) At the middle tier for CMMC 2.0, as it was with the middle tier for 1.0, all 110 controls in SP 800-171 are supposed to be fully implemented. CMMC 1.0 had supplemented the SP 800-171 controls, resulting in a total of 130 controls at the mid-level, but 2.0 sticks with just the 110. At the top tier (Level 3), CMMC 2.0 will add some additional controls drawn from SP 800-172. (Under CMMC 1.0. the top tier had a total of 171 controls (the 110 in SP 800-171, plus the 20 added for its middle level, plus an additional 41.)

Version 1 of the CMMC is no longer available on the DoD website, but for anyone wishing to do a comparison, a copy is here. This comparison of NIST SP 800-171 and CMMC 1.0 is also very helpful, but only of historical interest.

Remember:  Despite the changes and delays in implementing CMMC, the DFARS clause 252.204-7012, Safeguarding Covered Defense Information and Cyber Incident Reporting, is included in all solicitations and contracts, including those using Federal Acquisition Regulation (FAR) part 12 commercial item procedures, except for acquisitions solely for commercially available off-the-shelf (COTS) items. The clause requires contractors to apply the security requirements of NIST SP 800-171 to “covered contractor information systems,” as defined in the clause (see the following paragraph), that are not part of an IT service or system operated on behalf of the Government. And the SP 800-171 DoD Assessment Methodology is still in place and DFARS clause 252.204-7020 still requires contractors to self-assess their compliance with NIST SP 800-171.

Further clarification: FAR 52.204-21 applies to contractor information systems that process, store or transmit “federal contract information” (FCI), defined as information not intended for public release that is provided by or generated for the government under a contract to develop or deliver a product or service. DFARS 252.204-7012 applies to contractor information systems that process, store, or transmit “covered defense information,” which is defined (paraphrasing here) as “controlled unclassified information” (CUI) that requires safeguarding or dissemination controls and is collected, developed, received, transmitted, used, or stored by or on behalf of the contractor in support of the performance of the contract. So CUI is a subset of FCI. See this short explanation from the Information Security Oversight Office in the National Archives. While DFARS 252.204-7012 imposes all 110 controls of SP 800-171 for all contracts involving CUI, FARS 52.204-21, for FCI, only requires compliance with a basic set of 17 controls drawn from SP 800-171. Under CMMC 2.0, Level 1 refers to those contracts that involve only FCI, while Levels 2 and 3 apply to contracts involving CUI.

9.2.5 Educational Institutions, Post-Secondary—Department of Education

In Dear Colleague Letter GEN-15-18 and GEN-16-12, the Office of Federal Student Aid (FSA) within the Department of Education reminded institutions about the longstanding requirements of GLBA and notified them of the office’s intention to begin enforcing the GLBA through annual compliance audits. In Dear CPA Letter CPA-19-01, the FSA explained the procedures for auditors to determine whether institutions were in compliance with GLBA.

9.2.7 Electric Power, Bulk Supply - Federal Energy Regulatory Commission

In January 2022, FERC issued a draft Notice of Proposed Rulemaking that proposes, pursuant to section 215(d)(5) of the Federal Power Act, to direct NERC to develop and submit for Commission approval new or modified Critical Infrastructure Protection (CIP) Reliability Standards that would require internal network security monitoring (INSM) for high and medium impact bulk electric system (BES) cyber systems. According to the notice, network security monitoring currently required under the CIP Reliability Standards focuses on preventing unauthorized access to BES cyber systems at the network perimeter, while INSM is applied within a “trust zone” and is designed to address situations where an attacker has already gained access to a system, with the aim of increasing the chance of early detection of malicious activity.

9.2.10.1 Financial Institutions—FTC Safeguards Rule

In October 2021, the FTC adopted the amendments to the GLBA Safeguards Rule mentioned in the book. The new rule is considerably more detailed in terms of the elements required in an information security plan. Among other things, regulated entities must:

  • Implement and periodically review access controls to (1) authenticate and permit access only to authorized users and (2) limit authorized users’ access only to customer information that they need to perform their duties and functions.

  • Inventory and manage data, personnel, devices, systems, and facilities.

  • Encrypt all customer information both in transit over external networks and at rest.

  • Adopt secure development practices for in-house developed applications that process customer information and procedures for evaluating, assessing, or testing the security of externally developed apps.

  • Implement multi-factor authentication for any individual accessing any information system or use other reasonably equivalent or more secure access controls.

  • Develop, implement and maintain procedures for the secure disposal of customer information no later than two years after the last date the information is used.

  • Adopt procedures for change management.

  • Monitor and log the activity of authorized users and detect unauthorized access or use of, or tampering with, customer information.

Details were also added to the requirement to test or otherwise monitor the effectiveness of key controls: For information systems, the monitoring and testing shall include continuous monitoring or periodic penetration testing and vulnerability assessments.

While the old rule said a regulated entity had to designate “an employee or employees” to coordinate its information security program, the new rule specifies that companies must designate a single “qualified individual” responsible for overseeing, implementing and enforcing their information security program. And under the new rule, the designated lead on cybersecurity must report to the board of directors at least annually.

In November 2022, the FTC extended by six months, to June 9, 2023, the deadline for companies to comply with many of the changes.

In an supplemental NPRM published on December 9, 2021, the FTC requested public comment on a proposal to further amend the Safeguards Rule to require a financial institution to report to the Commission any security event where the regulate entity has determined that misuse of customer information has occurred or is reasonably likely and at least 1,000 consumers have been affected or reasonably may be affected. Written comments were due by February 7, 2022.

9.2.10.3.1 Federal Financial Institutions Examination Council

In 2021, the FFIEC issued guidance titled Authentication and Access to Financial Institution Services and Systems. It sets forth risk management principles and practices that can support a financial institution’s authentication of (a) users accessing financial institution information systems, including employees, board members, third parties, service accounts, applications, and devices and (b) consumer and business customers authorized to access digital banking services. The 2021 guidance replaced the FFIEC-issued Authentication in an Internet Banking Environment (2005) and the Supplement to Authentication in an Internet Banking Environment (2011). Like much other cybersecurity guidance, it starts from the proposition that risk assessment (conducted prior to implementing a new financial service, as well as periodic risk assessments) should inform a financial institution’s decisions about authentication solutions and other controls that are deployed to mitigate identified risks. In other words, application of the principles and practices described in the guidance may vary at financial institutions based on their respective operational and technological complexity, risk assessments, and risk appetites and tolerances. With that caveat, the guidance lists 62 examples of practices or controls related to access management, authentication, and supporting controls, covering authentication, passwords, access and transactions, customer call centers and IT help desks, customers, logging and monitoring, systems access, privileged users, system and network design and architecture, email systems, and internet browsers.

One interesting point to note is the guidance’s evolving attitude toward multi-factor authentication. The 2005 guidance stated:

The agencies consider single-factor authentication [account # or username and password], as the only control mechanism, to be inadequate for high-risk transactions involving access to customer information or the movement of funds to other parties. … Where risk assessments indicate that the use of single-factor authentication is inadequate, financial institutions should implement multifactor authentication, layered security, or other controls reasonably calculated to mitigate those risks.

Note that layered security, such as the use of security questions, was recognized as suitable for high-risk transactions under this 2005 guidance, although it is not MFA. Note, too, that institutions’ security measures are dependent on their self-assessment of risk, and the guidance does not exactly define what is a high-risk transaction. Is every transaction that involves access to customer information or the movement of funds to other parties high risk?

By 2021, in recognition of the expanding attack surface and the evolving and increasingly sophisticated methods of attackers, the FFIEC concluded that “certain authentication controls, previously shown effective, no longer provide sufficient defense:”

Accordingly use of single-factor authentication as the only control mechanism has shown to be inadequate against these threats. Furthermore, single-factor authentication with layered security has shown to be inadequate for customers engaged in high-risk transactions and for high-risk users. When a financial institution management’s risk assessment indicates that single-factor authentication with layered security is inadequate, MFA or controls of equivalent strength as part of layered security can more effectively mitigate risks.

Note, again, how everything depends on a bank’s risk assessment. Note too, that the guidance does not specifically recommend MFA; it recommends “MFA or controls of equivalent strength.” And again, the guidance is circular on what constitutes high risk transactions: Transactions should be accorded more robust controls if they are “transactions that present higher risk of financial loss or potential breach of information for which enhanced authentication controls are warranted.”

The implication, though, is clear enough: a financial institution should take risk assessment seriously, and if it chooses not to require MFA, it should have a good reason.

9.2.11 Government Contractors, Federal – Federal Acquisition Regulation

On May 12, 2021, President Biden issued Executive Order 14028, Improving the Nation’s Cybersecurity, 86 Fed. Reg. 26633 (May 17, 2021). The order is much more detailed and technical than the average Executive Order. It directs officials throughout the executive branch to undertake scores of actions to improve the cybersecurity of federal systems, with varying deadlines. Many of these actions will deeply affect government contractors and their products and services. The EO also orders a variety of actions intended to reach beyond federal contractors. Different parts of the order address “systems that process data” (information technology or IT), systems “that run the vital machinery that ensures our safety” (operational technology or OT), information and communications technology (ICT) service providers, software, and cloud services and cloud service providers (CSPs).

Among the notable provisions of EO 14028 that will affect government contractors:

  • Data sharing: The Director of OMB will lead a process to amend the Federal Acquisition Regulation with contract language and requirements designed to ensure that providers of IT and OT service to the government collect and preserve data relevant to cybersecurity event prevention, detection, response and investigation and that they share cyberthreat and incident information with the government.

    • This includes “implementing technical capabilities, such as monitoring networks for threats in collaboration with agencies they support, as needed.”

  • Incident reporting: The Secretary of Homeland Security will lead a process to amend the FAR to include contract language that requires reporting of cyber incidents.

  • Cybersecurity requirements: The Secretary of Homeland Security will review agency-specific cybersecurity requirements that currently exist as a matter of law, policy, or contract and recommend to the FAR Council standardized contract language for appropriate cybersecurity requirements.  Such recommendations shall include consideration of the scope of contractors and associated service providers to be covered by the proposed contract language.

  • Zero Trust Architecture and cloud services: The order embraces Zero Trust Architecture and cloud services. The Secretary of Homeland Security, acting through CISA, shall develop security principles governing Cloud Service Providers (CSPs) for incorporation into agency modernization efforts; cloud-security technical reference architecture documentation; and a cloud-service governance framework.

  • Multi-factor authentication and encryption: Agencies shall adopt multi-factor authentication and encryption for data at rest and in transit.

  • Revamping FedRAMP: The Administrator of General Services is ordered to begin modernizing FedRAMP by, among other things, improving communication with CSPs through automation and standardization of messages at each stage of authorization, incorporating automation throughout the lifecycle of FedRAMP, including assessment, authorization, continuous monitoring, and compliance, and identifying relevant compliance frameworks that can be used as a substitute for the relevant portion of the authorization process.

The EO speaks broadly and in detail about enhancing software supply chain security. The order is directed specifically at the supply chain for software acquired by the federal government, but the forthcoming guidance may have a broader impact. And here’s what’s really important: Within one year of the date of the order, the Secretary of Homeland shall recommend to the FAR Council contract language requiring suppliers of software available for purchase by agencies to comply with, and attest to complying with, any requirements issued pursuant the supply chain security provisions of the EO. Thereafter, “agencies shall, as appropriate and consistent with applicable law, remove software products that do not meet the requirements of the amended FAR from all indefinite delivery indefinite quantity contracts; Federal Supply Schedules; Federal Government-wide Acquisition Contracts; Blanket Purchase Agreements; and Multiple Award Contracts.”

To develop such requirements, the EO requires the Director of NIST to adopt preliminary guidelines for enhancing software supply chain security and to publish guidance outlining security measures for critical software. It also requires the Secretary of Commerce, acting through the Director of NIST, to issue guidance identifying practices that enhance the security of the software supply chain.  Such guidance shall include standards, procedures, or criteria covering a wide range of topics related to secure software development, conformance the use of automated tools to maintain trusted source code supply chains and to check for vulnerabilities, providing purchasers with a Software Bill of Materials, and attesting to conformity with secure development practices.

The order has other provisions likely to have impact on federal contractors, including in products offered to non-government customers. For example--

  • The Secretary of Commerce acting through the Director of NIST shall publish guidelines recommending minimum standards for vendors’ testing of their software source code, including identifying recommended types of manual or automated testing (such as code review tools, static and dynamic analysis, software composition tools, and penetration testing).

Finally, the order has provisions directly aimed at consumer products: The Secretary of Commerce acting through the Director of NIST, in coordination with the Chair of the Federal Trade, shall identify IoT cybersecurity criteria for a consumer labeling program and secure software development practices or criteria for a consumer software labeling program.

Already, the EO is being implemented with –

Addition to fn 38: In January 2022, President Biden issued National Security Memorandum 8, further describing the authority of the National Security Agency with respect to national security systems. Among other things, the memo gave NSA the express authority to issue Binding Operational Directives to other defense and intelligence agencies, parallel to CISA’s authority for civilian systems.

9.2.12.2 HHS HIPAA Security Rule Guidance

In addition to the HHS resources, there is NIST Special Publication 800-66 Rev. 1, An Introductory Resource Guide for Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule (2008), which discusses security considerations and resources that may provide value when implementing the HIPAA Security Rule. In 2021, noting that cybersecurity resources have evolved since 2008, NIST initiated a process to revise the SP. Comments were due June 15, 2021.

9.2.12.3 Cybersecurity Guidance for the Health Industry Beyond HIPAA

In December 2021, HHS launched a new website for the 405(d) Program and Task Group. Some of the URLs provided in the book for 405(d) outputs no longer work, but all the items referenced in the book, including the HICP and Technical Volumes 1 and 2, are now compiled at https://405d.hhs.gov/public/navigation/resources.  The program issues an almost bewildering number of other resources, including a bi-monthly newsletter, a Spotlight series, a “That Seems Risky” series, a Myth Versus Fact series, a set of awareness products, and a series called Situation, Background, Assessment, Recommendation (SBAR), which had two items as of December 7. Everything under the 405(d) program is “voluntary,” but anything there could be cited by a plaintiff in a civil lawsuit--or possibly by a regulator--as indicative of a cybersecurity norm.

9.2.13 Medical Devices—Food and Drug Administration

In April 2022, to replace a never-finalized 2108 draft mentioned in the book, the FDA released a new draft guidance “Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions.” It is intended to supersede the 2014 guidance referenced in the book.

The new version, like the 2014 guidance and the 2018 draft, stresses that security is a matter of design that must be considered from the outset of a product’s development. (The word “design” appears 110 times in the new draft.) Building on references in the earlier versions, the new guidance highlights the need to address cybersecurity risks and mitigations throughout a product’s lifecycle. Like the 2018 version, for example, the new draft states that devices should be designed to facilitate the rapid patching and updating of deployed devices. (Patching was mentioned once in the 2014 version.) As in the 2018 draft, the new version emphasizes the theme of transparency, finding in the Food, Drug and Cosmetic Act an obligation to inform device users of relevant risks and security information. And like the 2018 version, the 2022 draft includes a long list of security controls, such as “Provide mechanisms for verifying the authenticity of information originating from the device” and “Implement design features that allow for security compromises and suspected compromise attempts to be detected, recognized, logged, timed, and acted upon during normal use.”

The document has evolved in notable ways. The new draft drops the 2018 version’s reliance on the NIST Cybersecurity Framework and instead introduces a new concept, Secure Product Development Framework (SPDF), as a way to achieve total product lifecycle considerations. The new version also drops an earlier two-tiered approach (“higher” and “standard”) to defining cybersecurity risk. It advances the use of multiple “architecture views” to communicate the threat model for a device from the perspective of different concerns. The new version replaces the 2018 concept of a Cybersecurity Bill of Materials with a Software Bill of Materials (SBOM), more narrowly defined to exclude hardware. Also, the new draft guidance gives more attention to vulnerability management, including the establishment of a coordinated vulnerability disclosure process and procedures for the communication of remediations, patches, and updates to customers.

9.2.14 Nuclear Power Plants—Nuclear Regulatory Commission

See also Nuclear Energy Institute, Identifying Systems and Assets Subject to the Cyber Security Rule (July 2012).

9.2.16 Pipelines—Transportation Security Administration

In May 2021, the Department of Transportation issued a directive requiring major pipelines  carrying petroleum products to review their current activities against TSA’s recommendations for pipeline cybersecurity to assess cyber risks, identify any gaps, develop remediation measures, and report the results to TSA and the Department of Homeland Security's Cybersecurity and Infrastructure Security Agency. Transportation Security Administration, Security Directive Pipeline-2021-1, Enhancing Pipeline Cybersecurity (May 28, 2022). See Jim Dempsey, Regulatory Alchemy: Turning Cybersecurity Guidelines Into Rules, Lawfare (June 1, 2021).

Based on responses to the May directive, the TSA issued a second security directive to pipelines in July 2021. The text of the directive, with a few redactions, is available here. It requires owners and operators of TSA-designated critical pipelines to implement specific mitigation measures to protect against ransomware attacks and other known threats to information technology and operational technology systems, develop and implement a cybersecurity contingency and recovery plan, and conduct a cybersecurity architecture design review.

9.2.17 Publicly Owned Companies – Securities and Exchange Commission

On March 9, 2022, the SEC proposed amendments to its rules to explicitly require certain disclosures by public companies regarding cybersecurity incidents, risk management, strategy, and governance. The proposed amendments would amend Form 8-K to require registrants to disclose information about a material cybersecurity incident within four business days after the registrant determines that it has experienced such an incident and would require periodic reporting to provide updates about previously reported incidents. The proposal also would require periodic reporting about a registrant’s policies and procedures to identify and manage cybersecurity risks; its board of directors' oversight of cybersecurity risk; and management’s role and expertise in assessing and managing cybersecurity risk and implementing cybersecurity policies and procedures. The proposal further would require annual reporting or certain proxy disclosure about the board of directors’ cybersecurity expertise, if any.

[New subchapter:] 9.2.17A Railroads - Transportation Security Administration

On December 2, 2021, DHS’s Transportation Security Administration issued two new Security Directives, effective December 31, 2021:

The two directives are essentially identical. Each requires covered entities to --

(1)   designate a cybersecurity coordinator who is available 24/7;

(2)  report cybersecurity incidents to the Cybersecurity and Infrastructure Security Agency (CISA);

(3)  develop a cybersecurity incident response plan;

(4)  conduct a cybersecurity vulnerability assessment using a form provided by TSA.

The incident reporting requirement got the most attention in the popular press. It requires reporting as soon as practicable, “but no later than 24 hours after a cybersecurity incident is identified.” A cybersecurity incident is defined as an event that jeopardizes, disrupts or otherwise impacts, or is reasonably likely to jeopardize, disrupt or otherwise impact, the integrity, confidentiality or availability of computers, information or communications systems or networks, physical or virtual infrastructure controlled by computers or information systems, or information resident on the system.  Elsewhere the directive states that this includes unauthorized access to an information or operational technology system, discovery of malicious software on an IT or OT system, or activity resulting in denial of service.

Perhaps equally if not more consequential is the requirement for a vulnerability assessment. Owner/operators “must identify remediation measures to address the vulnerabilities and cybersecurity gaps identified during the assessment and implement the plan for applying the identified measures.” The completed vulnerability assessment forms and remediation plans must be submitted to TSA by March 31, 2022. An awful lot turns on how TSA responds to the vulnerability assessments and remediation plans. A sign of its seriousness will be whether it sends any back for revision.

TSA also issued voluntary guidance for railroad owner/operators, public transportation agencies, and “Over-The-Road-Bus” owner/operators not otherwise covered under the two security directives. (Over-the-Road Bus means a bus characterized by an elevated passenger deck located over a baggage compartment.) TSA, Surface Transportation IC 2021-01, Enhancing Surface Transportation Cybersecurity.

9.2.18 SEC-Regulated Entities (Securities Exchanges, Broker-Dealers, Investment Advisers and Investment Companies)

In February 2022, the SEC proposed new rules under the Investment Advisers Act of 1940 and the Investment Company Act of 1940, focused on four elements: requiring advisers and funds to implement cybersecurity risk management policies and procedures; amending adviser and fund disclosure requirements to provide advisory clients and fund shareholders with improved information regarding cybersecurity risks and cybersecurity incidents; requiring advisers to report significant cybersecurity incidents to the Commission on a confidential basis; and new record-keeping requirements. The proposed risk management rules enumerate certain general elements that advisers and funds would be required to address in their cybersecurity policies and procedures, including risk assessment; access controls (such as procedures for the timely distribution, replacement, and revocation of passwords or methods of authentication); monitoring and other protections against unauthorized access; threat and vulnerability management (detecting, mitigating, and remediating threats and vulnerabilities); and incident response and recovery. Comments are due by April 11, 2022.

The SEC’s examinations and compliance priorities for 2022 again include cybersecurity. (In December, 2020, the OCIE, referred to in the book, became the Division of Examinations, referred to as EXAMS.)

Specifically, EXAMS will continue to review whether firms have taken appropriate measures to: (1) safeguard customer accounts and prevent account intrusions, including verifying an investor’s identity to prevent unauthorized account access; (2) oversee vendors and service providers; (3) address malicious email activities, such as phishing or account intrusions; (4) respond to incidents, including those related to ransomware attacks; (5) identify and detect red flags related to identity theft; and (6) manage operational risk as a result of a dispersed workforce in a work-from-home environment.

9.2.20A Substance Abuse Programs - Department of Health and Human Services

42 U.S.C. 290dd-2(g) authorizes the Secretary of Health and Human Services to prescribe regulations for the confidentiality of records of the identity, diagnosis, prognosis, or treatment of any patient which are maintained in connection with the performance of any program or activity relating to substance use disorder education, prevention, training, treatment, rehabilitation, or research, which is conducted, regulated, or assisted by any department or agency of the United States. The regulation is at 42 C.F.R. Part 2. Section 2.16 provides: “The part 2 program or other lawful holder of patient identifying information must have in place formal policies and procedures to reasonably protect against unauthorized uses and disclosures of patient identifying information and to protect against reasonably anticipated threats or hazards to the security of patient identifying information.”  For electronic records, these policies and procedures must address “(i) Creating, receiving, maintaining, and transmitting such records;​ ​(ii) Destroying such records, including sanitizing the electronic media on which such records are stored, to render the patient identifying information non-retrievable;​ ​(iii) Using and accessing electronic records or other electronic media containing patient identifying information; and(iv) Rendering the patient identifying information non-identifiable in a manner that creates a very low risk of re-identification (e.g., removing direct identifiers).”

9.2.24  Welfare and Pension Benefit Plans—Department of Labor

In April 2021, the Employee Benefits Security Administration in the U.S. Department of Labor issued guidance for plan sponsors, plan fiduciaries, record keepers, and plan participants on best practices for cybersecurity.  (The 2016 guidance was issued by an advisory council and thus was not, strictly speaking, a DoL product.) The EBSA guidance came in three parts:

  • Tips for Hiring a Service Provider: Intended to help plan sponsors and fiduciaries prudently select a service provider with strong cybersecurity practices and monitor their activities, as ERISA requires.

  • Cybersecurity Program Best Practices: Assists plan fiduciaries and record-keepers in their responsibilities to manage cybersecurity risks. The guidance identifies 12 areas requiring attention, many familiar from other guides. It says that plans should have a formal, well documented cybersecurity program, conduct prudent annual risk assessments, have a reliable annual third party audit of security controls, clearly define and assigned information security roles and responsibilities, have strong access control procedures, and implement and manage a secure system development life cycle program. Perhaps representing a newer generation of guidance, the EBSA document specifically calls out the need to ensure that assets or data stored in the cloud or managed by a third party service provider are subject to appropriate security reviews and independent security assessments.

  • Online Security Tips: Offers plan participants and beneficiaries who check their retirement accounts online basic rules to reduce the risk of fraud and loss.

Like other guidance, the EBSA documents are non-binding. The DoL, in releasing the guidance, did not specifically discuss enforcement.

[New subchapter:] 9.4 Standards for Industrial Control Systems

On July 28, 2021, President Biden signed a National Security Memorandum on Improving Cybersecurity for Critical Infrastructure Control Systems. The President’s move was unique in that it focused not on a sector but rather on a type of function: industrial control systems (ICSs). It has been recognized for some time that, throughout many otherwise distinct sectors, there are pieces of networked equipment that control physical assets (for example, turning valves on and off). Attacks on these systems can have catastrophic impact. The memorandum announced establishment of an Industrial Control Systems Cybersecurity Initiative, a voluntary, collaborative effort between the federal government and the critical infrastructure community to significantly improve the cybersecurity of these critical systems. It instructed DHS and NIST to develop and issue voluntary cybersecurity performance goals for critical infrastructure, beginning with preliminary goals for control systems across critical infrastructure sectors no later than September 22, 2021, followed by the issuance of final cross-sector control system goals and sector-specific critical infrastructure cybersecurity performance goals by July 2022. Note that the memorandum works at two levels: it requires issuance of performance goals for controls systems and sector-specific critical infrastructure cybersecurity performance goals; the latter seems to reach beyond ICSs.

As required, on September 21, CISA and NIST issued nine preliminary control system cybersecurity performance goals. Each of the nine goals includes specific objectives that support the deployment and operation of secure control systems that are further organized into baseline and enhanced objectives.

The Initiative had already began with a pilot effort with the electricity subsector. According to the White House, as of July 2021, over 150 electricity utilities representing almost 90 million residential customers were either deploying or had agreed to deploy control system cybersecurity technologies. As of July 2021, an action plan for natural gas pipelines was underway, and additional initiatives for Water and Wastewater Sector Systems and the Chemical Sector were planned to follow later in the year. On August 25, 2021, the Biden Administration announced the formal expansion of the ICS cybersecurity initiative to a second major sector: natural gas pipelines.


Last updated: Nov. 20, 2024.

Photo: “The Allegory of Good Government," by Ambrogio Lorenzetti, 1338, Museo Civico, Siena, (c) Erik Törner, CC BY-NC-SA 2.0.