1.概要
有許多不同類型的安全評估，并不總是容易在我們的頭腦清晰的表現出來
以下是對安全評估的主要類型的簡要描述，以及常見混淆評估的區別。
2.安全評估類型
2.1脆弱性評估：
脆弱性評估是一種旨在環境中產生盡可能多的漏洞的技術評估（威脅區別于風險，威脅是會造成損害，風險不一定會造成但是存在和脆弱性類似，因為不一定會發生），以及嚴重性和補救優先級信息。
通常混淆：漏洞評估是最經常與滲透測試被混淆（或者混為一談）。這主要是因為售前認為后者聽起來更cool，上帝保佑。
最佳使用時間：當安全度低至中等時，同時您需要優先列出所有錯誤的列表時，此時漏洞評估最適用，目標是盡可能高效地修復盡可能多的威脅/漏洞。
2.2滲透測試：
滲透測試是旨在實現特定目標的技術評估，例如竊取客戶數據，獲取域管理員帳號或修改敏感的薪資信息。
當然，滲透測試是最經常與脆弱性評估被混淆（或混為一談）。究其原因是因為另一種方法是將漏洞評估視為在知道/假設存在的情況下尋找安全問題，同時并將滲透測試視為驗證配置，直到您認為它是安全的。
最佳使用時間：由于滲透測試旨在實現一個或多個具體目標的安全評估，因此在大多數情況下不應由低級或中級安全機構委托。對低或中等安全性企業進行滲透測試我更推薦一整套的安全流程，如“實施整個組織的安全修補”，“禁用不活動的用戶”，和我最喜歡的一個：“了解你的敏感數據“，而不要浪費金錢進行滲透測試，除非您已經進行了一個或十幾個漏洞評估，然后修復了發現的一切。滲透測試用于在已經修復一定漏洞并不知道隱藏的威脅情況下進行的安全評估測試。
2.3紅隊評估：
紅隊“評估”在企業背景中是一個誤導，因為公司紅隊服務理想情況下應該是持續而不是短暫的。因此，理想情況下，紅隊評估比評估更適合服務（紅隊服務）。但不管這個區別，如果企業紅隊的中心目標是提高企業信息安全防御的質量，如果存在這種情況，那么這個防御是公司的藍隊。事實上，這是一個小寫的“紅隊”：一個獨立的組織，挑戰一個組織來提高其有效性。在公司紅隊的情況下，他們正在改進的組織是藍隊。
在我看來，紅隊服務應該總是有以下五個要素：組織獨立，防守協調，持續運作，對手仿真和功效測量。
通常混淆：紅隊服務最常見的是與滲透測試混淆。銷售和營銷團體幾乎會互換使用這些術語，以及許多內部安全組。令人困惑的人們基本上看到“紅隊”是一種精英更精英的滲透測試。紅隊評估和滲透測試評估是不一樣的，滲透測試是在一個定義的范圍和時間點評估，具有測試成功或失敗的具體目標。而企業紅隊（無論是內部還是外部）是持續的服務，模仿真實的攻擊者，以改善藍隊。他們有時可能會分享TiPs，但目的卻有很大不同。
最佳使用時間：當組織涵蓋了強有力的漏洞管理的基礎知識時，此時最好使用紅隊服務/紅隊評估，并且至少有一些檢測和響應環境存在惡意或可疑行為的能力。如果一個組織仍然在努力進行基本的資產管理，修補，網絡出口管理等基礎，通常最好在聘用或建立“紅隊”之前解決基礎的安全問題。紅隊一般評估和測試的是已經形成的，成熟的業務結構，而不是尋找不成熟或者剛開始搭建的環境中的問題。同時如果你沒有藍隊，你可能不需要紅隊。（具體情況具體運用）
2.4審計：
審計可以是技術/或者基于文檔的，并且重點關注現有的配置，以及如何與期望的標準進行比較。這是重要的一點。它不需要證明或驗證安全性;它驗證了對于已有安全手段的既定視角的一致性。這兩件事情不應該混淆。
通常混淆：審計往往與幾乎所有其他類型其目的是要找到漏洞并修復它們的安全評估混淆。如果有一個項目在標準說您不應該有漏洞，但是關鍵屬性是將當前狀態對應到任意評估標準，這可能是審計的一部分
最佳使用時間：組織通過審核來證明業務合規性。但重要的是，不應使用合規性來證明安全性。在已經檢查的情況下，安全組織顯然更有可能遵守合規要求，但符合合規性的組織不應該緊緊因為符合標準X或Y而覺得業務符合安全性，也就是說合規性≠安全性。
2.5白/灰/黑盒測試：
白/灰/黑測試說明用于指示測試人員在給定的技術測試中需要獲得多少內部信息。測試等級的意思是將光線映射到內部的透明度：白，灰，黑，因此白盒測試是測試人員可以完全訪問所有可用內部信息的地方，如網絡圖，源代碼等。灰盒測試是下一個不透明度水平這意味著測試者有一些信息，但并不是全部。一個黑盒測試–你只能猜測這是一個測試，測試者對于環境的內部知識為零，即從攻擊者的角度來進行測試。
常常混淆：圍繞白/灰/黑盒命名的最大的混亂來源是：人們并沒有意識到它們并不是真正的測試類型，而只是一個方面，一個范圍。它們最常用于脆弱性評估，您可能希望找到可能出現的最多問題，并為打開掩藏的威脅和風險提供重要動力。請記住，漏洞評估的目標是盡可能多地找到問題，因此隱藏來自測試人員的內部信息，使他們無法找到問題，并不會傷害到風險和威脅它們–但它會傷害您。不要混淆：攻擊者想知道什么，可以看什么/和攻擊者想做什么，存在什么問題。這是兩件事情，需要單獨處理。如果你想知道攻擊者能做什么。
最佳使用時間：白盒測試最適用于漏洞評估，因為您希望盡可能多地找到問題，無論測試人員如何發現它們。當人們對滲透測試和漏洞評估之間的區別感到困惑時，通常會使用灰盒測試。他們想提供一些信息，但不是全部。讓我們清楚一點：如果你想找到所有的問題，你不應該保留測試人員的信息。但是，如果您正在進行滲透測試，您不能給測試人員任何內容，那么這是一個黑盒測試。在你的腦海里保持清晰的界限，你會沒事的。
2.6風險評估：
風險評估，類似于威脅模型，對于區分兩者邊界有兩個比較模糊的方面：如何理解和如何進行。在最高級別，風險評估應包括確定當前可接受的風險水平，同時衡量當前風險水平，然后確定將兩者進行比較分析可以做些什么。風險評估通常涉及風險評估的兩個維度：概率和影響，以及使用定量和定性模型。在許多方面，風險評估和威脅建模都是類似的練習，因為每個人的目標是確定一個直截了當的行動，將風險降低到可接受的水平。
通常混淆：風險評估通常與威脅評估混淆，因為二者都是追求相似的目標。主要區別在于評估開始的地方以及他們的重點。威脅模型側重于攻擊場景，然后重心轉移到中間層，威脅，遠程控制和潛在的影響。風險評估通常從資產方面開始，評估資產的價值和風險，以及潛在的威脅，事件發生的損失概率，損失的影響等。
最佳使用時間：風險評估應被視為一個總結，用于確定您的資產有什么價值，資產如何受到攻擊，如果這些攻擊成功，您將會失去什么（造成什么樣的影響），以及應該如何處理這些問題（應急響應）。重要的是，當有人說他們要做一個風險評估，你深入了解什么是什么意思，即使用的是什么方法，什么模型，什么工具等等。
2.7威脅評估：
威脅評估是一種與其他提到的安全審查有些不同的安全評估。一般來說，它比技術更多地涉及物理攻擊，但線條模糊。威脅評估的主要重點是確定是否可靠地威脅（認為是炸彈威脅或暴力威脅），或者是以其他方式被發現的威脅。評估的驅動因素是確定應該花費多少資源（如果有的話）來解決有關問題。
常常混淆：“威脅”一詞在安全性中被多種使用，導致了很大的混亂。在這種情況下，與“威脅agent”的用法相反，該術語用于“威脅”，或“確定威脅是否真實”。起因來自特勤局調查學校的暴力行為，挑戰在于確定他們收到的成千上萬的威脅，他們應該以非常有限的資源回應。這與許多人在聽到威脅評估（正在調查黑客，政府等等）的潛在威脅agent的想法形成鮮明的對比。
最佳使用時間：威脅評估最適用于有人在將來發生攻擊的情況下，或者這種潛力被揭開。在這種情況下，目標是了解情況是否值得花費資源來解決。
2.8威脅建模：
威脅建模對于大多數組織而言，并不是一種很好理解的安全評估類型，部分問題對許多不同的人來說意味著許多不同的事情。在最基本的層面上，威脅建模是捕獲，記錄和（通常）可視化威脅代理，漏洞，攻擊，對策和對業務的影響與特定環境相關的過程。顧名思義，重點通常是從威脅代理和給定的攻擊情形開始，但隨后的工作流程可以捕獲可能利用的哪些漏洞，可能會使用的哪些漏洞，可能存在哪些對策可以阻止/減少這種攻擊，以及可能產生的業務影響等等，和SDL+風險評估有點類似
常常混淆：威脅建模一般令人困惑。許多混亂來自關于定義和語義的辯論，因為威脅建模通常包括圍繞威脅，威脅代理，漏洞，漏洞利用，控制，風險和影響的討論。每一個都是自己加載的，當你開始嘗試與所有的對話同時發生宗教戰爭時。另一個問題是人們失去了目標，因為有很多因素產生。我們試圖找出漏洞嗎？我們正在嘗試查看中間威脅？我們是否記錄潛在的業務影響？等等。最好的總結方法就是說，最好評估威脅建模給安全性帶來什么：那就是它顯示攻擊場景
最佳使用時間：組織應該在早期經常地使用威脅建模，并且它們應該是開發過程的一部分（SDL）。它們是確保已知潛在攻擊場景在實際上可以通過給定的安全狀態來處理的一種方式。威脅模型也可以從純粹的文檔和可見性的角度出色地顯現出來。看到你潛在的威脅因素，觀察他們可能如何攻擊你的應用程序或系統，使用什么陰謀和什么漏洞，對你的組織可能做了什么的往往是一個清晰的案例。它們對于顯示非安全性的用戶，不遵循安全流程的程序和產品尤其有用。
2.9Bug賞金：
Bug賞金是一種技術安全評估，利用眾包來查找系統中的漏洞。中心概念很簡單：無論質量如何，安全測試人員都有自己的優勢，弱點，經驗，偏見和偏好，這些結合在不同的人測試時為同一系統產生不同的發現。換句話說，您可以為100位經驗豐富的安全測試人員提供完全相同的測試方法，并且可能會發現廣泛不同的漏洞。bug賞金的概念是涵蓋這種差異，而不是通過在單個評估中利用多個測試人員來對付它。
常見的困惑：bug獎勵是進行技術安全測試的一種比較新的方法，和是否應該進行安全測試，還有一些混淆。我認為最好的答案是，bug賞金應該被認為是一個漏洞評估，其目標是盡可能多地尋找許多問題來進行修復，但是被認為是滲透測試，您應該首先進行經典的脆弱性評估。這樣做的原因是bug獎勵使用了許多人，擅長尋找不尋常的問題，不僅僅是運用自動化和單一測試者評估可以發現常見的問題。
最佳使用時間：當您已經執行了一個或多個標準漏洞評估（應包括自動化和手動測試）），然后修復了發現的所有內容時，最好再使用bug獎勵。將它們考慮進經典脆弱性評估和滲透測試之間的可選步驟，如上所述，它不是尋求所有安全問題，而是確認安全狀態是否是通過實現特定目標而所需要的狀態。
3.最經常混淆
以下是考慮這些評估類型時最常見的錯誤。
1.如果您對自己的安全狀態不確定，并且已經知道安全狀態不穩固，那么您應該進行脆弱性評估-而不是滲透測試。滲透測試用于測試您想了解的業務指定區域的狀態。
2.思考Bug賞金的最佳方式是增強漏洞評估的發現階段。脆弱性評估有兩件事：發現（盡可能多地找到問題）和優先級排序（首先要排列什么）。第一部分的Bug賞金很棒，第二部分不好使用。因此，當您已經完成多次漏洞評估并且已經找到了簡單的東西時，它們最適合使用。Bug Bounties擅長尋找使用其他方法找不到的問題。
3.由于市場營銷和銷售推動了信息產業的發展，人們不斷凝聚紅色團隊和滲透測試。因為紅隊是為了模仿對手，所以他們一般只有在持續運行的情況下才能工作，理想情況下永久地運行。所以，如果你有一些公司提供了兩周的“紅隊”參與，這可能更好地被描述為滲透測試。因此，主要的區別是真實世界的攻擊者的模仿，包括他們的韌性，持續的攻擊時間，TTP的復雜程度等。缺乏這些要素的評估是滲透測試，而不是紅隊的參與。紅隊評估和威脅模型更偏向于長遠安全保障。
4.總結
簡而言之：
脆弱性評估的目的是找到盡可能多的漏洞，以便優先處理補救措施。輸出是問題優先級的列表。
滲透測試旨在確定攻擊者是否可以在面對您當前的安全狀態時達到特定目標，例如竊取敏感數據或其他會對組織造成傷害的活動。產出是一份報告，說明目標是否實現，以及可能在過程中所做的任何其他觀察。滲透測試沒有提供完整的漏洞列表（漏洞不可能全部都發現），或者確定了所發現的任何優先級（有高中低之分）;
紅隊旨在不斷有效地效仿現實攻擊組織，以提高企業其防御能力。紅隊持續運作，具有接近全面和非常有限的限制，并不斷發展他們的方法來匹配/或超出組織的實際攻擊者的能力。
審計旨在確定給定組織對某一標準的措施。審計通常不直接測試安全性，而是測試是否符合標準。被測試的標準可能與實際安全性有很強或弱的聯系，不應與脆弱性評估或滲透測試混淆。審計的輸出是為了實現合規性而必須修正的領域的列表。
白/灰/黑盒評估是評估期間向安全測試機構提供多少信息的度量。這些可以是內部的，外部的，基于應用的，基于網絡的，有或沒有削減等。盒測試評估的唯一考慮是與測試方共享的信息量。
風險評估用于確定給定組織面臨的最重要風險，以確保將其納入業務可接受的水平。他們可以采取多種形式，但產出始終是優先考慮的風險列表，然后是建議。
威脅評估用于確定給定的威脅（通常但不一定是物理性質）是否值得花費有限的資源。產出通常是一個建議，如果有的話-應該致力于這個問題的修改。
威脅模型用于確定與給定系統相關的各種威脅，威脅情境，威脅人員，漏洞，，控制和影響。它們理想情況是在創造和開發過程中早期進行，并且在重大變化之后也可以重復進行。產出通常包括上述各項的文件，以及考慮到控制后的剩余風險，以及改進建議。
Bug獎勵是利用眾包來發現系統中的漏洞的項目。它們是漏洞評估工具箱中的工具和手段。參與賞金的人所使用的技術可能會有很大差異，正在測試的系統類型也會有所不同。重要的是，而不是內部團隊，或一組特定的合同雇員從事這項工作，或者是一大批獨立研究人員，他們都將自己的觀點納入測試中。
創建日期：2015年3月|更新：2017年3月
