符合14028號行政命令（EO）要求的“關鍵軟體”定義

2021年6月25日

引言

2021年5月12日頒佈的14028號行政命令《改善國家網路安全》要求國家標準技術研究院（NIST）釋出“關鍵軟體”一詞的定義。

 

(g) 在本命令頒佈45天內，商務部長（透過NIST院長）須在與國防部長（透過NSA局長）、國土安全部部長（透過CISA局長）、OMB局長以及國家情報總監討論後釋出“關鍵軟體”一詞的定義，並將其納入根據本條（e）款制定的指南中。該定義應說明執行所需的許可權或訪問級別、與其他軟體的整合和依賴性、是否需要直接訪問網路和計算資源、影響信任的關鍵功能的效能以及受到入侵時可能導致的潛在損害。

 

該行政命令要求網路安全與基礎設施安全域性（CISA）依據所釋出的“關鍵軟體”定義，制定一份符合命令要求的相關軟體類別和產品清單。

 

(h) 在根據本條（g）款釋出定義後30天內，國土安全部部長（透過CISA局長）須與商務部長（透過NIST院長）討論，確定符合依據本條（g）款釋出的“關鍵軟體”定義的當前正在使用或採購流程涉及的軟體類別和產品清單，並提供給各機構。

 

為了讓定義符合實際使用情況，NIST向相關人群徵集意見，舉辦虛擬研討會收集資訊，與CISA、行政管理和預算局（OMB）、國家情報總監辦公室（ODNI）和國家安全域性（NSA）協商確定定義，提出分階段實施的構想，並初步擬定了適用於初始階段的通用軟體類別清單。CISA和OMB將就如何根據行政命令應用該定義提供指導。NIST與CISA和OMB密切合作，確保定義和建議與相應計劃一致。

 

本文從背景資訊和“關鍵”一詞的上下文入手，提出了分階段實施的構想；根據行政命令的要求定義了“關鍵軟體”一詞，初步擬定了符合該定義的軟體清單，並建議將清單納入初始實施階段。文章最後部分是常見問題（FAQ）解答。CISA將為初始和後續實施階段確定最終的軟體類別。

 

背景

最近發生的事件表明，聯邦政府必須加大力度，查明、阻止、防護、檢測和響應惡意網路行動和攻擊者。尤其需要注意的是，威脅行為者會利用普遍使用的軟體、複雜的底層程式碼以及軟體開發和分發活動發動攻擊。本文所述行政命令有多個目標，包括協助制定安全基線，確保聯邦政府使用的關鍵軟體產品的安全。軟體被標為“EO-關鍵”後，後續會有一系列其他活動，包括聯邦政府如何購買該關鍵軟體以及部署後如何進行管理。重點是，該行政命令著力對軟體購買進行限制，只允許購買滿足安全措施的軟體，例如採用了命令第4（e）款中定義的安全開發流程和完整性檢查。

 

由於命令覆蓋範圍廣泛以及對政府執行和軟體市場有潛在影響，NIST對於定義“關鍵軟體”設定了以下目標：

· 清晰–該計劃的實施將推動整個聯邦政府的活動，並對軟體行業產生影響。提供清晰的定義供軟體行業和政府使用，這對命令的成功實施至關重要。

· 可行–實施命令時必須考慮到軟體行業的執行機制，包括產品開發、採購和部署。軟體市場是動態變化、不斷髮展的，軟體的開發、引入和使用方式也在快速變化。軟體可作為產品、產品的一部分或服務購買。軟體通常是模組化的，包含許多元件。

 

“關鍵”一詞有許多現成的定義和用法。大多數是圍繞技術如何支援各種任務或流程，如“關鍵安全”或“關鍵基礎設施”。本文所述命令中該術語的用法略有不同，它不是基於軟體的使用方法，而是基於特定軟體的屬性，這些屬性使得軟體在大多數用例中都是關鍵存在。也就是說，它主要針對的是與網路運營和安全基礎設施相關的關鍵功能。這與“高價值資產”計劃下的“聯邦民用企業基本IT”的概念類似。

 

為了將行政命令下的“關鍵”定義與該詞的通用用法區分開來，在容易混淆時，我們將會使用“EO-關鍵”一詞進行明示。

 

方法

