<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Security Materials on Tarragon</title><link>https://tarrragon.github.io/blog/tags/security-materials/</link><description>Recent content in Security Materials on Tarragon</description><generator>Hugo -- gohugo.io</generator><language>zh-TW</language><copyright>Tarragon (CC BY 4.0)</copyright><lastBuildDate>Thu, 30 Apr 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://tarrragon.github.io/blog/tags/security-materials/index.xml" rel="self" type="application/rss+xml"/><item><title>7.BM 藍隊素材庫</title><link>https://tarrragon.github.io/blog/backend/07-security-data-protection/blue-team/materials/</link><pubDate>Thu, 30 Apr 2026 00:00:00 +0000</pubDate><guid>https://tarrragon.github.io/blog/backend/07-security-data-protection/blue-team/materials/</guid><description>&lt;p>藍隊素材庫的責任是提供防守推演的可回溯證據。素材庫把專業來源、現場案例、演練情境與控制模式分層整理，讓後續文章能從可靠材料延伸，並降低單一事故敘事的依賴。&lt;/p>
&lt;h2 id="素材分層">素材分層&lt;/h2>
&lt;table>
 &lt;thead>
 &lt;tr>
 &lt;th>分層&lt;/th>
 &lt;th>責任&lt;/th>
 &lt;th>使用時機&lt;/th>
 &lt;/tr>
 &lt;/thead>
 &lt;tbody>
 &lt;tr>
 &lt;td>Professional sources&lt;/td>
 &lt;td>建立藍隊詞彙、流程與驗證基準&lt;/td>
 &lt;td>寫控制面、偵測、事故流程時引用&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>Field cases&lt;/td>
 &lt;td>補充攻防事件中的防守壓力與決策節點&lt;/td>
 &lt;td>設計案例推演與 tabletop 時引用&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>Scenarios&lt;/td>
 &lt;td>把來源與案例轉成可演練的服務情境&lt;/td>
 &lt;td>寫 Game Day 與 &lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/runbook/" data-link-title="Runbook" data-link-desc="說明 runbook 如何把事故判斷與操作步驟標準化">runbook&lt;/a> 時引用&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>Control patterns&lt;/td>
 &lt;td>把重複出現的防守做法整理成可搬運模式&lt;/td>
 &lt;td>寫 &lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/release-gate/" data-link-title="Release Gate" data-link-desc="說明變更在正式釋出前如何通過或阻擋">release gate&lt;/a> 與驗證規則時引用&lt;/td>
 &lt;/tr>
 &lt;/tbody>
&lt;/table>
&lt;p>素材分層的核心是讓來源、推演與文章分工清楚。Professional sources 提供判讀語言，field cases 提供現場壓力，scenarios 提供演練路徑，control patterns 提供工程化重用。&lt;/p>
&lt;h2 id="使用路由">使用路由&lt;/h2>
&lt;p>藍隊文章引用素材時先選來源層級、並在引用前確認來源與當下文章主題的對應關係。下表是條件式對應、不是無條件 universal 推薦：&lt;/p>
&lt;table>
 &lt;thead>
 &lt;tr>
 &lt;th>文章主題&lt;/th>
 &lt;th>適合優先引用&lt;/th>
 &lt;th>適合場景&lt;/th>
 &lt;th>不適合場景&lt;/th>
 &lt;/tr>
 &lt;/thead>
 &lt;tbody>
 &lt;tr>
 &lt;td>流程 / 治理基準&lt;/td>
 &lt;td>NIST CSF、NIST SP 800 系列&lt;/td>
 &lt;td>政策層、合規對齊、跨組織共通語言&lt;/td>
 &lt;td>具體偵測規則 / IoC（NIST 不深入到 detection content layer）&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>處置建議 / 跨機構協作&lt;/td>
 &lt;td>CISA advisory、CISA KEV&lt;/td>
 &lt;td>重大事件期間的處置時序、KEV 列入、公部門協作&lt;/td>
 &lt;td>平時穩定流程設計（CISA advisory 是事件驅動、節奏跟長期 baseline 不同）&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>防守技術詞彙 / 對抗能力對照&lt;/td>
 &lt;td>MITRE D3FEND、MITRE ATT&amp;amp;CK&lt;/td>
 &lt;td>對抗矩陣、控制能力對照、紅藍對齊語言&lt;/td>
 &lt;td>具體 tooling 配置 / vendor-specific 設定&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>偵測規則格式 / 生命週期&lt;/td>
 &lt;td>Sigma、SANS detection 教材&lt;/td>
 &lt;td>規則格式、test event、retirement 流程設計&lt;/td>
 &lt;td>政策對齊 / 合規語言（detection content 不是 governance layer）&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>現場壓力 / 職能趨勢 / TTP&lt;/td>
 &lt;td>Mandiant、Crowdstrike 報告&lt;/td>
 &lt;td>補事件案例、actor TTP、telemetry 視角&lt;/td>
 &lt;td>標準化基準（廠商報告各有觀察偏差、不適合當 single source of truth）&lt;/td>
 &lt;/tr>
 &lt;/tbody>
