<b>3.2 不同階段的安全建設重點</b>
<b></b>
<b>1. 戰後重建</b>
救火階段過去之後會進入正式的安全建設期。第一個階段是基礎的安全建設,這一期主要做生産網絡和辦公網絡的網絡安全的基礎部分。也就是在前面1.4節“不同規模企業的安全管理”介紹的大中型企業對應的那些需求(當然也包括中小企業的那些)。完成的标志:一方面是所提的那些點全都覆寫到了,另一方面是在實踐上不落後于公司的整體技術步伐,比如運維側在用puppet、saltstack之類的工具實作了一定程度的自動化運維,那你的安全措施也不好意思是純手工的對不對,如果産品團隊傳遞已經在用持續內建了,那你是不是也至少提供個帶點自動化的代碼檢查工具,而不是純肉眼去ctrl+f?這一部分其實是很多人眼中甲方安全的全部内容,不過我覺得遠不能止于此。如果這個場景切換到準生态級公司,也許要變化一下,直接向全線工具自動化看齊,一開始就同步自研必要的工具。
<b>2. 進階</b>
以上算是解決了安全的溫飽問題,第二階段就是要向更廣的方向拓展。一是廣義的資訊安全,以前是在忙于解決不被黑而抽不出身,現在安全相關的事情都要抓起來,從隻對接内部it,運維和研發部門擴充到全公司,跟安全相關的環節需要加入必要的流程,以前下線的硬碟不消磁的現在要重視起來了,以前雇員可以随意披露公司的資訊以後就不可以了,以前雇員離職的賬号不回收的現在開始不可能了,以前dba可以給資料庫插條記錄然後去電商上賣裝備的,那種事從此開始要一刀切斷,諸如此類的事情還有很多。其實這個時候你可以把iso27001拿出來看看了。二是業務安全,比如使用者資料的隐私保護,之前安全隻是作為保障而不是一種前台可見的競争力,但現在安全需要封裝起來對使用者可見,對産品競争力負責,如果公司已經發展到一個很大的平台,盜号問題都解決不了的,我覺得真的需要考慮一下自己的烏紗帽問題。這一部分對安全圈人士而言可能并不高大上,可能沒太多值得拿出來炫技的部分,但是我認為這些是務實的安全負責人需要考慮的問題,這些屬于經營管理者視角下的一攬子安全問題,如果這些問題不解決而去發明waf發明hids去,盡管可以拿到安全圈來發兩篇文章炫耀一下,但從職責上看屬于本末倒置,直接影響公司營收的問題需要先解決。之是以把業務安全放在第二階段而不是去優化安全基礎架構是因為投入産出的邊際成本,投在業務安全上,這一部分産出會比較直覺,對高層來說安全從第一階段到第二階段一直是有明顯可見的産出,而如果此時選擇去優化基礎安全能力,這種産出受邊際成本遞增的影響,效果會極其不确定,而這時候業務安全問題頻發,就會被倒逼至兩難的境地,一則優化基礎安全的工作做了一半,一則又要考慮是否中途轉去做點救火的事情,而安全産出是安全團隊對公司高層影響力的所在,隻有看到持續的産出才會影響力增加,才會有持續的投入,尤其在老闆不是技術出身的公司,他也許很難了解你去發明waf的價值,他隻會問盜号這麼嚴重怎麼不解決。這個問題從工程師的視角和管理者的視角得出的結論可能完全不同,安全對高層的影響力是安全團隊在公司内發展壯大的基礎,這是很多甲方安全團隊之痛,你可以對比一下自己所在的環境,安全團隊的負責人對大方向的把控上是不是做到了可持續發展,好吧,這個問題有點<b>尖銳。</b>
<b>3. 優化期</b>
第三個階段會感到開源工具不足以支撐業務規模,進入自研工具時代。其實做攻防和研發安全産品完全是兩碼事,存在巨大的鴻溝,如果拿做攻防的團隊直接去做安全工具開發,恐怕挫折會比較多,即便有些研究員擅長做底層的東西,但對于高并發生産環境的伺服器工具而言,還是有很大的門檻。另一方面做攻防和做研發的思路也截然不同,此時其實是在傳遞産品而不是在樹立安全機制,是以要分拆團隊,另外招人。
<b>4. 對外開放</b>
第四個階段,安全能力對外開放,成為乙方,不是所有的甲方安全團隊都會經曆這個階段,故而此處不展開。不過我想最重要的差別是,經營意識,成本意識,營運,整體傳遞,2b和2c的差別,線下最後一公裡。