企業安全管理（二）

ayazero · 2015/06/23 15:55

0x00 創建一支安全團隊

---

注： 這個題目有一個上下文，就是在我寫的企業安全系列裏，只針對去互聯網公司創建甲方安全團隊，不適用於其餘場景

若是要去一家公司領銜安全建設，第一個問題就是如何創建安全團隊。上面提到不一樣的公司情況對應的安全建設需求是不同的，須要的安全團隊也是不同的，因此我按不一樣的場景來深刻這個問題。

在目前國內的市場中，BAT這種公司基本是不須要你去組團隊的，對安全負責人有需求的公司大約是從準生態級互聯網公司、平臺級互聯網公司、大型集團的互聯網+、千千萬萬的互聯網創業型公司……

若是你在一個小型極客型團隊，Youtube被Google收購前只有17我的，在這樣的公司你本身就是安全團隊，俗稱「one man army」，此時一切title皆浮雲，須要的只是一個全棧工程師。

對於絕大多數創業型公司而言，就像以前所說的，CSO不必定須要，你拉兩個小夥伴一塊兒去幹活就好了，今天BAT的安全總監們，當年也都是手把手幹活的工程師小夥伴，10多年過去了，工程師熬成了「CSO」大叔。當你的公司變成BAT時，只要你成長的夠快，也許下一個就是你本身。

安全的人如今其實很難招，不少企業都找不到安全負責人，因此會有一堆沒有甲方安全實操經驗或者沒有總體安全經驗的人被推上安全Team Leader的崗位，對絕大多數公司而言，安全建設的需求都是聚焦於應用的，因此安全團隊必然也是須要偏網絡和應用的人，大牛顯然是不必的，而懂滲透，有必定網絡系統應用攻防理論基礎的人是最具培養價值的，除此以外乙方的諮詢顧問、搞安全標準的、售前售後等在這個場景下的培養成本都很高，不具備短時間ROI因此都不會是潛在的候選者。在安全技術領域裏，其實只有兩類人會有長期發展潛力：一類酷愛攻防的人，對繞過與阻斷有着天生的興趣，第二類就是可能不是很熱愛安全，可是CS基礎極好的程序員，這一類放哪裏都是牛人，第一類則跟行業相關。粗俗一點的說法找幾個小黑客或者委婉的說法找幾個會滲透的白帽子就能去作企業安全了？這種觀點是否是有人會以爲偏科的厲害了。確實我也認爲會滲透跟作企業安全的系統性建設之間仍是有比較大的鴻溝的，僅僅是說在有限選擇的狀況下，假如你不像某些土豪公司同樣隨便就能招成手，那麼可選的替代方案中最具可行性和性價比的是什麼，之因此選會滲透懂攻防那是由於具有了在實踐層面而不是理論層面真正理解安全工做的基礎，在此基礎上去培養是很是快的，策略、流程、標準、方法論能夠慢慢學，由於這些都不是救火時最須要的技能，而是在和平年代且規模較大的公司才須要的東西。看有些公司的招聘工程師的要求裏還寫着要證書什麼的，不由感慨一下，不少能作事的「騷年」其實根本沒有證書，有證書的人一般適合去作乙方的售前而不是甲方的安全工程師，甲方招聘要求證書的，基本上都是傳統行業，互聯網行業裏這麼寫的一般狀況下你也許應該懷疑一下那裏的總體水平。固然了這個說法對安全負責人的招聘不成立，由於國內的CTO不多有懂安全的，招聘者其實也不知道安全總監到底須要哪些技能，隨便COPY了一個也很正常，高端職位的JD不少時候都是模糊的，除了一個Title以外其餘都要聊了才知道，這時候你就不要去嫌棄JD怎麼寫的這麼差，畢竟老闆也不懂這事該怎麼作，找你就是爲了解決這個問題。

