Validation on Tarragonhttps://tarrragon.github.io/blog/tags/validation/Recent content in Validation on TarragonHugo -- gohugo.iozh-TWTarragon (CC BY 4.0)Fri, 19 Jun 2026 00:00:00 +0000表單 UX 模式https://tarrragon.github.io/blog/ux-design/03-input-mechanism/form-ux-pattern/Fri, 19 Jun 2026 00:00:00 +0000https://tarrragon.github.io/blog/ux-design/03-input-mechanism/form-ux-pattern/<p>表單輸入和 terminal 輸入用同一套四維度決策框架（keyboard type / submit model / IME policy / special keys），但每個維度的選項和取捨方向不同。表單場景的使用者輸入的是結構化但自然語言為主的內容 — 姓名、email、地址 — 手機鍵盤的自動行為在這個場景中大部分是幫助。</p> <h2 id="keyboard-type-的選擇">Keyboard type 的選擇</h2> <p>表單的每個欄位應該使用最適合該欄位內容的鍵盤。正確的 keyboard type 減少使用者在鍵盤上找按鍵的時間，也讓自動填入和驗證更準確。</p> <table> <thead> <tr> <th>欄位</th> <th>Keyboard type</th> <th>理由</th> </tr> </thead> <tbody> <tr> <td>Email</td> <td>emailAddress</td> <td>有 <code>@</code> 和 <code>.</code> 快捷鍵</td> </tr> <tr> <td>電話號碼</td> <td>phone</td> <td>只顯示數字和 <code>+</code> <code>-</code></td> </tr> <tr> <td>URL</td> <td>url</td> <td>有 <code>.com</code> 快捷鍵和 <code>/</code> 鍵</td> </tr> <tr> <td>密碼</td> <td>visiblePassword</td> <td>關閉自動校正，保留字元可見控制</td> </tr> <tr> <td>搜尋</td> <td>text</td> <td>一般文字，可搭配 <code>textInputAction: search</code></td> </tr> <tr> <td>數字金額</td> <td>numberWithOptions(decimal: true)</td> <td>數字鍵盤加小數點</td> </tr> </tbody> </table> <h2 id="驗證時機">驗證時機</h2> <p>表單驗證的時機影響使用者的操作流暢度和錯誤修正效率。</p> <h3 id="即時驗證on-change">即時驗證（on change）</h3> <p>每次輸入變化時驗證。適合格式明確的欄位（email 格式、手機號碼長度）。即時驗證在使用者輸入過程中就能回饋格式錯誤，不需要等到送出。</p> <p>即時驗證的風險是過早報錯。使用者正在輸入 email 地址 <code>user@</code> 時，缺少 domain 部分 — 這個時候報「email 格式錯誤」對使用者沒有幫助。解法是在欄位失去焦點（on blur）時才顯示錯誤，輸入過程中只顯示通過的驗證（例如勾號表示格式正確）。</p> <h3 id="送出時驗證on-submit">送出時驗證（on submit）</h3> <p>使用者按送出按鈕時統一驗證所有欄位。適合需要多欄位交叉驗證的場景（密碼確認、日期範圍）。</p> <p>送出時驗證的風險是使用者填完整張表單才知道哪裡有問題。在欄位多的表單中，使用者需要回頭找到錯誤欄位修正 — 用 scroll 定位和欄位 highlight 減輕這個成本。</p> <h3 id="混合策略">混合策略</h3> <p>格式驗證用即時（on blur）、業務邏輯驗證用送出時。Email 格式在失去焦點時檢查，「email 是否已被註冊」在送出時呼叫 API 檢查。</p> <h2 id="auto-fill-支援">Auto-fill 支援</h2> <p>手機系統（iOS AutoFill、Android Autofill）可以自動填入使用者已儲存的資訊（姓名、地址、信用卡）。App 需要正確標記每個欄位的語意類型（<code>autofillHints</code>），系統才能匹配正確的儲存值。</p> <p>正確標記的欄位讓使用者一鍵填入而非手動輸入 — 在 mobile 上減少的打字量直接轉化為轉換率提升。</p> <h2 id="錯誤回饋">錯誤回饋</h2> <p>錯誤訊息的位置和內容影響使用者修正錯誤的效率。</p> <p><strong>位置</strong>：錯誤訊息應該緊跟在對應欄位下方，而非集中在表單頂部或底部。使用者需要在看到錯誤的同時看到對應的欄位，不需要來回比對。</p> <p><strong>內容</strong>：錯誤訊息應該說明「期望什麼」而非「哪裡錯了」。「請輸入有效的 email 地址」比「email 格式無效」提供更多行動指引。</p> <p><strong>視覺</strong>：錯誤欄位的邊框變色（通常紅色）讓使用者在視覺掃描時快速定位。搭配錯誤文字使用，不要只靠顏色（色盲使用者）。</p> <h2 id="下一步路由">下一步路由</h2> <ul> <li>搜尋場景的輸入設計 → <a href="https://tarrragon.github.io/blog/ux-design/03-input-mechanism/search-ux-pattern/" data-link-title="搜尋 UX 模式" data-link-desc="Debounce / instant / suggestion 三種搜尋模式的取捨 — 和輸入機制的 submit model 維度直接相關">搜尋 UX 模式</a></li> <li>四維度決策表總覽 → <a href="https://tarrragon.github.io/blog/ux-design/03-input-mechanism/four-dimension-decision/" data-link-title="輸入機制決策表" data-link-desc="Keyboard type / submit model / IME policy / special keys 四個維度的決策框架 — 每個維度都是設計決策，影響 UI layout 和 protocol">輸入機制決策表</a></li> <li>安全敏感欄位的 IME 控制 → <a href="https://tarrragon.github.io/blog/ux-design/03-input-mechanism/ime-security-checklist/" data-link-title="安全敏感輸入框的 IME 控制 checklist" data-link-desc="處理密碼、API key、伺服器路徑等 secret 的輸入框需要關閉 IME 的個人化學習和自動校正 — 安全要求而非 UX 偏好">IME 安全 checklist</a></li> </ul>表單輸入和 terminal 輸入用同一套四維度決策框架（keyboard type / submit model / IME policy / special keys），但每個維度的選項和取捨方向不同。表單場景的使用者輸入的是結構化但自然語言為主的內容 — 姓名、email、地址 — 手機鍵盤的自動行為在這個場景中大部分是幫助。

