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