# 時間序

---

**事故回應流程 Incident Response Process / 目標：恢復應有的服務水準**
* 偵測/檢測 (Detection) : 識別的判斷真假，排定順序
* 回應/響應 (Response) : 有CSRT或CSIRT，在最短的時間要有團隊(完成)
* 緩解/抑制 (Mitigation) : 限制事件的影響範圍，先停損(Containment)後根除(Eradication)
* 報告 (Reporting) : 報告給主管了解知道，甚至到執法單位
* 恢復 (Recovery) : 有損害則恢復至原來可運作的狀態
* 修復/補救 (Remediation) : 要做根因分析
* 檢討改進/總結教訓 (Leasson Learned) : 學習本次事件避免再犯

**上課版本**
* 準備階段 (Preparation) : 建立事故回應計畫、有老闆支持、變成政策、建立IR TEAM、加強員工資安知識訓練
* 預處理 (Triage) : 判斷真假、排定順序、完成通報
* 回應 (Response) : 先停損、後根除、有損害再復原
* 事後 (Post-incident) : 尋找根因、防止再發、反省檢討、持續改善

---

**網路攻擊鏈 Cyber Kill Chain**
* 偵查 (Reconnaissance) : 攻擊者收集目標對象的資料，如電子郵件信箱、社群平台的資料，以找到可以下手的弱點；或是透過工具，掃描目標對象的網站、系統，得知使用的系統種類、版本。
* 武裝 (Weaponization) : 攻擊者使用現成的開源工具或是自行開發專屬的惡意程式。
* 遞送 (Delivery) : 攻擊者將攻擊武器送入目標的系統內，如透過釣魚信件裡的連結、夾帶木馬的盜版軟體、隨身碟。
* 漏洞利用 (Exploitation) : 確保遞送的惡意軟體，藉由目標對象的系統漏洞，得以順利開啟，並使攻擊者獲得控制權。
* 安裝 (Installation) : 攻擊者確保自身可以長期控制目標的系統內，以有足夠的時間進行後續環節。
* 發令與控制 (Command & Control) : 本環節取兩個單字的字首，又可簡稱為 C2。攻擊者潛伏在目標的系統內，收集資料，探索環境，以便審慎規劃後續行動。
* 行動 (Actions) : 根據攻擊者的最終目標，採取行動，如破壞系統、竊取機密資料、勒索目標對象。

---

**安全控制措施 (ISC)2 時間軸**
* 事前
* 指示(Directive) : 公司對資訊系統的資安政策 - 資安公告、逃生出口
* 威懾(Deterrent) : 資訊系統的警告標語(違反規則會有什麼處罰)，降低犯罪心理 - 柵欄、保安、安全攝影機
* 預防(Preventive) : 在資訊系統出事前，盡可能的避免- 職位輪調、加密、防火牆、門禁卡
* 事中
* 偵測(Detective) : 在資訊系統出事時，要即早發現- IDS、密罐、SIEM、監控系統
* 糾正(Corrective) : 發現異常，就要立即進行校正- 隔離病毒、網頁阻擋
* 事後
* 復原(Recovery) : 資訊系統出事後，若是功能完全喪失，就要進行還原- 備份還原
* 其它
* 補償(Compensating) : 若A方案不足或不好用，使用B方案補償- 盲人院的視網膜改指紋辨識

---

**NIST RMF(Risk Management Framework)**


* 準備 (Prepare) : 這個階段可能需要採取的步驟。
* 了解組織和系統需求
* 確立安全目標和要求
* 確認相關法規和標準
* 確立風險管理策略
* 確定RMF流程
* 確保組織和利害關係者參與
* 進行風險評估
* 確定資源和預算
* 訓練和培訓
* 建立RMF文件
* 分類系統 (Categorize System) : 依據BIA分析結果來盤點資料有多重要(看CIA)，取最高水位(High Water)，分類系統會取得系統影響等級(高、中、低)
* NIST SP 800-53
* 高衝擊有 449 控制措施
* 中衝擊有 365 控制措施
* 低衝擊有 230 控制措施
* 選擇控制 (Select Controls) :
* 定範圍(Scoping)：從一個控制框架中，把不適用的控制措施排除，定出初步的範圍，相當於ISO27001的適用性聲明(SOA、Statement of Applicability)
* 量身訂作(Tailoring)：量身定做、修改基準內的安全控制，不好用的調整，不夠用的新增定範圍後再根據系統及組織個別的安全需要去調整初步的控制措施
* 實施控制 (Implement Controls) : 執行安全控制措施
* 評鑑控制 (Access Control) : 評鑑(查驗Examination、訪談Interviewing、測試Testing)所實施安全控制的有效性與符合性，會產出評鑑報告
* 授權系統 (Authorize System) : 主管授權讓系統上線(系統被授權)，授權非永久授權，會定期評鑑
* 監控控制 (Monitor Contols) : 上線後監控安全控制措施

