# 資安架構實操：規劃及設計堅實安全架構
Author: Neil Rerup Milad Aslaner
# Summary
* 主要探討網路安全架構，其核心重點在於「架構」本身，而非僅限於「安全」概念。作者強調，網路安全應被視為對企業架構的品質保證，而非企業的核心業務，因此安全措施必須從解決方案的設計之初就全面整合，而非事後才追加。
* 書中為安全架構師提供了一些核心原則：
* 理解安全不是業務核心：安全架構師應以業務需求為導向，提供解決方案以應對風險，而非將安全凌駕於一切之上。
* 理解並緩解風險：不僅要指出問題，更要提出實際可行的解決方案。
* 溝通是成功的關鍵：架構師必須與各方利害關係人進行清晰、持續的溝通。
* 避免說教：透過傾聽利害關係人的需求來建立信任，而不是強制推行個人觀點。
* 方案由技術、人員、流程及治理組成：一個完整的解決方案必須全面考慮這四個層面。
* 持續向利害關係人重複確認所聽到的內容，以確保理解無誤並建立信任。
* 此外，本書強調標準化和模板化對於提高工作品質和投資報酬率的重要性。
* 在專案交付方面，書中深入探討了傳統瀑布式開發方法，這在大多數組織中仍是主流。安全架構師在每個階段（啟動、需求收集、設計、建置、測試、生產移交）的參與細節和所需交付的重要成果物都得到詳細說明。這些成果物包括需求文檔（特別是需求追溯矩陣 (RTM)）、供應商選擇文件、安全設計評估 (SDA) 和 架構設計文檔 (ADD)。
* 書中還提供了實用的網路安全設計指南，涵蓋了當今企業面臨的關鍵威脅領域，如端點安全（勒索軟體、間諜軟體、特洛伊木馬、病毒）、郵件安全、網路安全（DDoS 攻擊、竊聽、資料外洩）、雲端安全（資料外洩、憑證洩露、拒絕服務攻擊）、自帶設備 (BYOD) 和物聯網 (IoT) 等，並針對這些威脅提供了具體的緩解措施。
* 最後，本書展望了網路安全架構的未來。它分析了政治、經濟、技術、社會和競爭等環境變數將如何影響安全架構師的角色演變。趨勢顯示，安全職能將更深入地融入各個架構領域，最終可能導致專門的安全架構師角色被其他通用架構師所吸收。作者以反諷的語氣指出，這將是安全架構師成功實現其「將安全整合到一切之中」目標的標誌。