考慮到軟體市場的規模、範圍和複雜性以及政府實施行政命令所需的基礎設施，NIST已與關鍵機構就分階段實施EO-關鍵軟體供應鏈安全保護的設想進行了溝通。透過這種分階段方法，聯邦政府和軟體行業能夠循序漸進地實施行政命令，及時提供反饋，逐步改進流程。

 

定義和說明材料

本節對EO-關鍵軟體進行了定義，並透過表格初步列出了軟體類別以及說明資訊，供初期實施時參考。之後，CISA將根據定義提供軟體類別的權威列表，用於初始實施階段。該權威列表擬定後，將在此處提供連結。

 

最後，本文列出了有關定義解釋、分階段方法等方面的常見問題並進行了解答。

 

EO-關鍵軟體是指包含一個或多個元件或與一個或多個元件具有直接軟體依賴關係、且具有下述任一屬性的軟體：

• 需要以提升的許可權或管理許可權執行；

• 對網路或計算資源具有直接或特權訪問許可權；

• 可控制對資料或運營技術的訪問；

• 所執行的某項功能對信任至關重要；或

• 使用特權訪問許可權在正常信任邊界之外執行。

 

該定義適用於為生產系統購買或部署各種形式的軟體（如單機軟體、特定裝置或硬體元件的整合軟體、基於雲的軟體等）用於運營目的。其他用例（例如軟體僅用於研究或測試，沒有部署在生產系統中）不在本定義範圍之內。（參見FAQ #10 和 FAQ #11.）

 

NIST建議，初始實施階段將重點放在本地部署的單機軟體上，這些軟體具有關鍵安全功能或在遭到破壞後會造成類似的重大潛在危害。後續階段可擴充套件到其他類別的軟體，例如：

· 控制資料訪問的軟體；

· 基於雲的軟體和混合軟體；

· 軟體開發工具，如程式碼庫系統、開發工具、測試軟體、整合軟體、打包軟體和部署軟體；

· 引導級韌體中的軟體元件；或

· 運營技術（OT）中的軟體元件。

下表初步列出了EO-關鍵軟體類別，用以說明如何按上文建議初步實施EO-關鍵軟體定義。如前所述，CISA將在稍後提供軟體類別的權威列表。

 

