當安全產品企業本身也需要利用種種途徑來購買其產品的漏洞描述時，事態到底會變成什么樣？正如我們近期不斷聽到的關于HBGary，RSA以及Comodo攻擊的新聞，安全產品如今也已淪為緩沖區溢出及目錄檢索等攻擊方式的犧牲品。

大多數人都會誤以為我們的安全保障工具本身是安全的。但實際情況是，安全產品與那些經常遭受0day漏洞困擾的桌面應用程序并沒有本質上的不同——它們都是由程序員編寫的。程序員也是人，而人總會犯下錯誤并由此形成漏洞。

殘酷的現實是：安全產品同任何一款軟件或設備一樣，在實際應用之前都要經歷類似的檢驗過程。

企業不應該盲目地引進一個全新的安全解決方案。正如在選擇那些與安全無關的產品時一樣，他們最好是根據IT組織對該款新安全工具所做出的相關風險評估來進行判斷。評估內容包括檢查其代碼在開發過程中是否安全以及部署一套模擬解決方案以進行滲透測試。

檢驗的第一步是要進行風險評估工作，以確保設備的安置及軟件的安裝不會對環境安全產生負面影響。有這樣一個值得思考的重要問題：如果攻擊者成功利用了安全軟件中的某個漏洞，會帶來何種程度的后果？攻擊者到底能通過獲取企業系統訪問權限來破壞或竊取到哪些信息？

早在2006年末，"Big Yellow"蠕蟲病毒就為上述問題提供了一些極具威脅性的回應。攻擊者能夠在運行著賽門鐵克殺毒軟件的Windows系統上輕松獲得遠程訪問及管理的全部權限。借由這種途徑，蠕蟲病毒得以利用僵尸網絡的形式滲入系統，進而使攻擊者獲得了對系統的遠程控制能力。

如果事先做過風險評估工作，各類機構可能會在如何更好地選擇安全產品方面得出較為明確的結論。被利用于遠程管理的漏洞端口本應只限于與管理服務器間溝通，有了這些清醒的認識，我們就可以大大降低蠕蟲病毒的傳播機率與造成的損失。

許多打算采購安全產品的企業壓根忘記了向供應廠商詢問其產品是否遵循安全編碼規范。他們是否具備一套包括安全性測試在內的標準軟件開發周期（簡稱SDLC）。顯然，如果我們問起，電話那頭的工作人員往往會給出肯定的答案，別松懈，繼續從他那里套出更多信息。他們的源代碼進行過審核嗎？有沒有第三方給出的分析結果及滲透測試報告？

當然，在這種情況下，大家恐怕不得不姑且聽信供應商的口頭承諾。不過多進行交談并了解其處理過程（只要不觸及核心技術，工作人員是會進行介紹的）可以讓我們更安心。話題還應該涉及到在未來的應用中遇到問題時的情況--供應商如何避免產品缺陷，又會以何種方式來解決突發情況？

在產品的評估階段進行滲透測試--或是模擬一次小型攻擊--也同樣有機會暴露那些在風險評估過程中沒有被注意到的細小問題。例如該產品在安裝時可能需要利用訪問控制，而這一步驟會削弱當前運行環境的安全性；該產品可能包含一個能夠避過識別掃描的漏洞；應用協議內容模糊不清等等。

如今許多安全解決方案都會提供基于頁面的管理界面，而這將會導致另一個安全隱患，專家如是說。該管理界面所存在的缺口有可能使整個企業遭受攻擊。經由該頁面管理（或者是任何頁面應用程序）漏洞，我們可能會受到包括跨站點腳本（簡稱XSS）、偽造跨站請求（簡稱CSRF）、SQL注入或未經授權的遠程命令執行等各種我們不希望見到的侵害。

有時漏洞來自于同安全產品捆綁在一起的底層頁面服務。說起這個話題，我先舉兩個實例：案例一中，某位供應商由于使用了過時的目錄安裝結構而導致了安全漏洞，進而使數十萬名病人的病歷遭到曝光。這個安全問題很有意思，因為它的后果對客戶而言極其嚴重，而避免的辦法只需在安全解決方案部署之前進行一次評估即可。

第二個案例是在一臺JBOSS服務器上發現了類似的漏洞。在一次滲透測試中，服務器被發現有遭受入侵的跡象，該漏洞導致攻擊者能夠在運行著JBOSS服務的Windows主機上能夠獲得全部遠程訪問權限。在這種情況之下，客戶在購買并部署這套安全工具之前，向供應商提交了問題報告及修復建議。

沒人希望一款安全產品中存在著漏洞，但這種情況卻無法完全避免。進行風險評估、向供應商正確發問以及做好滲透測試可以幫助降低--甚至消除--漏洞造成巨大損失的可能性。請記住，我們付費購買產品是為了保護自己的計算機運行環境，而不是使其更不安全。采取適當的預防措施，才能確保安全產品發揮其應有的保護作用。

原文鏈接：http://www.darkreading.com/vulnerability-management/167901026/security/vulnerabilities/229400725/tech-insight-when-security-products-attack.html 

譯文鏈接：http://netsecurity.51cto.com/art/201104/255557.htm