前言：
高效读书，一张逻辑图读懂、读薄书中重点。
注：下面文字只是对逻辑思维图的”翻译“，节省时间，只看图即可。
安全管理体系逻辑思维图
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.互联网公司即便是很大的厂商也不可能选择在安全方面什么都自己做，比如拨VPN 需要一个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.参与业界交流，避免闭门造车