---

**滲透測試**

EC-Council's LPT


* 蒐集開源情資 (Information Gathering)
* 掃描與偵查 (Scanning and Reconnaissance) : ping , nmap
* 指紋辨識與枚舉 (Fingerprinting and Enumeration)
* 弱點評鑑 (Vulnerability Assessment) : sqlmap , Nikto , Metasploit
* 利用研究與驗證 (Exploit Research and Verification)
* 出報告 (Report)

(ISC)2
* 計畫（Plan）
* 資訊蒐集和發現（Information Gathering & Discovery）
* 弱點發現（Vulnerability Discovery ）
* 利用（Exploiting）
* 報告（Reporting）

---

**ISO 22301 BCM 上課的版本**

1. 內外部環境分析 (Internal and External Analysis)
2. 識別出利害關係人並了解利害關係人的需求 (Stakeholder Analysis)
3. 訂定範圍 (Defining the Scope)
範圍(Scope)主要是根據【組織單位】與【產品及服務】兩個面向訂出來。
範圍(Scope)的呈現 : 以清單方式來呈現
4. 業務衝擊分析 (Business Impact Analysis) : BIA就是要找出的關鍵流程(MTD)及關鍵資源(RTO)，以了解關鍵流程停擺對於業務衝擊有多大。MTD是指關鍵流程可以停多久，不是機器；因此，MTD不要說成【停機】時間，停機會讓人誤以為是指機器停機。
5. 風險評鑑 (Risk Assessment)
6. 風險處置 (Risk Treatment)
7. 計畫書測試與演練 (Testing and Exercises)

**計畫書測試與演練**
* 查核表(Checklist)：檢核表勾一勾
* 走一遍(Walkthrough)：情境模擬(Tabletop)
* 模擬(Simulation)：模擬測試 (真的到系統上操作，但是非關鍵業務)
* 平行(Parallel)：在不影響正式環境下，請⼀組⼈到異地進行部署，但沒有切換正式環境
* 全中斷(Full interruption)：實戰演練，直接中斷正式環境，到備援站點接手處理

**OSG上課的版本**


* 項目範圍和計劃編制(Project Scope and Planning)
* 業務組織分析(Business Organization Analysis)
* 選擇BCP團隊(BCP Team Selection)
* 資源相關需求(Resource Requirements)
* 法律和法規要求(Legal and Regulatory Requirement)
* 業務衝擊評估(Business Impact Assessment)
* 確認資源優先級(Identify Priorities)
* 識別風險(Identification Risk)
* 可能性評估(Likelihood Assesment)
* 影響評估(Impact Assesment)
* 資源優先級劃分(Resource Prioritization)
* 連續性計劃(Continuity Planning)
* 策略開發(Strategy Development)
* 預備和處理(Provisions and Processes)
* 批准和實現(Plan Approval and Implementation)
* 計劃批准(Plan Approval)
* 計劃實現(Plan Implementation)
* 教育和訓練(Training and Education)
* BCP文件化(BCP Documentation)

---

**資料的生命週期**

* Create
* Store
* Use
* Share
* Archive
* Destroy

---

**CMM(SW-CMM) / CMMI**

* Level 5 : Optimizing / Optimizing
* 可能會建立回饋機制，透過過往開發經驗量化後，檢討並衍生出創新的方法進行專案開發，並明確指出過往流程缺陷問題，定期改進檢討。缺陷預防、技術更改管理和過程更改管理
* Level 4 : Managed / Quantitatively Managed
* 利用統計的方法與技術來量測品質和流程績效，建立品質和流程績效的量化目標，並在整個流程中受到管理。定量處理管理和軟件質量管理
* Level 3 : Define / Define
* 軟體發展中的程序，包含開發及管理等都已經建檔並文件化、標準化、組織都能夠發展出一套標準程序並演進和修改 ，所有專案的開發或維護都必須按標準程序進行。組織處理中心、組織處理定義、培訓計劃、綜合的軟件管理、軟件產品工程、團體之間的協調和對等評審
* Level 2 : Repeatable / Managed
* 出現基本的生命週期管理過程，可以開始建立基本專案流程，也可依據之前成功經驗與程序來複製類似應用。需求管理、軟件項目計劃編制、軟件項目跟蹤和監督、軟件轉包合同管理、軟件質量保證和軟件配置管理。
* Level 1 : Initial / Initial
* 這個階段幾乎或完全沒有定義軟體開發過程，都是靠組織成員的能力完成，並非使用一套正式且經過驗證的開發流程。