單純攻防型的人在前期培養比較快，但當安全團隊隨着公司規模和業務快速成長時，思惟過於單點的人可能會出現「瓶頸」，後面會提到安全建設其實是分階段的，並且是系統性的，視野和思路開闊的人會從工程師中拔尖出來，成爲安全Team中的Leader。

對於比較大型的平臺級公司而言，安全團隊會有些規模，不僅是須要工程師，還須要有經驗的Leader，必需要有在運維安全，pc端web應用安全以及移動端app安全能獨當一面的人，若是業務安全尚無歸屬或空白地帶的話，還須要籌建業務安全團隊。

準生態級公司建安全團隊這種需求比較少，但由於本身曾被問及這樣的問題，因此就把思考的結果寫出來。對於這種級別的公司，因爲其業務線比較長，研發團隊規模一般也比較龐大，整個基礎架構也構建於相似雲計算的底層架構之上（姑且稱之爲私有云吧），光有應用安全的人是不夠的，安全的領頭人必須本身對企業安全理解夠深，Leader這一級必須對系統性的方法論有足夠的瞭解，隨便舉些例子，（1）在出安全事件時若是leader的第一反應是直接讓人上機器去查後門的，（2）對運維繫統變動風險不瞭解的，（3）對在哪一層作防護性價比最高不熟悉的，（4）不明白救火和治病的區別的（這種思路會一度體如今提的安全整改建議上），諸如此類的狀態去擔任leader就會比較吃力（Leader上面的安全老大天然也會很吃力）。另外Leader的跨組織溝通能力應該比較高，在這種規模的公司，不是你的安全策略提的正確就必定會被人接受的。團隊裏還應該有1-2個大牛級人物，因此帶隊人本身應該是在圈內有影響力的人，不然這些事情實踐起來都很難。

實際上當你進入一個平臺級公司開始，安全建設早已不是一項純技術的工做，而技術管理上的系統性思路會影響整個安全團隊的投產比。

0x01 從零開始

---

本篇就談一下上任之初要作些什麼吧，不少沒作過甲方安全的人也許都沒有頭緒，或者你只是接觸甲方安全的一個細分領域而不是全貌，也許我說的能爲你省點腦汁，由於開始是最難的，等過了這個階段找到了感受後面的路就平坦了。

上任之初你須要三張表。第一張表：組織結構圖，這些是開展業務的基礎，掃視一下組織結構中每一塊安全工做的干係人。例如行政、HR、財務部門是跟公司層面信息安全管理的全局性制度的制定和發佈相關的部門，內部審計也跟他們強相關；基礎架構的運維團隊，運維安全相關的要跟他們合做；研發團隊，可能在組織結構中分散於各個事業部、各產品線，不必定叫研發，但本質都是產品交付的團隊，應用安全和基礎服務器軟件安全相關的要找他們，也是SDL實施的主要對象；運營、市場、客服類職能他們可能沒有直接的系統權限，可是會有一些諸如CMS的後臺權限（被社工的對象），廣告的引入發佈（掛馬的iframe，黑鏈）等亂七八糟的安全問題的關聯者，他們也是某些重大安全事件上升到社會影響的危機管理的公關部門；（大）數據部門，由於安全也要用到大數據，看是複用一套技術架構仍是本身搞，這個取決於每一個公司的實際情況，有的本身搞，有的則複用；產品部門，一些跟業務安全和風控相關的安全建設要跟他們合做；CXOs這裏泛指組織中的決策層，什麼問題要藉助他們本身拿捏吧，雙刃劍。