&lt;/table>
&lt;p>引用前的 verifiability check：「此來源原文有沒有 conditional scope？我引用時有沒有保留？」——避免把 NIST 的 organizational risk discussion 引成 universal mandate、把 MITRE 的 abstract technique 引成 specific tool requirement。&lt;/p>
&lt;h2 id="反向驗證">反向驗證&lt;/h2>
&lt;p>素材庫的反向驗證責任是提醒作者區分「來源能支撐什麼」與「來源需要在本章轉譯什麼」：&lt;/p>
&lt;ul>
&lt;li>&lt;strong>NIST / CISA&lt;/strong>：適合支撐流程基準與處置建議、不適合直接生成 detection rule 內容。原文常是 organizational-level guidance、轉譯到 service-level 時要明示 deployment scope。&lt;/li>
&lt;li>&lt;strong>MITRE D3FEND / ATT&amp;amp;CK&lt;/strong>：適合支撐威脅導向與防守詞彙、不適合直接當 implementation checklist。Technique-level 描述需要在文章補 product-specific mechanism。&lt;/li>
&lt;li>&lt;strong>Sigma&lt;/strong>：適合支撐偵測規則格式、不適合當完整的 detection coverage map。單一規則的有效性 depends on log source / parser 一致性。&lt;/li>
&lt;li>&lt;strong>Mandiant / SANS&lt;/strong>：適合支撐現場壓力與職能趨勢、不適合當 universal baseline。廠商視角受客戶基數 / 行業組成偏差影響。&lt;/li>
&lt;/ul>
&lt;p>每個素材的 last-checked 與適用範圍變動風險、由各 source 卡片在 professional-sources 子分類各自記錄。&lt;/p>
&lt;h2 id="子分類">子分類&lt;/h2>
&lt;table>
 &lt;thead>
 &lt;tr>
 &lt;th>子分類&lt;/th>
 &lt;th>責任&lt;/th>
 &lt;th>初始狀態&lt;/th>
 &lt;/tr>
 &lt;/thead>
 &lt;tbody>
 &lt;tr>
 &lt;td>&lt;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="整理藍隊可引用的專業來源，明確標示可支撐論點與引用限制">Professional sources&lt;/a>&lt;/td>
 &lt;td>專業來源卡與引用限制&lt;/td>
 &lt;td>先建立七張來源卡&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="https://tarrragon.github.io/blog/backend/07-security-data-protection/blue-team/materials/field-cases/" data-link-title="7.BM2 藍隊現場案例素材" data-link-desc="定義藍隊現場案例的收錄規則，支援後續防守推演與控制面補強">Field cases&lt;/a>&lt;/td>
 &lt;td>藍隊現場案例與事件壓力&lt;/td>
 &lt;td>已收錄 11 張案例&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="https://tarrragon.github.io/blog/backend/07-security-data-protection/blue-team/materials/scenarios/" data-link-title="7.BM3 藍隊推演情境素材" data-link-desc="定義藍隊推演情境模板，協助把來源與案例轉成 tabletop 與 Game Day">Scenarios&lt;/a>&lt;/td>
 &lt;td>Tabletop 與 Game Day 情境素材&lt;/td>
 &lt;td>已收錄 4 張情境&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="https://tarrragon.github.io/blog/backend/07-security-data-protection/blue-team/materials/control-patterns/" data-link-title="7.BM4 藍隊控制模式素材" data-link-desc="定義藍隊控制模式分類，支援 release gate、偵測驗證與事故交接">Control patterns&lt;/a>&lt;/td>
 &lt;td>控制面模式與驗證模式&lt;/td>
 &lt;td>已收錄 7 張模式&lt;/td>
 &lt;/tr>
 &lt;/tbody>