---

**Wuson SDLC**
* 規劃 (Planning)
* 分析 (Analysis)
* 設計 (Design)
* 發展 (Development)
* 測試 (Testing)
* 交付 (Delivery)
* 維護 (Maintenance)

**System Development Life Cycle**

* 起始(Initial)：開始要先評估與分類等級級別
* 購買/開發(Acquisition/Development)：可以選擇要自建還是購買
* 實施/評鑑(Implement/Assessment)：(此階段包含C&A) 上線前要取得同意與測試
* 運維和維護(Operations and Maintenance)：要有Change Management的管理
* 除役(Disposal)：要注重資料殘餘的議題

**Software Development Life Cycle**

* 需求收集：確認開發軟體的原因及方法模型，執行、操作及其開發軟體的人員
* 設計(架構)：處理軟體如何實現所制訂的目標，這些目標被包裝到功能設計中
* 開發：編成軟體代碼，以滿足設計階段規定的規範
* 測試 / 驗證：驗證軟體以確保達到目標並且軟體按計畫進行
* 發佈 / 維護：部署軟體，然後確保正確配置，修補和監控軟體

---

**e-Discovery**


* 信息治理 (Information Governance)：確保有資訊系統有**妥善的資料處理流程**
* 識別 (Identification)：當有需求被要求提供時,能指出信息發現的位置
* 保存 (Preservation)：確保發現的信息不能被更改或刪除
* 收集 (Collection)：用於E-Discovery的過程
* 處理 (Processing)：過濾收集訊息,進行初步修剪Cut through,減少資訊量的檢查
* 檢視 (Review)：剩下的訊息檢查那些是移除敏感需要保護的資訊
* 分析 (Analysis)：針對留下的內容與文檔再深層的檢測
* 產生 (Production)：需提交信息產出的標準化格式
* 呈現 (Presentation)：向證人與法院和其他當事者演示信息

---

**費根檢查**


* 規劃 / 计划(planning)
* 概述(overview)
* 准备(preparation)
* 審查，检查(Meeting, Inspection)
* 返工(rework)
* 追查 / 后续(follow-up，Re-inspection)

---

**NIST 800-137A ISCM(資訊系統緊急應變管理)**


* 定義(Define)：ISCM的戰略Strategy
* 建立(Establish)：建立ISCM的計劃(Program)
* 實施(Implement)：執行實施ISCM的計劃(Program)
* 分析和報告(Analyze and Report)：報告和分析結果
* 回應/響應(Response)：針對結果進行響應
* 審查和更新(Review and Update)：對ISCM進行審查與更新

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-137A.pdf

---

**NIST BCM 營運持續管理相關計畫書**
* T1 組織使命願景，與人員安全，Organization (Strategic planning) 策略規劃
* Crisis Communication Plan (CCP) 危機溝通計畫
* Occupant Emergency Plan (OEP) ⼈員緊急計畫
* T2 產品服務，持續交付，Business Processes (Continuity planning) 持續性計畫
* Continuity of Operations Plan (COOP) 維運持續計畫
* Business Continuity Plan (BCP) 業務持續計畫
* T3 CIA 資訊安全
* Disaster Recovery Plan (DRP) 災難復原計畫
* Information System Contingency Plan (ISCP) 資訊系統應急計畫
* Critical Infrastructure Protection (CIP) Plan 關鍵基礎設施保護計畫
* Cyber Incident Response Plan (CIRP) 資安事故回應計畫

---

**變更管理流程 OSG 第16章**

* 請求變更 (Request the change) : 一旦識別出所需的變更，員工便會請求變更。組織內可能會提供網站供員工申請提交，並追蹤執行情況。
* 審核變更 (Review the change) : 組織內的專家會審核，審核的人員會來自組織內幾個不同的領域，也可能需要提交變更審核委員會批准。
* 批准/拒絕變更 (Approve/reject the change) : 依據審核結果，這些專家會批准或拒絕變更。
* 測試變更 (Test the change) : 一旦批准更改，需要對變更進行測試，並安排在非正式環境避免造成損害。
* 安排並實施變更 (Schedule and implement the change) : 按部就班實施變更，可能會安排在離峰時段進行，以避免對系統或用戶造成過多的影響。
* 記錄變更 (Document the change) : 記錄變更主要是確保所有相關人員知道變更，會需要修改配置管理文件。

---

**補丁管理步驟 OSG 第16章**

