簡單地說，如果我們想要解決軟件安全問題，我們就需要把更多注意力放在缺陷上。

　　使用ARA尋找軟件缺陷

　　多年來，我們都在致力于軟件風險分析和設計審查。當我們在1997年第一次開始審查系統的安全性時，我們采用了專業的方法--三個專業人士在房間里使用一塊白板來審查。而現在，當我們深入檢查軟件架構中的缺陷時，我們采用的是被稱為架構風險分析（ARA）的方法。

　　ARA包括四個步驟。步驟0（我們通常是從0開始的，因為我們是奇客）是獲取一個架構圖。這可能聽起來很愚蠢，但不管你信不信，從開發團隊獲取相關的最新的架構圖比聽起來更困難。例如，一些開發團隊指出“代碼就是設計”，對此，我們不敢茍同。

　　這個步驟的最終目標是創建軟件系統的單頁總覽視圖。單頁總覽視圖非常重要，因為我們想要“森林級”的軟件視圖，避免“只見樹林不見森林”。我們都知道，漏洞出現在樹木級，而缺陷則在森林級。我們不想要看到大堆代碼，我們不想要UML，也不想要防火墻配置網絡地圖。在很多情況下，我們可以通過詢問軟件架構師、開發人員和測試人員自己繪制一頁紙的總覽圖。

　　你的圖表需要包含一些重要元素，其中包括，但不限于，DAO/持久層、業務邏輯/業務規則、安全功能、工具包（WSE、WCF、Ajax）、中間件、web服務、云計算API、緩存和分發。

　　當你得到架構圖后，你需要進行三個專門的分析步驟：1）已知攻擊分析，2）系統特定攻擊分析，以及3）相關性分析。（我們重新命名了ARA的這三個步驟以便用戶更容易理解）。

　　1）已知攻擊分析很容易理解，正如其字面意思。獲取與你的架構相關的已知攻擊列表，并逐一進行檢查。微軟的STRIDE方法（有人將其誤叫成威脅建模）就是一個很好的例子。STRIDE是欺騙、篡改、否認、信息泄漏、拒絕服務和特權提升的縮寫。這就是微軟已知攻擊清單。

　　已知攻擊分析的關鍵是要知道一些已有的攻擊。如果你能制定一份設計層面的攻擊的列表，這就已經成功了一半。STRIDE可能適用于操作系統供應商，而你需要根據自己的市場和自己面對的獨特的攻擊者建立自己的列表。創建這種列表的方法之一是詢問你的漏洞管理團隊，看看哪些攻擊最常見。

　　當你發現列表中的某個攻擊具有相關性，計算其影響力，并思考你該如何修復架構來降低風險。請注意我們這里使用的是“降低”。有時候缺陷并不需要完全解決或者完全根除，我們只需要根據特定情況將風險降低到可接受的水平即可。

　　如果能夠找出根本性的缺陷，對于企業來說，真的很有價值。發現一個有缺陷的設計，通過正確部署安全控制，降低數十或數百個漏洞帶來的風險，這難道不是好事嗎？我們可以通過輸出編碼來實現這一過程。

　　2）系統特定攻擊分析側重于根據系統的運作情況來揭露無根據的假設、深挖歧義內容以及尋找新攻擊。這個步驟需要最豐富的經驗和天賦，因為安全本身是軟件的新興的屬性。你知道，有時候軟件自己運行時很正常，但當它被添加到更大的生態系統時，它就完全脫離軌道了。這就是我們的意思。預見自然發生的后果可能是非常棘手的工作。

　　在很多情況下，分解問題可能會有所幫助。最起碼，在這個步驟中，我們可以思考信任建模（明確確定信任邊界）、數據敏感性建模（確定隱私和信任問題）以及威脅建模（確定攻擊者，并從攻擊者的角度考慮）。請注意，我們這里使用的威脅建模的術語與微軟的有所不同。

　　在這里，我們想強調的一種方法是綜合不同的觀點。你能否試想，兩個軟件架構師，一個架構，在同一個房間，會發生什么事？提示：這里不存在世界和平。利用非常有經驗的架構師對相同系統的不同觀點，能夠幫助你全面綜合地解決問題。

　　在此步驟中，注意你所發現的攻擊及其影響。想一想你該如何通過修改設計來降低這種風險。

　　3）相關性分析在于，確定你依賴的其他軟件架構的運作情況。讓我們面對現實吧，現在的軟件幾乎總是依賴于別人設計和構建的組件和框架的正常運作。它們的前提條件是什么？它們如何影響你的系統？如果框架“胡作非為”，你的設計會怎樣？

　　請從你正在依賴的組件開始，確認這些問題：你依賴的組件中是否有已知漏洞？（無論是開源組件或者其它，答案通常是肯定的）。你是否在這些框架中構建了足夠的安全控制？它們真的有用嗎？（不幸的是，答案通常是否定的）還有其它功能或特性需要被禁用嗎？（可能）。框架在默認情況下安全嗎？（可能，如果你最近操作得當的話）。

　　寫下你發現的事實，思考其影響，確定該怎么做。在完成ARA的四個步驟后，你會發現你面臨很多風險，也會產生很多改進設計的想法。考慮這些風險，并明確對業務的影響。然后將你發現的風險進行優先排序，提出解決方案來解決你所發現的最重要的缺陷。

　　接下來有些棘手：搞清楚如何以及何時進行重大的架構變更。在某些情況下，解決方案需要幾年時間才能展開，對此，請不要太絕望。

　　輕量級設計審查

　　ARA聽起來很容易嗎？但事實并非如此。由于這個過程很密集，并且涉及很多專業知識，深入的ARA并不會適用于所有你的應用。ARA是關鍵系統必備的架構，但對于非核心系統，這并沒有必要。在以后的文章中，我們將探討應該如何解決在這些“不太重要的”系統中的漏洞問題。

　　修復你的缺陷

　　無論你的架構審查過程是否會帶來快速的重構或者使用多年的多個版本企業架構的變更，現在是時候讓我們開始重視軟件安全問題。我們不能放棄漏洞檢測以及用來發現和修復漏洞的工具，但與此同時，鑒于缺陷也占據一半的問題，我們需要謹慎地解決這些問題。