摘要

網絡物理系統是控制機械部件的計算機化系統。這些系統必須既功能安全又網絡安全。因此，已建立的功能安全與網絡安全標準需求創建網絡安全檔案（ACs），以論證系統是功能安全與網絡安全的，即所有功能安全與網絡安全目標都已實現。然而，在實踐中，功能安全與網絡安全團隊往往分開工作，網絡安全檔案通常在開發后期以手動方式創建。除了重建已采取的設計決策需要付出巨大努力外，這種方法還會導致在更改幾乎不可能的后期才發現沖突。由于工程師經常利用緩解策略和對策模式來實現既定的功能安全與網絡安全目標，因此我提出了一種方法，通過增加這些模式的額外設計原理和網絡安全檔案片段，以半自動方式支持完整網絡安全檔案的創建。通過這種方法，我希望通過在開發的早期階段將功能安全與網絡安全專家聚集在一起，為集成的“設計即功能安全與網絡安全”流程鋪平道路。這一目標將通過允許他們基于共同的設計原理開展工作來實現，而這些設計原理還將被用于自動推導網絡安全檔案。從而，減少了創建網絡安全檔案的手動工作量，并降低了出錯的可能性。

1、引言

網絡物理系統（CPSs）是計算機控制的機械系統（例如，現代汽車或工業控制系統）。這些系統通常由大量相互連接的子系統和組件組成。由于由此產生的高度復雜性，網絡物理系統通常采用基于模型的技術進行設計。此外，網絡物理系統通常是安全關鍵的，因為它們通常由人類操作，或者以某種方式與人類或環境交互。為了能夠遠程訪問網絡物理系統，它們越來越多地連接到互聯網。結果，這種連接性也使它們成為攻擊者的誘人目標。因此，網絡物理系統也變得越來越網絡安全關鍵。

為了使這些系統安全，必須識別和緩解對人類健康和生命或環境的潛在危害。例如，在汽車領域，ISO 26262 標準要求工程師在危害分析和風險評估（HARA）階段執行安全活動。在HARA 階段，識別潛在危害并定義系統必須實現的安全目標。在部署系統之前，工程師必須通過論證這些安全目標已實現且所有相關危害已被預防，來證明系統是安全的。這種論證在安全檔案中進行。安全檔案通過論證所應用的緩解策略和對策的有效性，展示安全目標是如何得到滿足的。

類似地，為了使網絡物理系統網絡安全，必須識別對系統的潛在威脅。網絡安全的重要性日益增加，這也反映在工業領域（參見 IEC 62443）和汽車領域（參見 ISO 21434）采用新的網絡安全標準上。例如，在汽車領域，ISO 21434 標準要求工程師在威脅分析和風險評估（TARA）階段執行網絡安全活動。在 TARA 階段，識別系統面臨的威脅以及系統必須實現的網絡安全目標。同樣，為了論證系統是網絡安全的（即所有網絡安全目標都已實現），需要構建一個網絡安全檔案。

仔細觀察這兩個過程會發現，在功能安全與網絡安全這兩個領域，都進行了早期分析（分別是 HARA 和 TARA）。此外，所有相關的功能安全與網絡安全標準都要求構建功能安全與網絡安全檔案（或更一般的網絡安全檔案）。此外，這兩個領域之間存在相關性。出于安全原因做出的決策（例如，要求信息公開可用）可能與網絡安全決策（例如，要求信息隱藏）相沖突。因此，安全檔案需要參考網絡安全檔案中論證的決策，反之亦然。為了處理相互沖突的功能安全與網絡安全目標，功能安全與網絡安全團隊在開發過程中協同工作（設計即功能安全與網絡安全）是有利的。

