By Eric Byres
One week ago, President Biden signed the Executive Order on Improving the Nation’s Cybersecurity.

By the next morning, I had already waded through the content several times. Compared to any Executive Order (EO) I’ve seen, this is a massive and complex policy document. The average length of an EO is under 3½ pages; most are just 1 or 2 pages.

Executive Order 14028 weighs in at 18 pages, but it isn’t just the length that is unprecedented: The order includes 74 actionable directives. Forty-five of those directives have defined due dates, many of which are linked to the completion of other directives. Add to all of this a plethora of acronyms and abbreviations common to the cybersecurity world and the result is a document that is going to take months to fully decipher.


What Does this Mean?
The new order repeatedly calls out Operational Technology (OT) in both the introduction to the EO and the EO FACT Sheet. However, it switches focus to a more general term, Critical Software, as it spells out the list of requirements and directives that will be mandatory for all software sold to the U.S. Government.

So, what exactly do they mean by Critical Software? Right now, we can’t be sure. However, after the recent Colonial Pipeline incident, I think it’s probably safe to assume that OT software is included in this category. A definitive answer on this isn’t far off though: The Director of CISA is tasked with providing a list of software categories meeting the definition of Critical Software by July 26.

Of course, the companies affected by this order don’t have months to understand how it will impact them. They need to figure this out now so they can implement a plan to meet the new requirements. This is especially true for companies that supply the aforementioned Critical Software to the U.S. Government.

Key Takeaways
With so much information to absorb, I thought it would be helpful to provide a quick summary of what I believe are the key takeaways in Executive Order 14028.

I’ll start with the observation that securing the software supply chain is arguably the major focus of this EO. Almost 1/3 of the document’s policy statements are in the Enhancing Software Supply Chain Security section. This is no surprise after the SolarWinds attack in December infiltrated all five branches of the U.S. Military, the Pentagon, the State Department, the National Security Agency, the White House, and a whole lot of other significant targets. That kind of widespread havoc was certain to set the tone for this EO.

While some media stories suggest the EO is a response to the Colonial Pipeline attack, I don’t believe that to be the case. A document of this size and depth couldn’t have been written over the weekend between that attack and the time the EO released. Its scope is simply much further reaching and broader than the ransomware attack at the center of the Colonial Pipeline issue for that to be the case.

While the goals of this major initiative to secure the software supply chain aren’t obvious on first reading of the EO, the accompanying EO Fact Sheet proves helpful. I’ve extracted four objectives from that document stand out for me:

  1. The Executive Order will improve the security of software by establishing baseline security standards for development of software sold to the government…
  2. Requires developers to maintain greater visibility into their software and making security data publicly available….
  3. It stands up a concurrent public-private process to develop new and innovative approaches to secure software development and uses the power of Federal procurement to incentivize the market…
  4. Creates a pilot program to create an “energy star” type of label so the government – and the public at large – can quickly determine whether software was developed securely.

It’s unclear yet how exactly the order plans to achieve these objectives. What is clear is that Software Bill of Materials (SBOM) is a core concept with no fewer than 14 mentions. Two key directives related to SBOMs include:

4 (e) (vii) providing a purchaser a Software Bill of Materials (SBOM) for each product directly or by publishing it on a public website;
4 (f) Within 60 days of the date of this order, the Secretary of Commerce, in coordination with the Assistant Secretary for Communications and Information and the Administrator of the National Telecommunications and Information Administration, shall publish minimum elements for an SBOM.

Click here to view the full timeline.

As a point of interest, the aDolus team has been actively involved with the National Telecommunications and Information Administration (NTIA) SBOM Framing Committee in defining and testing these elements.

Bottom Line
Suppliers of ICS/OT products to the government (or suppliers to a company that supplies to the government) have some work to do. The security information these companies are required to share with clients will change in the next 365 days. It takes a lot of digging to understand the exact schedule, but the following timeline should help. It includes the due dates for the various supply chain directives, highlighting those that most impact software suppliers.

This EO is going to impact the industry in a way that no other U.S. cyber legislation ever has. It will also ripple far beyond the U.S., especially the Middle East, where sovereign oil companies are looking to duplicate these requirements for their OT Software Supply Chain. Even if your company does not sell to the U.S. government, expect to feel the effects of this EO over the next few years.
Eric Byres is an ISA Fellow and internationally known expert on OT cyber security. He and his team at aDolus Technology has been researching and creating Software Bill of Materials (SBOMs) for the OT market since 2017.