1. 漏洞管理

1.1. 漏洞的利用可能會導致災難恢復的場景，因此，必須首先建立一個能夠防止漏洞被利用的系統

1.2. 建立一個漏洞管理流程，該流程可用於識別漏洞並幫助緩解這些漏洞威脅

1.3. 一個系統不可能百分之百安全，但是可以採取一些措施使黑客難以完成他們的任務

1.4. 漏洞管理階段的最大挑戰是缺乏可用信息

• 1.4.1. 一些組織沒有記錄其政策、程序、策略、流程和安全資產，因此可能很難獲得完成這一階段所需的信息

• 1.4.2. 大公司有多個業務部門，缺乏足夠的資源和嚴謹的文檔，而且職責交叉重疊

• 1.4.3. 唯一解決方案是，定期進行內務管理活動以確保所有重要的事情都記錄在案，且每名員工都清楚地理解自身的職責

2. 創建漏洞管理策略

2.1. 為確保擁有健康的安全項目並降低組織風險，組織必須有效地識別、評估和補救弱點

2.2. 漏洞管理旨在減少組織暴露，強化攻擊表面區域，提高組織彈性

2.3. 最佳方法是使用漏洞管理生命週期

• 2.3.1. 以有序的方式規劃所有漏洞緩解過程

• 2.3.2. 使網絡安全事件的目標和受害者能夠減輕已經造成或可能造成的損害

• 2.3.3. 在正確的時間執行正確的應對措施，以便在攻擊者濫用漏洞之前發現並解決這些漏洞

3. 階段

3.1. 資產盤點

• 3.1.1. 編制資產目錄

• 3.1.1.1. 資產目錄被描述為該策略的關鍵，因為它列出了有關主機的所有詳細信息以幫助用户徹底清理所有可能存在漏洞的計算機

• 3.1.2. 資產目錄是一個網絡中所有主機和所含軟件的登記冊

• 3.1.3. 至少應該顯示一個組織所擁有的硬件和軟件資產，以及它們的相關許可細節

• 3.1.4. 還應該顯示這些資產中存在的漏洞

• 3.1.5. 許多組織缺乏有效的資產登記，因此在保護其設備時很困難

• 3.1.6. 讓一名員工負責管理資產目錄以確保記錄所有設備，並確保目錄保持最新

• 3.1.7. 資產目錄也是網絡和系統管理員用來快速查找和修補設備和系統的強大工具

• 3.1.7.1. 如果沒有目錄，在修補或安裝新的安全軟件時，可能會遺漏一些設備，它們將會成為攻擊者攻擊的目標設備和系統

• 3.1.8. 缺乏資產目錄還可能導致組織在安全方面的支出不足或超支

• 3.1.8.1. 無法正確確定需要為其購買保護服務的設備和系統

• 3.1.8.2. 組織也缺乏有效確保一致性的資產目錄維護工具

3.2. 信息管理

• 3.2.1. 控制信息如何流入組織

• 3.2.2. 最關鍵的信息流是來自組織網絡的互聯網流量

• 3.2.2.1. 組織需要防範的蠕蟲、病毒和其他惡意軟件威脅數量不斷增加

• 3.2.2.2. 本地網絡內部和外部的流量也有所增加

• 3.2.2.3. 不斷增加的流量可能會給組織帶來更多惡意軟件

• 3.2.2.4. 應該注意這種信息流以防止威脅進入或離開網絡

• 3.2.3. 目標應該是建立一種有效的方式，在儘可能短的時間內向相關人員提供有關漏洞和網絡安全事件的信息

• 3.2.4. 在這個階段結束時，如果系統遭遇破壞，事件響應者和其他用户之間應該有一個精心設計的溝通渠道

• 3.2.5. 存在競爭關係的組織可以通過獲得對方的秘密配方、原型和商業秘密，從而勝過對方

• 3.2.5.1. 信息管理在漏洞管理策略中至關重要

• 3.2.6. 為了實現有效的信息管理，組織可以部署計算機安全事件響應小組(Computer Security Incident Response Team，CSIRT)來處理其信息存儲和傳輸面臨的威脅

• 3.2.7. 在訪問信息時，組織可以採用最低權限的策略

• 3.2.7.1. 此策略確保拒絕用户訪問除履行職責所必需的信息之外的所有信息

• 3.2.7.2. 減少訪問敏感信息的人數是減少攻擊途徑的有力措施

• 3.2.8. 建立檢測和阻止惡意人員訪問文件的機制

• 3.2.8.1. 可以確保拒絕惡意流量進入，並在發現諸如監聽之類的可疑活動時進行報告

• 3.2.8.2. 還可以安裝在最終用户設備上，以防止非法複製或讀取數據

• 3.2.9. 所有這些挑戰共同影響組織在面對潛在的或已驗證的黑客企圖的情況下可以採取的行為和擁有的響應時間

• 3.2.9.1. 將合法告警視為誤報而不予理睬並不令人意外

