What Does the Cybersecurity Executive Order Mean for You?

June 29, 2021

With almost daily headlines about cyber attacks against private organizations – attacks that can affect critical infrastructure and, potentially, our very lives – the May 12 executive order (EO) improving the nation’s cyber defenses is both a call-to-action and a declaration of urgency. The EO establishes several objectives to promote better security practices and standards of performance. Interestingly, most of the EO’s directives are security practices that government agencies and private industry should already be following.

Recent incidents highlight the complexity of critical information services for both government and the private sector. Each depends on the orchestration of components from multiple cybersecurity vendors, each of which could be the “weak link in the chain” from a breach or resilience perspective.

The new executive order provides security professionals with ammunition as they pursue essential initiatives and projects that may have encountered management resistance or been underfunded/de-prioritized previously.

Almost all EO requirements draw upon existing, published standards and industry best practices. The biggest game changer for private industry will likely be a greater focus on security assurance for software. Defect reduction at the source of software development can improve security and quality with the potential to reduce the total lifecycle ownership cost to both vendors and customers.

Background and Scope of Reach

While setting clear goals, in most cases the EO doesn’t mandate how they should be achieved. Rather, it defers to existing authorities, such as the Cybersecurity and Infrastructure Security Agency (CISA) and the National Institute of Standards and Technology (NIST) to offer recommendations directing civilian sectors of the executive branch within defined timeframes. There are specific provisions that apply to security practices and operations within federal agencies, including (but not limited to):

Many of these provisions, however, will affect the wider supply chain of IT products and services using the Federal Government’s procurement power to drive higher standards and conformity with the EO’s objectives. These requirements will be, in general, an evolution of current practice standards, although the implementation may be somewhat disruptive.

The mandate for more proactive measures and broader supply-chain considerations will exert impacts far beyond just federal agencies. An overall shift is taking place in focus from detection and response to prevention or “impact minimization.” This makes good sense, particularly in the light of the continuing chronology of high-profile intrusions and consistent analyses of the mean time to detect (MTTD) incidents of around six months.

New Standards or Enforcement of Existing Requirements?

Federal services typically run on, or are supported by, private sector products and services. The ability for a customer, including the Federal Government, to objectively evaluate the security of a vendor application (or a complex system) is very difficult and heavily relies on the cooperation of the vendor. Establishing a software assurance practice, particularly one that can be verified or certified by an independent entity, would go a long way to aiding individual customer inquiries.

Industry is already making considerable expenditures in addressing the risks associated with third-party risk management (TPRM) programs. Supply chain risk includes longer times to detect, greater complexity in managing and significantly higher costs associated with breaches. These expenditures include both developing programs to perform due diligence on vendors as well as responding to assessment requests from customers. Thousands of companies are making duplicative inquiries to the same set of vendors. Common standards and published benchmark data for vendors and products would allow a single-point evaluation, with the results shared among all interested parties, benefiting suppliers and consumers alike.

The main impacts for organizations doing business with the Federal Government will be:

What Will Software Security Assurance Look Like?

A major supply-chain emphasis of the executive order is greater security of the software supply chain to reduce exploitable flaws in procured products. As mentioned above, modern systems have complex dependencies on multiple components and vendors. Successful breaches typically require exploitation of flaws in only a small subset of these. Section four of the executive order establishes a timeline for collaboration with the director of NIST to establish guidance and practices for:

The Information Technology Security Evaluation Criteria (ITSEC) program provides an extremely useful model of what this may look like. ITSEC drew from US DOD standards (such as the Orange Book) and represented a structured set of criteria for evaluating claims of security within products and systems.

Claims of security enforcement capabilities in a product would be evaluated to an agreed-upon level of rigor by an independent, licensed evaluation facility. At lower levels of assurance, the claims may be subject to functional and penetration testing. More advanced levels of assurance would require additional reviews of the development process as well as more invasive technical testing. To attain the highest level of assurance, a formal, rigorous model for the capabilities would be required with full traceability and failure mode analysis. The procurement model would involve an evaluation of risk and establishment of security requirements along with identified levels of assurance. This would allow the procurement of “off the shelf” products that met those capability and assurance requirements, affording an appropriate balance of cost, security and flexibility.

We have observed a common theme of software quality management emphasizing (late-stage) technical testing rather than being driven by informed, risk-based decision making through consistent adoption and validation of security requirements. Coding standards, vulnerability testing and other technical evaluation measures have their place in the development lifecycle. However, technical testing often does not consider the full context of the purpose of the software and the relevant risks.

Formalization of processes to identify and emphasize the traceability of the design, testing and assurance of critical functions in systems may yield higher quality products as well as reduced overall costs, particularly when we consider “late stage” repair scenarios. The direction of the executive order towards governance of the full development lifecycle could drive a valuable “rising tide” if industry heeds the lessons learned from ITSEC and other defect reduction methodologies (such as Six Sigma).

Conclusion

While it may be the case that there is little “new” within this executive order, it does promote coordinated and mandated levels of controls to respond to a growing threat to critical infrastructure. The EO can act as a call to action to implement good practices, to collaborate and communicate, as well as to raise the bar for software and service security.

The President of the United States backing security professionals on the gravity of the risks facing the industry provides a new incentive for everyone. Add to the mix common standards for determining product and vendor assurance, and it’s clear that security practices and trust benefit us all.

*Christopher Hyers, a Risk Management & Transformation Principal at Optiv is a contributor to this blog.