前言

兩年時間在企業安全上能做什麼，筆者嘗試挑戰了一下這個問題。截至寫這篇文章時，還有一些子領域做得不太好，不過既然時間差不多2年了，就拿出來分享一下吧。

對於企業安全建設，能說出來的人很多，但能落地龐大安全體系的人極少，大多需要5-10年。

範圍物件

筆者任職公司是一個擁有數億使用者、各種各樣的業務、幾十個APP、幾十萬Server OS例項、數萬僱員的公司，並且有多家投資公司，上下游有大量產業鏈合作伙伴，還有跨境業務。

在這種體量的公司規模下，先簡單解讀一下面臨的挑戰及安全需求：

1. IDC規模決定不可能用“買買買”搞定這攤子事，也不可能依賴開源軟體，只能開啟大規模自研之路。

2. IT僱員規模雖然不是網際網路行業最大，但也是非常龐大（數萬），並且呈現高度的地域離散化和移動化，除了BeyondCorp之類的搞不定。

3. 不只是做自己的企業邊界內安全就可以，還要兼顧投後賦能、第三方、（資料）供應鏈安全；邊做自己同時還要兼顧生態安全。

4. 建團隊不能只靠HR、獵頭，用常規手段多半是2年也建不起來能消化這些總需求的團隊。

目標設定

對於一個體量雖然不是最大，但跟最大的網際網路公司業務形態非常類似，技術棧廣度又比較接近的情況而言，在結果上必須達到一線網際網路公司將近全部的安全能力，才可以認為滿足當下的需求。

設定這個目標並不是表面做做，或者為了PR的需求，而是真實的需求。稍微展開一下有幾個很關鍵的因素：

實事求是地講，一線網際網路公司安全水平70%-80%左右的能力，並不是一個行業很高的標準，對於大多數公司來說這只是一個真正意義上及格的水平。原因在於70%-80%能力大約也就實現了相對系統化的安全體系，安全能力覆蓋率接近100%，在重點技術棧部分有縱深防禦能力。縱深防禦在很多場景下是及格的入門標準，熟悉攻擊的人都知道，單層防禦沒有兜底方案被突破的機率很大，結果往往等同於安全能力不及格。

那有人也許會問，照你這麼說市面上那麼多公司都不具備所謂的縱深防禦能力，他們全都不及格麼？真相總是殘酷的，筆者也無力回答這個問題。

另一方面，僅僅“滿足當下的需求”並不一定能適配未來的發展，有可能跟不上未來網際網路/IT技術本身的發展，或者表現出安全阻礙業務的效率（不是說安全絕對不阻礙業務，而是說相對行業水平來說拖後腿）。

挑戰一：沒有人

沒有人可能是最大的困擾了，如此龐大的安全體系One man army是不可能的，說的再好，安全負責人的知識結構再完整也無濟於事。且要實現這種目標必須讓團隊具備全棧的能力，不僅僅是web，也不是加二進位制就夠了，而是開發、演算法、隱私保護、運營各樣各樣的全都需要，最終安全團隊的技能需要覆蓋網際網路全技術棧和所有的安全領域（工控這種小眾一點的除外）。上哪兒去搬來這樣的團隊是個大考驗，而且我們還是有倒數計時目標的。

很多時候我們看一家公司的安全能力，不妨先從側面看看他的安全團隊的知識結構和技能，這樣往往可以印證是不是跟他PR的一樣，也可以作為一種側面窺探安全能力的參考。譬如，一個安全團隊規模不大，假如只有30人以下，那麼他基本不太可能具備大規模自研的能力，也不可能去實踐縱深防禦體系。如果一個安全團隊的技能主要以web安全為主，主業也是一個webservice為主的簡單業務，是不是能說安全可以cover了呢？答案是否，因為資產技術棧和防禦技術棧不對等，資產技術棧比攻擊面選擇性稍微大一點，但通常遠大於web的防禦技術棧，所以一旦攻擊涉及到二進位制層面就可能不能從容應對，從現實來說小安全團隊的組成選擇主營業務對口雖然無可厚非，但苛求結果的角度來說不會特別理想。

反之，如果團隊的知識結構沒有問題，而效率、ROI不理想，那麼最大的瓶頸可能在安全負責人。尤其當主營業務相當掙錢，對安全不是那麼計較投產比的時候，往往很容易掩蓋這個問題。

挑戰二：工程能力

對於很多市值100億美元以上公司的安全團隊來說，他們的真實瓶頸往往不是安全技術能力，而是工程化能力。這種所謂的工程化能力體現在能把自研的安全產品、安全系統落地於海量分散式環境，落地於規模龐大的組織的IT系統上，且不降低效能，不影響可用性，不出故障和運營事故。做一個安全產品demo是相對簡單的，但也只是第一步，很多人以為隨便湊幾個RD便可以開發出安全產品部署到數以萬計的系統上，但結果往往會半途而廢。預估不足就在於安全方案設計，規則運營，資料分析都不是最難的，難的往往是效能和可用性。

