The 12th of May, 2022, the United Stated of America (US) published the “Executive Order on Improving the Nation’s Cybersecurity“. This executive order was a direct consequence of the infamous SolarWinds incident that allegedly affected the US government. This regulation tries to unify, establish, and improve the cybersecurity policies and processes of the whole US Federal Government.

This executive order is very important for cloud service providers (CSPs) and companies that develop software, specially for those that are providers or want to be providers of the US government and its agencies. It is also important for other companies because this kind of requirements usually propagate when the ones that need to comply (US agencies) require their providers to comply too.

There is a lot (and probably necessary) bureaucratic language that makes it difficult to identify, on a first read, the specific cybersecurity requirements that affect or can affect providers. In this article I have tried to extract all cybersecurity requirements, and I have interpreted how companies can comply with them. I say “defined requirements” because many details are not defined in this executive order. What it establishes is that within <number> days of the date of the order <someone> will define <something> with more detail. They establish that something needs to be defined in the future 35 times in the document.

Also it is important to mention that my interpretation is not necessarily correct and even if it is correct, the implementation might not be appropriate for your company.

Below I list the sections where I have identified relevant requirements. In each section I have copied and pasted between quotes the exact words found in the executive order. I have used […] when in the executive order there is more text before or after the words. The text that is not between quotes is text that I have added for clarification or for the sentence to make sense. I have added “REQ#” to each requirement just to make it easy to identify the different requirements and to be able to refer to them.

Requirements

Section 1. Policy.

REQ1: “The private sector must adapt to the continuously changing threat environment”.

REQ2: The private sector must “ensure its products are built and operate securely”.

REQ3: The private sector must “partner with the Federal Government to foster a more secure cyberspace”.

These first three requirements are very generic, but they establish some important concepts. The providers must adapt continuously. This is not a one time effort, therefore a system is necessary to maintain the compliance.

REQ2 makes it clear that these requirements affect both development and operation.

REQ3 establishes the general idea that cooperation between the providers and the US Federal Government is an essential part of the order.

Sec. 2. Removing Barriers to Sharing Threat Information.

REQ5: “[…] current contract terms or restrictions may limit the sharing of such threat or incident information with executive departments and agencies […]”, “Removing these contractual barriers and increasing the sharing of information about such threats, incidents, and risks are necessary […]”

Providers will need to remove contractual barriers that impede sharing cybersecurity information with the US Federal Government. What exactly should be removed? In the following requirements the order clarifies this a bit, but essentially, this is something to be defined.

REQ6: “[…] service providers (shall) collect and preserve data, information, and reporting relevant to cybersecurity event prevention, detection, response, and investigation on all information systems over which they have control, including systems operated on behalf of agencies, consistent with agencies’ requirements;”

This section is a lot about cybersecurity incidents. This requirement establishes that service providers must collect and preserve cybersecurity data. It is necessary that cloud services and products have the capability of logging information about security events that can be interesting during the investigation of a potential security breach. For example, data about authentication: who has logged, when, and from where. Each solution should defined during its design the list of events that would be interesting to investigate during a potential security breach and the solution should allow to generate logs about them.

REQ7: “service providers (shall) share such data, information, and reporting, as they relate to cyber incidents or potential incidents relevant to any agency with which they have contracted […]”

Service providers must be ready to share that information in case it is necessary.

REQ8: “service providers (shall) collaborate with Federal cybersecurity or investigative agencies in their investigations of and responses to incidents or potential incidents on Federal Information Systems […]”

Service providers should have enough resources to collaborate with the Federal Government and agencies. In order to be able to collaborate, the providers teams should be trained on incident response, in the tooling they have available, and on the data they can access to perform the investigation.

REQ9: Service providers shall collaborate with Federal cybersecurity or investigative agencies “[…] by implementing technical capabilities, such as monitoring networks for threats in collaboration with agencies they support, as needed;”

Depending on the service provided, providers might even be required, based on this requirement, to implement network monitoring capabilities in collaboration with Federal agencies.

REQ10: “service providers (shall) share cyber threat and incident information with agencies […]”, that information must be shared “[…] in industry-recognized formats for incident response and remediation.”

This requirement is very similar to others already defined, but it adds an interesting bit: service providers must be ready to share incident information in industry-recognized formats. I interpret that the order is talking about indicators of compromise (IoCs) and that it is referring to standards like STIX/TAXII.

REQ11: “service providers (shall) share data with agencies, CISA, and the FBI as may be necessary for the Federal Government to respond to cyber threats, incidents, and risks.”

The order makes it clear that incident information will be shared with different US organizations depending on the case.

REQ12: “information and communications technology (ICT) service providers entering into contracts with agencies must promptly report to such agencies when they discover a cyber incident involving a software product or service provided to such agencies or involving a support system for a software product or service provided to such agencies” “ICT service providers must also directly report to CISA whenever they report […] to Federal Civilian Executive Branch (FCEB) Agencies, and CISA must centrally collect and manage such information;”