然而，在實踐中，功能安全與網絡安全團隊往往各自為政。但至少在創建網絡安全檔案方面，兩個領域的團隊應該相互溝通，以協調功能安全與網絡安全決策，因為功能安全與網絡安全檔案之間存在依賴關系。然而，網絡安全檔案通常在開發結束時以基于文本的方式手動創建。這是有問題的，因為潛在的沖突可能在開發后期才被發現。此外，由于網絡安全檔案的目的是傳達和解釋所選對策與已定義的安全或網絡安全目標之間的關系，因此其構建需要早期開發階段（例如，系統設計階段）的決策。這些決策，即設計原理，包括設計決策背后的原因、其合理性、考慮的替代方案和權衡，以及導致該決策的論證。然而，設計原理通常沒有記錄，僅作為隱性知識存在于相關工程師的腦海中。如果在開發后期創建網絡安全檔案，工程師就必須手動重建隱性的設計原理，這會導致大量的工作量和較高的出錯可能性。

為了簡化網絡安全檔案的創建并提高其構建效率，我提出了一種方法，通過形式化這些措施和相應策略背后的意圖和原理，積極支持從更高層次的目標（無論是安全還是網絡安全）到實際更具體的對策的決策制定和細化過程。然后，這種形式化的設計原理將用于自動推導網絡安全檔案。

本文的其余部分結構如下：在第2節中，我將詳細描述問題，并提出我希望通過工作解決的研究問題。第3節介紹相關工作，并說明當前最先進的研究為何不足以解決所述的研究問題。第 4 節通過解決每個所述的研究問題來呈現我的解決方案。在第 5 節中，我將介紹評估我的研究結果的評估方法。最后，第 6 節總結本文，并展示研究的當前狀態。

2、問題描述

為了進一步說明研究挑戰，圖 1 展示了一個基于 ISO 21434 汽車網絡安全標準附錄 G 中的示例的汽車領域簡化示例。該圖顯示了一個 UML 組件圖，包含汽車前照燈系統的五個組件：HeadlampSwitch（前照燈開關）、BodyControlECU（車身控制電子控制單元）、PowerSwitchActuator（電源開關執行器）、GatewayECU（網關電子控制單元）和 NavigationECU（導航電子控制單元）。這些組件代表汽車電子控制單元（ECUs），其功能是打開和關閉汽車的前照燈。在汽車系統中，電子控制單元通常通過總線系統（例如，CAN 總線）相互通信，每個電子控制單元都被允許在總線上寫入和讀取數據。為了按功能分隔電子控制單元，現代汽車有多個用于不同任務的 CAN 總線。為了使電子控制單元能夠在不同的總線網絡之間通信，使用了網關（參見 GatewayECU）。

在我們的示例中，NavigationECU 通過藍牙和蜂窩網絡提供與外部世界的連接。由于與互聯網的連接，在 TARA 階段識別出的一個潛在威脅是攻擊者向 CAN 總線網絡注入惡意消息（參見 TamperingThreat）。如果攻擊者設法將被操縱的 CAN 消息傳播到前照燈系統，攻擊者可能能夠在夜間關閉前照燈。這導致了 CrashHazard（碰撞危害），即前照燈意外關閉可能導致碰撞。為了應對潛在的威脅和危害，為系統定義了功能安全與網絡安全目標。例如，為了防止意外關閉車燈，相應的消息請求應受到保護（參見網絡安全目標 LampSwitchIntegrity）。此外，為了防止碰撞，應防止前照燈意外關閉（參見安全目標 HeadlampFunctionality）。

圖1：根據ISO 21434的HARA/TARA階段結果（附錄G示例）

設計原理僅隱含存在。為了消除某些威脅和危害，工程師對系統做出假設。例如，前照燈系統可以使用防篡改外殼進行物理保護，以防止未經授權的修改。對于所有剩余的危害和威脅，必須在系統中實施適當的對策。找到合適的對策并非易事，需要一種結構化的方法來評估潛在的緩解方法和策略。本質上，找到對策是功能安全與網絡安全需求提取過程的一部分，在該過程中，功能安全與網絡安全目標得到細化。這種緩解策略的一個例子可以是 “縱深防御” 方法，該方法涉及多個網絡安全層以防止攻擊的蔓延。

