# CISSP-ISSAP
* 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))

---
## 1.1 識別法律、法規、組織和行業要求
* 1.1.1 適用的資訊安全標準和指南
* 1.1.2 第三方和合約義務（例如，供應鏈、外包、合作夥伴）
* 1.1.3 適用的敏感/個人資料標準、指南和隱私法規
* <font color="yellow">1.1.4 彈性解決方案</font>

### 1.1.1 適用的資訊安全標準和指南
#### ISO/IEC 27000 系列
* 核心概念：此系列標準定義了資訊安全管理系統 (ISMS)，描述了組織為保護資訊所採取的控制措施。其目標是協助選擇、實施和管理安全控制措施。
* ISO/IEC 27001：這是一個規範性標準，提出了建立ISMS的要求。它可以幫助組織展示其遵循了良好的安全實踐，並向外部各方提供保證。
* ISO/IEC 27002：這是一個實踐指南，提供了可用於滿足風險處理要求的控制措施清單。這些控制措施涵蓋了政策、人力資源安全、資產管理、存取控制和實體安全等多個領域。
* 應用：安全架構師可以依賴這些標準來建立一個能夠提供充分保護並通過稽核的ISMS。這些標準提供了一個權威的基準，可用於衡量安全管理功能的有效性。
#### NIST 標準與框架
* 網路安全框架 (Cybersecurity Framework)：
* 此框架提供了一個建立網路安全計畫的步驟，包括識別 (Identify)、保護 (Protect)、偵測 (Defend)、回應 (Respond) 和復原 (Recover)。
* 它首先要求組織識別對其資產（包括人員、系統、資料等）的風險，並根據業務需求確定優先順序。
* 聯邦資訊處理標準 (FIPS)：這些標準對美國聯邦政府行政部門內的機構具有法律約束力。
* FIPS 199：強制要求對聯邦資訊和資訊系統進行安全分類，分類基於機密性、完整性和可用性 (CIA三元組) 的影響級別（低、中、高）。==系統的分類不能低於其處理資訊的分類。(high-water mark)==
* FIPS 200：規定了聯邦資訊和資訊系統的最低安全要求，為不同安全級別的系統設定了必須滿足的基準線。
* NIST SP 800-53：提供了一個全面的安全與隱私控制措施目錄，旨在為組織運營、資產和個人提供充分的保護。這些控制措施靈活且可客製化，以管理組織範圍內的風險。
#### ==支付卡產業資料安全標準 (PCI DSS)==
* 目的：由主要支付卡發行商（如Visa、MasterCard）創建，旨在增強全球支付帳戶資料的安全性。它不是法律，而是商家與銀行之間的合約協議的一部分。
* 核心規則：包含12項核心規則，是技術和營運要求的組合。重點包括：
* 安裝和維護防火牆以保護持卡人資料。
* 保護儲存和傳輸中的持卡人資料（例如，在開放的公共網路上加密傳輸）。
* 維護漏洞管理計畫，定期更新防毒軟體。
* 追蹤和監控對網路資源和持卡人資料的所有存取。
* 定期測試安全系統和流程。
* 維護解決所有人員資訊安全問題的資訊安全政策。
* 補償性控制：當組織因技術或業務限制無法明確滿足某項要求時，可以使用補償性控制來充分降低相關風險，從而仍被視為合規。

#### 選擇標準時的考量因素
* 有效性與歷史：該標準是否成功？它已經存在多久了？一個新推出的標準可能因為缺乏相關知識而難以實施。
* 組織成熟度：初創公司可能缺乏遵循複雜架構框架所需的成熟度，但選擇一個框架可以幫助其建立標準和可重複的流程。
* 方法：標準可以採用由上而下（從戰略願景開始）或由下而上（從單個活動開始組裝）的方法。此外，還有基於特定流程需求的流程特定標準。

### 1.1.2 第三方和合約義務（例如，供應鏈、外包、合作夥伴）
#### ==外包 (Outsourcing)==
* 組織選擇外包有多種原因，包括獲取內部可能缺乏的專業技能、讓組織能專注於其核心業務活動，以及更有效地應對需求波動而無需永久增加產能或投資設備。雖然外包看似能節省成本，但有時預期的成本節省並未實現。
#### 降低外包風險的關鍵措施：
* 清晰的合約：降低外包相關風險最重要的手段是簽訂清晰的合約。合約必須明確規定各方提供的服務水準、合約的有效司法管轄區，以及發生爭議時應採取的行動。
* 服務級別協議 (SLA)：透過SLA和可交付成果要求來確定績效要求至關重要。
* 供應鏈風險評估：合約可能要求對外包供應商的招聘流程有一定程度的信任，例如審查其組織和財務狀況、員工培訓和認證，或使用員工保密協議 (NDA) 來保護外包組織的智慧財產權。
* 溝通計畫：建立一個溝通計畫，設立單一聯繫點或聯絡人，負責兩個組織之間的介面，可以簡化溝通，從而降低風險。
* 安全整合：在整合基礎設施時，安全架構師需要確保安全通訊，例如可能需要建立交叉認證。此外，可能需要建立外部網路 (extranet) 以便在安全的網路區段交換資訊，並建立虛擬私人網路 (VPN) 以實現組織間的安全通訊。
* 安全架構師的角色：安全架構師在合約談判中的主要角色通常是理解與關係和共享系統相關的風險，或就外包決策提出建議，以確保安全問題得到解決。
#### 供應鏈風險 (Supply Chain Risk)
* 供應鏈風險管理是解決與供應鏈相關風險的關鍵過程，==NIST SP 800-161 Rev.1== 提供了相關實踐指南。
* 其目標是識別和避免不可信的供應商、防止假冒產品、篡改、未經授權的生產、盜竊以及惡意軟體的插入。
#### NIST SP 800-161 的供應鏈風險管理流程包含四個主要領域：
1. ==框架設定 (Frame)==：理解營運要求和關鍵任務威脅，並確定組織的限制、系統的重要性及其適當的基準。
2. 評估 (Assess)：評估風險是基於對威脅和漏洞的審查與分析。這包括分析威脅來源的能力和動機（對抗性威脅，如插入假冒產品或惡意軟體）以及自然災害等非對抗性威脅。同時，也需考慮供應鏈中的漏洞，例如供應商破產或缺乏品質控制。
3. 回應 (Respond)：根據風險評估的結果來確定是接受、減輕、共享、轉移還是避免風險。
4. 監控 (Monitor)：在選擇風險回應後，應進行監控以確保風險得到妥善管理。
* 許多組織和政府正在重新思考依賴不安全供應鏈的風險，並開始推動本地採購關鍵組件的政策，以確保品質控制並防止後門等安全漏洞。
#### 與外部實體的協調
* 在發生事件時，與外部實體（如媒體、監管機構、執法部門）的協調至關重要。
* 法律報告：許多隱私法規要求在發生潛在資料外洩時，必須在規定時間內通知監管機構和可能受影響的利害關係人。法律報告應透過受過訓練並被授權代表組織發言的聯絡人進行。
* 利害關係人溝通：必須迅速與客戶和員工等首先受影響的群體溝通，展現透明、誠實和開放的態度。同時，也需與供應商、金融機構、經銷商和監管機構保持溝通，以維持信任和支持。
* 公共關係：與媒體的合作尤其具有挑戰性，許多組織會將其公關職能外包給專業機構。應準備好傳達的訊息，並利用公司網站和社交媒體等多種渠道進行溝通。