• 3.2.9.2. 進出組織網絡的流量也變得複雜起來

3.3. 風險評估

• 3.3.1. 在降低風險之前，安全小組應該對其面臨的威脅和漏洞進行深入分析

• 3.3.2. 在理想的IT環境中，安全小組應該能夠應對所有漏洞，因為他們有足夠的資源和時間

• 3.3.3. 組織必須優先考慮某些漏洞，並分配資源來緩解這些漏洞

• 3.3.4. 國際標準化組織(ISO)建議選擇和確定一種與組織管理相一致的風險評估方法，並採用適合組織的方法

• 3.3.5. 子階段

• 3.3.5.1. 範圍識別

>  3.3.5.1.1. 風險評估始於範圍識別

>  3.3.5.1.2. 組織的安全小組只有有限的預算，因此，風險評估必須確定將覆蓋的領域和不會覆蓋的領域，確定要保護的內容、其敏感性以及需要保護的級別等

>  3.3.5.1.3. 範圍需要仔細定義，因為這決定將從何處開始進行內部和外部的漏洞分析

• 3.3.5.2. 收集數據

>  3.3.5.2.1. 收集有關保護組織免受網絡威脅的現有政策和程序的數據

>  3.3.5.2.2. 通過對用户和網絡管理員等人員進行訪談、問卷和調查來實現

>  3.3.5.2.3. 應收集範圍內的所有網絡、應用程序和系統的相關數據

  >   3.3.5.2.3.1. 服務包、操作系統版本、運行的應用程序、位置、訪問控制權限、入侵檢測測試、防火牆測試、網絡調查和端口掃描

• 3.3.5.3. 政策和程序分析

>  3.3.5.3.1. 組織設立政策和程序來管理其資源的使用方式，以確保它們被正確和安全地使用

>  3.3.5.3.2. 審查和分析現有的政策和程序是很重要的

>  3.3.5.3.3. 制定並宣傳了政策和程序，並不意味着它們得到了遵守

>  3.3.5.3.4. 對不遵守規定的行為的處罰也應該進行分析

>  3.3.5.3.5. 知道組織是否有足夠的政策和程序來解決漏洞

• 3.3.5.4. 漏洞分析

>  3.3.5.4.1. 必須進行漏洞分析以確定組織的暴露面並找出是否有足夠的應對措施來保護自己

>  3.3.5.4.2. 會召集滲透測試人員來執行此過程

>  3.3.5.4.3. 最大的困難是排除誤報

  >   3.3.5.4.3.1. 必須將各種工具一起使用，才能得出組織中現有漏洞的可靠列表

>  3.3.5.4.4. 根據所發現的漏洞對組織構成的風險進行分級

  >   3.3.5.4.4.1. 嚴重程度和暴露程度較低的漏洞通常評級較低

  >   3.3.5.4.4.2. 輕微級是針對需要大量資源才能利用，但對組織影響很小的漏洞

  >   3.3.5.4.4.3. 中等級是針對那些具有中等破壞性、可利用性和暴露可能性的漏洞

  >   3.3.5.4.4.4. 高嚴重性級指那些需要較少資源即可利用，但會對組織造成很大損害的漏洞

• 3.3.5.5. 威脅分析

>  3.3.5.5.1. 對一個組織的威脅是指可能導致一個組織的數據和服務被篡改、破壞或中斷的操作、代碼或軟件

>  3.3.5.5.2. 威脅分析是為了查看組織中可能發生的風險，且必須分析發現的威脅以確定其對組織的影響

>  3.3.5.5.3. 該分級系統可能與漏洞分析中使用的分級系統有所不同

>  3.3.5.5.4. 對識別出的威脅進行量化和分級

• 3.3.5.6. 可接受風險分析

>  3.3.5.6.1. 首先評估現有的政策、程序和安全機制，以確定它們是否足夠完善

>  3.3.5.6.2. 假定組織中存在漏洞，並採取糾正措施以確保不斷升級，直到足夠充分

>  3.3.5.6.3. 沒有涵蓋的任何風險都被視為可接受的風險

>  3.3.5.6.4. 隨着時間的推移，風險可能會變得更具危害性，因此必須定期進行分析

  >   3.3.5.6.4.1. 只有在確定它們不會構成威脅之後，風險評估才會結束

  >   3.3.5.6.4.2. 如果它們可能構成威脅，就應該更新防護標準以應對它們

>  3.3.5.6.5. 該子階段標誌着漏洞管理戰略的風險評估階段結束

3.4. 漏洞評估

• 3.4.1. 漏洞評估緊隨風險評估之後，因為這兩個階段密切相關

• 3.4.2. 通過若干道德黑客攻擊嘗試和滲透測試來進行，組織網絡上的服務器、打印機、工作站、防火牆、路由器和交換機都是這些攻擊的目標

• 3.4.3. 目的在於使用潛在攻擊者可能使用的相同工具和技術來模擬真實的黑客場景

• 3.4.4. 目標不僅是識別漏洞，而且要以快速、準確的方式進行識別

