讀軟體開發安全之道：概念、設計與實施04緩解

1. 緩解

1.1. 安全思維轉換為有效行動的方法就是首先預判威脅，然後針對可能的漏洞加以保護

1.2. 主動響應的做法就叫做“緩解”

• 1.2.1. mitigation

• 1.2.2. 喂寶寶的時候給孩子圍上圍嘴，避免掉下來的食物粘在寶寶的衣服上，還有安全帶、限速、火災警報、食品安全操作規範、公共衛生措施和工業安全法規，這些統統都屬於緩解措施

• 1.2.3. 降低問題的嚴重性、危害性或者縮小影響範圍

• 1.2.4. 都透過主動採取手段來規避或者減少風險所帶來的預期損失

1.3. 緩解措施可以降低風險，但不能徹底消除風險

• 1.3.1. 如果我們可以設法徹底消除風險​，那無論如何都應該採取這樣的措施

• 1.3.2. 比如，刪除了一個不安全的舊特性

1.4. 緩解措施關注的是降低攻擊發生的可能性，提升發起攻擊的難度，或者降低攻擊造成的危害

1.5. 那些讓利用漏洞的操作更容易被檢測出來的措施也可以算是緩解措施

• 1.5.1. 給自己的商品採用防篡改包裝一樣，它們都可以促成人們更快做出反應並且進行補救

1.6. 每一項微小的努力都可以提高整個系統的安全性，即使是有限的勝利也可以不斷改善系統，構成更理想的保護措施

2. 解決威脅

2.1. 威脅建模可以向我們展示哪裡可能出現問題，這樣我們就可以把安全的重心放在“刀刃”上

2.2. 明確風險點（即重要事件或者決策閾值）才是緩解風險的最好機會

• 2.2.1. 我們永遠應該首先解決那些最重大的風險，對它們進行最大程度的限制

• 2.2.2. 對於那些處理敏感個人資訊的系統，未經授權而洩露資訊的威脅總是如影隨形

2.3. 手段

• 2.3.1. 把能夠訪問這類資料的範圍降至最低

• 2.3.2. 減少收集的資訊總量

• 2.3.3. 主動刪除那些不會再使用的過時資料

• 2.3.4. 在出現入侵事件的情況下透過審計執行早期檢測

• 2.3.5. 採取行動來降低攻擊者洩露資料的能力

2.4. 對最高安全級別的風險提供了保護之後，我們需要有選擇地對較低程度的風險進行緩解

• 2.4.1. 只要緩解手段不會增加太多負擔，也不會增加設計的複雜性

2.5. 例子

• 2.5.1. 將每次登入時提交的密碼與加鹽密碼雜湊值(salted hash)進行比較，而不是與明文的真實密碼進行比較

• 2.5.1.1. 可以避免儲存明文密碼

• 2.5.1.2. 哪怕攻擊者入侵了系統，他們也無法獲得實際的密碼

2.6. 只要有機會就要降低風險

3. 把攻擊面減到最小

3.1. 一旦我們判斷得出一個系統的攻擊面，我們就知道利用漏洞的行為最有可能源自哪裡，因此我們採取的一切可以加固系統“外部城牆”的行為都是一場重大的勝利

• 3.1.1. 考慮每個入口點下游涉及多少程式碼和資料

• 3.1.2. 可以讓包含漏洞的程式碼數量更少

3.2. 在客戶端/伺服器系統中，我們可以把伺服器的功能推送給客戶端，這樣就可以減小伺服器的攻擊面

• 3.2.1. 如果客戶端擁有必要的資訊和計算資源，就不僅可以減少伺服器的負載，還可以減小伺服器的攻擊面

3.3. 把功能從一個面向公眾、任何人都可以匿名呼叫的API轉移到需要進行認證的API，也可以有效地減小攻擊面

• 3.3.1. 建立賬戶不僅可以減緩攻擊速度，也可以追蹤攻擊者，還可以實施速率限制

3.4. 使用核心服務的庫和驅動器可以透過最小化核心內部程式碼和連線核心的介面來達到減小攻擊面的目的

• 3.4.1. 不僅有更少的核心轉換被攻擊，而且即使攻擊取得了成功，使用者態程式碼也無法造成大規模的破壞

3.5. 部署和運維都可以提供很多減小攻擊面的機會

• 3.5.1. 最簡單的做法就是把所有資源都挪到防火牆的後面