軟體類別	說明	產品型別	列入理由
身份、憑證和訪問管理（ICAM）	對組織使用者、系統和裝置進行集中識別、認證、訪問許可權管理或強制執行訪問決策的軟體	· 身份管理系統 · 身份提供者及聯合服務 · 證書頒發機構 · 訪問代理 · 特權訪問管理軟體 · 公鑰基礎設施	· 確保只有授權使用者、系統和裝置才能訪問敏感資訊和功能的基礎軟體
作業系統、虛擬機器管理程式、容器環境	建立或管理對硬體資源（裸機或虛擬化/容器化）的訪問和控制、併為軟體應用程式和/或互動使用者提供訪問控制、記憶體管理和執行時執行環境等公共服務的軟體	· 伺服器、桌上型電腦和移動裝置的作業系統 · 支援作業系統和類似環境虛擬化執行的虛擬機器管理程式和容器執行時系統	· 軟體具有高許可權，可直接訪問和控制底層硬體資源並提供最基本的關鍵信任和安全功能
Web瀏覽器	透過網路處理Web伺服器所提供內容的軟體，通常用作裝置和服務配置功能的使用者介面	· 單機和嵌入式瀏覽器	· 執行多重訪問管理功能 · 支援瀏覽器外掛和擴充套件，如用於儲存Web伺服器資源憑證的密碼管理器 · 為從遠端來源下載的程式碼提供執行環境 · 為儲存內容提供訪問管理，例如根據請求提供給Web伺服器的訪問令牌
端點安全	安裝在端點上的軟體，通常具有提升的許可權，以支援或促進端點的安全操作，或用以收集端點的詳細資訊	· 全磁碟加密 · 密碼管理器 · 查詢、刪除或隔離惡意軟體的軟體 · 報告端點安全狀態（漏洞和配置）的軟體 · 收集有關韌體、作業系統、應用程式、使用者和服務賬號以及執行時環境詳細狀態資訊的軟體	· 擁有對資料、安全資訊和服務的特權訪問許可權，以實現對使用者和系統資料的深度檢測 · 提供對信任至關重要的功能
網路控制	執行協議、演算法和功能以配置、控制、監視和保護網路資料傳輸的軟體	· 路由協議 · DNS解析器和伺服器 · 軟體定義的網路控制協議 · 虛擬專用網（VPN）軟體 · 主機配置協議	· 對關鍵網路控制功能具有特權訪問許可權 · 一般會被惡意軟體攻擊，以便進行更復雜的資料外洩攻擊
網路保護	防止惡意網路流量進入或離開網段或系統邊界的產品	· 防火牆、入侵檢測/防範系統 · 基於網路的策略實施點 · 應用防火牆和檢測系統	· 提供對信任至關重要的功能，通常具有提升的許可權
網路監控與配置	基於網路的監控和管理軟體，對各種系統具有更改狀態或安裝代理/獲取特權的能力	· 網路管理系統 · 網路配置管理工具 · 網路流量監控系統	· 能夠使用提升的許可權和/或遠端安裝的代理監控和/或配置企業IT系統
執行監控和分析	用以獲取遠端系統的執行狀態和安全資訊的軟體，以及用於處理、分析和響應這些資訊的軟體	· 安全資訊與事件管理（SIEM）系統	· 在遠端系統上廣泛部署的具有提升許可權的軟體代理 · 對事件檢測和響應以及安全事件取證根因分析至關重要的分析系統 · 惡意軟體常試圖關閉或規避此類軟體
遠端掃描	透過掃描網路中的公開服務確定網路端點狀態的軟體	· 漏洞檢測和管理軟體	· 通常對網路服務具有特權訪問許可權，並收集有關其他系統中所包含漏洞的敏感資訊
遠端訪問和配置管理	用於遠端系統管理和端點配置或遠端控制其他系統的軟體	· 策略管理 · 更新/補丁管理 · 應用程式配置管理系統 · 遠端訪問/共享軟體 · 資產發現和清點系統 · 移動裝置管理系統	· 使用重要的訪問許可權和提升許可權進行操作，可見性極低，端點使用者幾乎無法控制
備份/恢復及遠端儲存	用於建立副本和傳輸端點或其他網路裝置所儲存資料的軟體	· 備份服務系統 · 恢復管理器 · 網路連線儲存（NAS）和儲存區域網路（SAN）軟體	· 對使用者和系統資料具有特權訪問許可權 · 對網路事件（如勒索軟體）發生後的響應和恢復功能至關重要

常見問題

 

以下問題在與OMB和CISA討論後確定，作補充說明之用。

 

1. 下一階段何時開始？

CISA和OMB將會監控計劃的初期實施情況，決定何時加入其他軟體類別。

2. 定義中的“直接軟體依賴”是什麼意思？

對於特定元件或產品，“直接軟體依賴”指的是直接整合到該軟體例項中、且該軟體例項執行所必需的其他軟體元件（如庫、包、模組等）。這並不是對依賴關係的系統定義，也未涵蓋獨立產品的介面和服務。

3. 定義中的“對信任至關重要”是什麼意思？

“對信任至關重要”包括用於安全功能的軟體類別，如網路控制、端點安全和網路保護。

4. 軟體產品在雲中、本地或混合環境中部署有什麼不同嗎？

沒有。如果產品或服務提供的功能符合EO-關鍵定義，那麼無論其部署模式如何，產品或服務本身都視為EO-關鍵。

儘管如此，NIST建議，命令的初始實施階段應將重點放在本地部署的軟體上。許多本地產品依賴於雲元件和服務來執行EO-關鍵功能（例如基於雲的訪問控制）。在這種情況下，如果本地元件直接執行EO-關鍵功能，則為關鍵元件。建議在後續實施階段考慮雲元件和系統，留出時間與此類系統的其他聯邦要求（如FedRAMP）進行協調。

5. 開源軟體有可能是EO-關鍵軟體嗎？

有可能。如果開源軟體執行的功能屬於EO-關鍵功能，那麼該軟體就是EO-關鍵軟體。實際應用中，開源軟體常整合在其他產品中。這種情況下，產品開發人員將開源元件視為開發過程的一部分。有時候，開源軟體為獨立產品。這種情況下，行政命令的要求仍然適用。如果支援該產品的開源社群沒有或無法滿足第4（e）款中的某些要求，政府可能需要介入。