### 1.1.3 適用的敏感/個人資料標準、指南和隱私法規
#### OECD 隱私原則 (OECD Privacy Principles):
* 基礎地位：
* 經濟合作暨發展組織(OECD)的隱私原則已成為全球許多隱私法律的基礎。其目的是為了促進跨境資訊的自由流動，並減少因隱私原則實施上的差異而產生的法律問題。
* 八大核心原則：
1. 收集限制 (Collection limitation): 個人資料的收集應有限制，並以合法、公平的方式獲取。
2. 資料品質 (Data quality): 個人資料應與其使用目的相關，並保持準確、完整和最新。
3. 目的明確 (Purpose specification): 收集個人資料的目的應在收集時或之前明確指定。
4. ==使用限制 (Use limitation):== 個人資料不應被用於指定目的之外的用途，除非獲得資料主體同意或法律授權。
5. 安全保障 (Security safeguards): 應採取合理的安全措施保護個人資料，防止遺失或未經授權的存取。
6. 公開原則 (Openness): 關於個人資料的發展、實踐和政策應保持公開透明。
7. 個人參與 (Individual participation): 個人有權確認其資料的存在、存取其資料、要求更正或刪除。
8. 責任承擔 (Accountability): 資料控制者應對遵守上述原則負責。
#### 歐盟通用資料保護規則 (GDPR):
* 重要性： GDPR可能是全球最重要的隱私法律，它為所有歐盟成員國制定了一致且強制性的隱私要求。
* 廣泛適用性： 即使組織總部位於歐盟經濟區(EEA)之外，只要向EEA內的個人提供商品或服務，也需遵守GDPR。
* 關鍵角色：
* 資料控制者 (Data controller): 決定個人資料處理目的和方法的實體，對資料保護負有最終責任。
* 資料處理者 (Data processor): 代表資料控制者處理個人資料的實體，例如雲端服務提供商。
* 資料保護長 (Data Protection Officer, DPO): 具備資料保護法律專業知識的專家，負責監督組織內部法規遵循情況。
* 核心要求：
* 資料外洩通報： 在懷疑發生資料外洩時，必須在72小時內通知受影響的資料主體和監管機構，除非洩露的資料經加密等措施處理，不大可能造成損害。
* 被遺忘權 (Right of erasure): 資料主體有權要求組織刪除其個人可識別資訊，但此權利並非絕對。
#### Gramm-Leach-Bliley 法案 (GLBA)：
* 專為金融機構制定，要求其向客戶揭露如何處理、分享和保護財務資料，並賦予客戶選擇退出的權利。
#### Sarbanes-Oxley 法案 (SOX)：
* 適用於所有美國上市公司，旨在透過==要求公司實施和報告內部會計控制來保護股東和公眾免受會計錯誤或欺詐行為的影響==。
#### 醫療健康資訊
* 目的:
* HIPAA的頒布是為了保護個人健康訊息，並規範美國的醫療保健隱私和資料處理實踐
* HITECH針對處理美國個人健康資訊(PHI)的醫療保健計劃、醫療保健資訊交換中心和醫療保健提供者。
* 要求：
* HIPAA要求必須為個人可識別的健康資訊提供隱私保護，並確保電子受保護健康資訊(ePHI)的機密性、完整性和可用性。
* HITECH法案則擴大了HIPAA的保護範圍，並加重了不合規的罰則。
#### 北美電力可靠性公司 (NERC CIP):
* 針對北美電力系統運營的行業標準，旨在確保關鍵基礎設施的可靠性和安全性。
#### 電子通訊隱私法 (ECPA)：
* 禁止未經授權攔截、使用或洩露任何有線、口頭或電子通訊。
#### 加州消費者隱私法 (CCPA)：
* 賦予消費者對其個人資料的權利，包括了解企業收集了哪些關於他們的資訊、要求刪除其資料，以及禁止出售其資料的權利。
#### 其他地區的法規
* 英國：主要法律包括《電腦濫用法》和《資料隱私法》（即英國版的GDPR）。
* 亞太地區：亞太經濟合作會議 (APEC) 制定了跨境隱私規則框架，核心概念包括預防傷害、提供通知、限制蒐集和個人資訊的正確使用。澳洲、紐西蘭和新加坡等國家也被視為符合GDPR規範。
* 拉丁美洲：許多國家將資料保護視為憲法權利。阿根廷等國家被認為符合GDPR規範。
* 注意司法管轄議題
### <font color="yellow">1.1.4 韌性解決方案</font>
* 韌性 (resiliency)
* 指系統或組織能夠防止系統和資料受到損害，或在==發生問題時能夠迅速恢復，僅造成極少的停機時間或功能損失的能力==。
* 於保護資料的隱私和敏感性，以及支持組織關鍵業務功能的系統和應用程式的可用性而言，這些概念至關重要。
* 從安全架構師的角度來看，除了實施法律、法規、指南和控制措施外，還可以透過以下幾種通用方法來開發彈性解決方案：
1. 強化安全態勢 (Strengthen your security posture)
* 主動採取全面的方法來實施強大的安全控制和資料保護機制，尤其是在資料彈性方面。
* 實施複雜的身份驗證和授權解決方案，確保只有授權人員才能存取系統和資料。
2. 制定全面的災難復原計畫 (Develop a comprehensive disaster recovery plan)
* 這是建立韌性解決方案的關鍵。
* 計畫應識別關鍵系統和資料，並制定應對任何中斷（無論是來自攻擊還是自然災害）的方案。
* 內建備援 (redundancy) 和快速復原流程與系統的能力，對於恢復資料和資源以維持業務連續性至關重要。
3. 實施有效的備份解決方案 (Implement an effective backup solution)
* 資料複製和備份能力非常重要。
* 了解資料保留和還原流程。
* 應根據資料的存取頻率和需要保留的時間長短，考量不同的儲存方案，如熱儲存 (Hot storage)、溫儲存 (Warm storage) 和冷儲存 (Cold storage)。
4. 實施雲端解決方案 (Implement cloud solutions)
* 雲端供應商在彈性方面扮演著重要角色，因為它們擁有廣泛的地理分佈，能夠提供容錯移轉 (failover)、備援 (redundancy) 和備份。
* 雲端供應商可以提供自動複製和容錯移轉系統的解決方案，以及多種類型的資料庫應用和儲存能力。這包括冷儲存，它雖然不易即時存取，但可作為恢復資料的**「氣隙」(air gap) 故障保護**措施。

