復(fù)雜的供應(yīng)鏈有復(fù)雜的安全性要求，想要確保供應(yīng)鏈的安全就要盡可能地做到這些。

左右兼顧

將供應(yīng)鏈安全視為組織內(nèi)部的事情，這是一個非常局限且危險的假設(shè)。Tripwire 的產(chǎn)品管理與策略副總裁 Tim Erlin 表示“當(dāng)考慮保護(hù)供應(yīng)鏈安全時，必須同時考慮上游與下游。向我們提供產(chǎn)品的供應(yīng)商和我們作為供應(yīng)商提供產(chǎn)品的客戶都應(yīng)該在供應(yīng)鏈安全的考慮范圍內(nèi)”。

因為涉及到供應(yīng)鏈的上下游，首先就要知道供應(yīng)鏈鏈接了哪些組織。Erlin 表示“理想情況下，應(yīng)該能夠識別、處理與組織打交道的任何組織都有權(quán)訪問的數(shù)據(jù)”。

關(guān)于 API 安全性的討論有很多，大多數(shù)都集中在組織或者供應(yīng)商的 API 上。同時也應(yīng)該注意客戶要求使用的 API 和服務(wù)，保證整個供應(yīng)鏈的安全性。

合同優(yōu)先

供應(yīng)鏈中任何環(huán)節(jié)發(fā)生問題，產(chǎn)生的后果和責(zé)任都會在上下游帶來很大的影響。KnowBe4 的安全意識倡導(dǎo)官 James McQuiggan 表示“如果第三方遭受數(shù)據(jù)泄露或攻擊，雙方之間的合同應(yīng)該確定數(shù)據(jù)泄露以及為支持該類事件而進(jìn)行的程序”。原因很簡單，因為失敗可能會給組織帶來更大的風(fēng)險和損失。

盡管合同和協(xié)議傾向于考慮已知威脅與事件，但也可以對新威脅的響應(yīng)過程和程序做出安排。一些業(yè)務(wù)部門必須具有承擔(dān)合同中的法規(guī)或法律責(zé)任的義務(wù)。例如，美國國防部發(fā)布的網(wǎng)絡(luò)安全成熟度模型認(rèn)證(CMMC)框架，在未來所有國防部合同中強制規(guī)定了相應(yīng)條款。國防部的主承包商和分包商必須滿足所有國防部合同要求的 CMMC 成熟度水平，否則會被取消競爭資格。

關(guān)鍵行業(yè)中，快速響應(yīng)的能力尤為重要。NCC 區(qū)域總監(jiān) Jeff Roth 解釋說“醫(yī)療服務(wù)提供商，從實體到商業(yè)伙伴，都在進(jìn)行電子化。在快速提供病患所需數(shù)據(jù)的同時還要保證數(shù)據(jù)交付服務(wù)的安全性，這是一個具有挑戰(zhàn)性的工作”。

了解數(shù)據(jù)

在供應(yīng)鏈上下游保護(hù)數(shù)據(jù)很重要，但如果不知道共享哪些數(shù)據(jù)就無法進(jìn)行保護(hù)。尤其是只有設(shè)備彼此交換數(shù)據(jù)，將人排除在外時。

“物聯(lián)網(wǎng)設(shè)備通常是關(guān)鍵，很少有設(shè)備是孤立存在的，而物聯(lián)網(wǎng)的互聯(lián)網(wǎng)組件也反映了這種依賴性”，信息安全論壇的管理總監(jiān) Steve Durbin 如是說。“智能化需要多個設(shè)備協(xié)同工作，通常需要數(shù)量很多的設(shè)備作為輸入”。

現(xiàn)在的自動化流程可能需要 IT、OT 甚至消費類設(shè)備的參與，而不同類型的設(shè)備都有不同的安全需求。了解系統(tǒng)之間的數(shù)據(jù)流是進(jìn)行安全防護(hù)的一部分。

牢記流程

將安全問題限定在供應(yīng)鏈技術(shù)和基礎(chǔ)架構(gòu)是很自然的，但是要記住操作流程也會對安全產(chǎn)生影響。Vectra 的 Morales 表示“風(fēng)險通常也與操作流程有關(guān)，而不是只和代碼中的缺陷或漏洞有關(guān)”。

