第3章程序安全

1、第3章 程序安全 本章要點r 具有安全隱患的編程錯誤 r 惡意代碼 r 防止惡意代碼和脆弱性的程序開發(fā)控制 r 控制程序運行時的缺陷 程序構(gòu)成了一個計算機系統(tǒng)的很多部分，因此多種形式保護程序是計算機安全的核心。我 們 將 所 有 代 碼 片 稱 之 為 “ 程 序程 序 ” (program)。這里需要提出兩個重要問題：怎樣消除程序中的缺陷？在程序有缺陷的情況下，如何保護計算機資源？ 本章討論的是一般的程序話題，包括程序編寫。程序安全中一個重要問題是信任信任。信任問題是指：假設(shè)提供一個已完成的程序，如何來確定它的安全性或者說如何以最安全的方式使用它？答案是采用獨立的第三方的評估第三方的評估。3

2、.1 安全程序 評估程序安全與軟件質(zhì)量的評估相似，一種評估軟件安全性或質(zhì)量的方法是讓人們列出能反映該軟件整體安全的那些特性。然而，不同的人有不同的答案。人們對軟件質(zhì)量的總體設(shè)想也會影響對安全性的評估。一般而言，開發(fā)者把錯誤的數(shù)量數(shù)量和種種類類作為衡量產(chǎn)品質(zhì)量的依據(jù)。 當(dāng)一個人在從事軟件活動的過程中有所疏失時，我們稱之為過失過失(error)。過失可能會在計算機程序中導(dǎo)致一個錯誤錯誤(fault)，或者一個不確定的步驟、命令、過程或數(shù)據(jù)定義。一個單獨的過失可以產(chǎn)生很多錯誤，一個錯誤可以隱藏在任何產(chǎn)品的開發(fā)和維護中。 一次失效失效(failure)就是對系統(tǒng)要求行為的一次違反。一次失效意味著系統(tǒng)沒

3、有按照需求執(zhí)行。 錯誤是對系統(tǒng)的內(nèi)部觀點而言的，是開發(fā)開發(fā)者者所見到的；而失效則是對系統(tǒng)的外部觀點而言的，是用戶用戶看到的問題。3.1.1 修改錯誤 修改錯誤是評估安全質(zhì)量的一種方法。計算機安全工作建立在“查找錯誤并打補丁查找錯誤并打補丁” (penetrate and patch)的模式上。分析專家在該模式下尋找錯誤，并給錯誤打上補丁。3.1.1 修改錯誤 (續(xù)) 缺陷： 1) 修補指定問題的壓力使得人們僅僅關(guān)注錯誤本身，而不是與之相關(guān)的上下文環(huán)境。 2) 在離錯誤較遠的區(qū)域，其副作用不明顯。 3) 修補一個問題時常導(dǎo)致其他地方的失敗，或者說補丁僅僅解決一個地方的問題，而沒有解決相關(guān)地方的問

4、題。 4) 打補丁可能會影響系統(tǒng)的功能和性能，所以補丁經(jīng)常不能恰當(dāng)?shù)匦扪a系統(tǒng)錯誤。 3.1.2 意外行為 “程序安全缺陷程序安全缺陷” (program security flaw) 是由于程序的脆弱點而引起的不恰當(dāng)?shù)某绦蛐袨椤?“脆弱點”和“缺陷”這組詞與“錯誤”和“失效”這組詞之間并沒有直接的對應(yīng)關(guān)系。一個缺陷可以是一個錯誤或是失效，而脆弱點經(jīng)常用來描述某一類缺陷，諸如緩沖區(qū)溢出。盡管不一致，但應(yīng)該記?。何覀儽仨殢膬蓚€方面來看待脆弱點和缺陷，即起因起因和影響影響。 程序安全性缺陷可以來源于任何種類的軟件錯誤。有必要將程序缺陷劃分為兩種邏輯類別：由開發(fā)者的疏忽所引起的錯誤和惡(有)意設(shè)計的缺

