如何找出目標系統需要處理的安全風險？

目標系統已經按照確認過的功能規則重新實作，仍然不能只根據程式可以執行就判斷安全性。相同的輸入方式、保存狀態或相依項目，在不同功能中可能造成完全不同的影響。通用安全清單可以提醒常見問題，卻無法代替對實際系統情境的確認。

安全風險分析要說明需要保護甚麼、可能發生甚麼問題、會造成甚麼影響，以及準備如何處理。這項工作也能把「系統要安全」轉換成可以實作與驗證的條件，避免安全要求停留在沒有完成標準的原則。

NIST SP 800-30 Rev. 1將風險評估視為風險管理的一部分，評估結果需要提供足以決定處理方式的資訊。OWASP 的威脅建模（Threat Modeling）說明則將工作整理為建立系統模型、找出可能問題、決定處理方式，以及檢查結果是否足夠。本章會沿用這個順序，但只分析目標系統已確認的構成，不預設所有系統都具有相同架構或威脅。

先界定這次分析的範圍

開始分析前，要先說明這次檢查哪個目標系統版本、哪些功能路徑，以及哪些組成項目。範圍過大時，風險描述容易只剩下「資料可能外洩」或「系統可能被破壞」等籠統句子。範圍過小時，則可能忽略一項功能跨越多個邊界後才出現的影響。

第一次分析可以選擇已經完成實作與功能驗證的代表性路徑，確認方法可以實際執行，再擴大到全部替換範圍。正式切換前，所有納入目標系統的功能、資料與相依項目都要有對應結果，不能只保護最先完成的功能。

每次分析至少要記錄下列範圍資訊：

• 記錄目標系統版本、功能名稱、進入方式及預期完成結果。
• 列出功能會讀取、產生或修改的內容，以及這些內容後續會由哪些功能使用。
• 列出功能實際使用的執行設定、相依項目與輸入輸出方式。
• 標示這次未納入的項目、排除原因及預定確認方式。

範圍應該對應目前設計與實作。只使用早期架構圖或遺留系統的組成推測目標系統，可能會分析已經移除的路徑，也可能漏掉重新設計後新增的互動方式。

從需要保護的內容與功能開始

安全風險要先連回具體保護目標。依照NIST 對資訊安全的說明，可以從機密性（Confidentiality）、完整性（Integrity）與可用性（Availability）三個角度確認影響：

三項目標的重要程度要按照實際用途判斷。公開輸出可能沒有機密性要求，內容遭修改仍會破壞完整性。偶爾執行的轉換功能也可能具有固定完成期限，因此仍要確認可用性。不能因為資料不敏感，就直接判定相關功能沒有安全風險。

可以從已確認的功能規格、資料流向與資料保留決定，列出下列內容：

• 列出功能需要的輸入、輸出及保存狀態，說明錯誤或缺少時的實際影響。
• 列出會改變功能結果的執行設定，說明哪些值需要限制修改範圍。
• 列出具有敏感性、保存責任或外部相容要求的內容。
• 列出目標系統必須依賴的其他程式、檔案、資料來源或執行環境能力。
• 列出失敗後需要復原、重新執行或人工處理的功能。

這份清單只記錄類型、用途與保護需求，不放入密碼、權杖、憑證、私密金鑰或其他可直接使用的敏感內容。

沿著資料流向找出安全邊界

知道需要保護的內容後，接著追查它如何進入系統、在哪裡改變，以及最後提供給誰。原有的系統環境圖、資料流向與功能流程可以直接作為起點，不必為安全分析重新建立一套互不相連的文件。

追查時要標示下列位置：

內容跨越不同信任條件的位置可以標示為信任邊界（Trust Boundary）。例如，內容從外部檔案進入系統、原本只能讀取內容的流程要求修改保存狀態，或目標系統把資料傳給由其他責任範圍維護的相依項目，都需要重新確認輸入能否信任及輸出可以揭露到甚麼程度。

信任邊界不代表系統一定使用網路或分散式架構。同一執行環境中的檔案、不同功能模組、執行設定與人工匯入內容，也可能具有不同信任條件。判斷依據是內容來源、可修改對象與保護責任是否改變。

將可能問題寫成具體風險情境

