讀軟件開發(fā)安全之道：概念、設(shè)計與實施03威脅.png

1. 威脅

1.1. 威脅常常比事件本身更加可怖

• 1.1.1. 索爾·阿林斯基

1.2. 威脅無處不在

• 1.2.1. 如果妥善管理，我們也可以安然與威脅共存

• 1.2.2. 我們自己沒有幾百萬年進(jìn)化而來的本能來防御軟件方面的威脅

1.3. 把視角從軟件構(gòu)建者轉(zhuǎn)向攻擊者

• 1.3.1. 理解一個系統(tǒng)的潛在風(fēng)險是一切的起點

• 1.3.2. 在軟件設(shè)計中加入可靠的防御和緩解措施

1.4. 軟件的本質(zhì)：它是由一堆代碼和組件構(gòu)成的，這些代碼和組件承擔(dān)著數(shù)據(jù)處理和存儲的職責(zé)

1.5. 威脅包含各種可以帶來傷害的方式

• 1.5.1. 刻意發(fā)動的對抗性攻擊行為

• 1.5.2. 軟件錯誤

• 1.5.3. 人為錯誤

• 1.5.4. 意外事故

• 1.5.5. 硬件故障

1.6. 很難窮舉大型軟件系統(tǒng)的所有威脅和漏洞

• 1.6.1. 高明的安全工作是逐步提高標(biāo)準(zhǔn)，而不是追求盡善盡美

• 1.6.2. 我們恐怕從來都對那些遭到挫敗的攻擊一無所知，而缺乏反饋機(jī)制往往會讓人倍感失望

• 1.6.3. 我們展現(xiàn)出來的安全意識越強(qiáng)，我們就可以看到越多的威脅

1.7. 理解威脅建?？梢宰屛覀儼岩曇皬陌踩陨蠑U(kuò)展出去，從而重新審視我們的目標(biāo)系統(tǒng)

2. 對抗性視角

2.1. 人類肇事者才是萬惡之源

• 2.1.1. 安全事件不會自己無緣無故地發(fā)生

2.2. 只要對軟件安全性進(jìn)行協(xié)同分析，就一定要考慮可能的對手會進(jìn)行什么樣的嘗試，這樣才能預(yù)測和防御潛在的攻擊

• 2.2.1. 不要自欺欺人地認(rèn)為自己可以準(zhǔn)確地預(yù)測對手的一舉一動

• 2.2.2. 不要花費(fèi)大量時間和精力去猜測他們的具體想法

• 2.2.3. 不要自以為是永遠(yuǎn)比對手棋高一著的名偵探

2.3. 了解攻擊者的思考方式的確有其價值，但我們的目標(biāo)是開發(fā)安全軟件，所以攻擊者具體會通過什么技術(shù)手段來探測、滲透和泄露數(shù)據(jù)無關(guān)緊要

2.4. 軟件錯誤絕對是攻擊者重點關(guān)注的對象，因為它們往往就是軟件的弱點所在

• 2.4.1. 攻擊者如果偶然發(fā)現(xiàn)了某些明顯的軟件錯誤，他們就會嘗試創(chuàng)建一些變體，看看能不能造成實實在在的破壞

• 2.4.2. 一旦攻擊者發(fā)現(xiàn)了漏洞，他們就很有可能把更多時間和精力放在這個漏洞上，因為很多瑕疵都可以被攻擊者借助協(xié)同攻擊擴(kuò)展出嚴(yán)重的后果

2.5. 兩項幾乎不會引人注意的細(xì)微漏洞如果結(jié)合在一起，就可以制造出一次重大的攻擊，因此我們應(yīng)該嚴(yán)肅對待一切漏洞

2.6. 攻擊一個系統(tǒng)可能獲得的收益越高，人們就越有可能應(yīng)用更多的技術(shù)和資源來對這個系統(tǒng)發(fā)起攻擊

• 2.6.1. 政府、軍方、大型企業(yè)和金融機(jī)構(gòu)的系統(tǒng)都是重大的攻擊目標(biāo)

2.7. 與一切形式的攻擊行為一樣，攻擊的難度總是小于抵御攻擊的難度

• 2.7.1. 攻擊者只需要選擇好切入點，然后下定決心去利用盡可能多的漏洞就可以了，因為攻擊者其實只需要成功一次就夠了

