今天開始做SOC團隊版流程的逐步介紹，包含設計時每個流程Node的功能與為何要如此設定，重要的幾條線的意義與作用。
值得注意的是，三個SOC流程中，反而是個人版的設計最複雜，因為一個人的時間精神有限，所以要透過更多的Node協助判斷，預先處理／後處理，更多的判斷，所以反而更複雜
流程代碼：SEC_IR_FLOW_SOC_TEAM
表單代碼：SEC_IR_SOC_TEAM
| 項目 | 說明 |
|---|---|
| 流程名稱 | 資安事件處置流程（SOC 團隊版） |
| 流程代碼 | SEC_IR_FLOW_SOC_TEAM，綁定表單 SEC_IR_SOC_TEAM（資安事件處置（SOC 團隊版）） |
| 適用編制 | 3 到 8 人、有輪班的監控中心 |
| 一句話用途 | 高危案件同時開「人工簽核」與「SLA 計時」兩條並行的路；逾時只催辦與升級通報，處置永遠由人決定 |
| 用到的節點 | 開始、寫入欄位、分支、簽核、防禦決策、緊急廣播、暫停、設定變數、結束，共 9 種 |
| 簽核角色 | 一線：資安人員 SECURITY_STAFF；二線：資安主管 SOC_SUPERVISOR |
| 本文用途 | 與外部人士討論 SOC 運作方式時的共同底稿：流程怎麼走、每條線為什麼這樣拉、目前做不到什麼 |
處置流程的形狀取決於「有沒有人在看」，不是事件量。SOC 團隊版的前提是：組織有 3 到 8 位資安人員輪班，案件進來時通常有人在線。這種編制的失敗模式不是「沒有人」，而是「漏看」：案件掛在清單上，每個人都以為別人會處理。
所以這個流程選擇的介入強度是催辦與升級通報，而不是替人做決定。高危案件（嚴重度 4 以上）進來時，流程同時走兩條路：
計時軌從頭到尾不寫任何防禦決策、不動簽核任務。它跑完自己的路就安靜結束；封鎖或放行只會從人按下的那一顆按鈕產生。
| 版本 | 一句話 | 逾時的時候 |
|---|---|---|
| 標準版 SEC_INCIDENT_FLOW | 有人隨時在線、先跑起來再說；SLA 只是處置中心清單上的顯示 | 什麼都不會發生，全靠人盯清單 |
| SOC 團隊版（本篇） | 有輪班但會漏看；用計時軌把「沒人動」變成看得見的事件 | 15 分催辦、30 分通報主管，處置仍由人決定 |
| 小企業單人版 SEC_IR_FLOW_SOLO | 只有一位資安人員、每天 16 小時沒人看；先自動短期封鎖、上班後再複核 | 流程自己寫入有期限的封鎖決策 |
三個流程各自綁一張表單，可以同時存在，由事件路由規則決定哪些案件走哪一個
下圖由建置腳本中的流程定義直接產生：節點位置取自流程設計器畫布上的座標（等比放大），20 個節點與 28 條出線全數畫出。為了讓線不重疊，出線在圖上改走水平與垂直折線；在流程設計器裡它們是直線，連接關係完全相同。
讀圖順序：先看左邊的主幹分流（所有案件都會經過），再看下方的人工處置軌（人在這裡做決定），最後看上方的 SLA 計時軌（只有高危案件會啟動）。整張圖只有一個「結束」，而且只有人工處置軌與低危歸檔會走到它。
案件不是人填表單產生的，而是偵測器送進來的事件自動建立的。從事件到流程啟動之間有五個步驟：
| 步驟 | 平台做什麼 | 對流程的意義 |
|---|---|---|
| step 1 接收 | 偵測器（WAF、入侵偵測等）以 API 金鑰與簽章把事件送到平台。平台接受兩種格式：平台定義的標準事件格式，以及搭配「原生格式設定檔」的來源系統原始格式。同一個事件編號重送不會重複處理。 | 金鑰上設有允許的偵測來源清單，清單外的來源會被拒絕。 |
| step 2 正規化 | 不論哪種格式，都會整理出六個共同欄位：severity_id（嚴重度）、actor_ip（來源位址）、target_host（目標主機）、source_system（偵測來源）、finding_rule_id（規則 ID）、occurred_at（發生時間）。 | 流程的分流條件、封鎖目標、聚合降噪、處置中心的 SLA 顯示都讀這一組欄位。 |
| step 3 路由 | 「開放防禦 ／ 事件路由設定」的規則依優先序由大到小評估，第一條命中的規則決定這個事件用哪一張表單；表單決定流程（取該表單最新的已發行版本）。沒有任何規則命中，事件會被拒收。 | 要讓案件走 SOC 團隊版，就要有一條規則把它導向表單 SEC_IR_SOC_TEAM。示範企業 DemoSOC 的規則是「嚴重度 3 以上走 SOC 團隊版，其餘走標準版」。 |
| step 4 聚合降噪 | 60 分鐘內，同一個來源位址加上同一個規則 ID 的事件，會併進既有案件，不另開新案。一般只併進「仍在進行中」的案件；嚴重度 2 以下的事件連已結案的案件也併。 | 併案時案件的聚合事件數加一、嚴重度取較高者、風險分數重算，但流程不會重新分流。 |
| step 5 建案 | 把事件欄位與情報欄位寫進表單，建立案件並從「開始」節點啟動流程。案件跑的是建案當下那一版已發行流程的快照。 | 之後再修改流程，不影響已經在跑的案件。 |
| 欄位（表單上的名稱） | key | 流程哪裡用到 |
|---|---|---|
| 嚴重度 | severity_id | 「嚴重度分流」的三條規則；低危歸檔註記的文字 |
| 攻擊者 IP | actor_ip | 兩個防禦決策節點的目標值；封鎖完成通報的標題與內文 |
| 事件標題 | finding_title | 防禦決策的理由、三則廣播的標題或內文 |
| 規則 ID | finding_rule_id | 封鎖決策的理由 |
| 情報摘要 | intel_summary | 由流程寫入（情報摘要、低危歸檔註記兩個節點），給簽核者看 |
| 風險分數、建議處置、本案件聚合事件數、24 小時內同源事件數、該 IP 歷史封鎖次數 | risk_score、recommended_action、od_event_count、od_repeat_count、od_history_block_count | 「情報摘要」節點把這五個值組成一段文字 |
五個情報欄位都是建案當下由平台用自己的資料算出來的，不查外部情資：
以下的「T+0」是事件進到平台的時間。流程的每個節點由背景執行器逐一執行，從建案到簽核任務出現大約 20 秒；暫停節點的 15 分鐘從它自己開始執行的那一刻起算，所以下表的分鐘數都是近似值。範例來源位址為 203.0.113.45。
三種情境的前半段相同：
| 時間 | 流程做什麼 | 誰看到什麼 |
|---|---|---|
| T+0 | 開始 → 情報摘要（把五個情報欄位組成一段文字寫進表單）→ 嚴重度分流命中「高危雙軌」規則，兩條出線同時往下走：「一線簽核（高危）」進入等待、「SLA 計時 15 分」開始倒數。 | 案件出現在「資安案件處置中心」，持有資安人員角色的人都看得到、都可以簽。清單上這件案子顯示 15 分鐘的 SLA 倒數（這是清單自己的顯示，與流程的計時軌各算各的）。 |
| 時間 | 人工處置軌 | SLA 計時軌 |
|---|---|---|
| T+6 分 | 一線填寫處置意見（至少 10 個字）並按下「封鎖攻擊來源」。決策值 block 寫入流程變數 soc_decision → 寫入封鎖決策（目標 203.0.113.45、期限 1 小時、執行點 nftables 與 edl）→ 封鎖完成通報 → 結束。流程終態為「已完成」。 | 仍在倒數。 |
| T+15 分 | （已結束） | 暫停節點到期，執行器發現流程已經結束，把這個節點標為取消。「檢查是否已簽核」不會執行，不發任何廣播，也不會留下「準時完成」的標記。 |
如果 T+6 分選的是「升級二線」，人工處置軌會停在「二線處置」等資安主管。此時流程還沒結束，所以 T+15 分計時軌會真的醒來檢查：soc_decision 的值是 escalate、不是空的，判定為「已簽」，走到「準時完成」（把流程變數 sla_track 設為 signed_in_sla）後安靜結束。二線有沒有處理，計時軌不看。
| 時間 | 人工處置軌 | SLA 計時軌 |
|---|---|---|
| T+15 分 | 簽核任務仍在等待，不受影響。 | 暫停到期 → 檢查是否已簽核：soc_decision 是空的，走「逾時」→ SLA 逾時催辦（廣播代碼 SOC-SLA-WARN，對象資安人員，不需確認）→ 再等 15 分開始倒數。 |
| T+22 分 | 一線簽核，依所選決策往下走到結束。 | 仍在倒數。 |
| T+30 分 | （已結束） | 第二個暫停節點到期，流程已結束，節點被取消。「二次檢查」不會執行，不會通報主管。若案件此時還在等二線，則會執行二次檢查、判定「已簽」，走到「催辦後完成」（sla_track = signed_after_warn）。 |
| 時間 | 人工處置軌 | SLA 計時軌 |
|---|---|---|
| T+15 分 | 等待中。 | 發出 SLA 逾時催辦，開始第二段 15 分鐘倒數。 |
| T+30 分 | 等待中。 | 二次檢查：仍是空的，走「仍未簽」→ 升級通報主管（廣播代碼 SOC-SLA-ESCALATE，對象資安主管，需要確認）→ 已升級通報（sla_track = escalated）。計時軌到此結束。 |
| T+30 分之後 | 簽核任務繼續等待，沒有期限。之後任何持有資安人員角色的人簽核，流程照常往下走。 | 不再有任何自動動作。流程不會自動封鎖、不會自動結案、也不會第三次通知。 |
| 時間 | 流程做什麼 | 誰看到什麼 |
|---|---|---|
| T+0 | 開始 → 情報摘要 → 嚴重度分流命中「中危標準簽核」→ 一線簽核（中危）進入等待。不啟動計時軌。 | 案件出現在處置中心，清單顯示 60 分鐘的 SLA 倒數。 |
| 有人簽核時 | 四個決策與高危完全相同：封鎖、放行各接一個防禦決策節點，升級接二線處置，誤判直接結束。 | — |
| T+60 分仍未簽 | 流程不做任何事。 | 處置中心上方統計的「SLA 逾時」數字加一，僅此而已。 |
| 時間 | 流程做什麼 | 誰看到什麼 |
|---|---|---|
| T+0 | 開始 → 情報摘要 → 嚴重度分流命中「低危自動歸檔」→ 低危歸檔註記（把表單的情報摘要欄位改寫成「低危事件（severity N）自動歸檔，未進入人工簽核。」）→ 結束。整個過程在一分鐘內完成。 | 沒有人會收到簽核任務。案件可在處置中心的「已結案」視角查到。 |
注意兩件事：低危歸檔註記與情報摘要寫的是同一個欄位，所以低危案件最後留在表單上的是歸檔註記，情報摘要那段文字會被蓋掉（五個情報欄位的數值仍在）。另外，60 分鐘內同來源、同規則的低危事件會併進同一件已結案的案件，只累加聚合事件數，不會灌出大量歸檔案件。
嚴重度分流的三條規則都是數值或字串比較；欄位缺值或不是數字時，三條比較都視為不成立，改走 fallback：送到「一線簽核（中危）」交給人判斷，之後的路與中危完全相同。
實務上會走到這裡的，是以「原生格式」接進來、而設定檔沒有對應出嚴重度的事件；平台的標準事件格式規定嚴重度必填且為 0 到 6 的整數，缺值的事件在接收階段就會被退回。另外請留意：嚴重度 0 是合法值，它滿足「2 以下」，會被當成低危自動歸檔。
今天先到此，明天會介紹此流程有使用到的所有節點。
如果您之前已經安裝過，今天發表此篇之後更新版本，請使用 install.sh --update更新
iThome鐵人賽
看影片追技術