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肯定是要平衡開發運維安全三者的關係的，不會一直傾向性為安全撐腰，而運維和研發的頭肯定都是希望有一個強有力的做安全的外援，在別人心中是不是符合需求且值得信賴這個只有自己去評估了。

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