功能安全與網絡安全需求通常由不同學科的獨立團隊提取，盡管存在需要考慮的依賴關系和權衡。這是一個問題，因為可能在開發生命周期的后期才發現相互沖突的目標和策略。此外，工程師的許多隱性知識參與到需求提取過程中，而這些知識往往沒有被記錄。然而，所選緩解策略背后的這種設計原理是后續網絡安全檔案所需要的，因此如果沒有被記錄，就需要進行重建。但是，即使過程中做出的戰略決策被記錄下來，它們的可重用性也往往有限，因為這取決于決策的存儲形式（例如，如果記錄為非結構化文本）。這導致在重建和重用確保系統功能安全與網絡安全所需的設計決策方面需要付出大量努力。

為了有效地支持兩個領域的工程師進行目標細化過程，我提出了第一個研究問題（RQ1）：如何存儲目標細化過程中更高層次緩解策略背后的隱性設計原理，以便日后重用并將其用于創建網絡安全檔案？

高效找到合適的對策。為了實施預期的策略，需要找到具體的對策。對于某些類型的危害和威脅，可以考慮已建立的對策模式目錄（參見 Mitre ATT&CK 網絡安全模式目錄）。如果我們考慮我們的運行示例，防止向 CAN 網絡注入惡意消息的一個潛在對策是在 GatewayECU 上實施白名單，只允許可信消息在網絡之間傳輸。選擇這些對策時會考慮某些因素，例如在當前系統環境中的適用性以及對該措施的安全或網絡安全影響的假設。還必須考慮功能安全與網絡安全方面之間的潛在沖突。例如，所采用的白名單不得阻止任何與安全相關的數據。因此，真正的挑戰實際上不是找到任何對策，而是找到滿足某些要求的合適對策。提取合適對策過程中做出的設計決策是每個應用對策背后的設計原理的一部分。與所選緩解策略背后的設計原理類似，每個實際對策背后的原理也是創建網絡安全檔案所需要的。在網絡安全檔案中，需要有關所應用對策有效性的證據，以論證已實現所述目標。對于這種論證，每個措施背后的原理至關重要。然而，與更高層次的緩解策略一樣，對策背后的設計原理通常也僅表現為隱性知識。

因此，為了有效地支持工程師選擇對策，我提出了以下研究問題（RQ2）：如何存儲具體對策背后的設計原理，并將其用于對策的高效選擇以及網絡安全檔案的創建？

減少創建網絡安全檔案的工作量。在最終部署網絡物理系統之前，工程師必須確保系統可以功能安全與網絡安全地運行。這必須記錄在網絡安全檔案中，該案例論證所選對策實現所述目標的有效性。如前所述，創建網絡安全檔案需要所應用的緩解策略和實際對策背后的設計原理。然而，設計原理和網絡安全檔案是不同的，盡管兩者都旨在論證為什么所述的功能安全與網絡安全目標已經得到滿足。但它們從兩個相反的角度處理這個方面：設計原理是在需求分析期間創建的，表達例如所選對策的意圖，而網絡安全檔案側重于論證和合規性評估，即它們基于已做出的決策。

如果在開發過程的后期創建網絡安全檔案，大多數決策已經確定，如果可以找到更好的解決方案，系統設計的更改也幾乎不可能。另一方面，在開發的早期階段做出的設計決策非常不穩定，容易發生變化（例如，由于變更請求）。因此，簡單地在增量系統設計過程的同時開始創建網絡安全檔案會導致工作量增加和頻繁的變更。如果手動創建網絡安全檔案，情況會更糟，因為必須不斷調整它們。為了利用早期創建的網絡安全檔案，需要從系統設計時存在的設計原理中推導它們。

