3.1 從零開始

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

1．三張表

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

第二張表：每一個線上產品（服務）和交付團隊（包括其主要負責人）的映射。這張圖實際就是縮水版的問題響應流程，是日常安全問題的窗口，漏洞管理流程主要通過這些渠道去推動，一個安全團隊的Leader通常需要對應于一個或若干產品的安全改進。不過這里也要分一下權重，比如支撐公司主要營收的產品需要一個主力小團隊去負責其SDL全過程，而邊緣性的產品一個小團隊可以并發承接好幾個甚至10個以上的產品，粒度相對粗一點過濾主要的安全問題即可。通常這樣做符合風險管理方法論，但對于深知大公司病又創業過的我來說，還是稍微有些補充的看法，很多成長中的業務，出于起步階段，沒有龐大的用戶群，可能得不到公共職能部門的有力扶持，例如運維、安全等，明日之星的業務完全可能被扼殺在搖籃里，這種時候對有責任心的安全團隊來說如何帶著VC的眼光選擇性的投入是一件很有意思的事。在一個公司里是安全團隊的話語權大還是支柱產品線的話語權大？當然是支柱產品，等產品成長起來了再去補安全的課這種事后諸葛亮的事情誰都會做，等業務成長起來后自己都能去建安全團隊了，不一定再需要公共安全團隊的支持。錦上添花還是雪中送炭，業務團隊的這種感受最后也會反饋給安全團隊。

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

2．歷史遺留問題

到了這里你是不是躍躍欲試，想馬上建立完整的安全體系了？估計有人恨不得馬上拿掃描器去掃一遍了，別急，就像那首兒童歌曲唱的“葡萄成熟還早得很吶！”，你現在的角色還是救火隊長，離建設還早，這跟你的能力和視野沒關系，這是客觀情況決定的，一個安全沒有大問題的公司通常也不會去找一個安全負責人。找安全負責人的公司意味著都有一堆安全問題亟待處理。這里就引申出一個問題，一般情況下都是出了比較嚴重的安全問題才去招聘安全負責人和建立專職的安全團隊的，就是說這些系統曾經被滲透過，或現在正在被控制中，沒有人可以確定哪些是干凈的，哪些是有問題的，而你加入的時間點往往就是安全一片空白還不確定是不是正在被人搞。有人說系統全部重裝，那你不如直接跟老板說全部系統下線，域名注銷，關門算了，那樣子顯然是行不通的，所以防御者不是時時處處都占上風。這個問題只能灰度處理，逐步建立入侵檢測手段，嘗試發現異常行為，然后以類似灰度滾動升級的方式去做一輪線上系統的后門排查。

3．初期三件事

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

一邊熟悉業務，一邊當救火隊長，一邊籌建團隊基本就是上任后的主要工作了。如果團隊籌建得快，這個階段2～3個月就可以結束了，但以目前招聘相對難的狀況來看可能需要4～6個月。