導(dǎo)致安全問題的軟件缺陷主要有兩種：部署中的漏洞和設(shè)計中的缺陷。現(xiàn)在軟件安全市場中的大部分重點都放在發(fā)現(xiàn)和修復(fù)漏洞上，這主要是因為自動代碼審查工具讓這個過程變得很簡單。但其實軟件設(shè)計和架構(gòu)中的缺陷問題也占據(jù)很大比率，它占所有安全問題的50%。

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

使用ARA尋找軟件缺陷

多年來，我們都在致力于軟件風(fēng)險分析和設(shè)計審查。當(dāng)我們在1997年第一次開始審查系統(tǒng)的安全性時，我們采用了專業(yè)的方法--三個專業(yè)人士在房間里使用一塊白板來審查。而現(xiàn)在，當(dāng)我們深入檢查軟件架構(gòu)中的缺陷時，我們采用的是被稱為架構(gòu)風(fēng)險分析(ARA)的方法。

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

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

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

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

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

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

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

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

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

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

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

在此步驟中，注意你所發(fā)現(xiàn)的攻擊及其影響。想一想你該如何通過修改設(shè)計來降低這種風(fēng)險。

3)相關(guān)性分析在于，確定你依賴的其他軟件架構(gòu)的運作情況。讓我們面對現(xiàn)實吧，現(xiàn)在的軟件幾乎總是依賴于別人設(shè)計和構(gòu)建的組件和框架的正常運作。它們的前提條件是什么?它們?nèi)绾斡绊懩愕南到y(tǒng)?如果框架“胡作非為”，你的設(shè)計會怎樣?

請從你正在依賴的組件開始，確認這些問題：你依賴的組件中是否有已知漏洞?(無論是開源組件或者其它，答案通常是肯定的)。你是否在這些框架中構(gòu)建了足夠的安全控制?它們真的有用嗎?(不幸的是，答案通常是否定的)還有其它功能或特性需要被禁用嗎?(可能)?？蚣茉谀J情況下安全嗎?(可能，如果你最近操作得當(dāng)?shù)脑?。

寫下你發(fā)現(xiàn)的事實，思考其影響，確定該怎么做。在完成ARA的四個步驟后，你會發(fā)現(xiàn)你面臨很多風(fēng)險，也會產(chǎn)生很多改進設(shè)計的想法?？紤]這些風(fēng)險，并明確對業(yè)務(wù)的影響。然后將你發(fā)現(xiàn)的風(fēng)險進行優(yōu)先排序，提出解決方案來解決你所發(fā)現(xiàn)的最重要的缺陷。

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

輕量級設(shè)計審查

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

修復(fù)你的缺陷

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