Keyboard type 的選擇

表單的每個欄位應該使用最適合該欄位內容的鍵盤。正確的 keyboard type 減少使用者在鍵盤上找按鍵的時間，也讓自動填入和驗證更準確。

欄位 Keyboard type 理由
Email emailAddress 有 @ 和 . 快捷鍵
電話號碼 phone 只顯示數字和 + -
URL url 有 .com 快捷鍵和 / 鍵
密碼 visiblePassword 關閉自動校正，保留字元可見控制
搜尋 text 一般文字，可搭配 textInputAction: search
數字金額 numberWithOptions(decimal: true) 數字鍵盤加小數點

驗證時機

表單驗證的時機影響使用者的操作流暢度和錯誤修正效率。

即時驗證（on change）

每次輸入變化時驗證。適合格式明確的欄位（email 格式、手機號碼長度）。即時驗證在使用者輸入過程中就能回饋格式錯誤，不需要等到送出。

即時驗證的風險是過早報錯。使用者正在輸入 email 地址 user@ 時，缺少 domain 部分 — 這個時候報「email 格式錯誤」對使用者沒有幫助。解法是在欄位失去焦點（on blur）時才顯示錯誤，輸入過程中只顯示通過的驗證（例如勾號表示格式正確）。

送出時驗證（on submit）

使用者按送出按鈕時統一驗證所有欄位。適合需要多欄位交叉驗證的場景（密碼確認、日期範圍）。

送出時驗證的風險是使用者填完整張表單才知道哪裡有問題。在欄位多的表單中，使用者需要回頭找到錯誤欄位修正 — 用 scroll 定位和欄位 highlight 減輕這個成本。

混合策略

格式驗證用即時（on blur）、業務邏輯驗證用送出時。Email 格式在失去焦點時檢查，「email 是否已被註冊」在送出時呼叫 API 檢查。

Auto-fill 支援

手機系統（iOS AutoFill、Android Autofill）可以自動填入使用者已儲存的資訊（姓名、地址、信用卡）。App 需要正確標記每個欄位的語意類型（autofillHints），系統才能匹配正確的儲存值。

