有成千上萬的書籍講解什麼是信息安全，什麼是滲透測試，也有數不清的培訓課程視頻。但是，我敢打賭，在這些材料中，隻有不到10%是在寫報告的事情。在一個完整的滲透測試過程中，有将近一半的時間都用在了編寫報告上，這聽起來很讓人吃驚，但是也并不奇怪。

教會某人寫報告不像教會某人制作一個完美的緩沖區溢出那麼有意思，大部分的滲透測試人員情願複習19次TCP數據包結構的工作原理，也不願意寫一份報告。

不管我們的滲透測試水平多麼高，想要把一個很深的技術點解釋得很通俗易懂，即使是完全不懂安全的人也可以理解，這是一件異常艱難的挑戰。不但得學會簡單明了的解釋滲透測試的結果，還得控制好時間。這樣做的好處很多，關系到客戶會不會不斷地采購你的服務。

有一次，我開車到350英裡以外的一家客戶那裡做售前，當面重新解釋了滲透測試報告的本内容；如果能把測試報告寫得簡單明了，我就不用跑這麼一趟，相當于節省了一整天的時間和一整箱汽油。舉個例子：

一個模糊不清的解釋：“SSH版本應該被禁用，因為它含有高危漏洞，可能允許攻擊者在網絡上攔截和解密通信，雖然攻擊者控制網絡的風險很低，這減少了嚴重性。”清楚的解釋：“建議在這些設備上禁用SSH，如果不這樣做，就有可能允許攻擊者在當地網絡解密和攔截通訊。”

請謹記：滲透測試是一個科學的過程，像所有科學流程一樣，應該是獨立可重複的。當客戶不滿意測試結果時，他有權要求另外一名測試人員進行複現。如果第一個測試人員沒有在報告中詳細說明是如何得出結論的話，第二個測試人員将會不知從何入手，得出的結論也極有可能不一樣。更糟糕的是，可能會有潛在漏洞暴露于外部沒有被發現。

①　200多本滲透測試系列電子書

②　網絡安全标準題庫資料

③　項目源碼

④　網絡安全基礎入門、Linux、web安全、攻防方面的視頻

⑤　網絡安全學習路線

⑥　私信“安全”免費獲取

舉個例子：

模糊不清的描述：“我使用端口掃描器檢測到了一個開放的TCP端口。“清晰明了的描述：“我使用Nmap 5.50，對一段端口進行SYN掃描，發現了一個開放的TCP端口。

命令是：nmap –sS –p 7000-8000“

報告是實實在在的測試過程的輸出，且是真實測試結果的證據。對客戶高層管理人員（批準用于測試的資金的人）可能對報告的内容沒有什麼興趣，但這份報告是他們唯一一份證明測試費用的證據。滲透測試不像其他類型的合同項目。合同結束了，沒有搭建新的系統，也沒有往應用程序添加新的代碼。沒有報告，很難向别人解釋他們剛買的什麼東西。

至少有三種類型的人會閱讀你的報告：高級管理人員，IT管理和IT技術人員。高級管理人員根本不關心，或者壓根不明白它的意思，如果支付服務器使用SSL v2加密連接。他們想知道的答案是“我們現在到底安不安全？”IT管理對該組織的整體安全性感興趣，同時也希望确保其特定的部門在測試過程中都沒有發現任何重大問題。我記得給三個IT經理一份特别詳細的報告。閱讀這份報告後有兩個人臉色變得蒼白，而第三個人笑着說“太好了，沒有數據庫的安全問題”。IT人員是負責修複測試過程中發現的問題的人。他們想知道三件事：受影響系統的名稱，該漏洞的嚴重程度以及如何解決它。他們也希望這些信息以一種清晰而且有組織的方式呈現給他們。最好的方法是将這些信息以資産和嚴重程度來進行劃分。例如“服務器A”存在“漏洞X，Y和Z，漏洞Y是最關鍵的。這樣IT人員就可以快速的找到問題的關鍵，及時修複。當然,你可以問你的客戶是否願意對漏洞分組。畢竟測試是為了他們的利益，他們是付錢的人！一些客戶喜歡有個詳細說明每個漏洞的頁面，并表明受漏洞影響的資産有哪些。