Service providers will need to report to the agencies and other US organizations any security incident related to a product or service (or their support systems). This is more important than it seems: some organizations try to hide security incidents. With this executive order they will have a mandate to communicate them.

Sec. 3. Modernizing Federal Government Cybersecurity.

REQ13: “cloud-computing environments with Zero Trust Architecture.”

Zero Trust Architecture! And what is that? There is not a clear definition, but in general, we say Zero Trust Architecture is a systems architecture where there are no trusted components or zones. In that scenario, every component needs to authenticate to another component to establish communication and the communication should be always encrypted as there are no trusted networks.

REQ14: “multi-factor authentication and encryption for data at rest and in transit”

Here the order is absolutely explicit: multi-factor authentication and encryption for data at rest and in transit must be used to protect all the systems in the Secure Development Life Cycle (SDLC) of the service. Additionally, the product or service itself should allow the customer to enable multi-factor authentication.

Sec. 4. Enhancing Software Supply Chain Security.

“secure software development environments […]”:

The following requirements are related to the software development environments.

• REQ15: “using administratively separate build environments;”

Building means different things depending on the technology but basically it means compiling the software. Build environments are important for the executive order. The risk it tries to reduce is an attacker having access to the build environment and introducing a trojan or backdoor within the software.

This requirement establishes that there must exist some kind of isolation between the different build environments so if one is compromised, there is some security that isolates the attacker to that environment and it’s not easy to move laterally. What it tries to avoid is that if the build environment for software A is compromised, that not all the software of the company is compromised.

• REQ16: “auditing trust relationships;”

Trust relationships are the paths that attackers use for lateral movement and escalation of privileges. We should reduce those paths to a minimum, but if it is necessary that they exist, they have to be audited: we should know everything about the existing trusts, who has used them, when, how, etc.

• REQ17: “establishing multi-factor, risk-based authentication and conditional access across the enterprise;”

As mentioned before, multi-factor authentication is essential for the executive order. Here it is reiterated by requiring it for the build environment systems, not only for the software or the service.

• REQ18: “documenting and minimizing dependencies on enterprise products that are part of the environments used to develop, build, and edit software;”

The more dependencies, the more attack surface. We must know them and we must reduce them to the minimum. We should identify and remove the dependencies that are present but not used for different reasons. Then, they have to be up-to-date. The last step is thinking whether they are necessary or a minimum amount of custom code will suffice.

• REQ19: “employing encryption for data;”

Encryption at rest and in transit is required across the different sections of the order. I would suggest to not get crazy and prioritize where encryption provides more value. Some encryption may not increase the security and can increase a lot the complexity and the effort needed to maintain it. Focus on the use cases where encryption do really increase security in a relevant way.

• REQ20: “monitoring operations and alerts and responding to attempted and actual cyber incidents;”

Monitor operations related to build environments and report security incidents.

We should consider the build environments as production environments and we should apply the same security controls. I frequently hear: “this vulnerability is not in production so we are not affected”. If the vulnerability is there, in the build environment, we should consider it a first level vulnerability and fix it with the same or more priority than other vulnerabilities.

REQ21: “generating and, when requested by a purchaser, providing artifacts that demonstrate conformance […]”

This requirement gives the executive order a spirit of certification estandard: it requires that the providers demonstrate compliance. In the audit world, the way of demonstrating compliance is by generating evidence. It is not only necessary to comply, it is necessary to generate artifacts that an independent auditor could review to evidence that the company is compliant. Documents, registers, logs, etc. are important evidence. Any process defined to comply with these requirements should embed steps to generate evidence that can be shown to auditors in case of being required.

REQ22: “employing automated tools, or comparable processes, to maintain trusted source code supply chains, thereby ensuring the integrity of the code;”

For controls to ensure the integrity of the code we can use hashes and signatures. A current way of protecting the integrity of the code is using a code repository as Gitlab and protect it as much as possible. Additionally, we can configure it to require that developers sign their commits, providing an additional level of security.

REQ23: “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;”

This requirement is about including SAST and SCA tools in the CI/CD system. Solutions as Gitlab have a CI engine integrated where we can execute code scanning every time a pull request is created, blocking it from being merged if the scan finds issues with severity above a threshold.

In the past, cybersecurity has done these scans a gate at the end of the development of a solution. What is needed is to embed this process in the developers workflow, as soon as possible, and not wait until the end of the development.

REQ24: “providing, […], artifacts of the execution of the tools and processes described […]” above.

We have to be able to provide evidence of the execution of these tools. Execution logs and result reports would suffice.

REQ25: “[…] making publicly available summary information on completion of these actions, to include a summary description of the risks assessed and mitigated;”

I don’t think it is necessary to include all the details, but the company is required to publish information about the mechanisms implemented and how they reduce the risks.