因此，我提出了第三個研究問題（RQ3）：如何（半）自動地從緩解策略和所應用對策背后的設計原理中推導網絡安全檔案？

3、背景和相關工作

在本節中，我將介紹解決第 2 節中提出的研究問題的現有工作。這項工作涉及設計原理捕獲、對策模式和網絡安全檔案領域。我還將概述我希望在我的方法中解決的現有方法的缺點。

在系統設計階段進行目標細化建模和捕獲設計原理的研究有著悠久的傳統。該領域一種流行的方法是面向目標的需求工程（GORE），其起源于 20 世紀 90 年代初。GORE 的一個著名建模方法是 van Lamsweerde 等人提出的 Keep All Objectives Satisfied（KAOS）方法。Darimont 和 van Lamsweerde 還基于 KAOS 定義了一個正式框架，以允許定義通用目標細化模式。雖然 GORE 和 KAOS 通常應用于需求提取領域，但它們最近通過應用于網絡物理系統的功能安全與網絡安全工程而受到關注。

結合設計原理捕獲和網絡安全檔案（RQ1）。盡管最近對前置保障活動的研究感興趣，但是關于將更高層次設計策略的顯式建模設計原理與網絡安全檔案相結合的工作卻很少。Ito 等人在他們的工作中提出了一種方法，將汽車 ISO 26262 安全標準定義的概念階段創建的 KAOS 模型與目標結構表示法（GSN）中定義的網絡安全檔案模型相鏈接。GSN 是一種廣泛使用的論證表示法，以基于模型的方式圖形化地表示此類網絡安全檔案。它通常用于定義安全論證，但作為一種通用的論證表示法，它不僅限于安全方面，也可用于網絡安全論證。此外，Ito 等人的方法僅限于安全領域，目標模型和安全檔案仍然必須并行創建，因為該方法側重于使用鏈接矩陣保持它們彼此同步。

Habli 等人從不同的角度解決研究挑戰。他們提出了一種通過在需求工程階段早期以 GSN 創建網絡安全檔案來擴展 GORE 與論證的方法。然而，在這種方法中，GSN 用于一般性地論證目標和需求的實現，而沒有特別關注安全或網絡安全。此外，GSN 默認缺乏顯式建模目標之間沖突的可能性。這是因為 GSN 作為一種論證表示法，主要用于事后建模論證。正如作者所建議的，通過簡單地限制節點的描述來在 GSN 模型中建模反目標，會使沖突更難識別。

結合對策模式和網絡安全檔案（RQ2）。Martin 等人在他們的工作中（擴展了 Preschern 等人的工作）提出了一種結合功能安全與網絡安全模式工程的工作流。在這個工作流中，功能安全與網絡安全模式以及它們的原理、潛在沖突和相應的 GSN 網絡安全檔案片段被一起使用和存儲。該方法通過工具支持實現，該工具支持提供網絡安全檔案片段的自動組合和實例化。盡管這種方法匹配設計模式和相應的網絡安全檔案片段，但選擇模式的過程仍然主要是手動的。因此，除了僅根據模式描述手動選擇模式之外，工程師在選擇合適對策的決策過程中沒有得到指導。此外，將網絡安全檔案片段與單個模式匹配導致論證在很大程度上局限于所選的相應模式。

?ljivo 等人提出了一種基于契約的模式實例化框架，其中架構設計模式（例如，防火墻）與靜態網絡安全檔案論證模式相結合。通過基于所選設計模式實例化此論證模式，所提供的工具支持能夠生成 GSN 中的網絡安全檔案。然而，由于設計模式應用于系統模型中的特定組件，他們的方法僅限于具體的對策模式。因此，它缺乏對不能應用于單個組件的更高層次設計策略的支持。

Meng 等人提出了一種相關方法，他們提出了一種基于公開可用的攻擊模式自動生成網絡安全檔案片段的工具支持方法。然而，盡管論證再次局限于單個對策，但他們的方法也僅關注一組預定義的網絡安全模式。

