前言：
高效讀書，一張邏輯圖讀懂、讀薄書中重點。
注：下面文字只是對邏輯思維圖的”翻譯“，節省時間，只看圖即可。

安全管理體系邏輯思維圖

1.說明
1.1.安全管理體系類似於專案管理的PMBOK，本質上是一種方法論和參考維度，覆蓋組織全部的技術活動和全生命週期
1.2.安全管理體系是一個隨業務擴張而逐漸完善的過程
2.相對“全集”
2.1.這裡所說的全集其實算不上是全集，只是一個相對的、偏實操的集合，真正意義上的全集引用了國際上的諸多標準、指南和最佳實踐
2.2.圖13-1 是站在安全職能的角度看平時要做哪些事情

3.組織
3.1.公司規模
3.1.1.較小的安全團隊
不需要很嚴格的劃分，甚至不需要引入過分複雜的團隊管理

3.1.2.發展至20人規模以後
可能需要做一些簡單的工種劃分
3.1.3.比較大型的公司及平臺
一隊做傳統的攻防對抗領域
一隊做偏於業務安全上的“風控”
3.2.圖13-2僅作為組織劃分的示例，現實中不一定按照這樣分

3.3.安全體系內部，業務安全含風控團隊通常是攻防的2倍以上。安全團隊的規模與業務成長的適應性比例參見表13-2

4.KPI
4.1.業界有IT平衡計分卡這樣的工具提供了高緯度的參考，如圖13-3所示

4.2.在“IT使用者滿意度”這個角度，主要是兩個客戶
4.2.1.內部客戶
內部客戶是使用和依賴安全能力的兄弟部門，例如業務線、運維、研發等職能
4.2.2.外部客戶

對於外部客戶，2C型別的業務那就是線上的使用者，安全最大的需求就是保障使用者資料安全，保護使用者隱私，不損失使用者體驗
4.3.“IT內部過程”這個維度，安全作為輔助的職能，最主要就是保障交付、運營等流程的效率
4.3.1.對應安全工作
覆蓋率
覆蓋深度
檢出率/主動止損率
TCO/ROI
技術維度指標
5.外部評價指標
5.1.攻防能力
5.1.1.對攻防的理解是做安全的基礎
5.1.2.業界普遍的狀況是整體實力強的安全團隊攻防能力必然不弱，而攻防能力弱的團隊其安全建設必然強不到哪裡去
5.1.3.攻防技術在安全建設中屬於“單點”技術，決定的是單點的駕馭和深入程度
5.2.視野和方法論
5.2.1.單點技術代表區域性的執行力，但在影響整個安全團隊的產出因素上仍然受制於團隊的整體視野和所使用的方法論
5.2.2.甲方的安全團隊並不是一個純安全研究性質的職能，所以只強調攻防和漏洞是不足以產生高ROI 的，因為安全建設中有很大一部分跟具體的漏洞不相關，跟漏洞緩解和免疫機制也不相關
5.2.3.綜觀業界，過於強調風險管理方法論的單位其解決實際問題的能力往往比較欠缺，而一味強調攻防排斥安全標準的團隊往往頂層安全設計有問題
5.3.工程化能力
5.3.1.對於中大型網際網路公司的安全建設，能否將單點的攻防知識轉換為整個公司業務全線防禦、縱深防禦、自動化的能力就是工程化
5.4.對業務的影響力
5.4.1.這一點跟內部的影響力，跨組織的溝通能力，推動能力，團隊視野有很大的關係。最明顯的特徵就是安全團隊是在做微觀、狹義的安全還是做覆蓋面較大、廣義的安全
5.4.2.安全做得最好的企業一定是將安全和風險意識根植於企業文化中
6.最小集合
6.1.對於創業型公司，不強調流程的公司文化中，為了保障全生命週期的安全管理的實施效果，在流程層面必須要要應對的幾個方面如下
6.1.1.建立事前的安全基線，各種安全程式設計規範、運維配置規範等
6.1.2.事中的釋出&變更環節的安全管理
6.1.3.事後的救火機制
6.1.4.上面3條比較容易理解，但是隻有這3條顯然是不夠的，如果業務在發展而安全永遠停留在這個治理水平上就不太合理，所以必須有一些機制保證安全管理的水平是與時俱進的
6.1.5.把救火逐步轉化為防禦機制或對現有安全策略升級的流程（或團隊意識）
6.1.6.整個公司或至少業務線級別的週期性風險評估，主要用於識別新的風險和潛在的可能轉為安全事件的誘因，以此審視目前的安全體系中是否缺少必要的自檢環節
6.2.資產管理
6.2.1.搞清組織中一共有多少需要納入安全管理範疇的資產是所有安全工作的基礎
6.2.2.資產管理的好壞直接反映運維的管理能力，也很大程度上會影響安全的工作
6.2.3.有了基礎的資產管理以後，對資產做分類分級，既是資訊保安的需求，也是BCM的基礎要求，同時隱私保護也有這個需求
6.3.釋出和變更流程
6.3.1.安全管理中的大部分流程在任何一個公司都不會獨立存在，而是把“安全措施”嵌入到公司其他的研發運營環節中
6.3.2.對網際網路公司而言，變更釋出是價值鏈中佔據最大量的工作之一，所以在這個環節上如何“卡位”，圖13-4簡單做了一個示例