第二張表：每個線上產品（服務）和交付團隊（包括其主要負責人）的映射。這張圖實際就是縮水版的問題響應流程，是平常安全問題的窗口，漏洞管理流程主要經過這些渠道去push，一個安全team的leader一般須要對應一個或若干產品的安全改進。不過這裏也要分一下權重，好比支撐公司主要營收的產品須要一個主力小團隊去負責其SDL全過程，而邊緣性的產品一個小團隊能夠併發承接好幾個甚至10個以上的產品，粒度相對粗一點過濾主要的安全問題便可，一般這樣作符合風險管理方法論，但對於深知大公司病又創業過的我來講，仍是稍微有些補充的見解，不少成長中的業務，出於起步階段，沒有龐大的用戶羣，可能得不到公共職能的有力扶持，例如運維、安全等，明日之星的業務徹底可能被扼殺在搖籃裏，這種時候對有責任心的安全團隊來講如何帶着VC的眼光選擇性的投入是一件頗有意思的事。在一個公司裏是安全團隊的話語權大仍是支柱產品線的話語權大？固然是支柱產品，等產品成長起來了再去補安全的課這種過後諸葛亮的事情誰都會作，說的難聽一點業務成長起來時本身都能去建安全團隊了，不必定再須要公共安全團隊的支持。錦上添花仍是雪中送炭業務團隊的這種感覺最後也會反饋給安全團隊，so, up 2 u!

第三張表：準確的說應該是第三類，包括全網拓撲，各系統的邏輯架構圖，物理部署圖，各系統間的調用關係，服務治理結構，數據流關係等，這些圖未必一開始就有現成的，促成業務團隊交付或者本身去調研均可以，之後的平常工做都須要這些基礎材料。若是運維有資產管理也須要關注一下。

到了這裏你是否是躍躍欲試，想立刻創建完整的安全體系了？估計有人巴不得拿上掃描器去掃一遍了，別急，就像那兒童歌曲唱的「葡萄成熟還早得很吶！」，你如今的角色仍是救火隊長，離建設還早，這跟你的能力和視野不要緊，這是客觀狀況決定的，一個安全沒有大問題的公司一般也不會去找一個安全負責人。找安全負責人的公司意味着都有一堆安全問題亟待處理。這裏就引伸出一個問題，通常狀況下都是出了比較嚴重的安全問題纔去招聘安全負責人和創建專職的安全團隊的，就是說這些系統曾經被滲透過，或如今正在被控制中，沒有人能夠肯定哪些是乾淨的，哪些是有問題的，而你加入的時間點每每就是安全一片空白還不肯定是否是正在被人搞，有人說系統所有重裝，那你不如直接跟老闆說所有系統下線，域名註銷，關門算了，那樣子顯然是行不通的，因此防護者不是時時到處都佔上風。這個問題只能灰度處理，逐步創建入侵檢測手段，嘗試發現異常行爲，而後以相似灰度滾動升級的方式去作一輪線上系統的後門排查。

一開始的安全不能全線鋪開，而是要集中作好3件事，第一是事前的安全基線，不可能永遠作過後的救火隊長，因此必定要從源頭儘量保證你到位後新上線的系統是安全的；第二件是創建事中的監控的能力，各類多維度的入侵檢測，作到有針對性的、及時的救火；第三件是作好過後的應急響應能力，讓應急的時間成本更短，溯源和根因分析的能力更強。

一邊熟悉業務，一邊當救火隊長，一邊籌建團隊基本就是上任後的主要工做了。若是團隊籌建的快，這段階段2-3個月就能夠結束了。

0x02 不一樣階段的安全建設重點

---

救火階段過去以後會進入正式的安全建設期。第一個階段是基礎的安全建設，這一期主要作生產網絡和辦公網絡的網絡安全的基礎部分。也就是在「不一樣規模的的企業安全」章節裏大中型企業對應的那些需求（固然也包括中小企業的那些），完成的標誌一方面是所提的那些點全都覆蓋到了，另外一方面是在實踐上不落後於公司的總體技術步伐，好比運維側在用puppet，saltstack之類的工具實現了必定程度的自動化運維，那你的安全措施也很差意思是純手工的對不對，若是產品團隊交付已經在用持續集成了，那你是否是也至少提供個帶點自動化的代碼檢查工具，而不是純肉眼去Ctrl+F？這一部分實際上是不少人眼中甲方安全的所有內容，不過我以爲遠不能止於此。若是這個場景切換到準生態級公司，也許要變化一下，直接向全線工具自動化看齊，一開始就同步自研必要的工具。

