---
# System prepended metadata

title: 資通安全概論 Day3

---

# 資通安全概論 Day3

## 第二天回顧
* 資訊委外
* 履約管理
    * 紅字要記
* 識別符三要素
* FRR/FAR > CER
* TOKEN
* OTP(同步/非同步)
* 加解密技術
    * 算法須公開
    * 非對稱 > 公私鑰
    * RSA / ECC(橢圓曲線密碼編譯) / ElGamal
    * 數位信封 
* 數位簽章

## [Unit 7] 網路安全與實體安全
### 網路安全防禦技術(續)
#### <kbd>P2-92 ~ P2-94</kbd> 網站應用程式防火牆(WAF)
* = Web Application Firewall
* 用途：偵測與防禦針對網站應用程式之攻擊行為
    * 例如XSS(跨站腳本攻擊Cross-Site Scripting)或SQL注入(SQL injection)
* 應用類型分為**硬體式**與**軟體式**
    * 硬體式(單一主機)：執行速度快
    * 軟體式(安裝在一台主機上)：
* 都可以處理HTTPS加解密動作
* 重點：異常網站應用程式被攻擊事件應立即匯出、保留足夠時間、定期分析、並定期處理
* 選購考量：
    * 處理效能要符合機關流量需求
    * 中文URL/傳輸內容的判斷能力
    * HTTPS加密連線可先在WAF過濾後，再應用到後端網站上
    * IDS/IPS無法判斷HTTPS連線

#### <kbd>P2-95 ~ P2-97</kbd> 入侵偵測與防禦系統(IDS/IPS)
* 入侵偵測系統 = IDS
* (入侵)防禦系統 = IPS
* 識別網路異常/攻擊行為，特定攻擊可立即阻擋
* SSL加密連線內容無法識別
* 技術類型
    * 特徵碼比對：比對**攻擊特徵碼**，判斷較精準，但只能偵測已知攻擊
    * 異常行為模式分析：較**分析比對**出異常行為，可偵測未知攻擊，但容易誤判
    * 狀態協定分析：事先**定義**完整協定內容，較為精準且可偵測未知攻擊，但耗費運算資源
* 選購考量
    * 針對DoS/DDoS(阻斷/分散式阻斷服務)攻擊能分辨合法/異常封包差異
    * 產生報表、即時訊息，中央控管，以及對IM/P2P管理

#### <kbd>P2-98 ~ P2-100</kbd> 虛擬私有網路(VPN)
* = Virtual Private Network
* 在公開網路上建立私有通道(tunnel)
* 保護通訊資料機密/完整性
* VPN類型
    * 遠端(使用者)存取VPN：適用外勤人員從外網連接內部網路
        * IPSec VPN
        * SSL VPN
    * Side-to-Side VPN：站點對站點連線，例如機關與各分駐站點
    * Extranet VPN
* 選購考量
    * 本身應具備防火牆功能
    * 建議有獨特規格
 
#### <kbd>P2-101 ~ P2-102</kbd> 防毒系統
* 防止病毒、蠕蟲、間諜、後門、及木馬等惡意程式入侵
* 來源：
    * email
    * 隨身碟：`autorun.inf`
    * 瀏覽網站：JavaScript惡意程式碼
    * 即時通訊
    * 檔案傳輸分享
* 部署方式：PC及Server防毒、email/網路防毒閘道
    * 例如：Windows Defender等
    * 上網防毒至少應支援SMTP/POP/HTTP(S)和FTP等協定
* 重點：
    * 應定期更新病毒碼
    * 應定期分析
    * 未安裝防毒軟體的電腦應避免聯網
    * 防火牆控管未經防毒閘道過濾的連線行為
    * 「PC/Server防毒」和「防毒閘道」兩系統可採用不同品牌
* 選購考量
    * 病毒偵測精準度
    * 效能影響
    * 是否提供中央控管
  
#### <kbd>P2-103 ~ P2-105</kbd> 垃圾郵件過濾系統
* 過濾垃圾廣告郵件，避免社交工程攻擊
* 判斷技術
   * 連線模式(黑名單/傳送政府框架=SPF)
   * 關鍵字比對
   * 內容過濾
   * 外部資料庫比對
   * 貝氏演算
   * 圖像辨識
* 部署方式
   * 閘道模式
       * 在mail server的就在mail server
   * Bridge模式
       * 單點故障就會ByPass掉流量
