Risk Acceptance on Tarragonhttps://tarrragon.github.io/blog/tags/risk-acceptance/Recent content in Risk Acceptance on TarragonHugo -- gohugo.iozh-TWTarragon (CC BY 4.0)Thu, 30 Apr 2026 00:00:00 +0000Security Exceptionhttps://tarrragon.github.io/blog/backend/knowledge-cards/security-exception/Thu, 30 Apr 2026 00:00:00 +0000https://tarrragon.github.io/blog/backend/knowledge-cards/security-exception/<p>Security exception 的核心概念是「在明確邊界內接受短期風險，並用協議管理收斂路徑」。它讓風險接受決策可追蹤、可關閉、可回寫。 可先對照 <a href="https://tarrragon.github.io/blog/backend/knowledge-cards/release-gate/" data-link-title="Release Gate" data-link-desc="說明變更在正式釋出前如何通過或阻擋">Release Gate</a>。</p> <h2 id="概念位置">概念位置</h2> <p>Security exception 位在 <a href="https://tarrragon.github.io/blog/backend/knowledge-cards/release-gate/" data-link-title="Release Gate" data-link-desc="說明變更在正式釋出前如何通過或阻擋">Release Gate</a>、<a href="https://tarrragon.github.io/blog/backend/knowledge-cards/release-freeze/" data-link-title="Release Freeze" data-link-desc="說明高風險期間如何以凍結策略保護正式環境">Release Freeze</a> 與 <a href="https://tarrragon.github.io/blog/backend/knowledge-cards/tripwire/" data-link-title="Tripwire" data-link-desc="說明風險決策在條件變化時如何自動回到評估流程">Tripwire</a> 之間。它承接治理層決策，並把決策資訊交給部署與 incident workflow。</p> <h2 id="可觀察訊號">可觀察訊號</h2> <p>系統需要 security exception 的訊號是：</p> <ul> <li>修補窗口與業務時程暫時不一致</li> <li>高風險項目需要短期過渡方案</li> <li>團隊需要紀錄接受範圍與期限</li> <li>關閉條件需要跨角色共識與可驗證證據</li> </ul> <h2 id="接近真實網路服務的例子">接近真實網路服務的例子</h2> <p>新漏洞公告後，某服務在修補完成前以例外方式允許受控上線，同步啟用補償控制（流量限制、額外審計、強化告警），並設定到期日與重評估會議時間。</p> <h2 id="設計責任">設計責任</h2> <p>Security exception 要定義 risk scope、expiry、compensating controls、owner、close criteria 與 write-back target。例外成立的同時，也要同步設計關閉節奏與回寫路徑。</p>Security exception 的核心概念是「在明確邊界內接受短期風險，並用協議管理收斂路徑」。它讓風險接受決策可追蹤、可關閉、可回寫。 可先對照 Release Gate。

概念位置

Security exception 位在 Release Gate、Release Freeze 與 Tripwire 之間。它承接治理層決策，並把決策資訊交給部署與 incident workflow。

可觀察訊號

系統需要 security exception 的訊號是：

  • 修補窗口與業務時程暫時不一致
  • 高風險項目需要短期過渡方案
  • 團隊需要紀錄接受範圍與期限
  • 關閉條件需要跨角色共識與可驗證證據

接近真實網路服務的例子

新漏洞公告後，某服務在修補完成前以例外方式允許受控上線，同步啟用補償控制（流量限制、額外審計、強化告警），並設定到期日與重評估會議時間。

設計責任