這也是國內網際網路公司安全能力跟全球頭部公司比安全能力受制約最大的地方。

筆者就職時這家公司的其他技術領域已經有較大的發展和積累，對運維事故、可用性都有嚴格的定義和管理，大多數系統都有比較苛刻的逐年提升的可用性指標，對安全建設來說最大的壞處是你已經享受不到

挑戰三：向上管理能力

經常聽到一些聲音，諸如：

“老闆不重視安全”；

 “不給投入資源”；

“領導是個外行”；

“安全就是個背鍋的”；

“業務方完全不懂安全”；

……

如果你不是問我建設性的建議而僅僅是針對這些現象的看法的話，那麼我認為“以上全錯”，只有一個真實的原因，那就是安全負責人的基本功不到位，甚至有些觀點很危險。

做一個大安全體系需要的能力，已經遠遠超越純技術層面，不能跟高層建立正確的溝通語言，肯定是做不出來的，因為這裡面有太多的事情是需要上下同欲、橫向對齊。即使送你100張安全體系的圖背得滾瓜爛熟，給你一支現成的100人的全技術棧安全團隊，缺了這個能力，你還是會發現安全體系很難落地。

就像筆者寫《網際網路企業安全高階指南》充其量只是寫了些事情該怎麼做，但實際一點沒說CISO該怎麼做，所以很多讀者會發現即使看了那本書想在自己的企業裡落地，但總感覺哪裡還有點問題。現在我來解這個困惑：最大的Gap還是在實踐者的管理基本功和全棧技術視野。

強調工程能力和全棧技術視野的另一重影響是：這個因素直接決定安全團隊和其他團隊（SRE、IaaS和PaaS研發、業務研發）的溝通寬度。當兩者之間的溝通管道越窄時，安全團隊越容易落入自嗨，越寬則有利於作出接地氣的專案。

挑戰四：推動能力

在海量基礎設施和複雜系統中落地考驗的是工程能力以及自動化運維水平（後者通常不是大問題），但這只是面向機器的部分，而安全能力不可避免有面向人的那一部分，且比面向機器的部分多的多，譬如幾個月內讓幾萬僱員全部安裝防毒軟體這無異於進行一場整風運動，連乙方的安全廠商都沒聽說過有甲方能這麼幹的，且這種手段如果屢試不爽是一定會有大的副作用的，而我們設定的時間要求，必須多次、強制、強勢、無反彈的發生類似整風運動這樣的事情，這個極其考驗文案、溝通和推動能力，如果你的團隊是一群純“藍軍”組成的，連個正兒八經能溝通的人都沒有，那麼恭喜你，mission impossible！

筆者也曾聽說過直接讓安全工程師改寫不合規的員工電腦桌面，不知道為什麼，第一反應是安全工程師跟安全負責人有仇，想讓安全負責人儘快下崗。守正出奇應該是一個主旋律，奇的方法偶爾用一兩次還行，如果高頻率的反覆用，安全團隊可能很危險。

挑戰五：專業技能 ？

如果有第5點的話，我想可能是安全負責人本身不能是一個外行和純管理者，因為2年時間沒有算進一個外行管理者自己學習、消化和錯誤決策的成本，而是隻有緊湊的執行時間，也即是對怎麼做不需要思考，而是要在落地效率上快馬加鞭。執行速度加快意味著自己需要知道怎麼做，而不是反覆選型、驗證、推倒重來。也不允許對人和專案上有太多的試水和推倒重來。簡單來說，自己既要知道怎麼做，又要知道招的人能不能做，還要知道人做的好不好。（這句話寫起來很簡單，實際要做到極難）

分解安全體系

圖示的安全體系是一個較通用的技術沙盤，適用市值百億到千億美元公司較通用領域的安全建設。當然這只是個一級技術沙盤，沒有展現更多的細節和實現，也沒有業務相關性，主要給《網際網路企業安全高階指南》做一個面向實操的update。因為書沒有空寫第二版，所以就零零碎碎把一些需要及時update的東西寫出來。

另外這張圖只是展示了傳統意義的安全能力，沒有展現對內的監管、審計和內控。只做隱私保護與網路安全是不夠的，這只是狹義的安全；廣義上的資訊保安仍然有大量對內的工作要做，當然除了安全外，還需要做一些賦能業務的事，你可能覺得光光是這些安全需求已經很多了，難以消化，如果加上對內監管和業務賦能，那事情又比這張技術沙盤多出一倍。也不知道看官們是怎麼定義安全工作的，筆者認為安全做的再好，價值也是有限的。所以筆者所在的安全團隊從來不會只做純安全。