正確標記的欄位讓使用者一鍵填入而非手動輸入 — 在 mobile 上減少的打字量直接轉化為轉換率提升。

錯誤回饋

錯誤訊息的位置和內容影響使用者修正錯誤的效率。

位置：錯誤訊息應該緊跟在對應欄位下方，而非集中在表單頂部或底部。使用者需要在看到錯誤的同時看到對應的欄位，不需要來回比對。

內容：錯誤訊息應該說明「期望什麼」而非「哪裡錯了」。「請輸入有效的 email 地址」比「email 格式無效」提供更多行動指引。

視覺：錯誤欄位的邊框變色（通常紅色）讓使用者在視覺掃描時快速定位。搭配錯誤文字使用，不要只靠顏色（色盲使用者）。

下一步路由

]]>7.B7 Threat-Informed Validationhttps://tarrragon.github.io/blog/backend/07-security-data-protection/blue-team/threat-informed-validation/Thu, 30 Apr 2026 00:00:00 +0000https://tarrragon.github.io/blog/backend/07-security-data-protection/blue-team/threat-informed-validation/<p>本篇的責任是建立 threat-informed validation 路徑。讀者讀完後，能把攻擊行為模型轉成控制面驗證與偵測測試。</p> <h2 id="核心論點">核心論點</h2> <p>Threat-informed validation 的核心概念是用威脅行為驗證防守能力。防守驗證從「控制是否存在」升級為「控制是否能在對手行為下持續生效」。</p> <h2 id="讀者入口">讀者入口</h2> <p>本篇適合銜接 <a href="https://tarrragon.github.io/blog/backend/07-security-data-protection/red-team/" data-link-title="7.1 攻擊者視角（紅隊）與攻擊面驗證" data-link-desc="從攻擊者角度盤點暴露面、邊界、濫用路徑與資料外洩風險">7.1 攻擊者視角（紅隊）與攻擊面驗證</a>、<a href="https://tarrragon.github.io/blog/backend/07-security-data-protection/blue-team/security-control-validation/" data-link-title="7.B3 資安控制驗證" data-link-desc="建立資安控制面如何用證據、演練與 release gate 驗證的大綱">7.B3 資安控制驗證</a> 與 <a href="https://tarrragon.github.io/blog/backend/07-security-data-protection/blue-team/materials/professional-sources/mitre-attack-evaluations-threat-informed-validation/" data-link-title="MITRE ATT&amp;CK Evaluations：威脅導向驗證素材" data-link-desc="把 MITRE ATT&amp;CK Evaluations 轉成藍隊 threat-informed validation 素材">MITRE ATT&amp;CK Evaluations</a>。</p> <h2 id="驗證流程">驗證流程</h2> <table> <thead> <tr> <th>步驟</th> <th>責任</th> <th>產出</th> </tr> </thead> <tbody> <tr> <td>Threat selection</td> <td>選擇要驗證的攻擊行為</td> <td>threat scenario</td> </tr> <tr> <td>Control mapping</td> <td>對應控制面與偵測規則</td> <td>control map</td> </tr> <tr> <td>Emulation design</td> <td>設計可重複測試流程</td> <td>exercise script</td> </tr> <tr> <td>Signal check</td> <td>檢查告警、分級與交接</td> <td>signal evidence</td> </tr> <tr> <td>Decision review</td> <td>審查 containment 與回應判讀</td> <td>response review</td> </tr> <tr> <td>Write-back</td> <td>回寫規則、runbook、章節</td> <td>backlog updates</td> </tr> </tbody> </table> <h2 id="threat-選型">Threat 選型</h2> <p>Threat 選型的責任是聚焦高風險路徑。選型可優先對準 identity abuse、edge exposure、supply chain tampering 與 data exfiltration。</p> <h2 id="控制映射">控制映射</h2> <p>控制映射的責任是把威脅行為接到服務控制面。每個威脅情境都需要標示 identity、entrypoint、data、supply chain、detection 與 governance 的責任邊界。</p> <h2 id="驗證證據">驗證證據</h2> <p>驗證證據的責任是讓測試結果可比較。常見證據包含規則命中率、triage 時間、誤報率、containment 完成時間與回寫完成率。</p> <h2 id="失配修正">失配修正</h2> <p>失配修正的責任是讓驗證結果轉成改進行動。當控制面與行為模型失配時，修正可以落在規則調校、流程補強或控制新增，並同步更新 release gate 與 runbook。</p> <h2 id="判讀訊號與路由">判讀訊號與路由</h2> <table> <thead> <tr> <th>判讀訊號</th> <th>代表需求</th> <th>下一步路由</th> </tr> </thead> <tbody> <tr> <td>控制存在但測試命中率低</td> <td>需要重整映射與規則</td> <td>7.B7 → 7.B5</td> </tr> <tr> <td>測試命中後交接速度慢</td> <td>需要優化 triage loop</td> <td>7.B7 → 7.B6</td> </tr> <tr> <td>測試結果只記錄成功與失敗</td> <td>需要補 evidence 指標</td> <td>7.B7 → 7.B3</td> </tr> <tr> <td>高風險行為未納入演練</td> <td>需要擴充 scenario 庫</td> <td>7.B7 → 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/security-control-validation/" data-link-title="7.B3 資安控制驗證" data-link-desc="建立資安控制面如何用證據、演練與 release gate 驗證的大綱">7.B3 資安控制驗證</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/blue-team-scenario-library/" data-link-title="7.B9 Blue Team Scenario Library" data-link-desc="把高風險服務情境轉成可重用推演素材，支援 tabletop 與 game day 設計">7.B9 Blue Team Scenario Library</a></li> </ul> <h2 id="完稿判準">完稿判準</h2> <p>完稿時要讓讀者能把一個威脅路徑轉成驗證方案。輸出至少包含威脅選型、控制映射、測試設計、證據欄位、修正路由與回寫位置。</p>本篇的責任是建立 threat-informed validation 路徑。讀者讀完後，能把攻擊行為模型轉成控制面驗證與偵測測試。