5、陷。 3.1.2 意外行為 (續(xù)) 分類幫助我們理解一些方法，用以防止將缺陷有意或無意地引入到以后的代碼編寫中。一個因疏忽而引起的錯誤給用戶及其組織帶來的損失可能與惡意漏洞帶來的損失相當(dāng)。計算機攻擊計算機攻擊(cyber attack) 即有意的安全事件，是如今最大的安全威脅。 從根本上說安全是困難的，安全時常與有效性和性能相沖突，而且錯誤的安全解決方案會阻礙安全編程的真實進展。我們還沒有技術(shù)來消除或解決所有的程序安全缺陷。原因有兩個： 3.1.2 意外行為 (續(xù)) 1) 程序控制是在單獨的程序和程序員的級別上實施的。功能測試是解決程序“應(yīng)該應(yīng)該做什么做什么”的問題，而安全測試還要確定 “不應(yīng)

6、該做什么不應(yīng)該做什么” 的問題。要保證程序精確地按照設(shè)計者和用戶的意圖來執(zhí)行而沒有其他的行為，這幾乎是不可能的。在一個復(fù)雜的大型系統(tǒng)中，不管設(shè)計者或程序員的意圖何在，許多相關(guān)模塊都以各種各樣難以控制的方式交織著。巨大的規(guī)模巨大的規(guī)模和復(fù)雜性復(fù)雜性使得我們不可能去預(yù)防和檢查所有缺陷。想要植入惡意代碼的程序員可以利用系統(tǒng)的不完整性成功地將漏洞隱藏其中。 3.1.2 意外行為 (續(xù)) 2) 程序設(shè)計和軟件工程技術(shù)的發(fā)展迅速遠遠超過了計算機安全技術(shù)的發(fā)展速度。所以我們經(jīng)常發(fā)現(xiàn)自己還在努力保護去年的技術(shù)，而軟件開發(fā)者卻正迅速地采用當(dāng)前最新的技術(shù)了。 # 盡管如此，我們可以通過理解什么導(dǎo)致錯誤以及怎樣阻止

7、它，來開發(fā)技術(shù)和工具，保護大多數(shù)計算機的應(yīng)用程序。 3.1.3 缺陷類型 Landwehr等提出了一種關(guān)于程序缺陷的分類法，首先分為有意和無意的缺陷。進一步將有意缺陷細分為惡意和非惡意的類型。無意的缺陷分為6類： 確認(rèn)過失確認(rèn)過失(不完善或不一致不完善或不一致)：許可權(quán)核查。 域過失域過失：對于數(shù)據(jù)的受控訪問。 序列化和混淆序列化和混淆：程序流順序。 不充分的識別和鑒別不充分的識別和鑒別：授權(quán)的基礎(chǔ)。 邊界條件違規(guī)邊界條件違規(guī)：首次或末次情形失效。 其他可以利用的邏輯過失邏輯過失。 3.2 非惡意的程序漏洞 3.2.1緩沖區(qū)溢出 問題說明問題說明 定義定義 1 緩沖區(qū)緩沖區(qū)（或數(shù)組、字符串）是