對於技術沙盤中涉及的具體內容，筆者會在另一篇文章《下一代網際網路企業安全架構》中展開。

實現和應對

那說到底這些事情該如何做呢？我們來談談從安全負責人視角（而不是安全工程師視角）展開最重要的事情。這些事情比研發HIDS，態勢感知這些具體的專案重要的多。

• 安全治理框架

首先團隊的技術能力是一種硬能力，這個幾乎沒辦法去講有什麼捷徑。但是對於安全體系而言，首先要做的是建立安全治理模型，明曰模型，實際不是模型，而是一套公司內的安全權責框架，能代表安全團隊本身去推動專案落地，儘量由人為推動變成“輕推動+自我驅動”。安全團隊可能掛靠於各種技術、平臺、職能團隊下，跟CEO之間往往也不是一級彙報關係，本身的組織層級和影響力都是有限的，如果全都靠安全團隊自己去推那就比較累了，所以一定要借虎皮，而且是名正言順的。

建立公司層面的風險統籌視角，並建立相關的虛擬組織對公司/事業群/業務單元風險週期性的評估和控制，對於安全團隊而言相當於有了一個更高階的推手，當然不是說所有的事情都需要透過借虎皮這種方式，其實大部分事情，如果安全團隊本身的溝通表達能力比較專業的話應該尋求內部消化，藉助更高層級通常僅限於重後果、高頻率、大範圍、反覆性的事情。對於這個問題其實也不是說一定要這種形式，任何可以借勢的方法都可以認為是常規手段。

安全管理怎麼做最好其實是沒有標準答案的，所以筆者在這裡也不過多的列出自己的解，避免限制大家的想象力。

對於安全負責人來說不能一上來就陷進技術視角，而是要為團隊開啟道路，否則安全團隊產能高，但落不了地，結果還是不好。

• 業界對標

以筆者長期的觀察，在甲方企業安全這個領域國內沒有公司真正進入“無人區”，都還是有學習和模仿的物件的。積累不足的創新很多時候其實是自嗨，本質上是由於知識量或視野不足，不知道在世界上已經有一個更好的方法而已。在小一點的公司可能周遭人的知識不足以挑戰你，在大公司這種形式上的“創新”則表現為人力和資源的浪費，想到哪裡做到哪裡往往是安全體系建設效率低下的原因。

對於國內的二三線網際網路公司大多在整體技術積累上不表現為太領先和前瞻性，追求安全上的創新筆者認為無此必要，因為從安全團隊的普遍職級、知識結構來看，能完成真正有意義的創新的機率極其低。那是不是完全不需要創新，也不是，跟業態相關的還是有的，譬如全球只有你所在的公司有這種業務形態，那還是有機會去思考對應的獨特解決方案。

對於絕大多數公司而言，業界對標有助於快速識別自己的短板並且相對系統化的進行建設。安全本質上屬於風險管理大類的工作，這類工作最忌諱：有10個風險，今年做3個，明年再做2個，看上去每年的指標還提高了，是不是績效很好了？外行領導可能會陷入這種業績不錯的假象裡。如果不對全域性結果負責，還缺了50%的風險都沒有得到控制，屬於工作做得非常差。做安全的同學，尤其是作為Leader，負責某個領域或者幾個領域，可能經常會被上級問及一個問題，就是安全做得好不好，我也看到過公司高管問下面同學這個問題，立馬回答好或不好的，其實這樣子的回答完全沒有意義，因為好或者不好要看跟誰比，要視資源投入和時間效率來衡量產出。

假設以一家一線公司的安全高投入的結果去跟一個二線公司比，即使小幅領先也是差，但是如果同體量級別公司中，如果能力和效率大幅領先，甚至趕超上一個級別的公司，這種結果才有比較的意義。

以筆者所在的團隊為例，我們會根據公司規模、競爭環境、技術整體成熟度，結合團隊的落地實現能力去階段性的選擇不同的對標和參考物件（具體來說我們現階段會對標全球網際網路行業的頭部公司；部分產品設計領域對標科技行業的某些頭部公司；在地域、國情、業態相關的子領域會參考國內的一線公司，當然為了給團隊設定高標準的底線，末了還會加一句其他公司暫時不參考）。

高標準對於任何一個有追求的團隊來說都是不應放棄的底線。“要做什麼事繼而選擇什麼人”跟“有什麼人繼而選擇做力所能及的事”，這代表了國內安全團隊的分水嶺。考慮團隊落地能力主要是防止揠苗助長的行為，譬如對於一個10人安全團隊，非要去模仿Google那種全棧自研的安全體系確實屬於目標設定失誤。

