<?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>NIST on Tarragon</title><link>https://tarrragon.github.io/blog/tags/nist/</link><description>Recent content in NIST 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/nist/index.xml" rel="self" type="application/rss+xml"/><item><title>NIST SP 800-61r3：事故回應作為風險管理能力</title><link>https://tarrragon.github.io/blog/backend/07-security-data-protection/blue-team/materials/professional-sources/nist-sp-800-61r3-incident-response/</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/professional-sources/nist-sp-800-61r3-incident-response/</guid><description>&lt;p>NIST SP 800-61r3 的素材責任是把事故回應放進整體資安風險管理。NIST 在 2025 年 4 月發布 Rev. 3，並說明它取代 2012 年的 Rev. 2，定位為 CSF 2.0 community profile。&lt;/p>
&lt;h2 id="來源定位">來源定位&lt;/h2>
&lt;p>&lt;a href="https://csrc.nist.gov/pubs/sp/800/61/r3/final">NIST SP 800-61 Rev. 3&lt;/a> 適合支撐「事故回應需要跨 Identify、Protect、Detect、Respond、Recover、Govern」的論點。它把 incident response 從單一救火流程，轉成涵蓋治理、偵測、回應與復原的風險管理能力。&lt;/p>
&lt;h2 id="可引用論點">可引用論點&lt;/h2>
&lt;table>
 &lt;thead>
 &lt;tr>
 &lt;th>可引用論點&lt;/th>
 &lt;th>藍隊轉譯&lt;/th>
 &lt;/tr>
 &lt;/thead>
 &lt;tbody>
 &lt;tr>
 &lt;td>事故回應屬於風險管理&lt;/td>
 &lt;td>7.B 可把 incident routing 接到治理例外與 &lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/tripwire/" data-link-title="Tripwire" data-link-desc="說明風險決策在條件變化時如何自動回到評估流程">tripwire&lt;/a>&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>CSF 2.0 六大功能都參與&lt;/td>
 &lt;td>控制面地圖需要同時包含偵測、回應、復原與治理&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>回應效率需要前置準備&lt;/td>
 &lt;td>&lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/runbook/" data-link-title="Runbook" data-link-desc="說明 runbook 如何把事故判斷與操作步驟標準化">runbook&lt;/a>、owner、evidence chain 要在事故前建立&lt;/td>
 &lt;/tr>
 &lt;/tbody>
&lt;/table>
&lt;h2 id="後端服務轉譯">後端服務轉譯&lt;/h2>
&lt;p>後端服務引用這張卡時，重點是把事故回應拆成工程欄位。常見欄位包含 signal、&lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/incident-severity/" data-link-title="Incident Severity" data-link-desc="說明事故分級如何把產品影響轉成對應處置節奏">severity&lt;/a>、owner、&lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/containment/" data-link-title="Containment" data-link-desc="說明事故處理中如何限制擴散面，為回復與驗證爭取時間">containment&lt;/a> action、&lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/rollback-strategy/" data-link-title="Rollback Strategy" data-link-desc="說明事故期間如何判斷回滾、回切與暫停變更">rollback&lt;/a> route、evidence target 與 post-incident write-back。&lt;/p>
&lt;h2 id="引用限制">引用限制&lt;/h2>
&lt;p>NIST 適合提供流程與治理基準，具體控制項仍要回到服務架構轉譯。若文章要討論 API gateway、queue、&lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/artifact-provenance/" data-link-title="Artifact Provenance" data-link-desc="說明交付物的來源、完整性與簽章關聯如何建立信任">artifact&lt;/a> registry 或 database 的細節，需搭配 05/06/08 實作章節補足。&lt;/p></description><content:encoded><![CDATA[<p>NIST SP 800-61r3 的素材責任是把事故回應放進整體資安風險管理。NIST 在 2025 年 4 月發布 Rev. 3，並說明它取代 2012 年的 Rev. 2，定位為 CSF 2.0 community profile。</p>
<h2 id="來源定位">來源定位</h2>
<p><a href="https://csrc.nist.gov/pubs/sp/800/61/r3/final">NIST SP 800-61 Rev. 3</a> 適合支撐「事故回應需要跨 Identify、Protect、Detect、Respond、Recover、Govern」的論點。它把 incident response 從單一救火流程，轉成涵蓋治理、偵測、回應與復原的風險管理能力。</p>
<h2 id="可引用論點">可引用論點</h2>
<table>
  <thead>
      <tr>
          <th>可引用論點</th>
          <th>藍隊轉譯</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td>事故回應屬於風險管理</td>
          <td>7.B 可把 incident routing 接到治理例外與 <a href="/blog/backend/knowledge-cards/tripwire/" data-link-title="Tripwire" data-link-desc="說明風險決策在條件變化時如何自動回到評估流程">tripwire</a></td>
      </tr>
      <tr>
          <td>CSF 2.0 六大功能都參與</td>
          <td>控制面地圖需要同時包含偵測、回應、復原與治理</td>
      </tr>
      <tr>
          <td>回應效率需要前置準備</td>
          <td><a href="/blog/backend/knowledge-cards/runbook/" data-link-title="Runbook" data-link-desc="說明 runbook 如何把事故判斷與操作步驟標準化">runbook</a>、owner、evidence chain 要在事故前建立</td>
      </tr>
  </tbody>
</table>
<h2 id="後端服務轉譯">後端服務轉譯</h2>
<p>後端服務引用這張卡時，重點是把事故回應拆成工程欄位。常見欄位包含 signal、<a href="/blog/backend/knowledge-cards/incident-severity/" data-link-title="Incident Severity" data-link-desc="說明事故分級如何把產品影響轉成對應處置節奏">severity</a>、owner、<a href="/blog/backend/knowledge-cards/containment/" data-link-title="Containment" data-link-desc="說明事故處理中如何限制擴散面，為回復與驗證爭取時間">containment</a> action、<a href="/blog/backend/knowledge-cards/rollback-strategy/" data-link-title="Rollback Strategy" data-link-desc="說明事故期間如何判斷回滾、回切與暫停變更">rollback</a> route、evidence target 與 post-incident write-back。</p>
<h2 id="引用限制">引用限制</h2>
<p>NIST 適合提供流程與治理基準，具體控制項仍要回到服務架構轉譯。若文章要討論 API gateway、queue、<a href="/blog/backend/knowledge-cards/artifact-provenance/" data-link-title="Artifact Provenance" data-link-desc="說明交付物的來源、完整性與簽章關聯如何建立信任">artifact</a> registry 或 database 的細節，需搭配 05/06/08 實作章節補足。</p>
]]></content:encoded></item></channel></rss>