## 1.2 針對治理、風險與合規 (GRC) 進行架構設計
* 1.2.1 識別關鍵資產、業務目標和利害關係人
* 1.2.2 設計監控和報告（例如，漏洞管理、合規性稽核）
* 1.2.3 設計可稽核性（例如，確定法規、立法、鑑識要求、職責分離、高保證系統）
* <font color="yellow">1.2.4 整合風險評估產物</font>
* 1.2.5 建議風險處理（例如，減輕、轉移、接受、規避）

### GRC
* 治理 (Governance): 制定組織的長期戰略方向，並建立問責制與所有權。這與專注於日常運營的管理(Management)不同。良好的治理是展現組織致力於法規遵循與盡職照護(due care)的關鍵。
* 治理即對標安全措施對標業務政策與策略
* 治理可確保跨業務功能實施一致的策略
* 透過清楚政策、角色指派及程序定義決策的架構
* 風險管理 (Risk Management): 雖然是資訊安全計畫的基礎，但常被誤解。風險管理充滿變數，且對不同人而言有不同的解讀。承擔風險是業務增長的必要部分，關鍵在於將風險控制在可接受的範圍內。
* 評估、處理及監控風險
* 合規性 (Compliance): 組織有義務證明其遵守了標準、法規、法律及最佳實踐。架構師必須將稽核、監控與衡量能力設計到系統與業務流程中，以證明風險得到有效緩解。
* 內部稽核確認組織符合法規或政策要求
* 紀錄與評鑑支持安全維運，但稽核直接展示遵守標準與法律
### 1.2.1 識別關鍵資產、業務目標與利害關係人
* 此部分強調風險管理必須與企業的使命和業務目標緊密結合。
#### 資產與業務的關係：
1. 了解業務目標與使命 (Relationship to Business Mission)
* 理解業務性質：安全架構師需要了解組織為何存在——是提供商品、服務，還是兩者兼具？是營利性企業、非營利組織，還是政府機構（如執法或軍事單位）？。不同性質的組織有不同的安全要求；例如，電子商務業務依賴安全的網路，而電力公司等受監管行業則有法律規定的正常運行時間要求。
* 確定核心業務功能：透過與高階管理層溝通，架構師需要學習哪些業務部分是組織希望在困境中生存下來的核心功能，哪些是可能被關閉或停止的周邊功能。
* 評估組織的生存意願與風險策略：了解組織在面對困境時是決心克服，還是只做最低限度的維持，這會影響風險管理策略的制定。有些組織追求安全與品質，而另一些則可能只遵守法律的最低要求以最大化利潤。
2. 識別與分類關鍵資產 (Identify and Classify Assets)
* 資產的定義：資產分為主要資產 (primary assets) 和支援性資產 (supporting assets)。
* 主要資產：包括業務流程、活動、產品和服務的提供，以及資訊資源。這些是業務的核心，其損失可能導致業務失敗。
* 支援性資產：幫助業務運行的資產，如硬體、軟體、網路、人員，甚至營業地點。這些通常是可以替換或外包的。
* 資產價值的確定：資產價值可能難以確定，因為它包含有形價值（如建築、設備的貨幣價值）和無形價值（如聲譽、品牌認可度和消費者信心）。組織聲譽的損失可能因資料外洩等事件而急劇下降，並產生法律責任和恢復成本。資產價值最終常基於所有者的看法。
* 資產分類：資產的分類通常基於機密性、完整性和可用性 (CIA) 的核心安全原則。分類反映了若未能滿足這些安全要求可能造成的影響級別（高、中、低）。資訊系統的安全分類不應低於其處理的資訊的分類。
* 資產所有權：識別每項資產的負責人或所有者 (owner) 至關重要，特別是資訊所有者，他們在法律上對資訊的保護負責。許多法律要求組織指定資訊所有者，他們需對資料保護承擔個人和企業代表的責任。
* 資產管理：組織應使用資產管理資料庫或配置管理資料庫 (CMDB) 來記錄所有資產，包括其唯一標識符、所有者、位置及關聯系統。若組織不清楚自己擁有什麼資產（如過時的網路圖或未追蹤的雲端服務），這些資產很可能未得到適當的監控和保護。
3. 識別利害關係人 (Identify Key Stakeholders)
* 利害關係人的定義：利害關係人是指對專案結果有利害關係、能影響決策或成功的個人或群體。
* 內部利害關係人：可能包括董事會成員、高階主管、董事、經理、技術負責人和安全人員。組織的風險所有者是董事會或具有預算權力的高階主管。
* 外部利害關係人：也應識別所有需要存取系統的內外部使用者，包括客戶、業務夥伴、監管機構和供應商。
* 溝通與參與：識別關鍵利害關係人後，必須記錄下來並建立持續的溝通管道，讓他們積極參與專案。透過與利害關係人的正式和非正式會議，可以設定期望、識別關鍵績效指標，並識別和減輕專案風險。
* 在設計及執行安全架構階段，識別跨部門的利害關係人確保系統要求對齊業務需要與合規期待
* 這方法避免窄化IT焦點或以指責為中心的模型，並促進了整體、協調的安全設計。

