Difference between revisions of "Supply Chain"

From MgmtWiki
Jump to: navigation, search
(Solutions)
(DevSecOps)
Line 82: Line 82:
 
The code development paradigm gives developers the ability to create deployment packages which contain code that the developer pulled in as a dependency, often with little more than a click to download the code from a repository. The result is that some other attack on some other code body can bet included into an application package without review. A new paradigm of DevSecOps adds an additional layer that assures the code building process is not compromised.
 
The code development paradigm gives developers the ability to create deployment packages which contain code that the developer pulled in as a dependency, often with little more than a click to download the code from a repository. The result is that some other attack on some other code body can bet included into an application package without review. A new paradigm of DevSecOps adds an additional layer that assures the code building process is not compromised.
 
===DevSecOps===
 
===DevSecOps===
Is basically just DevOps with a intervening security check.
+
Is basically just DevOps with a intervening security check. Assuming that the developers were not able to build the final product, that would have been sufficient to block the Solar Winds attack.
  
 
===Risk Management===
 
===Risk Management===

Revision as of 08:54, 15 June 2022

Full Title or Meme

For Identity Management in a digital world the important parts of the supply change are the user hardware and software and the entire cloud ecosystem.

Context

  • The supply chain involves two concerns in this wiki:
  1. the source and identity of software and hardware used in computer systems,
  2. the data contained in logistics operations that are maintained in computer data bases.
  • In both cases identification and integrity of supplier and the goods throughout the entire life-cycle (including the ultimate disposition) need to be documented.
  • Typically, the only parts of the first defined Supply Chain that a user or developer sees are the immediate hardware or software decision that they make. The full scale of all the parts that are drawn into the local system by those decisions are seldom investigated, even when a Threat Model is created.
  • The US NCCoE has established a Supply Chain Assurance effort focused on the hardware.
  • While the core problem is security of the entire supply chain, most the current effort seems to be at detecting and responding to breaches.[1]

Problems

  • The most common problem of Supply Chain corruption is indifference. Typically when included in a Threat Model the response will be "you must be in real trouble if you don't know where your computers are coming from." It is still likely that most threat analysis will omit any concern with supply chain corruption.
  • Even though it may be incredibly difficult to get management to consider supply chain issues, it is not useful to address any security issues if you cannot even be sure that the computers and the software delivered are free of deliberate or accidental vulnerabilities.
  • Portable hardware devices have proven to be an easy attack target. In the simplest case a USB file key is left lying around where someone might use it and thus infect the computer. In more sophisticated attacks the hardware will be altered in the supply chain before it reaches the intended target user. For example Criminals are mailing altered Ledger devices to steal cryptocurrency [2]
  • The exploits have started to surface with (2020) Solar Winds infections that continue to be discovered. There the problem was a dll that was replaced in the development chain that was never validated.
  • Developer tools make it very easy to inject dependence's on external packages with just a click of the mouse. the article on "Dependency Confusion: How I Hacked Into Apple, Microsoft and Dozens of Other Companies" shows how easy that act can be exploited. The vulnerability has always been their, but as other exploits are blocked, this one becomes more attractive.
  • Another tool attack that appeared in 2015 in Travis CI was still the source of leaked developers Credentials in 2022.[3] This is a case of a tool that enables continuous integration of updates into running code. So that any code that uses these tools can have one of the dependencies compromised, which infects the delivered end product.

Dependency Injections

This is about a broad meaning of dependency injections that apply whenever a download application takes a dependency on code from any source outside of the current development project.

"Dependency Confusion: How I Hacked into Apple, Microsoft and Dozens of Other Companies" shows how easy that act can be exploited. The vulnerability has always been there, but as other exploits are blocked, this one becomes more attractive.

Getting the full Chain

The Biden EO on cybersecurity calls out the SBOM, the software bill of materials, as critical to security of government security. Usually, the SBOM is limited to the software supply chain for one approved acquisition. The problem is the aggregation of software that can occur beyond what is specified. One very good example is offered by the government's own use of the PIV card to access email. When a employee or contractor is trying to access government email at home, they need a smart card reader. If they go to Amazon to find one, they will likely get a cheap reader that comes with driver software loaded from the internet and filled with malware.[4]

