4月4日文 在探尋威脅模式的生命之旅中，人們正處于測試階段。從分析需求、資產(chǎn)和威脅，到設(shè)計通用的可重用威脅模式，并在安全監(jiān)控平臺實(shí)現(xiàn)這種模式，人難免會犯錯。

19世紀(jì)英國著名藝術(shù)家約翰·羅斯金曾說， “品質(zhì)從來靠的就不是偶然機(jī)遇，唯有勤奮才能打造卓越品質(zhì)”(Quality is never an accident，it is always the result of intelligent effort)。

因此，結(jié)構(gòu)良好的精確測試過程對驗(yàn)證模式是否正確實(shí)現(xiàn)并確保有效解決攻擊場景至關(guān)重要。

即使處于測試階段，軟件開發(fā)生命周期(Software Development Life Cycle，SDLC)的典型流程也能引領(lǐng)正確的方向。

軟件測試方法同樣適用于威脅模型以上這種驗(yàn)證攻擊模式一旦實(shí)現(xiàn)，通常用于軟件測試的黑盒測試及白盒測試兩種互補(bǔ)的方法將如何應(yīng)用到新實(shí)現(xiàn)的威脅模型之中?

白盒測試旨在驗(yàn)證威脅模式的邏輯，并確保實(shí)現(xiàn)(Implementation)與要求相符。如果正確進(jìn)入設(shè)計階段，構(gòu)成該模式的不同組件應(yīng)已被明確定義和記錄。無論處于哪個階段，都需要準(zhǔn)備具體的輸入和預(yù)期輸出列表，以觸發(fā)實(shí)現(xiàn)的各個部分。與任何軟件一樣，測試進(jìn)度可以通過測試覆蓋的代碼百分比來量化，但這個過程可能會比較耗時。

在安全運(yùn)維中心(SOC)，時間就是寶貴的資源，因此自動化是關(guān)鍵。所幸的是，在這個階段，我們應(yīng)該能擁有大量的歷史數(shù)據(jù)，因?yàn)樾畔⒁呀?jīng)開始流入系統(tǒng)。因此，選擇精確的樣本至關(guān)重要，因?yàn)楸仨氁哂辛己玫乃礁采w范圍(例如測試組件的數(shù)量)和垂直覆蓋范圍(例如輸入的種類)?？梢越柚鷾y試組件映射每個選定的樣本使邏輯驗(yàn)證和威脅模式邏輯有效。此外，為了確保輸出仍與要求一致，變化之后，可以將相同的樣本重新注入平臺。

相反，黑盒測試檢驗(yàn)的是威脅模式的功能，而無需仔細(xì)檢查邏輯。

在這個階段，建議從攻擊場景(最初在分析階段詳細(xì)闡述的)開始，并確定攻擊者可能會利用的方法。許多組織機(jī)構(gòu)發(fā)現(xiàn)建立或參與到“紅隊”中(扮演攻擊者的角色)是有益的，藍(lán)隊通過確保實(shí)現(xiàn)的威脅模式防御，并按預(yù)期行事。演習(xí)最后，兩隊會面審查結(jié)果，并羅列所有當(dāng)前未被實(shí)現(xiàn)和需進(jìn)一步審查的威脅模式而檢測的所有情形。

安全運(yùn)維中心除了懼怕攻擊者，還應(yīng)減少信噪比留下的疑問就是，如何根據(jù)測試結(jié)果衡量模式的有效性。最簡單的方式是評估誤報和漏報率。這兩個參數(shù)便于理解威脅模式基于漏報率的有效性，以及該模式能根據(jù)誤報率產(chǎn)生的潛在“噪聲”。

每個安全運(yùn)維中心目前為止應(yīng)該學(xué)到了一個非常重要的教訓(xùn)：最危險的敵人可能不是隱蔽的攻擊者，而是誤報量淹沒了分析師，阻止其響應(yīng)事關(guān)重大的安全問題。在保護(hù)組織機(jī)構(gòu)之前必須減少信噪比。

此流程結(jié)束時，企業(yè)必須著手從根本上分析識別到的每個問題，但要注意簡單對實(shí)現(xiàn)進(jìn)行更改，要是最終迷途未返，那就太可惜了。

接觸代碼之前，企業(yè)應(yīng)從需求分析結(jié)果入手思考：是否完全錯過了攻擊場景?是不是存在沒有考慮到的數(shù)據(jù)源?是不是實(shí)現(xiàn)過程出了差錯?借助簡單的清單進(jìn)入該階段能夠減少或者杜絕對其它威脅模式造成負(fù)面影響。

但需要注意的是，要意識到所做的工作可能會在短時間內(nèi)過時，也就是說，可能會出現(xiàn)新的測試威脅模式和攻擊場景，當(dāng)然，企業(yè)對策也在不斷變化。