8、一個用來存儲數(shù)據(jù)的空間。緩沖區(qū)位于內(nèi)存中。由于內(nèi)存是有限的，所以緩沖區(qū)的容量也是有限的。因此，在許多程序設(shè)計語言中，程序員必須聲明緩沖區(qū)的最大容量，以使編譯器能留出所需的空間。3.2.1緩沖區(qū)溢出(續(xù))C程序中：char sample10;sample10=B;samplei=B; /執(zhí)行過程確定i的值3.2.1緩沖區(qū)溢出(續(xù))若有：for(i=0;i0 DO stmts END從K到stmtsCASE (exp) val1: stmts從exp到stmtsB:=fcn(args)從fcn到BOPEN FILE f沒有信息流動READ (f, X)從文件f到XWRITE (f, X)從X 到文

9、件f3.4.9 隱蔽通道：泄露信息的程序 (續(xù)) 對隱蔽通道的小結(jié)對隱蔽通道的小結(jié) 隱蔽通道對信息系統(tǒng)的安全來說是一個嚴(yán)重的威脅。隱蔽通道攻擊手段非常靈活，可以隱藏在任何服務(wù)程序，如打印機程序等。制造起來也不比病毒難。容量和速度也不是限制信息流傳播的條件，特別是隱藏在硬件中的隱蔽通道。關(guān)閉隱蔽通道的技術(shù)進展并不樂觀。 隱蔽通道存在的可能性要求人們對程序開發(fā)分析、系統(tǒng)結(jié)構(gòu)分析和輸出審查給予更大關(guān)注。3.5 對程序威脅的控制 應(yīng)該更關(guān)注如何預(yù)防漏洞而不是修補漏洞。這需要在軟件開發(fā)軟件開發(fā)(software development)期間，即編寫規(guī)范、設(shè)計、編碼和測試等過程中，實施控制。我們將討論：開

10、發(fā)控制、操作系統(tǒng)控制和管理控制。這里先討論開發(fā)控制。 3.5.1 開發(fā)控制 軟件開發(fā)過程的特點軟件開發(fā)過程的特點 開發(fā)過程中需要完成的任務(wù)： 系統(tǒng)需求分析系統(tǒng)需求分析，獲取系統(tǒng)的需求并從用戶的角度構(gòu)建模型系統(tǒng)。 設(shè)計系統(tǒng)設(shè)計系統(tǒng)，從需求描述出發(fā)，提出解決問題的方案，并為該方案建模。 實現(xiàn)系統(tǒng)實現(xiàn)系統(tǒng)，以設(shè)計方案為藍本來實施問題的解決方案。 測試系統(tǒng)測試系統(tǒng)，確保系統(tǒng)符合需求分析和系統(tǒng)設(shè)計中所提出的需要。 在不同的階段復(fù)查系統(tǒng)在不同的階段復(fù)查系統(tǒng)，確保最終的產(chǎn)品符合需求分析和系統(tǒng)設(shè)計中所提出的要求。 為系統(tǒng)編寫文檔為系統(tǒng)編寫文檔，以進行對用戶的培訓(xùn)和支持。 管理系統(tǒng)管理系統(tǒng)，以清除一些不必要的資

11、源。這些資源在軟件開發(fā)過程中使用，但系統(tǒng)完成后，它們可能會成為通往系統(tǒng)內(nèi)部的暗道。 維護系統(tǒng)維護系統(tǒng)，追蹤被發(fā)現(xiàn)的問題、必要的系統(tǒng)變化和已經(jīng)產(chǎn)生的系統(tǒng)變化，并從整體上評估它們對系統(tǒng)的質(zhì)量和功能的影響。3.5.1 開發(fā)控制 (續(xù))軟件開發(fā)過程的特點軟件開發(fā)過程的特點 (續(xù)續(xù))設(shè)計安全、可用的系統(tǒng)，需要注意如下要點：1) 不能隨意發(fā)揮可用的安全性能2) 工具不是解決方案3) 關(guān)注上層4) 讓用戶滿意5) 局部思考，局部動作 3.5.1 開發(fā)控制 (續(xù)) 模塊化、封裝性和信息隱藏模塊化、封裝性和信息隱藏 通常，代碼的生存期生存期(shelf-life)是很長的。但是，隨著時間的推移，代碼需要完善，因

12、為需求可能發(fā)生變更，并且發(fā)現(xiàn)的錯誤需要修改。因此，軟件工程的一個重要原則就是將代碼或其他設(shè)計實體做成小型、獨立的單元，稱為組件組件(component)或模塊模塊(module)。當(dāng)系統(tǒng)按照這種方法開發(fā)時，我們 稱其為模塊化模塊化(modular) 。3.5.1 開發(fā)控制 (續(xù)) 模塊化、封裝性和信息隱藏模塊化、封裝性和信息隱藏 (續(xù)續(xù)) 如果一個獨立的組件不受其他組件的影響，就很容易找出其中故障的原因，并將故障的危害控制在最小范圍內(nèi)。獨立組件也使系統(tǒng)的維護變得容易，因為對一個獨立組件所做的調(diào)整將不會影響其他組件。在組件間完全獨立的情況下，我們能更容易地發(fā)現(xiàn)漏洞所在。這種獨立的模塊化形式稱為封