• 2.7.2. 防守方需要善加利用所有可用的優(yōu)勢

3. 4個問題

3.1. 我們的工作是什么？

• 3.1.1. 旨在建立項目的背景和范圍

3.2. 哪里有可能出錯？

• 3.2.1. 旨在盡可能地判斷有可能發(fā)生的問題

3.3. 我們打算怎么辦？

• 3.3.1. 旨在設(shè)法緩解我們發(fā)現(xiàn)的問題

3.4. 我們干得怎么樣？

• 3.4.1. 旨在讓我們對整個流程發(fā)問

  • 3.4.1.1. 軟件承擔(dān)了什么工作

  • 3.4.1.2. 軟件可能產(chǎn)生什么問題

  • 3.4.1.3. 我們在應(yīng)對這些威脅的時候發(fā)揮得如何

4. 威脅建模

4.1. 哪里有可能出錯？

• 4.1.1. 在安全領(lǐng)域，這個問題毫無反諷的意味，它簡潔地表達(dá)了威脅建模的出發(fā)點

4.2. 威脅建模的基本流程

• 4.2.1. 從系統(tǒng)模型出發(fā)，確保我們對整個系統(tǒng)范疇內(nèi)的要求全都進(jìn)行了考量

• 4.2.2. 判斷系統(tǒng)中需要加以保護(hù)的資產(chǎn)（包括有價值的數(shù)據(jù)和資源）

• 4.2.3. 逐個組件地搜索系統(tǒng)模型，尋找潛在的威脅，判斷攻擊面（即攻擊的起源地）、信任邊界（連接系統(tǒng)可靠組件和不可靠組件的接口）以及不同類型的威脅

• 4.2.4. 按照確定性從高到低的順序，依次分析這些潛在的威脅

• 4.2.5. 按照嚴(yán)重性從高到低的順序，依次對威脅進(jìn)行評分

• 4.2.6. 對最嚴(yán)重的威脅提出降低風(fēng)險的緩解措施

• 4.2.7. 從效果最好、實施最簡單的方法開始，不斷增加緩解措施，直至看到實際的效果

• 4.2.8. 從最關(guān)鍵的威脅開始，逐個測試緩解措施的效果

4.3. 在實踐當(dāng)中，第一次威脅建模只應(yīng)該關(guān)注那些針對高價值資產(chǎn)的重大、高風(fēng)險威脅

4.4. 人們在日常生活中都會根據(jù)本能，做一些類似于威脅建模的工作，采取符合一般常識的預(yù)防性措施

• 4.4.1. 在別人能聽到的地方說話就是攻擊面，用無聲的輸入法代替語言表達(dá)就是一種行之有效的緩解措施

4.5. 雖然我們在現(xiàn)實生活中會自然而然地采取這樣的行動，但是把這些方法應(yīng)用到我們本能還不能覆蓋的復(fù)雜軟件系統(tǒng)上則需要制定更多的規(guī)則

4.6. 威脅建模會使用數(shù)據(jù)流圖(Data Flow Diagram，DFD)或者統(tǒng)一建模語言(Unified Modeling Language，UML)

• 4.6.1. 更加正式的方法往往更加嚴(yán)格，輸出的結(jié)果也更加準(zhǔn)確

4.7. 比較理想的軟件可以把工作中最重要的內(nèi)容全部自動化

• 4.7.1. 解釋輸出的結(jié)果并且進(jìn)行風(fēng)險評估還是需要人工介入

4.8. 按照Goldilocks原則選擇合適的粒度

• 4.8.1. 不要摻雜過多的細(xì)節(jié)（否則工作永遠(yuǎn)也做不完）

• 4.8.2. 不要太過提綱挈領(lǐng)（否則我們會忽略很多重要的細(xì)節(jié)）

• 4.8.3. 如果這項工作很快就完成了，但我們還是沒有獲得針對目標(biāo)系統(tǒng)的太多信息，這就很可能表示粒度不夠

• 4.8.4. 如果我們埋頭苦干了幾個小時之后，發(fā)現(xiàn)距離成果還有十萬八千里，就說明粒度有些過高了

5. 判斷資產(chǎn)

5.1. 資產(chǎn)是指系統(tǒng)中我們必須加以保護(hù)的實體