只記錄「輸入未驗證」、「缺少加密」或「相依項目不安全」，還無法判斷真正影響。這些描述指出可能的缺口，卻沒有說明缺口會在哪項功能中造成甚麼結果。

一項風險情境應該包含四個部分：

1. 說明風險成立前需要具備的條件。
2. 說明內容、功能或相依項目可能發生的事件。
3. 說明事件會影響哪項保護目標與功能結果。
4. 說明目前是否已有保護方式，以及它能降低哪一部分風險。

例如，目標系統確實具有檔案匯入功能時，可以記錄：「來源檔案在核准後、匯入前仍可被其他流程修改。目標系統如果直接按照修改後內容更新保存狀態，可能產生未經確認的結果，影響資料完整性與後續輸出。」這項描述包含具體時間點、變更方式與影響，後續才能決定要限制來源、核對內容、隔離處理，或採用其他符合需求的方式。

分析時可以從下列問題展開，但只保留符合實際系統構成的情境：

• 輸入內容是否可能遭到偽造、修改、重複提供或刻意放大？
• 狀態是否可能由不應修改它的功能或流程變更？
• 輸出、錯誤內容或執行紀錄是否可能包含不需要揭露的資訊？
• 執行設定是否可能在未受控的情況下改變功能結果或保護方式？
• 相依項目失效、回傳非預期內容或版本改變時，目標系統會留下甚麼結果？
• 大量輸入、重複觸發或長時間處理是否會阻礙其他必要功能？

安全風險可能來自刻意行為，也可能來自設定錯誤、操作失誤或相依項目異常。記錄時要保留實際原因，不把所有失敗都描述成攻擊，也不要因為沒有觀察到攻擊就忽略可以預見的安全影響。

記錄每項風險的判斷資訊

風險清單需要讓後續人員知道為甚麼要處理，以及如何確認處理結果。每一列應該對應一個條件、事件與影響相同的風險情境。如果同一個輸入缺口可能造成資料外洩與功能中斷，而且兩者的處理方式不同，就要拆成不同項目。

風險識別碼要能連回功能規格、實作與測試，不需要把所有資訊重複寫入同一份表格。相關文件只要保存識別碼及必要摘要，就能在需求或實作改變時找出需要一起更新的位置。

按照可能性與影響安排優先度

風險優先度用來決定先處理哪些問題，以及哪些項目會阻擋目標系統切換。它不能只沿用掃描工具的嚴重程度，也不能因為某個問題容易修正就自動列為最高優先。

評估發生可能性時，可以確認風險需要哪些前提、相關邊界會被接觸多少次、目前保護方式是否有效，以及過去是否出現相同情況。評估影響時，則要確認受影響的功能、內容、後續處理與恢復難度。影響範圍不同的情境應該分開記錄，避免使用單一分數掩蓋差異。

如果資訊不足，應該明確標示未知項目與補充方式。例如，尚未確認外部輸入是否具有來源核對機制時，可以先檢查實際交換流程，不能直接把可能性填成「低」。高影響且資訊不足的項目，通常要先取得更多資訊或採取暫時限制，再決定是否接受。

使用高、中、低等分級時，每一級都要有共同定義。相同情境在不同人員判斷下如果會得到完全不同的結果，表示分級條件仍不夠清楚。分數或矩陣可以協助排序，最後仍要保留成立條件、影響及判斷依據。

為風險選擇合適的處理方式

每項已確認風險都要有處理決定。可以按照需求與限制選擇下列方向：

• 移除不再需要的功能、資料或互動方式，讓風險成立條件消失。
• 加入限制、隔離、核對、遮蔽、復原或其他保護方式，降低發生可能性或影響。
• 由已確認的外部機制處理特定責任，並記錄雙方邊界、失敗結果與確認方式。
• 接受目前無法進一步降低的風險，記錄適用範圍、理由、核准人員及重新檢查條件。

把責任交給其他相依項目，不代表目標系統不再受影響。仍要確認該項目提供哪些保護、失效時如何處理，以及目標系統是否需要自行驗證結果。無法確認處理方式或影響的未知項目，也不能直接視為已接受風險。