Trusting Trust

  • The core problem is "Where does Trust Start"?
  • Many developers start with "Trust on First Use" which allows the developer to take a trust dependency and then store the public key used in that decision to automatically allow updates.
  • Even that TOFU policy does not get to the real core of the problem that was addressed by Ken Thompson on Multics. Specifically, what if the developer tools are compromised?
  • David A. Wheeler addressed the problem in his thesis on Trusting Trust
    An Air Force evaluation of Multics, and Ken Thompson’s Turing award lecture (“Reflections on Trusting Trust”), showed that compilers can be subverted to insert malicious Trojan horses into critical software, including themselves. If this “trusting trust” attack goes undetected, even complete analysis of a system’s source code will not find the malicious code that is running. Previously-known countermeasures have been grossly inadequate. If this attack cannot be countered, attackers can quietly subvert entire classes of computer systems, gaining complete control over financial, infrastructure, military, and/or business system infrastructures worldwide. This dissertation’s thesis is that the trusting trust attack can be detected and effectively countered using the “Diverse Double-Compiling” (DDC) technique, as demonstrated by (1) a formal proof that DDC can determine if source code and generated executable code correspond, (2) a demonstration of DDC with four compilers (a small C compiler, a small Lisp compiler, a small maliciously corrupted Lisp compiler, and a large industrial-strength C compiler, GCC), and (3) a description of approaches for applying DDC in various real-world scenarios. In the DDC technique, source code is compiled twice: once with a second (trusted) compiler (using the source code of the compiler’s parent), and then the compiler source code is compiled using the result of the first compilation. If the result is bit-for-bit identical with the untrusted executable, then the source code accurately represents the executable.

Signed Code

When a company signs an application package, the concept is that the application is safe to run. As we have seen with the Solar Winds it is possible for an attacker to replace a piece of third-party code with one that contains malware. They the signed package seems to have all of the right dependencies, but those dependencies were compromised before the application was built and signed. This situation is common with devops development paradigms.

In the case of the https://www.bleepingcomputer.com/news/security/malware-now-using-nvidias-stolen-code-signing-certificates/ NVIDIA hack], the signing key itself was either exfiltrated, or the attacker was able to sign their own code which enables then to install code into the kernel of Microsoft Windows.

Open Source Code

Perhaps the largest threat to the software supply chain is the large and growing collection of utilities that are available that run on the commonly deployed operating systems with admin privilege. While the large vulnerability created by Solar Winds was proprietary code, there was at least a corporate entity to take responsibility. With a large number of open source utilities, there is no such entity to take responsibility when attacks occur. One such utility was the Apache Log4j, a Java-based logging utility originally released on 2001-01-08 by an individual. It is part of the Apache Logging Services, a project of the Apache Software Foundation. Other loggers are available, but Apache's large footprint makes this logger widespread.

A major exploit was discovered by Chen Zhaojun of Alibaba Cloud Security Team as reported by Wired "A vulnerability in the Log4j logging framework has security teams scrambling to put in a fix."[5] On 2021-11-26 Cisco entered CVE-2021-44228. A patch release came on on 2021-12-06 from Apache. On 2021-12-11 the US DHS CISA released a warning that suggested users take immediate action to patch vulnerabilities.[6] By then exploits were already proliferating across the globe. Apache's web site explains that Log4j version 1 is still supported and no warning that all old releases should be immediately killed. That is really bad advice from Apache.

Solutions

With the issuance of the Executive Order on Cyber Security, NIST was tasked with a definition of Critical Software. The report fails to even mention zero trust principles and explicitly walks back from applying Zero Trust Architecture to this definition in the final point of the definition which is:

EO-critical software is defined as any software that has, or had direct software dependencies upon, one or more components with at least one of these attributes:

  • is designed to run with elevated privilege or manage privileges;
  • has direct or privileged access to networking or computing resources;
  • is designed to control access to data or operational technology;
  • performs a function critical to trust; or,
  • operates outside of normal trust boundaries with privileged access.

NIST recommends that the initial EO implementation phase focus on standalone, on-premises software that has security-critical functions or poses similar significant potential for harm if compromised. Subsequent phases may address other categories of software such as:

  • software that controls access to data;
  • cloud-based and hybrid software;
  • software development tools such as code repository systems, development tools, testing software, integration software, packaging software, and deployment software;
  • software components in boot-level firmware; or
  • software components in operational technology (OT).
  • Consumer Software Criteria

