Difference between revisions of "Supply Chain"
(→DevOps) |
(→Risk Management) |
||
Line 72: | Line 72: | ||
===Risk Management=== | ===Risk Management=== | ||
− | The US DoD has published [https://www.acq.osd.mil/log/MR/.PSM_workshop.html/2019_Files/Day_Two/3_Supply_Chain_Risk_Management_Mulligan.pdf 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: | + | * |
+ | * The US DoD has published [https://www.acq.osd.mil/log/MR/.PSM_workshop.html/2019_Files/Day_Two/3_Supply_Chain_Risk_Management_Mulligan.pdf 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: | ||
# JS J4/EUCOM Cyber Mapping Initiative | # JS J4/EUCOM Cyber Mapping Initiative | ||
# 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) | # 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) |
Revision as of 16:50, 23 April 2022
Contents
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.
- NIST began accepting input on IoT for Supply Chain Assurance on 2021-12-01 to be published as NIST SP 1800-34 parts A, B and C on Architecture and "How-To" Guides.
- Securing the Industrial Internet of Things is NCCoE focused on Infrastructure like the Electric distribution network.] aka IIoT
- General IoT security is addressed in Convergent Evolution: SP 800-213, the Federal Profile, and the IoT Cybersecurity Catalog 2021-12-02
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 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:
- JS J4/EUCOM Cyber Mapping Initiative
- 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)
- DoDI 85000-1 Cybersecurity - already obsolete
- DISA SCRM Efforts
References
- ↑ 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/
- ↑ 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/
- ↑ Lilly Hey Newman, The Internet Is on Fire’ Wired (2021-12-18) https://www.wired.com/story/log4j-flaw-hacking-internet/
- ↑ 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
- See the wiki pages Trusted Computing and Wallet for more examples of supply chain problems.