以上算是解決了安全的溫飽問題，第二階段就是要向更廣的方向拓展，一是廣義的信息安全，之前是在忙於解決不被黑而抽不出身，如今安全相關的事情都要抓起來，從只對接內部IT，運維和研發部門擴展到全公司，跟安全相關的環節須要加入必要的流程，之前下線的硬盤不消磁的如今要重視起來了，之前僱員能夠隨意的披露公司的信息之後就不能夠了，之前僱員離職的帳號不回收的如今開始不可能了，之前DBA能夠給數據庫插條記錄而後去電商上買裝備的，那種事今後開始要一刀切斷，諸如此類的事情還有不少，其實這個時候你能夠把ISO27001拿出來看看了。二是業務安全，好比用戶數據的隱私保護，以前安全只是做爲保障而不是一種前臺可見的競爭力，但如今安全須要封裝起來對用戶可見，對產品競爭力負責，若是公司已經發展到一個很大的平臺，盜號問題都解決不了的，我以爲真的須要考慮一下本身的烏紗帽問題。這一部分對安全圈人士而言可能並不高大上，可能沒太多值得拿出來炫技的部分，可是我認爲這些是務實的安全負責人須要考慮的問題，這些屬於經營管理者視角下的一攬子安全問題，若是這些問題不解決而去發明WAF發明HIDS去，儘管能夠拿到安全圈來發兩篇文章炫耀一下，但從職責上看屬於本末倒置，直接影響公司營收的問題須要先解決。之因此把業務安全放在第二階段而不是去優化安全基礎架構是由於投入產出的邊際成本，投在業務安全上，這一部分產出會比較直觀，對高層來講安全從第一階段到第二階段一直是有明顯可見的產出，而若是此時選擇去優化基礎安全能力，這種產出受邊際成本遞增的影響，效果會極其不肯定，而這時候業務安全問題頻發，就會被倒逼至兩難的境地，一則優化基礎安全的工做作了一半，一則又要考慮是否中途轉去作點救火的事情，而安全產出是安全團隊對公司高層影響力的所在，只有看到持續的產出纔會影響力增長，纔會有持續的投入，尤爲在老闆不是技術出身的公司，他也許很難理解你去發明WAF的價值，他只會問盜號這麼嚴重怎麼不解決。這個問題從工程師的視角和管理者的視角得出的結論可能徹底不一樣，安全對高層的影響力是安全團隊在公司內發展壯大的基礎，這是不少甲方安全團隊之痛，你能夠對比一下本身所在的環境，安全團隊的負責人對大方向的把控上是否是作到了可持續發展，好吧，這個問題有點尖銳。

第三個階段開源工具不足以支撐業務規模，進入自研時代。其實作攻防和研發安全產品徹底是兩碼事，存在巨大的鴻溝，若是拿作攻防的團隊直接去作安全工具開發，恐怕挫折會比較多，即使有些研究員擅長作底層的東西，但對於高併發生產環境的服務器工具而言，仍是有很大的門檻的。另外一方面作攻防和作研發的思路也大相徑庭，此時實際上是在交付產品而不是在樹立安全機制，因此要分拆團隊，另外招人。

第四個階段，安全能力對外開放，成爲乙方，不是全部的甲方安全團隊都會經歷這個階段，故而此處不展開。不過我想最重要的區別是，經營意識，成本意識，運營，總體交付，2B和2C的區別，線下最後一千米。

0x03 如何推進安全策略

---

這是一個在安全負責人的面試中常常被說起的問題，也是在現實生活中甲方團隊每天面對的問題。若是你不是正巧在面試，那怎麼回答這個問題其實不重要。