# 1.了解資安架構
## 定義與核心概念：
* 資安架構是以資安為重點的架構活動，而非有架構傾向的資安活動。
* 其本質是規劃和建構 IT 解決方案，並在其中整合安全考量。
* 架構學（Architecture）的目的是建構事物以使其更有用，而資安（Security）則旨在減緩進程、發現並理解如何破壞事物。理解兩者的區別有助於把握資安架構的重要性。
* 架構的根本目的是傳達未來的狀態，將業務資訊轉化為技術術語，並將技術資訊傳達給非技術人員。
## 資安架構的歷史演進：
* 架構實踐：始於 1980 年代中期，最早的框架是 1987 年 John Zachman 的 Zachman Framework。
## 框架多樣性：ISO 記錄了超過 67 種不同的架構框架。
* TOGAF (The Open Group Architecture Forum)：最知名，但在安全架構概念提出之前創建，因此未將資安和風險管理納入考量，僅將網絡、基礎設施、應用程式和資訊視為架構層。
* SABSA (Sherwood Applied Business Security Architecture)：在 2007 年創立，基於 TOGAF 和 Zachman，是一個獨特的基於安全的架構框架，增加了關於特定安全活動的第三維度。但其僅關注安全，未在整個 IT 組織中廣泛採用。
* 資安作為附加考量：早期 IT 中，安全常被視為事後添加的功能，這會導致解決方案中存在漏洞和弱點。
### 各層次的資安整合：
* 網絡層 (Network Architecture)：
* 資安問題最先浮現。防火牆的發明（例如 Check Point 的 Stateful Inspection）是資安架構的第一步。隨後引入了網絡分區（security zones），如 DMZ，以控制內部攻擊。VPN 和 VLANs 也用於保護網絡。
* 基礎設施層 (Infrastructure Architecture)：
* 為解決作業系統（如 Microsoft Windows）的程式碼品質問題，Microsoft 在 2002 年建立了 Trustworthy Computing Initiative，將 Secure Development Life Cycle (SDLC) 整合到程式碼開發中，以降低漏洞。單點登入 (SSO) 和聯盟 (Federation) 也在此層發展。
* 應用程式層 (Application Architecture)：
* 隨著應用程式開發的加速，安全架構師開始關注應用程式程式碼的品質控制。由於難以檢查所有程式碼，應用程式閘道器 (Application Gateway)、XML 加速器和 Web 代理（Web Proxy）等「路障」方法被標準化，用於保護應用程式。
* 虛擬化架構 (Virtual Architectures)：
* VLANs 和 VPNs 是虛擬化的邏輯延伸。虛擬化改變了管理員的角色，引入了擁有「上帝權限」的虛擬管理員。
* 雲端架構 (Cloud)：
* 虛擬化的邏輯延伸導致了雲端服務的興起（SaaS, PaaS, IaaS）。雲端安全仍處於初期階段，需要從保護設備轉向保護資訊。
## 組織中的架構層次：
* 治理 (Governance)：組織應對安全達成一致的基礎，包括政策、組織監督和原則。
* 戰略與專案管理 (Strategy and Program Management)：設定資安願景，確保所有架構與願景保持一致。
* 專案交付 (Project Delivery)：資安架構師在資安專案中扮演解決方案架構師，在非資安專案中扮演支援角色。
* 營運 (Operations)：接收專案產出並為新策略提供反饋，識別組織風險。
## 資安架構師的角色：
* 企業資安架構師 (Enterprise Security Architects)：
* 主要處理戰略和專案管理層面，提供企業級的資安願景和專案計畫。
* 解決方案資安架構師 (Solution Security Architects)：
* 專注於專案，可以是資安特定專案的解決方案架構師，或在非資安專案中提供支援。
* 資安工程師 (Security Engineers)：
* 也稱技術架構師，專注於技術實施、優化和支援。
* 首席資安架構師 (Chief Security Architect)：
* 最高級別的資安架構師，負責領導、管理團隊並參與治理層面。
## 標準化 (Templatization) 的重要性
* 透過標準化方法和模板，資安架構師可以顯著提高工作品質並加速交付速度，從而提高投資報酬率。

# 2.治理：資安架構的基石
## 資安治理的基礎：
* 資安治理是資安架構師所有工作的基礎，提供方向和框架。
* 沒有治理，資安會變得個人化，導致解決方案無法滿足組織需求。
* 資安人員若無治理支持，其意見僅代表個人觀點。
* 應從戰略角度處理治理，考慮組織特性和長期目標，模型化行為模式而非僅限於技術。
## 主要治理文件 (Artifacts)：
* 資安原則 (Security Principles)：
* 組織個性的核心，指導如何解釋政策和標準。
* 應簡潔明瞭，不超過一句話，並少於十條。
* 應涵蓋人員、流程、技術和治理四大核心組成部分。
* 制定流程：與多方利害關係人進行一對一訪談，收集他們的觀點，然後綜合整理，反饋以供校正，最終確定並溝通。
* 核心原則：資安不是核心業務，理解並減輕風險，溝通是成功的關鍵，不說教，解決方案是技術、人員、流程和（治理）的組合，治理驅動行動而非個人意見，向利害關係人重複確認所聽到的內容。
* 資安政策與標準 (Security Policies and Standards)：
* 資安架構師建立解決方案或提供指導的基礎。
* 必須獲得所有利害關係人（不限於資安人員）的同意與簽署。
* 政策 (Policies)：表明組織的意圖或目標，是核心價值，不應輕易改變。
* 程序 (Procedures)：實施政策的方法。
* 標準 (Standards)：衡量組織在某個領域的狀態的基準，通常不涉及強制執行。
* 寫作原則：文件應簡短、簡潔，理想情況下不超過兩頁。避免使用過於專業的術語，並盡量獨立於特定技術。
* 政策制定流程：先個別訪談利害關係人，然後根據訪談結果討論政策選項，提供多種風險程度的選項供選擇，最終審查草案並獲簽署。
* 資安架構指南 (Security Architecture Guidance, SAG) 文件：
* 旨在描述設計中需要考慮和解決的各個領域，可視為資安架構的入門指南。
* 確保資安是設計的一部分，而非獨立的層次。
* 應說明解決方案正在處理的資訊類型、機密性、完整性、可用性 (CIA) 要求，以及認證/授權、存取控制、資料傳輸中安全、資料靜止安全和審計日誌等要求。