REQ26: “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;”

Provenance: the place of origin of something. What is required here is that we have traceability of any component used in the service. If this were food, if we get poisoned by eating this meat, we should be able to go to the store and ask where that meat comes from and it should be possible to go back to the truck that transported the meat, the slaughterhouse where the cow was killed, the field where the cow used to eat, etc. In software, we need to know from where we downloaded a package, date, time, hash when it was downloaded, and any other data that helps identify the origin of the component.

If we download dependencies directly from the Internet by using public registers like PyPI, RubyGems, etc. we won’t have good provenance. Software companies should have their own internal dependency repositories. That way they reduce the dependency from public registers and they improve the provenance data by centralizing in one place when a piece of software was downloaded, from where, etc.

Companies can also implement controls like GuardDog in the internal repositories to improve the security of the dependencies.

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

The Software Bill of Materials (SBOM) is one of the concepts more repeated after the executive order was published. An SBOM is an inventory, a list, of the components of a software or service. If a software was a Spanish omelette, its SBOM would be: potatoes, eggs, oil, and salt. This inventory should be useful to identify potential security threats and vulnerabilities. For open source software, companies can generate their own SBOMs, however, for propietary software, the requirement to share SBOMs will be a game changer.

What systax an SBOM should have? There are multiple standards for SBOMS, for example, SPDX or CycloneDX. The executive order does not establish which format should be used. It is up to the companies to decide.

REQ28: “participating in a vulnerability disclosure program that includes a reporting and disclosure process;”

Vulnerabilities cannot be kept private. If they are, customers remain at risk because they don’t know that they have been exposed and that they need to upgrade the software. Additionally, the providers should be open to receive reports about vulnerabilities and they should have processes in place to gather that information and act upon it.

REQ29: “ensuring and attesting, to the extent practicable, to the integrity and provenance of open source software used within any portion of a product.”

Ensuring integrity and provenance when using software is difficult, especially if they use many dependencies from different places. In open source, we see that each application use dozens of dependencies, and we are aware of the risk. When we use propietary software, we don’t see the dependencies it uses and it might be using the same number or more. The thing is that we have to ensure provenance as much as possible and using internal artifact repositories is a good mechanism.

REQ30: “applying practices of least privilege, network segmentation, and proper configuration.”

These are basics that must be taken into account.

• Least privilege: only people that need access to systems or information should have access to them.
• Network segmentation: although the segmentation of the network is a bit out of date in the Kubernetes world, we still should identify and use proper security boundaries and isolate assets with different risks.
• Proper configuration: can there exist other kind of configuration?

REQ31: “manual or automated testing (such as code review tools, static and dynamic analysis, software composition tools, and penetration testing)”

Testing, testing, and testing: code reviews, static analysis (SAST), dynamic analysis (DAST), software composition (SCA), penetration testing…I would add red teaming, as a special case of penetration test; and fuzzing that can be seen as a subset of dynamic analysis.

There are an infinite number of tools of each type, but to I would like to mention a few: semgrep for SAST; ZAP and nuclei for DAST; and DependencyCheck for SCA.

We should establish these processes as embeded and transparent in the development life cycle as possible.

REQ32: “secure software development practices”

Do we train our developers to avoid code injections? XSS? Broken authentication and authorization? We have to be sure our developers apply good secure software development practices everyday. One way of supporting this objective is to perform code reviews. By doing good planned code reviews, developers can share knowledge about secure development practices and improve their skills.

Sec. 8. Improving the Federal Government’s Investigative and Remediation Capabilities.

REQ33: “[…] collect and maintain […]” “Information from network and system logs on Federal Information Systems […]” “[…] necessary to address a cyber incident […]”

In this requirement, the executive order is again explicit about logs. Providers have to store logs that can be used to investigate potential cyber security incidents.

REQ34: “Logs shall be protected by cryptographic methods to ensure integrity once collected and periodically verified against the hashes throughout their retention.”

The logs shall be protected correctly. Based on this requirement, providers have to use any cryptographic method they can use to protect the integrity of the logs. It seems that good permissions are not enough. The provider should have a process in place to verify the hashes at planned intervals.

REQ35: “Data shall be retained in a manner consistent with all applicable privacy laws and regulations.”

All these data retention requirements must comply with any privacy laws and regulations applicable, so for example, in Europe, this data retention should comply with GDPR.

Conclusions

The US “Executive Order on Improving the Nation’s Cybersecurity” if applied and enforced correctly will improve the security of the software and the supply chain and collaboration between the US Federal Government and its providers. Besides collaboration and information sharing, the executive order focus a lot on how software is developed, built, and deployed, that is what we call the software supply chain.

The executive order does not define many specific security controls. A lot of requeriments are pending and much of what is defined is lightly specified, giving space to companies to define how to comply with the requirements.