談一談安全運營工作是什麼

文丨弼政（職業欠錢），美團基礎安全負責人

0x00. 安全運營的熱議可能是怎麼來的

寫完《我理解的安全運營》這一年來，“安全運營”這個詞恰好有一種火了的架勢：

有些乙方開始在安全峰會舉辦“安全運營”專場，大家坐一起探討到底安全運營是個什麼東西，以及有點什麼“運營技巧”，甚至有一些乙方提供了“安全運營產品”、“安全運營服務”。

時間上的先後順序，有時讓我錯覺，似乎自己開創一輪安全圈創造新詞活動。當然，我個人認知不失調的情況下，還是能夠清醒客觀的認知到，自己肯定沒有這麼大的影響力。那到底是什麼驅動了業界對“安全運營”的關注呢？

也許有2個可能性共同作用促成的：

某活動將安全風險直觀化了

業界普遍從建設期進入運營期

第一點，筆者其實是從TK教主某一次分享中記下來的。大致意思是，資訊資產承載的價值正越來越高，風險也越來越大。

粗淺的解讀，15年前，我在大學宿舍的電腦中毒了，頂多就是我宿舍的同學不能打遊戲了，存在上面的資料丟了就丟了，沒什麼影響。而前兩年，Wannacry的肆虐，讓很多醫院之類的基礎設施系統崩壞，影響到的是社會民生，安全風險越來越直觀，國民認知越來越具體。

除了這些基礎設施和生命安全的案例，涉及到資金安全（銀行卡被盜刷）、App隱私安全（許可權濫用、資料洩露），甚至有人可以入侵心臟起搏器，讓移植了人工心臟的病人直接死去。（安全問題作用於人身安全）。

只不過大家老以為是在電影、新聞裡的才有的黑客攻防素材離自己很遠。組織的決策者其實也有類似的認知。一家公司經營過程中，有風險的事情那麼多，不是所有事情都會去立即馬上去執行的，除非這些風險已經擺在了面前。

一直到最近，國家層面連續多年舉辦的某大型真人實戰演練活動，把烏克蘭、委內瑞拉電網之類的案例，在國內進行近似的呈現。很多組織的決策者（或者安全主管）發現，哎呀，不能只是隨便僱2，3個安全工程師對付一下合規就算了，大家動真格的啊。戳破了以前其樂融融的假象，不再滿足於買幾個安全裝置往角落裡一丟，半年出個報告對付一下合規檢查的敷衍工作，是關注“運營效果”的核心動力。

一旦實實在在的去追求“本來應該做好的安全效果”，大多數人其實都會自覺關注到“運營”這個方向上來。

第二點的理解更簡單，安全從業者之前天天嚷嚷著，安全不受重視，其實是真的。有些企業要不是為了上市合規，說不定壓根不會僱傭安全工程師。招倆安全工程師往往也覺得是給業務拖後腿的，安全工程師這不讓幹，那不讓幹，業務跑不快，在老闆心中一直有著錯誤的認知，覺得安全是負擔而不是保駕護航走的更遠的幫手。

但客觀的說，也有不少企業已經過了最初野蠻生長的階段，市值、體量、社會影響力都不容兒戲了。成長的過程中，企業或多或少也招了點安全工程師，只不過由於人數實在太少，所以並不去追求安全工作是否做到了應有的效果。（雖然團隊在自己的述職文件和技術沙盤圖上，可以假裝自己做了很多工作，只是實際工作裡，這些名詞並不能幫助公司處理好一些低階的風險）

所以，從建設階段的視角來看，很多公司基本的安全建設工作或多或少做完了，也該實實在在的考慮一下，從運營的視角來看，是否可以做的更好了。此時，安全從業者關注“運營”的方法論、小技巧甚至於產品、服務，都是自然而然，理所應當的。

0x01. 以組織規模迭代過程和SDL為例簡單闡述運營工作的開展

因為《我理解的安全運營》的緣故，有些人經常問我，安全運營工作到底長什麼樣子，在裡面幹活的同學都在忙點什麼，有沒有一些小技巧或者方法可以share。

這個話題比較大，所以今天我虛構一個故事，介紹一下，隨著組織規模的不斷膨脹變大，安全工作者可能面臨的主要矛盾變化，並以SDL為例，說一些在人少事多的前提下可能採取的運營思路。掛一漏萬，如果有什麼地方說的不好，歡迎大家批評指正多交流。

比方說某一家網際網路公司，已經有了不少的使用者，業務模式也趨於穩定了。突然有一天被攻擊，之前都是運維和開發捎帶手的去解決（可能也解決的並不專業，但是自己也不知道），因為業務發展不錯，他們不想再親手處理了，就想幹脆招個安全工程師吧。