# 3. 參考資安架構 (Reference Security Architecture, RSA)
* 重要性：是資安架構師最重要的工具，用於確保在設計解決方案、戰略或專案時不遺漏任何組件。
* 組成部分：涵蓋技術、人員、流程和治理四個核心組件。
## 技術參考架構：
* 邊界防護 (Border Protection)：
* 網絡層的安全組件，包括網絡分區（如測試/開發、QA/鏡像、生產、公司桌面、DMZ）。
* 設計規則：按資安分類邏輯分組設備，流量應從高安全性區域發起流向低安全性區域。移動設備普及後，網絡邊界從防火牆轉移到設備本身，設計應從保護設備轉向保護資訊。
* 偵測服務 (Detection Services)：
* 用於偵測正在發生的資安事件，如 IDS/IPS、網絡存取控制 (NAC)、事件監控 (SIEM) 和儀表板 (GRC)。
* 內容控制服務 (Content Control Services)：
* 控制文件進出企業的技術，如防毒軟體、反垃圾郵件過濾、網頁防毒、網頁活動監控、白名單和資料丟失防護 (DLP)。
* 配置管理 (Configuration Management)：
* 確保解決方案在生產中保持預期配置，包括組策略物件 (GPO)、強化 (Hardening)、虛擬化配置、補丁管理和漏洞掃描。設計規則：掃描解決方案不應穿透防火牆，應將代理置於每個安全區域內。
* 審計服務 (Auditing Services)：
* 確保架構符合組織標準，包括風險註冊表、資安認證實驗室、合規性掃描和行業標準。設計規則：確保能夠審計雲端解決方案的技術配置和控制。
* 實體安全技術 (Physical Security Technologies)：
* 不能忽略實體安全。
* 包括實體存取控制、影片監控、實體入侵偵測、訪客管理和中央管理系統 (CMS)。設計規則：將 CMS 的日誌整合到 SIEM 中，以關聯實體和資安日誌。
* 身份與存取管理 (Identity and Access Management, IAM)：
* 唯一能證明投資報酬率的資安領域。
* 可實現帳戶佈建、單點登入 (SSO)、聯盟、自助服務管理。 IAM 分為憑證、資料儲存庫、存取管理、佈建和聯盟。設計規則：集中化 IAM 存在風險，需根據解決方案風險級別決定。
* 密碼學服務 (Cryptographic Services)：
* 涉及加密技術。
* 包括傳輸中資料加密（VPN、TLS、SSL、SSH）和靜止資料加密。設計規則：將加密標準與 NIST 建議綁定。涉及金鑰和憑證管理 (PKI)，包括憑證授權單位 (CA)、憑證驗證、憑證撤銷列表 (CRL) 和高安全模組 (HSM)。
* 應用程式安全 (Application Security)：
* 大部分漏洞產生於應用程式層。
* 重點是 Secure Development Life Cycle (SDLC) 的整合。涵蓋需求收集、設計（設計模式、威脅建模工具）、建構（標準化開發者函式庫、程式碼最佳實踐、程式碼審查、服務導向架構 (SOA)、企業服務匯流排 (ESB)）和測試（動態程式碼審查、漏洞評估、模糊測試）以及生產階段的程式碼簽署。設計規則：在開發生命週期的每個階段使用檢查清單。
## 流程參考架構：
* 強調安全不是技術，而是流程。
* 涵蓋人員流程、資料控制管理、核心 SOC 流程、情報、架構、存取管理、業務連續性/災難恢復、資安工具集、合規性和業務參與。
* 與基礎設施組合作：採取品質改進/品質保證方法，關注硬化和配置管理。
* 核心 SOC 流程：應對危機（Operations Time）事件（Analytical Time）。 crisis response, triage, callout, case management, incident research, change management, problem management, event analysis, modeling/baselining, vulnerability/compliance scanning。
## 人員參考架構：
* 基於 Forrester 的「Security Organization 2.0」模型。
* 涵蓋資安監督、IT 風險、資安工程、資安營運和身份與存取管理功能。