3.6. 透過網路進行遠端管理的設定也是一例

• 3.6.1. 如果使用率不高，就應該考慮禁用這類特性，只在必要的情況下使用有線接入的方式發起訪問

3.7. 不斷思考各種方法來減少外部訪問、把功能和介面減到最少，對那些不需要暴露給公眾的服務提供保護

• 3.7.1. 我們越是能夠理解一個特性應該應用在哪裡、應該如何應用，我們就可以找到越多的緩解手段

4. 縮小漏洞視窗

4.1. 縮小漏洞視窗類似於減小攻擊面，但是這種策略的目標並不是減小承受攻擊的範圍，而是把漏洞有可能出現的有效時間間隔減到最小

• 4.1.1. 獵手會在射擊之前開啟保險，然後在射擊之後重新掛上保險一樣

4.2. 低信任資料或者請求與高信任程式碼進行互操作的那個地方

• 4.2.1. 為了能夠更好地隔離高信任程式碼，我們需要把這些程式碼的執行操作減到最少

• 4.2.2. 應該在呼叫高信任程式碼之前首先執行錯誤校驗，確保程式碼可以繼續完成工作後退出

4.3. 程式碼訪問安全

• 4.3.1. Code Access Security，CAS

• 4.3.2. 一種如今已經很少使用的安全模型，它完美地說明了縮小漏洞視窗這種緩解措施，因為它提供了對程式碼有效許可權的細粒度控制

4.4. 重要的限制手段包括限制時間視窗、限制地理位置、僅限制賬戶內金額等

• 4.4.1. 所有這些緩解手段都有助益，因為這些手段會避免出現入侵行為時發生最壞的情況

5. 把暴露的資料減到最少

5.1. 針對資料洩露的結構性緩解策略是限制記憶體中敏感資料的儲存時間

5.2. 把資料的生命週期減到最小，而不是限制程式碼以高許可權執行的時間

• 5.2.1. 私鑰或者密碼之類的認證憑據，我們應該在不需要這些資料的時候，立刻在記憶體中把它們覆蓋掉，這樣做是絕對值得的

5.3. Heartbleed漏洞威脅到大量網頁的安全，暴露了儲存空間的各類敏感資料

• 5.3.1. 限制這種敏感資料的保留時間完全可以成為一種合理的緩解措施

• 5.3.1.1. 有可能的話，應該先止損​

5.4. 主動清除資料副本是一種極端的情況，這種操作只應該針對那些最敏感的資料，或者僅在關閉賬戶這種重要操作發生時執行

6. 訪問策略與訪問控制

6.1. 標準的作業系統許可權機制都會提供非常基本的檔案訪問控制

• 6.1.1. 這些許可權根據程序的使用者和組的所有權，採用全有或全無的方式來控制讀（機密性）或寫（完整性）訪問

6.2. Web服務和微服務被設計為代表那些一般不對應程序所有者的主體來工作

• 6.2.1. 一個程序會對所有透過了認證的請求提供服務，並要求獲得許可權來訪問所有客戶端資料

• 6.2.2. 只要存在漏洞，所有客戶端資料就都有風險

6.3. 縮小“可以訪問的資源”與“系統正好允許訪問的資源”之間的差異

• 6.3.1. 可以限制每分鐘或者每小時的訪問次數

• 6.3.2. 實施最大的資料量限制

• 6.3.3. 實施與工作時間相對應的時間限制策略

• 6.3.4. 根據同行的策略或者歷史資料來採取可變的訪問限制

6.4. 確定安全訪問限制是一項艱難的工作，但是絕對物超所值，因為這可以幫助我們理解應用的安全需求

6.5. 在設定策略的時候留有餘地，避免嚴格的策略妨礙了人們的正常工作

• 6.5.1. 讓個別代理人員提交合理的解釋，從而在短時間內提升針對自己的限制值

• 6.5.2. 透過設定這種“減壓閥”​，我們就可以對基本的訪問策略實施嚴格的限制

• 6.5.3. 申請可以接受審計，如果這種申請次數越來越多，管理人員就應該研究需求是否已經提升，以及需求提升的原因，並且在掌握了這些情況的基礎上對限制值進行放鬆

• 6.5.4. 使用軟限制來建立訪問策略，而不用拍腦袋想出來的引數執行“一刀切”政策

7. 介面

7.1. 安全分析中的重中之重

7.2. 介面可以揭示資料流和控制流