• 5.1.1. 大多數(shù)資產(chǎn)都是數(shù)據(jù)，但是資產(chǎn)也有可能包含硬件、通信帶寬、計算資源和其他物理資源（如電能等）等

• 5.1.2. 威脅建模的初學(xué)者一般都希望對所有資產(chǎn)統(tǒng)統(tǒng)加以保護(hù)

• 5.1.3. 在實際工作中，我們需要對自己的資產(chǎn)進(jìn)行優(yōu)先級排序

• 5.1.4. 應(yīng)該始終確保內(nèi)部系統(tǒng)日志是保密的

  • 5.1.4.1. 讓管理員成為唯一可以讀取日志內(nèi)容的賬戶

• 5.1.5. 應(yīng)該保證將有限的精力優(yōu)先投入到需要加以保護(hù)的資產(chǎn)上

5.2. 建議不要試著去做復(fù)雜的風(fēng)險評估計算

5.3. 對資產(chǎn)進(jìn)行優(yōu)先級排序其實有一種簡單而且非常高效的方式，那就是通過“襯衫尺碼”來對它們進(jìn)行排序

• 5.3.1. 需要進(jìn)行優(yōu)先級排序的資產(chǎn)應(yīng)該包含客戶資源、個人信息、企業(yè)文檔、操作日志和軟件代碼等，當(dāng)然這些只是一部分高優(yōu)先級資產(chǎn)

• 5.3.2. 不同數(shù)據(jù)泄露、篡改和破壞帶來的負(fù)面影響也大不相同

5.4. 如果我們把資產(chǎn)集中起來，就可以大幅簡化我們的分析工作，不過我們也要注意在這個過程中不能錯失重要的信息

5.5. 一定要從各方的角度分別考慮資產(chǎn)的價值

• 5.5.1. 資產(chǎn)中每一項的價值都取決于你在這家公司扮演的角色是CEO、廣告人員、客戶，還是希望從網(wǎng)絡(luò)攻擊中攫取經(jīng)濟(jì)利益或者政治回報的黑客

• 5.5.2. 即使是客戶，不同的客戶對通信中的數(shù)據(jù)隱私和數(shù)據(jù)價值也有不同的理解

• 5.5.3. 優(yōu)秀的數(shù)據(jù)管理原則規(guī)定，對客戶和合作伙伴的數(shù)據(jù)所提供的保護(hù)應(yīng)該超過對自己企業(yè)數(shù)據(jù)提供的保護(hù)

6. 判斷攻擊面

6.1. 我們應(yīng)該考慮盡一切可能縮小攻擊面，因為這樣可以徹底消弭潛在的攻擊源

6.2. 很多攻擊都有可能在整個系統(tǒng)中散布出去，所以盡早防御這類攻擊才是最好的防御方式

• 6.2.1. 安全的政府大樓都會把配備金屬探測器的檢驗裝置放在大樓唯一的公共入口處

6.3. 軟件設(shè)計往往比設(shè)計一棟物理大樓要復(fù)雜得多，所以判斷整個攻擊面也殊非易事

6.4. 應(yīng)該把內(nèi)部網(wǎng)絡(luò)看成一個風(fēng)險比較小的攻擊面

6.5. 攻擊面不局限于數(shù)字世界內(nèi)部

• 6.5.1. 攻擊者甚至可以執(zhí)行側(cè)信道攻擊(side-channel attack)，即通過檢測系統(tǒng)發(fā)出的電磁信號、熱量、功耗甚至鍵盤的聲音等信息，來推測系統(tǒng)內(nèi)部的狀態(tài)

7. 判斷信任邊界

7.1. 信任和權(quán)限總是相互關(guān)聯(lián)的，所以我們也可以把信任邊界理解為權(quán)限邊界

• 7.1.1. 信任和權(quán)限是高度相關(guān)的：只要信任度夠高，權(quán)限往往也就很高，反之亦然

7.2. 如果在人類社會中給信任邊界進(jìn)行類比，那么信任邊界可以類比公司經(jīng)理（了解更多內(nèi)部信息）和員工之間的信息差，或者你家的大門（你可以選擇誰能夠進(jìn)入你的家門）

7.3. 操作系統(tǒng)的內(nèi)核-用戶界面就是信任邊界的經(jīng)典示例