* 評估補丁 (Evaluate patches) : 補丁發佈時管理員要評估適不適用。
* 測試補丁 (Test patches) : 要在非正式環境上測試，並確認是否有其它副作用，最糟的情況就是安裝後無法再正常啟動，或是不斷循環重開機。
* 審批補丁 (Approve the patches) : 測試完確定是安全可用，接下來就是批准補丁的部置。
* 部署補丁 (Deploy the patches) : 經過測試與審批，管理員就可以動手執行，可採自動或手動方式進行(通常自動比較好，但仍要看情況)。
* 驗證補丁已完成部署 (Verify that patches are deployed) : 部署完成後會定期測試系統及審計它，確保系統已保持更新狀態。

***確認是否適用 > 不會有副作用 > 批准後才能執行 > 持續監控***

---

**物理安全控制机制**

* 阻止 Deter
* 拒絕 Deny
* 檢測 Detect
* 延遲 Delay
* 確定 Determine
* 決定 Decide

---

**Ｖ模型**


* 瀑布模型的擴展，有助於在開發過程的早期階段確定測試規劃和設計的需求
* 它是貫穿 SDLC（軟件開發生命週期）的**持續測試**
* 左臂對應**瀑布模型**
* 右臂對應於**測試階段**
* 每個驗證活動都有其驗證活動
* V模型的主要目的是在**交付之前滿足業務需求並提供信心**

---

# 非時間序

**個資處理原則** (非時間序)

* 告知⽬的
* 取得同意
* 蒐集最⼩化
* 開放修改、允許刪除(被遺忘權)
* 善盡保護原則(做好資安)
* 出事要告知、出事要負責

---

**(ISC)2道德準則** (非時間序)

* (國家社會) 保護社會、共同利益、必要的公眾信任和信⼼以及基礎設施。
* (個人道德) 以光榮、誠實、公正、負責任和合法的⽅式⾏事。
* (為雇主) 為原則提供勤奮和稱職的服務。(為你的雇主提供專業)
* (為產業) 推進和保護職業。(促進並保護資安專業)

---

**通用標準 EAL 7 個等級**

* EAL1 : 經過**功能**測試
* EAL2 : 經過**結構**測試
* EAL3 : 有條不紊地進行**測試和檢查**
* EAL4 : 系統地設計，測試和審查
* EAL5 : 半正式設計和測試
* EAL6 : 半正式驗證，設計和測試
* EAL7 : **正式驗證**，設計和測試

---

**威脅建模**

方法有很多種，例如 PASTA / Attack Trees / VAST / OCTAVE 等，老師上課教的是微軟的方法，且把 Threat Modeling 視為軟體工程的風險管理。
1. 風險識別 : 看圖找威脅，尤其是資料流程圖(DFD)，找到的威脅要根據 STRIDE 來進行分類
1. 風險分析 : 根據 DREAD 來計算每個威脅的風險分數
1. 風險評估 : 這點沒有特別強調
1. 風險處置 : 針對威脅提出處置方式，評估殘餘風險及文件化

STRIDE，目前最普及 Threat Modeling 手法，也是 Microsoft SDL 預設 STRIDE Risk Modeling 工具。
* 偽冒(Spoofing) : 冒充身份的威脅(如人或物)。
* 篡改(Tampering) : 篡改數據的威脅。
* 抵賴否認(Repudiation) : 被忽略的威脅。
* 資訊外洩(Information Disclosure) : 資訊外洩威脅。
* 阻斷服務(Denial of Service) : 消耗資源、服務不可以用。
* 提權(Elevation of Privileges) : 未經授權獲取或提升許可權。

DREAD，風險評鑑模型Risk Assessment Model:用於風險分析計算機安全威脅的系統部份

* 傷害性(Damage) : 若遭受攻擊的情況有多糟糕?
* 重現性(Reproducibility) : 如何重現這攻擊情境
* 可利用性(Exploitability) : 發起這攻擊需要哪些條件?
* 受影響的用戶(Affected Users) : 若攻擊有多少人被影響?
* 可發現性(Discoverability) : 若發現這威脅的難易度為何?

---

**受信賴恢復**


---

**覆蓋率測試**

* Statement coverage : 語句覆蓋率測試可驗證在測試過程中是否**執行了每一行代碼**。
* Branch coverage : 分支覆蓋率測試可驗證了所有語句是否在**所有if and else條件**下執行。
* Condition coverage : 條件覆蓋率測試驗證代碼中的**每個邏輯測試**是否在所有輸入集下執行。
* Function coverage : 功能覆蓋率測試驗證代碼中的**每個功能**均已調用並返回結果。