# 資通安全概論 Day1

## 前言
* 第一天 > 208 ， 第二天 > 204
* ISO 27001/27005

## [Unit 1] 資通安全基本觀念

### <kbd>P1-11</kbd> 每年各位都在做資安演練等
* 台積電
* (社會/新聞報導)資安事件
* [伊朗離心機](https://indsr.org.tw/respublicationcon?uid=12&resid=733&pid=3017)
* 有關NVIDIA H20 GPU被中國控訴相關([報導1](https://www.bbc.com/zhongwen/articles/cglne94k69po/trad) / [報導2](https://www.reuters.com/world/china/china-cautions-tech-firms-over-nvidia-h20-ai-chip-purchases-sources-say-2025-08-12/))

### <kbd>P1-13</kbd> 資通安全目標
* CIA資安三要素 > 分析威脅對資訊CIA損害/產生風險
* C = 機密性 = Confidentiality
* 非授權人員不可存取 >>> 資訊**秘密**性
* I = 完整性 = Integrity
* 防止資料遭竄改 >>> 資訊**正確**性
* A = 可用性 = Avaliability
* 防止系統故障 or 遭(惡意)阻斷 >>> 資訊處理**可獲得**性
* 法規遵循
* **政府機關**需要做到該目標
* 「國家機密保護法施行細則」[28-4](https://mojlaw.moj.gov.tw/LawContentExtent.aspx?lsid=FL026648&LawNo=28)
### <kbd>P1-14</kbd> CIA不同技術與方法
* 建議在分析問題或方案時，可以先將問題歸類，後續會比較容易找到應對方法
* 存取控制(e.g.帳號密碼等)
* 機密性保護，可採用加密技術(DES/AES/RC)

### <kbd>P1-15</kbd> 風險管理關係圖
* 搭配 <kbd>P1-46</kbd> 的圖表參考
* 要在「最低成本」下達成「最高成效」

### <kbd>P1-16</kbd> NIST框架
* Wikipedia[說明](https://zh.wikipedia.org/zh-tw/NIST%E7%B6%B2%E7%B5%A1%E5%AE%89%E5%85%A8%E6%A1%86%E6%9E%B6)
* 包含核心、執行層級及組態
* 框架核心可再分為五大功能面向：
* 辨識
* 保護
* 偵測
* 應變
* 復原

## [Unit 2] 資通安全相關法規
* 目前有相關考試
### <kbd>P1-19</kbd> 國家資安會報
* 行政院特別設置
* 資安署 > 資安法規專區 > [資通安全管理法](https://moda.gov.tw/ACS/laws/regulations/624)
* 組織架構圖有誤，[正確版如下](https://moda.gov.tw/ACS/nicst/organization/662)
* 資通安全長 > 資安會報召集人 > 行政院副院長
* 分為「網路防護體系(數發部資安署)」及「網路犯罪偵防體系(內政部/法務部)」
### <kbd>P1-20 ~ P1-25</kbd> 資通安全管理法(資安法)
* 關鍵基礎設施(CI)：指實體/虛擬財產/網路/功能停止或效能降低，對國家安全/社會公眾利益/國民生活/經濟活動有重大影響，經主管機關定期檢視後認定者
* 資通安全事件：只要在網路發生，在政府機關內受到影響者，幾乎算是。
* 章節條文可以參考(主要列出範圍及規則)
* CI特定非公務機關者(如：台電/中油等)也適用
### 資通安全管理法 > 相關子法：
* <kbd>P1-26</kbd> 施行細則
* <kbd>P1-27 ~ P1-28</kbd> 資通安全責任等級分級辦法
* 分ABCDE級 (新北衛生局=B)
* 行政院/直轄市等機關「每兩年」核定
* 會提出應辦理事項
* <kbd>P1-28 ~ P1-29</kbd> 資通安全事件通報及應變辦法
* 分1234級(依**影響性質**及**業務受影響程度**決定)
* <kbd>P1-30 ~ P1-32</kbd> 應變流程
* 差在公務機關提報給「上級或監督機關」。公營、財團法人或CI提供單位提報給「中央目的主管機關」
### <kbd>P1-35 ~ P1-36</kbd> 國家機密保護法
* 分為**絕對機密**、**極機密**、**機密**三級
* 核定原則：**最小範圍**、
* 報密期限：原核定起算**絕對機密30年**(本來是永久)、**極機密20年**、**機密10年**
### <kbd>P1-37</kbd> 個人資料保護法
* 規範個人資料「收集」「處理」及「利用」
* 個資(自然人)資料包含：**屬性資料**、**行為資料**及其他可間接/直接取得的**可識別**該個人資料
### <kbd>P1-39 ~ P1-42</kbd> 資訊安全管理系統 = ISMS
* 現在施行的ISO 27001:2022分為「4個關鍵領域」和「93項控制措施」
* 通過 ISO 27001 = CNS 27001 標準檢驗並取得證書
* ISMS建置流程與ISO 27001建置流程一樣
* [4.2.1 ~ 4.2.4](https://cclib.ctcn.edu.tw/html/Data/%E6%95%99%E8%82%B2%E8%A8%93%E7%B7%B4/1031%E6%A0%A1%E5%85%A7%E8%B3%87%E5%AE%89%E6%95%99%E8%82%B2%E8%A8%93%E7%B7%B4-1031124_2.pdf)
### <kbd>P1-39 ~ P1-42</kbd> FAQ
1.
2. 不包含
3.
4. 是
5. 通常為副首長，也可以指派
6. 很多(可以參考前面內容)

## [Unit 3] 資通安全相關法規
### <kbd>P1-46</kbd> 風險定義及目標
* 圖表可往前找<KBD>P1-15</KBD>參考
* 要在「最低成本」下達成「最高成效」
* 在最低的防護成本投入下，獲得最佳化(最合適的)安全性
* 風險透過「衝擊」與其「可能性」來定義**影響/損害程度**
### <kbd>P1-47</kbd> 風險管理流程
* CNS 27005流程
* 政府資安人員應了解風險評鑑的技術，用來評鑑資通系統的風險，以採取適當的防護措施，降低資安風險
* 全景建立：(後面會解釋)
* 風險評鑑：識別資訊資產、威脅、弱點、衝擊、可能性、已部屬的控制措施
#### 全景建立
* <kbd>P1-48 ~ P1-51</kbd> 全景建立
* 建立相關法規
* 界定風險評鑑範圍
* 識別內/外部安全需求
* 外部：文化、趨勢、國家或區域局勢(如：美國對等關稅)
* 規劃風險管理基本準則
* 若使用「詳細風險評鑑」者，需清點資通系統的所有資訊及資產，同時整合系統、設備、所有涉及人員及單位。
* <kbd>P1-52</kbd> 風險管理做法
1. 先進行**高階風險分析**
* 有關分類高/中/普級，可參考資通安全責任等級分級辦法[附表9](https://law.moj.gov.tw/LawClass/LawGetFile.ashx?FileId=0000254363&lan=C)
2. 將**高安全等級系統**執行詳細風險評鑑
* 有關各等級的防護基準，可參考資通安全責任等級分級辦法[附表10](https://law.moj.gov.tw/LawClass/LawGetFile.ashx?FileId=0000298115&lan=C)
* <kbd>P1-53 ~ P1-55</kbd> 風險評估準則
* <kbd>P1-56</kbd> 衝擊準則
* 破壞資訊或資通系統CIA對組織衝擊的**嚴重性**
* 風險計算方式：
> 風險值 = 資產價值 X 威脅發生可能性 X 脆弱性利用難易度
> 普級：1 ~ 6，中級：7 ~ 12，高級：13 ~ 27
* <kbd>P1-57 ~　P1-59</kbd> 風險接受準則
* 與**人員生命相關**之衝擊產生的風險**一律不接受**
* 以一級行政機關來說：「機密性」 > 「可用性」及「完整性」
* <kbd>P1-60</kbd> 風險管理範疇與邊界
* 要排除風險管理範疇外者，應敘明理由
* <kbd>P1-61 ~ P1-63</kbd> 風險評鑑組織
* 避免單一人員做所有事情 > 結果過於主觀會不符合真實狀況
* 建議成立「跨部門」組織
#### 風險評鑑
* <kbd>P1-65 ~ P1-66</kbd> 高階風險評鑑作法
* 資通系統安全等級去4大影響構面**最高**者
* <kbd>P1-67</kbd> 詳細做法
* 實際作業時，風險識別最後的「後果識別」和風險分析階段「後果評鑒」通常會**同時進行**
* 風險評估完可接受等級後，會進行「風險處理」及「風險監視與審查」
#### 風險處理
* <kbd>P1-69</kbd> 處理階段
* 處理活動選項：有四種
* 風險修改(降低)
* 風險保留(接受)
* 風險避免
* 風險分擔(轉移)
* 處理完後剩餘的為「殘餘風險」，會評斷處理是否合意(風險決策點2)
* <kbd>P1-70</kbd> 風險修改(降低)
* 可參考資通安全責任等級分級辦法[附表10](https://law.moj.gov.tw/LawClass/LawGetFile.ashx?FileId=0000298115&lan=C)
* 另參考[安全控制措施參考指引](https://www.nics.nat.gov.tw/cybersecurity_resources/reference_guide/Common_Standards/)內的「安全控制措施詳細說明」
* <kbd>P1-71</kbd> 風險保留(接受)
* 要有決策過程(如：機房因不可抗力因素決定保留其風險)
* 其他三者都無法處理時，或是「人力」或「成本」考量後，才能決定保留其風險
* <kbd>P1-72</kbd> 風險避免
* 對其風險「不涉入」或是「撤退行動」的決策
* 避免造成特定風險增加的活動或情形
* 社交工程，除了進行演練外，
* <kbd>P1-73</kbd> 風險分擔(轉移)
* 通常方式有「硬體資產上購買保險」或是「合約中訂定惩罰性違約金條款」

### 業務持續運作管理
* <kbd>P1-74 ~ P1-77</kbd> 業務持續運作
* 確保「重要核心業務」不受重大故障或災難的影響
* 重點在「核心業務」的持續運作(中斷的極限等)
* 將風險降到「可接受的等級」
* 制定與實施「應變計劃」
* 選用「控制措施」降低風險
* 管理程序包含下列7步驟：
*
* 管理流程必須獲得**高階管理人員**的認同與支持
* 避免變成「有作有交代」就可以的計劃 > 無用/無效計劃文件
* 必須要有核心業務所有相關部門的投入
* <kbd>P1-78</kbd> 建議業務持續運作策略
* 定義範圍：BCP需處理的災害(天災人禍)
* <kbd>P1-79</kbd> 營運衝擊分析
* = Bussiness Impact Analysis (BIA)
* 了解當災害發生後的**嚴重程度**，以及需要**多少時間**來處理
* <kbd>P1-80 ~ P1-85</kbd> 防禦性控制措施
* 可防禦災害 > 避免損害
* 不可防禦災害 > 降低災害
* 評估核心業務最大容許停機時間(Maximum Tolerable Downtime = MTD)
* 仰賴資源中大多項目影響度到「高」者，MTD為該時間
* 核心業務與其每一項資源去評估面臨的威脅與弱點
* 評估復原目標時間(Recovery Time Objective = RTO)
* 後續計算出「仰賴資源風險」與「核心業務功能風險」
*
* <kbd>P1-86</kbd> 確認業務功能與資源復原的「先後順序」
* 必須是基礎建設完成後，再建立其軟硬體
* <kbd>P1-87 ~ P1-90</kbd> 發展復原策略
* 目的是**指導**復原作業的**規劃方式與規模(成本)**
* 參考其核心業務的**最大**容許中斷時間
* 備援設施場所分為：
* Hot Site (熱備援)
* 使用案例：國防業務
* Warm Site (溫備援)
* Cold Site (冷備援)
* 資料復原方式
* 線上備份：服務同時也做資料備份
* 離線備份：中斷服務時進行備份
* 異地備份：定時將備份資料送至其他場所
* 異地備援：復原速度最快，(規定)應離開30公里
* <kbd>P1-91 ~ P1-94</kbd> 發展營運持續計劃
* **BCP時程要記**
* 復原階段主要就是要讓核心系統回覆到「暫時可運作」的狀態，且應於**容許中斷時程內**完成
* <kbd>P1-95 ~ P1-97</kbd> 測試與演練
* 檢驗BCP的**可行性**，並補強為考量之缺陷
* 確保於**容許中斷時程內**完成復原作業
* 讓相關人員熟悉相關災害復原工作
* 測試方式分以下兩種：
* 「並行測試」：將系統及業務搬移至「備援場所」測試，可能導致部分業務無法運作
* 「完全中斷測試」：中斷原場所，進行實際模擬BCP復原與重建測試
* <kbd>P1-98 ~ P1-99</kbd> 維護營運持續計劃
* 判斷BCP正確且有效：
* 在可容許中斷時間內復原完成
* 備份資料可成功回存
* 人員在可接受時間內到達
* 人原了解BCP內容，可執行其職責
* BCP與現況需求符合
* <kbd>P1-101</kbd> FAQ(小組討論)

## [Unit 4] 作業安全
### 資通系統日常維運工作
* <kbd>P1-105 ~ P1-106</kbd> 維運工作類型
* 日常營運期間會因各種原因理由而改變(例如：軟硬體安裝/變更/更新/修補、組態更新等)
* <kbd>P1-107</kbd> 軟硬體的維護
* 硬體維護
* 定期維護
* 準備相關零組件
* 設備/伺服器/
* 軟體安裝
* 確保**沒有惡意軟體**
* 符合機關政策及**合法授權**
* 軟硬體資產應造冊管理，安裝移除及異動時應被記錄
* DMZ
### 組態管理
* <kbd>P1-109 ~ P1-110</kbd> 組態管理
* 組態項目(Configuration Item = CI)
* 組態管理資料庫(Configuration Management Database = CMDB)
* <kbd>P1-111 ~ P1-112</kbd> 組態變更管理
* 有變更任何系統組態現況的動作都可以稱為「變更」
* 變更CMDB反應變更後的組態現況，以避免其他IT管理服務參考到過去資訊造成錯誤
* 安全組態影響之前應進行風險分析(例如AD網域帳號的密碼規則中，長度從10碼縮短成8碼，可能提高猜測成功率)
* <kbd>P1-113</kbd> 政府組態基準(GCB)導入
* [資安院內容](https://www.nics.nat.gov.tw/core_business/cybersecurity_defense/GCB/)
* Goverment Configuration Baseline = GCB
* 雖看似簡單，卻是一直以來很多政府機關問題的根源
* <kbd>P1-114</kbd> GCB類別及項目
* [資安署部署資源項目](https://www.nics.nat.gov.tw/core_business/cybersecurity_defense/GCB/GCB_Deployment_Resources/)
* 針對各種OS，應用程式等的組態內容
* GCB類別分為：
1. 網通設備
* 交換器
* 防火牆
* 路由器
2. 作業系統
* Microsoft Windows Series(Ｗin11/10/Server2022等)
* Linux 各發行版 (RedHat/Debian/Ubuntu等)
4. 應用程式
* MS所有程式
* 各類SQL Server(MS SQL/OracleDB/MySQL/PosgreSQL/MongoDB等)
* 各類Web Server(MS IIS/Apache/Apache Tomcat/Nginx等)
6. 瀏覽器(Browser)
* IE
* Chromium系列(Chrome/Edge等)
* Firefox
* <kbd>P1-115</kbd> 不當之案例
* <kbd>P1-116 ~ P1-118</kbd> 資通安全弱點通報系統
* Vulnerability Analysis and Notice System = VANS
* [資安院說明](https://www.nics.nat.gov.tw/core_business/cybersecurity_defense/VANS/)
* 掌握資訊資產是否有弱點
* 要做資產盤點、依登入的設備進行弱點比對
* 涵蓋範圍
### 監控與問題管理
* <kbd>P1-120 ~ P1-121</kbd> 異常監控
* 監控包含以下類型
* 可用性監控：系統故障或異常時可立刻發出警訊
* 完整性監測：是否有被非授權更動
* 入侵偵測監控：是否有非授權登入
* 異常管理流程： <span style="color:red;font-weight:bold">(注意)</span>
* 異常的警告與通報：應有明確通報程序，以確保負責管理人員可接收到。
* 異常處理與回報：
* 問題管理流程： <span style="color:red;font-weight:bold">(注意)</span>
* <kbd>P1-122</kbd> 問題管理
* 分析解決異常事件的**根本原因**，降低因異常事件對資通系統的負面影響。
* <kbd>P1-123 ~ P1-124</kbd> 弱點掃描
* 社交工程演練
* 實體弱點
* 弱掃報告
* 依弱點「暴露情形」，「揭露後的損害程度」及「所在資產的重要程度」排定修補優先順序
* 和殘餘風險一樣，要做弱掃修補
* 方式有「安裝修補程式(消除)」「調整設定(消除)」「關閉服務(避免)」「強化防禦降低弱點暴露率」
* 可能無法採修補方法，除了接受風險外溢可考量補充性做法實施(例如安裝WAF等)
* <kbd>P1-125 ~ P1-126</kbd> 滲透測試
* 目的：模擬駭客手法，檢測安全防護機制被突破的可能性
* 類型：「人員實體測試」(社交工程攻擊)及「系統網站測試」(被動：封包監聽，主動：通行碼猜測，弱點掃描，權限跳脫或異常輸入)
* 弱點修補：被揭露之弱點應依照風險高低順序規劃修補方式與期限
* <kbd>P1-127 ~ P1-128</kbd> 稽核作業
* 系統稽核紀錄包含：
* 所有存取行爲紀錄
* 安全相關紀錄
* 異常/除錯/錯誤訊息
* 舉例：Windows的Eventlog(事件檢視器)
* 紀錄分析：應定期執行，運用**自動化統計分析**或**關聯分析**
* 保存期限：應符合相關法規及政策要求
* 保護方式：
* 規劃足夠儲存空間
* 防止非授權存取與變動(例如：[近期台積電事件](https://www.cna.com.tw/news/afe/202508100155.aspx))
* 時間同步(重設時都應該檢查時區是否有誤)
* 避免系統管理者可修改稽核紀錄(可以即時匯出至稽核紀錄伺服器)
### 防範社交工程攻擊
* <kbd>P1-129 ~ P1-135</kbd> 社交工程
* 利用人性弱點、應用簡單的溝通或欺騙伎倆、進行其非法存取與破壞行為
* 重大事件或新聞
* 日常活動
* 線上理財投資
* 帳單管理
* 購物網站
* 攻擊類型：
* 電子郵件隱藏惡意程式
* 網路釣魚：偽裝電子郵件通知需重新輸入密碼等資訊
* 電信詐騙
* 偽裝修補程式
* Wifi免費熱點：偽裝成公共或免費Wifi熱點
* 即時通訊：發送詐騙訊息，吸引民眾點選釣魚網站
* 防範觀念：
* 隨時提高警覺，應保持小心求證的戒心：不未經確認就提供資料、不開來路不明信件、不開啟未經確認的連結、不下載非法軟體或檔案
* 資訊釋出時要確認身份及經過授權
* 遇到疑似狀況或事件，通報給有關單位