7.3. 介面會充當明確定義的資訊節點，我們就應該在這裡實施緩解措施

• 7.3.1. 只要存在信任邊界，那麼最主要的安全關注點都應該著眼於資料流和控制流從低信任元件流向高信任元件的地方

7.4. 在大型系統中，網路之間、程序之間，甚至程序內部一般都會包含介面

• 7.4.1. 端點裝置之間的互動幾乎必然會透過線路來完成，其他型別的介面情況更加複雜

• 7.4.2. 程序之間通訊介面的可信度幾乎和網路介面的別無二致

• 7.4.2.1. 程序間的通訊和網路介面也就成了威脅建模的主要焦點

7.5. 從攻擊者的角度看，程序內的邊界是非常容易突破的

7.6. 所有大型軟體的設計方案都面臨相同的問題，那就是如何構建元件才能把高許可權訪問的區域降到最低限度，以及如何限制敏感資訊流從而減小安全風險

• 7.6.1. 把資訊訪問限制到一個最小的元件範圍，相關元件又得到了良好的隔離，那麼攻擊者想要訪問敏感資料，難度就會大得多

7.7. 介面架構是決定系統能否成功保護資產的核心因素

8. 通訊

8.1. 通訊對幾乎任何軟體系統都是基本元件，當然這裡的通訊包括網際網路絡通訊、私有網路通訊，或者透過藍芽、USB等協議實現的外圍連線通訊

• 8.1.1. 要麼通道在物理上足夠安全，針對竊聽和嗅探提供了防護手段

• 8.1.2. 要麼資料進行了加密，使資料的完整性和機密效能夠得到保障

8.2. 物理安全往往都不十分可靠，因為只要攻擊者繞過了這些物理安全防護手段，往往就能夠訪問到完整的資料，而且這種入侵方式很難被發現

8.3. 現有計算負載的基礎上增加加密運算也沒有什麼問題，所以不對通訊進行加密的理由一般都不怎麼充分

8.4. 哪怕是最好的加密措施也不是什麼靈丹妙藥，因為還有一種威脅存在，那就是加密無法掩飾通訊的發生

• 8.4.1. 如果攻擊者可以讀取到通道中的原始資料，即使他們無法對資料的內容進行解密，也可以看到有資料在通道中進行收發，因此也就可以粗略地估算出資料總量

• 8.4.2. 如果攻擊者可以對通訊通道進行篡改，他們就有可能讓通訊造成延遲，甚至直接阻塞通訊傳輸

9. 儲存

9.1. 儲存資料就相當於把資料傳送給“未來”​，以備人們在未來提取使用

9.2. 儲存介質中的靜態資料很容易遭到攻擊，就像線上纜中傳輸的通訊資料很容易遭到攻擊一樣

• 9.2.1. 保護靜態資料不受篡改和洩露需要同時藉助物理安全措施和加密

• 9.2.2. 所儲存資料的可用性也依賴資料備份或者物理層面的保護措施

9.3. 在系統設計方案中，儲存同樣是無處不在的，這類系統常常把保護資料安全的具體措施推遲到操作的時候再來處理，這就會錯失在設計方案中減少資料丟失的機會

9.4. 我們備份的既可以是完整的資料集，也可以是增量資料、互動記錄，這些資訊累加起來就可以準確地重建資料

• 9.4.1. 它們都應該進行獨立、可靠的儲存，並且按照一定的頻率進行備份，同時保證延遲時間在合理範圍之內

• 9.4.2. 雲架構可以用近乎實時的方式提供冗餘資料複製功能，這可能就是最理想的連續備份解決方案，當然這種解決方案不是免費的

9.5. 所有靜態資料（包括備份資料）都存在被非法訪問的風險，所以我們必須在物理上對資料進行保護或者加密

• 9.5.1. 我們建立的備份資料越多，洩露的風險也就越大，因為每份副本都有可能洩露

• 9.5.2. 要求我們在資料丟失風險和資料洩露風險之間進行權衡，我們不可能同時把兩種風險都降到最低，但是我們可以用很多方式來判斷兩種風險之間最理想的平衡點

9.6. 推薦大家使用那些廣泛使用的開放標準，因為一旦官方不再支援私有格式，就只能進行逆向工程了

• 9.6.1. 儲存的時間週期越長，轉換檔案格式的必要性就越高，因為軟體標準是在不斷進化的，應用也會放棄對“古老”格式的支援