這時候，一個人的安全部出現了。安全工程師初來乍到一看，公司啥都沒有啊，文件制度上線釋出流程伺服器運維規範，辦公網准入防病毒SSO雙因子因素，反爬風控防作弊。。。

得了，這個工程師除了救火，還要開始張羅一大堆的工作，寫文件（拿行業裡的模板素材換個公司的LOGO最快），勉強算解決了文件制度，能執行多少暫且不論，聊勝於無吧，起碼合規檢查的時候有東西交差。

然後開始人肉去稽核程式碼，也自己去黑一下公司的業務，發現點漏洞推動修復。日常有漏洞預警也知道開始響應了，同時張羅一些專案，逐步去解決防病毒、SDL、入侵檢測、許可權管理等資料安全相關的工作。

因為只有個把安全工程師（也可能隨著業務的發展，團隊擴張到了10人以下），安全的工作量一開起頭來就幾乎沒完沒了，所以大部分的工作只能淺嘗輒止，做完就算（這種現象在開發、運維等團隊同樣存在，畢竟企業發展階段不同，誰都不成熟）。這個階段不追求什麼最佳實踐，能落地就算好的，更別說還有無疾而終的專案呢。

當然公司因為規模也還小，沒什麼人盯著，所以那些事情即便不做很深，也沒出啥大事（或者出不了啥大事）。被真人演習/某些對手盯上了另說……

可是，如果公司業務發展很快，成為垂直領域的明星。樹大招風，被行業主管部門甚至社會輿論給監督上了。老闆開始關注細節，就會覺得這些問題看起來也不難解決啊，怎麼解決的不好呢？現在事情都鬧大了，安全團隊就開始有壓力了。

（嗯，潛臺詞就是，如果公司小，大概率是不會有這些壓力的，所以安全團隊可以相對舒服的繼續幹下去。當然如果主管安全團隊的Leader一開始就懂這些，公司即使沒出什麼大事，大家也會提前遭遇挑戰）

老闆開始期待某一類的問題將來得到一個合理的治理。起碼不能出現低階錯誤，本來很簡單能做好的事，沒盡力，漏了，很容易背上責任心不好的鍋。

我們從“有做一些工作，以應對安全風險”變成了“基本功要過關，免得再出現同類風險不好解釋”的時候，大概率會發現，團隊的資源和能力不夠用。

比如說漏洞管理，大家普遍號稱自己使用SDL的方法論來解決。SDL是微軟很多年前提出來的一個理念，有一本書來介紹這個方法論。但是一句話提煉核心邏輯，其實就是把安全嵌入開發生命週期的每一個流程，這個思路幫助微軟把Windows和Office系列的產品做到了今天的樣子（你會放心的使用微軟家的產品）。這種思路是以專案為單位實施的，一個專案，從立項設計、架構評審、實現、測試、釋出、運營的全週期都要安全工程師參與進去，才算是做好SDL，否則你知道這個專案就一定會有低階錯誤出現。

在國內，稍微大一點的公司，公司的專案可能成千上萬甚至百萬個。

而任何一家公司的安全工程師數量都是有限的，分到SDL這個職能的可能更少，很多公司說不定就個把人。這幾個人能維護個掃描器把公司的每一個Web專案掃一遍，說不定就對敢外分享自己公司做SDL的心得了。白盒審計因為誤報的關係、人工審計因為工作量的關係可能壓根就運營不起來。

（這部分完全看公司實際情況，公司核心專案少，迭代少的時候，也有同行能做到每一行程式碼都親自人肉稽核的。）

如果老闆不在乎不重視（比如說偶爾出個漏洞，也沒被大肆的PR），其實這幾個人也可以開開心心的做自己喜歡的事情，得過且過混著日子。

但是如果老闆指出，因為安全工程師的存在，希望力所能及的減少外面能發現漏洞的可能性，每一個外部報告的漏洞都追究一下是不是真的技術上很難規避，負責SDL的這幾個兄弟就要發愁了。因為真的有很多“本可以做好但是實在很煩的工作懶得去做”，一旦出了問題，也很難說這是一個行業難題別人都搞不定所以我們才出事的呀。

一方面，絕大多數公司的人力支撐不了全公司那麼大的工作量，另一方面，不具備混日子的條件了，那就開幹吧。開動腦筋，抓主要矛盾。

分析一下歷史過往案例，大概率能發現一般新專案上線的時候，RD沒經驗，被白帽子捅得最多，所以把有限的人力集中起來審計新專案應該是比較可行的方法。（能最快速度的減少外部報告漏洞的數量）。

依附於公司的釋出流程，每當有新申請域名、新專案上線，安全工程師要求人工稽核完畢才允許上線，是最合理的方案。

上線成功之後的專案再迭代產生新的漏洞此時還關注不到，所以只要時間拉長，漏洞還是反覆在報。這靠人肉稽核終究不是個辦法呀，咋辦呢？整個掃描器吧，商業的還是開源的或者自研的無所謂，總而言之，有了一個掃描器，應該就能解放自己了。