13、裝性封裝性(encapsulation)。 信息隱藏信息隱藏(information hiding)是模塊化軟件的又一個特性。信息隱藏指的是，每個組件都隱藏自己的實現(xiàn)細節(jié)或設(shè)計細節(jié)。 這樣在系統(tǒng)需要調(diào)整時，只需要調(diào)整某個特定組件。3.5.1 開發(fā)控制 (續(xù)) 模塊化、封裝性和信息隱藏模塊化、封裝性和信息隱藏 (續(xù)續(xù)) 模塊化是將一個任務(wù)劃分為若干子任務(wù)的過程。這種劃分是以邏輯性邏輯性或功能性功能性為基礎(chǔ)的。模塊化使得每個組件都必須滿足4個條件： 單任務(wù)單任務(wù)：只完成一個特定的功能 小型化小型化：一個組件包含的信息數(shù)量非常少，以至于人們可以很容易地理解它的構(gòu)造和內(nèi)容 簡單化簡單化：復(fù)雜程度不高，

14、可以很容易地理解模塊的意圖和構(gòu)造 獨立性獨立性：不依靠其他模塊而獨立完成任務(wù) 3.5.1 開發(fā)控制 (續(xù))圖 3.16 模塊化模塊化、封裝性和信息隱藏模塊化、封裝性和信息隱藏 (續(xù)續(xù))3.5.1 開發(fā)控制 (續(xù)) 模塊化、封裝性和信息隱藏模塊化、封裝性和信息隱藏 (續(xù)續(xù)) 小型、獨立的組件具有許多好處： 易維護易維護：當(dāng)需要用改進版本取代一個舊版本的組件時，如果該組件只執(zhí)行某個單獨的功能，則只需將舊組件移除就可以了。 易理解易理解：人們通常更容易理解一個由許多小型組件所構(gòu)成的系統(tǒng)，而不容易理解一個由大量非結(jié)構(gòu)化的代碼所構(gòu)成的系統(tǒng)。 可重用可重用：為一項特定任務(wù)而開發(fā)的組件經(jīng)?？梢员黄渌到y(tǒng)重復(fù)

15、利用。重用正確、已經(jīng)存在的代碼或設(shè)計，可以減少開發(fā)和測試的難度。 易修復(fù)易修復(fù)：對完成一項特定任務(wù)的組件來說，很容易確定它的故障。 易測試易測試：一個良好定義了輸入、輸出和功能性的組件可以僅從自身出發(fā)盡一切可能性來進行測試，這些測試不用考慮其他模塊的影響。 3.5.1 開發(fā)控制 (續(xù)) 模塊化、封裝性和信息隱藏模塊化、封裝性和信息隱藏 (續(xù)續(xù)) 內(nèi)聚內(nèi)聚(cohesion)是指組件中所有元素的存在都有充足的邏輯理由或功能理由，每個組件元素都與組件要執(zhí)行的單一任務(wù)是相關(guān)的。耦合耦合(coupling)是指某個組件與系統(tǒng)中其他組件的相互依賴程度。圖 3.17 耦合3.5.1 開發(fā)控制 (續(xù)) 模塊

16、化、封裝性和信息隱藏模塊化、封裝性和信息隱藏 (續(xù)續(xù)) 封裝性 一個被封裝組件的邊界可以根據(jù)需要設(shè)計成半透明或透明。應(yīng)該將組件內(nèi)的信息打包，隱藏應(yīng)該隱藏的部分，并將應(yīng)該可見的部分呈現(xiàn)出來。3.5.1 開發(fā)控制 (續(xù)) 模塊化、封裝性和信息隱藏模塊化、封裝性和信息隱藏 (續(xù)續(xù)) 信息隱藏 一個設(shè)計良好的組件，對其他設(shè)計者而言沒有必要知道該模塊的實現(xiàn)細節(jié)。隱藏實現(xiàn)細節(jié)，使得惡意開發(fā)者因為不知道該組件是如何工作的，而不能輕易用其他的組件替換。圖 3.18 信息隱藏3.5.1 開發(fā)控制 (續(xù)) 相互猜疑相互猜疑 相互猜疑相互猜疑(mutual suspicion) 是描述兩個程序的關(guān)系，相互猜疑的程序