For the Internet of Things (IoT) or any other end-point computing device the purchaser needs some sort of inventory of the components of the device to assure that the device delivered is the device ordered.

The other major category is Endpoint Security, which should be applicable to web browsers and to mobile wallets, defined as "Software installed on an endpoint, usually with elevated privileges which enable or contribute to the secure operation of the endpoint or enable the detailed collection of information about the endpoint"

  • Full disk encryption
  • Password Managers
  • Software that searches for, removes, or quarantines malicious software
  • Software that reports the security state of the endpoint (vulnerabilities and configurations)
  • Software that collects detailed information about the state of the firmware, operating system, applications, user and service accounts, and runtime environment.

The US DoD is typically not covered by NIST specs which apply to other parts of the Government. Some of the DoD efforts include:

  • USTRANSCOM prepares for third-party cyber compliance assessments (2021-04-15) "to hold commercial partners accountable for supply chain risks in preparation for broad adoption of the Defense Department’s Cybersecurity Maturity Model Certification (CMMC) program".
  • DOD revamps controversial CMMC program (2021-11-04) and promises a new strategic direction for protecting federal contract information and controlled unclassified information that allows for more self-assessment, eliminates several tiers of compliance and reduces the role of third party assessment.

For the topic of this wiki, which is: Identity, credential, and access management (ICAM), or Software that centrally identifies, authenticates, manages access rights for, or enforces access decisions for organizational users, systems, and devices. That is software that is used in these products:

  • Identity management systems
  • Identity provider and federation services
  • Certificate issuers
  • Access brokers
  • Privileged access management software
  • Public key infrastructure

DevOps

The code development paradigm gives developers the ability to create deployment packages which contain code that the developer pulled in as a dependency, often with little more than a click to download the code from a repository. The result is that some other attack on some other code body can bet included into an application package without review. A new paradigm of DevSecOps adds an additional layer that assures the code building process is not compromised.

DevSecOps

Is basically just DevOps with a intervening security check. Assuming that the developers were not able to build the final product, that would have been sufficient to block the Solar Winds attack.

Risk Management

  • The first step of risk management is risk assessment which is also a buzz word of growing relavance.
  • As a result of attacks on the supply chain, there are a large number of efforts in industry and government to find some solution. It has been suggested that the number of efforts is excessive on 2022-02-21 in the Federal News Network.
  • The US DoD has published Supply Chain Risk Management (SCRM) in 2019-05-19 which includes a definition of Cyber SCRM (or just C-SCRM) which in defined in these documents:
  1. JS J4/EUCOM Cyber Mapping Initiative
  2. DFARS 252;104-7012 (Basically just NIST SP 800-171 plus the demand that industry tell everything to the government with nothing returned in kind)
  3. DoDI 85000-1 Cybersecurity - already obsolete
  4. DISA SCRM Efforts

References

  1. Nathan Eddy, Software Supply Chain Security Becomes Prime Concern in 2022 Dice (2022-01-10) https://insights.dice.com/2022/01/10/software-supply-chain-security-becomes-prime-concern-in-2022/
  2. Lawrence Abrams, Criminals are mailing altered Ledger devices to steal cryptocurrency Bleeping Computer (2021-06-16) https://www.bleepingcomputer.com/news/cryptocurrency/criminals-are-mailing-altered-ledger-devices-to-steal-cryptocurrency/
  3. Dan Goodin, Credentials for thousands of open-source projects free for the taking—again! (2022-06-13) Ars Technica https://arstechnica.com/information-technology/2022/06/credentials-for-thousands-of-open-source-projects-free-for-the-taking-again/
  4. Brian Krebs When Your Smart ID Card Reader Comes With Malware (2022-05-17) https://krebsonsecurity.com/2022/05/when-your-smart-id-card-reader-comes-with-malware/
  5. Lilly Hey Newman, The Internet Is on Fire’ Wired (2021-12-18) https://www.wired.com/story/log4j-flaw-hacking-internet/
  6. STATEMENT FROM CISA DIRECTOR EASTERLY ON “LOG4J” VULNERABILITY (2021-12-11) US DHS CISA https://www.cisa.gov/news/2021/12/11/statement-cisa-director-easterly-log4j-vulnerability

Other Material