# IV. 策略與專案層級的工作產物
## 資安架構策略 (Cybersecurity Architecture Strategy)：
* 企業資安架構師的職責，旨在支持業務方向。
* 核心四要素：身處何處（現狀）、目標何在（未來）、擁有何種資源、如何達成目標。
* 策略分層：企業策略、IT 策略、資安架構策略，層層支持。
* 需求收集：從 CIO、首席架構師、CISO、營運團隊、服務台和財務部門收集人員、技術、流程和治理相關的需求。
* 現狀評估：利用 RSA 結構化評估，識別技術、人員、流程和治理組件的現狀和架構風險。
* 環境變數：無法控制但必須考慮的驅動因素，包括政治、經濟、技術、社會和競爭變數。
* 未來願景/需求：使用決策四象限（重要且緊急、重要但不緊急、不重要但緊急、不重要且不緊急）來優先排序事項。應**專注於「重要但不緊急」**的事項來制定策略。
* SWOT 分析：識別優勢、劣勢、機會和威脅，影響戰略舉措。
* 舉措與路線圖：將研究和規劃轉化為具體的直接和間接舉措。
* 度量指標：選擇 2-3 個度量指標（人員、流程、技術、治理）來衡量戰略進展。
## 關鍵決策文件 (Key Decision Documents, KDD)：
* 記錄重大決策的理由，確保決策的透明度和可追溯性。
* 包含目的、議題、建議（核心）、假設、風險、限制、利害關係人需求和供應商資訊。
* 設計 KDD 時應保持開放心態，而非僅為已做出的決策找理由。
* 「無為」也是一個有效選項。
## 風險註冊表 (Risk Register)：
* 用於記錄和監控環境風險的工具。
* 區分不同類型的風險：安全風險、架構風險、專案風險和業務風險。
* 安全風險：通常處理超出我們控制範圍的事物。
* 架構風險：與我們意識到的決策相關，關於對技術環境進行更改（或不更改）的風險。
* 風險評估應始終基於風險級別和業務需求，而非行業最佳實踐。
* 持續衡量風險：使用一致的方法（例如可能性 x 影響），消除個人偏見。
* 風險影響評估 (Risk Impact Assessment, RIA)：一種工具，通過決策樹和預設測量快速且一致地評估解決方案風險。
## 白皮書 (Whitepapers)：
* 企業資安架構師用來溝通思想和觀點的工具。
* 可用於研究新技術、審查供應商產品、將資安整合到解決方案中以及評估供應商套件。