保護方式要對應具體情境。輸入驗證無法解決執行設定遭非預期修改，執行紀錄也不能防止敏感內容被錯誤輸出。選擇方式時要說明它降低哪個成立條件或影響，並確認沒有產生新的功能錯誤或可用性問題。

將處理決定轉換成可檢查條件

「加強驗證」、「妥善保護資料」或「避免服務中斷」都無法直接判斷是否完成。處理決定需要改寫成具有前提、動作與預期結果的條件，再交由對應實作與後續測試確認。

例如，可以將風險轉換成下列條件：

每項條件要連回風險識別碼。後續章節設計輸入驗證、異常處理及測試時，就能從同一項風險確認正常、失敗與邊界案例。實作完成後也要保存檢查結果，不能只把風險項目改成完成狀態。

NIST Cybersecurity Framework 2.0提供用來理解、評估、安排優先度與溝通安全成果的共同分類，但不規定每個系統必須採用相同實作。目標系統仍要按照自身功能、限制與風險情境選擇保護方式。

記錄處理後仍存在的風險

採取保護方式後，風險可能降低，但不一定完全消失。剩餘風險（Residual Risk）要說明目前仍可能發生的情況、造成的影響，以及為甚麼現有結果可以接受。

例如，限制單次輸入大小可以降低處理能力被占滿的可能性，仍可能出現大量符合單次限制的重複輸入。是否需要再限制執行頻率、調整處理方式或接受目前結果，要按照功能用途與實際使用範圍決定。

接受剩餘風險時，至少要記錄下列資訊：

• 說明已完成的保護方式及確認結果。
• 說明仍然存在的成立條件、影響及適用範圍。
• 指定能核准需求與安全限制的人員確認接受理由。
• 定義重新檢查的日期或系統變更條件。
• 記錄風險發生後的發現、限制影響與恢復方式。

接受決定只適用於記錄中的版本與範圍。需求、資料敏感程度或系統邊界改變後，原有決定不能自動沿用。

隨目標系統變更重新檢查

安全風險分析需要和目標系統一起維護。OWASP 的威脅建模說明強調，模型要隨系統持續更新，不能在設計階段完成一次後就停止維護。

出現下列變更時，應該重新檢查相關風險：

• 功能新增輸入、輸出、狀態變更或新的使用方式。
• 保存內容的用途、敏感程度、格式或保存期限改變。
• 相依項目、版本、交換格式或失敗行為改變。
• 執行設定、部署方式或可修改內容的責任範圍改變。
• 測試、執行紀錄或實際異常顯示原有保護方式未達預期。
• 正式切換使既有系統、目標系統與相依項目的並存關係改變。

更新時要保留風險識別碼與修訂紀錄，讓需求、實作及測試可以追蹤同一項問題。如果情境已經不存在，可以記錄關閉原因與確認結果，不必讓失效項目永久留在目前清單中。

完成安全風險分析的檢查

完成一輪分析後，可以使用下列問題確認結果：

• 分析範圍是否對應明確的目標系統版本、功能與邊界？
• 需要保護的內容與功能是否具有機密性、完整性或可用性的具體要求？
• 資料流向是否標示輸入、處理、狀態變更、相依項目與輸出位置？
• 每項風險是否包含成立條件、可能事件、實際影響與現有保護方式？
• 優先度是否同時記錄可能性、影響與資訊來源，避免只依賴工具分數？
• 每項風險是否具有處理決定、可檢查條件與負責確認的人員？
• 處理後仍存在的風險是否已記錄接受理由與重新檢查條件？
• 需求、實作、測試與風險紀錄是否能透過固定識別碼互相追蹤？

重點整理

• 安全風險分析要先界定目標系統版本、功能與組成範圍，再擴大到全部替換內容。
• 需要保護的內容與功能可以從機密性、完整性及可用性確認具體影響，不應只按照資料是否敏感判斷。
• 資料流向與信任條件改變的位置可以協助找出安全邊界，而且不預設系統採用網路或分散式架構。
• 風險情境要包含成立條件、可能事件、實際影響與現有保護方式，才能安排優先度及選擇處理方式。
• 每項處理決定都要轉換成可檢查條件，並記錄處理後仍存在的風險、接受理由與確認人員。
• 功能、資料、相依項目、執行設定或部署方式改變時，要同步更新風險紀錄及相關驗證結果。