17、各自運行，仿佛系統(tǒng)中其他程序是惡意或者不正確的。每個程序都保護它的接口數(shù)據(jù)以限制其他程序訪問。 限制限制 一個受限制的程序被嚴(yán)格地限制它可以訪問的系統(tǒng)資源。強限制有助于限制病毒擴散。3.5.1 開發(fā)控制 (續(xù)) 遺傳的多樣性遺傳的多樣性 來自一個來源的系統(tǒng)的多個組件是危險的。軟件產(chǎn)品的緊密集成也是一個類似問題。由于緊密集成，修補一個軟件產(chǎn)品的漏洞會影響其他軟件產(chǎn)品。3.5.1 開發(fā)控制 (續(xù))技術(shù)手段技術(shù)手段軟件開發(fā)階段，幾種關(guān)鍵的技術(shù)包括：1) 對等復(fù)查2) 風(fēng)險分析3) 測試4) 良好的設(shè)計5) 預(yù)測6) 靜態(tài)分析7) 配置管理8) 錯誤分析 3.5.1 開發(fā)控制 (續(xù)) 對等復(fù)查對等復(fù)查

18、 三種有很細微差別的對等復(fù)查： 復(fù)查復(fù)查：讓復(fù)查小組非正式地對產(chǎn)品做出評審，目的在于在開發(fā)繼續(xù)進行之前，聽取大多數(shù)人的意見。 走查走查：產(chǎn)品的制造者將產(chǎn)品提交評審小組，并主持和控制小組的討論。該類型復(fù)查的目的在于讓小組成員針對產(chǎn)品進行學(xué)習(xí)，關(guān)注的焦點是研究某個單獨的文檔。 檢查檢查：這種復(fù)查更加正規(guī)，它將根據(jù)一張清單做詳細的分析，該清單上列舉了一些應(yīng)該關(guān)注的問題。作者不再是討論的主持人，而錯誤的發(fā)現(xiàn)和修正通常由統(tǒng)計測試來控制。3.5.1 開發(fā)控制 (續(xù)) 對等復(fù)查對等復(fù)查 (續(xù)續(xù)) 發(fā)現(xiàn)了錯誤后可以采取至少三種方法進行處理： 1) 研究錯誤發(fā)生的方式、時間和原因。 2) 采取行動阻止錯誤的運行

19、。 3) 仔細檢查產(chǎn)品以找出被忽略的錯誤實例和影響。3.5.1 開發(fā)控制 (續(xù)) 對等復(fù)查對等復(fù)查 (續(xù)續(xù)) 進行對等復(fù)查非常必要。Hewlett-Packard早期的研究表明：在開發(fā)過程中實施了對等復(fù)查的產(chǎn)品比其他實施傳統(tǒng)測試技術(shù)的產(chǎn)品具有明顯優(yōu)勢。 圖 3.19 報告的錯誤發(fā)現(xiàn)率3.5.1 開發(fā)控制 (續(xù)) 對等復(fù)查對等復(fù)查 (續(xù)續(xù)) 復(fù)查的過程包括了幾個重要步驟：計劃計劃、個體準(zhǔn)備個體準(zhǔn)備、會議討論會議討論、再工作再工作和再檢查再檢查。復(fù)查中，應(yīng)該密切關(guān)注復(fù)查者的發(fā)現(xiàn)和他們發(fā)現(xiàn)問題的速度。這可以了解每位復(fù)查者是否勝任。而且可以了解某類錯誤是否較其他錯誤更難發(fā)現(xiàn)。對錯誤的處理還要追根溯源。