核心論點

Threat-informed validation 的核心概念是用威脅行為驗證防守能力。防守驗證從「控制是否存在」升級為「控制是否能在對手行為下持續生效」。

讀者入口

本篇適合銜接 7.1 攻擊者視角（紅隊）與攻擊面驗證、7.B3 資安控制驗證 與 MITRE ATT&CK Evaluations。

驗證流程

步驟 責任 產出
Threat selection 選擇要驗證的攻擊行為 threat scenario
Control mapping 對應控制面與偵測規則 control map
Emulation design 設計可重複測試流程 exercise script
Signal check 檢查告警、分級與交接 signal evidence
Decision review 審查 containment 與回應判讀 response review
Write-back 回寫規則、runbook、章節 backlog updates

Threat 選型

Threat 選型的責任是聚焦高風險路徑。選型可優先對準 identity abuse、edge exposure、supply chain tampering 與 data exfiltration。

控制映射

控制映射的責任是把威脅行為接到服務控制面。每個威脅情境都需要標示 identity、entrypoint、data、supply chain、detection 與 governance 的責任邊界。

驗證證據

驗證證據的責任是讓測試結果可比較。常見證據包含規則命中率、triage 時間、誤報率、containment 完成時間與回寫完成率。

失配修正

失配修正的責任是讓驗證結果轉成改進行動。當控制面與行為模型失配時，修正可以落在規則調校、流程補強或控制新增，並同步更新 release gate 與 runbook。

判讀訊號與路由

判讀訊號 代表需求 下一步路由
控制存在但測試命中率低 需要重整映射與規則 7.B7 → 7.B5
測試命中後交接速度慢 需要優化 triage loop 7.B7 → 7.B6
測試結果只記錄成功與失敗 需要補 evidence 指標 7.B7 → 7.B3
高風險行為未納入演練 需要擴充 scenario 庫 7.B7 → 7.B9

必連章節

完稿判準