6. 政府開發軟體有可能是EO-關鍵軟體嗎？

有可能。聯邦政府透過內部和合同開發軟體，這些產品通常被稱為GOTS（政府現成）軟體。如果GOTS軟體執行的功能屬於EO-關鍵功能，那麼該軟體就是EO-關鍵軟體。雖然行政命令第4條未對商用和GOTS軟體進行區分，但GOTS軟體的開發和採購方式可能要求針對EO-關鍵軟體制定的標準、程式和標準在這方面有所區分。

7. 如果一個產品只包含部分EO-關鍵功能，產品怎麼定性？

產品若包含EO-關鍵定義中的功能，就屬於EO-關鍵產品。不過，某些EO-關鍵軟體產品可能包含特殊元件，這些元件不具有EO-關鍵屬性或不直接支援產品提供的EO-關鍵功能。開發人員證明其產品具有第4（e）款要求的安全措施時，可以明確說明產品的哪些元件為EO-關鍵元件，具有這類安全措施，而哪些元件不是。當然，這可能會導致各廠商對如何劃定證明範圍理解不一致，但只要廠商明確了哪些元件要進行證明、哪些不需要即可。

8. 軟體若作為另一產品的元件購買應如何處理？

產品若執行EO-關鍵定義中的功能，就屬於EO-關鍵產品。在證明實施了第4（e）款中規定的安全措施時，廠商可以具體說明其產品的哪些元件實施了這些措施。這其中可能包括由其他方開發的元件。例如，如果政府欲購買包含作業系統的產品，那麼該產品為EO-關鍵產品，需要證明實施了安全措施，但此等證明可僅限於作業系統。參見FAQ #7。

9. 該計劃如何與FedRAMP協調？

行政命令第3條涉及FedRAMP的現代化。建議的分階段方法從本地軟體開始，可能會包括一些依賴雲託管元件的本地軟體。CISA將與FedRAMP協調，確定行政命令在後續實施階段對基於雲的軟體的適用範圍。

10. 該定義排除了未在生產系統中部署用於運營目的的軟體。能進一步解釋一下嗎？

有幾種用例，共同點是擁有軟體，但部署方式決定了軟體即使被入侵也不足以構成重大的危害風險，例如，作為研究物件的軟體和為存檔目的收集的軟體。也就是說，政府可以購買EO-關鍵軟體用於這些非運營目的，這種情況下，即使廠商沒有實施或證明採用4（e）款中的安全措施也無妨。

11. 國家安全系統（NSS）中使用的軟體呢？是否包含在內？

行政命令第9條描述了行政命令要求對國家安全系統的適用性。

12. 嵌入式軟體或韌體有可能屬於EO-關鍵定義範圍嗎？

有可能。若嵌入式軟體或韌體執行EO-關鍵定義中的功能，就屬於EO-關鍵軟體或韌體。考慮到此類產品的複雜性，我們建議在初始實施階段排除此類軟體。

13. 各部門和機構難道不應該根據支援機構任務的軟體使用方法來判斷軟體是否屬於EO-關鍵定義範圍嗎？

不。對EO-關鍵的定義是基於軟體的功能，而不是其使用方式。這樣，軟體廠商無需瞭解具體的採購和部署方式便能確定其產品是否為EO-關鍵軟體，進而按照第4（e）款要求行事。這會避免市場產生誤解。否則，政府在採購時可能無貨可買或可選範圍很小，因為廠商沒法預知產品是否為EO-關鍵軟體。表中定義的EO-關鍵軟體型別適用於大多數情況。

14. 關鍵安全系統等高保證系統是EO-關鍵系統嗎？

關鍵安全系統等高保證系統包含很多型別，許多都有法規或行業安全要求。如果這些系統使用包含EO-關鍵功能的軟體，則該軟體是EO-關鍵軟體。關鍵安全與高保證軟體和系統會有額外的安全要求。例如，如果高保證系統包含作業系統，而因為作業系統屬於EO-關鍵軟體，則該系統除了要滿足關鍵安全或其他系統要求外，還必須滿足EO-關鍵要求。

15. 如果我使用的軟體產品未包含在EO-關鍵清單中，但對我來說是關鍵的，我可以要求廠商提供證明嗎？

可以，各部門和機構可在採購中加入第4（e）款中定義的EO-關鍵安全措施。