可是掃描器一開起來，可能馬上就被業務罵死：以前都沒事的，你一掃我的業務掛了，監控告警刷屏了，資料髒了，你趕緊給我停了。

於是給業務解釋：我不掃，以後黑客也會掃的啦，我會盡量規避update/delete相關的危險資產，有風險的Poc儘量不發啦。你也稍微處理一下告警監控，把我以後掃描觸發的告警都遮蔽掉不要緊張啦。

好不容易達成一致，天天掃，可SRC還是天天報漏洞，尤其是一做N倍積分獎勵活動就報得特別歡。以前不操心也就算了，現在每次SRC報的漏洞會琢磨一下，為毛掃描器就掃不出來呢？為毛人工稽核的時候就沒看出來呢？

一覆盤就能發現黑盒掃描器各種細節存在短板，比如URL不全拉（趕緊從NIDS、AccessLog裡找資料補救）、排程問題、POST主動規避導致沒檢測到、爬蟲引擎效率或者能力問題、某些資產Payload積累問題……

這些問題以前不想管，現在老闆重結果了，也不是不能解決，那就整唄。

隨著自己能力的提升，某些型別的問題的確在逐漸減少，當主要矛盾解決掉之後，次要矛盾就上升為了主要矛盾，再繼續解決。

這時候發現，有很多漏洞，要是有原始碼就能很輕鬆的掃出來。那就上個白盒審計的產品唄，一掃，烏壓壓的上萬的告警，仔細一看，就4個有效的，還是低危的XSS……

差點就崩潰了。

那也得接著整啊，跟掃描器一樣，團隊還是就這幾個人（還要分出一些人處理人工審計新上線的專案）。這點資源，不要追求解決業界所有已知的漏洞不出現，追求把公司歷史上出過、最常見的，而且解決起來成本不高的漏洞，做好增量控制更迫在眉睫一些。

於是我們就把白盒審計產品自帶的所有原生規則都幹掉，從頭開始，自己按照OWASP Top 10，還有SRC歷史資料上高頻出現又很容易識別的規則開始，吭哧吭哧寫了幾十個規則。

根據自己的經驗和人工的整理，迭代幾個版本，終於在沒什麼誤報的前提下，能夠識別一些漏洞了。這下好了，自研的白盒審計能力也有了。每次SRC漏報的時候，負責白盒審計專案的同學也要覆盤，這事我從原始碼上是不是一定掃不到呢？

新專案人工審計把關、黑盒自動化例行化掃描、白盒例行化審計（結合程式碼倉庫和釋出平臺控制每一次迭代），都整上來了，公司的SDL能力肯定比之前強多了規範多了。

可是，這樣就行了麼？

其實沒有，越權這種邏輯漏洞如影隨形，幾乎成了各大SRC的心頭病。如果你是個新的白帽子，不知道挖什麼漏洞，可以去試試越權，估計很快能有成就感。

而且越權漏洞這玩意吧，成本賊低，危害卻高很多，比XSS什麼的利用起來爽多了，動不動就能看別人資料，操作別人的資產。PR風險也大。

老闆咄咄逼人之後，這事也必須解決啊，黑盒白盒其實都搞不定。垂直越權黑盒相對還有點可行性，但是水平越權這種東西，有時候業務的邏輯介於公開和半公開之間，掃描器弄倆賬號去看一個ID，返回的結果是一樣（證明B賬號看到了A賬號的資料），so what?這事允不允許只有業務自己說了算，它是個業務邏輯強相關的事啊。

雖然掃描器掃出一大堆的可疑list，但是人工去閉環成本實在太高了（回到了老問題，人一個一個看是看不過來的，中長期天天看這玩意，工程師也要崩潰），哪怕你臨時人工找到了幾個真的有問題的漏洞，但是它不是個長久的事。

問題必須解決，自動化又解決不了，必須人工判斷，安全工程師的人工數量又顯然支援不了全公司。所以順理成章的得出一個結論：這玩意得業務自己人工搞定。

於是很開心的跟業務說：你們應該交付安全的程式碼，這是你們自己的責任啊，越權漏洞這麼難搞，風險又大，出了事不光是我們倒黴，你們也倒黴啊。你們不是有QA環節麼，能不能每一次迭代，QA把越權測試用例當成一個“必選項”啊？

業務聽了聽覺得也有道理，但是你怎麼知道我做沒做好呢？

安全工程師說，我也不知道啊，你要是做了，就在程式碼裡留個暗號，我回頭去原始碼倉庫裡掃這個暗號，誰做了就說明他知道了，沒這個暗號我就發工單提醒他做這個測試。

業務說，那要是有人惡意填這個暗號就是不幹活呢？