完稿時要讓讀者能把一個威脅路徑轉成驗證方案。輸出至少包含威脅選型、控制映射、測試設計、證據欄位、修正路由與回寫位置。

]]>7.BM4 藍隊控制模式素材https://tarrragon.github.io/blog/backend/07-security-data-protection/blue-team/materials/control-patterns/Thu, 30 Apr 2026 00:00:00 +0000https://tarrragon.github.io/blog/backend/07-security-data-protection/blue-team/materials/control-patterns/<p>藍隊控制模式素材的責任是把反覆出現的防守做法整理成可搬運模式。控制模式介於來源卡與文章之間，負責把專業來源轉成服務可操作欄位。</p> <h2 id="模式分類">模式分類</h2> <table> <thead> <tr> <th>模式</th> <th>責任</th> <th>承接章節</th> </tr> </thead> <tbody> <tr> <td>Control owner pattern</td> <td>明確主責、協作與升級角色</td> <td>7.B1 / 08</td> </tr> <tr> <td>Evidence chain pattern</td> <td>保留判讀、驗證、回復與通報證據</td> <td>7.B3 / 7.7</td> </tr> <tr> <td>Detection lifecycle pattern</td> <td>管理規則來源、測試、誤報與退場</td> <td>7.B2 / 7.13</td> </tr> <tr> <td>Vulnerability response pattern</td> <td>管理曝險、緩解、修補與驗證</td> <td>7.B2 / 05</td> </tr> <tr> <td>Exercise write-back pattern</td> <td>把演練結果回寫到 <a href="https://tarrragon.github.io/blog/backend/knowledge-cards/runbook/" data-link-title="Runbook" data-link-desc="說明 runbook 如何把事故判斷與操作步驟標準化">runbook</a> 與控制面</td> <td>7.B4 / 7.19</td> </tr> </tbody> </table> <h2 id="使用原則">使用原則</h2> <p>控制模式的使用原則是先定義判讀欄位，再交給章節發展情境。模式卡提供可搬運骨架，文章負責說明它在真實服務中的取捨、風險與下一步路由。</p> <h2 id="source-first-規則">Source-first 規則</h2> <p>控制模式卡的責任是從多個來源案例中抽出可搬運做法。每張模式卡至少要引用一張 field case 或 professional source，並說明這個模式支撐哪一類 scenario。</p> <p>模式卡可以比單一案例更抽象，抽象後仍要保留判讀訊號、證據欄位、適用邊界與回寫位置。這個要求讓控制模式能服務工程實作，並保持可交接的操作語意。</p> <h2 id="下一輪模式大綱">下一輪模式大綱</h2> <table> <thead> <tr> <th>模式卡</th> <th>核心欄位</th> <th>使用情境</th> <th>回寫位置</th> </tr> </thead> <tbody> <tr> <td><a href="https://tarrragon.github.io/blog/backend/07-security-data-protection/blue-team/materials/control-patterns/control-owner-pattern/" data-link-title="Control Owner Pattern" data-link-desc="定義高風險控制面如何配置 owner、協作角色、決策角色與升級路徑">Control owner pattern</a></td> <td>owner、collaborator、decision maker、escalation path</td> <td>高風險控制面需要明確接手</td> <td><code>7.B1</code> + <code>08</code></td> </tr> <tr> <td><a href="https://tarrragon.github.io/blog/backend/07-security-data-protection/blue-team/materials/control-patterns/evidence-chain-pattern/" data-link-title="Evidence Chain Pattern" data-link-desc="定義事故與演練需要保存的訊號、決策、artifact、timeline 與 retention 證據">Evidence chain pattern</a></td> <td>signal、decision record、artifact、timeline、retention</td> <td>演練與事故需要可回查證據</td> <td><code>7.7</code> + <code>7.B3</code></td> </tr> <tr> <td><a href="https://tarrragon.github.io/blog/backend/07-security-data-protection/blue-team/materials/control-patterns/detection-lifecycle-pattern/" data-link-title="Detection Lifecycle Pattern" data-link-desc="定義偵測規則如何管理來源、邏輯、測試事件、誤報與退場">Detection lifecycle pattern</a></td> <td>source、logic、test event、false positive、retirement</td> <td>偵測規則需要維護節奏</td> <td><code>7.B5</code> + <code>7.13</code></td> </tr> <tr> <td><a href="https://tarrragon.github.io/blog/backend/07-security-data-protection/blue-team/materials/control-patterns/vulnerability-response-pattern/" data-link-title="Vulnerability Response Pattern" data-link-desc="定義漏洞回應如何從 observed 推進到 assessed、mitigated、patched、validated 與 closed">Vulnerability response pattern</a></td> <td>observed、assessed、mitigated、patched、validated、closed</td> <td>漏洞事件需要狀態交接</td> <td><code>7.B11</code> + <code>05</code></td> </tr> <tr> <td><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></td> <td>finding、control update、runbook update、owner、<a href="https://tarrragon.github.io/blog/backend/knowledge-cards/tripwire/" data-link-title="Tripwire" data-link-desc="說明風險決策在條件變化時如何自動回到評估流程">tripwire</a></td> <td>演練結果需要轉成工程任務</td> <td><code>7.B4</code> + <code>7.24</code></td> </tr> <tr> <td><a href="https://tarrragon.github.io/blog/backend/07-security-data-protection/blue-team/materials/control-patterns/credential-hygiene-pattern/" data-link-title="Credential Hygiene Pattern" data-link-desc="定義 credential、MFA、輪替、infostealer 監控與 network boundary 的共同基線">Credential hygiene pattern</a></td> <td>MFA enforcement、rotation、reset workflow、exposure monitoring、network boundary</td> <td>credential、token、session 需要共同基線</td> <td><code>7.2</code> + <code>7.B12</code></td> </tr> <tr> <td><a href="https://tarrragon.github.io/blog/backend/07-security-data-protection/blue-team/materials/control-patterns/recovery-readiness-pattern/" data-link-title="Recovery Readiness Pattern" data-link-desc="定義長時間 outage 復原、備援存取與外部依賴溝通的共同欄位">Recovery readiness pattern</a></td> <td>recovery objective、backup access、restore verification、dependency map、communication cadence</td> <td>長時間 outage 與外部依賴需要事前準備</td> <td><code>7.24</code> + <code>08</code></td> </tr> </tbody> </table> <p>控制模式卡的完成條件是能被 field case 與 scenario 同時引用。每張卡都要提供判讀訊號、適用邊界、驗證方法與下一步路由。</p>藍隊控制模式素材的責任是把反覆出現的防守做法整理成可搬運模式。控制模式介於來源卡與文章之間，負責把專業來源轉成服務可操作欄位。