• 3.4.5. 該步驟應生成關於組織面臨的所有漏洞的綜合報告

• 3.4.6. 要考慮的是組織應該評估什麼

• 3.4.6.1. 機可能是潛在攻擊的關鍵目標

• 3.4.7. 漏洞掃描器

• 3.4.7.1. 一些掃描器可能提供錯誤的評估報告，並將組織引向錯誤的道路

• 3.4.8. 隨着所有道德黑客和滲透測試活動的進行，網絡、服務器和工作站都會受到影響，防火牆等網絡設備也會變得遲緩，在進行拒絕服務攻擊時更是如此

• 3.4.9. Metasploit等工具要求你對Linux有深入的瞭解，並具有使用命令行界面的經驗

• 3.4.10. 漏洞評估方式

• 3.4.10.1. 外部評估：從外部發現漏洞

• 3.4.10.2. 內部評估：在網絡內部發現漏洞

• 3.4.10.3. 社會工程：查找人力和培訓差距方面的漏洞

• 3.4.10.4. 無線評估：發現無線網絡內的漏洞

• 3.4.10.5. 物理安全評估：查找與人和設施相關的漏洞

• 3.4.10.6. 應用程序與數據庫：發現軟件漏洞

3.5. 報告和補救跟蹤

• 3.5.1. 進行漏洞評估後將進入報告和補救階段

• 3.5.2. 報告的任務是幫助系統管理員瞭解組織的當前安全狀態以及組織中仍然存在的不安全領域，並向負責人指出這些情況

• 3.5.2.1. 所有確定的風險和漏洞都必須報告給組織的利益相關者

• 3.5.2.2. 涉及屬於組織的所有硬件和軟件資產

• 3.5.2.3. 還應對報告進行微調，以滿足不同受眾的需求

• 3.5.2.4. 為管理層提供了一些關鍵內容，這樣他們就可以將其與組織的未來發展方向聯繫起來

• 3.5.2.5. 報告通常在補救之前進行，因此，在漏洞管理階段編譯的所有信息都可以無縫地融入本階段

• 3.5.3. 補救啓動了結束漏洞管理週期的實際過程

• 3.5.3.1. 漏洞評估階段在分析威脅和漏洞並概述了可接受的風險之後提早結束了

• 3.5.3.2. 補救階段通過提出針對已發現威脅和漏洞的解決方案來補充這一點

• 3.5.3.3. 應公佈負責補救這些風險和漏洞的合適人員

• 3.5.4. 應跟蹤所有易受攻擊的主機、服務器和網絡設備，並制定必要的步驟以消除漏洞並保護它們免受未來的攻擊

• 3.5.5. 是漏洞管理策略中最重要的任務，如果執行得好，漏洞管理就是成功的

• 3.5.5.1. 同時還針對掃描工具發現的錯誤確定解決方案

• 3.5.5.2. 如果在這個階段做得不到位，則會使整個漏洞管理過程變得毫無意義

• 3.5.6. 一份寫得不好的報告可能會導致補救措施不力，從而使組織仍然面臨威脅

• 3.5.6.1. 沒有文檔的話，可能很難更新定製的軟件

• 3.5.6.2. 軟件供應商之間溝通不暢，當需要為系統打補丁時，組織也可能面臨挑戰

• 3.5.6.3. 補救措施可能會因最終用户缺乏合作而受到影響

• 3.5.6.4. 補救可能導致最終用户停機，這是用户永遠不想經歷的事情

3.6. 響應計劃

• 3.6.1. 響應計劃可以認為是漏洞管理戰略中最簡單但卻非常重要的一步

• 3.6.2. 在響應計劃中，組織應該想出一個辦法來修補、更新或升級那些被確認為具有某些風險或漏洞的系統

• 3.6.3. 在這一階段最重要的是執行速度

• 3.6.3.1. 由於響應計劃不完善，大多數公司在攻擊開始時還沒有做到這一點

• 3.6.3.2. 如果攻擊沒有被及時阻止，甚至會有更多的計算機成為受害者

• 3.6.3.3. 在響應計劃方面，速度是多麼重要

>  3.6.3.3.1. 補丁程序應在可用時立即安裝

• 3.6.4. 及時與合適的人進行適當的溝通

• 3.6.4.1. 當一個補丁發佈時，黑客就會毫不遲疑地想方設法危害那些沒有安裝補丁的組織

• 3.6.5. 問責

• 3.6.5.1. 組織需要知道誰應該為未安裝補丁程序負責

• 3.6.5.2. 用户可能需要對取消安裝負責

• 3.6.5.3. 在其他情況下，可能是IT部門沒有及時啓動修補過程

• 3.6.5.4. 總應該有人為沒有安裝補丁程序負責

• 3.6.6. 重複努力

• 3.6.6.1. 通常發生在IT安全人員眾多的大型組織中

• 3.6.6.2. 可能使用相同的響應計劃，但由於溝通不暢，可能最終會重複對方的操作，但收效甚微