6.3.3.主要在“設計”和“交付”這兩個點設計，在理論篇中也提到設計階段的參與是根據產品輕重程度決定的
6.4.事件處理流程
6.4.1.角色定義
聯絡人（運維/安全）
執行者（運維/研發/安全）
指揮人（技術體系主要負責人）
6.4.2.定義職責矩陣
6.4.3.流程圖
安全運營事故的響應流程如圖13-5所示

6.4.4.系統關聯影響
7.安全產品研發
7.1.以前甲方安全基本不涉及這個話題，在網際網路行業崛起後，以Google為首的業界領導 廠商把自己的方案構建於自研系統和開源軟體之上，這似乎成了行業的潛規則
7.2.根據市場上乙方的安全產品，依葫蘆畫瓢，把原理摸清楚後，尋找相關的開源軟體，逐漸改造成使用分散式架構的安全產品。開始可能不如商業產品好用，但省去了大筆的軟體license和硬體盒子 的費用
7.3.關於是否有必要自研，有幾個方面要考慮
7.3.1.網際網路公司即便是很大的廠商也不可能選擇在安全方面什麼都自己做，比如撥v*n 需要一個RSA的動態令牌，這種並非主營業務，不面向客戶，也沒有多少受眾群 體，花點錢買一下現成的就行了，完全沒必要自己做
7.3.2.規模效應決定價效比的問題：打算自研某個安全產品一定是應用場景覆蓋的IT資產超過某個數量級，這樣所花費的人工研發和維護的成本才會小於同等數量級的IT資產使用商業解決方案時採購的總花費，否則一個很小的業務，幾百臺伺服器，花了10人小團隊用於研發相關的安全產品就是吃力不討好的事
7.3.3.對於攻防類的安全產品比較容易獲得通用的商業解決方案，但對於風控類的產品， 由於跟業務強相關，幾乎鮮有現成的解決方案，所以風控側相較而言自研的需求和必要性更大一些
8.開放與合作
8.1.SRC （安全應急響應中心）只是一個形式上的開端，其更大意義上是指安全工作不能只坐在辦公室裡苦練內功，而是應該走出去尋求與業界廣泛的合作
8.1.1.與乙方安全廠商合作，共享資料和威脅情報
8.1.2.與其他甲方公司或第三方SRC合作，共享威脅情報
8.1.3.與供應鏈上下游合作，使安全過程覆蓋價值鏈的延伸段
8.1.4.參與業界交流，避免閉門造車