.png)
February 2, 2024
Re: FAR Case 2021–017
The Operational Technology Cybersecurity Coalition (OTCC) appreciates the opportunity to submit feedback on FAR Case 2021–017, which seeks to amend the Federal Acquisition Regulation (FAR) to partially implement Executive Order 14028 on cyber threats and incident reporting and information sharing for Federal contractors and to implement related cybersecurity policies.
The OTCC is a diverse group of leading industrial control systems (ICS) and operational technology (OT) cybersecurity vendors covering the entire OT lifecycle. As such, we applaud the decision made by the Department of Defense (DoD), the General Services Administration (GSA), and the National Aeronautics and Space Administration (NASA) to update these regulations to include OT and Internet of Things (IoT) as specific, individualized categories that merit monitoring and incident reporting requirements. This will help facilitate precision in communication, targeted cybersecurity strategies, regulatory compliance, accurate risk assessment, and adaptability to technological changes.
Outside of the inclusion of IoT and OT in the definition of industrial control systems, we have a number of other concerns with the proposed rule.
Software Bills of Materials (SBOMs)
Over the last few years, software producers have invested greatly into maturing their ability to generate software bills of materials. Still, it remains unclear how exactly the government intends to collect, secure, and use SBOMs.
The proposed rule would impose, for the first time, a requirement that federal contractors develop and maintain Software Bills of Materials (SBOMs) for any software used in performance of the contract regardless of whether there is a security incident. However, most contractors do not create their own software and instead use commercial off-the-shelf products for which SBOMs might not be readily available and may need to be generated specifically for the contractor and government transactions. This can be especially burdensome for small contractors and become a barrier to entry for some of the small businesses that the Administration is seeking to bring into the government. Implementing the necessary processes and systems to generate and maintain comprehensive SBOMs can be resource-intensive and possibly cost prohibitive for smaller companies, especially those with extensive software portfolios.
Inconsistencies in federal SBOM rules will also cause confusion for contractors. For example:
There is a significant difference between the M-22-18 SBOM requirement, which calls for an SBOM as an optional artifact to be provided upon request, and the proposal in 2021-17, which includes an SBOM requirement for all software used in the performance of a contract.
SBOMs in the M-22-18 context are intended to help secure software development processes, whereas this proposed rule requires SBOMs for incident investigation and subsequent remediation efforts. It remains unclear as to whether or not SBOMS are optional or mandatory.
Further, this proposed rule requires the flow down of the SBOM requirements to all subcontractors. This seems to contradict long standing guidance from the National Institute of Standards and Technology (NIST) and the Cybersecurity and Infrastructure Security Administration (CISA) that SBOMs are required only for top level dependencies and will require additional investments into staffing and the establishment and automation of processes.
These inconsistencies and lack of clarity will ultimately disproportionately impact small businesses, so it is important for any SBOM requirement to strike the right balance between producing the desired security benefits and protecting enterprise software vendors' ability to maintain a competitive advantage.
Further, the proposed rule would require that SBOMs comply with all of the minimum elements identified in Section IV of The Minimum Elements for a Software Bill of Materials published by the Department of Commerce. However, it does not limit SBOMs to those elements, making it possible that various agencies could develop unique SBOM requirements that go beyond the minimum elements. This means that a company would have to develop a unique SBOM for every government agency with which it does business. Any requirements for SBOMs must have a uniform standard across government agencies.
Beyond the resource and financial burden to contractors, SBOMs present possible security risks to contractors by effectively serving as “roadmaps” for malicious actors seeking to exploit vulnerabilities. They could also reveal sensitive intellectual property information or give companies insights into components and dependencies of their competitors’ technological architecture, making it possible for them to replicate or surpass the services offered by their competitors. Therefore, any collection and storage of SBOM information must be securely transmitted and stored. Before any SBOM requirements are imposed, the government needs to establish a secure system for transmitting and storing SBOM data, as well as establish clear guidelines that govern when, how, and under what circumstances SBOM materials can be accessed and used.
The SBOMs will also include a significant amount of vulnerability and other sensitive information each contractor will presumably have to provide to each agency with which it provides products or services. This puts this information at significant risk due to varying levels of cybersecurity maturity at each agency. It therefore makes more sense to develop a central, secure database to maintain vendor information that can in turn be accessed by agencies that need to access a contractor’s SBOM materials.
Because SBOMs are best produced when the software is developed, and often include SBOMs from upstream suppliers, we recommend that the rule direct agencies to be able accept any of the NTIA-recommended (or subsequent CISA-recommended) SBOM formats (i.e., CycloneDX, SPDX, and SWID) to drive towards harmonization.
Security Incident Reporting Harmonization
We understand that timely incident reporting and sharing indicators of compromise are critical to not only responding to a cyber breach but can also help protect other targets and victims. However, as the rule appears to acknowledge, the timeline included in the rule – within eight hours of discovery – does not align with multiple other incident reporting regimes under which several of our companies might also be subject to. This acknowledgment is particularly notable given the messages coming from this Administration about the need to harmonize existing incident reporting regimes. For example, on July 19, 2023, the White House Office of the National Cyber Director (ONCD) announced a request for information (RFI) on cybersecurity regulatory harmonization and regulatory reciprocity. While the results of the RFI are not yet public, we expect the responses will argue strongly that the Federal Government adopt clear incident reporting models and timelines that give companies the ability to focus on responding to incidents rather than myriad reporting regimes.
Additionally, on September 19, 2023, the Department of Homeland Security (DHS) released a report titled “Harmonization of Cyber Incident Reporting to the Federal Government.” Among its recommendations was for the Federal Government to “adopt model cyber incident reporting timelines and triggers wherever practicable. Federal agencies should evaluate the feasibility of adapting current and future cyber incident reporting requirements to align to model timeline and trigger provisions.” While the 8-hour timeline included in the proposed rule aligns with one of the examples you provide, it breaks with at least two others that adopt a 72-hour disclosure window. We highly encourage you to work closely with DHS and ONCD as they work to solve the issue of harmonizing reporting requirements before putting into regulation a deadline that might add to the burden of incident responders without a clearly justified need to provide breach notifications within 8 hours.
Ambiguity and uncertainty caused by different definitions and requirements can lead to inconsistent reporting practices by contractors, which can hinder effective cyber threat intelligence and response efforts. Any efforts to harmonize regulations within sectors should start with developing common definitions, lexicon, and reporting regimes. Exceptions to any harmonization, especially those related to reporting timelines, should be clearly justified, and tied directly to the operational needs of the entity to whom an entity must report.
Access to Contractor Information and Information Systems
The proposed rule would require contractors provide the Cybersecurity and Infrastructure Security Agency (CISA), the Federal Bureau of Investigations (FBI), and contracting agency “full access” to contractor information, systems, and personnel in the event of an incident. This includes access to not only contractor information systems used in performance of the contract, but also systems which “support performance” of the contract. This raises significant concerns with government access to systems and information networks and sensitive business records.
The proposed rule attempts to address this to some degree by specifying that the rule does “not include” business records that do not incorporate government data, and data such as operating procedures, software coding or algorithms that are not uniquely applied to the Government data. However, those exceptions are narrow and do not apply to the types of systems that “support performance” of government contracts, which can also support enterprise work, or other contracted work unrelated to the government.
Additionally, the proposed rule would grant limitless system access to contractors’ commercially owned information systems to multiple agencies. This discrepancy harms the trusted partnership between the different contracting parties by applying different standards for public and private entities. Many companies work with other subcontractors, and there is no clear mechanism for companies to provide “full access” to third-party systems.
”Full access” to systems also raises a number of concerns, including risks to intellectual property, privacy concerns, data security and protection, regulatory compliance in highly regulated sectors, and disruption of operations. It also rests heavily on the assumption that that “full access” is needed to respond to an incident, and government respondents should have access to and possession of sensitive company information. Notice, timelines, and scope of full access should all be tailored to the specific reportable cyber incident in questions.
Finally, giving the government “full access” amid an incident could disrupt any mitigation efforts being undertaken by a company or third-party responders. CIRCIA, to which the rule refers multiple times, includes language that governs, to some extent, what information the government can access during a cyber incident targeting critical infrastructure, and what the government can do with the information it receives. (6 U.S.C. § 681e). Adopting those limitations would address at least some of the concerns with government access to contractor information.
Again, the OTCC thanks you for the opportunity to share our concerns with FAR Case 2021–017 and looks forward to further engagement on this issue.
Sincerely,
Andrew Howell
Executive Director, OTCC
Comments