安全工程師說，這我也沒辦法，但總比之前強點吧。

於是全公司開始吭哧吭哧照著這個辦，一年之後，越權漏洞整體還真下降了80%。（對，的確存在少部分不正直的人，或者沒做好的人）但這真的是一個不錯的成績了對吧？

然而老闆卻仍然不滿意，他覺得，剩下那20%隱患還是很大啊，難道就真的沒辦法了麼？

安全工程師回答，有是有，就是成本賊高，得把業務直接訪問資料庫給拆開來，弄箇中間層，中間層負責訪問資料，業務只能請求中間層要資料，而且每次請求都要帶上使用者的身份票據，中間層根據票據許可權來判斷返回資料與否。這樣任何一個核心資料加上中間層，業務都遷移改造完畢，未來新的業務要訪問這份資料，因為沒有自由連線資料的許可權，也沒有自己設計許可權的自由，所以就沒機會再犯錯誤了。

微信的全程票據和Google的Gmail都是類似的思想。

那就整吧，於是吭哧吭哧開發票據服務，統一全域性許可權管理系統，一個一個接。

至於啥時候能接完就不知道了。

一邊幹啊乾的，突然發現團隊小夥伴越來越不開心，鬧離職。原來，以前挖洞很爽的小夥伴，天天人肉看業務程式碼，審計出來的都是那些低階漏洞，實在是沒勁。於是把能自動化的都交給黑白盒自動化審計平臺，偏邏輯類的漏洞交給上面“水平越權治理”類的方法。徹底解放小夥伴，大家又能開開心心的一起戰鬥了。

為了讓業務可以多支援幾個QA環節自測的必測專案，還可以結合公司釋出平臺弄一些自動化的問卷，結合業務特性出推薦的一些不同的必備測試項，於是一個“威脅建模平臺”誕生了。

在這個平臺上，結合業務歷史漏洞、涉及到的敏感資料欄位和流向，員工參加線上安全培訓和考試成績（尤其是某員工名下漏洞特別多的時候），綜合給評分，建議對應的同學、管理者有針對性的提升自己的能力。

比如說，掃描器很多主動規避風險的URL資產不敢掃的，可以讓業務自助授權強行掃，例行化，有些白盒審計出來不一定是漏洞（僅僅是不符合安全規範），提醒業務去按規範編碼。

於是很多模糊地帶的東西，通過打分評價激勵體系，鼓勵員工去做多一些配合讓步，可能會進一步提升安全性。

但是這些都是一些運營的思路，如果老闆還是不滿意呢？

答案可能比較簡單，招更多的人，做更多的自動化專案（比如IAST），做更多的人工介入（比如Google的重點專案Chrome，當年是有4個安全工程師直接在專案組內從頭跟到尾，沙箱之類的安全架構設計和實現都是這幾個安全工程師搞出來的）。

整套組合拳打下來，最終，公司的產品安全性一定是有提升的。而這就是一個典型的SDL運營套路。這個套路里有什麼技術含量麼？其實沒有，只要站在“這個問題我不放過，目標不妥協，我覺得其實是可以解決掉，哪怕是解決大部分也好”的角度，那很多團隊都可以做到更好。

當然老闆在整個過程中也可能一直給這個團隊增加難度（比如SRC的活動要求不間斷的增加獎勵的力度），但是每次大家通過分析新的問題聚集性，總能找到新的主要矛盾和解決方法。

我想，這就是我想表達的安全運營了。

它的本質，是我們相信有一些目標不必妥協，本身就可以解決，於是我們竭盡全力，爭取資源或者看菜下飯都行，在現有的資源裡，力所能及的做到最好，實實在在的保護公司的安全。

它和技術無關，但又息息相關，每一次診斷問題的時候，沒有紮實的技術基本功和行業專業視野，其實是很難給出最合適的解決思路的。有很多次，小夥伴的診斷方向其實都可能有了偏差，也是有更多的小夥伴集思廣益給拉了回來。

這樣的安全運營理念，它會“產品化”麼？可以被“平臺化”麼？

我覺得可能很難，但是基於這樣務實的追求，做一些方便的輔助平臺，或者外包服務，應該也是挺受歡迎的吧。

今天就到這，之後結合入侵檢測、應急響應、IT安全（BeyondCorp，你們有時候也叫做零信任或者無邊界），我再分享一下個人的經驗。

最 後，筆 者 如 是 說

嗯，最近團隊在瘋狂的招人。

如果你正經歷著上述類似一個人的安全部的經歷，有著不錯的技術功底（能挖洞、會滲透、懂程式設計），也希望在一個相對大的平臺（有挑戰），做一些比較務實的安全防禦工作，又或者哪怕是研究工作，可以試試來我們團隊。

不看 JD 介紹，就看你個人匹配度，簡歷投遞：zhaobizheng#meituan.com