資安遙測

🎯 什麼情境該想到我

當你「被入侵好幾個月都沒發現，最後是外部夥伴或客戶注意到盜刷才通知你」的時候。

⚙️ 怎麼用（步驟 / 公式）

意圖：把資安的監控、記錄與告警放進 Dev、QA、Ops 正在使用的同一套工具裡，讓整個價值流的每個人都看得見自己的應用與環境在一個充滿敵意的威脅環境中表現如何。

問題的形狀（Marcus Sachs，Verizon 資料外洩研究員，2010）
年復一年，在絕大多數持卡人資料外洩案中，組織是在外洩發生數個月或數季之後才偵測到；更糟的是，發現的方式往往不是內部監控控制，而更可能是組織外部的某個人——通常是業務夥伴，或是注意到詐欺交易的客戶。主要原因之一是：組織裡沒有人固定在審視 log 檔案。換句話說，內部資安控制常常無法及時偵測外洩，不是因為監控有盲點，就是因為沒有人在日常工作中檢視相關遙測。

A. 應用層要埋的遙測

• 成功與失敗的使用者登入
• 使用者密碼重設
• 使用者 email 位址重設
• 使用者信用卡變更

具體判準：作為暴力破解登入嘗試的早期指標，可以顯示**「失敗登入嘗試次數／成功登入次數」的比值**。當然也要針對重要事件建立告警，以便快速偵測與修正。

B. 環境層要監控／告警的項目

• OS 變更（生產環境、以及我們的 build 基礎設施）
• Security group 變更
• 組態變更（OSSEC、Puppet、Chef、Tripwire）
• 雲端基礎設施變更（VPC、security groups、users and privileges）
• XSS 嘗試（cross-site scripting attacks）
• SQLi 嘗試（SQL injection attacks）
• Web server 錯誤（4XX 與 5XX）

同時要確認 logging 設定正確、所有遙測送到對的地方。偵測到攻擊時，除了記錄之外，也可以選擇封鎖存取並保存來源資訊，以協助選擇最佳緩解措施。

Etsy 2010 案例（Nick Galbreath）

• Galbreath 當時是 Etsy 的工程總監，負責資安、防詐與隱私。他把 fraud 定義為「系統運作不正確，讓無效或未經檢查的輸入進入系統，造成財務損失、資料遺失／竊取、系統停機、破壞，或對另一個系統的攻擊」。
• 關鍵組織決策：他沒有另外成立防詐或資安部門，而是把這些責任嵌入整個 DevOps 價值流。
• 他建立的資安遙測與其他 Dev/Ops 導向的指標並排顯示，每一位 Etsy 工程師例行都會看到，共三項：
  1. 異常的生產程式終止（segmentation faults、core dumps 等）：特別關注為什麼某些程序在整個生產環境中不斷 dump core、且都是由同一個 IP 位址來的流量觸發；同樣值得關注的是 HTTP “500 Internal Server Errors”——這些是「漏洞正被利用以取得未授權存取、且需要緊急套用修補」的指標。
  2. 資料庫語法錯誤：「我們一直在程式碼裡尋找資料庫語法錯誤——它們要嘛讓 SQL Injection 攻擊成為可能，要嘛就是正在進行中的實際攻擊。因此我們對程式碼中的資料庫語法錯誤採取零容忍，因為它仍是被用來攻破系統的主要攻擊向量之一。」
  3. SQL injection 攻擊的跡象：「這是一個荒謬地簡單的測試——只要 ‘UNION ALL’ 出現在使用者輸入欄位裡我們就告警，因為那幾乎總是意味著 SQL injection 攻擊。我們也加了單元測試，確保這類不受控的使用者輸入永遠不可能進入我們的資料庫查詢。」
• 效果：Galbreath——「沒有什麼比看到自己的程式被即時攻擊，更能讓開發者理解這個運行環境有多充滿敵意。」結果是開發者意識到自己一直在被攻擊，這改變了他們寫程式當下對自己程式碼安全性的思考方式。

原文（暴力破解的具體判準）：「as an early indicator of brute-force login attempts to gain unauthorized access, we might display the ratio of unsuccessful login attempts to successful logins.」（L12047–12049）

原文（零容忍）：「For this reason, we had zero-tolerance for database syntax errors in our code, because it remains one of the leading attack vectors used to compromise systems.」（L12112–12115）

原文（極簡的 SQLi 偵測）：「This was a ridiculously simple test—we’d merely alert whenever ‘UNION ALL’ showed up in user-input fields, since it almost always indicates a SQL injection attack.」（L12117–12120）

🧪 我實際套用的紀錄

• （待填）

⚠️ 注意 / 什麼時候不適用

• 把資安遙測放進只有 Infosec 看得到的儀表板，等於沒做。 這條的整個效力來自「與 Dev/Ops 指標並排、每位工程師例行都看到」。
• 告警不是終點，單元測試才是。 Etsy 的 SQLi 做法是「告警」＋「加單元測試確保這類輸入永遠進不了資料庫查詢」——只有前者你會被告警淹沒。
• 別忽略 build 基礎設施的 OS 變更：書中把它與生產環境並列，因為建置環境同樣是攻擊面（見 保護部署管線）。
• 「失敗／成功登入比值」比「失敗登入絕對數」更有訊號，因為流量成長會讓絕對數失去意義。

🔗 相關工具

• 五層遙測覆蓋（資安遙測是同一套遙測體系的一層，不是另一套系統）
• 工具-遙測與監控（上位心法卡）
• 保護部署管線（build 基礎設施的變更也要被監控）
• 四類應用資安自動測試（測不到的部分交給生產遙測，兩者互補）
• 預先核可的資安函式庫（logging 與集中式 ELK stack 的組態就放在共用儲存庫）
• 把變更重歸類為標準變更（遙測同時是稽核證據的來源）
• DevOps手冊