雖然我已經提到了滲透測試報告三種最常見的讀者，但這并不是一個詳盡的清單。一旦報告交付給客戶，取決于他們用它幹什麼。它可能最終被提交給審計人員作為審計的證據。它可以通過銷售團隊呈現給潛在客戶。

“任何人都可以說自己的産品是安全的，但他們可以證明這一點？我們可以看看這裡的滲透測試報告。“

報告甚至可能最終共享給整個組織。這聽起來很瘋狂，但它确實發生過。我執行一次社會工程學測試，其結果低于客戶的期望。被觸怒的CEO将報告傳遞給整個組織，作為提高防範社會工程攻擊意識的一種方式。更有趣的是，幾周後當我訪問同一個公司做一些安全意識的培訓。我在自我介紹時說，我就是之前那個負責社工測試的人。憤怒的目光，嘲諷的語氣，埋怨我給他們所有人帶來多少麻煩。我的内心毫無波動，答道：“把密碼給我總比給真正的黑客好。”

有時候你會很幸運地看到，客戶在項目計劃之初就表明他們想要的報告内容。甚至有一些更為細小的要求，比如，字體大小和線間距等。但是這隻是少數，大部分客戶還是不知道最終要什麼結果，所以下面給出一般報告的撰寫程序。封面封面是報告的第一面窗戶，封面頁上包含的細節可以不那麼明顯。但是測試公司的名稱、标志以及客戶的名稱應該突出顯示。諸如“内部網絡掃描”或“DMZ測試”測試标題也應該在那裡，對于相同的客戶執行多個測試時，可以避免混淆。測試時間也要寫上，随着時間的推移，用戶可以清楚地得知他們的安全狀況是否得到了改善。另外該封面還應包含文檔的密級，并與客戶商定如何保密好這份商業上的敏感文件。内容提要我見過一些簡直像短篇小說一樣的内容提要，其實這部分一般要限制在一頁紙以内。不要提及任何特定的工具、技術，因為客戶根本不在乎，他們隻需要知道的是你做了什麼，發現了什麼，接下來要發生什麼，為什麼，執行摘要的最後一行應該是一個結論，即明确指出該系統是安全還是不安全。

舉個例子：一個糟糕的總結：“總之，我們發現一些地方的安全策略運作良好，但有些地方并未遵從。這導緻了一定風險，但并不是緻命風險。”一個優秀的總結：“總之，我們發現了某些地方沒有遵守安全策略，這給組織帶來了一個風險，因此我們必須聲明該系統是不安全的。”

漏洞總結将漏洞列表放在一個頁面上，這樣，IT經理便可以一目了然的知道接下來要做什麼。具體怎樣表現出來，形式多樣，你可以使用花哨的圖形（像表格或圖表），隻要清晰明了就行。漏洞可以按類别（例如軟件問題，網絡設備配置，密碼策略）進行分組，嚴重程度或CVSS評分——方法很多，隻要工作做得好，很容易理解。

測試團隊的詳細信息記錄測試過程中所涉及的每一個測試人員的名字，這是一個基本的禮節問題，讓客戶知道是誰在測試他們的網絡，并提供聯系方式，以便後續報告中問題讨論。一些客戶和測試公司也喜歡依據測試的内容向不同的測試小組分配任務。多一雙眼睛，就可以從不同的角度查看系統的問題。工具列表包括版本和功能的簡要描述。這點會涉及到可重複性。如果有人要準确複現您的測試，他們需要确切地知道您使用的工具。

工作範圍

事先已經同意，轉載作為參考是有用的。

報告主體

這部分才是報告的精華，報告的正文應包括所有檢測到的漏洞細節，如何發現漏洞，如何利用漏洞，以及漏洞利用的可能性。無論你做的是什麼，都要保證給出一個清晰的解釋。我看過無數份報告，都是簡單的複制粘貼漏洞掃描的結果，這是不對的。另外報告中還應包括切實貼合的修複建議。

在任何情況下任何一份報告應該加密傳輸。這雖然是常識，但往往大家就會摔倒在最後的這環上。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!