# 5. 專案交付中的資安架構
## 專案交付方法論：
* 瀑布模型 (Waterfall Methodology)：
* 最常見的專案交付方式，線性、步驟清晰、階段有審批門檻。
* 優點：邏輯性強，便於任務分離和品質控制。
* 缺點：耗時長，易引入官僚程序，導致成本增加。
* 缺陷成本：缺陷發現得越晚，修復成本越高。
* 瀑布模型通常包括：啟動、需求收集、設計、建構、測試和生產移交 (PTO) 階段。
* 敏捷方法 (Agile Methodology)：
* 最初用於軟體開發，注重快速交付小組件，而非一次性交付完整解決方案。
* 優點：更快看到成果，更快獲得投資報酬率。
* 風險：許多人將敏捷作為不規範操作和不充分文檔化的藉口。
* 資安架構師在敏捷中應保持簡單，並與敏捷團隊在每個微階段合作，關注戰略終點，但處理微觀戰術影響。
## 資安架構師在專案中的角色：
* 解決方案資安架構師：當專案本身是資安解決方案時，負責整個解決方案的交付，包括非資安方面。
* 支援資安架構師：在非資安專案中，作為資安領域的專家 (SME)，為解決方案架構師提供支援和建議。
## 各階段的資安架構活動與產物：
* 啟動階段 (Initiation Phase)：
* 由專案經理主導，確立專案範圍、預算和高層級設計。
* 資安架構師應：定義專案架構風險緩解措施，確保專案架構與資安戰略保持一致，並在專案風險註冊表中記錄架構風險。
* 避免專案經理因成本或時間而縮減需求範圍，這會影響未來策略。
* 需求收集階段 (Requirement Gathering Phase)：
* 專案中最重要的階段。若未妥善收集需求，專案失敗風險高。
* 資安架構師必須親自參與需求收集，不可推卸責任。
* 流程：像藝術而非科學。引導利害關係人從「無意識無能」到「有意識無能」，使用開放式問題。詢問「還有誰應該交談？」確保訪談所有利害關係人。將收集到的筆記反饋給利害關係人進行確認。
* 資安架構指南 (SAG) 在此階段發揮作用。
* 需求收集表：使用 Excel 表格作為模板，包含「業務需求領域」、「需求描述」和「提供的評論」三欄。涵蓋業務連續性、客戶標準/審計、功能、財務、介面、維護性、營運環境、可移植性、隱私、可靠性、報告、可擴展性、安全性和可用性等領域。支援資安架構師應提供其資安需求，例如資安架構策略、資安技術、日誌記錄、傳輸中資料和靜止資料保護以及 IAM 相關需求。
* 需求文件 (Requirements Document)：將原始筆記轉化為可用格式，依循業務需求領域結構化。將業務需求細分為功能性和非功能性需求，並為每個需求分配獨特的編號（例如 AV1）。需求一旦簽署，不應再添加新需求，以避免範圍蔓延。
* 需求追溯矩陣 (Requirements Traceability Matrix, RTM)：
• 專案交付過程中架構師最常用的文件。
• 作為衡量專案是否滿足需求的「成績單」，追蹤每個階段的進度。
• 追溯設計文件、程式碼模組、測試案例和使用者驗收確認。
* 設計階段 (Design Phase)：
* 資安架構師應儘早參與設計，而非等待設計完成後再提出修改。
* 支援資安架構師交付：建議的資安基礎設施、資安設計評估 (Security Design Assessment, SDA)、資安原則和適用的資安政策與標準。
* 解決方案資安架構師交付：供應商選擇、架構設計文件 (Architecture Design Document, ADD)、關鍵決策文件 (KDD)、需求映射和測試計畫。
* 建構階段 (Build Phase)：
* 資安架構師主要專注於確保設計按預期實施。
* 支援資安架構師關注：整合支援和資安架構驗證。
* 解決方案資安架構師負責：建構文件（詳列實體組件、連接方式、驗證資訊）、測試/開發環境實施和生產實施監督。
* 測試階段 (Testing Phase)：
* 解決方案應已達 95% 穩定。
* 測試計畫在此階段使用。
* 支援資安架構師：驗證漏洞掃描結果（並解釋給專案團隊）、驗證白盒/黑盒測試（應用程式安全）、資安功能測試（確保資安基礎設施正常運作）。
* 解決方案資安架構師：性能測試、單元測試、整合測試、高可用性 (HA) 測試、災難恢復 (DR) 測試和使用者驗收測試 (UAT)。
* 始終根據需求驗證測試。
* 生產移交階段 (Production Turnover, PTO)：
* 專案的最後主要階段。
* 與各營運團隊互動（SOC、NOC、Wintel/UNIX 團隊、應用程式團隊、服務台、變更諮詢委員會 CAB）。
* 資安架構師需確保：將建構文件提供給 SOC，SOC 調整系統；解決方案資安架構師提供建構文件、測試結果、ADD，並更新票證系統。
* 專案交付產物：詳細闡述
◦ 供應商選擇 (Vendor Selection)：
▪ 應由需求驅動，而非盲目選擇產品。
▪ 流程：收集需求，識別產品需求，為需求建立權重，選擇評估團隊，研究供應商產品，選擇供應商組，發送 RFP，根據響應縮小供應商範圍，準備 QA 環境進行烘烤測試 (Bake-Off)，評估結果，選擇主要和備用供應商，談判，結束流程。
▪ 評估業務標準：補丁頻率、參考文檔、供應商年齡和財務可行性、過往記錄、市場份額、支援地點、改進路線圖。
◦ 資安設計評估 (Security Design Assessment, SDA)：
▪ 當支援資安架構師在設計過程後期才介入時，用於審查設計並提供建議。
▪ 包括專案計畫（範圍、高層級需求、交付物、滿意度標準、假設/限制/風險）。
▪ SDA 檢查清單：列出期望看到的文檔清單（行政、架構、設計、產品文獻、營運支援、合規性、資訊文檔）。
▪ SDA 工作簿：收集評估相關資訊，為每個架構層建立單獨標籤（資訊、網絡、應用程式、基礎設施、合規性、風險、參考、偏差），並記錄發現和建議。
▪ SDA 執行摘要：向專案團隊和專案發起人提供建議的簡短模板化報告，核心是評估結果和建議。
◦ 建構文件 (Build Documentation)：
▪ 為營運團隊提供關於實體組件、連接方式和驗證資訊的詳細說明。
▪ 包含安裝表、資料庫表、管理員表、用戶名表、URL 表以及 SSL 憑證、CLI 命令、日誌資訊和支援系統等附加資訊。
# 6. 架構設計文件 (Architecture Design Document, ADD)
* 重要性：架構師可以創建的最重要的文件（需求收集是最重要的活動）。
* 與建構文件的區別：ADD 是應該創建的設計（85% 穩定），而建構文件是已經創建的內容（100% 穩定）。
* 方法：應與組織使用的架構框架保持一致（如 TOGAF、Zachman）。可以記錄現狀或僅記錄將發生的變更。
* 資安整合：資安應內建於架構的各個層次，而非獨立部分。
* 結構：
◦ 文件頭部分 (Header Sections)：目的、摘要、用途、執行摘要（供高階主管閱讀的簡短概述）、範圍（明確指出納入和排除的部分）、需求參考。
◦ 目標架構 (Target Architecture)：ADD 的核心部分。
▪ 業務架構 (Business Architecture)：關注解決方案對業務流程、人員職責和治理的影響，包括流程圖和 RACI 圖。
▪ 資料與資訊架構 (Data and Information Architecture)：
• 資安架構最重要的一層，關乎資訊本身的安全。
• 包括解決方案資訊（資料庫結構、資料結構）和系統資訊（日誌、元資料）。
• 資安考量：關鍵性分類、CRUD 矩陣（權限）、靜止資料安全（加密）、傳輸中資料安全。
• Tokenization (標記化)：將敏感資訊替換為標記，以在雲端環境中保護資料隱私。
▪ 應用程式架構 (Application Architecture)：涵蓋介面和應用程式。分為 COTS (Commercial Off-The-Shelf)、客製化和混合應用程式。強調 Secure Development Life Cycle (SDLC) 的整合。資安組件包括應用程式層級角色、認證來源、資安日誌記錄和 Web 應用程式防火牆 (WAF)。應用程式資安架構檢查點包括：部署與基礎設施、輸入驗證、認證/授權、配置、敏感資料、會話管理、密碼學和例外處理。
▪ 基礎設施架構 (Infrastructure Architecture)：資安架構師花費時間最多的一層。包括網絡組件（IP 地址、VLANs、防火牆規則）、伺服器組件（作業系統、埠、服務）、資料庫組件（伺服器配置、連接）、應用程式伺服器組件、管理/監控工具、備份組件和終端組件。應利用 RSA 確保各個安全層次（邊界防護、偵測服務、配置服務、審計服務、IAM 等）得到充分考慮。
◦ 結尾部分 (Concluding Sections)：
▪ 差距分析 (Gap Analysis)：描述與需求文件中的差距，說明原因，並記錄業務、架構和資安風險影響。
▪ 建議 (Recommendations)：記錄架構師在創建解決方案過程中學到的、超出專案範圍的經驗和改進建議。
# 7. 資安架構與營運
• 營運作為關鍵利害關係人：營運團隊是最常見的利害關係人，理解他們的需求對於最小化解決方案成本至關重要。
• 策略回饋循環：策略驅動解決方案，解決方案移交營運維護，營運再向策略和解決方案提供回饋，形成回饋循環。
• 能力改進：與營運團隊討論現有解決方案的能力、優勢、劣勢和需解決的問題 (SWOT)，不僅限於技術，還包括人員和流程。
• 資安架構策略的輸入：每個營運團隊的需求，無論是基於規劃還是合約，都應作為策略的輸入。RSA 是組織這些輸入的良好結構。
• 監控架構風險：
◦ 遺留系統 (Legacy systems) 是最大的架構風險來源。
◦ 選項：調查、選擇、部署、營運/維護、退役。
• 支援營運策略：理解各營運團隊的活動和計畫，並支援其發展。透過整合能力，可降低總體成本和支援成本。
# 8. 實用資安架構設計
• 核心假設：每個組織都必須假設自己已被入侵。
• 主要威脅領域：
◦ 終端安全 (Endpoint Security)：
▪ 焦點從網絡攻擊轉向終端攻擊。
▪ 勒索軟體 (Ransomware)：加密設備硬碟、共享驅動器、可移動存儲媒體，要求支付贖金。緩解措施：備份資料、更新防毒軟體 (AV)、尋求專業技術支援、支付贖金。
▪ 間諜軟體與廣告軟體 (Spyware and Adware)：未經用戶同意收集個人資訊或彈出廣告。緩解措施：更新作業系統和程式、安全儲存密碼、配置瀏覽器安全設定、安裝防毒軟體。
▪ 特洛伊木馬 (Trojan Horses)：偽裝成合法軟體執行惡意功能。緩解措施：避免下載可疑軟體或來自可疑網站的軟體、避免在瀏覽器中儲存密碼、使用防毒軟體。
▪ 病毒 (Viruses)：竊取、操縱或破壞資料，自我複製並感染其他程式。緩解措施：避免點擊可疑連結/附件、避免公共 Wi-Fi、使用主機防火牆、更新防毒軟體、格式化硬碟、用戶培訓、企業防毒程式、避免使用 Windows XP 等已終止支援的作業系統。
▪ 總結：終端安全是現代安全架構最重要的方面之一，備份和強密碼策略仍是關鍵。
◦ 郵件安全 (Mail Security)：
▪ 電子郵件是常見的攻擊媒介，用於傳輸惡意軟體和進行網路釣魚。
▪ 威脅：惡意軟體（附件、連結）、非惡意軟體（網路釣魚、CEO 詐騙）、傳輸中被截取、弱密碼。
▪ 最佳實踐：嚴格的郵件安全政策（附件、連結、CC/BCC 使用、明文憑證、複雜密碼）、使用安全交換伺服器（如 Microsoft Exchange Server），用戶安全教育（網路釣魚、CEO 詐騙）、主機資安工具、加密、保護 Webmail 應用程式、郵件掃描器和郵件備份。
◦ 網絡安全 (Network Security)：
▪ DDoS 攻擊：通過殭屍網絡向網站或伺服器發送大量非法請求，使其過載。緩解措施：安裝有效防火牆、投資網路彈性 (cyber resilience)、建立替代站點。
▪ 竊聽 (Eavesdropping)：攻擊者截取網絡通信以收集敏感資料。緩解措施：使用 SSL 協議加密通信、安裝防火牆、入侵偵測系統 (IDS)、網絡分區、使用複雜密碼、避免不安全連接。
▪ 資料洩露 (Data Breaches)：駭客滲透網絡並存取敏感和機密資料。緩解措施：提高使用者對社會工程攻擊方法的認識、安裝入侵預防系統、使用防火牆。
▪ 總結：網絡邊界雖被認為「失守」，但基本網絡安全仍重要，機器學習和人工智慧將提高防火牆等工具的智能化。
◦ 雲端安全 (Cloud Security)：
▪ 隨著雲端採用率增加，攻擊者也將目標轉向雲端平台。
▪ 資料洩露：儘管雲服務供應商有安全措施，資料洩露仍是威脅，常因人為錯誤、應用程式漏洞或弱資安政策引起。緩解措施：使用雙因子認證 (Two-factor authentication)、加密資料傳輸。
▪ 憑證洩露 (Compromised Credentials)：用戶在雲端使用弱密碼的習慣導致的威脅。緩解措施：強制使用強密碼、使用第三方密碼管理器、雙因子認證。
▪ 拒絕服務 (Denial of Service)：威脅雲端可用性，用戶無法控制。緩解措施：建立備用站點。
▪ 總結：雲端提供多種資安優勢，多因子認證是關鍵。
◦ 自帶設備 (Bring Your Own Device, BYOD)：
▪ 降低組織成本，提高用戶移動性和生產力。
▪ 資料丟失 (Data Loss)：設備被盜或損壞導致資料丟失。緩解措施：安全備份、硬碟加密、限制敏感資料儲存、要求應用程式重新驗證。
▪ 不安全使用 (Insecure Usage)：員工家人或朋友使用設備，可能缺乏安全意識。緩解措施：要求員工使用兩個用戶檔案（工作和個人），分離個人與工作生活。
▪ 惡意方遠端存取 (Remote Access by Malicious Parties)：惡意方可能利用遠端存取憑證入侵組織系統。緩解措施：使用組織應用程式創建加密連接、敏感資料僅臨時存於主記憶體並在應用程式關閉後清除。
▪ 惡意應用程式 (Malicious Applications)：個人設備可能已存在惡意應用程式。緩解措施：檢查設備是否存在惡意軟體、鼓勵使用更新的防毒軟體、提供企業級防毒客戶端。
▪ 內部威脅 (Insider Threats)：內部人員利用 BYOD 政策的漏洞進行間諜活動。緩解措施：背景調查、基於角色的伺服器存取、共享驅動器的權限管理（讀寫權限）。
▪ 總結：BYOD 應在安全與生產力之間取得平衡，分層存取企業資源是好的實踐。
◦ 物聯網 (Internet of Things, IoT)：
▪ 資安攻擊面的新興領域，大量新興設備聯網。
▪ 弱認證/授權 (Weak Authentication/Authorization)：用戶懶於更改預設密碼，設備記憶體中憑證保護不足，用戶角色缺乏定義。緩解措施：強制一次性密碼 (OTPs) 和複雜性要求、加密憑證、分離用戶角色、鼓勵雙因子認證、要求重新驗證。
▪ 不安全介面 (Insecure Interfaces)：設計 rushed 導致介面漏洞。緩解措施：防止 SQL 注入和 XSS 腳本攻擊、加密憑證傳輸、強密碼要求。
▪ 配置不足 (Insufficient Configurability)：用戶無法修改設備內建安全控制。緩解措施：製造商在設計時優先考慮安全，更新 Web 介面以提供更多安全選項。
▪ 總結：IoT 市場蓬勃發展，但供應商多不重視安全，需注意強認證、安全介面和磁碟加密。
# 9. 資安架構技術趨勢與未來
• 技術趨勢 (Trends in Security Architecture Technology)：
◦ 利用 RSA 來結構化分析趨勢。
◦ 邊界防護：雲端安全（雲服務供應商將增強其安全產品）、標記化（解決雲端環境下隱私保護問題，符合 GDPR）、災難恢復（對快速恢復的需求增加，雲端降低了成本）、VPN（使用率可能下降，被 SSL 等加密協議取代）。
◦ 偵測服務：人工智慧 (AI)（實現即時響應、環境「自我修復」）、事件響應（自動化響應，Stix/Taxii 等協議實現資安技術間的溝通）。
◦ 內容控制服務：垃圾郵件作為新型網路釣魚技術（攻擊手法將更為巧妙）。
◦ 身份與存取管理 (IAM)：雙因子認證的使用將增加，手機將作為主要認證工具。
◦ 審計服務：隱私/GDPR（對隱私保護的需求增加，將有更多相關立法，可能出現國際標準）。
◦ 配置管理：終端安全（關注記憶體駐留惡意軟體）、新技術帶來新漏洞（AI、數位集中化、資料過載、使用者介面變化）。
◦ 密碼學服務：比特幣和區塊鏈安全（區塊鏈有望取代用戶名/密碼，用於 IoT 認證，推動去中心化）。
◦ 應用程式安全：應用程式服務於國家（供應鏈風險，考慮供應商來源國家的潛在刻意漏洞）。
• 資安架構的未來：
◦ 環境變數驅動：政治（立法驅動支出）、經濟（強調 ROI）、技術（漸進式變化，品質控制）、社會（資安職位細分化，支援資安架構師向審計角色轉變，解決方案架構師涵蓋資安技術）、競爭（精品架構公司興起，資安內建於產品中）。
◦ 洩露與反應：對更快發現和響應攻擊的需求增加。所有設備將日誌發送到 SIEM，事件響應自動化，自我修復網絡。
◦ 設計安全 (Secure by Design)：網絡設計從扁平化轉向更多安全區域。資安演進遵循 OSI 模型層次：從實體層開始，向上移動到網絡、基礎設施、應用程式、中介軟體、雲端，最終到達資料層。下一個重點將是「流程」，例如業務流程自動化 (BPA) 和業務流程管理 (BPM)。
◦ 網路資安與實體安全的融合：
▪ 由於物聯網 (IoT) 的發展，實體安全控制（如門禁系統、無線攝像頭）開始使用軟體和硬體，導致網路資安與實體安全領域的融合。
▪ 兩個領域的專業人員背景差異大，融合存在挑戰。
▪ 未來可能由首席風險官統一管理這兩個領域。
◦ 諷刺的成功：資安架構師的目標是將安全整合到一切事物中，這可能導致資安職位被其他架構師吸收，因為資安成為每個人的責任。這被視為資安的成功定義，但卻讓資安架構師的獨立工作崗位變得多餘。