首先，推進安全策略必須是在組織中自上而下的，先跟高層達成一致，造成共同語言，對安全建設要付出的成本和收益造成基本認知，這個成本不僅是安全團隊的人力成本和所用的IDC資源，還包括安全建設的管理成本，流程可能會變長，發佈鏈條會比過去更長，有些產品可能會停頓整改安全，安全特性的開發可能會佔用正常的功能迭代週期，程序員可能會站起來講安全是束縛，這些都是須要跟各產品線老大達成一致的，他們要認同作安全這件事的價值，你也要儘量的提供輕便的方法不影響業務的速度。在規模較大的公司，只有自上而下的方式才能推得動，若是你反其道行之，那我估計安全團隊多半在公司是沒有地位的，頂多也就是在微博或者技術博客上有些外在的影響力。往下攻略去影響程序員和SA/DBA的難度確定比往上攻略去影響CXO/VPs的難度小，但若是一開始就選擇一條好走的路，實際對安全團隊來講是不負責任的，做爲Leader本身就是要很苦逼的把這一課給過了，不然安全團隊就只能作些補洞、打雜、救火隊長的事。

戰術層面，在我過去的文章《CSO的生存藝術》http://bbs.chinaunix.net/forum.php?mod=viewthread&tid=1163970 中提到一些因勢利導的方法，如今回頭看這些方法當然值得一用，但也不是最早應該拿出來的。不少時候我認爲甲方安全團隊思路受限的地方在於：老是把安全放在研發和運維的對立面上，認爲天生就是有衝突的。不信回顧一下開會時是否是常常有人對着研發和運維說「大家應該如何如何……應該這麼作不然就會被黑……」諸如此類的都反映出意識形態中安全以爲研發就是腦殘，運維就是傻叉。爲何我以前用了「合做」一詞，其實換個角度，你真的瞭解開發和運維嗎，是否是找到個漏洞就心理高高在上了？你是在幫助他們解決問題，仍是在指使他們聽你行事，若是你是產品研發的領頭人，聽到下面的程序員對安全修改怨聲載道會怎麼想？個人建議是從如今開始不要再用「大家」這個詞，而改用「咱們」，自此以後便會驅動你換位思考，感同身受，真正成爲助力業務的夥伴。其實有些問題處理的好，真正讓人感到你提的建議很專業，研發和運維人員不只會接受，並且會認爲本身掌握了更好的編碼技能或者安全配置技能而產生正向的驅動力。再通俗一點，若是安全跟研發的人際關係是好的，提什麼建議都能接受，若是我承認你這我的，那麼我也承認你說的事，反之，本位主義對立，人際關係很差，那無論你提的對不對，老子就是不肯意改，僅僅是迫於CTO的淫威不得不改，但老子心理仍是有怨氣，老子仍是要在代碼裏留個彩蛋。利用高層的大棒去驅動多是一種屢試不爽的技巧，但我認爲不是上策。

安全策略的推進還依賴於安全建設的有效性，若是你們都看到了安全策略的成效，都認爲是有意義的，那麼會支持你去進一步推進安全策略的在整個公司的覆蓋率和覆蓋的維度，反之，若是你們都以爲你只不過是在玩些救火的權宜之計，心理可能會以爲有點low，後續天然也不會很賣力的幫你推，由於沒有認同感。因此安全的影響力是否是徹底依賴於高層的重視，我以爲有關係，但也跟本身的表現有很大的關係。CTO確定是要平衡開發運維安全三者的關係的，不會一直傾向性爲安全撐腰，而運維和研發的頭確定都是但願有一個強有力的作安全的外援，在別人心中是否是符合需求且值得信賴這個只有本身去評估了。

至於程序員鼓勵師，我姑且認爲那是一種實施層面的權宜之計，同時反映出安全行業比較缺乏既懂技術又情商高那麼一點的人。