對於安全負責人來說，如果你所做的事情整體格局低於公司所處的市場地位，那麼你可能危險了。因為在老闆眼裡，你是所有職能模組裡拖後腿的那個人。很多同學不明白公司大了為什麼總要去給自己空降一個更高階別的安全負責人，大抵就是這方面的原因，格局的修煉沒辦法在短時間內靠勤奮速成。

是不是這些東西太虛了，其實也不是，一方面是管理基本功，另一方面是專業技能和技術視野。除了對於安全理解還包括對於安全以外的網際網路通用技術的理解。如果你瞭解一種攻擊緩解機制，這種機制能否大範圍的用在辦公網路的PC，還是大規模運用於生產環境的IaaS，實現方式上能滿足自動化運維，能支援熔斷降級、儘可能不影響效能和使用者體驗，攻防角度對抗價效比最高的攔截檢測點，綜合衡量後的實現方案。強於單點對抗弱於工程技術，或者倒過來都可能造成誤判。所以廣大的安全從業者可以用一個尖銳的視角去評估現有團隊的瓶頸，那就是看安全負責人本人的知識結構和平衡性。

如果你不是CISO，而是純高P，最忌諱的就是你給不出在這個子領域的業界最佳實踐的解，凡事都喜歡自己造輪子，又不能證明生產力，就容易讓團隊陷入尷尬的境地。

在實操上，進行對業界對標時，我們會評估物件在子領域的成熟度，但凡只有Demo，沒有覆蓋率，沒有實際的資料化迭代運營，我們都評估為目標公司在該子領域不具備實際能力。舉例來說做一個anti kernel rootkit的demo很容易，但只要沒有大規模應用，我們就認為不具備能力。Demo可能有PR的價值，但是工程落地上直接對標可能會產生誤導效果。

• 安全研究

安全研究嚴格意義上來說算不上是一個安全的子領域，因為安全研究存在於每一個安全子領域，單獨拉出來說是因為大多數安全團隊的組織結構反映了這是一箇中長期投入的事情，可泛泛的理解為KPI導向相對模糊，有些甚至是純PR。安全研究沒有做的好和不好之說，只有相對接地氣和不接地氣。“未來長什麼樣是沒人知道的”，這句話有兩面性，一種代表不設限，消極地看則是無視成本和投入。

為什麼要在這裡提安全研究，因為對於安全團隊到達一定規模以上，哪怕是兩年的“閃電戰”也必定會涉及，只針對當下做100%的安全運營是不可能滿足業務增長需求的，甚至當其他公司的團隊也在小步快跑時，你只選擇對標當前狀態就會永遠被人甩在身後。彎道超車並非不可能，關鍵在於要對標別人的未來狀態，這句話是不是邏輯有問題，其實對標大部分公司的未來狀態都是有可能的，因為相對於他們自身的業界標杆而言，他們自己也是在學習和模仿的路上，所以這件事的門檻在於你是否能看到業界的發展路徑，如果團隊能力差不多，那麼直接奔下一個點去就會事半功倍，所以整件事情達成效率的關鍵還在於你能否開啟上帝視角，其次就是你在具體的專案上能否判斷是選擇新建，照搬，改進還是因為環境問題選擇性略過對應的安全特性，這些決定了效率。

具體到實操上，安全研究這件事可以分為短期、中期和長期。短期定義為領導廠商已經成功落地的成熟技術，其餘廠商不具備，但我方整體技術環境ready，可以選擇研究（實際上等價於分析）然後複製。中期是目前行業的必然技術趨勢，2-3年可見，進行預研和轉化。長期（定義為3-5年）則是真正意義上為進入“無人區”做準備的，通常只有處於領導市場地位的公司（或挑戰者象限的公司）才有此類需求，這類研究需要管理預期，大多可能會失敗，沒有結論或沒有應用場景，需要容忍投入損失，目測國內有此類實際需求的公司不超過5家。

PR、頂會論文、應用場景、落地產品和服務，這些永遠是在安全研究投入上需要平衡的話題。筆者根據自己所處的業務環境，選擇以能實際落地的短期研究為主，輔之以有應用場景的中期預研，次之可以選擇PR，在沒有進入無人區的預示前不會選擇進行長期研究。這個選擇完全是應時應地制宜，只是一個trade off，結論也不是長期穩定的，會隨環境的變化而變，且預計兩年內會有調整。

限於篇幅和碼字太累，此文先收筆到這裡，關於達成兩年閃電戰的關鍵因素其實還有一些，譬如如何評價和改進安全建設這些打算單獨成文。

小結

最後總結一下提升效率的幾個關鍵因素：

1. 視野平衡性

2. 管理基本功

3. 他山之石可以攻玉

4. 全域性推進方法論

5. ……

如果看官發現我故意省略了最重要的事情請不要說出來。

一 個 廣 告

美團安全2019年招聘火熱進行中~

如果你想加入我們，歡迎簡歷請發至郵箱zhaoyan17@meituan.com。