### 1.2.2 設計監控與報告
* 有效的風險管理需要持續的監控與報告，以確保控制措施的有效性。
#### 監控設計的核心原則與目的
1. 證明控制的有效性：風險管理需要選擇足夠的控制措施來減輕風險。唯一能確定風險是否得到妥善管理的方法，就是監控和衡量這些控制措施的有效性。如果一個控制措施無法被測試，那麼它就無法被信任。
2. 發現異常與問題：監控的主要目標是發現異常情況並揭露問題。這需要先建立定義正常操作的基準線，因為若不了解「正常」，就很難偵測到「異常」。
3. 支援合規與稽核：組織有義務證明其遵守標準、法規和法律。安全架構師必須將記錄和捕捉相關數據以證明合規性的能力，設計到系統和業務流程中。有效的監控和報告機制是第三方合規性稽核的基礎。
4. 漏洞管理：監控和報告是漏洞管理流程的集合，這些流程透過系統和人員來執行。這包括利用SIEM系統、威脅情資和行為分析來識別和緩解安全風險與事件。
#### 設計監控與報告能力的關鍵任務
1. 識別與實施技術解決方案
* 識別與實施技術：設計監控能力的第一項任務是識別並實施用於持續收集和分析數據的技術解決方案、程序和實踐。
* 安全資訊與事件管理 (SIEM)：SIEM 系統是常見的第一線漏洞管理解決方案，它透過代理程式和日誌監控系統，匯總來自多個來源的數據，並進行近乎即時的分析，為管理層和管理員提供有關當前威脅環境和系統活動的寶貴資訊。
* 威脅情資 (Threat Intelligence)：收集和分析來自全球網路流量監控、組織間數據共享、暗網監控等多種來源的數據，以了解全球對手的行動及其採用的技術。信譽饋送 (Reputation feeds) 可用於監控和攔截來自不良網站的流量。
* 行為分析 (Behavior Analysis)：建立正常行為的設定檔，並標記系統、流程或使用者的異常行為，例如在非預期時間的活動、可疑下載或多次登入失敗。
2. 確定監控範圍
* 監控必須在系統或業務流程的各個層級進行，包括：
* 使用者及其活動，特別是特權帳戶，因其風險較高，必須受到監控。
* 應用程式、交易和錯誤日誌。
* 硬體修補和使用年限。
* 對建築物和敏感區域的實體存取。
3. 整合至事件管理流程
* 支援事件管理：監控和報告能力的設計深受組織事件管理流程和工具的影響。許多技術解決方案（如SIEM）本身就具備工作流程管理功能，能在警報被標記並轉化為事件時啟動。
* NIST 事件管理框架：安全架構師應了解如NIST SP 861, Rev. 2等標準框架，該框架將事件管理分為準備、偵測與分析、遏制/根除/復原，以及事後活動四個主要步驟。
4. 支援主動式安全監控與修復
* 自動化：面對日益增長的數據量和複雜的雲端系統，監控與修復流程的自動化至關重要。
* 持續監控：整合國家漏洞資料庫 (NVD) 等威脅情資來源，實現持續監控，以發現錯誤配置、缺少修補程式和應用程式漏洞。
* 漏洞評估與滲透測試：這些測試應在系統投入生產前及之後定期進行，旨在於攻擊者之前發現問題，從而預防數據外洩。測試結果可用於證明符合法規要求和行業標準。
5. 支援稽核功能 (Auditability)
* 設計稽核證據來源：系統必須設計成能夠捕捉稽核證據，例如日誌、文件等，以供稽核人員收集和評估。
* 日誌管理：應啟用日誌，並制定流程來審查日誌、生成報告。日誌數據應儲存在符合法律規定的位置，並受到保護以防篡改。
* 持續稽核與控制自我評估 (CSA)：設計應支援持續稽核（不斷收集和分析稽核數據）和CSA（將監控控制措施的責任賦予地方管理層），以提高管理層的警覺性並縮短事件應對時間。
### 1.2.3 可稽核性設計
* 為了證明合規性，系統必須設計成可供稽核。
#### 可稽核性設計的核心目標
1. ==證明合規性：組織有義務證明其遵守標準、法規和法律==。安全架構師必須在系統和業務流程中內建記錄和捕捉相關數據的能力，以證明合規性。這些數據是第三方合規稽核的基礎。
2. 支援稽核流程：系統的設計必須能夠支援正式的審查或稽核過程。這意味著系統應能提供稽核所需的證據，例如日誌、文件和其他記錄，以便稽核人員收集和評估。
3. 確保控制措施的有效性：一個無法被測試的控制措施是不可信的。設計必須確保安全控制措施能夠被監控和衡量其有效性，從而證明風險已得到適當緩解。
4. 提供責任歸屬 (Accountability)：透過記錄和監控系統上的所有活動，並將這些活動追溯到特定的人員或流程，可以建立責任歸屬。這是身份與存取管理 (IAM) 中 IAAA 模型（身份識別、驗證、授權、責任歸屬）的最後一個關鍵步驟。
#### 可稽核性設計的關鍵要素
1. 日誌管理 (Log Management)
* 啟用並保護日誌：系統應設計為能夠透過部署日誌來捕捉事件，包括正常的允許事件以及錯誤或問題。日誌必須受到保護，以防止未經授權的篡改或刪除，例如通過檔案完整性檢查。
* 集中化與正規化：使用 SIEM (安全資訊與事件管理) 系統等工具，將來自不同來源（如防火牆、IDS/IPS、應用程式）的日誌數據匯集到一個中心點進行分析。數據應被正規化 (normalized) 為標準格式，以便於分析和關聯。
* 時間同步：確保所有系統的時間同步至關重要，例如使用網路時間協定 (NTP)。這對於在分散式網路中準確關聯來自不同系統的日誌條目至關重要。
* 日誌審查流程：必須建立審查日誌和生成報告的流程。由於日誌數據量龐大，應使用工具、過濾器和程序來尋找重要的異常、趨勢或可疑活動模式。
2. 內建稽核機制
* ==稽核掛鉤 (Audit Hooks)==：在流程中內建稽核掛鉤，允許稽核人員在交易處理過程中捕捉資訊。這有助於==即時識別問題==，而不是在流程結束後才發現。
* 整合測試設施 (Integrated Test Facility, ITF)：ITF 允許將測試交易插入正常的業務流程中，以驗證應用程式是否正確處理交易，而不會影響生產數據。
* 職責分離 (Segregation of Duties)：設計系統時應強制執行職責分離，以防止舞弊和錯誤。稽核功能本身也應由多於一人執行。
3. 網路與系統分段 (Segmentation)
* 分層控制：如同實體安全設計，網路和系統架構應採用分層控制（又稱深度防禦）的理念。透過將網路分段（例如，使用 DMZ、內部信任網路），可以在每個分段的邊界設置控制點。
* 在控制點進行監控：每個分段的邊界都是放置監控設備（如 IDS、防火牆）以記錄流量的理想位置。這使得網路流量的稽核成為可能，並能深入了解控制措施的有效性。
4. 支援持續稽核與自我評估
* 持續稽核 (Continuous Auditing)：設計應支援持續收集和分析稽核數據的能力。這有助於近乎即時地識別和解決問題，而不是等待年度稽核。
* 控制自我評估 (Control Self-Assessment, CSA)：系統設計應能支援本地管理者監控其職責範圍內的控制措施有效性。這不僅增強了管理者的風險意識，也縮短了事件應對時間。
5. 支援數位鑑識 (Digital Forensics)
* 證據的完整性：系統設計應考慮到在發生事件時支援數位鑑識調查的需求。這意味著系統捕捉的數據（如日誌）必須保持其完整性，以便在調查中作為可信證據，常見存放在WORM（write-once-read-many）儲存就是個例子。
* 監管鏈 (Chain of Custody)：設計應能支援記錄證據處理的所有環節，確保監管鏈的完整與不間斷。
* 將數位取證整合到系統架構中，可確保及時、可靠地收集證據。外部合作夥伴關係和自動化技術或許能夠支援回應，但無法取代嵌入式取證準備。