Dantas 等人提出了一種自動檢查安全或網絡安全模式在架構系統模型中適用性的方法。該方法基于線性時序邏輯，根據所應用的模式提供自動化的功能安全與網絡安全推理。雖然這允許在架構模型中自動化應用具體的功能安全與網絡安全模式，但它缺乏關于這些模式如何以及為何滿足給定的功能安全與網絡安全目標的詳細原理。與 Martin 等人的方法一樣，他們的方法更多地關注具體模式及其設計原理，而較少關注更廣泛的緩解策略。

自動推導網絡安全檔案（RQ3）。有幾種方法可以從系統模型中找到的對策中推導出基于模型的網絡安全檔案。然而，這些方法側重于基于實際應用的措施，即局部受限的系統信息，在 GSN 中推導網絡安全檔案。因此，它們沒有考慮更高層次的緩解策略。

總之，有一些方法涉及設計原理、對策和網絡安全檔案之間的關系，但它們只關注個別方面。然而，據我所知，沒有一種方法像我打算在我的工作中做的那樣，綜合考慮所有子方面。

4、解決方案思路

為了解決第 2 節中提出的研究問題，我提出了一種從開發早期階段做出的設計決策中自動推導基于模型的網絡安全檔案的方法。為此，我的方法旨在支持系統設計階段從更高層次的功能安全與網絡安全目標到具體對策的目標細化過程。特別是，目標是使找到適當對策的過程更高效，并跟蹤和重用在選擇這些對策時做出的決策以推導網絡安全檔案。為了實現這一點，我希望利用模式來存儲重復出現的對策，因為關于對策背后設計原理的重要信息，例如它們的適用性、合理性或與其他措施可能存在的沖突等，都可以嵌入到模式描述中。

圖 2 展示了所提出的解決方案如何整合到更廣泛的系統設計流程中。現有的流程步驟用灰色標注，而新提出的流程步驟用藍色標注。流程步驟左側的齒輪圖標表示該步驟可通過自動化方式提供支持。圖右側顯示了我的工作的擬議貢獻（C1 至 C3），橙色星形圖標指示了它們對流程的影響。第一步（步驟 1）是定義系統模型，即項目定義，在此基礎上確定危害、威脅以及功能安全與網絡安全目標（參見 ISO 21434）。這些目標在系統的概念階段進行細化，在此階段找到適當的功能安全與網絡安全要求（即對策）。在目標細化過程中，制定緩解策略（步驟 2）。

圖 2：擬議解決方案的流程整合

為了允許日后重用緩解和目標細化策略并簡化網絡安全檔案的創建（參見 RQ1），我提出了第一個貢獻（C1）：定義一個復雜的對策模式目錄。在這個模式目錄中，反復出現的功能安全與網絡安全對策應作為對策模式存儲。利用這個目錄，工程師應能在多個層級上對所含模式進行分層結構化。每個層級對應不同粒度的不同緩解策略和目標細化技術。這使得不同的模式能夠通過更廣泛的緩解策略相互關聯，具體取決于該對策模式所服務的安全或網絡安全目標。為了在模式目錄中捕捉這些緩解策略背后的設計原理，每個存儲的策略還應關聯一個相應的論證片段。這些論證片段組合起來，就形成了一個能反映為實現所述功能安全與網絡安全目標而采取的選定緩解方法的網絡安全檔案。

在制定緩解策略后，需要找到能實施這些策略的合適對策（圖 2 中的步驟 3）。為了有效地支持工程師選擇此類對策（參見 RQ2），對策模式目錄（參見貢獻 C1）中的模式需要提供關于其預期用途和適用性的額外元信息。因此，作為我的第二個貢獻（C2），我提議將模式的明確建模設計原理與模式本身一同存儲。設計原理通過提供關于模式的環境假設、合理性、在系統模型中的適用性以及與其他模式的潛在沖突等有用信息，對模式描述進行補充。通過明確建模模式的設計原理，我的目標是捕捉那些通常僅以隱性形式存在的知識。由于這些信息也是創建網絡安全檔案所必需的，因此與緩解策略相關聯的片段（參見貢獻 C1）類似，論證片段也應與模式的設計原理一同存儲。

