<b>第3章</b>
甲方安全建設方法論
那些國際安全标準、模型和理論已經講了千萬遍,方法論的東西也許是好東西,但是一般人可能都沒時間去讀完,有時候也會覺得理論脫離實踐,是以本章講的方法論都從是實操出發的。
<b>3.1從零開始</b>
本篇談一下cso上任之初要做些什麼吧。很多沒做過甲方安全的人也許都沒有頭緒,或者你隻是接觸甲方安全的一個細分領域而不是全貌,也許我說的能為你省點腦汁,因為開始是最難的,等過了這個階段找到了感覺,後面的路就平坦了。
<b>1. 三張表</b>
上任之初你需要三張表。第一張表:組織結構圖,這些是開展業務的基礎,掃視一下組織結構中每一塊安全工作的幹系人。例如行政、hr、财務部門是跟公司層面資訊安全管理的全局性制度的制定和釋出相關的部門,内部審計也跟其強相關;基礎架構的運維團隊,運維安全相關的要跟他們合作;研發團隊,可能在組織結構中分散于各個事業部、各産品線,不一定叫研發,但本質都是産品傳遞的團隊,應用安全和基礎伺服器軟體安全相關的要找他們,也是sdl實施的主要對象;營運、市場、客服類職能他們可能沒有直接的系統權限,但是會有一些諸如cms的背景權限(被社工的對象),廣告的引入釋出(挂馬的iframe,黑鍊)等亂七八糟的安全問題的關聯者,他們也是某些重大安全事件上升到社會影響的危機管理的公關部門;(大)資料部門,因為安全也要用到大資料,是複用一套技術架構還是自己搞,這個取決于每個公司的實際狀況,有的自己搞,有的則複用;産品部門,一些跟業務安全和風控相關的安全建設要跟他們合作;cxos:這裡泛指組織中的決策層,什麼問題要借助他們自己拿捏吧,雙刃劍。
第二張表:每一個線上産品(服務)和傳遞團隊(包括其主要負責人)的映射。這張圖實際就是縮水版的問題響應流程,是日常安全問題的視窗,漏洞管理流程主要通過這些管道去推動,一個安全團隊的leader通常需要對應于一個或若幹産品的安全改進。不過這裡也要分一下權重,比如支撐公司主要營收的産品需要一個主力小團隊去負責其sdl全過程,而邊緣性的産品一個小團隊可以并發承接好幾個甚至10個以上的産品,粒度相對粗一點過濾主要的安全問題即可。通常這樣做符合風險管理方法論,但對于深知大公司病又創業過的我來說,還是稍微有些補充的看法,很多成長中的業務,出于起步階段,沒有龐大的使用者群,可能得不到公共職能部門的有力扶持,例如運維、安全等,明日之星的業務完全可能被扼殺在搖籃裡,這種時候對有責任心的安全團隊來說如何帶着vc的眼光選擇性的投入是一件很有意思的事。在一個公司裡是安全團隊的話語權大還是支柱産品線的話語權大?當然是支柱産品,等産品成長起來了再去補安全的課這種事後諸葛亮的事情誰都會做,等業務成長起來後自己都能去建安全團隊了,不一定再需要公共安全團隊的支援。錦上添花還是雪中送炭,業務團隊的這種感受最後也會回報給安全團隊。
第三張表:準确地說應該是第三類,包括全網拓撲、各系統的邏輯架構圖、實體部署圖、各系統間的調用關系、服務治理結構、資料流關系等,這些圖未必一開始就有現成的,促成業務團隊傳遞或者自己去調研都可以,以後的日常工作都需要這些基礎材料。如果運維有資産管理也需要關注一下。
<b>2. 曆史遺留問題</b>
到了這裡你是不是躍躍欲試,想馬上建立完整的安全體系了?估計有人恨不得馬上拿掃描器去掃一遍了,别急,就像那首兒童歌曲唱的“葡萄成熟還早得很呐!”,你現在的角色還是救火隊長,離建設還早,這跟你的能力和視野沒關系,這是客觀情況決定的,一個安全沒有大問題的公司通常也不會去找一個安全負責人。找安全負責人的公司意味着都有一堆安全問題亟待處理。這裡就引申出一個問題,一般情況下都是出了比較嚴重的安全問題才去招聘安全負責人和建立專職的安全團隊的,就是說這些系統曾經被滲透過,或現在正在被控制中,沒有人可以确定哪些是幹淨的,哪些是有問題的,而你加入的時間點往往就是安全一片空白還不确定是不是正在被人搞。有人說系統全部重裝,那你不如直接跟老闆說全部系統下線,域名登出,關門算了,那樣子顯然是行不通的,是以防禦者不是時時處處都占上風。這個問題隻能灰階處理,逐漸建立入侵檢測手段,嘗試發現異常行為,然後以類似灰階滾動更新的方式去做一輪線上系統的後門排查。
<b>3. 初期三件事</b>
一開始的安全不能全線鋪開,而是要集中做好三件事,第一件是事前的安全基線,不可能永遠做事後的救火隊長,是以一定要從源頭盡可能保證你到位後新上線的系統是安全的;第二件是建立事中的監控的能力,各種多元度的入侵檢測,做到有針對性的、及時的救火;第三件是做好事後的應急響應能力,讓應急的時間成本更短,溯源和根因分析的能力更強。
一邊熟悉業務,一邊當救火隊長,一邊籌建團隊基本就是上任後的主要工作了。如果團隊籌建得快,這個階段2~3個月就可以結束了,但以目前招聘相對難的狀況來看可能需要4~6個月。