### <font color="yellow">1.2.4 整合風險評鑑產出</font>
* 風險評鑑的結果是用於指導後續風險應對的基礎。
#### 評鑑流程：
1. 驅動風險回應 (風險處理)
* 基礎決策：風險評鑑的結果是風險回應流程的主要輸入。評鑑報告會識別組織面臨的風險及其嚴重性或緊迫性。
* 管理層參與：安全架構師將風險評鑑的結果（產出）提交給管理層。管理層根據其風險偏好 (risk appetite) 來驅動風險回應的決策。
* 選擇處理方式：風險處理的目標是與管理層互動，選擇適當的方式來處理已識別的風險。處理方式包括：
* 避免 (Avoid)：停止或不從事產生風險的活動。
* 減少/緩解 (Reduce/Mitigate)：透過新增或強化控制措施（如安全保障措施和對策）來降低風險的可能性或衝擊。
* 轉移/共享 (Transfer/Share)：透過購買保險或建立業務合作夥伴關係將部分風險轉移給另一方。
* 接受 (Accept)：保留並承擔與風險相關的潛在損失。這是風險管理的最後一步，通常在實施控制措施後仍存在的殘餘風險 (residual risk) 才應被接受。
* 文件化：新識別或重新評估的風險會被添加到風險登記冊 (risk register) 中，並在下一階段的風險管理中用於證明風險回應的合理性。風險評估工具（例如風險登記冊）是動態工具，會隨著時間推移而不斷發展，為架構、治理和合規性決策提供關鍵輸入。它們並非靜態文檔，也並非僅限於審計用途。
2. 促進風險監控
* 回饋循環：風險處理完成後，進入風險監控階段。在此階段，安全架構師會監控風險處理措施的有效性，並將結果呈現給管理層。
* 衡量有效性：風險監控會追蹤已實施的控制措施是否達成了預期的結果，也就是說，它們在緩解風險方面是否有效。監控過程會將實際的殘餘風險與管理層可接受的風險水平進行比較。
* 觸發重新評鑑：當風險監控發現風險發生變化時（例如出現新威脅、新漏洞或業務優先順序改變），可以啟動對當前風險水平的重新評鑑。
3. 作為持續溝通與管理的基礎
* 管理層支持：將風險評鑑產出回饋給管理層，是為了在專案進一步進行前，確保管理層理解組織及特定系統的風險，並對所選的控制措施表示支持與同意 (buy-in)。
* 更新風險登記冊 (Risk Register)：風險登記冊是一個集中記錄所有已知風險的文件。風險評鑑的產出（如新識別的風險）必須被記錄在風險登記冊中。當風險得到解決、緩解或其級別發生變化時，也需要更新登記冊，以反映組織當前的風險狀況。
* 提供資訊流：風險管理是一個包含框架設定 (Frame)、評鑑 (Assess)、回應 (Respond) 和監控 (Monitor) 的循環過程。風險評鑑的產出在這些階段之間流動，為整個風險管理生命週期提供必要的資訊和溝通基礎。

