網際網路企業安全進階指南3.7.1 攻防驅動修改

<b>3.7.1　攻防驅動修改</b>

大多數甲方安全團隊所做的工作實際上處于這個次元。通過對已知的攻擊手段，例如sql注入，xss等建立事前的安全編碼标準，并在釋出前做代碼審計、滲透測試和提出漏洞修補方案。這種模式的顯著優點是針對性比較強，直入主題，見效快。

簡單的流程+事件驅動型構成了這種日常行為的本質，簡單的流程通常包括：

事前基線：web安全編碼标準，各公司内部範圍流傳的app應用安全設計文檔，這個文檔的品質水準通常可以差很遠，當然文檔永遠隻是文檔，可能就是開發部門不強制不考試800年都不看的東西。

事中措施：代碼審計，釋出前過一輪掃描器+滲透測試。

事後機制：http全流量ids，web日志大資料分析，等等。

事件驅動：發現了新的安全問題就“事後諸葛亮一把”，做點補救性措施。

從整個過程看，攻防驅動修改比較偏“事後”，相對于完整的sdl，威脅模組化等工作而言，它似乎不用發散精力投入太多就能覆寫已知的攻擊點，而且在研發側不用面對比較大的“推動sdl落地的壓力”

但是它的缺點也是顯而易見的，由于過程方法論的施力點的比較偏事後，是以在從源頭上發現和改進問題的能力不足，弱于在産品内建的安全機制上建立縱深防禦，被繞過的可能性比較大，事後的bug率到一定程度就很難再改善，隻能通過不斷的攻防對抗更新去事後修補。籠統一點講就是考慮不夠系統性。這跟目前安全行業缺少真正的安全架構設計人才有關，攻防的聲音鋪天蓋地，跟國外比一下在設計和工程化方面差距不小。

事後修補是不是總是有效的，縫縫補補的感覺你覺得會如何呢，對于公司的邊緣性産品你可以希望它早日歸入曆史的塵埃，而對于公司的支柱型産品你隻能寄希望于某一個大版本更新時把某些機制推倒重新來過。