20、開發(fā)中記載錯誤的日志錯誤的日志可以形成檢查清單，以備復(fù)查使用。管理措施必須強制系統(tǒng)在開發(fā)的整個過程中使用苛刻的復(fù)查法才能保證最終程序的安全。3.5.1 開發(fā)控制 (續(xù)) 風(fēng)險分析風(fēng)險分析 風(fēng)險分析風(fēng)險分析(hazard analysis)是在系統(tǒng)級上采用一系列技術(shù)揭示系統(tǒng)潛在的不安全狀態(tài)。風(fēng)險分析是系統(tǒng)級而非代碼級，其對發(fā)現(xiàn)安全漏洞無能為力。風(fēng)險分析越早越好，并且應(yīng)該貫穿整個軟件生存期。大量不同的技術(shù)都支持查找和管理潛在的風(fēng)險。 3.5.1 開發(fā)控制 (續(xù)) 風(fēng)險分析風(fēng)險分析(續(xù)) 最有效的技術(shù)是風(fēng)險和運行性研究風(fēng)險和運行性研究(hazard and operability studies，H

21、AZOP)、失效模式和后失效模式和后果分析果分析(failure modes and effects analysis，F(xiàn)MEA)，以及故障樹分析故障樹分析(fault tree analysis，F(xiàn)TA)。 表 3.6 風(fēng)險分析的觀點已知原因未知原因已知結(jié)果描述出系統(tǒng)的行為推論分析，如FTA未知結(jié)果誘導(dǎo)分析，如FMEA探測分析，如HAZOP3.5.1 開發(fā)控制 (續(xù)) 測試測試 測試是針對產(chǎn)品質(zhì)量的活動，目的是消除產(chǎn)品的故障或使故障在允許范圍內(nèi)。由于一個控制失敗暴露出的脆弱點是再多的功能控制所無法改善的，因此，測試者應(yīng)該保持足夠的謹(jǐn)慎。 安全測試很艱難。副作用、依賴性、不可預(yù)知的用戶、有缺陷

22、的實現(xiàn)基礎(chǔ)都給安全測試帶來困難。安全測試復(fù)雜的本質(zhì)在于，不僅安全測試復(fù)雜的本質(zhì)在于，不僅需要考慮程序的正確運行，而還必須考慮程需要考慮程序的正確運行，而還必須考慮程序可能出錯的各種方式序可能出錯的各種方式。3.5.1 開發(fā)控制 (續(xù)) 測試測試 (續(xù)續(xù)) 測試通常包括幾個階段： 單元測試單元測試(unit testing)是在可操控的環(huán)境下實現(xiàn)的，這樣測試小組可以為組件輸入一組預(yù)定的數(shù)據(jù)，并觀察組件的輸出行為和輸出數(shù)據(jù)。此外，測試小組還依據(jù)輸入和輸出數(shù)據(jù)檢查內(nèi)部結(jié)構(gòu)、邏輯條件和邊界條件。 集成測試集成測試(integration testing)是確保系統(tǒng)的組件間按照系統(tǒng)設(shè)計規(guī)范的描述協(xié)調(diào)工作

23、的檢測過程。 3.5.1 開發(fā)控制 (續(xù)) 測試測試 (續(xù)續(xù)) 功能測試功能測試(function test)評估系統(tǒng)以確定集成系統(tǒng)的功能是否同需求規(guī)范中所描述的一樣。測試的結(jié)果是一個功能性系統(tǒng)。 性能測試性能測試(performance test) 將把系統(tǒng)與軟、硬件需求做比較。在功能測試和性能測試期間，檢查了系統(tǒng)的安全需求，確信安全需求與安全性能相一致。 接受測試接受測試(acceptance test) 將檢查系統(tǒng)是否符合用戶的需求規(guī)范。 安裝測試安裝測試(installation test) 將系統(tǒng)安裝在運行環(huán)境中進行最后的測試，確保系統(tǒng)在安裝后仍然具有同樣的功能性。同時，安全需求還經(jīng)

24、常指出系統(tǒng)不應(yīng)該做的事情。 3.5.1 開發(fā)控制 (續(xù)) 測試測試 (續(xù)續(xù)) 此外還有對系統(tǒng)的安全性非常重要的回歸測試回歸測試(regression testing)，目的是確保在系統(tǒng)的功能加強或修復(fù)了某個漏洞后，其他功能仍可以正常運行而不受系統(tǒng)變化的影響。 以上每種測試方法可以采用黑盒測試黑盒測試(black-box testing)和白盒測試白盒測試(white-box testing)。多種技術(shù)的混合使用取決于系統(tǒng)的大小、應(yīng)用領(lǐng)域、風(fēng)險總和等因素。3.5.1 開發(fā)控制 (續(xù)) 測試測試 (續(xù)續(xù)) 獨立測試獨立測試(independent testing)是相當(dāng)必要的，可以預(yù)防開發(fā)者在正常

