給TSRC等甲方平臺建設的一些建議
從7月份加入TSRC平臺來,我一直都給TSRC(Tencent Security Response Center)的朋友提了很多的建議,不過我用的方式都比較“極端”,所以給很多人的印象是我是TSRC平臺最難纏的!直到最近博客及微博一系列的討論,我也直接淪落為邪惡的“鬧事者”!這個其中可能與甲方強大的“封建殘余理論”有直接的關系,不過可能是我們對甲方對安全“進化”要求過高。于是只有采用以前常用的“曝光引發公共關注”的手段來促進發展了!?
我一直認為TSRC這樣的平臺是有積極意義的,所以把之前的一些建議提一下,希望給后來者得到一些啟發。【這些建議可能比較凌亂沒有體系!】
首先明確2點:
一、如何評價甲方漏洞平臺的價值。
甲方評價平臺的價值不應該是收集了多少漏洞,吸引了多少白帽子,發了多少獎品等,而是應該看這個平臺給甲方的安全體系建設帶來了多少價值。包括:提升自己員工(安全、開發、運維、管理等)的技術技能及安全意識、發現和彌補自身安全流程(如sdl等)的缺陷、改進自身測試工具及流程(如黑、白盒審計工具等)等等。通過平臺吸收外界能量,提升本身的能力才是價值的體現。
另外我覺得甲方提升安全的最終目的是為了保證用戶的利益安全。也就是最終對象是用戶的利益。而對于用戶應該不拋棄不放棄,更不應該bs小白用戶。恰好我認為保護更多的小白用戶的利益才是技術發展的動力。
而這些主題思想關系到整個平臺的建設具體的措施的實施。
二、拋棄“封建殘余”,真正重視和尊重安全人員。
目前來看,很多的甲方并沒有從“敵對”的“封建思想”里走出來,還有很多的殘余,漏洞平臺是一個甲方和各大外來安全人員的一個互動平臺,也就是說參與到這個平臺的人就應該受到必須的尊重,然而很多甲方思想還是:“我給你獎金我給你獎品你能不能消停點?”的層次,所以我就在微博說了“GS3我已經砸了!” 雖然這只是個謊話 :)。
尊重是一個持續的過程,可體現在平臺與白帽子互動交流的各個細節。當然有改變甲方這樣的“根深蒂固”的思想,可能是一個很漫長的過程 ...
一些具體的建議:
1、完善自己的對漏洞的響應、審查、補丁等流程。在TSRC的實踐看來,個人感覺TSRC更像是一個“傳達室”,每天的工作就是確認下漏洞然后分發給不同的部門開發,進行修補。完全沒有體現SDL的精髓,SDL是要求每個流程都需要有安全人員的參與,包括漏洞的確認,危害評估,漏洞影響的范圍(如其他的產品線可能有類似的漏洞),給出具體的補丁修補方案及防御措施等等。
2、提高員工自身的能力。包括技術、安全的理解及和白帽子溝通能力等。個人認為身為安全人員都基礎不過關,那他指導的安全流程實施本身就是不靠譜的。
3、重視漏洞修補。前面提到的平臺價值就涉及到這個問題。很多的白帽子及甲方安全人員迷失在茫茫的“漏洞”里,而不重視甚至不在乎漏洞有沒有得到很好的解決。在我報告給tsrc的漏洞里的dom-xss類型的漏洞,除了直接刪除漏洞頁面代碼的修復方案外,其余重補率幾乎達100%!有的漏洞甚至補丁次數達到了4-5次!而TSRC的標準本身是不重視漏洞修補復查情況(以前的標準是補丁復查出現的漏洞+1分),當我提出要按新漏洞計算時困難重重,因為他們某些安全人員認為這個不重要!并且說這個平臺上就我有那么多問題!那么難纏!這是因為我知道在這樣的機制下白帽子認真復查漏洞的基本沒有!于是結果就是“漏洞還是那個漏洞!”。 為了證實我的看法,我還去某些平臺上公布的騰訊的漏洞,復查一下,補丁隨便就bypass了!
4、尊重標準。標準制訂了就不能隨時修改,即使原標準有缺陷,也要在以白帽子利益優先的基礎上承認,并發布新的標準并告示。
5、標準的制訂:
當時我給騰訊的建議是采用修正模式。也就是不用單一死板的漏洞類型來評估。對于甲方來說評估一個漏洞應該從多個方面來考慮:
i、 實施攻擊的成本。包括漏洞有成熟的利用方式不需要什么門檻就可以實現攻擊、漏洞觸發的條件等。甚至包括發動攻擊的法律風險等。
ii、 一但攻擊成功的后果。比如攻擊者利用這個漏洞可以取得的權限等等
iii、 這個漏洞的影響范圍。比如某些通用的函數里的漏洞,可能覆蓋到很多的產品線,很可能導致漏補等情況。
iiii、對技術的尊重及認可。這個主要是體現在有的漏洞通過某些技術完美利用了很難利用的漏洞等
...
應該把以上的一些因素的權重來實現一個修正的評分模式。而甲方不應該只看到漏洞的利用效果來評價。甲方的目的是修補漏洞,變得更加安全,可以更大程度的保護好用戶的利益。而不是去變相鼓勵滲透入侵。
6、獎勵機制
TSRC從7月開始采用月排名的機制進行獎勵。可能是考慮到獎品的成本問題,而采用這個方式。但是這個方式存在很大的問題,也就是越到后面排名,越不公平。我想很多白帽子意識到這個問題。所以為了彌補這些缺陷,騰訊采用了一些其他的獎勵措施。比如直接給高危漏洞單獨發放ipad等,但這個方式是才完全從漏洞利用來評價的!可能導致的后果就是,任何一個有可能得到shell的漏洞類型,白帽子都可能去嘗試一下,這也是上面提到的“變相鼓勵滲透入侵”的理由。還有一個措施就是把客服端、在線安全及移動客服端安全分開。而對于客服端領域因為參與的人少,直接不用費力就可以得大獎。這樣導致的成本也就不斷的提高,可能換個更公平的方案的成本可能差不多。
個人建議可以取消排名機制,白帽子根據提交的漏洞累計積分。然后根據積分發放對應的獎品。至于這個方案的成本和上面方案的成本比較,要看甲方自己去調查分析了。
7、加強和白帽子的交流合作。這個上面也有提到。在tsrc里看到的白帽子就提交漏洞就ok了。應該讓白帽子參與到漏洞原理分析,觸發提交,并可以提出修補的建議,補丁的確認等流程里。這個也是提醒尊重白帽子的主要途徑。
8、加強平臺建設
這個比較具體的漏洞平臺的設計的一些細節。比如給白帽子提供更多的關于漏洞的細節,如觸發的環境條件的描敘(操作系統、瀏覽器及版本、觸發的錯誤信息等)這樣可以盡可能的減少漏洞重現分析、甚至補丁等的成本。 還如完善交流的機制,減少和白帽子溝通成本等等。
最后,希望以上的一些建議,對于甲方的平臺建設起點作用!更加希望各大甲方重視自己的安全,希望不是“皇帝不急、太監急!”(雖然我不是東方不敗)!
update:
其實還忘記一點就是刷分問題,對于本身基礎底子不夠的甲方,刷分是不可避免的!恰好相反刷分可以加強鞏固技術安全,彌補一些基礎不足。也就是文章里“如何評價甲方漏洞平臺的價值” 的方式來評價的!!