Unpacking EO14028: Improving the Nation's Cybersecurity - Pt. 1


Late Wednesday night President Biden signed the Executive Order on Improving the Nation’s Cybersecurity.  

Compared to any Executive Order (EO) I’ve seen, this is a massive and complex policy document: the average length of an EO has been under 3½ pages; most are just 1 or 2 pages. This EO weighs in at 18 pages with 74 actionable directives. Forty-five of those directives have defined due dates, many linked to the completion of other directives. Add in the soup of acronyms and abbreviations common to the cybersecurity world and you have a document that is going to take months to fully decipher.

Unfortunately, companies don’t have months to understand how this EO will impact them. This is especially true for companies that supply Critical Software to the U.S. government (more on this in a bit). So let me provide a quick summary of the key takeaways (more in-depth analysis will follow in the days to come — be sure to click Subscribe when you've read to the end to get notified of updates).

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. (I’ve seen media stories suggesting this EO is a response to the Colonial Pipeline attack, but this document clearly wasn’t written over the weekend. Its scope is much further reaching and broader than ransomware attacks.) 

The goals of this major initiative to secure the software supply chain aren’t obvious on first reading of the EO. But head to the accompanying EO Fact Sheet and four objectives stand out. I’ve quoted these directly from the Fact Sheet:

  1. The Executive Order will improve the security of software by establishing baseline security standards for development of software sold to the government... 

  2. requiring 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. it 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.

How exactly the EO plans to achieve the above objectives is something I will lay out in my next blog post. That said, Software Bill of Materials (SBOMs) is a core concept with no less than 14 mentions. Two key directives 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.

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

I’ll also point out that the EO repeatedly calls out Operational Technology (OT) in both the introduction of the EO and the EO Fact Sheet. Then the EO switches focus to a more general term, Critical Software, as it spells out the list of requirements and directives that will be required for all software sold to the U.S. Government. After last week's Colonial Pipeline incident, you can be pretty confident that OT software is included as Critical Software. We won’t have to wait too long to find out for sure: the Director of CISA is tasked with providing a list of software categories meeting the definition of Critical Software by July 26.

The bottom line? If you are a supplier of ICS/OT products to the government (or a supplier to a company that supplies to the government), the security information you must share with your clients is going to change in the next 365 days. It takes a lot of digging to understand the exact days, so my team has created a timeline of the due dates for the various supply chain directives, highlighting those that most impact software suppliers:

We’ll be providing additional analysis of the EO over the next two weeks, focusing specifically on the software supply chain requirements and how they will impact the OT market (subscribe to this blog down below to be notified of the next report). In the meantime, if you are looking for guidance on creating SBOMs or enriching SBOM data, or on software supply chain security in general, please reach out. We’ve been researching and creating SBOMs for the OT market since 2017 and we are happy to help you.

Posted in ICS/IoT Upgrade Management, vulnerability disclosure, Regulatory Requirements, Vulnerability Tracking, Supply Chain Management, SBOM, EO14028

Leave a Reply