介紹
本節解釋了系統驅動風險分析的核心概念、這些技術可以增加哪些價值以及它們在哪些方面不太有用。
本介紹的目的并不是為您提供實現此類技術的藍圖。但是，一旦您了解了這些基礎知識，您應該能夠使用系統驅動的標準或框架（因為它們基于類似的風險視角），并了解它們與組件驅動的風險管理技術有何不同。
如果您還沒有這樣做，請在閱讀本節之前先閱讀介紹組件和系統驅動的風險評估的部分。
系統驅動的風險分析有什么用處？
系統驅動的風險分析最適合識別因系統組件之間的交互而出現的風險。這些風險可以在沒有任何單個組件損壞或受到損害的情況下發生，因此它們可以識別組件驅動方法無法識別的風險。
在小型、簡單的系統中，無需任何特別正式的方法就可以識別這些交互風險。然而，對于更大、更復雜的系統來說，這是不可行的，而這正是系統驅動方法增加真正價值的地方。系統驅動的方法最適合在某些新場景中使用，特別是在項目或交付框架的設計和概念開發階段，以及您可能需要識別系統組件之間的交互所出現的風險的情況。
這種技術的最終產品是您正在分析的系統的一組安全要求。系統驅動的風險管理技術應該使您能夠將這些要求追溯到您試圖避免的特定結果，這有助于您確定潛在安全改進的優先順序。
什么是系統？
就本指南而言，“系統”一詞是指旨在實現特定功能的事物。這一功能可以通過技術來實現，但同樣，“系統”可以是一群人、一座建筑物或自然發生的天氣模式。因此，談論“系統”而不提及其功能或目的是沒有意義的。使用這個定義，在分析系統時，由您（和您的利益相關者）在分析之前定義您正在查看的系統的功能。
例如，您可以在組織的網站上執行風險評估。您的站點所在的服務器將是該系統的重要組成部分，但它并不能代表整個系統。允許您的組織托管網站的系統將包括一系列其他內容，包括（但不限于）：
你的互聯網連接
維護網站的人
作為網站一部分保存客戶記錄的數據庫
管理網站管理方式的組織政策
在此示例中，您感興趣的系統不僅僅是網站；還包括網站。該系統允許您的客戶和合作伙伴通過互聯網了解您的組織。定義系統功能是系統驅動風險分析的核心部分。
定義“功能”
如果您正在談論系統，那么首先必須說明您要分析的功能。否則，您可能最終只分析單個系統組件（例如上例中的網站服務器）而忽略其余部分。系統功能的示例可能是：
讓客戶能夠使用互聯網購買您的產品
使人們能夠在一小時內從倫敦到達伯明翰
使組織的員工能夠協作制作和共享文檔
系統驅動的風險管理方法的定義特征之一是，它們需要在開發的早期階段明確說明系統的功能。此階段的一個常見錯誤是將系統的功能與系統有助于解決的問題的陳述相混淆。
例如，您可能會說銷售網站的功能是“提高組織的銷售數字”。嚴格來說，網站的功能應該是“讓客戶能夠在網上識別并購買你的產品，并讓你的物流部門能夠及時發貨”。該功能將有助于解決“提高銷量”的問題，但并不能徹底解決該問題，其他解決方案也會對解決該問題產生影響。
良好的功能陳述必須是可實現的，并且必須能夠驗證您是否已經實現了它。正確執行此功能聲明是進行系統驅動風險分析的重要組成部分。
定義系統的“損失”
在系統和組件驅動技術的介紹中，我們了解了系統不應實現（或有助于實現）的高級目的如何被稱為損失。為了執行系統驅動的風險分析，您需要枚舉您不希望在系統運行中發生的高級結果。在這種情況下，我們只關心損失的實際結果。
在這里，我們談論的是組織非常關心的高層損失。如果您識別出少量非常重大的損失，而不是大量相對較小的損失，那么這種方法最有效。
損失的例子包括：
受傷或死亡
針對您的組織的大規模欺詐
觸犯法律
關鍵的組織流程被破壞
任何系統驅動的風險分析的一個重要部分是清楚、準確地定義您在操作或設計的系統背景下擔心哪些損失。重要的是，我們不是在討論實現損失的方式，而是在討論結果本身。此階段的結果應該是您確定與您的系統相關的損失列表。
將這些原則付諸實踐
在網絡安全中，系統驅動的風險分析技術遠沒有組件驅動的技術那么成熟。因此，形式化技術較少，而且它們之間的差異較大。本指南介紹了NCSC認為這些技術的共同特征，并解釋了它們可以增加哪些價值。
任何系統驅動的風險分析技術都應該從功能的闡明以及您希望避免的損失開始。您通常期望看到一個迭代過程，通過將功能語句分解為子系統（每個子系統都有自己的功能）并演示這些子系統如何相互控制和通信，從而增加該功能語句的復雜性。在每個迭代階段，您將探索任何可能的損失風險，在此過程中，您將制定安全要求以避免這些風險。
談論技術系統的網絡安全風險的一個重大障礙是組織和分析師在正確分析系統級別之前快速轉向組件級別思考的誘惑。這就是為什么我們建議組織通過在系統和組件級別上了解網絡安全風險來獲得對其所面臨的網絡安全風險的最佳視角。
常用的系統驅動的網絡風險管理方法和框架
本節簡要描述一些系統驅動的網絡風險管理方法和框架。
我們提供了每種技術的具體指南的鏈接。這些提供了有關每種技術如何工作以及它們如何增加價值的更多詳細信息。
還有更多應用這些原則的技術（此處未列出）。下面包含的三個（我們認為）最好地說明了這些類型的技術之間的差異。
STPA
STPA（系統理論過程分析）是STAMP框架的一部分，它是對事故原因進行建模的技術集合。它是由麻省理工學院的NancyLeveson教授和她的同事開發的。雖然STPA最初專注于安全，但后來它已適應許多其他環境，其中一些適應網絡安全要求。
托加夫
TOGAF（TheOpenGroupArchitecturalFramework）是TheOpenGroup開發的商用架構框架。雖然它本身不是一種風險管理技術，但它借鑒了許多與系統驅動的風險分析框架（例如STPA）相同的想法。它是一種企業架構標準，旨在提高業務效率和管理風險，例如尋求提供更好的投資回報、減少管理費用和改進采購流程。該框架基于迭代過程模型，可以單獨或與其他框架集成在整個組織的不同級別實施。TOGAF支持我們的指南中描述的自上而下（系統驅動）和自下而上（組件）的風險管理方法。
南非標準協會
南非標準協會是一個業務驅動的安全架構框架，高度關注組織如何為利益相關者創造價值。正如TOGAF所指出的，雖然SABSA主要不是一種風險分析技術，但它借鑒了許多相同的系統概念。從組織價值鏈的獨特配置開始，SABSA框架幫助分析師將流程分解為多個業務架構層。這些層依次向下發展為業務能力、業務流程、業務服務，并從那里向下進入技術服務。SABSA要求分析師解決每一層的風險，以便在“堆棧”頂部定義的需求能夠向下繼承并在每一層得到解決。