25、過程中隱藏一些東西，或保留一個子系統(tǒng)不受測試控制中以便將來使用。獨立測試可以增大對隱藏事物的曝光率。 滲透測試滲透測試(penetration testing)是計算機安全中一種獨特的測試類型。在這種測試形式中，測試員盡量讓軟件失敗。也就是說，盡量發(fā)現(xiàn)軟件是否做了它沒有被假定做的事情，測試可能的安全失效。3.5.1 開發(fā)控制 (續(xù)) 良好的設(shè)計良好的設(shè)計 許多與設(shè)計有關(guān)的活動對開發(fā)安全軟件有幫助。 1) 使用容錯技術(shù)容錯技術(shù)(fault tolerance)的哲學(xué)。處理錯誤應(yīng)該盡量減少對系統(tǒng)的破壞且盡量符合安全。錯誤處理通常不應(yīng)該采用被被動故障檢測動故障檢測(passive fault det

26、ection)，而是主動故障檢測主動故障檢測(active fault detection)，還可以利用冗余性冗余性(redundancy)。如果修正錯誤的風(fēng)險太大，則可以應(yīng)用容錯技術(shù)，即安全策略選擇減輕安全問題的影響而不是阻止它的發(fā)生。3.5.1 開發(fā)控制 (續(xù)) 良好的設(shè)計良好的設(shè)計 (續(xù)續(xù)) 2) 使用一致的策略策略(policy)來處理錯誤。典型的錯誤包括：不能提供某個服務(wù)、提供錯誤的服務(wù)或數(shù)據(jù)、損壞數(shù)據(jù)。解決出現(xiàn)的這些問題可以對應(yīng)于每種錯誤采取如下一種方法： 重試重試：將系統(tǒng)恢復(fù)到之前的狀態(tài)，使用其他策略重新運行服務(wù)。 修改修改：將系統(tǒng)恢復(fù)到之前的狀態(tài)，修正一些系統(tǒng)特征，使用相同的策

27、略重新運行服務(wù)。 報告報告：將系統(tǒng)恢復(fù)到之前的狀態(tài)，將問題報告給錯誤處理組件，并不再執(zhí)行服務(wù)。 #這些一致性的策略將有助于查找系統(tǒng)的安全脆弱點。3.5.1 開發(fā)控制 (續(xù)) 良好的設(shè)計良好的設(shè)計 (續(xù)續(xù)) 3) 抓住設(shè)計的基本原理設(shè)計的基本原理(desgin rationale)和歷史記錄。這些文獻有助我們了解采用某種方法創(chuàng)建系統(tǒng)的依據(jù)。 4) 使用設(shè)計模式設(shè)計模式(design pattern)。設(shè)計模式可以對將來的設(shè)計方法提供指導(dǎo)，簡化設(shè)計。3.5.1 開發(fā)控制 (續(xù)) 前景預(yù)測前景預(yù)測 軟件開發(fā)過程中的前景預(yù)測，其預(yù)測內(nèi)容是創(chuàng)建和使用系統(tǒng)的風(fēng)險性。前景預(yù)測可以幫助我們挑選控制方法，以及決

28、定控制的數(shù)量。例如，如果認(rèn)為某個安全分支的風(fēng)險系數(shù)很小，我們就不會投入大量的資金、時間和精力來建立復(fù)雜的控制系統(tǒng)?；蛘?，可以在可能的風(fēng)險沖擊下證明同時使用一系列控制即“深度防御深度防御” (defense in depth)是正確的。 3.5.1 開發(fā)控制 (續(xù)) 靜態(tài)分析靜態(tài)分析 在系統(tǒng)完成運行之前，可以通過檢查設(shè)計和代碼來尋找和修復(fù)安全漏洞。對等復(fù)查涉及這項技術(shù)。但靜態(tài)分析更進一步檢查設(shè)計和代碼的細節(jié)，并在對等復(fù)查之前進行?？梢詮囊韵聨讉€方面檢查設(shè)計和代碼： 控制流結(jié)構(gòu)、數(shù)據(jù)流結(jié)構(gòu)、數(shù)據(jù)結(jié)構(gòu)。3.5.1 開發(fā)控制 (續(xù)) 配置管理配置管理 在開發(fā)軟件時，重要的一點是必須清楚誰誰在什么時候什