• 7.3.1. 系統(tǒng)會啟動內(nèi)核

• 7.3.2. 內(nèi)核會把應(yīng)用隔離在不同的用戶處理實例當(dāng)中

  • 7.3.2.1. 不同的用戶處理實例對應(yīng)不同的用戶賬戶

• 7.3.3. 這樣就可以避免各個用戶相互干擾，或者整個系統(tǒng)徹底崩潰

7.4. 安全外殼(Secure Shell，SSH)守護(hù)進(jìn)程(sshd)是一個理想的、采用了信任邊界的安全設(shè)計示例

• 7.4.1. 為了能夠接收SSH登錄請求，守護(hù)進(jìn)程必須為通信創(chuàng)建一條安全的信道（在這條信道中傳輸?shù)臄?shù)據(jù)不會被嗅探或者篡改），然后才能處理和驗證敏感的證書

• 7.4.2. 需要調(diào)用大量代碼、使用最高的優(yōu)先級運(yùn)行程序（這樣才能為所有用戶賬戶創(chuàng)建進(jìn)程）

• 7.4.3. 入站的請求可以來自互聯(lián)網(wǎng)的任何一個角落，而請求是否是攻擊行為一開始根本無從判斷，所以我們很難找到更有吸引力的目標(biāo)

7.5. 在一個操作系統(tǒng)中，超級用戶固然應(yīng)該擁有最高級別的信任，其他管理員用戶也可以考慮獲得類似級別的權(quán)限

• 7.5.1. 訪客賬戶的信任級別一般都是最低的，而且我們可能更需要針對這類用戶來保護(hù)我們的系統(tǒng)，而不是去保護(hù)這類用戶的資源

7.6. Web服務(wù)器需要有能力抵御惡意客戶端用戶，因此Web前端系統(tǒng)往往會對入站的流量進(jìn)行驗證，并且只轉(zhuǎn)發(fā)那些合法的請求，這就有效地建立起了與互聯(lián)網(wǎng)之間的信任邊界

7.7. 在信任邊界的兩邊，一定要通過定義明確的接口和協(xié)議來提供轉(zhuǎn)換和過渡

7.8. 最大的風(fēng)險往往隱藏在從低信任區(qū)域向高信任區(qū)域過渡的地方

• 7.8.1. 不代表我們就可以忽視那些從高信任區(qū)域向低信任區(qū)域過渡的場景

• 7.8.2. 只要我們的系統(tǒng)還在向那些信任度比較低的組件發(fā)送數(shù)據(jù)，我們就應(yīng)該考慮信息泄露的可能性和出現(xiàn)其他問題的可能性

• 7.8.3. 不要用敏感的信息來命名計算機(jī)，這樣會讓攻擊者得到重要的提示，從而有機(jī)會在系統(tǒng)上運(yùn)行代碼來對系統(tǒng)實施入侵

• 7.8.4. 只要高信任服務(wù)會代表低信任請求來運(yùn)作，這個系統(tǒng)就有遭到DoS攻擊的風(fēng)險

  • 7.8.4.1. 用戶請求方可能會通過這種方式讓系統(tǒng)內(nèi)核過載

8. 判斷威脅

8.1. 威脅往往會集中在重要資產(chǎn)和信任邊界周圍，但是也有可能出現(xiàn)在系統(tǒng)的任何一個地方

8.2. 系統(tǒng)的主要威脅會集中于我們的資產(chǎn)和系統(tǒng)的信任邊界

8.3. 即使很小的威脅也有可能需要我們采取措施進(jìn)行緩解

• 8.3.1. 是否需要采取措施取決于這些威脅有多大的可能性會發(fā)展成嚴(yán)重的問題，以及它所針對的資產(chǎn)有多高的價值

8.4. STRIDE關(guān)注的重點是判斷威脅的過程

• 8.4.1. STRIDE只是對軟件面臨的威脅進(jìn)行了分類

8.5. STRIDE中有一半的威脅屬于對基礎(chǔ)信息安全的直接威脅

• 8.5.1. 信息泄露針對的是機(jī)密性

• 8.5.2. 篡改針對的是完整性

• 8.5.3. 拒絕服務(wù)則旨在破壞信息的可用性

8.6. STRIDE的另一半針對的是黃金標(biāo)準(zhǔn)