&lt;/table>
&lt;h2 id="推演資產化大綱">推演資產化大綱&lt;/h2>
&lt;table>
 &lt;thead>
 &lt;tr>
 &lt;th>順序&lt;/th>
 &lt;th>素材層&lt;/th>
 &lt;th>預計產出&lt;/th>
 &lt;th>使用方式&lt;/th>
 &lt;/tr>
 &lt;/thead>
 &lt;tbody>
 &lt;tr>
 &lt;td>1&lt;/td>
 &lt;td>Field cases&lt;/td>
 &lt;td>11 張現場案例卡(含變體)&lt;/td>
 &lt;td>抽出 defender pressure、control gap、detection route&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>2&lt;/td>
 &lt;td>Scenarios&lt;/td>
 &lt;td>4 張推演情境卡&lt;/td>
 &lt;td>組成 tabletop、Game Day 與 incident handoff 演練&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>3&lt;/td>
 &lt;td>Control patterns&lt;/td>
 &lt;td>7 張控制模式卡&lt;/td>
 &lt;td>提供 release gate、evidence chain、owner、credential、recovery 與 write-back 欄位&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>4&lt;/td>
 &lt;td>Write-back&lt;/td>
 &lt;td>已回寫 &lt;code>7.B1&lt;/code>、&lt;code>7.B9&lt;/code>、&lt;code>7.B12&lt;/code>、&lt;code>7.24&lt;/code>&lt;/td>
 &lt;td>讓素材回到文章主路由與實作交接&lt;/td>
 &lt;/tr>
 &lt;/tbody>
