本系列文章是亞遠景科技結合ASPICE for Cybersecurity Guideline，對ASPICE for Cybersecurity進行的一些标準解讀和應用說明，希望向更多的人明晰化标準的一些要求，也幫助推動标準在行業的發展。
目前推出的ASPICE for Cybersecurity标準中新增加了6個過程，分别是
- ASPICE for Cybersecurity VDA Guideline(01)ACQ.2.供應商要求和選擇;
- ASPICE for Cybersecurity VDA Guideline(02)MAN.7.網絡安全風險管理;
- ASPICE for Cybersecurity VDA Guideline(03)SEC.1.網絡安全需求擷取;
- ASPICE for Cybersecurity VDA Guideline(04)SEC.2.網絡安全實施;
- SEC.3 Risk Treatment Verification 風險處理的驗證;
- SEC.4 Risk Treatment Validation 風險處理的确認。
目前已經解讀了前4個過程，還沒有看過的朋友可以點選上方标題前往閱讀。
本篇要講解的過程是：
SEC.3.Risk Treatment Verification風險處理的驗證
閱讀時間約為9分鐘（含有獨家解讀），建議收藏并關注我們
風險處理的驗證過程概述
風險處理驗證過程的目的是确認設計的實作群組件的內建能夠符合網絡安全需求、改進的架構設計和詳細設計。
風險處理驗證過程確定網絡安全控制的實作是符合相應的網絡安全需求、相應的架構設計和詳細設計的。
而網絡安全控制在大多數情況下是由功能或非功能需求以及相應的架構設計和詳細設計來承載的。它們是實作網絡安全需求的詳細解決方案。
風險處理驗證過程的目的僅僅是證明其實作是滿足這些需求和規定的設計的，這個過程提供了證據證明這些措施的執行是正确的。
從某種意義上說，這個驗證過程不能衡量已經規定和實施了的措施是否正确，即它不能提供任何證據直接證明某網絡安全目标對于降低其相應的網絡安全風險的适用性。
而網絡安全目标的适用性和相應降低預期風險的解決方案的有效性都将在SEC.4風險處理确認過程的範圍内。
驗證(verification)過程是證明設計實作，而不證明安全目标的實作，也就是安全風險的有效減緩，而後續的SEC.4确認（Validation）過程将專注于安全目标的實作。
評級建議
（1）風險處理驗證政策Risk treatment verification strategy
網絡安全需求是一個系統和/或軟體特别要具備的特性，它們的驗證将在不同的內建級别中執行，如軟體單元、內建軟體或一個完全內建的系統。
網絡安全驗證可能包括：
- 靜态軟體分析
- 軟體單元測試
- 軟體內建和合格性測試
- 系統內建和合格性測試
一般來說，所有的驗證活動都遵循一個文檔化的風險處理驗證政策，這好比ASPICE中各個驗證于測試過程的政策性檔案，往往包括以下幾方面：
a) 驗證範圍的定義，包括被驗證的工作産品或過程；
b) 關于關于驗證和測試的具體要求(例如，網絡安全相關的利益相關者的協定、ISO/SAE21434、代碼名額、MISRA、測試覆寫範圍)的定義
c) 驗證和評審的方法和工具的定義
d) 辨別未指定功能的方法的定義
e) 測試用例和測試資料開發方法的定義（例如，開發正反面測試、等價測試用例等）
f) 對驗證活動的回歸政策的定義
g) 關于每種驗證方法的驗證或測試環境的定義
h) 準入準出和驗證通過的标準的定義
i) 處理失敗的測試和驗證結果的方法
注：(i)是指問題解決管理（SUP.9)
建議和規則：
[SEC.3.RL.1]If the risk treatment verification strategy does not cover all aspects above, the indicator BP1 cannot be rated F.
解讀：如果風險處理驗證政策沒有涵蓋上述所有方面，則名額BP1不能被評為F。
[SEC.3.RL.2]If the risk treatment verification strategy does not cover aspects b, c, d, the indicator BP1 cannot be rated higher than P.
解讀：如果風險處理驗證政策不包括b、c、d等方面，則名額BP1的評分不能高于P。
[SEC.3.RL.3]If the verification specifications are not based on cybersecurity requirements,architectural design, and the detailed design, the indicator BP2 must not be rated higher than P.
解讀：如果驗證規範不基于網絡安全需求、架構設計和詳細設計，則名額BP2的等級不得高于P。
整個SEC.3的過程都可以類比ASPICE的SWE.4/5/6，SYS.4/5這幾個測試驗證過程，在實施中，可以考慮單獨成文的制作一份網絡安全相關設計的驗證政策檔案，以明晰各類驗證和測試的方式方法，也可以選擇在原本已有的SWE.4/5/6，SYS.4/5等測試驗證過程政策中，針對性的對各自過程所需驗證的網絡安全控制手段進行測試驗證的補充性說明，如，在常見的SWE.4的單元驗證政策中，往往會定義MISRA C的規範作為其靜态驗證準則，加入網絡安全相關的開發工作後，可以考慮加入其他網絡安全相關的編碼規範，如CERT C等等。
相關内容：
- BP1：“Develop a risk treatment verification strategy” “制定風險處理驗證政策”
- Output WP08-52：Test plan測試計劃
- Output WP19-10：Verification strategy 驗證政策
評級一緻性
下圖顯示了SEC.3 各BP以及其他流程之間的關系：
這些關系被用作在以下子章節中定義的評級規則和建議的基礎。
評級還應考慮可追溯性和一緻性、總結和溝通以及政策和計劃的一般方面。請參考VDA ASPICE GUIDELINE（第一版）了解更多資訊。
(1)SEC.3内部的評級一緻性Rating consistency within SEC.3
在SEC.3的範圍内以下BP之間有互相關系：
BP2：制定風險處理驗證的規範Develop specification for risk treatment verification
[SEC.3.RL.4]If the indicator for developing the verification strategy (BP1) is downrated due to missing or inadequate definitions of methods for test case and test data development, the indicator BP2 shall be downrated.
解讀：如果由于測試用例和測試資料開發方法的定義缺失或不充分，導緻驗證政策的名額(BP1)被下調，則名額BP2應被下調。
BP3：執行驗證活動Perform verification activities
[SEC.3.RL.5]If the indicator for developing the verification specification (BP2) is downrated, the indicator BP3 cannot be rated higher.
解讀：如果制定驗證規範（BP2）的名額下調，則名額BP3不能更高。
（2）對第1級其他流程的評級一緻性Rating consistency to other processes at Level 1
SEC.2的以下BP與其他流程有關系:
BP2：制定風險處理驗證規範Develop specification for risk treatment verification
[SEC.3.RC.1]If the BP1 for SEC.1 or SEC.2 is downrated, this should be in line with the rating of the indicator BP2.
解讀：如果SEC.1或SEC.2的BP1被降級，則BP2的評級需與之拉齊。
關于亞遠景科技
上海亞遠景資訊科技有限公司是國内汽車行業咨詢及評估領軍機構之一，深耕于ASPICE、ISO26262功能安全、ISO21434網絡安全領域，擁有10年以上的行業經驗，專精于咨詢、評估及教育訓練服務，廣受全球車廠及供應商贊譽，客戶好評率行業領先。堅持以“探索、研發、融合”引領創新發展，秉持“用心服務、專業技術、合作發展”的理念，不斷以新技術新模式為客戶提供更有效更靈活的服務。
原創：ASPICE for Cybersecurity VDA Guideline解讀(05)SEC.3.風險處理的驗證