Security exception 要定義 risk scope、expiry、compensating controls、owner、close criteria 與 write-back target。例外成立的同時，也要同步設計關閉節奏與回寫路徑。

]]>7.R11.P18 例外缺少期限與關閉條件https://tarrragon.github.io/blog/backend/07-security-data-protection/red-team/problem-cards/fp-exception-without-expiry/Thu, 30 Apr 2026 00:00:00 +0000https://tarrragon.github.io/blog/backend/07-security-data-protection/red-team/problem-cards/fp-exception-without-expiry/<p>這個失效樣式的核心問題是風險例外只有批准結果，沒有到期與關閉邊界。當例外缺少期限與關閉條件，暫時接受的風險會長期停留在正式路徑，並削弱 <a href="https://tarrragon.github.io/blog/backend/knowledge-cards/containment/" data-link-title="Containment" data-link-desc="說明事故處理中如何限制擴散面，為回復與驗證爭取時間">containment</a> 節奏。</p> <h2 id="常見形成條件">常見形成條件</h2> <ul> <li>例外申請缺少量化關閉條件。</li> <li>例外期間缺少補償控制與監測 <a href="https://tarrragon.github.io/blog/backend/knowledge-cards/runbook/" data-link-title="Runbook" data-link-desc="說明 runbook 如何把事故判斷與操作步驟標準化">runbook</a>。</li> <li>重大事件發生後沒有觸發例外重審。</li> </ul> <h2 id="判讀訊號">判讀訊號</h2> <ul> <li>例外決策長期存續且無重評估記錄。</li> <li>例外到期後仍自動延長。</li> <li>關鍵風險指標變化時例外狀態沒有同步調整與 <a href="https://tarrragon.github.io/blog/backend/knowledge-cards/incident-timeline/" data-link-title="Incident Timeline" data-link-desc="說明事故時間線如何支援判斷、溝通與復盤">incident timeline</a> 回寫。</li> </ul> <h2 id="案例觸發參考">案例觸發參考</h2> <ul> <li><a href="https://tarrragon.github.io/blog/backend/07-security-data-protection/red-team/cases/edge-exposure/panos-cve-2024-3400-edge-rce/" data-link-title="7.R7.3.4 PAN-OS 2024：邊界設備遠端命令執行" data-link-desc="邊界設備 RCE 事件如何迫使團隊在修補與營運可用性間快速取捨">PAN-OS 2024</a></li> <li><a href="https://tarrragon.github.io/blog/backend/07-security-data-protection/red-team/cases/supply-chain/xz-backdoor-2024-open-source-supply-chain/" data-link-title="7.R7.2.4 XZ Backdoor 2024：開源供應鏈長期滲透" data-link-desc="開源維護鏈遭滲透後，為何會直接影響廣泛 Linux 發行流程">XZ 2024</a></li> <li><a href="https://tarrragon.github.io/blog/backend/07-security-data-protection/red-team/cases/identity-access/uber-2022-mfa-fatigue/" data-link-title="7.R7.1.1 Uber 2022：MFA 疲勞與內部工具擴散" data-link-desc="從社交工程到內部工具存取，拆解身分流程與權限邊界的失效點">Uber 2022</a></li> </ul> <h2 id="來源流程卡">來源流程卡</h2> <ul> <li><a href="https://tarrragon.github.io/blog/backend/07-security-data-protection/red-team/problem-cards/plan-change-flow-abuse/" data-link-title="7.R11.7 方案升降級流程濫用" data-link-desc="說明方案切換流程為何容易成為權限與資源邊界繞過點">方案升降級流程濫用</a></li> </ul> <h2 id="下一步路由">下一步路由</h2> <p>本失效樣式對應的實作 chain：</p> <p><strong>控制面（mitigation 在這裡定義）</strong>：</p> <ul> <li><a href="https://tarrragon.github.io/blog/backend/07-security-data-protection/security-routing-from-case-to-service/" data-link-title="7.8 模組路由：問題到服務實作" data-link-desc="整理問題節點如何路由到部署、可靠性與事故處理章節">7.13 安全事件路由</a></li> </ul> <p><strong>演練 / 控制落地（轉成欄位）</strong>：</p> <ul> <li><a href="https://tarrragon.github.io/blog/backend/07-security-data-protection/blue-team/materials/control-patterns/exercise-write-back-pattern/" data-link-title="Exercise Write-back Pattern" data-link-desc="定義 tabletop 與 game day 如何把 finding 回寫成控制更新、runbook 更新與 [tripwire](/backend/knowledge-cards/tripwire/)">Exercise write-back pattern</a></li> </ul>這個失效樣式的核心問題是風險例外只有批准結果，沒有到期與關閉邊界。當例外缺少期限與關閉條件，暫時接受的風險會長期停留在正式路徑，並削弱 containment 節奏。

常見形成條件

  • 例外申請缺少量化關閉條件。
  • 例外期間缺少補償控制與監測 runbook。
  • 重大事件發生後沒有觸發例外重審。

判讀訊號

  • 例外決策長期存續且無重評估記錄。
  • 例外到期後仍自動延長。
  • 關鍵風險指標變化時例外狀態沒有同步調整與 incident timeline 回寫。

案例觸發參考

來源流程卡

下一步路由

本失效樣式對應的實作 chain：

控制面（mitigation 在這裡定義）：

演練 / 控制落地（轉成欄位）：

]]>