### 1.2.5 建議風險處理方案
* 在評估風險後，必須決定如何應對。
#### 風險處理的四種主要方法
:::warning
組織有四種可接受的方式來回應已識別的風險：
1. 避免 (Avoid)：
* 定義：停止或不從事會產生風險的活動。
* 應用：這通常不是企業所樂見的選項，因為承擔風險是業務成長的必要部分。但在某些情況下，如果風險過高且無法有效緩解，停止相關活動可能是最明智的選擇。
2. 減少/緩解 (Reduce/Mitigate)：
* 定義：透過實施新的或增強的控制措施（如安全保障措施和對策），來降低風險發生的可能性 (likelihood) 或衝擊 (impact)。
* 應用：這是最常見的風險處理方法。安全架構師會建議並設計適當的控制措施，例如技術、管理或實體控制，以將風險降低到可接受的水平。
3. 轉移/共享 (Transfer/Share)：
* 定義：將部分或全部風險轉移給第三方。
* 應用：
* 常見的方式包括購買網路責任保險 (cyber liability insurance)，將財務損失的風險轉移給保險公司，或透過建立業務合作夥伴關係來分攤風險。
* 需要注意的是，即使外包了某些功能，組織仍然對資料安全負有最終責任，無法完全轉移法律責任。
* CIO提出提高免賠額度，降低保費負擔時，應該由現有風險登錄表支援的定量風險評估可提供客觀數據，為風險接受度和保險免賠額的決策提供參考。其他措施或許可以提供背景信息，但缺乏財務論證所需的嚴謹性。
4. 接受 (Accept)：
* 定義：在評估後，決定保留並承擔與風險相關的潛在損失。
* 應用：這通常是風險管理的最後一步。只有在實施了所有合理的控制措施後仍然存在的殘餘風險 (residual risk)，並且該風險水平在管理層的可接受範圍內時，才應被接受。安全架構師的職責是確保管理層（作為風險所有者）清楚了解他們所接受的風險水平。風險無知 (risk ignorance)，即假裝風險不存在，是不可接受的。
:::

#### 選擇控制措施時的關鍵考量
* 在建議緩解措施（即控制措施）時，安全架構師必須進行成本效益分析。
* 成本效益分析 (Cost-Benefit Analysis)：
* 原則：投入保護一項資產的成本不應超過該資產本身的價值。
* 目的：確保在安全上的投資是合理的，並且能夠透過降低風險來實現相應的效益。
* 挑戰：
* 總體擁有成本 (TCO)：評估控制措施的成本時，不僅要考慮初始購買成本，還必須包括準備需求、供應商會議、合約談判、實施、培訓、維護、對性能的影響以及最終的處置成本等所有費用。
* 效益量化：很難將定性風險評估的結果（如高、中、低風險等級）與控制措施的貨幣成本進行直接比較。
* 殘餘風險 (Residual Risk)：
* 定義：在實施控制措施後仍然存在的風險。
* 目標：所有風險都應透過控制或轉移來緩解，直到殘餘風險達到管理層認為可以接受的水平。
* 補償性控制 (Compensating Controls)：
* 定義：當因技術或業務限制而無法直接滿足某項要求時，可以部署的替代性控制措施。
* 應用：如果補償性控制能夠充分緩解相關風險，即使未完全遵循原始規定，組織仍可被視為合規。這為在複雜環境中實現安全目標提供了靈活性。
---

