序言mysql
大人，時代變了linux
面臨的場景不一樣web
技術的不一樣redis
應該怎麼作算法
戰略sql
組織編程
技術json
策略windows
將來的發展安全
是不是創業的方向
序言
近日在看到安全牛發佈的《漏洞管理的八大趨勢》，其中提到了「大量數據和案例代表，雖然漏洞評估和管理工具不斷豐富，可是漏洞管理重在「管理」，企業的漏洞管理或脆弱性風險相關管理依然存在很大的改進空間，例如，人才資金匱乏、缺少對漏洞風險和受影響資產的感知能力、企業孤島和部門戰爭、漏洞修復效率低下等。」這裏僅僅談談「漏洞修復」這一個小的環節，就有不少的發散點。
是的！閉環漏洞很辛苦，夠了！別再讓業務修復各類安全漏洞了。
市面上乙方的各類安全加固方案都談到windows linux系統基線的操做，redis、mysql的加固，常見web漏洞修復方法，操做手冊面面俱到，但鮮有對具體的修復工做開展起來的組織和策略的探討。通過實戰的同行必定知道像fastjson這樣的高危漏洞，並非簡單的響應就完事，若是安所有門僅僅給出業務「升級」兩個字的修復方案，那真是「半天雲裏翻筋頭 -- 遲早要跌跟頭呢」。
看完本文但願讀者們認識到，實施漏洞修復時的組織規劃和策略管理工做相當重要；還須要意識到以往的修復方案常常缺少系統性視角；最後，必須正確地認識到，在漏洞修復這個安全小閉環上，你們在各個方面仍是「愣頭青」，也許是一個巨大的創業空間。
大人，時代變了
面臨的場景不一樣
作安全平常打交道的大量工做是找漏洞和修漏洞。筆者認爲隨着IT技術的發展，漏洞管理中涉及「漏洞修復」的這個動做能夠粗略劃分爲四個階段：
1、早期漏洞修復和補丁管理就是同一回事，以往的漏洞都是IT和操做系統層面。以「永恆之藍」爲例，就是IT和安全團隊一塊兒爲達成安全這一目標實施打補丁。市面上已有的可靠的解決辦法是完善資產管理和保障IT建設的成熟度。
二：近年來主要的問題是web類軟件的安全漏洞，因此SDL和DevSecOps文化的思路強調關注儘可能在軟件開發生命週期早期階段集成漏洞掃描和修復。各類工單系統，黑白盒、高危端口掃描、工單系統，都是合適的解決方案，廣義上SRC（應急響應中心）和威脅情報以後安全團隊的內部流轉也是屬於這一類。
三：ImageMagick和fastjson這裏的漏洞就是關注第三方軟件在應急的時候可否快速準確的修復。近日鬧得沸沸揚揚的Ripple20漏洞涉及全球數億物聯網設備受到影響。因爲軟件供應鏈複雜或未被跟蹤，這類小型庫不只被設備廠商直接使用，並且還被集成到其餘軟件套件中。這意味着許多公司甚至不知道他們正在使用漏洞代碼，並且這個存在漏洞的庫名甚至不會出如今它們的代碼中。目前看到的有效修復辦法是供應商審查和隔離方案。
四：預測將來3-5年會涉及數據安全風險的修復，如何在線上不影響業務到時候，解決一我的臉識別的數據安全漏洞？如何在知足隱私保護的前提下解決數據的加工製造過程當中的安全問題？如何對IOT萬物互聯的億萬臺設備進行統一的漏洞升級？
技術的不一樣
傳統的安全政策僅僅爲了企業合規和不出事，漏洞修復是公司內部的自閉環。如今必需要作出改變了。甲方正面臨着外部要求、內部技術、社會環境、技術發展的多重變化。
-
外部方面：有出海戰略的企業適應GDPR要求（字節跳動禁止中國員工訪問海外產品代碼庫，「內外有別」保平安）；產品和用戶逐步意識到將安全做爲應該具有的默認屬性（自主可控戰略的本質是打破國外公司在互聯網架構上的壟斷，防範軟硬件設施存在影響我國網絡安全的後門和漏洞）；國家監管要求（你懂得）。 -
內部變化也隨着而來，技術上的微服務、容器化，一個漏洞涉及千百萬的服務器，動輒牽一髮而動全身，比以往的打補丁更困難。業務的快速迭代需求的變化再也不須要卡點的漏洞掃描發版流程，但願接入的基礎設施默認安全，甚至自動緩解安全漏洞。 -
社會環境的變化衍生了金融安全、區塊鏈技術、人臉識別、隱私保護的新需求，對安全和對應的修復技術標準提出了新的挑戰。
雖然漏洞修復是平常工做，可是目前缺乏新的方法論指導。SDL重視產品研發，DevSecOps重視安全的協同，都並無談論漏洞修復這件事。實戰中SDL只能解決產品發佈前的漏洞發現、解決、管理，DevSecOps在現在極致專業化分工的時代，還想安全作業務的「修復」的事情，難度可太大了。
歷史的成功經驗不能解決問題，不能用過去來準備將來，要從將來的形態反推安全建設的要求。
應該怎麼作
不像公衆號裏認識到的風風火火的大黑客，安全工做實際90%的基礎工做就是治理漏洞。以上面的安全治理框架爲例（且看筆者務虛=_=!），須要優先創建組織，搭建流程，匹配管理信息，以具體的戰略爲例：
戰略
漏洞安全治理在戰略上只能是模糊的方向，動態的安全戰略。不可能一步到位，須要認知迭代，不斷的試錯失敗。以季度\年爲維度歸零安全團隊的目標，將公司內的有限資源不斷轉移到核心價值上。
固然戰略也取決於安全責任人進入的賽道，伴隨企業業務的發展，符合CTO的市場規劃。跑在好的賽道會很快從「一我的的安所有」到搭建草臺班子。有人才才能執行戰略，單獨的有技術並不能。好的人才，瓶頸是中層。團隊不能負擔戰略，也是很難持續成功的。不要吐槽人手不夠，每一件事老是人手不夠的，人手夠了，還有戰略和組織能力的缺失問題，須要懂權衡的團隊領導帶路，安全的方法論影響力也要跟上。對外安全的修復工做也講究「矯枉過正」，「法於上,僅得爲中,取法於中,故爲其下」，同業務告知安全風險，反覆樹立安全意識，時時講，日日講。
好的工程化能力就是對修復方案有審美能力，知道什麼問題重要，什麼方向有價值，怎麼作安全是優雅的。抉擇漏洞修復、緩解、轉移的幾個安全方案沒有好壞高低之分，只要組織滿意就好。可是實現的路徑和方法卻有好壞之分，有的方法步驟效率高，一步一個臺階，很快逼近安全建設的目標；有的團隊一直在原地打轉，每天在救火，天生一個補鍋匠，還自嘆人手不足。雙方的惟一差異不在大牛的配置，而在對目標和現狀的理解水平有差距。例如全公司的IT編程技術的如今的狀態是剛起步創業公司，所有是基於開源的一我的的安所有的方案，夢想目標狀態是微軟，你必須構造或描述一條從開源到自研的可行線路，而且是時間最短的，成本最低的，風險最小的，這將考驗制定戰略的耐心。不然不少漏洞修復的具體工做的執行者會急躁、搞僵和業務的關係，問題在於主要在對本身現狀不清，不知現狀是什麼，同時對將來的對標對象每每只有一個模糊的概念，並無理解其內涵。
面對須要修復的漏洞太多了，制定戰略的勇氣在於選擇不作什麼。不要盲目追隨新技術，不要妥協短時間的利益。其中的決策讀者們只可意會不可言傳。
組織
作事情的組織搭配從專業上分紅四大塊，戰略；組織和計劃；運營；監控。CISO比較偏重戰略；安全總監比較偏重組織和計劃；而修復數據、面向的業務催修比較偏重運營；漏洞複查時比較偏重監控。人不多是十項全能，只能有所偏重，略懂其餘的內容。通常安全團隊的構成也是有巨大的問題，懂安全人多，懂業務人少，固然通常公司的要求能找到人上手幹活就行，安全團隊的調整難度很是大，致使的後果是如今CISO最累，不只僅是要技術專家，業務專家，還得是管理專家。參考以前的文章《基層安全管理者須要具有的素質》。保證組織能力運轉順暢除了技術能力以外，更要有有持續改進的思惟，輔助不斷組織的治理優化。
縱觀近年安全團隊的發展，還沒有發現單純由於安全入侵而垮臺的公司，可是因管理混亂、向上管理不足和事多人少致使安全團隊一盤散沙坊間卻有活生生例子。談具體修復哪一個漏洞，其實是會有和應急響應有混淆的時候，各位讀者們所處的單位各有各的業務形態，事情須要人作，組織形態千差萬別，幹活的老是攻防對抗出身的安全工程師。執行漏洞修復和平常安全應急的能力要求的不一樣在於前者要求如下五點：
-
工程系統能力
-
產品安全
-
威脅建模
-
安全編碼
-
安全風險管理
對完美候選人的背景要求同時具有漏洞研究、開發能力，有產品線經歷的會比較吃香。技術上千萬不要爲了技術創新而創新，工做是爲了解決問題，只是解決問題的路上，順帶的有創新成果出現。
技術
某些涉及長期規劃的漏洞修復工做必須吃透技術的紅利。以往安全團隊能夠給出基於waf、防火牆技術的漏洞緩解方案，在數據安全，業務安全的崛起時，沒有紅利了。須要注意到企業零信任的場景仍然有巨大的發揮空間。筆者注意到金融行業從業人員已經認識到繼續堆安全盒子已經不可行，提早佈局雲上安全，k8s等基礎安全建設的團隊，會享受到將來的技術紅利。
威脅情報體現了另一個技術極端，掌握超前的技術和信息太多，不但不能提升咱們判斷能力，反而面對一大堆互相矛盾的信息時，若是咱們沒有足夠的專業能力和辨別技術，絕對會不知所措，迷失方向，不能判斷正確與否，猶如走入大霧瀰漫的迷魂陣中，完全全靠朋友圈。也許一個高超的漏洞情報，徹底不用你去修復，隨着時間的推移，會被認爲僅僅是PR而已。
缺少思考的能力
筆者我的認爲專業能力以外，有好奇心、關注創新、敢於接受新的挑戰、願意幫忙的就能夠專職作SDL。但咱們技術人員廣泛缺少的就是思考，更別提什麼反思了，在不經思考的前提下就採起行動、當行動出現阻礙的時候又匆忙用另外一個行動去替換或掩蓋，捨本逐末。常常出現的問題就是，給業務提供的修復方案不專業，說不清方案的價值。以ghostscript這個漏洞爲例，須要思考爲何一個腳本語言的逃逸反而要在imagemagick側來修復緩解，理解思考清楚爲何，才能給出穩定的解決路徑，不斷覆盤，思考讓節奏慢下來，不打擾業務。
策略
漏洞修復策略粗略能夠劃分爲三種：
別人家產品對內的漏洞修復
這個流程通常很清晰了，通常是接受情報源，肯定漏洞級別，排查涉及的資產，拉人修復發工單便可。這裏再也不贅述。
本身家產品對內的漏洞修復
假設我是google，我內部的GCP平臺出現了安全風險能夠影響所有用戶，須要按照如下的流程，逐步發佈，且注意，並非僅僅寫個POC，照抄網上的修復方案就能解決，安全團隊必需要同業務站在一塊兒，懂得影響上下游範圍，懂得跟進發布計劃，懂得閉環此類型問題。不少時候並無合適的安全修復方案， 只能選擇無奈給出臨時緩解技術。
本身家產品對外的漏洞修復
對外有客戶發佈的漏洞修復流程，須要處理的就更復雜了，業界對這類問題談論的少。假設我是google，我對外發布的Chrome出現了反饋的安全風險，必須有複雜的評估流程和發版方案，下面是一個評估標準，讀者們自行領會。
誠然，讀者們會有一個問題，若是有切實的安全漏洞，是否是客戶必須得滯後受影響，沒有知情權，答案是確定的。很無奈，雖然fastjson總出安全問題fastj，按照行業標準，在沒有外部公佈的可利用POC上，fastjson先內部全集團修復，再開源發版的作法是無可指責的。下面給出了一個評估的算法工具，有對外產品出售的公司，能夠對號入座合理排期。
| 得分 | ||||
|---|---|---|---|---|
| 客戶影響數 小於10k 10k-100k 100k以上 |
1 | 2 | 3 | 2 |
| 發現難易度 困難 通常 簡單 |
1 | 2 | 3 | 2 |
| 公開度 我的微博微信 微信公衆號，技術網站 公開站點 |
1 | 2 | 3 | 1 |
| 對商業影響 影響客戶對產品的信心 高價值客戶流失 客戶大量流失 |
1 | 2 | 3 | 2 |
| 後續風險 子產品有風險 同平臺產品有風險 相關產品有相似風險 |
1 | 2 | 3 | 2 |
| 總得分（處置標準參考CVSS 3.0） | 9 |
將來的發展
著名密碼學家、圖靈獎得到者Adi Shamir總結過三條定律：第一，絕對安全的系統不存在；第二，要想風險減半，開支就得翻倍；第三，密碼每每是被繞過而不是被攻破的。而因爲經歷和能力限制，咱們不可能對全部信息和知識都有辨別能力，這就要求咱們限定本身的專業方向和特長，不能漫無目標貪大求全，要穩穩走路。漏洞是修不完的，攻擊者的速度，變化愈來愈快。目標只能是--在合理的性價比下，完成相對安全的建設。這又回到戰略上了--將公司內的有限資源不斷轉移到核心價值上。
是不是創業的方向
筆者我的以爲一款漏洞管理和修復工具會是好的產品。《Gartner 2020九大安全與風險趨勢》提出安全過程自動化的出現消除了重複的任務，漏洞管理屬於SOAR的一部分，確實解決了企業大量不在面對漏洞新聞無所適從的局面，有但願解放生產力。
從具體內容上，這是提供實際的客戶價值。給業務進行一次黑客滲透測試只能引起對方好奇心，客戶更但願更多瞭解具體產品來驗證產品是否有這樣的能力。甲方愈來愈多安全專家，但願乙方不只僅知道漏洞，並非駐場服務，而是客觀解決企業產生的風險。一款能夠修復安全漏洞的產品，是安全服務真正亮肌肉的時刻。
安全的細分領域早期的進入者較容易經過引領/教育市場創建領導品牌。目前的此類的產品爲空。如今的大公司雖然能夠包裝資產管理+漏洞威脅評分，可是沒有接地氣的告知漏洞對於不一樣的企業真正的風險是什麼；漏洞修復方案都是一套模板文字，不能自動化的解決；沒有聯動內部的工單系統；關注安全的攻擊視角，防守者的加固視角欠缺。
並且這個行業賽道足夠寬，能夠取代業務本身的SDL團隊很大一部分工做。技術壁壘會是大量漏洞的自動化緩解修復。門檻是積累的運營數據。
一家之言，你們輕拍磚，歡迎留言探討。
本文分享自微信公衆號 - WhITECat安全團隊（WhITECat_007）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。