關聯筆記：Google Cybersecurity Certificate > C2 課程總覽
C2W3 — 資安工具導論（Introduction to cybersecurity tools）
Module 3: Introduction to cybersecurity tools
目錄
- 一、這週的核心問題是什麼
- 為什麼這週先學 log 再談工具？
- 分析師實際上在用工具回答什麼問題？
- 二、log 與 SIEM 怎麼把訊號變成線索
- 三種常見 log 來源是什麼？
- SIEM 到底幫了什麼忙？
- dashboard（儀錶板）為什麼能加快判斷？
- 三、常見資安工具怎麼看懂
- 自管、雲端與混合部署怎麼分？
- Splunk 與 Chronicle 常見看板在看什麼？
- 開源工具和專有工具怎麼分？
- 四、工具會怎麼繼續演進
- SIEM 未來會往哪裡走？
- 初學者該對資安工具抱什麼期待？
- 五、術語速查表
一、這週的核心問題是什麼
1. 為什麼這週先學 log 再談工具？
- 因為工具不是憑空產生洞察，工具吃的是資料，而 log 就是最基礎的原料
- 日誌（Log）：記錄組織系統與網路中發生過的事件
- 分析師要先知道有哪些訊號可看，才知道工具能幫忙整理什麼
- 從 C2W1、C2W2 的角度看，前兩週在學「風險是什麼、該怎麼管」，這週開始進到「怎麼用資料看見風險」
核心邏輯
工具不會替你做判斷。工具的價值，是把零散事件整理成可判讀的線索；真正決定下一步的是分析師。
2. 分析師實際上在用工具回答什麼問題？
- 現在發生了什麼事？
- 這件事發生在誰、哪台主機、哪個 IP、哪個時間點？
- 這是單一異常，還是能串成攻擊脈絡的跡象？
- 這件事的風險有多高，要不要立刻升級處理？
- 我手上的證據夠不夠支持通報、調查或回應？
先問問題，再開工具
如果一開始只想著「我要用哪個工具」，通常會迷路；先定義你要確認的現象，工具才會變得有方向。
二、log 與 SIEM 怎麼把訊號變成線索
從原料到判讀的資料流：
| 階段 | 角色 | 產出 |
|---|---|---|
| Log（原料） | 各系統留下事件紀錄 | 原始事件條目 |
| SIEM（處理） | 集中收集 + 關聯分析 | 警報、可搜尋資料庫 |
| Dashboard（呈現） | 視覺化呈現重點 | 圖表、時間線、趨勢 |
log sources ──→ SIEM ──→ dashboard ──→ analyst
(原料) (處理) (呈現) (判讀)1. 三種常見 log 來源是什麼？
| Log 類型 | 會記錄什麼 | 分析師能看出什麼 |
|---|---|---|
| Firewall log | 來自網際網路的連線嘗試、內部對外請求 | 哪些連線被允許、拒絕，是否有可疑來源持續嘗試 |
| Network log | 裝置進出網路、裝置與服務之間的連線 | 哪些裝置互動異常，是否有不尋常流量或路徑 |
| Server log | 網站、郵件、檔案分享等服務事件 | 登入、密碼、使用者名稱請求，以及服務端是否出現異常 |
- 同一個安全事件，往往要交叉看多種 log 才看得完整
- 只看單一 log 容易誤判；例如登入異常可能還要搭配網路位置與主機活動一起看
易漏點
看不到 log，不代表沒事發生；很多時候只是 log source 沒有接好、沒有保留，或儲存格式不利於分析。
2. SIEM 到底幫了什麼忙？
- SIEM（Security Information and Event Management）：收集並分析 log 資料、監控關鍵活動的應用程式
- 核心能力包括：
- 集中收集多來源 log
- 即時監控與事件分析
- 觸發告警
- 把大量資料集中在同一個位置供搜尋與調查
| SIEM 能力 | 對分析師的實際價值 |
|---|---|
| 集中化 | 不用到處翻不同系統，各種 log 可以放在同一個工作面板 |
| 分析與關聯 | 比較容易把零散事件串成可理解的事件鏈 |
| 即時可視性 | 異常一出現就有機會被看到，不用等人工慢慢翻 |
| 告警 | 先把高風險訊號浮出來，讓人力優先處理重要事件 |
| 搜尋與篩選 | 快速縮小調查範圍，節省人工檢視成本 |
- 課程特別提醒：SIEM 不會自動適合所有組織，必須依照組織環境持續客製與調整
- 新威脅出現時，原本的規則、警示條件、資料來源設定，也要一起更新
3. dashboard（儀錶板）為什麼能加快判斷？
- dashboard（儀錶板）會把安全資料整理成圖表、表格、時間線，讓分析師更快看出趨勢
- 課程舉的例子是可疑登入：
- 五分鐘內對同一帳號嘗試 500 次登入
- 地理位置異常
- 發生時間不在平常工作時段
- 這種情境如果只看原始 log 很花時間，但用 dashboard 可以更快看出模式
| dashboard（儀錶板）會強調什麼 | 代表的意義 |
|---|---|
| 時間線 | 異常是瞬間尖峰，還是持續一段時間 |
| 地理位置 | 是否出現在非預期地區 |
| 帳號 / 裝置 / IP | 哪個風險對象最值得先追 |
| 指標（Metrics） | 系統表現或事件規模，例如回應時間、可用性、失敗率 |
dashboard（儀錶板）的真正用途
dashboard（儀錶板）不是只拿來「看漂亮圖表」，而是幫你把注意力集中在最值得追的異常上。
三、常見資安工具怎麼看懂
1. 自管、雲端與混合部署怎麼分？
| 類型 | 誰維運 | 適合什麼情境 | 課程中的例子 |
|---|---|---|---|
| 自管部署（Self-hosted） | 組織自己安裝、操作、維護 | 需要保有實體基礎設施控制權，或對敏感資料有較高掌控需求 | Splunk Enterprise |
| 雲端代管部署（Cloud-hosted） | 供應商代管，透過網際網路存取 | 不想自己投資基礎設施，想快速使用服務 | Splunk Cloud |
| 雲端原生部署（Cloud-native） | 供應商代管，且工具從設計起就為雲端能力最佳化 | 想利用雲端的可用性、彈性與可擴充性 | Chronicle |
| 混合部署（Hybrid） | 自管與雲端混合 | 一部分服務留在本地，一部分放雲端 | Splunk 常見於混合環境 |
- 實務上，課程這裡提到的常見資安工具，多半是以雲端部署或混合部署方式導入
- Splunk Cloud：偏雲端部署，也常出現在混合部署環境
- Chronicle：Google 的雲端原生部署（cloud-native）SIEM，強調資料保留、搜尋與分析能力
- Splunk Enterprise：是自管部署版本，但在實務上常和雲端版本一起形成混合部署
選工具不是比品牌
真正的問題是：資料在哪裡、誰來維運、組織能不能接受雲端、以及是否需要保有對敏感資料的實體控制權。
2. Splunk 與 Chronicle 常見看板在看什麼？
Splunk 常見看板
| 看板 | 主要用途 | 分析師可能怎麼用 |
|---|---|---|
| Security posture dashboard（安全態勢儀錶板） | 看過去 24 小時的重要安全事件與趨勢 | 即時追查可疑網路活動或特定 IP 的異常 |
| Executive summary dashboard（高階摘要儀錶板） | 提供高階層級的健康狀態與趨勢摘要 | 對利害關係人報告某段時間的事件趨勢 |
| Incident review dashboard（事件審查儀錶板） | 聚焦高風險、需要優先處理的事件 | 看事件發生前後的視覺化時間線 |
| Risk analysis dashboard（風險分析儀錶板） | 看特定風險對象的風險變化 | 例如觀察某使用者是否在異常時段登入 |
Chronicle 常見看板
| 看板 | 主要用途 | 分析師可能怎麼用 |
|---|---|---|
| Enterprise insights dashboard（企業洞察儀錶板） | 顯示近期警報、可疑網域與信心分數 | 快速判斷 IOC 與威脅嚴重度 |
| Data ingestion and health dashboard（資料匯入與健康度儀錶板） | 監控事件量、log source、資料匯入成功率 | 檢查 log 是否正常進來，避免監控盲區 |
| IOC matches dashboard（IOC 比對儀錶板） | 觀察威脅指標隨時間的出現情況 | 追某個可疑網域、IP 或裝置是否持續活動 |
| Main dashboard（主儀錶板） | 高層級看整體告警與事件活動 | 觀察 failed login 等趨勢是否突然上升 |
| Rule detections dashboard（規則偵測儀錶板） | 看特定偵測規則觸發的事件統計 | 找出反覆出現的事件類型與對應處置需求 |
| User sign in overview dashboard（使用者登入總覽儀錶板） | 觀察整體使用者登入行為 | 找出同帳號同時出現在多地登入等異常 |
- Chronicle 在課程中特別提到可以依照資產、網域、使用者、IP 位址等角度分析資料
- 它也會標示 IOC（Indicator of Compromise，入侵指標）、信心分數與嚴重度，幫助排序優先級
3. 開源工具和專有工具怎麼分？
| 類型 | 特點 | 代表例子 | 你該怎麼理解 |
|---|---|---|---|
| Open-source | 原始碼公開、通常免費、可高度客製 | Linux、Suricata | 彈性高、透明度高，很多已是業界標準 |
| Proprietary | 由公司擁有與維護、通常要付費 | Splunk、Google SecOps / Chronicle | 供應商支援完整，但原始碼與更新節奏掌握在廠商手上 |
- Linux：常見的開源作業系統，之後課程會更深入學 CLI
- Suricata：開源的網路分析與威脅偵測工具，可檢查網路流量、產生 log、找可疑行為
- 課程特別點出一個常見誤解：開源不代表比較不安全
- 反而因為原始碼公開、社群能快速檢視與修補，許多開源工具非常成熟
易混點：開源不等於沒人維護
很多開源工具背後都有成熟社群或基金會，例如 Suricata 由 OISF 維護。差別不在「有沒有人管」，而在維護模式與授權方式。
四、工具會怎麼繼續演進
1. SIEM 未來會往哪裡走？
- 越來越多組織走向雲端，SIEM 也必須支援 cloud-hosted 與 cloud-native 環境
- IoT（物聯網） 裝置越多，攻擊面越大，資料量也會暴增
- AI / ML 會持續強化：
- 威脅相關術語辨識
- dashboard（儀錶板）視覺化
- 資料儲存與分析效率
- 自動化也會變得更重要
| 發展方向 | 代表什麼 |
|---|---|
| 雲端化 | 工具要能更彈性地處理分散式環境 |
| 大量資料處理 | 面對更多裝置、更多事件、更多攻擊型態 |
| 自動化 | 把常見、重複的處置流程交給系統先跑 |
| 平台整合 | 不同安全平台之間要能互相溝通 |
- 課程在這裡引進 SOAR（Security Orchestration, Automation, and Response）
- 它是一組用自動化回應安全事件的應用程式、工具與 workflow
- 可以把常見事件的處理流程標準化，讓分析師把時間留給更複雜、不能完全自動化的事件
2. 初學者該對資安工具抱什麼期待？
- 工具很重要，但不是「先會寫 code 才能進資安」
- 課程中的從業者特別提醒，很多迷思都不必要：
- 不一定要先會寫程式
- 不一定要會 hack
- 不一定要是數學高手
- 不一定要有資安學位
- 真正重要的能力常常包括：
- 問對問題
- 快速學習
- 做研究
- 建立關係與跨部門合作
資安不是孤軍作戰
很多工作都需要和 IT、產品、法務、管理層合作。工具只是共同語言的一部分，溝通能力同樣重要。
Parisa 與 Talya 兩個補充提醒
- 安全設計要考慮可近用性（accessibility）：例如只用紅色表示警告，對色弱或色盲使用者可能無效。安全措施若無法被不同能力的使用者正確理解，就可能失去效果。
- 不同背景是優勢，不是缺點：業界沒有單一路徑，商管背景、研究能力、溝通能力，都可能成為你做安全工作的強項。
五、術語速查表
| 英文 | 中文 | 白話解釋 |
|---|---|---|
| Log | 日誌 | 系統、服務或使用者活動留下的紀錄 |
| Firewall log | 防火牆日誌 | 記錄內外網連線嘗試與請求 |
| Network log | 網路日誌 | 記錄裝置進出網路與彼此連線情況 |
| Server log | 伺服器日誌 | 記錄網站、郵件、檔案服務等事件 |
| SIEM | 安全資訊與事件管理 | 收集並分析 log、監控關鍵活動的工具 |
| Dashboard | 儀錶板 | 把資料整理成圖表、表格、時間線的介面 |
| Metrics | 指標 | 例如回應時間、可用性、失敗率等技術屬性 |
| Splunk Enterprise | Splunk 企業版 | 自管式的 SIEM / 資料分析工具 |
| Splunk Cloud | Splunk 雲端版 | 雲端代管的 log 收集、搜尋與監控工具 |
| Chronicle | Chronicle | Google 的 cloud-native SIEM 工具 |
| IOC | 入侵指標 | 可疑網域、IP、裝置等可能顯示遭入侵的訊號 |
| SOAR | 安全協調、自動化與回應 | 用自動化處理安全事件的工具與 workflow 集合 |
| Suricata | Suricata | 開源網路分析與威脅偵測工具 |
| Operating system (OS) | 作業系統 | 介於電腦硬體與使用者之間的基礎軟體 |
筆記建立日期：2026-03-27 ｜ 最後更新：2026-05-01