# Reference
## 參考資料
* Agile Application Lifecycle Management: Using DevOps to Drive Process Improvement, 1st Ed. by Bob Aiello, Leslie Sachs. Publisher: Addison-Wesley Professional. (Jun, 2016).
* Agile Application Security by Laura Bell, Rich Smith, Michael Brunton-Spall, Jim Bird. Publisher: O'Reilly Media, Inc. (Jun, 2017).
* Architecting Secure Software Systems, 1st Ed. by Asoke Talukder, Manish Chaitanya. Publisher: Auerbach Publications. (Sep, 2019).
* Applied Cryptography: Protocols, Algorithms and Source Code in C, 20th Anniversary Ed. by Bruce Schneier. Publisher: Wiley. (Mar, 2015).
* Beginning Database Design Solutions by Rod Stephens. Publisher: Jossey-Bass. (Nov, 2008).
* Business Continuity and Disaster Recovery Planning for IT Professionals, 2nd Ed. by Susan Snedaker. Publisher: Syngress. (Sep, 2013).
* Cloud Storage Security: A Practical Guide by Aaron Wheeler, Michael Winburn. Publisher: Elsevier. (Jul, 2015).
* Common Criteria for Information Technology Security Evaluation, Version 3.1 Rev. 5 by Mead, N. Publisher: Carnegie. (Apr, 2017).
* Data Center Handbook, 2nd Ed. by Hwaiyu Geng. Publisher: Wiley. (May, 2021).
* Disaster Recovery and Business Continuity, 3rd Ed. by B.S. Thejandra. Publisher: IT Governance Publishing. (Jan, 2014).
* Enterprise Security Architecture: A Business-Driven Approach, 1st Ed. by John Sherwood. Publisher: CRC Press. (Nov, 2015).
* Identity and Access Management: Business Performance Through Connected Intelligence, 1st Ed. by Ertem Osmanoglu. Publisher: Syngress. (Nov, 2013).
* Information Security Management Handbook, Vol. 6, 6th Ed. by Harold F. Tipton and Micki Krause Nozaki. Publisher: Auerbach Publications. (Apr, 2016).
* Information Security Management Handbook, Vol. 7, 6th Ed. by Richard O'Hanley, James Tiller. Publisher: Auerbach Publications. (Aug, 2013).
* NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems by Marianne Swanson, Pauline Bowen, Amy Wohl Phillips, Dean Gallup, David Lynes. (May, 2010).
* NIST SP 800-57, Rev. 5, Recommendation for Key Management: Part 1 – General by Elaine Barker. Publisher: NIST. (May, 2020) .
* NIST SP 800-61, Rev. 2, Computer Security Incident Handling Guide by Paul Cichonski, Tom Millar, Tim Grance, Karen Scarfone. (Aug, 2012).
* NIST SP 800-63-3, Digital Identity Guidelines: Enrollment and Identity Proofing by Paul A. Grassi, James L. Fenton, Naomi B. Lefkovitz, Jamie M. Danker, Yee-Yin Choong, Kristen K. Greene, Mary F. Theofanos. (Jun, 2017).
* NIST SP 800-115, Technical Guide to Information Security Testing and Assessment by Karen Scarfone, Murugiah Souppaya, Amanda Cody, Angela Orebaugh. (Sep, 2008).
* ]NIST SP 800-125, Guide to Security for Full Virtualization Technologies by Karen Scarfone, Murugiah Souppaya, Paul Hoffman. (Jan, 2011).
* NIST SP 800-162, Guide to Attribute Based Access Control (ABAC) Definition and Considerations by Vincent Hu, David Ferraiolo, Rick Kuhn, Adam Schnitzer, Kenneth Sandlin, Robert Miller, Karen Scarfone. (Jan, 2014).
* Official (ISC)² Guide to the ISSAP CBK, 2nd Ed. by Adam Gordon. Publisher: Auerbach Publications. (Jan, 2017).
* Payment Card Industry Data Security Standards, Requirements and Security Assessment Procedures, Version 3.2.1 by PCI Security Standards Council. Publisher:
* Security Standards Council, LLC. (May, 2018).
* Practical Internet of Things Security, 2nd Ed. by Brian Russel, Drew Van Duren. Publisher: Packt Publisher. (Nov, 2018).
* SABSA Executive Summary by SABSA. Publisher: The SABSA Institute. (Dec, 2021).
* Secure Coding in C and C++, 2nd Ed. by Robert Seacord. Publisher: Addison-Wesley Professional. (Apr, 2013).
* Security Patterns in Practice: Designing Secure Architectures Using Software Patterns by Eduardo Fernandez-Buglioni. Publisher: Wiley. (May, 2013).
* Security Guidance for Critical Areas of Focus in Cloud Computing v4.0 by Rich Mogull, James Arlen, Adrian Lane, Gunnar Peterson, Mike Rothman, David Mortman. Publisher: Cloud Security Alliance. (Jul, 2017).
## Flash Card
1. [D1 flash cards](https://www.isc2.org/certifications/issap/issap-self-study-resources/issap-flash-cards-1)
2. [D2 flash cards](https://www.isc2.org/certifications/issap/issap-self-study-resources/issap-flash-cards-2)
3. [D3 flash cards](https://www.isc2.org/certifications/issap/issap-self-study-resources/issap-flash-cards-3)
4. [D4 flash cards](https://www.isc2.org/certifications/issap/issap-self-study-resources/issap-flash-cards-4)
5. [D5 flash cards](https://www.isc2.org/certifications/issap/issap-self-study-resources/issap-flash-cards-5)
6. [D6 flash cards](https://www.isc2.org/certifications/issap/issap-self-study-resources/issap-flash-cards-6)
## Domain 1
* Acceptable Risk: A suitable level of risk commensurate with the potential benefits of the organization's operations as determined by senior management.
* Adequate Controls: Safeguards and countermeasures commensurate with the level of risk.
* Availability: Ensuring timely and reliable access to and use of information by authorized users.
* Compliance: Adherence to a mandate; both the actions demonstrating adherence and the tools, processes, and documentation that are used in adherence.
* Confidentiality: Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information.
* Control: A safeguard or countermeasure used to mitigate risk; it may be technical, managerial or physical.
* Classification: Entails analyzing the data or assets that the organization retains, determining its importance and value, and then assigning it to a category.
* Data Owner/Controller: An entity that collects or creates PII.
* Data Processor: Processes data provided to them by the data controller.
* Due Care: A legal concept pertaining to the duty owed by a provider to a customer.
* Due Diligence:Actions taken by a vendor to demonstrate or provide due care.
* Ethics: Moral principles that govern behavior.
* Firewalls: Devices that enforce administrative security policies by filtering incoming and outgoing traffic based on a set of rules.
* Forensics: The examination of evidence related to criminal activity.
* Governance: The process of how an organization is managed; usually includes all aspects of how decisions are made for that organization, such as policies, roles, and procedures the organization uses to make those decisions.
* Integrity: Guarding against improper information modification or destruction and includes ensuring information non-repudiation and authenticity.
* Least Privilege: The practice of only granting a user the minimal permissions necessary to perform their explicit job function.
* Legacy IT Systems: IT systems that have been in use for an extended time period.
* Non-repudiation: Inability to deny. In cryptography, a service that ensures the sender cannot deny a message was sent and the integrity of the message is intact, and the receiver cannot claim receiving a different message.
* Penetration Testing:The attempt to enter a system or network through an unauthorized channel.
* Policy:Documents published and promulgated by senior management dictating and describing the organization's strategic goals.
* Privacy Shield: A now-obsolete agreement between the United States and the European Union related to the transmission of EU citizens' data to the United States.
* Regulations: Rules enforced by a regulatory body or authority.
* Risk:The possibility of damage or harm and the likelihood that damage or harm will be realized.
* Risk Management: The process of identifying, evaluating and controlling threats, including all the phases of risk context (or frame), risk assessment, risk treatment, and risk monitoring.
* Risk Treatment: The determination of the best way to address an identified risk.
* Separation of Duties: The practice of ensuring that no organizational process can be completed by a single person; forces collusion to reduce insider threats.
* Shadow IT: IT services acquired and managed outside of the traditional IT department.
* Stakeholder:Any entity with a vested interest including owners, suppliers, employees and customers.
* Vulnerability Management:The process of identifying and addressing any weaknesses or gaps that could lead to a security breach.

## Domain 2
* Baseline:A documented, lowest level of security configuration allowed by a standard or organization.
* Centralized (System or Architecture):Model where all processing is performed at a central location.
* Distributed (System or Architecture):Model where processing can be done at many different connected locations.
* Gateway Device:A firewall or other device sitting at the edge of a network to regulate traffic and enforce rules.
* Service-oriented Architecture(SOA):A set of principles and methodologies for designing and developing software in the form of interoperable services. These services are well-defined business functions that are built as software components (i.e., discrete pieces of code and/or data structures) that can be reused for different purposes. (Source: NIST SP 800-53 Rev. 5).
* Threat Modeling:A process by which developers can understand security threats to a system, determine risks from those threats, and establish appropriate mitigations.
* Tightly Coupled: Software modules that are linked to one another and only operate together.
* Validate a Control:Prove that the existing control is the correct control.
* Verify a Control:Prove the existence of a control.

## Domain 3
* Asymmetric:Not identical on both sides. In cryptography, key pairs are used, one to encrypt, the other to decrypt.
* Block Mode Ciphers:A cryptographic operation that works on data arranged in blocks.
* Certificate:A formal statement of ownership of a public encryption key.
* Containers:A packaged software unit.
* Encoding:The action of changing a message into another format through the use of a code.
* Encryption:The process of converting the message from its plaintext to ciphertext.
* Hash Function:Accepts an input message of any length and generates, through a one-way operation, a fixed-length output called a message digest or hash.
* Hybrid Encryption:A cryptographic implementation that uses both symmetric and asymmetric algorithms.
* Initialization Vector (IV):A non-secret binary vector used as the initializing input algorithm, or a random starting point, for the encryption of a plaintext block sequence to increase security by introducing additional cryptographic variance and to synchronize cryptographic equipment.
* Layered Defense:The use of multiple controls arranged in series to provide several consecutive controls to protect an asset; also called defense in depth.
* Middleware: An interface between systems, often between an application and multiple underlying legacy systems.
* Perfect Forward Secrecy:Assurance that the compromise of a cryptographic key will not compromise other keys.
* Side-Channel Attacks:Attacks against a cryptographic system based on timing and power analysis; not based on attacking the content of the message.
* State:The condition an entity is in at a point in time.
* Stream-based Ciphers:A cryptographic operation that operates on a bit or character at a time.
* Trusted Path:A secure management communications channel.
* Virtual Machines:An emulation of a computing system.

## Domain 4
* Entitlement:A set of rules, defined by the resource owner, for managing access to a resource (asset, service, or entity) and for what purpose.
* Identity and Access Management (IAM):Management of Identities throughout the identity management life cycle.
* Privileged Accounts:Accounts on a system with higher levels of permissions.
* Proof of Possession:A way to verify ownership of an identity.
* Single Sign-On:The concept that there is one authentication and authorization model for a single user.

## Domanin 5
* Certification:Formal review of software to ensure that all security controls were built into the software as designed.
* Systems Authorization:Formal management acceptance of risk and approval for software to be placed into production based on certain operating conditions; also known as accreditation.

## Domain 6
* Business Continuity (BC):Actions, processes, and tools for ensuring an organization can continue critical operations during a contingency.
* Business Continuity and Disaster Recovery (BCDR):The process of jointly addressing business resiliency and restoration of critical infrastructure and functionality after a disruption.
* Business Impact Analysis (BIA):A list of the organization's assets annotated to reflect the criticality of each asset to the organization.
* Computer Security Incident:A violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices.
* Disaster Recovery:The ability to provide IT services following an interruption, often at an alternate location.