Control Mapping on Tarragonhttps://tarrragon.github.io/blog/tags/control-mapping/Recent content in Control Mapping on TarragonHugo -- gohugo.iozh-TWTarragon (CC BY 4.0)Thu, 30 Apr 2026 00:00:00 +00007.B8 Defensive Vocabulary Maphttps://tarrragon.github.io/blog/backend/07-security-data-protection/blue-team/defensive-vocabulary-map/Thu, 30 Apr 2026 00:00:00 +0000https://tarrragon.github.io/blog/backend/07-security-data-protection/blue-team/defensive-vocabulary-map/<p>本篇的責任是建立 defensive vocabulary map。讀者讀完後，能用一致詞彙描述控制面能力、偵測責任與交接欄位。</p> <h2 id="核心論點">核心論點</h2> <p>Defensive vocabulary map 的核心概念是用共用詞彙降低跨團隊摩擦。詞彙一旦一致，規則設計、事件交接與演練回寫都能更快收斂。</p> <h2 id="讀者入口">讀者入口</h2> <p>本篇適合銜接 <a href="https://tarrragon.github.io/blog/backend/07-security-data-protection/blue-team/defense-control-map/" data-link-title="7.B1 防守控制面地圖" data-link-desc="建立防守控制面如何對應身份、入口、資料、供應鏈、偵測與治理問題的大綱">7.B1 防守控制面地圖</a>、<a href="https://tarrragon.github.io/blog/backend/07-security-data-protection/blue-team/materials/professional-sources/mitre-d3fend-defense-vocabulary/" data-link-title="MITRE D3FEND：防守技術詞彙地圖" data-link-desc="把 MITRE D3FEND 轉成藍隊控制面與防守技術詞彙素材">MITRE D3FEND</a> 與 <a href="https://tarrragon.github.io/blog/backend/knowledge-cards/trust-boundary/" data-link-title="Trust Boundary" data-link-desc="說明系統哪些位置開始不能沿用原本的信任假設">trust boundary</a>。</p> <h2 id="詞彙地圖欄位">詞彙地圖欄位</h2> <table> <thead> <tr> <th>欄位</th> <th>責任</th> <th>產出</th> </tr> </thead> <tbody> <tr> <td>Term</td> <td>定義防守技術名稱</td> <td>vocabulary entry</td> </tr> <tr> <td>Scope</td> <td>說明技術作用範圍</td> <td>boundary note</td> </tr> <tr> <td>Signal</td> <td>對應可觀測訊號</td> <td>signal mapping</td> </tr> <tr> <td>Owner</td> <td>對應主責角色</td> <td>owner mapping</td> </tr> <tr> <td>Evidence</td> <td>對應驗證證據</td> <td>evidence mapping</td> </tr> <tr> <td>Handoff</td> <td>對應交接章節</td> <td>routing link</td> </tr> </tbody> </table> <h2 id="詞彙分層">詞彙分層</h2> <p>詞彙分層的責任是避免同詞多義。建議至少分三層：</p> <ol> <li>Control term：描述防守能力。</li> <li>Detection term：描述訊號與規則。</li> <li>Response term：描述分級、處置與回寫。</li> </ol> <h2 id="邊界對齊">邊界對齊</h2> <p>邊界對齊的責任是讓詞彙對上服務邊界。每個詞彙都要能回答它作用在哪個 trust boundary、影響哪種資產、由哪個 owner 維護。</p> <h2 id="與規則生命周期整合">與規則生命周期整合</h2> <p>與規則生命周期整合的責任是把詞彙直接接到規則資產。詞彙卡可對應到 rule source、triage question、severity 與 evidence，形成可追溯的維護鏈。</p> <h2 id="判讀訊號與路由">判讀訊號與路由</h2> <table> <thead> <tr> <th>判讀訊號</th> <th>代表需求</th> <th>下一步路由</th> </tr> </thead> <tbody> <tr> <td>同一事件在不同團隊有不同命名</td> <td>需要統一詞彙地圖</td> <td>7.B8 → 7.B1</td> </tr> <tr> <td>規則描述與控制描述尚未對齊</td> <td>需要補 term-to-rule 映射</td> <td>7.B8 → 7.B5</td> </tr> <tr> <td>交接文件使用抽象詞彙</td> <td>需要補邊界與證據欄位</td> <td>7.B8 → 7.B6</td> </tr> <tr> <td>演練回寫尚未回到章節</td> <td>需要補 handoff 欄位</td> <td>7.B8 → 7.B9</td> </tr> </tbody> </table> <h2 id="必連章節">必連章節</h2> <ul> <li><a href="https://tarrragon.github.io/blog/backend/07-security-data-protection/blue-team/defense-control-map/" data-link-title="7.B1 防守控制面地圖" data-link-desc="建立防守控制面如何對應身份、入口、資料、供應鏈、偵測與治理問題的大綱">7.B1 防守控制面地圖</a></li> <li><a href="https://tarrragon.github.io/blog/backend/07-security-data-protection/blue-team/detection-engineering-lifecycle/" data-link-title="7.B5 Detection Engineering Lifecycle" data-link-desc="把偵測規則視為可維護資產，建立從來源、測試、調校到退場的完整生命週期">7.B5 Detection Engineering Lifecycle</a></li> <li><a href="https://tarrragon.github.io/blog/backend/07-security-data-protection/blue-team/incident-triage-loop/" data-link-title="7.B6 Incident Triage Loop" data-link-desc="把資安訊號轉成 triage、severity、owner、containment 與 evidence 的回應循環">7.B6 Incident Triage Loop</a></li> <li><a href="https://tarrragon.github.io/blog/backend/07-security-data-protection/blue-team/materials/professional-sources/" data-link-title="7.BM1 藍隊專業來源卡" data-link-desc="整理藍隊可引用的專業來源，明確標示可支撐論點與引用限制">7.BM1 藍隊專業來源卡</a></li> </ul> <h2 id="完稿判準">完稿判準</h2> <p>完稿時要讓讀者能把防守詞彙寫成可交接地圖。輸出至少包含 term、scope、signal、owner、evidence 與 handoff。</p>本篇的責任是建立 defensive vocabulary map。讀者讀完後，能用一致詞彙描述控制面能力、偵測責任與交接欄位。

