A new American government? Then there must be a new cybersecurity EO.
Cocktail Party
The Biden Administration rolled out a web of interlocking directions centering on key agencies the White House will now need to manage. Some of the actions come due in the next few months while others have longer timelines. As always, implementation, follow through, coordination and buy-in will determine the success of this effort.
Meeting
The Biden Administration unveiled a far-reaching executive order intended to address the cybersecurity of both United States (U.S.) government agencies and the private sector entities with whom it contracts for a significant portion of information and communications technology. The White House is looking to use contractual language to drive much of the change on the private side of the federal cybersecurity equation and will change federal acquisition regulations where necessary. On the public side, the administration is charging the agencies with new responsibilities, and the Office of Management and Budget, Cybersecurity and Infrastructure Security Agency, the National Security Agency, the National Institute of Standards and Technology, and the Departments of Homeland Security and Commerce will drive much of the efforts.
Geek Out
The Biden Administration issued the long rumored executive order on cybersecurity in the wake of the Colonial Pipeline ransomware attack. However, this directive does not deal with ransomware or private sector critical infrastructure at all. The SolarWinds, Microsoft Exchange, and Accellion hacks drove the development of this executive order, especially the vulnerabilities Russian and Chinese hackers apparently used in software supply chains. Of course, this is the second executive order in a few months. In March, the administration issued Executive Order (EO) 14017, “America’s Supply Chains” that directed a wide-ranging review of key U.S. sectors and their dependence on increasingly attenuated supply chains. (see here for more detail and analysis).
However, the Biden Administration has been working on another executive order for most of its tenure to address cybersecurity more widely. Thus the release yesterday of the “Executive Order on Improving the Nation’s Cybersecurity.” In the policy section, President Joe Biden declared:
It is the policy of my Administration that the prevention, detection, assessment, and remediation of cyber incidents is a top priority and essential to national and economic security. The Federal Government must lead by example. All Federal Information Systems should meet or exceed the standards and requirements for cybersecurity set forth in and issued pursuant to this order.
The administration pointed to barriers in the U.S. government’s contracts with private sector contractors:
current contract terms or restrictions may limit the sharing of such threat or incident information with executive departments and agencies (agencies) that are responsible for investigating or remediating cyber incidents, such as the Cybersecurity and Infrastructure Security Agency (CISA), the Federal Bureau of Investigation (FBI), and other elements of the Intelligence Community (IC). Removing these contractual barriers and increasing the sharing of information about such threats, incidents, and risks are necessary steps to accelerating incident deterrence, prevention, and response efforts and to enabling more effective defense of agencies’ systems and of information collected, processed, and maintained by or for the Federal Government.
It bears noting that the SolarWinds hack, so far as facts have been made public, was discovered by the security firm, FireEye, working on its own. It was not the case (again, so far as we know) that a federal contractor knew of the supply chain attack and kept the information to itself. This is not to say there have not been cases where private sector companies that contract to provide ICT services to the U.S. government have not reported intrusions and breaches. Under the Defense Federal Acquisition Regulation Supplement (DFARS), many defense contractors already have an affirmative responsibility to report some security incidents within 72 hours.
And so, the Office of Management and Budget (OMB) “in consultation with the Secretary of Defense, the Attorney General, the Secretary of Homeland Security, and the Director of National Intelligence” will have 60 days to review “the Federal Acquisition Regulation (FAR) and the Defense Federal Acquisition Regulation Supplement contract requirements and language for contracting with IT and OT service providers.” The purpose of this review is to make recommendations for “updates to such requirements and language to the FAR Council and other appropriate agencies…[including] descriptions of contractors to be covered by the proposed contract language.” OMB’s recommendations must address the following:
- service providers collect and preserve data, information, and reporting relevant to cybersecurity event prevention, detection, response, and investigation on all information systems over which they have control, including systems operated on behalf of agencies, consistent with agencies’ requirements;
- service providers share such data, information, and reporting, as they relate to cyber incidents or potential incidents relevant to any agency with which they have contracted, directly with such agency and any other agency that the Director of OMB, in consultation with the Secretary of Defense, the Attorney General, the Secretary of Homeland Security, and the Director of National Intelligence, deems appropriate, consistent with applicable privacy laws, regulations, and policies;
- service providers collaborate with Federal cybersecurity or investigative agencies in their investigations of and responses to incidents or potential incidents on Federal Information Systems, including by implementing technical capabilities, such as monitoring networks for threats in collaboration with agencies they support, as needed; and
- service providers share cyber threat and incident information with agencies, doing so, where possible, in industry-recognized formats for incident response and remediation.
The FAR Council will have three months to use OMB’s recommendations to propose changes to federal contracting language, and if “appropriate,” publish such changes for public comment. However, the EO does not set a deadline for the final issuance or completion of this task.
Will the U.S. government make this contract language retroactive to cover current, ongoing contracts? Will the FAR Council recommend slipping these provisions into task orders and contract renewals? This is not clear from the EO, but the Biden Administration should give this thought to ensure its plan to require U.S. contractors to share information is quickly and widely adopted and implemented.
OMB’s Federal Procurement Policy Office Administrator heads the FAR Council, and that position is currently filled by a Trump Administration appointee, Michael Wooten. It is not clear whether the White House will allow Wooten to continue serving in that position or will nominate its own person. Regardless, the White House and OMB will likely be able to exert pressure on the FAR Council to see this task through.
Of course, the U.S. government already has an information sharing system. The ”Cybersecurity Act of 2015’” (P.L. 114-113) established an information sharing system that provided significant liability protection for private sector entities sharing amongst themselves and especially with the U.S. government. However, this system has been widely panned and rarely used according to U.S. data (the 2017 and 2019 joint Office of the Inspectors General reports on this program.)
Nonetheless, the next requirement in the EO may seek to leverage this system. Within four months, the Department of Homeland Security (where the information sharing system resides) and OMB “shall take appropriate steps to ensure to the greatest extent possible that service providers share data with agencies, Cybersecurity and Infrastructure Security Agency (CISA) and the Federal Bureau of Investigation (FBI), as may be necessary for the Federal Government to respond to cyber threats, incidents, and risks.”
The EO then goes on to spell out a process to ensure contracts with a seemingly different class of federal contractors also mandate the reporting of security incidents among other changes. The previously discussed provisions pertain to “IT and OT service providers” whereas Section 2(f)(1) references “information and communications technology (ICT) service providers.” The definitions section of the EO does not provide definitions for either term, which may complicate efforts to execute the EO, for there is a different, parallel process for ICT service providers.
Setting this aside for the moment, Section 2(f) sets U.S. policy that ICT service providers contracting with the U.S. government “must promptly report to such agencies when they discover a cyber incident involving a software product or service provided to such agencies or involving a support system for a software product or service provided to such agencies.” Moreover, such companies working with “Federal Civilian Executive Branch Agencies” (FCEB) must report incidents to CISA except for those pertaining to National Security Systems (NSS). Incidents involving this latter class of systems are to be reported to an agency to be named later, but it may turn out to be the National Security Agency (NSA).
If the goal is uniform contract language and reporting requirements across the U.S. government, it is not clear where there is a bifurcated process predicated on two classes of U.S. contractors: IT and OT service providers and ICT service providers.
However, aside and apart from this issue, it would seem to make more sense to consider contractual language implemented through the FAR requiring contractors to report all cyber incidents since future nation-state hacks will likely find new ways into U.S. systems.
In any event, DHS will need to make separate recommendations to the FAR Council on contract language within 45 days “that identifies:
- the nature of cyber incidents that require reporting;
- the types of information regarding cyber incidents that require reporting to facilitate effective cyber incident response and remediation;
- appropriate and effective protections for privacy and civil liberties;
- the time periods within which contractors must report cyber incidents based on a graduated scale of severity, with reporting on the most severe cyber incidents not to exceed 3 days after initial detection;
- NSS reporting requirements; and
- the type of contractors and associated service providers to be covered by the proposed contract language.
The parameters of DHS’ direction raise some questions. First, if the agency is to determine which classes of contractors and providers are to be subject to the new contract requirements, this runs the risk that certain stakeholders will lobby to be omitted, threatening the broader sweep of the EO that envisions all contractor cybersecurity incidents being reported to the U.S. government to better protect U.S. systems. Likewise, DHS will need to determine which “cyber incidents” need to be reported, which also invites a conservative approach that would mandate only the reporting of the most serious incidents. If this were to be the direction DHS goes, a risk is created that a significant incident may not be reported. One also wonders whether 72 hours is too loose a timeframe for a contractor to inform the U.S. government there may be a problem. Undoubtedly the White House is working from the framework much of the Defense Industrial Base works under (as mentioned above in the DFARS), but it may be advisable and possible to reduce this timeframe for the clock starts running upon “initial detection.”
The FAR Council then has three months to “review the recommendations and publish for public comment proposed updates to the FAR.” So, this would be a second FAR Council rulemaking.
Separate from the twin tracks to review and remake contract language and requirements, the NSA would have three months to work with the Department of Justice, DHS, and the Director of National Intelligence (DNI) to “jointly develop procedures for ensuring that cyber incident reports are promptly and appropriately shared among agencies.” Given that DHS is already supposed to be serving this role under the “Cybersecurity Act of 2015,” this may be duplicative or an indication the current system is failing.
Within two months, CISA would need to “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” that must “include consideration of the scope of contractors and associated service providers to be covered by the proposed contract language.” The FAR Council would then have two months to review these recommendations and then propose any changes to the FAR. Agencies would then need to remove any language from their acquisition regulations that duplicate any such FAR Council updates to the FAR.
Consequently, it appears the FAR Council will be managing three different rulemakings to change different aspects of contractual language submitted by three different entities: OMB, DHS, and CISA.
Section 3 of the EO addresses modernizing U.S. government cybersecurity. The administration asserted:
To keep pace with today’s dynamic and increasingly sophisticated cyber threat environment, the Federal Government must take decisive steps to modernize its approach to cybersecurity, including by increasing the Federal Government’s visibility into threats, while protecting privacy and civil liberties. The Federal Government must adopt security best practices; advance toward Zero Trust Architecture; accelerate movement to secure cloud services, including Software as a Service (SaaS), Infrastructure as a Service (IaaS), and Platform as a Service (PaaS); centralize and streamline access to cybersecurity data to drive analytics for identifying and managing cybersecurity risks; and invest in both technology and personnel to match these modernization goals.
Under this section of the EO, within two months, all agency heads will need to review and then update its existing plans to use cloud computing and fashion plans to employ Zero Trust Architecture. The agencies will then need to report to National Security Advisor Jake Sullivan on these plans. And, it bears note the definition of agency used in the EO is much broader than the usual definition, and, as a result, independent agencies like the Federal Trade Commission (FTC) and Securities and Exchange Commission (SEC) are subject to these dictates.
A directive to use zero trust architecture is new and marks a new direction in federal cybersecurity. The National Institute of Standards and Technology published a guidance document on zero trust in August 2020, but it has not been widely adopted by the U.S. government.
However, the Biden Administration is opting to double down on the cloud. The White House is also directing key U.S. government stakeholders to remake how agencies are using cloud technology to ensure “they shall do so in a coordinated, deliberate way that allows the Federal Government to prevent, detect, assess, and remediate cyber incidents.” Further, when agencies migrate operations to the cloud, they must use Zero Trust Architecture, to the extent they can. CISA must “modernize its current cybersecurity programs, services, and capabilities to be fully functional with cloud-computing environments with Zero Trust Architecture.” Of course, this EO does not associate any funding with this mandate, presumably leaving the agency to use existing funds to manage such a transition. CISA must also work with the General Services Administration (GSA) and its in-house program to regularize the use of cloud service providers, the Federal Risk and Authorization Management Program (FedRAMP), to “develop security principles governing Cloud Service Providers (CSPs) for incorporation into agency modernization efforts.”
To bring about the above-mentioned cloud computing policy changes, within three months, OMB must draft a new “Federal cloud-security strategy and provide guidance to agencies accordingly.” This new strategy would probably modify, alter, or replace the 2019 Cloud Smart strategy. DHS would also have a cloud-related deliverable within the next three months, for the agency would need to develop “cloud-security technical reference architecture documentation that illustrates recommended approaches to cloud migration and data protection for agency data collection and reporting” for federal civilian agencies (aka in the EO as FCEB). CISA has two months to draft and issue a “cloud-service governance framework” that must “identify a range of services and protections available to agencies based on incident severity…[and] data and processing activities associated with those services and protections.”
CISA would draw the task of tackling the issue of the unclassified data agencies hold. The agency must “evaluate the types and sensitivity of their respective agency’s unclassified data” and must report to OMB. This evaluation “shall prioritize identification of the unclassified data considered by the agency to be the most sensitive and under the greatest threat, and appropriate processing and storage solutions for those data.” One wonders how the decade old, ongoing effort at the National Archives and Records Administration’s Information Security Oversight Office (ISOO) to address Controlled Unclassified Information (CUI) fits into this evaluation. CUI is defined in regulation as “information the Government creates or possesses, or that an entity creates or possesses for or on behalf of the Government, that a law, regulation, or Government-wide policy requires or permits an agency to handle using safeguarding or dissemination controls.” It is possible to imagine unclassified information that falls outside the definition of CUI, so there may be a need to better secure this type of information.
The EO directs agencies to implement and use multi-factor authentication (MFA) and encryption for data at rest and in transit within six months and to report to CISA, OMB, and the National Security Advisor every two months on these efforts until fully adopted. Agencies unable to fully adopt these techniques within six months must provide a rationale in writing. The inclusion of these requirements suggests there are agencies not using MFA and encryption, which is a staggering thought considering the sensitive information the U.S. government holds. CISA shall help FCEB adopt MFA and encryption through “all appropriate steps to maximize adoption.”
DHS has three months to “establish a framework to collaborate on cybersecurity and incident response activities related to FCEB cloud technology, in order to ensure effective information sharing among agencies and between agencies and CSPs.”
GSA must revamp of FedRAMP, starting 60 days of the EO’s issuance, per the White House’s detailed instructions.
The fourth section of the EO addresses software supply chain security, and the Biden Administration provided the policy rationale for its proposed changes:
The security of software used by the Federal Government is vital to the Federal Government’s ability to perform its critical functions. The development of commercial software often lacks transparency, sufficient focus on the ability of the software to resist attack, and adequate controls to prevent tampering by malicious actors. There is a pressing need to implement more rigorous and predictable mechanisms for ensuring that products function securely, and as intended. The security and integrity of “critical software” — software that performs functions critical to trust (such as affording or requiring elevated system privileges or direct access to networking and computing resources) — is a particular concern. Accordingly, the Federal Government must take action to rapidly improve the security and integrity of the software supply chain, with a priority on addressing critical software.
Within one month, NIST must “solicit input from the Federal Government, private sector, academia, and other appropriate actors to identify existing or develop new standards, tools, and best practices for complying with the standards, procedures, or criteria in subsection (e) of this section” (see below for this list.) NIST’s guidelines must “include criteria that can be used to evaluate software security, include criteria to evaluate the security practices of the developers and suppliers themselves, and identify innovative tools or methods to demonstrate conformance with secure practices.”
These are the standards, procedures, or criteria NIST must investigate and incorporate into its standards on software supply chain security:
(i) secure software development environments, including such actions as:
(A) using administratively separate build environments;
(B) auditing trust relationships;
(C) establishing multi-factor, risk-based authentication and conditional access across the enterprise;
(D) documenting and minimizing dependencies on enterprise products that are part of the environments used to develop, build, and edit software;
(E) employing encryption for data; and
(F) monitoring operations and alerts and responding to attempted and actual cyber incidents;
(ii) generating and, when requested by a purchaser, providing artifacts that demonstrate conformance to the processes set forth in subsection (e)(i) of this section;
(iii) employing automated tools, or comparable processes, to maintain trusted source code supply chains, thereby ensuring the integrity of the code;
(iv) employing automated tools, or comparable processes, that check for known and potential vulnerabilities and remediate them, which shall operate regularly, or at a minimum prior to product, version, or update release;
(v) providing, when requested by a purchaser, artifacts of the execution of the tools and processes described in subsection (e)(iii) and (iv) of this section, and making publicly available summary information on completion of these actions, to include a summary description of the risks assessed and mitigated;
(vi) maintaining accurate and up-to-date data, provenance (i.e., origin) of software code or components, and controls on internal and third-party software components, tools, and services present in software development processes, and performing audits and enforcement of these controls on a recurring basis;
(vii) providing a purchaser a Software Bill of Materials (SBOM) for each product directly or by publishing it on a public website;
(viii) participating in a vulnerability disclosure program that includes a reporting and disclosure process;
(ix) attesting to conformity with secure software development practices; and
(x) ensuring and attesting, to the extent practicable, to the integrity and provenance of open source software used within any portion of a product.
The EO also tasks NIST to “issue guidance identifying practices that enhance the security of the software supply chain” within three months. Moreover, NIST was given six months to publish “preliminary guidelines” on software supply chain security based on the input it receives when it solicits comment. Within one year, NIST must publish additional guidelines and establish a process to regularly revisit software supply chain security.
NIST is given the job of defining a key term for this section of the EO: “critical software.” The agency has 45 days to do so and is directed to keep in mind the “definition shall reflect the level of privilege or access required to function, integration and dependencies with other software, direct access to networking and computing resources, performance of a function critical to trust, and potential for harm if compromised.” 30 days after NIST publishes this definition, CISA will “identify and make available to agencies a list of categories of software and software products in use or in the acquisition process meeting the definition of critical software.” Thereafter NIST will “publish guidance outlining security measures for critical software… including applying practices of least privilege, network segmentation, and proper configuration.” OMB will then take steps to ensure agencies comply with the NIST guidance on security measures. Agencies operating “legacy” software (virtually all software developed and deployed before this section of the EO is fully implemented) will have to comply with OMB’s requirements or provide a plan on the steps they will take to remediate risks.
DHS will also make recommendations to the FAR Council for “contract language requiring suppliers of software available for purchase by agencies to comply with, and attest to complying with” the NIST definition of critical software and subsequent guidance and requirements applicable to U.S. agencies. The FAR Council will then issue changes to the FAR as appropriate. Moreover, agencies must “remove software products that do not meet the requirements of the amended FAR [regarding critical software] from all indefinite delivery indefinite quantity contracts; Federal Supply Schedules; Federal Government-wide Acquisition Contracts; Blanket Purchase Agreements; and Multiple Award Contracts.” This would create a significant obstacle for non-compliant software to be used in agency networks and by contractors.
The Department of Commerce (Commerce) must publish the minimum elements of a Software Bill of Materials (SBOM) within two months. This is a task Commerce may be able to handle quickly considering the National Telecommunications and Information Administration (NTIA) has been conducting a multistakeholder process on SBOM over the last few years.
Commerce must also “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)” within 60 days.
NIST would need to “initiate pilot programs informed by existing consumer product labeling programs to educate the public on the security capabilities of Internet-of-Things (IoT) devices and software development practices, and shall consider ways to incentivize manufacturers and developers to participate in these programs:
- To “identify IoT cybersecurity criteria for a consumer labeling program, and shall consider whether such a consumer labeling program may be operated in conjunction with or modeled after any similar existing government programs consistent with applicable law.”
- To “identify secure software development practices or criteria for a consumer software labeling program, and shall consider whether such a consumer software labeling program may be operated in conjunction with or modeled after any similar existing government programs, consistent with applicable law.”
Section 5 requires DHS to establish a Cyber Safety Review Board that shall “shall review and assess, with respect to significant cyber incidents (as defined under Presidential Policy Directive 41 of July 26, 2016 (United States Cyber Incident Coordination) (PPD 41)) affecting FCEB Information Systems or non-Federal systems, threat activity, vulnerabilities, mitigation activities, and agency responses.” This section spells out when DHS would convene this Board. And yet, DHS would first convene the Board to review “the cyber activities that prompted the establishment of a Cyber Unified Coordination Group (UCG) in December 2020” and “shall, within 90 days of the Board’s establishment, provide recommendations to the Secretary of Homeland Security for improving cybersecurity and incident response practices.” The UCG established in December 2020 was done to manage the U.S. government’s response to the SolarWinds supply chain attack. The EO details the extensive areas of this hack the recommendations must cover, and DHS would also provide advice on how to best implement these recommendations.
Section 6 would standardize the U.S. government’s response to cyber incidents, for these processes differ from agency to agency and demand uniformity. DHS must “develop a standard set of operational procedures (playbook) to be used in planning and conducting a cybersecurity vulnerability and incident response activity respecting FCEB Information Systems.” Any agency that wants to deviate from this playbook must show their procedures meet or exceed the standards DHS establishes. In order to ensure that agencies follow the playbook, CISA would need to “review and validate FCEB Agencies’ incident response and remediation results upon an agency’s completion of its incident response.”
The aim of Section 7 is to bolster U.S. civilian agency networks. The EO mandates:
FCEB Agencies shall deploy an Endpoint Detection and Response (EDR) initiative to support proactive detection of cybersecurity incidents within Federal Government infrastructure, active cyber hunting, containment and remediation, and incident response.
CISA has 30 days to provide OMB with “recommendations on options for implementing an EDR initiative, centrally located to support host-level visibility, attribution, and response regarding FCEB Information Systems.” OMB has 90 days after receiving these recommendations to “issue requirements for FCEB Agencies to adopt Federal Government-wide EDR approaches” that must make clear that CISA may “engage in cyber hunt, detection, and response activities” in FCEB networks and systems. To aid in CISA’s mission, “[w]ithin 75 days of the date of this order, agencies shall establish or update Memoranda of Agreement (MOA) with CISA for the Continuous Diagnostics and Mitigation Program to ensure object level data, as defined in the MOA, are available and accessible to CISA.”
Likewise regarding NSS, NSA must recommend to DOD, DNI, and “the Committee on National Security Systems (CNSS) appropriate actions for improving detection of cyber incidents affecting NSS, to the extent permitted by applicable law, including recommendations concerning EDR approaches and whether such measures should be operated by agencies or through a centralized service of common concern.”
DOD and DHS would need to share directives to agencies under their jurisdiction (defense and intelligence and civilian, respectively) and establish a formal system of consideration under which one agency would consider the directives of the other (e.g., if DOD issues a directive to its agencies, DHS would need to determine whether it should do the same for FCEB agencies.)
Section 8 deals with the U.S. government’s investigation and remediation of cyber incidents and vulnerabilities. The EO explained:
Information from network and system logs on Federal Information Systems (for both on-premises systems and connections hosted by third parties, such as CSPs) is invaluable for both investigation and remediation purposes. It is essential that agencies and their IT service providers collect and maintain such data and, when necessary to address a cyber incident on FCEB Information Systems, provide them upon request to the Secretary of Homeland Security through the Director of CISA and to the FBI, consistent with applicable law.
Finally, the NSA:
shall adopt NSS requirements that are equivalent to or exceed the cybersecurity requirements set forth in this order that are otherwise not applicable to NSS. Such requirements may provide for exceptions in circumstances necessitated by unique mission needs. Such requirements shall be codified in a National Security Memorandum (NSM). Until such time as that NSM is issued, programs, standards, or requirements established pursuant to this order shall not apply with respect to National Security Systems.
© Michael Kans, Michael Kans Blog and michaelkans.blog, 2019-2021. Unauthorized use and/or duplication of this material without express and written permission from this site’s author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to Michael Kans, Michael Kans Blog, and michaelkans.blog with appropriate and specific direction to the original content.
Michael Kans 