圖 3 通過示例展示了第 2 節中提到的白名單對策如何補充了額外的設計原理和保障信息。白名單對策在 GatewayECU 內部實施。為了重用該對策，可以將其定義為一個模式并存儲在擬議的模式目錄中，以備日后參考。在定義該模式時，其設計原理和目標結構表示法（GSN）中的網絡安全檔案片段（綠色）會附加到具體的對策實現中。然后，該模式可以存儲在模式目錄中，該目錄還包含用于更高層級緩解策略的 GSN 網絡安全檔案片段（紫色）。采用基于模型的方法來表示和推導網絡安全檔案，有助于工程師重用和鏈接現有的模型和設計原理工件（例如，來自模式目錄和模式描述）。系統模型工件與網絡安全檔案元素之間的鏈接（例如，通過跟蹤鏈接）更是有利的，因為這樣可以使關系更加清晰，并且更容易追蹤。

圖 3：為白名單對策模式補充額外的設計原理和保障信息

最后，來自模式目錄的模式元信息以及所應用的模式本身都可以作為推導網絡安全檔案的基礎。因此，作為我的第三個貢獻（C3），我提出一種（半）自動推導網絡安全檔案的方法，以減少其創建工作量（參見 RQ3）。為了創建系統的完整網絡安全檔案，可以重用預定義的網絡安全檔案片段（圖 2 中的步驟 4）。這些片段對應于更高層級緩解策略（參見貢獻 C1）和具體模式（參見貢獻 C2）背后的設計原理。因此，重建先前設計決策的繁瑣手動工作得以減少。通過組合這些片段（圖 2 中的步驟 5），可以在系統設計期間（此時關于對策的決策至關重要）部分自動推導網絡安全檔案。

除了對所提出方法進行正式描述外，我還期望開發上述方法的原型概念驗證軟件實現。該原型預計將提出的現有功能安全與網絡安全分析工具方法構建。因此，它是在 Eclipse 平臺上運行的工具原型的擴展。通過補充現有的分析流程，我還能夠在推導的網絡安全檔案中鏈接所選對策的效果（例如，分析結果）。

5、評估

為了評估我的方法，我計劃根據 Kitchenham 等人的指導方針進行案例研究。該案例研究將與汽車和 / 或工業領域的行業合作伙伴一起進行。我在德國弗勞恩霍夫研究機構的工作使我能夠在研究和行業項目中直接與行業合作伙伴驗證所述的研究挑戰。對于該案例研究，將與合作伙伴合作開發一個真實世界的運行示例，作為討論的共同基礎。基于此示例，識別危害、威脅以及功能安全與網絡安全目標。之后，為了證明我的方法確實解決了所述問題，我將評估使用我的方法在目標細化和對策選擇過程中對工程師的支持程度。在此過程中，我特別關注功能安全與網絡安全對策設計原理的表示、找到對策的效率以及在此過程中推導的最終網絡安全檔案的質量。

為了更好地評估所提出的方法，我計劃將其實現為概念驗證。實現過程將通過原型設計來驅動，以確保并與合作伙伴持續評估已識別的挑戰是否得到解決。

6、結論

總之，為了使網絡物理系統安全且網絡安全，功能安全與網絡安全團隊需要協同工作，在尊重兩個領域之間相互依賴關系的同時細化共同目標。著名的解決方案，即緩解策略和對策模式，可用于實現所述的功能安全與網絡安全目標。為了論證所有目標確實都已實現，我提出一種方法，通過補充這些模式的額外設計原理和網絡安全檔案片段，來支持規定網絡安全檔案的創建。