Difference between revisions of "Supply Chain"

From MgmtWiki
Jump to: navigation, search
(Risk Management)
(Risk Management)
Line 79: Line 79:
 
# DoDI 85000-1 Cybersecurity - already obsolete
 
# DoDI 85000-1 Cybersecurity - already obsolete
 
# DISA SCRM Efforts
 
# DISA SCRM Efforts
* The US CISA has also released a paper on [https://www.cisa.gov/supply-chain INFORMATION AND COMMUNICATIONS TECHNOLOGY SUPPLY CHAIN RISK MANAGEMENT]<blockquote>CISA, through the National Risk Management Center (NRMC), is committed to working with government and industry partners to ensure that supply chain risk management (SCRM) is an integrated component of security and resilience planning for the Nation’s infrastructure.</blockquote>
+
* The US CISA has also released a paper on [https://www.cisa.gov/supply-chain INFORMATION AND COMMUNICATIONS TECHNOLOGY SUPPLY CHAIN RISK MANAGEMENT]<blockquote>CISA, through the [https://www.cisa.gov/nrmc National Risk Management Center] (NRMC), is committed to working with government and industry partners to ensure that supply chain risk management (SCRM) is an integrated component of security and resilience planning for the Nation’s infrastructure.</blockquote>
  
 
==References==
 
==References==

Revision as of 21:08, 23 April 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

  • Typically, the only parts of the Supply Chain that a user or a 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.

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.

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."[3] 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.[4] 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 the to this definitions in the final point of the definition which is:

EO-critical software is defined as any software that has, or has 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.

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. Lilly Hey Newman, The Internet Is on Fire’ Wired (2021-12-18) https://www.wired.com/story/log4j-flaw-hacking-internet/
  4. 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