• 8.6.1. 欺騙是通過建立虛假的身份來破壞真實性

• 8.6.2. 權(quán)限提升破壞的是正確的授權(quán)

• 8.6.3. 抵賴則是對審計的威脅

  • 8.6.3.1. 避免抵賴這種威脅的方法是讓管理員和用戶明白，他們都要對自己的行為負(fù)責(zé)

  • 8.6.3.2. 他們都知道系統(tǒng)中有一份準(zhǔn)確的審計記錄

9. 緩解威脅

9.1. 通過重新設(shè)計或者增加防御的方式來緩解威脅，從而減少威脅的發(fā)生，或者把威脅造成的傷害降到可以接受的程度

9.2. 如果受到威脅的資產(chǎn)不是必要的信息，就直接把這些信息刪除

• 9.2.1. 如果不可能刪除這些信息，就努力降低這些信息暴露的可能性，或者對可能增加威脅性的可選特性進(jìn)行限制

9.3. 把一些責(zé)任交給第三方，從而轉(zhuǎn)移風(fēng)險

9.4. 在充分理解風(fēng)險之后，接受風(fēng)險的存在，承認(rèn)風(fēng)險的發(fā)生自有其合理性

9.5. 部分緩解措施

• 9.5.1. 降低傷害發(fā)生的概率：讓攻擊只可能在一小段時間內(nèi)發(fā)生

• 9.5.2. 降低傷害的嚴(yán)重程度：讓攻擊只能破壞一小部分?jǐn)?shù)據(jù)

• 9.5.3. 設(shè)法逆轉(zhuǎn)傷害：確保我們可以從備份文件中輕松恢復(fù)所有丟失的數(shù)據(jù)

• 9.5.4. 設(shè)計傷害正在發(fā)生的信號：使用防篡改的包裝，當(dāng)產(chǎn)品遭到篡改的時候能夠輕松發(fā)現(xiàn)篡改已經(jīng)發(fā)生，從而對消費(fèi)者提供保護(hù)

  • 9.5.4.1. 在軟件領(lǐng)域，良好的日志記錄可以起到這樣的效果

10. 隱私方面

10.1. 針對隱私的威脅手段與其他安全威脅手段一樣真實

• 10.1.1. 在對系統(tǒng)面臨的威脅進(jìn)行完整的評估時，這些針對隱私構(gòu)成威脅的方式需要進(jìn)行單獨的分析

• 10.1.2. 這類威脅在信息泄露的風(fēng)險中增加了人為因素

10.2. 我們應(yīng)該把自己看成個人信息的管家，努力從用戶的角度進(jìn)行考慮，包括認(rèn)真考慮用戶關(guān)注的隱私安全問題，并且為了避免用戶隱私泄露，怎么關(guān)注都不為過

10.3. 隨著人們的生活日趨數(shù)字化，移動計算設(shè)備已經(jīng)無處不在，隱私也越來越依賴這些代碼，未來如何發(fā)展殊難預(yù)料

• 10.3.1. 最明智的做法是保持高度警惕，并且始終站在時代浪潮的潮頭

10.4. 降低隱私威脅的一般解決方案

• 10.4.1. 對真實的用戶案例進(jìn)行建模，然后對隱私進(jìn)行評估，而不要僅思考抽象的內(nèi)容

• 10.4.2. 學(xué)習(xí)所應(yīng)用的隱私策略或法規(guī)，然后嚴(yán)格遵守這些條款

• 10.4.3. 通過限制手段，保證只有在必要的情況下才收集數(shù)據(jù)

• 10.4.4. 對看起來后果非常嚴(yán)重的威脅保持警惕

• 10.4.5. 不要在沒有清晰使用意圖的情況下收集或者保存隱私信息

• 10.4.6. 當(dāng)收集到的信息不需要繼續(xù)使用的時候，要主動刪除這些信息

• 10.4.7. 減少敏感信息的泄露

  • 10.4.7.1. 在理想情況下，敏感信息只能分享給需要知道的人

• 10.4.8. 減少與第三方共享的信息

  • 10.4.8.1. 如果存在這類信息，應(yīng)該用文檔進(jìn)行詳細(xì)的記錄

• 10.4.9. 要保持透明，讓終端用戶理解自己的數(shù)據(jù)保護(hù)措施