Third-Party Risk Management in the Executive Order on Improving the Nation’s Cybersecurity

The US Federal Government will require all information and operational technology suppliers to meet specific criteria to ensure their supply chains are secure. How should software manufacturers assess their supply chains?
Scott Lang
VP, Product Marketing
June 02, 2021
Blog eo nations cybersecurity 0621

On May 12, 2021, President Biden signed the Executive Order on Improving the Nation’s Cybersecurity. Developed in the wake of the highly damaging SolarWinds Orion software supply chain breach, the Order directs several US Federal Government agencies to better coordinate in preventing, detecting, responding to and mitigating security incidents and breaches by:

  • Removing barriers to sharing threat information
  • Modernizing Federal Government cybersecurity technologies and practices
  • Enhancing software supply chain security
  • Establishing and standardizing the Federal Government’s playbook for vulnerabilities and incident response
  • Improving the detection of cybersecurity vulnerabilities and incidents on Federal Government networks
  • Improving the Federal Government’s investigative and remediation capabilities

This Executive Order (EO) builds on previous cybersecurity-related EOs and requires agencies to establish uniform standards based on NIST, with enforcement beginning in May 2022.

Since this EO introduces several new third-party risk management requirements for Federal agencies to implement, this post focuses on Section 4. Enhancing Software Supply Chain Security. If software suppliers are not able to meet these requirements, they will be removed from the Federal Government’s Acquisition Regulation – meaning they can no longer sell to the government. The Federal Government will publish these requirements, including testing and evaluation criteria, later in the year.

How Third-Party Risk Management Applies to the President’s Executive Order

Critical Federal Government IT systems have long been the target of nation state attacks. Malicious actors know that the easiest, least secure path into Federal systems is often through third-party services and software. Third-party providers may not have the processes or controls necessary to detect malicious activity or code, and they can potentially expose a wide range of sensitive information.

Third-party risk management technologies and processes can help to address guidelines in the Executive Order that require organizations to evaluate and report on software security. The EO criteria include assessments of developer and supplier security controls, as well as documentation that demonstrates adherence to secure practices.

The table below summarizes some of the most important third-party risk management requirements addressed in the EO, along with Prevalent’s recommended capabilities to assess supplier practices.

EO Guidance Recommended Capabilities

4 (e) (i) (A)-(F)

Such guidance shall include standards, procedures, or criteria regarding:
(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;

When assessing third party software security practices, take advantage of existing industry-accepted standardized risk assessment questionnaire templates including the Standard Information Gathering (SIG), NIST, CMMC, and related assessments. Utilizing a single standardized assessment across your supplier base ensures that agencies can more efficiently compare the software security practices of their suppliers.

Note: Agencies can also take advantage of exchange networks, which contain already completed security risk assessments to accelerate the risk identification process.

4 (e) (ii)

(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;

When assessing a third party’s secure software development practices, ensure that you have the capability to centralize supporting evidence with built-in task and acceptance management, plus mandatory upload features. A secure document repository ensures that relevant parties can review documentation and artifacts accordingly.

4 (e) (iii)

(iii) employing automated tools, or comparable processes, to maintain trusted source code supply chains, thereby ensuring the integrity of the code;

See 4 (e) (i) (A)-(F) above.

4 (e) (iv)

(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;

Third parties must scan, triage and remediate vulnerabilities in their software and code, and attest to it. But threats don’t end there. Security teams should also monitor the Internet and dark web for cyber threats, leaked credentials or other indicators of compromise that can open pathways into Federal systems if left undetected.

4 (e) (v)

(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;

Reporting is key here. Federal IT security teams should be able to reveal risk trends, status, remediations and exceptions to common behavior for individual suppliers or groups with embedded machine learning insights. This would enable teams to quickly identify outliers across assessments, tasks, risks, etc. that could warrant further investigation.

4 (e) (vi)

(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;

Federal IT teams should be able to automatically map information gathered from internal audits to standards or regulatory frameworks applicable in this EO – including NIST, CMMC and others – to quickly visualize and address important control deficiencies, and attest to practices.

4 (e) (vii)

(vii) providing a purchaser a Software Bill of Materials (SBOM) for each product directly or by publishing it on a public website;

See 4 (e) (i) (A)-(F) above.

4 (e) (viii)

(viii) participating in a vulnerability disclosure program that includes a reporting and disclosure process;

See 4 (e) (i) (A)-(F) above.

4 (e) (ix)

(ix) attesting to conformity with secure software development practices; and

See 4 (e) (ii) above.

4 (e) (x)

(x) ensuring and attesting, to the extent practicable, to the integrity and provenance of open source software used within any portion of a product.

See 4 (e) (vi) above.

Building a Third-Party Risk Management Program that Complies with the EO on Improving the Nation’s Cybersecurity

As the requirements outlined in the Executive Order on Improving the Nation’s Cybersecurity take shape in the next year, now is the time for IT software companies to build or mature their own third-party risk management programs. Key considerations should include:

  • Identifying which suppliers are considered critical, and focusing assessment efforts on those that present the most inherent risk to your operations
  • Regularly assessing the secure software development lifecycle practices of key third parties that contribute code or updates to your final builds
  • Continuously monitoring the dark web, hacker chatter and other related forums for activity related to your third parties
  • Triaging and remediating assessment and monitoring findings
  • Centralizing documentation and reporting for auditors

Prevalent can help. We offer a SaaS solution that automates the critical tasks required to identify, assess, analyze, remediate, and continuously monitor third-party security, privacy, operational, compliance and procurement-related risks across every stage of the vendor lifecycle. For more on how Prevalent can help, read about our TPRM capabilities for the Executive Order on Improving the Nation's Cybersecurity or contact us for a strategy discussion today.

Leadership scott lang
Scott Lang
VP, Product Marketing

Scott Lang has 25 years of experience in security, currently guiding the product marketing strategy for Prevalent’s third-party risk management solutions where he is responsible for product content, launches, messaging and enablement. Prior to joining Prevalent, Scott was senior director of product marketing at privileged access management leader BeyondTrust, and before that director of security solution marketing at Dell, formerly Quest Software.

  • Ready for a demo?
  • Schedule a free personalized solution demonstration to see if Prevalent is a fit for you.
  • Request a Demo