Skip to main content

Improving Cybersecurity: Impact of the U.S. Executive Order

Published Date
Author Todd Thorner

Last month, the Biden administration signed an Executive Order (EO) aimed at improving security across federal networks amid rising concerns over cyberattacks. This EO, titled Improving the Nation’s Cybersecurity, mainly impacts federal government agencies and contractors.

One aim of the EO is to regulate what the U.S. federal government considers to be reasonable security practices within a software supply chain. For vendors, this involves managing secure software development lifecycles, best practices, and other guidelines for selling software to the federal government.

Why a new Executive Order?

A key goal of the EO is to manage the cybersecurity posture of applications across their lifecycle within the supply chain. To this end, NIST is already laying the groundwork for strong controls regarding what the government considers to be critical software.

NIST seeks to build on existing approaches and capabilities to avoid duplication and to speed implementation of needed security steps while also encouraging creative thinking and new approaches.

General discussions about cybersecurity within the software supply chain center around:

Cybersecurity theme

Applicability

Mitigation strategies based on a common set of well-known threats

If you plan to sell software to the federal government, you’ll need to integrate security with the DevOps lifecycle (DevSecOps). This includes feedback loops that continually add new mitigations to address future threats.

Managing the complexity of application portfolios and infrastructure with thought diversity

A diversified pool of advisors increases the likelihood of catching exploitable weaknesses and applying effective solutions.

Security as an ongoing activity rather than a single event

Consider an approach to your cybersecurity profile that includes the entire application lifecycle, from planning and procurement to building and deployment to maintenance and final retirement.

Alignment with standards bodies and industry groups

Many standards and frameworks propose a baseline of security controls that can account for well-known weaknesses, and taking advantage of those controls can free up scarce security resources. For example, CMMI corresponds with work being done by NIST and ISO.

Attention to business value

When discussing security with business stakeholders, thoughts turn toward risk and resiliency. DevSecOps teams must provide a clear alignment with business strategy and scope.

Extending security from the perimeter to assets

This implies the use of models like Zero Trust, where requirements related to applications and data are treated as first-class citizens.

Business portfolio view of software security

Whether the federal government acquires software off-the-shelf or through customized development, it must eventually configure systems across its software portfolio. This works out to become some form of product configuration, mission-specific software development, or integration. 

From the perspective of each individual application, that means making important security decisions regarding which posture to adopt for upgrading, patching, replacing, integrating, or installing new software.

Any decision about adopting a security-aware posture rests on the fundamentals of risk and cost. Organizations conduct this analysis by balancing business priorities and security threats.

In the past, experts had a more thorough understanding of threats and vulnerabilities for a given system. The highly distributed and integrated nature of today’s federal systems makes such thorough insight practically impossible, requiring instead a collaborative and cross-functional approach.

Cross-functional strengths needed for success:

  • Knowledge Management: sharing information across the supply chain as well as injecting other information from knowledge base groups like MITRE.

  • Requirements Management: propagating the appropriate requirements into DevOps and attesting to its completion without bias.

  • Audit and Compliance: mapping audit requirements to security requirements for purposes of providing essential elements of traceability across the supply chain.

  • Asset Management: incorporating security attributes based not just on business priority or patch deltas, but also on specific security standards and frameworks that apply to the system.

  • Risk Management: establishing a repeatable process of aggregating likelihoods and impacts of a security breach and proposing mitigations to strengthen the broader portfolio.

                  

                    Today’s federal systems require a cross-functional approach to security

How can software vendors adapt to the new regulations?

To ensure the integrity of software and infrastructure, the federal government will democratize security across the supply chain. A platform-based approach like this helps its various departments focus on requirements, offer appropriate guidance to implementation teams, provide defensible security attestations, integrate with established DevOps initiatives, and place risk at the forefront of strategic discussions.

This new EO will bring with it many changes. Software companies that serve the federal government must adjust their SDLC to remain a viable part of the federal supply chain.

In short order, NIST and other agencies are expected to create new frameworks, guidelines, and controls to ensure the integrity of the supply chain. Software providers in the federal supply chain, therefore, would need a robust auditable platform capable of rapidly assessing multiple stakeholder viewpoints to deliver secure software at scale.