* 重點
    * 定期自動更新辨識特徵碼
    * email過濾規則變更應建立管理程序(申請/核准/紀錄)
* 選購重點
    * 垃圾郵件判斷精準度
 
#### <kbd>P2-106</kbd> 端點偵測及回應系統(EDR)
* = Endpoint Detection and Response
* 端點指的是使用者終端(Client)
* 偵測與阻擋威脅，確保設備安全
* 也有XDR(Extended Detection and Response)

### <kbd>P2-107 ~ P2-115</kbd> 網路區域規劃
* 外部網路
    * 廣域網路(WAN)
* 內部網路(Intranet)
    * != 區域網路(LAN)
    * 外網無法直接連入內網
        * 可以架設代理伺服器
* 非軍事區(DMZ)
    * = Demilitarized Zone
    * FTP Server(Port:21/22等)
    * 網頁Server(Port:80/443等)
    * 只開特定服務/TCP Port
    * 需嚴密控管此區域到內網的存取
* 網路管理區域
    * 放置機關網路管理區域(網管系統/認證系統/監控系統)
    * 應明確標示網路路徑及維運方式
        * 每個switch上面的link都應標示清楚連線至何處

### <kbd>P2-116 ~ P2-119</kbd> 網路連建安全
* `RC4`已經被破解 > 中間人攻擊
* `TLS1.0`已不再安全
* 明文傳輸
    * Telnet / HTTP / FTP
    * 可能被監聽
    * FTP漏洞 > [RFC 2577](https://zh.wikipedia.org/zh-tw/%E6%96%87%E4%BB%B6%E4%BC%A0%E8%BE%93%E5%8D%8F%E8%AE%AE#%E5%AE%89%E5%85%A8%E6%80%A7)
* 加密網路傳輸
    * ~~HTTP~~ > HTTPS
    * ~~Telnet~~ > SSH
    * ~~FTP~~ > FTPS 
    * 可防止遭到竊聽/竄改訊息
* 可以用 `netstat` 確認電腦內已開啟網路服務 
```bash=
$ netstat  # Windows

使用中連線
  協定   本機位址                外部位址                  狀態
  TCP    127.0.0.1:1565         view-localhost:1566      ESTABLISHED
  TCP    127.0.0.1:1566         view-localhost:1565      ESTABLISHED
  TCP    140.OOO.XXX.92:1729    172.QQQ.2.3:https        ESTABLISHED
  TCP    140.OOO.XXX.92:2711    a865a9e11bc2c0d65:https  ESTABLISHED
  ...
  TCP    140.OOO.XXX.92:3903    lctsaa-ab-in-f3:https    TIME_WAIT
  ...
  TCP    140.OOO.XXX.92:3928    123:http                 TIME_WAIT
  
```

### <kbd>P2-120 ~ P2-129</kbd> 雲端運算安全
* 雲端運算特性
    * 隨選自助
    * 廣泛網路存取
    * 資源匯聚
    * 快速靈活性
    * 受量測服務
        * 所有服務都會被記錄下來
    * 多租用
        * 一個datacenter有多台server，一個server可分割給很多人使用(亦可一人專用)
* 舉例：[AWS](https://www.youtube.com/watch?v=q6WlzHLxNKI)、GCP等
* 分為以下兩種
    * 雲端技術：利用虛擬化/自動化/標準化來運用分配各種運算資源(CPU/RAM/Storage等)
    * 雲端服務：透過網路提供各種服務(email/cloud storage/calender/message等)
* 可參考[CNS 17788](https://www.bsigroup.com/zh-TW/about-bsi/media-centre/press-release/2015/may/ISO_IEC_17788_cloud_computing/) 
* 服務模式
    * 基礎設施 > IaaS
    * 平台 > PaaS
    * 軟體 > SaaS
* 部署模型
    * 公用雲(公有雲)
    * 私用雲(私有雲)
    * 社群雲
    * 混合雲
* 資安責任 > 責任分擔制
    * 政府機關考量三重點 = GRC (政府/風險/法規遵循)
* 資安問題
    * 用戶端
        * 是否遭到駭客或雲端業者竊取
        * 資料是否能存取
        * 傳輸時是否被擷取
    * 供應商端
    * 案例：[2019年7月 - HONDA](https://www.ithome.com.tw/news/132162)
* 服務協定：
    * 應簽訂**契約**及**服務水準協議**(Service Level Agreement = SLA) 
    * 可參考[CNS 19086](https://www.find.org.tw/tech_obser/browse/6835c1fe18e468e5780b74b262fd7c0b)
* 實作練習
    * [DVWA](https://github.com/digininja/DVWA)：是模擬易受攻擊的PHP/MySQL網頁應用程式

### <kbd>P2-130 ~ P2-153</kbd> 實體安全 
* 威脅類型
    * 天然災害
    * 供應系統中斷
    * 人為破壞
    * 政治事件
* 設計**量化指標** > 評估實體防護措施的**有效性**
    * 成功入侵次數
    * 成功破壞或竊盜次數
    * 不成功入侵次數
    * 不成功的破壞或竊盜次數
    * 偵測、評估到復原的時間
    * 對機關影響程度
    * 偵測機制誤判次數
    * 入侵者突破實體防護機制的時間
* **生命安全**是實體安全計畫中**永遠第一優先**
    * 例如門禁碰到故障停電時，應採用「失效安全(Fail-Safe)」原則(維持開啟狀態)
    * 可以參考CNS 27002
* 門應依**疏散方向**順向開啟(出口方向外推)
* 空調：
    * 應維持**正風壓**(開門時風向外流動)
    * 濕度40~60%
    * 保持進氣口整潔及空氣新鮮
    * 自動偵測煙霧
    * 獨立電力供應
    * 緊急手動開關
    * 應定期檢測
* 電力：
    * 有主要(日常供電)/次要(中斷時可供電)來源
    * 備援舉例 - 不斷電系統(UPS)：
        * 分在線式(平常用電會經過UPS)及非在線式(只有中斷時才會轉用UPS供電)
    * 電力干擾：閃電/高壓電/電纜/電器等
    * 靜電
        * 要使用抗靜電桌面/設備/天花板/地板
        * 不使用地毯
        * 設備需接地
        * 施工時戴上抗靜電帶
* 滅火
    * 降溫
    * 去除可燃物
    * 去除氧氣
    * 瓦解化學反應
* 緊急應變措施
    * 程序：緊急關機、人員疏散、人員認知訓練、消防演習
    * 清楚的文件：定期更新，隨手可得

## [Unit 8] 應用程式安全

### <kbd>P3-4</kbd> 定義
* 可以先從軟體安全工程的學理上建立基本觀念
* **應用安全**屬於軟體工程問題 > 由「設計」來解決
* **架構安全**屬於系統管理問題 > 由「設定」來解決

### <kbd>P3-5 ~ P3-13</kbd> 應用程式安全威脅
#### 緩衝區溢位
* 正常輸入資料時，程式碼將資料儲存至緩衝區的位址
* 惡意資料輸入時，
#### 惡意程式
* 可以分為以下幾種
    * 「病毒」：需要附著在程式或檔案中
    * 「蠕蟲」：自己有能力主動進行傳播
    * 「後門」：不須經一般安全控管，就可以遙控被植入者設備，分「維護用後門」及「被惡意植入後門」程式
    * 「木馬」：陷阱程式
    * 「間諜程式」竊取系統機密資料
* 現今惡意手法可能結合不同手法與行為
#### 邏輯炸彈
#### 隱藏通道
* 分為以下兩種：
    * 隱藏儲存通道：共享儲存空間
    * 隱藏時序通道：處理不同資料所需不同時間
    * 不受存取規則控管的通道，就稱為隱藏通道
#### 輸入攻擊
* 若使用端輸入惡意資料，應用程式沒有檢查，便可造成錯誤
* Web應用程式常見攻擊大多屬於此類
    * 跨網站腳本攻擊(Cross-Site Scripting = XSS)：輸入惡意JavaScript/VBScript代碼
    * SQL注入(SQL Injection)：輸入惡意SQL語法
* 收到「不可信任來源」所輸入內容時，應先進行過濾及正規化才進行後續作業

### <kbd>P3-14 ~ P3-18</kbd> 軟體開發生命週期安全(SSDLC)
* 傳統軟體開發思維
    * 特性：功能性導向/缺乏安全性考量
* SSDLC
    * = Secure Software Development Life Cycle
    * 步驟如下：
        1. 需求分析
        2. 架構設計
        3. 程式實作
        4. 測試及驗收
        5. 部署與維運

### <kbd>P3-19 ~ P3-29</kbd> 應用程式安全控制
* 變更控制
    * 實作應用程式變更控制流程
    * 所有變更都要獲得授權，且會記錄下來
* 職責區隔
    * 作業人員**不應**有權限存取線上程式碼/程式物件
    * 程式設計人員**不應**該存取線上運作中之軟體
* 程式庫維護
    * 所有紀錄都要有遷入遷出的紀錄
* 應用程式安全檢測
    * 任何程式都可能有瑕疵或弱點
    * 可以依靠工具輔助進行檢測
        * IPS
        * Site code Analysis
        * WAF
        * 滲透測試
        * 網站弱點評估
* 行動應用程式安全
    * 可以參考
    * 機關開發時很容易出現兩大問題
        * 程式碼安全性議題：可參考[OWASP Top 10](https://owasp.org/www-project-top-ten/)
        * 隱私侵犯議題：容易侵犯隱私
* 舉例：
    * LokiBot ([內容1](https://3c.ltn.com.tw/news/41103)/[內容2](https://www.checkpoint.com/tw/cyber-hub/threat-prevention/what-is-malware/lokibot-malware/)/[內容3](https://www.informationsecurity.com.tw/article/article_detail.aspx?aid=10575)) 

### <kbd>P3-30 ~ P3-18</kbd> Web應用程式安全
* OWASP Web 十大風險
    1. 權限控制失效 (Broken Access Control): 未經授權的存取，例如繞過存取控制檢查、未經授權存取他人資料等。
    2. 加密機制失效 (Cryptographic Failures): 使用過時或脆弱的加密演算法、敏感資料未加密傳輸等。
    3. 注入式攻擊 (Injection): 注入式攻擊，如SQL注入、OS命令注入等。 
    4. 不安全設計 (Insecure Design): 缺乏威脅建模、業務邏輯缺陷、安全需求不完整等。
    5. 安全設定缺陷 (Security Misconfiguration): 伺服器、框架、應用程式的設定錯誤，例如預設帳號密碼、不必要的權限等。
    6. 危險或過舊的元件 (Vulnerable and Outdated Components): 使用已知的漏洞元件、過時的函式庫或框架。 
    7. 認證及驗證機制失效 (Identification and Authentication Failures): 認證和驗證機制不完善，例如密碼破解、Session固定等。 
    8. 軟體及資料完整性失效 (Software and Data Integrity Failures): 軟體更新、資料傳輸過程中未驗證資料的完整性。 
    9. 資安記錄及監控失效 (Security Logging and Monitoring Failures): 缺乏足夠的日誌記錄和監控，無法及時發現和應對安全事件。 
    10. 伺服端請求偽造 (Server-Side Request Forgery (SSRF)): 伺服器端請求偽造，攻擊者可以利用此漏洞訪問內部資源或發起惡意請求。 
* 案例：
    * [16歲研究人員發現Google對外網站XSS漏洞可駭入內部網站](https://www.ithome.com.tw/news/131300)
    * [中國漏洞通報平臺烏雲公布：日盛證券外洩數億筆資料](https://www.ithome.com.tw/news/104363)
        * 獲取資料就可以進行社交工程攻擊
    * [OWASP ZAP Online Scan(Hosted Scan)](https://hostedscan.com/)
        * 可以拿來檢測弱點掃描
        * 介紹[文章](https://hackmd.io/@shinjielee/zap)
* 檢測
    * 定期針對核心資通系統進行網站安全弱點掃描
        * 黑箱檢測：SQL注入/XSS等，可以檢測執行時才出現的錯誤，無法清楚定位程式碼
        * 白箱檢測：靜態分析原始碼，檢測完整/精準度高，無法檢測執行時的錯誤
        * 滲透測試：權限跳脫/邏輯錯誤

## [Unit 9] 資通安全健診

### <kbd>P3-41 ~ P3-44</kbd> 項目
* 網路架構檢視
* 網路惡意活動檢視
* 使用者端電腦惡意活動檢視
    * 檢視是否使用不支援的系統/軟體
        * Windows 7以前
        * MS Office 2007以前
    * 檢視應用程式安全性更新情形
* 伺服器端電腦惡意活動檢視
    * 檢視是否使用不支援(不合時宜，結束生命週期)的系統/軟體
        * Windows Server 2003以前
        * MS Office 2007以前
* 目錄伺服器設定檢視
    * AD伺服器組態設定
* 防火牆連線設定檢視
    * 檢視防火牆是否有安全性弱點

### <kbd>P3-45 ~ P3-51</kbd> 流程
* 基本環境調查
    * Switch是否有Port mirror功能
* 決定範圍與抽樣方式
* 檢測配合事宜
    * 由受測單位提供資料給檢測單位
* 啟始會議
    * 執行檢測前辦理
    * 說明檢測項目及範圍
    * 參與人員須有機關及相關業務承辦人
* 執行檢測
    * 依照啟始會議決議的項目/流程辦理
* 撰寫檢測報告
* 提出改善建議
* 結束會議
    * 檢測完成後
    * 說明發現項目、改善建議與結論
* 修補規劃與追蹤
    * 依改善建議規劃修補方式
    * 已修補弱點，需留存弱點修補紀錄
    * 完成後要進行復測
* 分享資安健檢經驗

## [Unit 10] 資通安全事件通報及應變

### <kbd>P3-53</kbd> 辦法
* 資通安全管理法 [3](https://law.moj.gov.tw/LawClass/LawSingle.aspx?pcode=A0030297&flno=3) / [14](https://law.moj.gov.tw/LawClass/LawSingle.aspx?pcode=A0030297&flno=14) / [18](https://law.moj.gov.tw/LawClass/LawSingle.aspx?pcode=A0030297&flno=18)
```
第 3 條
本法用詞，定義如下：
一、資通系統：指用以蒐集、控制、傳輸、儲存、流通、刪除資訊或對資訊為其他處理、使用或分享之系統。
二、資通服務：指與資訊之蒐集、控制、傳輸、儲存、流通、刪除、其他處理、使用或分享相關之服務。
三、資通安全：指防止資通系統或資訊遭受未經授權之存取、使用、控制、洩漏、破壞、竄改、銷毀或其他侵害，以確保其機密性、完整性及可用性。
四、資通安全事件：指系統、服務或網路狀態經鑑別而顯示可能有違反資通安全政策或保護措施失效之狀態發生，影響資通系統機能運作，構成資通安全政策之威脅。
五、公務機關：指依法行使公權力之中央、地方機關（構）或公法人。但不包括軍事機關及情報機關。
六、特定非公務機關：指關鍵基礎設施提供者、公營事業及政府捐助之財團法人。
七、關鍵基礎設施：指實體或虛擬資產、系統或網路，其功能一旦停止運作或效能降低，對國家安全、社會公共利益、國民生活或經濟活動有重大影響之虞，經主管機關定期檢視並公告之領域。
八、關鍵基礎設施提供者：指維運或提供關鍵基礎設施之全部或一部，經中央目的事業主管機關指定，並報主管機關核定者。
九、政府捐助之財團法人：指其營運及資金運用計畫應依預算法第四十一條第三項規定送立法院，及其年度預算書應依同條第四項規定送立法院審議之財團法人。
```
```
第 14 條
1. 公務機關為因應資通安全事件，應訂定通報及應變機制。
2. 公務機關知悉資通安全事件時，除應通報上級或監督機關外，並應通報主管機關；無上級機關者，應通報主管機關。
3. 公務機關應向上級或監督機關提出資通安全事件調查、處理及改善報告，並送交主管機關；無上級機關者，應送交主管機關。
4. 前三項通報及應變機制之必要事項、通報內容、報告之提出及其他相關事項之辦法，由主管機關定之。
```
```
第 18 條
1. 特定非公務機關為因應資通安全事件，應訂定通報及應變機制。
2. 特定非公務機關於知悉資通安全事件時，應向中央目的事業主管機關通報。
3. 特定非公務機關應向中央目的事業主管機關提出資通安全事件調查、處理及改善報告；如為重大資通安全事件者，並應送交主管機關。
4. 前三項通報及應變機制之必要事項、通報內容、報告之提出及其他應遵行事項之辦法，由主管機關定之。
5. 知悉重大資通安全事件時，主管機關或中央目的事業主管機關於適當時機得公告與事件相關之必要內容及因應措施，並得提供相關協助。
```

### <kbd>P3-54 ~ P3-67</kbd> 資安事件通報
* 綜合評估說明
    * **由輕至重**分為**1234**級
    * 敏感資訊
    * 一般公務機密
    * 國家機密
    * 資安三要素(CIA)評估影響程度
        * 機密性/完整性/可用性
        * 其中一個等級數最高者，則以該等級為事件等級
* 通報資訊
    * 資通安全事件通報應變辦法 [3](https://law.moj.gov.tw/LawClass/LawSingle.aspx?pcode=A0030305&flno=3)
    ```
    第 3 條
    資通安全事件之通報內容，應包括下列項目：
    一、發生機關。
    二、發生或知悉時間。
    三、狀況之描述。
    四、等級之評估。
    五、因應事件所採取之措施。
    六、外部支援需求評估。
    七、其他相關事項。
    ```
* 作業流程
    * 公務機關/特並非公務機關者，**1小時**內向上呈報
    * 1/2級要在**8小時**內完成審核，3/4級則是**2小時**內完成
* 流程規範
    * 資通安全事件通報應變辦法 [9](https://law.moj.gov.tw/LawClass/LawSingle.aspx?pcode=A0030305&flno=9) / [10](https://law.moj.gov.tw/LawClass/LawSingle.aspx?pcode=A0030305&flno=10)
    ```
    第 9 條
    公務機關應就資通安全事件之通報訂定作業規範，其內容應包括下列事項：
    一、判定事件等級之流程及權責。
    二、事件之影響範圍、損害程度及機關因應能力之評估。
    三、資通安全事件之內部通報流程。
    四、通知受資通安全事件影響之其他機關之方式。
    五、前四款事項之演練。
    六、資通安全事件通報窗口及聯繫方式。
    七、其他資通安全事件通報相關事項。
    ```
    ```
    第 10 條
    公務機關應就資通安全事件之應變訂定作業規範，其內容應包括下列事項：
    一、應變小組之組織。
    二、事件發生前之演練作業。
    三、事件發生時之損害控制機制。
    四、事件發生後之復原、鑑識、調查及改善機制。
    五、事件相關紀錄之保全。
    六、其他資通安全事件應變相關事項。
    ```

### <kbd>P3-68 ~ P3-80</kbd> 資安事件處理
* 目的
    * 確認資安事件是否發生
    * 降低對業務與網路服務的中斷時間
    * 提供精準即時資訊
    * 規定時間內完成損害控制與復原作業
    * 實作控制以維護監管權
    * 讓法務單位可對惡意者提起訴訟
* 處理計畫
    * 定期重新審查計畫文件
        * 更新人員、科技、業務處理流程
    * 訓練
    * 財務支持
        * 預算
        * 額外設備
        * 專業人員
        * 員工薪資
        * 訓練費用
    * 演練
        * 定期見證
        * 修正作業流程
* 處理程序
    * 準備：事前的「準備」，在事件發生時越能有效快速的反應及處理
        * 資安事件處理小組：技術部門、管理人員、法務、數位鑑識專家、公共關係部門、人力資源部門、實體安全與維護部門、通訊部門 
    * 識別：資安事件無法完全防治，但**必須被偵測**
        * 識別**意圖**
        * 確認**範圍**
        * 保留**證據**
        * **可疑事件**
        * 監聽正在進行的**攻擊行為**
        * 識別出來的相關**證物**，從發現到提出至法院，須有完整的**監管紀錄**
    * 封鎖：封鎖入侵來源，避免災害擴大
        * 避免驚動入侵者，以避免**證據被銷毀**
        * 進行**證據分析**與**數位鑑識**
        * 阻擋攻擊來源IP和網段
        * 關閉不必要的服務
    * 根除：完全移除惡意程式
        * 決定採用移除/回存：是否可以完全移除乾淨，備份資料中是否有惡意程式
        * 強化防禦機制：提升稽核紀錄詳細程度，更嚴謹的控管存取來源
    * 復原：將業務與服務回復到正常運作狀態
    * 經驗學習：召開經驗學習會議
* 個資外洩
    * 在「識別」與「封鎖」階段應確定**個資外洩範圍**
    * 在「復原」階段，依個資法規定，應主動告知被洩漏對象，並提供改善方案以避免被洩漏者進一步損害

### <kbd>P3-81 ~ P3-</kbd> 數位證據與數位鑑識
* 數位鑑識程序
* 數位鑑識原則
    * 交換
    * 特徵
    * 健全性
    * 鑑別
    * 物證監管鏈
    * 數位證據完整性
    * 客觀性