# ISSAP Domain 2
* Author: 陳詰昌 Jeff C. Chen
* Email: [e-mail]

---
# 2025 Exam Outline (2025.8.1生效)
* 課程大綱 [Exam Outline](https://www.isc2.org/certifications/issap/issap-certification-exam-outline#Domain%201:%20Governance,%20Risk,%20and%20Compliance%20(GRC))

## Domain 2: 安全架構建模 – 佔比 22%
### 2.1 識別安全架構方法
* 2.1.1 範圍（例如，企業、雲端）和類型（例如，網路、服務導向架構 (SOA)）
* <font color="yellow">2.1.2 框架（例如，開放群組架構框架 (TOGAF)、謝伍德應用業務安全架構 (SABSA)、服務導向建模框架）</font>
* 2.1.3 參考架構和藍圖
* 2.1.4 威脅建模框架（例如，STRIDE 詐騙、竄改、否認、資訊洩露、服務阻斷和權限提升、通用漏洞評分系統 (CVSS)、威脅情報）

### 2.2 驗證設計（例如，功能驗收測試、回歸測試）
* 2.2.1 威脅建模結果（例如，威脅向量、影響、機率）
* 2.2.2 差距
* 2.2.3 替代解決方案/緩解措施/補償控制
* 2.2.4 內部或外部第三方（例如，桌面演練、建模與模擬、功能手動審查、同儕審查）
* 2.2.5 程式碼審查方法（例如，動態、手動、靜態、源碼組成分析）

# Domain 2: 安全架構建模
* 比較不同的架構方法，考慮其安全隱患，並評估隨著網路技術發展而不斷演變的安全挑戰。
* 分析各種架構模型的安全需求，包括服務導向架構和物聯網等新興範式，同時回顧安全模型和企業配置的基礎知識。
* 總結測試和驗證專案交付成果的流程，包括回歸測試、避免單點故障的策略以及基礎設施和控制設計的獨立驗證和確認。
## 2.1 識別安全架構方法
* 安全架構的範圍、類型、框架、參考架構、藍圖以及威脅建模框架，旨在幫助安全架構師設計滿足企業需求的彈性解決方案
### 分散式計算

### 2.1.1 範圍與類型
#### 1. 企業架構 (Enterprise Architecture)
* 企業架構指組織在從系統設計思維轉為企業架構思維上的轉變，而產生安全挑戰需要適當保護。
* 傳統的系統設計： 傳統的系統通常被設計為單一實體，僅支援單一業務功能，且其組件往往是緊密耦合（tightly coupled），亦即他們不僅連結且相互依賴。
* 轉而向企業架構：透過應用統一的標準、策略和控制措施來確保一致性，從而更輕鬆地滿足跨部門的合規性、更好的互通性（interoperability）和簡化培訓及使用。
* 安全可重複性： 企業架構的一個巨大優勢是能夠避免為每個單獨的系統重新設計安全解決方案。一旦安全模型建立，它就可以在企業內的每個系統上重複部署，從而實現一致性。
* 設計重點：系統開發模式轉向以資訊為中心（information-centric），使得底層硬體變得無關緊要，尤其在雲端，而這些原本獨立系統變成相互整合後，應有效管理系統安全。
* 挑戰
* 安全性必須提早納入：如果安全性沒有在專案生命週期的早期階段就納入考量，那麼要整合出一個有效且高效的安全解決方案通常會很困難且昂貴。
* 文檔的重要性：一個完整的架構文檔應該說明應用程序和安全設計的樣貌，並顯示其與需求文件和系統安全計畫（System Security Plan, SSP）之間的關聯。
* 平衡性挑戰：由於 EA 旨在創建一個統一的模型，它可能導致利害關係人（stakeholders）不滿，因為「一體適用（one size fits all）」的解決方案，對於每個單獨的用戶來說可能「誰都不適用（fits no one）」。
* 管理層支持至關重要：企業架構的採用需要高階管理層的支持，以確保所有員工和利害關係人被迫遵循架構的標準。管理層的支持對於在所有 IT 系統和業務流程中推行架構框架至關重要，以確保架構的一致性和有效性。


----
#### 2. 計算架構模型 (Computing Architecture Models)
1. 集中式計算系統 (Centralized Computing System)
* 定義： 一種所有處理皆在單一中心位置進行的模型，這是 1980 年代早期大型主機（Mainframes）時代的主要模型。
* 安全特點： 由於硬體集中在一個鎖定且安全的機房內，因此實體安全相對容易。
* 安全重點： 必須保護共享資源（伺服器）、網絡，以及人員和系統的身份驗證與授權。
* 風險管理： 中央系統可能成為單點故障（Single Point of Failure），因此需要數據備份、伺服器或支援基礎設施（例如電力和空調系統）的備援設計。
* 

2. 去中心化計算系統 (Decentralized Computing System)
* 定義： 處理可以在許多不同的連接位置完成的模型，這些位置可以在單一地理位置，也可以分散於多個地理位置。
* 安全挑戰：
* 安全管理不一致性：由於資源分散，這類系統容易在安全控制的管理上出現不一致性，例如存取控制、備份、實體安全和備用電源的管理。
* 本地責任增加： 在某些情況下，本地管理層對於營運和安全的管理擁有更多的實務責任。
* 單點洩露風險： 在多個分散位置使用單一密碼可能導致所有位置同時被洩露或破壞。
* 網路故障風險： 網路是分散式系統的關鍵，網路故障可能導致系統之間缺乏同步性。
* 資料擁有權複雜性： 安全架構師必須確定資料的擁有權，以確保即使資料位於或被第三方控制的系統使用，也能得到適當的保護。
* 保護措施：
* 強制執行基準配置： 必須強制實施基準配置（baseline configurations），並定期審查日誌和存取控制權限
* 確保系統獨立性： 安全架構應確保單一組件的故障不會影響其他系統或運作。
* 網路通訊安全： 網路通訊應透過加密來確保安全。
* 組件間身份驗證： 分散式系統的許多組件（如伺服器、端點和筆記型電腦）之間都需要進行身份驗證。
* 鼓勵使用標準協議： 應鼓勵使用通用且標準的協議。網絡通訊對於去中心化系統至關重要，因此應透過加密來保護。
3. 分散式Web系統（Distributed Web-based System）
* 定義：網際網路是分散式運算的一個例子，使用者可以使用幾乎任何裝置進行連接，而沒有中央控制與管理。
* 運作基礎：系統運作高度依賴於應用程式介面（APIs）提供互通性與易用性。
* 安全挑戰
* 終端裝置風險（Endpoint Risk）： 終端裝置（如使用者的電腦或行動裝置）可能已被入侵（compromised）。
* 網路風險： 網路可能不可靠，並且容易受到監控。
* 應用程式介面（API）不安全： 選擇使用的 API 可能不安全。
* 不安全的部署： 許多使網路系統得以運作的關鍵功能，可能被部署得不夠安全。例如：電子郵件（Email）可能沒有使用 DMARC（Domain-Based Message Authentication, Reporting and Conformance）。
* 網域名稱系統（DNS）可能沒有使用 DNSSec（DNS security）。
* 某些通訊可能仍在使用過時的技術，例如 SSL（Secure Sockets Layer）或較早版本的 TLS（Transport Layer Security）。
* 安全措施：
* 網路邊界防護： 網路邊界（perimeter）的防火牆應被小心管理，以過濾流量並防止可疑活動。
* 通訊加密： 與一般分散式系統一樣，網路通訊應透過加密來確保安全。
* 組件間身分驗證： 由於系統由許多組件（如伺服器、終端和筆記型電腦）組成，它們之間需要進行身分驗證。
* 

---
#### 3. 服務導向架構 (Service-Oriented Architecture, SOA)
* 在 SOA 架構中，服務是分散式且鬆散耦合的，這使得安全通訊和身分控制至關重要。架構必須確保每次互動的安全性身分驗證、授權和日誌記錄（責任追究）。
* 核心目標： 旨在創建一種靈活存取系統和數據的方式。
* 機制與協議： 通常是透過創建訊息傳遞通道，讓現有組件之間能夠進行互動。
* 
* 通訊： 兩個主要的通信協議是 SOAP 和 REST。
* REST 是一種更簡單、更高效的服務，但由於它使用 HTTP 進行 CRUD（創建、讀取、更新、刪除）功能，因此安全性較低。
* 演進： 微服務 (Microservices) 是 SOA 的下一階段，是一種獨立的、單一用途的微型應用程式。
* 以服務為導向的架構允許模組化成長並解耦服務，而 API Gateway則強制執行一致的集中式存取控制。

----
#### 4. 廣泛連接的設備與控制系統
##### 物聯網 (Internet of Things, IoT)
* IoT 系統的爆炸性增長極大地擴大了攻擊面，因為它們通常不在傳統 IT 部門的管理範圍內。
* 定義： 一個由相互關聯的計算設備組成的系統，能夠在無需人為互動的情況下透過數位網絡進行通信。
* 設備範圍： 包含從行動電話、平板電腦到大樓管理系統（如 HVAC、溫控器、電梯）和無線工業設備。
* 安全挑戰：
* 設計缺陷： 許多 IoT 設備缺乏足夠的記憶體或強健的作業系統來實施配置控制和存取管理等安全措施。
* 攻擊面： 這些設備連接到企業網絡，可能成為攻擊者入侵企業網絡的通道。
* 難以維護： 許多 IoT 設備壽命長，且常難以存取或嵌入在其他設備中，導致即使檢測到漏洞，也通常無法進行修補或更新。

##### 工業控制系統 (ICS) 及 SCADA
* ICS 和 SCADA 屬於營運技術 (OT) 範疇，用於監控和控制工業環境中的實體流程。
* 功能： SCADA 系統用於實時監控、處理和收集數據，以控制流程，例如電力分配或管道系統。ICS 系統用於操作許多先進的工業機械和流程。
* 歷史與風險： 這些設備傳統上是物理隔離（air gapped）的，但隨著現代化採用基於 IP 的通信，它們經常整合到 IT 網絡中，使其更容易受到網絡威脅。
* 核心挑戰： 安全與安全的權衡（Safety vs. Security）。由於這些系統（如切斷電源）要求快速反應（在幾分之一秒內完成），整合身份驗證或完整性檢查等安全控制可能會延緩流程，進而可能危及工作人員生命安全。
* 架構建議： 應透過網絡分段（或採用物理隔離）來保護這些設備，並可以考慮實施零信任安全模型。
* 

----
#### 5. 現代網絡技術
##### 軟體定義網絡 (Software Defined Network, SDN)
* SDN 代表了網絡技術的演進，旨在提供更優化、更具彈性的網絡連接。
* 核心架構： 將網絡功能抽象化為三個層面，透過 API 進行通信：
* 管理平面 (Management Plane)：頂層軟體，支持業務運營並允許管理底層基礎設施。
* 控制平面 (Control Plane)：位於管理平面和資料平面之間，將管理指令應用於網絡元件。
* 資料平面 (Data Plane)：由路由器、交換器、防火牆等網絡元件組成，代表數據傳輸。
* 優勢： SDN 提供了靈活性、敏捷性、冗餘性、效率、可擴展性，以及自動化管理和快速分配網絡資源的能力。
* 

##### 內容傳遞網絡 (Content Delivery Networks, CDN)
* 目的： 開發 CDN 是為了解決傳統網絡模型中，用戶存取遠程伺服器時會出現的明顯延遲（Latency）問題。
* 運作方式： CDN 由分散在世界各地的大量邊緣伺服器 (edge servers) 組成。當用戶下載內容時，文件會下載到離用戶最近的邊緣伺服器，並儲存在快取中。
* 效果： 實現了內容在網際網路上更高效的傳輸，提高了高可用性和整體性能。
1. 網絡架構的演進與安全挑戰
* 從集中式到分散式：
* 過去的系統多為集中式的大型主機，硬體集中在安全的機房內，實體安全相對容易。隨著技術發展，企業轉向分散式系統，特別是基於主從式模型的三層架構。
* 安全邊界的重新定義：
* 在傳統的本地（On-premises）環境中，安全範圍和所需控制相對較小。
* 當系統開始與外部實體（如合作夥伴、雲端服務）整合時，網絡和安全邊界必須重新定義，這促使了複雜安全架構的發展，例如網絡分段（segmentation）以保護數據和系統。

### 2.1.2 框架
* 框架提供了一種結構化的方法來規劃和設計系統，以確保最終的解決方案能夠滿足當前和未來的業務需求。
* 框架旨在解決的挑戰：
1. 需求不斷變化： 專案需求經常發生變化，框架有助於應對這些變化，以確保最終產品滿足使用者需求。
2. 設計思維的轉變： 從過去基礎設施驅動（infrastructure-driven）的系統，轉向數據驅動（data-driven）的系統。在數據驅動的系統中，硬體平台（如雲端環境）變得幾乎無關緊要。
3. 溝通問題： 業務和技術人員之間的溝通不良，常常導致交付的系統無法滿足實際的業務需求。
4. 安全整合滯後： 業務領導者經常優先考慮功能，而將安全考量推遲到專案生命週期的後期。如果安全沒有在早期階段納入，就很難整合一個有效且高效的解決方案。
5. 實現一致性： 框架旨在建立一個一致、有效，且可被業務重複利用的可重複模型。
成功的關鍵要素：
* 管理層支持：無論選擇哪種框架，成功實施的關鍵在於獲得管理層的支持，以強制將該架構框架應用於所有 IT 系統和業務流程。

----
#### 具體架構框架

| 框架 | 主要關注點 | 目的/設計理念 |
| -------- | -------- | -------- |
| TOGAF | 企業架構: | 旨在==提供一個流程和工具，用於開發企業架構==。目標是讓高層次的需求指導一個一致的架構模型，該模型可在整個組織的系統中部署。 |
| SABSA | 安全架構：安全與業務流程 | 旨在將安全與業務流程對齊。它是一種==基於風險與機會的方法==，目的是開發一個企業安全架構，建立可重複的安全模型。 |
| Zachman | 企業工程:IT與業務 | 旨在解決 IT 交付的專案與業務不一致的問題。它的目標是確保系統由業務的高層次使命驅動，並解決所有利害關係人（stakeholder）的需求。|

* TOGAF 支援整體企業規劃。
* Zachman 整理了架構觀點，但不重視策略協調。
* SABSA 則強調基於風險的安全協調，而非企業範圍的 IT 策略。

#### 1. Zachman 框架 (The Zachman Framework)
* 設計方法： 是一個由企業架構先驅 John Zachman 創建的自上而下 (top-down) 模型，為解決IT與業務對齊問題。
* 核心目標： 為解決 IT 交付專案失敗率高的問題，專注於企業工程 (enterprise engineering) 而非僅是系統工程。
* 一致性要求： 確保 IT 解決方案與企業的頂層使命 (high-level mission) 保持一致，並確保所有利害關係人的需求都得到解決。
* 設計流程： 從業務的背景和概念層次開始，設計是從高層次的業務需求（Goal List, Process List 等）逐步推導至技術選擇和系統組件的建構。


#### 2. ==SABSA (Sherwood Applied Business Security Architecture)==
* 設計方法： 也是一個自上而下 (top-down) 的方法，包含 5 個水平層：情境層、概念層、邏輯層、物理層、組件層。一個垂直層專注於跨架構的安全管理服務。。
* 核心目標： SABSA 特別專注於在==安全與業務流程之間創建一致性 (alignment)==。它是一個業務驅動 (business driven) 的框架，基於風險與機會。
* 模型輸出： 旨在開發一個可在組織中重複應用的企業安全架構模型。

#### 3. ==TOGAF (The Open Group Architectural Framework)==
* 設計方法： TOGAF（The Open Group Architectural Framework）是另一個自上而下 (top-down) 的企業模型。
* 核心目標： 建立一個一致的、可重複使用的架構模型，使 IT 與業務目標保持一致，包括跨職能規劃和整合。
* 策略對齊： 其目標是確保最終的架構能夠預測業務方向，並支持戰略目標。
* 效益： 透過部署基於此框架的產品，可以實現可重複的方法、遵守標準，並改善團隊之間的溝通。
* 專注點： TOGAF 專注於提供開發企業架構的流程和工具。
* 

* COBIT 是一個用於協助 IT 環境治理和管理的架構。
* 網路安全專用框架包括 NIST 網路安全框架，該框架包含五個並行且連續的階段：識別、保護、防禦、回應和復原。它可以與 TOGAF、SABSA、COBIT 等框架結合使用，也可用於衡量安全架構的成熟度和進行風險評估。

### 2.1.3 參考架構和藍圖 (Reference Architectures and Blueprints)
* 參考架構和藍圖是設計和開發安全解決方案中不可或缺的工具。
* 目的在於提供一個通用詞彙、可重複(reusable)、高效且符合行業最佳實踐的解決方案基礎。
* 參考架構
* 提供經過測試、可重複使用的模板，可加快系統開發速度並提高專案間的一致性。
* 並非完全不需要利害關係人的投入，而是依賴成熟的方法，縮短設計時間並減少錯誤。
* 並不能自動確保合規性或最佳邏輯結構——這些取決於具體情況。
* 真正價值在於標準化和降低風險。使用它們還可以幫助協調跨系統的安全實踐。

藍圖是針對不同用例和利害關係人準備的真實架構圖的表示，它簡化並抽象化了現實世界。

#### 核心概念與區分：
* 參考架構 (Reference Architecture)：
* 提供一個框架，通常針對特定領域或技術（如安全或雲端服務）。
* 它是基於供應商或行業最佳實踐，並作為創建更詳細設計的起點或範本。
* 一個好的參考架構應展示政策如何實施、說明使用案例情境、使用視覺圖表展示數據和通信流、闡明協議與標準，並記錄整合點。
* 微軟網路安全參考架構 (MCRA) 是一個主要範例，它專注於促進零信任原則的設計和實施。
* 藍圖 (Blueprint)：
* 是更詳細的計畫，提供具體的實施指令。
* 藍圖從參考架構中獲取高層指導，並將其轉化為切實可行的、針對特定專案的實施計畫。它包含設計細節、組件和設定。
* 在 IT 領域，藍圖用於構建特定的系統或產品，包括參考架構。
* 藍圖提供可重複使用的實施指導，有助於在部署和操作中實現一致性。
* 有些供應商提供的藍圖甚至可以實現自動化部署，將設計直接應用到目標環境中。
#### 應用優勢：
* 效率與標準化： 利用已有的參考架構和藍圖可以節省時間和金錢，因為大部分基礎工作已完成，只需根據需求調整即可。
* 衡量標準： 它們為標準和最佳實踐提供了基礎，並可隨時作為衡量營運中系統合規性的基準。

----
#### 相關安全模型與配置概念摘要
* 本章節也回顧了設計安全系統所必需的基礎安全模型和配置概念。
1. 基礎安全模型 (Security Models)
* 安全模型定義了資訊流動和交易在業務流程中如何遵守基本的存取規則：

| 模型名稱 | 核心原則 (CIA 重點) | 關鍵規則與目標 |
| -------- | -------- | -------- |
| Bell-LaPadula 模型 | 機密性 (Confidentiality) | 1. 簡單安全條件 (Simple Security Condition)： 禁止向上讀取 (No Read Up):低密級使用者不能讀取高密級文件。 2. 星型安全條件 (Star Security Condition)： 禁止向下寫入 (No Write Down):高密級使用者不能寫入低密級文件。 |
|Biba 模型 | 完整性 (Integrity)，關注數據的準確性 |簡單完整性條件 (Simple Integrity Condition)： 禁止向下讀取 (No Read Down)；使用者不能讀取比自己完整性級別低的數據。 星型完整性條件 (Star Integrity Condition)： 禁止向上寫入 (No Write Up)；使用者不能寫入比自己完整性級別高的系統。|
| Clark-Wilson 模型 | 完整性 (Integrity)，關注業務流程的完整性 | 透過強制實施職責分離 (Separation of Duties, SoD) 來確保授權使用者無法進行未經授權的修改。 強制使用格式嚴謹的交易 (well-formed transactions) 來確保內部和外部數據之間一致性。 |
* Bell-LaPadula
* 
* 
* Biba
* 
* Clark-Wilson 模型
* 
* 

2. 安全配置 (Security Configuration)
* 基線 (Baselines)： 用於在整個企業中創建各種軟體產品的一致實施。
* 基線應代表系統必須滿足的最低可接受配置標準，以確保系統部署安全並符合操作環境的風險。
* 基線為審計提供了一個標準，可以據此衡量合規性。
* 客製化 (Tailoring) 允許調整滿足基線要求所需的條件，但仍必須提供足夠的安全保護。
* 若系統無法滿足基線要求，可能需要實施補償性控制（Compensating Controls），這些控制措施必須被認為能夠提供足夠的安全保護以獲得豁免。
* 

3. 基準 (Benchmarks)
* 定義： 基準源自國際標準、行業標準，或同一行業部門或地區其他公司遵循的最佳實踐。
* 用途： 用於確保組織的操作達到與同行業其他組織相同水準的盡職照護 (due care)。
* 風險： 如果其他組織沒有遵循良好的實踐，僅僅跟隨他們的基準可能是不謹慎的，甚至可能導致組織承擔法律責任。
4. 設定檔 (Profiles)
* 定義： 組織應基於基線和基準開發設定檔，以描述資產將如何受到保護和管理。
* 內容： 設定檔描述了資產在其操作生命週期結束時，如何被獲取、維護和處置。
* 價值： 設定檔描述了硬體或軟體如何根據基線進行配置，確保了系統在企業中的一致部署，並提供了衡量合規性所需的標準。
* 基準是用於評估績效、合規性或品質的標準或參考點。指南(guideline)提供程序指導，但不用於衡量。藍圖(blueprint)是一份詳細的設計計劃，工作說明書(SoW)概述了合約任務，而非績效標準。基準可以幫助組織評估差距並確定需要改進的領域。

### ==2.1.4 威脅建模框架==
1. 威脅建模的定義與目標
* 定義： 威脅建模是一種結構化的方法，用來識別和評估對系統或組織的潛在威脅。
* 核心目標： 主要目標是在系統開發生命週期 (SDLC) 的早期階段進行，這樣可以將安全措施直接內建到系統中，而不是後期補救。
* 產出與應用： 威脅建模的結果可用於指導系統設計、識別漏洞，並為後續的威脅追蹤 (threat hunting) 和風險緩解活動提供資訊。
2. 常見的威脅建模框架與方法 威脅建模的方法有很多種，來源中提到了兩個重要的框架作為範例：STRIDE 和 OWASP。
* STRIDE 框架：
* 由微軟員工於1990年代開發，是針對IT系統最常見威脅類型的縮寫。
* STRIDE 代表六大威脅類別：
* Spoofing (詐騙)：透過冒充其他用戶或設備來取得未經授權的存取。
* Tampering (篡改)：惡意修改數據或設定，導致完整性問題。
* Repudiation (否認)：用戶否認其行為或交易，使問責變得複雜。
* Information disclosure (資訊洩漏)：未經授權地向外部洩漏敏感資訊。
* Denial of Service (DoS, 阻斷服務)：中斷合法用戶的服務可用性。
* Elevation of Privilege (權限提升)：用戶在系統內獲得未經授權的更高權限級別。
* 使用此框架可以幫助開發團隊系統性地思考和應對這些常見威脅。
* PASTA
* 攻擊模擬和威脅分析流程 (PASTA) 是一個全面的七階段方法，它整合了業務目標、合規性和技術分析，以識別威脅並確定其優先順序。
* STRIDE 可以將威脅分類，但缺乏 PASTA 的業務一致性。
* CVSS 可以對漏洞進行評分，但無法對威脅進行建模。
* MITRE ATT&CK 是一個攻擊者行為框架，而非建模流程。MITRE ATT&CK 是一個知識庫，它將現實世界中的對抗行為劃分為戰術和技術，幫助組織機構繪製和偵測威脅。與 STRIDE 或 PASTA 不同，它專注於觀察到的攻擊者行為。網路殺傷鏈 (Cyber Kill Chain) 可以模擬攻擊階段，但缺乏 MITRE ATT&CK 的廣度和粒度。 PASTA 是基於流程而非行為的。
* OWASP 威脅建模專案：
* OWASP (開放式 Web 應用程式安全專案) 是一個提供免費、開放資源的非營利組織，其專案已成為行業標準。
* 此方法採取一種更偏向流程導向的模式，透過回答四個關鍵問題來進行：
1. 我們正在處理什麼？(What are we working on?) - 定義建模的主題和範圍。
2. 可能出什麼問題？(What can go wrong?) - 識別潛在威脅，可透過腦力激盪或使用STRIDE等結構化方法來完成。
3. 我們該怎麼辦？(What are we going to do about it?) - 決定如何應對每個威脅，例如實施緩解措施或採用接受、規避、轉移等風險管理策略。
4. 我們做得好嗎？(Did we do a good job?) - 評估威脅建模工作的有效性。
3. 威脅建模的實踐與工具
* 手動與自動化： 威脅建模可以手動進行，例如建立表格來列出威脅類型、影響和攻擊範例。同時，也可以利用自動化工具來輔助，這些工具能協助建立應用程式模型、評估已知威脅並提供緩解建議。
* 流程步驟：
1. 定義範圍： 首先確定評估目標 (TOE)，例如一個完整的系統或應用程式的一部分。
2. 繪製資料流圖 (DFD)： 產生資料流圖來視覺化地呈現基礎架構、應用程式、資料流、資料儲存、處理過程和互動者，並標示出信任邊界。
3. 識別與應對威脅： 利用框架 (如 STRIDE) 和威脅情報來識別威脅並規劃應對措施。
* leveraging 外部資源：專業人員通常會利用如 CVE (通用漏洞披露) 資料庫和 CVSS (通用漏洞評分系統) 等行業資源來識別已知漏洞並評估其嚴重性，而不需要自己進行複雜的評分。
* 推薦工具： 來源中提到了一些安全架構師應該熟悉的工具，例如：
* 微軟的免費威脅建模工具 (Azure)。
* IriusRisk。
* OWASP 的 Threat Dragon 和 pytm 等開源工具。
#### CVSS(ommon Vulnerability Scoring System)
* CVSS 提供了一個一致的框架來評估漏洞的嚴重程度，從而更容易確定修復工作的優先順序。
* 此評分系統考慮了可用性和潛在影響，但它並非完美或精確——它僅供參考。
* 基礎評分反映了漏洞的核心嚴重性和影響，是衡量緊急程度最可靠的指標。
* 時間和環境評分會根據具體情況調整基礎評分，但處於次要地位。
* 漏洞利用成熟度是時間分數的組成部分，而非緊急程度的獨立決定因素。
* 它確保所有漏洞都使用通用語言進行評估。這有助於減少漏洞響應中的主觀判斷。

#### API保護
* API 閘道提供集中的、可擴展的保護，包括輸入過濾、存取控制和速率限制。
#### Scheme validation
* 模式驗證(Scheme validation )透過確保資料正確性並防止格式錯誤或惡意輸入來保護 API。
* 客戶端憑證直接驗證裝置(Client certificates authenticate devices)並強制執行來源驗證。

## 2.2 核實與驗證設計
* 單元測試
* 整合測試
### 2.2.1驗證威脅塑模結果
* 威脅塑模（Threat Modeling）結果的驗證，是確保安全架構設計在實際系統建構後仍能有效運作的關鍵步驟。
* 從設計到實施的確認： 測試和驗證專案交付成果的過程，旨在確保系統滿足功能需求並被客戶接受。
* 安全控制的有效性： 驗證（Validation）的目標是確保所選的安全控制是正確的，並且能夠有效緩解風險。一個控制措施如果無法有效地緩解其存在的風險，那麼它的價值就非常有限。
* 納入專案早期： 威脅塑模的結果應該在系統開發生命週期（SDLC）的早期用於建構更安全的系統，並為持續的威脅追蹤和風險緩解活動提供資訊。
* 測試的角度： 測試應採取兩種方法：一是從使用者的角度，確保應用程式按預期功能運作，並找出可能導致系統故障或洩露的問題；二是以攻擊者的視角，尋找可被利用的弱點或妥協系統運營的方式。
* 測試時機： 測試通常是應用程式在提交給管理層投入生產前的最後一步。
* 問題追蹤： 即使是設計最好的系統也會發現錯誤。安全架構師應鼓勵對所有新的和變更的應用程式進行徹底的測試。
* 威脅向量Threat Vector

* 影響(impact)是指成功攻擊可能造成的損害或損失的程度。它是風險評估的核心部分，通常與可能性(likelihood)相結合來確定整體風險。機率(probability)估計事件發生的機率，而標量值是一個通用的數字概念。風險是影響和可能性的結合。因此，「影響」(impact)在威脅建模中特別指潛在危害的程度。
*
----
#### 功能測試（Functional Testing）
* 目標： 功能測試旨在證明應用程式按預期功能運作，並確保最終交付的產品符合其指定的功能需求並獲得客戶接受。
* 功能測試：於確認軟體是否根據業務需求執行其預期功能。它根據給定的輸入驗證特定的輸出，並檢查其是否符合功能規格。功能測試是確保系統符合業務目標的最佳選擇。
* 實質性測試（Substantive testing）：透過基於統計或可變屬性的樣本來檢驗交易的整個過程。
* 驗收測試： 功能測試是系統在獲准部署production前，進行最終驗收測試（acceptance testing）的關鍵部分。
* 迴歸測試 (Regression Testing):新的程式碼變更、修補程式或更新，無意中破壞了現有功能或重新引入了先前已修復的問題、錯誤或有缺陷的功能。
* 靜態程式碼分析：評估程式碼質量，但不確認業務等級功能。
* 功能測試用於確認軟體是否根據業務需求執行其預期功能。

* 發生原因： 迴歸問題通常是由於文件記錄不佳、變更控制流程不足或缺乏版本控制所致。
* 應對策略： 由於系統是持續演進和開發的，安全架構師應始終鼓勵對所有新變更的應用程式進行徹底的測試，並理解迴歸測試的重要性。
#### 衝擊分析 Impact Analysis
#### Threat landscape
* 威脅態勢是指不斷演變的網路威脅，包括跨產業的攻擊方法、漏洞和威脅行為者。它為了解組織面臨的風險提供了背景資訊。
#### 單點故障 (Single Point of Failure, SPOF)
* 定義： 單點故障是指系統中的某個單一組件，一旦該組件失效，將會導致整個業務功能的徹底損失或系統癱瘓。
* 架構要求： 安全架構師必須設計出對此類故障具有韌性（resilient）的系統。
* 冗餘設計： 關鍵系統應具備能力，即使在支持操作中斷時也能維持運營，例如使用**不間斷電源（UPS）**來保持系統運作。
* 資料中心標準： 例如，為了解決單點故障，Tier 3 和 Tier 4 資料中心的指引要求配備冗餘電源供應。
* 測試職責： 安全架構師必須理解迴歸測試的重要性，以及透過其他形式的測試來發現任何單點故障的必要性。

### 2.2.2識別差距及替代解決方案
1. 差距分析 (Gap Analysis) 的定義與流程
* 核心定義： 差距分析是一種比較系統或安全計畫的「當前狀態」(current state) 與「目標狀態」(end state) 的過程，目的在於識別其中的不足之處。
* 結構化流程： 進行差距分析通常遵循以下步驟：
1. ==選擇標準框架==： 使用行業認可的標準框架，例如 ISO 27002 或 NIST 網路安全風險管理框架 (RMF)，作為衡量與比較的基準。
2. 評估員工與流程：安全措施的有效性與人員的安全意識和訓練程度以及流程的有效性直接相關。了解員工和受信任的第三方如何存取網路和系統、變更如何實施以及如何對員工進行威脅和應對措施方面的教育，是分析的關鍵部分。
3. 收集數據： 審查現有的安全控制措施、系統、網路設備與應用程式。同時，從安全監控與報告系統中收集關於漏洞、事件及其他相關資訊的數據。
4. 分析安全計畫： 結合前述數據與工具，對現有的安全計畫進行詳細分析，找出其中的弱點，並制定改進計畫。
* 常見活動： 用於識別差距的具體活動包括架構圖審查、桌面演練 (Tabletop exercises)、紅隊演練 (Red Team exercises)、風險評估以及功能驗收測試 (Functional acceptance testing)。
2. 替代方案 (Alternative Solutions)
* 目的： 當差距分析完成後，若發現現有方案存在缺陷，便需要尋找替代方案來解決這些不足。
* 方法與考量：
* 識別替代方案的過程應包含與利害關係人進行討論、腦力激盪，並研究競爭對手的成功與失敗案例。
* 這可能涉及選擇不同的供應商、產品或技術。例如，為了滿足新的安全需求或彌補現有產品的功能差距，可能會決定更換一種新型的防火牆。
* 當產品已過時或供應商發布了「生命週期結束」(end-of-life) 通知時，也必須尋找替代方案。

### 2.2.3 替代解決方案/緩解措施/補償控制
#### 1. 識別與提出替代解決方案 (Alternative Solutions)
* 目的： 在完成差距分析（Gap Analysis）之後，可能需要==識別替代解決方案來解決設計中的缺陷、改進流程或達到安全目標==。
* 識別方法： 識別替代方案的過程應包括與利害關係人進行討論、傾聽和腦力激盪。同時，也應研究競爭對手，並從他們的成功與失敗中汲取經驗教訓。
* 範例與時機： 替代解決方案可能包括選擇不同供應商的軟體解決方案（例如更換不同類型的防火牆）。
* 當某個產品已過時或供應商發布了「生命週期結束」（end-of-life）通知時，也必須尋求替代方案。
#### 2. 緩解措施 (Mitigations)
* 目的： 緩解措施旨在降低已發現漏洞所帶來的風險。
* 應用方式： 緩解措施可以是任何類型的控制、應用程式、系統或配置技術，用於減少在評估活動中發現的漏洞風險。
* 風險緩解的實踐範例： 更新軟體版本、應用最新的補丁和安全修復，即使尚未識別到特定的漏洞，也是一種良好的風險緩解實踐，能將軟體帶到最新的安全版本。
#### 3. 補償性控制 (Compensating Controls)
* ==補償性控制是當組織無法滿足某項明確要求的控制措施時，用來彌補風險的替代性安全措施。==
* 定義與必要性： 補償性控制的採用時機是當某個要求的控制措施因技術或其他正當的業務限制而無法實施時。組織可以透過實施補償性控制來充分緩解該要求所涉及的風險，仍可被視為合規。
* 類型： 補償性控制可以是技術性、實體性或管理性的。
* NIST 提供的常見範例： 根據 NIST 的指導，常見的補償性控制包括：
* 加密 (Encryption)
* 存取控制 (Access control)
* 多因子驗證 (Multifactor authentication, MFA)
* 網絡分段 (Network segmentation)
* 應用案例： 例如，如果由於性能衝擊過大而無法對資料庫進行加密（一項標準要求），則可以採取以下補償性控制：限制使用者存取、鎖定管理員帳戶，以及透過網絡分段將資料庫置於防火牆後或獨立子網路中。
* 分層防禦： 補償性控制作為額外的控制措施，常以分層防禦（layered defense）的形式部署。其核心在於：如果理想的風險緩解控制不可行，可以選擇其他仍能充分緩解風險的控制。

#### 4. 補充性控制措施(Supplementary controls)
* 當基線保護措施不足以應對特定情況時，補充控制措施旨在加強基線保護。重新設計基線保護措施並非適用於所有系統，尤其是在問題較為孤立的情況下。當基線保護措施無法實施時（並非實施了但不足），可以使用補償控制措施。假設無需採取任何行動可能會留下重大漏洞。

獨立核實(Verification)與驗證（Validation）
1. 驗證 (Verification) vs. 驗證 (Validation)
* 核實 (Verification): 這個過程是為了確保設計包含了所有必要及規定的控制措施。它回答的問題是：「我們是否按照設計要求來建構系統？」(Are we building the system right?)。這是一個檢查清單式的活動，確認所有功能和安全需求都已納入設計中。
* 驗證 (Validation): 這個過程是為了確保所選擇的控制措施是正確且有效的，能夠真正地緩解已識別的風險。它回答的問題是：「我們建構的系統是否正確？」(Are we building the right system?)。一個控制措施即使被正確實施 (verified)，如果它無法有效降低風險，那麼它就是無效的 (fails validation)。
2. 獨立審查的重要性
* 提供客觀保證： 雖然專案團隊會進行初步測試，但由獨立的第三方進行審查，可以提供一個不帶偏見的客觀視角。這有助於確認產品的功能與安全操作皆正確無誤，並確認實施控制措施後的剩餘風險 (residual risk)。
* 誰可以執行獨立審查： 執行審查的第三方可以是組織內部另一個獨立的部門，也可以是外部的專家或公司。
3. 以攻擊者思維進行測試
* 開發攻擊情境 (Attack Scenarios)： 為了有效測試控制措施，測試案例應包含「攻擊情境」。這需要評估人員像攻擊者一樣思考，找出所有可能的攻擊途徑與方法。
* 思考攻擊者的動機與能力： 評估時需考慮威脅來源的能力和動機，無論他們是來自內部還是外部。
* 超越常規測試： 測試不應僅限於預期的正常操作，還應包含現實及看似不切實際的攻擊情境，以確保系統在未來演變的營運環境中仍具韌性。
4. 桌面演練 (Tabletop Exercises)
* 定義與目的： 這是一種模擬危機情境的演練，旨在評估技術、程序和人員的應對能力。其目標是在不對正常營運造成干擾的情況下，發現計畫中的瑕疵或問題。
* 演練的優勢：
* 將關鍵人員（包含其代理人）聚集在一起，讓每個人了解自己在危機中的角色。
* 有助於評估狀況、防止問題擴散，並以符合成本效益的方式應對。
* 建立與外部合作夥伴（如供應商、客戶）的信任關係。
* 關鍵角色： 演練中一個最重要且常被低估的角色是記錄員 (scribe)，他負責詳細記錄所有發生的事情與決策，以便後續進行有效評估。
* 演練後評估 (Hot Wash)： 演練結束後應立即進行檢討（稱為 "hot wash"），記錄哪些做得好、哪些做得不好，並為每個待改進項目指派負責人與解決時限。
5. 其他測試方法
* 模擬測試 (Simulation Testing)： 模擬真實危機的演練，例如消防演習或模擬設備故障，以確保管理人員能夠在規定時間內從備份中恢復數據。測試必須盡可能真實，而不危及生命或公司資產。
* 手動審查與同儕審查 (Manual and Peer Reviews)： 透過訪談員工、觀察流程或進行滲透測試來檢查政策與法律的遵循情況。同儕審查則是利用具備相關經驗或專業知識的合格人員，對評估、報告、設計等文件進行分析與驗證，是一種有價值的手動測試方法。

### 2.2.4 內部或外部第三方
#### 1. 獨立審查的目的與必要性
* 提供客觀保證： 儘管專案團隊會進行初步測試，但由獨立的第三方進行審查，可以提供客觀的保證。
* 驗證與殘餘風險： 獨立審查的目標是獲得對交付產品的正確功能與安全操作的獨立保證。它同時確認安全控制措施的有效性，並確定實施控制後的殘餘風險 (residual risk)。
* 審查方的身份： 執行審查的第三方可以是組織內部另一個獨立的部門，也可以是外部專家或公司。公司可能會邀請他們的供應商或客戶參與測試，以增進關係並建立信任。
#### 2. 第三方驗證的方法與視角
* 攻擊者視角： 測試應採取攻擊者的視角，以尋找可被利用的弱點或妥協系統運營的方式。
* 開發攻擊情境： 為了有效測試控制措施，審查人員應開發攻擊情境 (attack scenarios)。
* 測試有效性： 測試控制措施是否有效的唯一方法是將其與證明該控制措施是必要的風險聯繫起來。
#### 3. 桌面演練 (Tabletop Exercises)
* 目的： 桌面演練是一種模擬危機情境的練習。
* 功能： 旨在評估技術、程序和人員的應對能力，並在不對正常營運造成干擾的情況下發現計畫中的瑕疵或問題。
* 演練後評估： 演練結束後應立即進行檢討，稱為 "hot wash"，記錄哪些做得好、哪些做得不好，並為每個待改進的項目指派負責人與解決時限。
#### 4. 外部審計與保證報告
* 當組織依賴外部服務供應商時，第三方審計報告是證明盡職照護 (due care) 的重要依據：
* 合規性評估： 合規性通常基於第三方執行的評估，為客戶提供外部服務供應商的數據和服務將受到保護的保證。
* SSAE 標準： 美國註冊會計師協會（AICPA）發布的 SSAE 2018（鑒證業務準則聲明）規定了鑒證或審計業務的標準。
* SOC 報告 (System and Organization Controls)：
* SOC 2 報告審查服務組織控制措施的設計或運營有效性，從技術角度對組織的安全實踐進行審查。
* SOC 3 報告是一個高層次的摘要，通常提供給外部發佈，用於證明組織的安全實踐已經過獨立評估。
* Type 2 評估評估控制措施實際的運營有效性，通常在至少六個月的期間內進行。許多組織會使用 SOC 3 報告來展示他們已進行過正式的獨立安全實踐評估。

* 同儕審查（Peer review）將不同的團隊成員聚集在一起，共同審查設計或程式碼庫，透過集體審查來提高品質。同儕審查通常能發現個別評審員遺漏的錯誤或偏差。人工審查通常由個人單獨進行，可能缺乏客觀性。靜態分析是自動化的，建模著重於模擬系統行為，而不是審查設計的一致性。
* 建模和模擬可以確認預期工作流程和邊緣情況下基於角色的行為，從而提供廣泛的驗證。靜態和同儕審查檢查邏輯和設計，但不會針對實際互動進行測試。動態測試檢查執行情況，但不檢查角色背後的設計邏輯。
* 透過主機代理進行集中日誌記錄可實現企業範圍的視覺性，同時保持本地團隊的靈活性。

### 2.2.5 程式碼審查方法
* 人工審查(manual review)對於發現自動化工具通常會遺漏的上下文或業務邏輯問題至關重要，提供業務功能評估所需的深度洞察。。
* 靜態和動態分析有助於發現技術缺陷，但無法發現與業務規則相關的邏輯錯誤。
* 桌面演習評估的是規劃和協調能力，而不是實施缺陷。
#### 1. 目的與價值
* 證明功能與安全性： 測試的目的與價值是雙重的，既要證明應用程式按預期功能運作，也要找出任何可能導致系統故障或洩漏的問題。
* 測試時機： 測試通常是應用程式在提交給管理層投入生產前的最後一步。
* 安全視角： 測試應採取兩種方法：
1. 使用者視角： 從使用者的角度，檢查應用程式運作時可能出現的錯誤或問題。
2. 攻擊者視角： 從攻擊者的角度，尋找可被利用的弱點或任何可能損害系統運營的方式。
#### 2. 測試策略與規劃
* 測試策略（Test Strategy）： 組織應具備適用於所有 IT 系統的測試策略，並依此為每個單獨的應用程式制定測試計畫。
* 風險導向： 測試策略應基於風險，並識別系統中的關鍵和敏感部分與數據。
* 測試目標： 每個測試目標都必須透過開發測試案例（test case）來達成。
#### 3. 程式碼測試方法與工具
* 設計可測試性： 應用程式的可測試性（testability）應被設計和建構在應用程式之中。
* 這可能涉及在交易過程中捕捉數據快照，例如使用稽核掛鉤（audit hook）或啟用鎖定（locks）來追蹤交易，以深入了解應用程式的操作。
* 整合測試設施（Integrated Test Facility, ITF）： 可以在正常的業務流程中插入測試交易，以確保應用程式正確處理交易，用於檢測交易處理中的任何問題。
* 實質性測試（Substantive Testing）： 應透過基於統計或可變屬性的樣本來檢驗交易的整個過程。
* 如果樣本量不正確或選擇不當，可能會導致不正確的測試結果。
* ==軟體組成分析 (Software Composition Analysis, SCA)==：
* 由於大多數應用程式是使用**開源軟體（Open-Source Software, OSS）**組件構建的，程式碼審查和開源組件審查至關重要。
* SCA 工具用於分析客製化應用程式，以識別開源組件、授權資訊以及來自國家漏洞資料庫（NVD）和其他專有資料庫的已知漏洞。
* SCA 的優勢是能夠自動化該過程，並可實施在**整合開發環境（IDE）**中，貫穿整個軟體生命週期。
#### 4. 軟體安全測試類型（與程式碼審查相關）
* 來源中提到了幾種確保應用程式安全性的技術：
* 靜態應用程式安全測試 (SAST)： SAST 旨在在不執行程式的情況下，檢查原始程式碼或位元組碼，從而更早地在開發過程中識別漏洞。SAST 可以發現源代碼中的安全缺陷。
* 滲透測試 (Penetration Test)： 旨在利用（exploit）已發現的潛在弱點。
* 滲透測試可以驗證潛在弱點是否可被利用，並評估其相對嚴重性。
* 這些測試應在系統投入生產前進行，並定期重複進行（例如每季）。