善用審查

無論對供應(yīng)鏈有多大的信任度，確保處理和移動數(shù)據(jù)時采取了必要的保護(hù)措施都是至關(guān)重要的。KnowBe4 的 McQuiggan 表示“組織需要對所有具有遠(yuǎn)程訪問權(quán)限或提供電子產(chǎn)品的供應(yīng)商進(jìn)行審查和年檢”，“信任但驗證的概念包括有關(guān)產(chǎn)品開發(fā)生命周期的第三方網(wǎng)絡(luò)安全政策的審查，這是了解產(chǎn)品漏洞的良好開始”。

Positive Technologies 的信息安全分析主管 Evgeny Gnedin 認(rèn)為“對供應(yīng)鏈攻擊來說，最危險的是攻擊者可能在很長一段時間內(nèi)都不會被注意到，而且攻擊本身也很可能會成功”。同時，Gnedin 指出多個成功的供應(yīng)鏈攻擊的示例，從針對華碩的 Rowhammer 到 NetPetya 和 Magecart 等。“通過轉(zhuǎn)向供應(yīng)鏈攻擊，使犯罪分子大大擴展了受害者的范圍。”

小也重要

在某些情況下，供應(yīng)鏈中大型組織的安全雖然處理相對麻煩，但是往往能夠提供資源從政策的指定到具體實施來保障安全。小公司則缺乏專業(yè)知識和相關(guān)資源。NCC 的 Roth 提出了一些具體的建議：

• 重點關(guān)注與每個特定關(guān)鍵供應(yīng)商相關(guān)的實際風(fēng)險和相應(yīng)的安全管控措施。小型供應(yīng)商可以掌握風(fēng)險，而不會產(chǎn)生超出這些小型供應(yīng)商承受能力的問題
• 構(gòu)建安全的基礎(chǔ)結(jié)構(gòu)，減少服務(wù)提供商的攻擊面
• 針對高風(fēng)險和中風(fēng)險的小型供應(yīng)商進(jìn)行重點網(wǎng)絡(luò)安全培訓(xùn)
• 定期監(jiān)控和反饋，進(jìn)一步幫助小型供應(yīng)商合規(guī)

高層意識

首先將風(fēng)險機進(jìn)行歸類：

• 業(yè)務(wù)風(fēng)險
• 操作風(fēng)險
• 市場風(fēng)險
• 人員風(fēng)險
• 法規(guī)風(fēng)險

供應(yīng)鏈給組織帶來的風(fēng)險既可以是戰(zhàn)略性的也可以是戰(zhàn)術(shù)性的。Digital Shadows 的 Guirakhoo 表示“當(dāng)組織依賴大量第三方，從而大大增加潛在攻擊面，這甚至?xí)永щy”。所構(gòu)成的風(fēng)險可能是戰(zhàn)略關(guān)系和伙伴關(guān)系的問題，使高級管理層意識到問題的嚴(yán)重性并將其納入決策過程以進(jìn)行響應(yīng)和補救。

關(guān)注云端

“現(xiàn)在許多重要數(shù)據(jù)都存儲在云上，這為犯罪分子提供了機會。通過攻擊云端可以破壞整個供應(yīng)鏈的安全并摧毀關(guān)鍵信息基礎(chǔ)設(shè)施”。

軟件和服務(wù)基本上由現(xiàn)有軟件、服務(wù)和模塊構(gòu)建而成，從而依賴和嵌套的產(chǎn)品越來越深。Accurica 聯(lián)合創(chuàng)始人兼首席執(zhí)行官 Sachin Aggarwal 表示“許多云基礎(chǔ)架構(gòu)和 SaaS 應(yīng)用都由許多組件構(gòu)成，通常都包含開源產(chǎn)品”，“例如，Amozon Web Services 使用 Linux、Java、Kubernetes、Xen 和 KVM，這些組件具備成本優(yōu)勢，但會帶來安全風(fēng)險，組織需要關(guān)注并減輕這些風(fēng)險”。

確定和審查軟件供應(yīng)鏈中每個組件的安全性以及云端的供應(yīng)鏈安全是一項龐大的工程，但這也是確保組織供應(yīng)鏈安全必不可少的一部分。