Difference between revisions of "Executive Order on Cybersecurity"

Revision as of 21:50, 27 December 2023

Full Title or Meme

Executive Order on Improving the Nation’s Cybersecurity from Joseph Biden on 2021-05-12

Context

• Issued days after the Colonial Pipeline carrying 45% of the East Coast's fuel was shut down after a ransomware attack compromised their computer systems which threatened the security of the pipeline.
• Unlike the previous EO 13800 on Cybersecurity from Trump (2017-05-11), this document includes deliverables and time lines.

Problem

"The United States faces persistent and increasingly sophisticated malicious cyber campaigns that threaten the public sector, the private sector, and ultimately the American people’s security and privacy.."

• The US has been treating cybersecurity as an offensive weapon and not addressing defense of the country, only of the military assets.
• In this order and in previous reports from the government, it is stated that barriers exist to sharing information. But they never admit that the federal government will not share threats that they find in software with the manufactures of that software.
• The order continues to push the problem that they have created by building offensive cryber weapons on the private section which is now being attacked by the very weapons that the US government has created or discovered.
• National security systems are not included until a NSM (National Security Memo) is issued by people who have no interest in seeing their authority or freedom of action diminished.

Solutions

• The Linux Foundation has created an Open Source Security Foundation which started with the o/s, naturally. They responded to the EO within a few days. It seems to be focused on critical industry primarily.

  OpenSSF is focused on improving the security of open source software (OSS) by building a broader community with targeted initiatives and best practices. It will start with a focus on metrics, tooling, best practices, developer identity validation and vulnerability disclosures best practices. In the future, there is a plan to focus resources on the most mission-critical software identified by Harvard’s Lab for Innovation Science. The OpenSSF was established on the premise that security researchers need a mechanism to allow them to collaboratively to address methods needed to secure the open source security supply chain. It recognizes that security researchers across the globe within organizations have common interests and concerns. OpenSSF facilitates sustained dialogue and project work among private entities, foundations and academia.

• The next effort by the OpenSSF was a Security Scorecards for Open Source Projects 2021-11-06 that built a scrore card entirely from a GitHub repo..

  The goal of Scorecards is to auto-generate a “security score” for open source projects to help users as they decide the trust, risk, and security posture for their use case. This data can also be used to augment any decision making in an automated fashion when new open source dependencies are introduced inside projects or at organizations. For example, organizations may decide that any new dependency with low scores has to go through additional evaluation. These checks could help mitigate malicious dependencies from getting deployed to production systems like we’ve seen recently with malicious NPM packages..

Buzz Word Bingo

• Zero trust architecture as defined by NIST
• Software as a Service SaaS (aka Cloud Technology)
• Cloud-service governance framework (a range of services and protections available to agencies based on incident severity.
• Multi-factor AuthN
• data at rest and in transit --- ENCRYPTION
• Critical software aka admin, root or sudo access.
• security and integrity of the software supply chain (esp. wrt "critical software")
  • Such guidance shall include standards, procedures, or criteria regarding: (note in particular the SBOM)

         (i)     secure software development environments, including such actions as:
             (A)  using administratively separate build environments;
             (B)  auditing trust relationships;
             (C)  establishing multi-factor, risk-based authentication and conditional access across the enterprise;
             (D)  documenting and minimizing dependencies on enterprise products that are part of the environments used to develop, build, and edit software;
             (E)  employing encryption for data; and
             (F)  monitoring operations and alerts and responding to attempted and actual cyber incidents;
         (ii)    generating and, when requested by a purchaser, providing artifacts that demonstrate conformance to the processes set forth in subsection (e)(i) of this section; 
         (iii)   employing automated tools, or comparable processes, to maintain trusted source code supply chains, thereby ensuring the integrity of the code;
         (iv)    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;
         (v)     providing, when requested by a purchaser, artifacts of the execution of the tools and processes described in subsection (e)(iii) and (iv) of this section, and making publicly available summary information on completion of these actions, to include a summary description of the risks assessed and mitigated;
         (vi)    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;
         (vii)   providing a purchaser a Software Bill of Materials (SBOM) for each product directly or by publishing it on a public website;
         (viii)  participating in a vulnerability disclosure program that includes a reporting and disclosure process;
         (ix)    attesting to conformity with secure software development practices; and
         (x)     ensuring and attesting, to the extent practicable, to the integrity and provenance of open source software used within any portion of a product.

SBOM

“Software Bill of Materials” or “SBOM” means a formal record containing the details and supply chain relationships of various components used in building software. Software developers and vendors often create products by assembling existing open source and commercial software components. The SBOM enumerates these components in a product. It is analogous to a list of ingredients on food packaging. An SBOM is useful to those who develop or manufacture software, those who select or purchase software, and those who operate software. Developers often use available open source and third-party software components to create a product; an SBOM allows the builder to make sure those components are up to date and to respond quickly to new vulnerabilities. Buyers can use an SBOM to perform vulnerability or license analysis, both of which can be used to evaluate risk in a product. Those who operate software can use SBOM to quickly and easily determine whether they are at potential risk of a newly discovered vulnerability. A widely used, machine-readable SBOM format allows for greater benefits through automation and tool integration. The SBOMs gain greater value when collectively stored in a repository that can be easily queried by other applications and systems. Understanding the supply chain of software, obtaining an SBOM, and using it to analyze known vulnerabilities are crucial in managing risk.

• Commentary

It is not clear who will be responsible for defining a SBOM. Here is one current problem. There is a open source product did:orb that includes a make file that depends on GCC (the Gnu Compiler). Now the problem is that there is no way to build the code without these tools. I am unclear how it could be possible to know if the tools provided any contribution the the finished products if it is required to build the product. So, is the GCC part of the did:orb SBOM? The following wiki page contains a sample SBOM, Did:orb#Software_Bill_of_Materials.

Zero Trust Architecture

“Zero Trust Architecture” means a security model, a set of system design principles, and a coordinated cybersecurity and system management strategy based on an acknowledgement that threats exist both inside and outside traditional network boundaries. The Zero Trust security model eliminates implicit trust in any one element, node, or service and instead requires continuous verification of the operational picture via real-time information from multiple sources to determine access and other system responses. In essence, a Zero Trust Architecture allows users full access but only to the bare minimum they need to perform their jobs. If a device is compromised, zero trust can ensure that the damage is contained. The Zero Trust Architecture security model assumes that a breach is inevitable or has likely already occurred, so it constantly limits access to only what is needed and looks for anomalous or malicious activity. Zero Trust Architecture embeds comprehensive security monitoring; granular risk-based access controls; and system security automation in a coordinated manner throughout all aspects of the infrastructure in order to focus on protecting data in real-time within a dynamic threat environment. This data-centric security model allows the concept of Least Privileged access to be applied for every access decision, where the answers to the questions of who, what, when, where, and how are critical for appropriately allowing or denying access to resources based on the combination of sever.

• Commentary

As written this sounds indistinguishable from the old principle of Least Privilege. Everything old is new again. It is not clear if Kerbeos, which bundles all of a user's privileges into a packet is compatible with this. Perhaps that depends on the expiry time of the Kerberos ticket? It does appear that a permission package would need to be created for every "application" that a user accessed rather than relying on the Kerberos ticket. While that sounds easy, it might result in unexplained failures of apps that worked before it was applied.

References