29、么時候?qū)κ裁醋隽嗽鯓拥母淖兪裁醋隽嗽鯓拥母淖儯?修改性改變修改性改變：維護系統(tǒng)日常功能的控制 適應(yīng)性改變適應(yīng)性改變：維護控制而對系統(tǒng)的調(diào)整 完善性改變完善性改變：完善已經(jīng)存在的系統(tǒng)功能 預(yù)防性改變預(yù)防性改變：預(yù)防系統(tǒng)性能下降到不能接受的程度3.5.1 開發(fā)控制 (續(xù)) 配置管理配置管理 (續(xù)續(xù)) 配置管理配置管理(configuration management)是在開發(fā)和維護期間用來控制軟件改變的過程，對安全性也十分有利。特別是，配置管理會審查新代碼或改變后的代碼，以確保安全漏洞沒有被有意或無意地插入其中。 配置管理中包含4類活動： 1) 配置鑒定 2) 配置控制和變化管理 3) 配置審查

30、4) 狀態(tài)說明3.5.1 開發(fā)控制 (續(xù)) 配置管理配置管理 (續(xù)續(xù)) 配置鑒定配置鑒定(configuration identification)設(shè)置了一個基線，所有改變后的代碼將與之比較。這就是說，首先創(chuàng)建一個詳細目錄，其中記載了系統(tǒng)的所有組件。然后，“凍結(jié)”該基線并小心地對其加以控制。當(dāng)系統(tǒng)發(fā)生改變時，將被描述為相對基線的改變。 配置控制配置控制(configuration control)和配置管理配置管理(configuration management)確保了可以協(xié)調(diào)不同的相關(guān)版本。這里有三種控制變化的方法：分隔文件分隔文件、delta方法方法和條件編譯條件編譯。分隔文件的方法就是

31、讓不同的系統(tǒng)版本擁有不同的文件。delta方法是指定某個版本為系統(tǒng)的主要版本，再定義其他的不同版本，版本中不同的文件稱為delta，包含一些編輯過的命令行，這些命令行描述了從主版本向其他變異版本的轉(zhuǎn)換方法。條件編譯是在所有版本中都使用同一個代碼組件，而由編譯器來決定哪個版本應(yīng)該使用哪條語句。這種方法似乎對安全應(yīng)用有吸引力，所有代碼都集中管理，如果版本非常復(fù)雜，代碼也就會非常難以閱讀和理解。 3.5.1 開發(fā)控制 (續(xù)) 配置管理配置管理 (續(xù)續(xù)) 配置審查配置審查(configuration audit)可以確保基線是完整和精確的。審查通常使用下面兩種獨立方法中的一種進行的：復(fù)查基線中的每個實

32、體，并將它們與投入使用的系統(tǒng)做比較；或者僅僅從大型系統(tǒng)中抽取小部分做抽樣審查以確保系統(tǒng)的一致性。 狀態(tài)說明狀態(tài)說明(status accounting)將記錄關(guān)于組件的信息，如所有組件的來源、最新版本、修改歷史記錄和未決定的修改申請等等。 3.5.1 開發(fā)控制 (續(xù)) 配置管理配置管理 (續(xù)續(xù)) 上述4類活動由配置和修改控制組配置和修改控制組(CCB, configuration and change control board)統(tǒng)一執(zhí)行。CCB包含系統(tǒng)相關(guān)不同群體代表，負(fù)責(zé)復(fù)查和改進各種修改申請。配置管理通過保護程序和文檔的完整性很好地實現(xiàn)了消除無意的系統(tǒng)威脅并預(yù)防惡意威脅的目標(biāo)。在系統(tǒng)運行階段，開發(fā)人員只能通過CCB來訪問運行成品程序。3.5.1 開發(fā)控制 (續(xù)) 從錯誤中吸取教訓(xùn)從錯誤中吸取教訓(xùn) 在設(shè)計和創(chuàng)建系統(tǒng)時，可以把決定做成文檔，不僅要記錄決定和做出該決定的原因，還要記錄不做出某個決定的原因還要記錄不做出某個決定的原因。從這些信息中，可以創(chuàng)建檢查清單和指導(dǎo)方針幫助系統(tǒng)開發(fā)，保證我們不會犯同樣的錯誤，并使其他系