寫在轉發之前：
新爺今天給我們推送一個文章，看完片頭，已經很是觸動，決定還是需要寫出來給自己。
211本科信息安全專業，成績一般，水平較差，xsh三年。大學也寫過代碼做過開發方向。後來找工作前，同學們大都走向開發崗或者徹底離開IT行業，做安全的只有那麼幾個大牛（因爲大部分人對於自己的安全水平還是心裏明白的），比如去阿里的某某、360的某某、綠盟的某某。他們都是在安全方向的研發崗，會逆向、會滲透、會彙編等等等等，是老師BitSec最喜歡的樣子。
我比較貪心，技術和管理（姑且這麼叫吧，別說我吹牛逼）兩邊經驗都不想浪費。所以大三暑假在找實習的時候就開始奔着兩個方向兼顧的那種去了。
秋招，某老牌遊戲公司CY的PMO崗位。我感覺選對了，啥都不用想了。在研發小組裏，負責推進項目整體進程。可惜，事與願違，項目組人員飽和，一直在PMO平臺負責相關文職工作，陪着Excel度過了4個月，作爲學生沒經驗也沒什麼思考和總結。
春招到了，從CY出來，還沒離開北京，幾天後在北郵參加現S公司的面試，拿到offer。國內一線網絡安全公司。崗位叫解決方案經理，其實在友商叫售前，在我們這可能特殊點，感覺啥都做，友商戲稱我們半個銷售半個售前。其實我們還捎帶做一些“運營”工作。雖然我是大學同學裏少數的進入安全大公司的，但是由於是市場崗位所以我一直覺得還是沒能在班主任面前擡起頭來。
工作以後，由於公司整體方向和自己崗位稍變的原因，相關運營工作越來越多，反而售前支撐少了，需求運營、行業運營、等保業務運營、解決方案運營…大都經歷過或者在進行中。
每一次用自己的思路去解決完客戶的問題、用自己的思路去實現項目落地、業務落地的時候，也感覺到了其中的價值感。但時不時的還會有對文章中所描述的“劍宗”、“氣宗”的崇拜、羨慕。哪怕到今天爲止，在我眼裏，他們纔是真正的信息安全人才呀。
看到這個文章，再回想起大二時，大高個孫輔導員發的一個朋友圈，他說現在缺的不是懂技術的IT人員，是懂業務的IT人員。
我現在正在這樣的路上走着吧，以後也永遠都不是原作者所言的“劍宗”、“氣宗”，也永遠都不是BitSec老師看着眼裏滿是喜歡的那種學生。
我依舊，會發揮自己的表達優勢、對客戶行業的理解、對項目方案的理解和對產品的綜合利用。因爲，站在全局視角去指揮每個崗位上的專業人員那種感覺，太爽了。那種用過往的經歷（寫過的代碼、做過的項目管理、分析過的方案…）來挽回損失、拿下項目的感覺，太特麼爽了
該學的，還是會學。
===============================================================
以下原文：
曾經，安全圈把從業人員分成劍宗和氣宗。劍宗是掌握一些招式，不需要長年累月的積累“內力”，有時候就能出奇制勝，搞Web安全的“腳本小子”被劃爲這一類，而氣宗因爲需要從彙編、編譯原理等晦澀的知識開始，學習曲線比較陡峭，大器晚成，碰到什麼不明白的地方就反編譯了看看彙編源碼，總能知其所以然，搞二進制的被劃入這一類。
這兩類人，共同看不起的是一類“文職安全工程師” —— 安全管理從業人員
所謂的“文職安全工程師”，往往是知道一些技術的基本概念（但不需要太深入），考個CISSP、學個ISO27001，或者啃一些等級保護制度的要求，知道一些大概的安全域和常規安全概念與解決方案的名詞，在企業裏負責安全合規審查的配合、安全規範制度的撰寫，或者對接乙方供應商，就可以了。近期GDPR的火爆，和早期上市公司對SOX404合規性的需要，也讓各大諮詢服務商培養了大量類似的從業人員。
業界也因此熱議是三分技術，七分管理，還是七分技術，三分管理。
如今，一些大型互聯網企業開始招聘一種叫做“安全運營工程師”的新物種，這是個什麼角色？到底是搞技術的還是搞管理的？我打算從個人的經歷做一些解讀和分享，請大家指正。
安全運營的定義
首先看“運營”的定義，筆者曾經從事網絡遊戲行業，這個行業有一個專門的崗位叫做“運營”，是老闆最愛找的人。
他們日常的工作是什麼呢？
在項目研發的前期，運營同學會根據自己的經驗，把項目常見的一些需求提給研發，此時是需求提出方，或者一定程度上的設計者，但並非產品經理。
一旦項目上線，運營會反覆的體驗產品，找出一些問題，小範圍灰度測試，徵求意見，但最重要的是分析數據（有專業的數據分析團隊按需求支持），診斷問題，再針對性的反饋優化需求，研發/產品 會配合執行。
根據拉新、留存、促銷的場景，不斷的策劃一些宣傳（有市場策劃同學配合）、廣告投放、節假日活動等。
最終，一個產品本身做的好不好，項目收益好不好，生命力強不強，主要看運營同學是否專業。
這樣的角色，可能有些同學會覺得像是“產品經理”，不一定是獨立存在的組織實體，但是他們的職責是比較清晰的，這是一羣爲項目的最終目標負責，從而不斷診斷分析問題、提出需求、協調各方資源，共同達成目標的人。
放在安全這個領域，我們也有類似的訴求：
自研或者採購一些安全產品，引入一些安全解決方案，只是手段，真正的訴求是解決我們的安全風險。
比如，有一些安全工程師非常喜歡寫一個掃描器、做一個HIDS的DEMO、搭建一套大數據分析的平臺、分析某個漏洞的細節並研究POC，這些工作都是有意義的，但是，這不是全部。
我的前領導經常說一句話“手段不是目標”，寫出一個掃描器，是手段，目標是爲了提前檢測出漏洞，減少公司因漏洞帶來的安全風險，寫出一個HIDS也是手段，目標是能夠發現入侵事件，及時止損，搭建一套大數據分析平臺同理。
站在爲目標負責的角度，你的確寫出來了一款掃描器，但是我使用開源產品或者商業產品同樣擁有一款掃描器，除了讓你本人有成就感之外，增加下一份工作的求職籌碼之外，究竟對目標作出了什麼樣的貢獻？
“我做出來了掃描器，可是沒例行跑起來啊，因爲一跑起來，把業務掃掛了/業務告警一大堆抗議了……”
“我的掃描器有例行跑，但是測試用例沒人家的全啊，好多漏洞檢測不出來啊”
“我的測試用例特別全，集衆家之所長，就是誤報多了點，多到什麼程度呢？每一個漏洞我都能檢測出來，但是伴隨着成百上千的誤報，所以得人肉一個一個篩選才能轉發給RD修復”
“我的掃描器很厲害，就是目標URL不在掃描列表裏，經常不在列表裏”
“我的掃描器不錯，但是SRC收到的漏洞一直沒減少，他們都是邏輯漏洞，越權漏洞，這個不是技術上能自動化解決的事啊，所以我不需要改進”
我做出來了HIDS，只不過兼容性差一點，上一次搞掛了業務機器，覆蓋率沒上去，被入侵的機器上都沒裝”
“我做出來了HIDS，採集的數據特別全，後臺存不下了，沒法分析”
“我做出來了HIDS，入侵檢測規則特別厲害，就是誤報稍微多了點，一天1萬單吧，所以只是看不過來恰好沒發現入侵”
“我做出來了HIDS，也報警了，只不過沒有人跟進，他們也看不懂我的告警是什麼意思，要是我親自處理就能抓到黑客了”
……
太多的企業裏，能有一個團隊擁有上述素質的安全工程師已經實屬不易，但是企業真的是爲了我們做出來的掃描器、HIDS之類的手段而付費麼？
我想不是的，企業多數情況下是爲產出付費，而不是爲知識付費。
花錢僱傭一個安全工程師，而工程師僅僅沉浸在自己做出東西的愉悅感裏，並不能爲公司減少安全風險，這是一個很尷尬的局面。
就好像有人僱傭了一個保鏢，武藝高強，但是小混混上來欺負主人的時候，保鏢無動於衷，主人天天被欺負，主人應該爲這個保鏢付費麼？
因此，企業花錢僱傭安全工程師的目標是要解決問題，而解決問題絕不僅僅是把一個安全產品買回來、把一個東西做出來就結束的事情。
在大的公司，解決問題的需求很強烈，安全技術、安全管理、安全開發等角色都具備的前提下，老闆發現某一些安全問題總是無法收斂，最終，引入一類新的角色，對問題進行分析、診斷，發現癥結後，協調資源，終於實現了目標。自此，安全運營工程師就出現在了世人的面前。
- 安全運營的主要職責和技能需求
參考遊戲運營的角色，我將安全運營定義爲：“爲了實現安全目標，提出安全解決構想、驗證效果、分析問題、診斷問題、協調資源解決問題並持續迭代優化的過程”。
這裏最重要的是解決問題，那麼一切影響目標達成的因素，都是運營的職責。
比如，我們招聘了一名優秀的安全工程師，他擁有豐富的掃描器、HIDS開發經驗，喜歡沉浸在技術中無法自拔，但是，每一個掃描的結果，發給RD後，RD產生了大量的諮詢，討論，大量的佔用了這名工程師的時間，以至於很多已知的Bug無法快速修復，每一個HIDS的告警，他無法抽出時間去一一閉環（找業務確認是否存在風險非常耗時），總有一些配合的團隊不靠譜，比如資產列表遺漏了，某個數據同步錯誤了……
這時候產生了大量的“雜活”，讓安全工程師去一一解決，一方面他不喜歡做這些“非技術”的工作，另一方面，他的能力模型也不一定勝任。
因此，讓另一名不需要負責參與研發的同學輔助配合，可能是比較適合的一個方案。
這名同學要解決前者不樂意解決的事情，他必須具備這樣的能力：
a. 擁有安全知識背景，能夠比較好的理解安全場景和需要解決的問題，擅長清晰的總結表達發生了什麼事；
b. 擁有研發、運維相關的背景知識，知道某一類問題的合理解決方案；
c. 擁有較好的溝通能力，可以在安全工程師、安全開發工程師、業務RD/SRE之間搭建溝通的橋樑；
d. 擁有一定的項目管理能力，較好的責任心，確保已知問題能夠得到閉環的解決，涉及到跨團隊的溝通，還需要有一定的大公司跨團隊協作的基本經驗；
e. 具備數據意識，可以提出數據埋點、統計訴求，並細心的將已發生的事件積累成數據素材，形成日常觀測的指標（針對可用性、覆蓋率、效果指標等）
前面的技能訴求比較容易理解，重點說一下最後一條，數據意識。
我曾經在負責入侵檢測項目的時候，領導猛的一下說，把數據拿出來看一下，我懵了，什麼數據？怎麼看？
當時我的內心無比的抗拒，並不知道發生了什麼，只記得後來反覆的被批評積累不夠，我也不知道到底需要積累什麼。
直到隔壁團隊一個看起來不那麼懂安全攻防的同學對我進行了一番輔導，我終於明白了，其實老闆管理的幅度大了，對每一個function的細節根本無法全面瞭解，無數的信息和細節都只是在我們自己的腦子裏，記憶裏，是碎片化的。如果想要給老闆快速的知悉事情的全貌，我們必須自己先設計好一些能夠說清楚主要矛盾的關鍵指標，比如：
a. 歷史上總共發生了多少次有記錄的入侵事件？
b. 每一次入侵事件的發現與否，不同時期的主動發現率比例是多少？
c. 每一次無法發現的根本原因定性是什麼樣的？
d. 已知原因解決的情況如何？
e. 舉一反三之後，如何陳述公司面對入侵的主動發現能力?比如我們可以羅列出多少種攻擊手法，能夠發現其中的多少種？不能發現的部分什麼時候能夠解決，承諾的發現能力在多少覆蓋範圍內是有效的？
……
於是，我們把歷史上的一次又一次的入侵事件記錄，找了一個Excel維護起來，每一個事件的關鍵結論用一個字段來描述，最終形成了以下關鍵指標：
a. HIDS覆蓋率（全部組件健康工作）曲線圖
b. 主動發現率曲線圖
c. 已知攻擊場景覆蓋率
d. 誤報工單收斂曲線圖
e. 每一次入侵響應時間曲線圖
f. 爲了發現入侵相關的基礎數據完整度
g. 每一個策略模型的可用性
……
再一次，被老闆要求彙報工作的時候，我終於可以比較自信的客觀闡述現狀了。我終於知道，原來把數據拿來看一下的含義，其實是要自己把相關的工作做好記錄，並按照上述思路，抽出有價值的指標，用數據量化的方式，來描繪現狀。而這些東西，一直都躺在之前一次又一次的事件記錄裏，一大堆的郵件或者文字的描述，變成有意義的數據之後，變成了我們和管理者溝通的橋樑。
同樣的問題，我看到很多的安全工程師每天都沒閒着，審計代碼發現漏洞、收到SRC報告催修漏洞，好一些的還專門做了一個記錄，差一點的，拉羣說完事情就過了，啥也沒留下。
如果讓他們“把數據拿來看一下”，他們可能啥都拿不出來，或者回去一個一個聊天記錄去搜索，不是缺胳膊就是少腿，大部分關鍵的字段當時並沒有特意去確認，死無對證。
亞馬遜有一個文化是，開啓一個項目之前，要求先寫新聞稿（想象一下，未來發布新聞稿的時候你要怎麼吹牛逼，確定好這個東西的主要矛盾和目標），再寫文檔，最後才寫代碼。
我覺得，安全運營的同學，可以一開始就用上述的思維，倒逼自己要用什麼指標去衡量自己一段時間的工作變化，看一看這些指標應該用哪些東西來表達比較合理，當前工作記錄裏有沒有去確認這些指標，並把每一次事件的關鍵指標維護下來。在半年度的績效總結時，往往才能更清晰的闡述自己的工作價值，寫週報的時候，使用這些數據總結的結論，也更能直觀的印證主要矛盾，指導下一步的工作。
- 安全運營的基本技巧
我們已經知道了，企業是爲你解決的安全問題付費，而不是爲你的知識付費了。
所以，對於一些希望謀求更好的成就感和價值回報的技術同學而言，轉向安全運營其實是一個不錯的選擇。由於能夠帶領項目持續取得結果上的改進，這類同學也比較容易上升到團隊Leader的角色。
那麼，我們安全運營工作中，一般會遇到哪些常見的問題，有什麼應對的技巧呢？
a. 安全的責任劃分
爲了解決安全問題，很多安全工程師本能的會把安全的鍋往自己的身上背。比如研發寫了一個漏洞，拼命的找自己無法發現的原因，同事把代碼上傳到GitHub，拼命的找自己是否能監控到的改進點，或者收到一個漏洞後，拼命的設計一個解決問題的“手段”，研發照做之後，再一次被白帽子繞過打臉……
而業務同學也理直氣壯的決定，我出安全問題，你們安全工程師都幹什麼吃的？要你們有什麼用？
久而久之，鍋背的多了，也就失去了同事和領導的信任，安全工程師和業務同學互道一聲SB，然後各奔東西。
其實這樣的合作模式安全工程師非常的冤枉，本質上，安全工程師的角色應該是醫生，而不是保姆。業務是病人，你有病，我有藥，你吃藥配合鍛鍊身體，有問題大家一起找解決辦法是OK的，而安全工程師開藥方，病人抽菸喝酒熬夜，生病了不接受手術，怪醫生無能的人有沒有呢？比較少吧？
所以，同樣的道理，我們應該不遺餘力的跟業務達成一種醫生和病人的互助關係: 首先任何安全問題出現了，安全團隊都難辭其咎，但是業務方纔是安全風險的主要承擔和責任方。
在這個前提下，安全同學能夠清晰的闡述風險的嚴重程度，我們希望達成的安全目標，手段可以給一些安全建議，但是業務方極有可能會基於自身的瞭解，找出更憂的實現目標的手段。安全的同學在事後輔以驗證（用黑客的攻擊方式多嘗試一下各種繞過對抗），可能會更好。
否則，安全同學在稍微大一點的規模，業務多種多樣，攻擊場景多種多樣，安全工程師不見得每一次都能勝任“可落地的具體技術手段”的工作，此時安全工程師的亞歷山大，一旦業務照着實施後再出事，也很容易影響安全同學的專業口碑和信任。
b. 自上而下還是自下而上
經常有同學發現業務存在安全風險，就直接拉當事人私聊處理，雙方都認爲，如果不到萬不得已，不要拉上級，不給上級添麻煩。
帶來的一個結果就是，有時候事情處理得不合理，不及時，沒閉環，導致一個已知風險被二次利用。要麼就是同一個人、同一個團隊反覆發生類似的問題，但管理者並不知情，沒有人對規避同一類風險舉一反三的專項自查。
又或者有一些需要業務配合的工作，安全工程師以一當百，面向全公司所有一線員工苦口婆心勸導，往往會面對百態人生，各種各樣的困難、藉口、特殊原因都出來了，安全運營工程師活生生的變成了一個一線客服，花了好幾個月的時間只積攢了無數的客觀困難，事情反正就是進展不大，甚至員工還會想出各種各樣的對抗的策略，假意配合轉身卸載之類的。
而一旦拉了雙方Leader，說明清楚風險、必要性和合理性，往往原來需要好幾個月的工期，變成了當天就能完成，原來各種客觀困難，現在都有解決的辦法了。
甚至個別業務的Leader還抱怨說：這麼嚴重的安全事件，應該早點通知我啊，你們安全同學怎麼標準比我自己還低啊？
一頂責任心不足的帽子又迎面而來。
因此，其實在絕大多數場合下，我們認爲，安全無小事，安全無私事。也就是說，任何安全事件，都不是一個人的事情，至少普通事件你的Leader應當知情，高危以上事件，中高層管理者應該知情，並及時對團隊裏類似現象進行輔導和管理。包括一些必要的安全措施，需要全員/多人配合的，往往會動用到業務的人力資源，此時都應該選擇自上而下的推動方式，告知項目的背景和意義，管理者所在團隊的配合進度，透明化晾曬出來，不配合的同學自然而然的會感受到壓力並公開透明的反饋原因。
在抓大放小的前提下，往往能夠節約自己大量的精力，也能快速的推進項目。
至於是否會過於強勢，得罪一線同學，我覺得這個屬於軟技能範疇，最壞情況下不近人情也是爲了執法，如果能有辦法把事情辦成了也不得罪一線，自然是更好的結局，這塊我個人也沒有特別萬能的辦法，如果有同行願意分享經驗最好。
c. 重視宣傳
很多專業的安全技術從業人員特別鄙視PR，覺得PR就是吹噓、沒有技術的代言詞。
但是實際上，在大規模企業裏，符合價值觀的宣導工作，對安全運營的效果是非常明顯的。
比如推行一個項目的前期，有正式立項的kick off，能夠說服高級管理人員支持，不管一線是否本能情願的支持吧，只要事情做完了，及時的反饋感謝兄弟團隊的配合，克服了什麼困難，分享一些運營數據闡述效果，爲公司帶來的正面價值，及時形成郵件、項目總結報告、內部全員推送稿等，往往能夠給項目帶來一種神奇的支持效果。
在日常的運營中，選擇可以引起員工、項目的關鍵支持者共鳴的一些素材，及時的撰寫專業的解讀、分析、經驗總結，贏得大家實在的信任，也有助於提升安全團隊的專業形象，並且給所有人一種“公司有這羣人在負責我們的安全，靠譜”的印象。