&lt;/table>
&lt;p>比例設計參考 &lt;a href="https://tarrragon.github.io/blog/report/source-library-ratio-supports-scenario-validation/" data-link-title="素材庫比例要支撐主情境的反向驗證" data-link-desc="當文章只展示少量主情境時，素材庫需要保留更多 field cases 或 source cards 來支撐反向驗證、壓力變體與後續擴寫。合理比例是主文章情境 4-5 個、來源素材約 2-3 倍，讓每個主情境背後至少有 2-3 個來源可回查。">素材庫比例支撐主情境的反向驗證&lt;/a>:主情境 4 個、來源 2-3 倍、scenario 4-5 張、pattern 5-7 張。素材庫已達上述上限,進入穩定維護狀態。&lt;/p></description><content:encoded><![CDATA[<p>藍隊素材庫的責任是提供防守推演的可回溯證據。素材庫把專業來源、現場案例、演練情境與控制模式分層整理，讓後續文章能從可靠材料延伸，並降低單一事故敘事的依賴。</p>
<h2 id="素材分層">素材分層</h2>
<table>
  <thead>
      <tr>
          <th>分層</th>
          <th>責任</th>
          <th>使用時機</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td>Professional sources</td>
          <td>建立藍隊詞彙、流程與驗證基準</td>
          <td>寫控制面、偵測、事故流程時引用</td>
      </tr>
      <tr>
          <td>Field cases</td>
          <td>補充攻防事件中的防守壓力與決策節點</td>
          <td>設計案例推演與 tabletop 時引用</td>
      </tr>
      <tr>
          <td>Scenarios</td>
          <td>把來源與案例轉成可演練的服務情境</td>
          <td>寫 Game Day 與 <a href="/blog/backend/knowledge-cards/runbook/" data-link-title="Runbook" data-link-desc="說明 runbook 如何把事故判斷與操作步驟標準化">runbook</a> 時引用</td>
      </tr>
      <tr>
          <td>Control patterns</td>
          <td>把重複出現的防守做法整理成可搬運模式</td>
          <td>寫 <a href="/blog/backend/knowledge-cards/release-gate/" data-link-title="Release Gate" data-link-desc="說明變更在正式釋出前如何通過或阻擋">release gate</a> 與驗證規則時引用</td>
      </tr>
  </tbody>
</table>
<p>素材分層的核心是讓來源、推演與文章分工清楚。Professional sources 提供判讀語言，field cases 提供現場壓力，scenarios 提供演練路徑，control patterns 提供工程化重用。</p>
<h2 id="使用路由">使用路由</h2>
<p>藍隊文章引用素材時先選來源層級、並在引用前確認來源與當下文章主題的對應關係。下表是條件式對應、不是無條件 universal 推薦：</p>
<table>
  <thead>
      <tr>
          <th>文章主題</th>
          <th>適合優先引用</th>
          <th>適合場景</th>
          <th>不適合場景</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td>流程 / 治理基準</td>
          <td>NIST CSF、NIST SP 800 系列</td>
          <td>政策層、合規對齊、跨組織共通語言</td>
          <td>具體偵測規則 / IoC（NIST 不深入到 detection content layer）</td>
      </tr>
      <tr>
          <td>處置建議 / 跨機構協作</td>
          <td>CISA advisory、CISA KEV</td>
          <td>重大事件期間的處置時序、KEV 列入、公部門協作</td>
          <td>平時穩定流程設計（CISA advisory 是事件驅動、節奏跟長期 baseline 不同）</td>
      </tr>
      <tr>
          <td>防守技術詞彙 / 對抗能力對照</td>
          <td>MITRE D3FEND、MITRE ATT&amp;CK</td>
          <td>對抗矩陣、控制能力對照、紅藍對齊語言</td>
          <td>具體 tooling 配置 / vendor-specific 設定</td>
      </tr>
      <tr>
          <td>偵測規則格式 / 生命週期</td>
          <td>Sigma、SANS detection 教材</td>
          <td>規則格式、test event、retirement 流程設計</td>
          <td>政策對齊 / 合規語言（detection content 不是 governance layer）</td>
      </tr>
      <tr>
          <td>現場壓力 / 職能趨勢 / TTP</td>
          <td>Mandiant、Crowdstrike 報告</td>
          <td>補事件案例、actor TTP、telemetry 視角</td>
          <td>標準化基準（廠商報告各有觀察偏差、不適合當 single source of truth）</td>
      </tr>
  </tbody>
</table>
<p>引用前的 verifiability check：「此來源原文有沒有 conditional scope？我引用時有沒有保留？」——避免把 NIST 的 organizational risk discussion 引成 universal mandate、把 MITRE 的 abstract technique 引成 specific tool requirement。</p>
<h2 id="反向驗證">反向驗證</h2>
<p>素材庫的反向驗證責任是提醒作者區分「來源能支撐什麼」與「來源需要在本章轉譯什麼」：</p>
<ul>
<li><strong>NIST / CISA</strong>：適合支撐流程基準與處置建議、不適合直接生成 detection rule 內容。原文常是 organizational-level guidance、轉譯到 service-level 時要明示 deployment scope。</li>
<li><strong>MITRE D3FEND / ATT&amp;CK</strong>：適合支撐威脅導向與防守詞彙、不適合直接當 implementation checklist。Technique-level 描述需要在文章補 product-specific mechanism。</li>
<li><strong>Sigma</strong>：適合支撐偵測規則格式、不適合當完整的 detection coverage map。單一規則的有效性 depends on log source / parser 一致性。</li>
<li><strong>Mandiant / SANS</strong>：適合支撐現場壓力與職能趨勢、不適合當 universal baseline。廠商視角受客戶基數 / 行業組成偏差影響。</li>
</ul>
<p>每個素材的 last-checked 與適用範圍變動風險、由各 source 卡片在 professional-sources 子分類各自記錄。</p>
<h2 id="子分類">子分類</h2>
<table>
  <thead>
      <tr>
          <th>子分類</th>
          <th>責任</th>
          <th>初始狀態</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td><a href="/blog/backend/07-security-data-protection/blue-team/materials/professional-sources/" data-link-title="7.BM1 藍隊專業來源卡" data-link-desc="整理藍隊可引用的專業來源，明確標示可支撐論點與引用限制">Professional sources</a></td>
          <td>專業來源卡與引用限制</td>
          <td>先建立七張來源卡</td>
      </tr>
      <tr>
          <td><a href="/blog/backend/07-security-data-protection/blue-team/materials/field-cases/" data-link-title="7.BM2 藍隊現場案例素材" data-link-desc="定義藍隊現場案例的收錄規則，支援後續防守推演與控制面補強">Field cases</a></td>
          <td>藍隊現場案例與事件壓力</td>
          <td>已收錄 11 張案例</td>
      </tr>
      <tr>
          <td><a href="/blog/backend/07-security-data-protection/blue-team/materials/scenarios/" data-link-title="7.BM3 藍隊推演情境素材" data-link-desc="定義藍隊推演情境模板，協助把來源與案例轉成 tabletop 與 Game Day">Scenarios</a></td>
          <td>Tabletop 與 Game Day 情境素材</td>
          <td>已收錄 4 張情境</td>
      </tr>
      <tr>
          <td><a href="/blog/backend/07-security-data-protection/blue-team/materials/control-patterns/" data-link-title="7.BM4 藍隊控制模式素材" data-link-desc="定義藍隊控制模式分類，支援 release gate、偵測驗證與事故交接">Control patterns</a></td>
          <td>控制面模式與驗證模式</td>
          <td>已收錄 7 張模式</td>
      </tr>
  </tbody>
</table>
<h2 id="推演資產化大綱">推演資產化大綱</h2>
<table>
  <thead>
      <tr>
          <th>順序</th>
          <th>素材層</th>
          <th>預計產出</th>
          <th>使用方式</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td>1</td>
          <td>Field cases</td>
          <td>11 張現場案例卡(含變體)</td>
          <td>抽出 defender pressure、control gap、detection route</td>
      </tr>
      <tr>
          <td>2</td>
          <td>Scenarios</td>
          <td>4 張推演情境卡</td>
          <td>組成 tabletop、Game Day 與 incident handoff 演練</td>
      </tr>
      <tr>
          <td>3</td>
          <td>Control patterns</td>
          <td>7 張控制模式卡</td>
          <td>提供 release gate、evidence chain、owner、credential、recovery 與 write-back 欄位</td>
      </tr>
      <tr>
          <td>4</td>
          <td>Write-back</td>
          <td>已回寫 <code>7.B1</code>、<code>7.B9</code>、<code>7.B12</code>、<code>7.24</code></td>
          <td>讓素材回到文章主路由與實作交接</td>
      </tr>
  </tbody>
</table>
<p>比例設計參考 <a href="/blog/report/source-library-ratio-supports-scenario-validation/" data-link-title="素材庫比例要支撐主情境的反向驗證" data-link-desc="當文章只展示少量主情境時，素材庫需要保留更多 field cases 或 source cards 來支撐反向驗證、壓力變體與後續擴寫。合理比例是主文章情境 4-5 個、來源素材約 2-3 倍，讓每個主情境背後至少有 2-3 個來源可回查。">素材庫比例支撐主情境的反向驗證</a>:主情境 4 個、來源 2-3 倍、scenario 4-5 張、pattern 5-7 張。素材庫已達上述上限,進入穩定維護狀態。</p>
<h2 id="下一步路由">下一步路由</h2>
<p>素材庫先服務 <a href="/blog/backend/07-security-data-protection/blue-team/defense-control-map/" data-link-title="7.B1 防守控制面地圖" data-link-desc="建立防守控制面如何對應身份、入口、資料、供應鏈、偵測與治理問題的大綱">7.B1 防守控制面地圖</a>、<a href="/blog/backend/07-security-data-protection/blue-team/detection-to-response-routing/" data-link-title="7.B2 從偵測到回應的路由" data-link-desc="建立資安偵測訊號如何轉成 triage、severity、升級與 incident workflow 的大綱">7.B2 偵測到回應的路由</a> 與 <a href="/blog/backend/07-security-data-protection/blue-team/tabletop-and-game-day-design/" data-link-title="7.B4 Tabletop 與 Game Day 設計" data-link-desc="建立藍隊如何設計 tabletop exercise 與 game day 的大綱">7.B4 Tabletop 與 Game Day</a>。後續每新增一篇藍隊文章，都要回到本素材庫補來源、情境或控制模式。</p>
]]></content:encoded></item></channel></rss>