# 📘 Day 1|黑箱 vs 白箱、TFDA 要求地圖 ## 🎯 學習目標 1. 了解 **黑箱測試 (PenTest)** 與 **白箱檢測 (SCA/SAST)** 的定義與差異。 2. 在 **Win11 + Kali (WSL2 或 VM)** 上完成工具環境初始化。 3. 建立專案用的 **資安工作資料夾架構**。 4. 輸出第一份「資安工作地圖 (WBS)」+工具清單。 --- ## 🧩 Part 1. 概念學習 ### 1. 黑箱測試 (Penetration Test, PenTest) - **模擬駭客行為**,不看程式碼,只測試外部攻擊面。 - 工具:nmap、Hydra、sqlmap、ZAP、Burp Suite。 - 常見發現:弱密碼、SQL Injection、XSS、錯誤設定。 - 定義 - **黑箱測試** = 像外部攻擊者一樣,不知道系統內部程式碼、架構或設定,只憑外部公開或可存取的介面進行測試。 - 與 **白箱測試**(有完整程式碼、架構資訊)與 **灰箱測試**(部分資訊)相對。 - 目標 - **找出外部攻擊面**:模擬真實駭客如何探索與利用漏洞。 - **驗證資安控制是否有效**:像防火牆、WAF、登入防爆機制。 - **衡量實際風險**:若攻擊者真的來了,可以走多遠?能不能進到核心資料? - 基本流程 1. **偵察 (Reconnaissance)** - 找到目標服務、版本、開放埠(用 nmap、Masscan)。**尋找攻擊面 (attack surface)** 2. **掃描與枚舉 (Scanning & Enumeration)** - 掃描弱點(ZAP、Nikto)、枚舉用戶名/目錄/子域名。 3. **利用 (Exploitation)** - 嘗試利用漏洞(sqlmap 注入、Hydra 爆破帳號密碼、XSS 測試)。 4. **後滲透 (Post-Exploitation)** - 確認能存取什麼資料、是否能橫向移動。 5. **報告 (Reporting)** - 紀錄發現、風險評級、修補建議。 - 工具 - **網路/服務偵測**:`nmap`、`masscan` - **密碼爆破**:`Hydra`、`Medusa` - **Web 弱點測試**:`sqlmap`(SQL Injection)、`ZAP`(OWASP DAST)、`Burp Suite`(攔截修改流量) - **自動化掃描**:Nikto、wpscan、dirb/dirbuster - 常見發現 - **弱密碼 / 預設帳號**(例如 admin/admin) - **SQL Injection**(未消毒的輸入 → 任意查詢) - **XSS(跨站腳本)** - **錯誤設定**(目錄遍歷、備份檔外洩、過度權限) - **不安全通訊協定**(FTP/Telnet 明文、過時 SSL/TLS) - 適用場景 - **醫療器材軟體/數位醫療系統**:測試是否可被外部攻擊導致病歷洩漏或醫療服務中斷。 - **上市前安全驗證**:TFDA/FDA/MDR 要求「獨立第三方滲透測試」。 - **紅隊演練 (Red Team Exercise)**:模擬真實駭客行為。 - 實務注意事項 - ✅ **授權範圍要明確**:避免誤測或觸法。 - ✅ **先自測、再委外**:開源工具先找明顯弱點,最後交給第三方提供獨立報告。 - ✅ **測試與修補循環**:滲透測試不是一次性的,應隨版本更新定期進行。 ### 2. 白箱檢測 (White-box Testing / Source Code Analysis, SCA) - 又稱「**原始碼檢測 (Source Code Analysis)**」,直接讀源碼。 - 工具:Semgrep、Bandit、Trivy、Fortify (商用)。 - 常見發現:硬編碼密碼、缺少輸入驗證、Cookie 未加 Secure 標誌。 - 定義 - **白箱檢測** = 在完全掌握原始碼的情況下,直接對程式碼進行靜態分析,檢查是否有**安全漏洞、弱點模式、違反安全規範的實作**。 - 不需執行程式(與 DAST 不同),強調 **早期發現、快速修補**。 - 目標 - 在開發階段提早找出漏洞,降低修補成本。 - 確保程式遵守安全編碼規範(如 OWASP ASVS、CWE Top 25)。 - 減少進入測試或生產階段的「已知弱點」。 - 基本流程 1. **選擇工具/規則集**:如 Semgrep(可客製規則)、Bandit(Python 專用)。 2. **掃描程式碼**:分析語法樹、控制流、資料流。 3. **產出報告**:列出疑似漏洞(通常會有誤報,需要人工審查)。 4. **修正 & 驗證**:針對每一項弱點修補,再次掃描確認。 5. **持續整合**:將 SCA 工具整合到 CI/CD pipeline,自動執行。 - 工具 - **開源**: - `Semgrep` → 輕量、支援多語言、可寫規則。 - `Bandit` → 專為 Python 安全弱點檢測。 - `Trivy` → 除容器/依賴檢測,也能做 IaC(基礎建設即程式碼)與程式弱點檢查。 - **商用**: - `Fortify`、`Checkmarx`、`Veracode` → 支援大型專案、合規性需求(醫材審查時常見)。 - 常見發現 - **硬編碼敏感資訊** → 密碼、金鑰、API Token 寫死在程式中。 - **缺少輸入驗證** → 導致 SQL Injection / XSS。 - **不安全加密/雜湊演算法** → MD5、SHA1、DES。 - **Cookie 未加 Secure/HttpOnly 標誌** → 可能被竊取。 - **錯誤處理不足** → 揭露堆疊訊息或路徑。 - 適用場景 - **開發早期/日常開發**:隨時發現錯誤,降低漏洞流入測試/生產。 - **醫材軟體送審文件**:SCA 報告可作為「Secure Coding Process」的證據。 - **DevSecOps Pipeline**:結合 GitHub Actions、GitLab CI,在每次 commit 自動掃描。 - 實務注意事項 - ✅ **誤報率**:SCA 常會誤判,需要人工審核。 - ✅ **需搭配 DAST/SAST**:光看程式碼找不到實際執行時的環境配置問題。 - ✅ **版本控制整合**:最好在 pull request 時自動跑掃描。 - ✅ **符合標準**:醫材領域建議對照 **CWE、OWASP ASVS、FDA Premarket Guidance** 等標準,證明檢測的充分性。 📌 小結: - **白箱檢測**專注在「程式碼安全」,能早期阻斷漏洞; - **黑箱測試**專注在「外部攻擊面」,驗證實際能否被利用; - **兩者搭配** → 才能符合醫療器材軟體送審與臨床安全的完整需求。 --- 👉 **差異表** | 特點 | 黑箱 (PenTest) | 白箱 (SCA) | | --- | --- | --- | | 可見度 | 只看外部介面 | 全部程式碼可見 | | 測試目標 | 外部攻擊面、部署 | 原始碼、程式邏輯 | | 工具 | nmap, Hydra, sqlmap, ZAP | Semgrep, Bandit, Trivy | | 適用時機 | 上線前 / 稽核 | 開發中 / 程式審查 | ### 🔐 軟體安全測試方法比較表 | 測試方法 | 黑箱測試 (Black-box / PenTest) | 白箱測試 (White-box / SCA) | 灰箱測試 (Gray-box) | | --- | --- | --- | --- | | **定義** | 模擬駭客,**完全不知情**,僅從外部攻擊面進行測試 | 有完整程式碼/設計資訊,針對**源碼安全性**檢測 | 測試者擁有**部分資訊**(如 API 文件、測試帳號),介於黑箱與白箱之間 | | **資訊掌握度** | 0% → 只知道服務對外開放 | 100% → 掌握所有程式碼與架構 | 介於 30–70% → 知道部分內部結構 | | **主要目標** | 驗證系統是否能被外部攻擊成功利用 | 找出程式碼層級安全漏洞 | 驗證權限劃分、API 安全性與內部設計弱點 | | **常用工具** | Nmap、Hydra、sqlmap、OWASP ZAP、Burp Suite | Semgrep、Bandit、Trivy、Fortify (商用) | Postman、Burp Suite + AuthMatrix、jwt_tool、GraphQL 測試工具 | | **常見發現** | 弱密碼、SQL Injection、XSS、錯誤設定 | 硬編碼密碼、缺少輸入驗證、不安全加密、Cookie 標誌缺失 | 權限提升 (Privilege Escalation)、IDOR、不當 Token 驗證、API 濫用 | | **優點** | 模擬真實駭客,能驗證整體防禦有效性 | 在開發早期就能找到問題,修補成本低 | 結合內外視角,測試更高效,特別適合角色/權限系統 | | **缺點** | 盲測耗時、覆蓋率有限 | 可能誤報多,需要人工審查;無法驗證實際攻擊利用性 | 需適度提供資訊;若資訊過多,可能變成白箱 | | **適合階段** | 系統上線前、年度委外滲透測試、法規送審前 | 開發早期、CI/CD Pipeline、程式碼 Review | 系統整合測試、醫材送審補強、角色/權限驗證 | | **醫材應用** | 測試醫療軟體能否被外部攻擊導致病歷洩漏或中斷 | 確認程式碼沒有硬編碼金鑰、弱加密演算法 | 驗證不同角色(醫師、護士、病患)的資料隔離是否正確 | 📌 **小結** - **黑箱**:看「攻擊能不能進來」 - **白箱**:看「程式碼有沒有漏洞」 - **灰箱**:看「內部角色/API 設計是否安全」 三者結合,才算完整的醫材資安檢測策略,能同時滿足 **實務防護 + 法規合規 (TFDA/FDA/IEC 62304/ISO 14971)** 的需求。 ### 3. TFDA 對資安的要求 - **必須有:** - 原始碼安全檢測報告(白箱)。 - 滲透測試報告(黑箱)。 - 風險管理文件(ISO 14971)。 - 軟體生命週期文件(IEC 62304 / IEC 81001-5-1)。 - **文件範本**:TFDA《醫療器材網路安全評估分析參考範本》 → 直接套用章節填寫。 ### 🔹 定義與背景 - **TFDA(食品藥物管理署)在審查數位醫療器材時,要求製造商或開發單位提供完整的資安檢測與風險管理文件**,以確保產品在臨床應用中不會因資安漏洞造成病患隱私洩漏或安全風險。 - 參考來源:TFDA《醫療器材網路安全評估分析參考範本》(可於 TFDA 官網下載)。 --- ### 🔹 必須有的文件(核心四件組) 1. **原始碼安全檢測報告(白箱測試,SAST/SCA)** - 工具:Semgrep、Bandit、Trivy、Fortify 等 - 目的:確保程式碼沒有硬編碼密碼、不安全函式、缺少輸入驗證等問題。 2. **滲透測試報告(黑箱測試,DAST/PenTest)** - 工具:Nmap、Burp Suite、OWASP ZAP、sqlmap 等 - 目的:模擬駭客攻擊,驗證實際部署是否存在 SQL Injection、XSS、弱密碼、錯誤設定。 - 最好由 **第三方專業單位**執行,以提升公信力。 3. **風險管理文件(依 ISO 14971)** - 建立「威脅事件 → 資安風險 → 控制措施 → 殘餘風險」的追溯矩陣。 - 資安風險需與病人安全風險結合(例如:若資安攻擊導致心律調整器停機 → 病患直接受害)。 4. **軟體生命週期文件** - **IEC 62304**:醫療軟體開發流程(需求、設計、驗證、維護)。 - **IEC 81001-5-1**:醫療 IT 安全工程標準,強調在 SDLC 中納入資安活動。 - 必須呈現 **DevSecOps 或 SDLC 中資安嵌入**的證據。 ### 🔹 文件範本(TFDA 提供) - **《醫療器材網路安全評估分析參考範本》** - 內容包括: - 系統概述 - 威脅與漏洞分析 - 風險評估表格 - 測試活動與結果 - 資安維運計畫 - **實務建議**:直接套用該範本的章節,逐一填入自家產品的測試報告與流程文件,可大幅減少文件編寫負擔。 ### 🔹 標準與 TFDA 的對應關係 | TFDA 要求 | 對應國際標準 | | --- | --- | | 原始碼檢測 | SAST/SCA 工具報告(對應 FDA Premarket、IEC 81001-5-1) | | 滲透測試 | DAST/PenTest 報告(對應 UL 2900、OWASP 標準) | | 風險管理 | ISO 14971(醫療風險管理) | | SDLC 文件 | IEC 62304(軟體生命週期)、IEC 81001-5-1(資安工程) | ### 🔹 實務注意事項 - ✅ **內部自測 vs 委外測試** - 初步可用 Kali + 開源工具進行自測; - 最終送審前建議委外第三方單位出具滲透測試與白箱檢測報告,公信力更高。 - ✅ **文件一致性** - 測試報告要能 trace 到風險管理表格(ISO 14971),並對應 SDLC 文件(IEC 62304)。 - ✅ **維運要求** - TFDA 不只看開發期,也要求 **上市後的資安維護計畫**(漏洞通報、SBOM、更新機制)。 - ✅ **國際一致性** - TFDA 的規範與 **FDA Premarket Guidance (2025 版)**、**EU MDR / MDCG 2019-16** 高度對齊,可以一套文件應付多地審查。 📌 **總結**: TFDA 對醫材資安的檢測要求 ≈ **白箱 + 黑箱 + 風險管理 + SDLC 文件**四合一,並且提供官方範本可以直接套用。 你如果要送件,最好的策略是: 1. **自測 → 修補 → 委外測試** 2. **把結果對齊 ISO 14971 & IEC 62304** 3. **最後填入 TFDA 範本**,形成一份完整的送審包。 --- ## 🛠️ Part 2. 工具環境建置 **1. 確認 Kali 已安裝(WSL2 或 VM)** ```powershell wsl --list --verbose # 確認有 kali-linux ``` **2. 更新套件** ```bash sudo apt update && sudo apt upgrade -y ``` **3. 安裝核心工具** ```bash # 滲透測試工具 sudo apt install -y nmap hydra sqlmap ffuf zaproxy # 原始碼檢測 sudo apt install -y python3-pip pip install semgrep bandit # 依賴檢測與 SBOM sudo apt install -y trivy ``` **4. 驗證工具版本** ```bash nmap -V hydra -h | head -n 3 sqlmap --version ffuf -h | head -n 5 zaproxy --version semgrep --version bandit --version trivy -v ``` 👉 建議把結果截圖,存進 `/Security/evidence/day1-tools.png`。 --- ## 📂 Part 3. 建立資安工作資料夾架構 在你的專案根目錄建立: ```bash mkdir -p Security/{01-SCA,02-PenTest,03-SBOM,04-TFDA,evidence} ``` 資料夾說明: - `01-SCA`:白箱檢測輸出(Semgrep、Bandit)。 - `02-PenTest`:黑箱檢測輸出(nmap、ZAP、Hydra)。 - `03-SBOM`:依賴檢測與 SBOM 檔案。 - `04-TFDA`:合規文件草稿(TFDA 範本、ISO 14971 風險管理表)。 - `evidence`:截圖、命令輸出、日誌。 --- ## 📝 Part 4. Side Project - **任務**:製作你的「資安工作分解結構 (WBS)」。 - **內容**: 1. 黑箱測試(工具、頻率、輸出)。 2. 白箱檢測(工具、規則、報告)。 3. SBOM 維護(工具、格式、更新頻率)。 4. 文件對應(TFDA 範本章節、ISO 14971 風險表、IEC 62304 生命週期表)。 📄 交付物:一份 Markdown/Word 檔 → `04-TFDA/WBS_v0.1.docx`。 --- ## ❓ Part 5. 隨堂考 (Day 1 — 15 題) ### 1. 黑箱測試的定義是什麼?請舉一個工具。 **定義**:黑箱測試 (Black-box Testing / Penetration Testing) 是從外部攻擊者的角度來測試系統,不需要知道程式碼或內部架構,只透過「可見的介面」進行攻擊與滲透。 **工具舉例**:`nmap`(掃描網路服務)、`OWASP ZAP`(Web 弱點掃描)、`Hydra`(口令爆破)。 --- ### 2. 白箱檢測的定義是什麼?請舉一個工具。 **定義**:白箱檢測 (White-box Testing / SCA, Static Code Analysis) 是檢查程式碼本身,分析源碼是否存在資安問題(例如硬編碼密碼、缺少輸入驗證)。 **工具舉例**:`Semgrep`、`Bandit`、`Trivy`(依賴漏洞掃描)。 --- ### 3. 黑箱和白箱測試的最大差異點是什麼? - **黑箱**:像駭客 → 只看外部輸入輸出,不知道程式碼。 - **白箱**:像開發者/稽核員 → 看得到原始碼與內部架構。 👉 最大差異:測試的「可見度」與「角度」不同,一個測攻擊面,一個測程式邏輯。 --- ### 4. TFDA 為什麼要求同時要有白箱與黑箱報告? 因為醫療器材系統必須同時證明: - **白箱 (SCA)**:開發階段程式碼乾淨、無明顯安全漏洞。 - **黑箱 (PenTest)**:實際部署後,不會被駭客從外部攻破。 👉 兩者互補,能確保系統從「內部程式邏輯」到「外部攻擊面」都安全,才能符合醫療法規的高敏感性要求。 --- ### 5. SCA 常見的兩個開源工具是什麼? - **Semgrep** → 規則式程式碼掃描,可偵測不安全函式或寫法。 - **Bandit** → Python 專用的靜態程式碼分析工具。 --- ### 6. PenTest 常見的三個工具是什麼? - **nmap** → 掃描網路服務與版本。 - **OWASP ZAP** → Web 應用弱點掃描。 - **Hydra** → 密碼/口令爆破測試。 (也可加 sqlmap、Burp Suite Pro,但三個核心工具足夠。) --- ### 7. 什麼是 SBOM?它在醫療器材資安裡的重要性是什麼? **定義**:SBOM (Software Bill of Materials) = 軟體物料清單,就像食材清單,列出軟體中所有依賴套件與版本。 **重要性**: - 可以追蹤哪些第三方套件有漏洞 (CVE)。 - 醫療器材必須符合 TFDA/FDA 的可追溯性與風險管理要求。 - 一旦外部公布漏洞,能快速比對是否受影響。 --- ### 8. nmap 的用途是什麼? - 掃描主機存活與開放埠號。 - 偵測服務與版本 (`sV`)。 - 可配合 NSE 腳本進行弱點測試(例如 `mysql-brute`)。 👉 常用於黑箱測試的第一步 Recon(偵察)。 --- ### 9. Hydra 常用來測試什麼? - 用來進行「密碼爆破測試」(Brute Force)。 - 支援多協定(HTTP POST、SSH、FTP、MySQL、PostgreSQL…)。 - 檢查系統是否有「弱口令」或「缺少鎖定/節流機制」。 --- ### 10. sqlmap 是用來檢測什麼漏洞? - **SQL Injection (SQL 注入漏洞)**。 - 可自動化測試是否能透過輸入注入 SQL 語法,讀取或竄改資料庫內容。 - 功能:偵測、列出 DB、讀取表格、甚至可能寫檔/提權(若風險高)。 --- ### 11. Bandit 主要用來掃描哪種語言? - **Python**。 - 可自動檢查 Python 專案是否存在資安風險,例如: - 使用不安全的 `eval()`。 - 硬編碼密碼。 - 弱加密演算法(如 MD5)。 --- ### 12. Semgrep 的規則庫可以從哪裡取得? - **官方 Semgrep Registry**(線上規則庫)。 - GitHub 社群分享的自訂規則。 - 自己撰寫 YAML 規則(支援 pattern、taint tracking)。 --- ### 13. 為什麼需要 evidence 資料夾? - **證據保存**:存放掃描結果、截圖、日誌。 - **合規需要**:TFDA/FDA 審查時,必須附「可重現的證據」。 - **報告可信度**:補洞前後的對照證據,讓審查員與管理層信服。 --- ### 14. 在 TFDA 規範下,哪三個國際標準必須參照? 1. **ISO 14971** → 醫療器材風險管理。 2. **IEC 62304** → 醫療器材軟體生命週期。 3. **IEC 81001-5-1** → 醫療軟體資安生命週期(新標準)。 --- ### 15. 今天的實作裡,你完成了哪三個具體產出? 1. 安裝並驗證 **Kali + 工具環境**(nmap、Hydra、sqlmap、ZAP、Semgrep、Bandit、Trivy)。 2. 建立 **資安工作資料夾架構**:`01-SCA, 02-PenTest, 03-SBOM, 04-TFDA, evidence`。 3. 撰寫 **資安工作分解結構 (WBS) v0.1**,確認要做哪些報告與測試項目。 --- ✅ 這樣回答之後,你就能把 Q&A 直接存進 `04-TFDA/Day1_QA.docx`,當作 **Day 1 學習紀錄**。 --- ✅ **Day 1 結束時,你會有:** - 已安裝好的工具環境(Kali)。 - 專案資安資料夾架構。 - WBS v0.1 文件草稿。 - 工具版本與截圖證據。 - 完成 15 題 Q&A 測驗。 --- 把 **Day 1 講義(含指令、Q&A)** 做成 Word/PDF,存進 `04-TFDA/Day1_Report.docx` 當作學習紀錄 Notion Link: [Introduction to ISO 14971](https://www.notion.so/Introduction-to-ISO-14971-25b0ad7cf43180a2951fe727e0bfca1e?pvs=21)