模式分類

模式 責任 承接章節
Control owner pattern 明確主責、協作與升級角色 7.B1 / 08
Evidence chain pattern 保留判讀、驗證、回復與通報證據 7.B3 / 7.7
Detection lifecycle pattern 管理規則來源、測試、誤報與退場 7.B2 / 7.13
Vulnerability response pattern 管理曝險、緩解、修補與驗證 7.B2 / 05
Exercise write-back pattern 把演練結果回寫到 runbook 與控制面 7.B4 / 7.19

使用原則

控制模式的使用原則是先定義判讀欄位，再交給章節發展情境。模式卡提供可搬運骨架，文章負責說明它在真實服務中的取捨、風險與下一步路由。

Source-first 規則

控制模式卡的責任是從多個來源案例中抽出可搬運做法。每張模式卡至少要引用一張 field case 或 professional source，並說明這個模式支撐哪一類 scenario。

模式卡可以比單一案例更抽象，抽象後仍要保留判讀訊號、證據欄位、適用邊界與回寫位置。這個要求讓控制模式能服務工程實作，並保持可交接的操作語意。

下一輪模式大綱

模式卡 核心欄位 使用情境 回寫位置
Control owner pattern owner、collaborator、decision maker、escalation path 高風險控制面需要明確接手 7.B1 + 08
Evidence chain pattern signal、decision record、artifact、timeline、retention 演練與事故需要可回查證據 7.7 + 7.B3
Detection lifecycle pattern source、logic、test event、false positive、retirement 偵測規則需要維護節奏 7.B5 + 7.13
Vulnerability response pattern observed、assessed、mitigated、patched、validated、closed 漏洞事件需要狀態交接 7.B11 + 05
Exercise write-back pattern finding、control update、runbook update、owner、tripwire 演練結果需要轉成工程任務 7.B4 + 7.24
Credential hygiene pattern MFA enforcement、rotation、reset workflow、exposure monitoring、network boundary credential、token、session 需要共同基線 7.2 + 7.B12
Recovery readiness pattern recovery objective、backup access、restore verification、dependency map、communication cadence 長時間 outage 與外部依賴需要事前準備 7.24 + 08

控制模式卡的完成條件是能被 field case 與 scenario 同時引用。每張卡都要提供判讀訊號、適用邊界、驗證方法與下一步路由。

]]>