核心論點

Defensive vocabulary map 的核心概念是用共用詞彙降低跨團隊摩擦。詞彙一旦一致，規則設計、事件交接與演練回寫都能更快收斂。

讀者入口

本篇適合銜接 7.B1 防守控制面地圖、MITRE D3FEND 與 trust boundary。

詞彙地圖欄位

欄位 責任 產出
Term 定義防守技術名稱 vocabulary entry
Scope 說明技術作用範圍 boundary note
Signal 對應可觀測訊號 signal mapping
Owner 對應主責角色 owner mapping
Evidence 對應驗證證據 evidence mapping
Handoff 對應交接章節 routing link

詞彙分層

詞彙分層的責任是避免同詞多義。建議至少分三層：

  1. Control term：描述防守能力。
  2. Detection term：描述訊號與規則。
  3. Response term：描述分級、處置與回寫。

邊界對齊

邊界對齊的責任是讓詞彙對上服務邊界。每個詞彙都要能回答它作用在哪個 trust boundary、影響哪種資產、由哪個 owner 維護。

與規則生命周期整合

與規則生命周期整合的責任是把詞彙直接接到規則資產。詞彙卡可對應到 rule source、triage question、severity 與 evidence，形成可追溯的維護鏈。

判讀訊號與路由

判讀訊號 代表需求 下一步路由
同一事件在不同團隊有不同命名 需要統一詞彙地圖 7.B8 → 7.B1
規則描述與控制描述尚未對齊 需要補 term-to-rule 映射 7.B8 → 7.B5
交接文件使用抽象詞彙 需要補邊界與證據欄位 7.B8 → 7.B6
演練回寫尚未回到章節 需要補 handoff 欄位 7.B8 → 7.B9

必連章節

完稿判準

完稿時要讓讀者能把防守詞彙寫成可交接地圖。輸出至少包含 term、scope、signal、owner、evidence 與 handoff。

]]>