第3章
甲方安全建设方法论
那些国际安全标准、模型和理论已经讲了千万遍，方法论的东西也许是好东西，但是一般人可能都没时间去读完，有时候也会觉得理论脱离实践，所以本章讲的方法论都从是实操出发的。
3.1从零开始
本篇谈一下CSO上任之初要做些什么吧。很多没做过甲方安全的人也许都没有头绪，或者你只是接触甲方安全的一个细分领域而不是全貌，也许我说的能为你省点脑汁，因为开始是最难的，等过了这个阶段找到了感觉，后面的路就平坦了。
1. 三张表
上任之初你需要三张表。第一张表：组织结构图，这些是开展业务的基础，扫视一下组织结构中每一块安全工作的干系人。例如行政、HR、财务部门是跟公司层面信息安全管理的全局性制度的制定和发布相关的部门，内部审计也跟其强相关；基础架构的运维团队，运维安全相关的要跟他们合作；研发团队，可能在组织结构中分散于各个事业部、各产品线，不一定叫研发，但本质都是产品交付的团队，应用安全和基础服务器软件安全相关的要找他们，也是SDL实施的主要对象；运营、市场、客服类职能他们可能没有直接的系统权限，但是会有一些诸如CMS的后台权限（被社工的对象），广告的引入发布（挂马的iframe，黑链）等乱七八糟的安全问题的关联者，他们也是某些重大安全事件上升到社会影响的危机管理的公关部门；（大）数据部门，因为安全也要用到大数据，是复用一套技术架构还是自己搞，这个取决于每个公司的实际状况，有的自己搞，有的则复用；产品部门，一些跟业务安全和风控相关的安全建设要跟他们合作；CXOs：这里泛指组织中的决策层，什么问题要借助他们自己拿捏吧，双刃剑。
第二张表：每一个线上产品（服务）和交付团队（包括其主要负责人）的映射。这张图实际就是缩水版的问题响应流程，是日常安全问题的窗口，漏洞管理流程主要通过这些渠道去推动，一个安全团队的Leader通常需要对应于一个或若干产品的安全改进。不过这里也要分一下权重，比如支撑公司主要营收的产品需要一个主力小团队去负责其SDL全过程，而边缘性的产品一个小团队可以并发承接好几个甚至10个以上的产品，粒度相对粗一点过滤主要的安全问题即可。通常这样做符合风险管理方法论，但对于深知大公司病又创业过的我来说，还是稍微有些补充的看法，很多成长中的业务，出于起步阶段，没有庞大的用户群，可能得不到公共职能部门的有力扶持，例如运维、安全等，明日之星的业务完全可能被扼杀在摇篮里，这种时候对有责任心的安全团队来说如何带着VC的眼光选择性的投入是一件很有意思的事。在一个公司里是安全团队的话语权大还是支柱产品线的话语权大？当然是支柱产品，等产品成长起来了再去补安全的课这种事后诸葛亮的事情谁都会做，等业务成长起来后自己都能去建安全团队了，不一定再需要公共安全团队的支持。锦上添花还是雪中送炭，业务团队的这种感受最后也会反馈给安全团队。
第三张表：准确地说应该是第三类，包括全网拓扑、各系统的逻辑架构图、物理部署图、各系统间的调用关系、服务治理结构、数据流关系等，这些图未必一开始就有现成的，促成业务团队交付或者自己去调研都可以，以后的日常工作都需要这些基础材料。如果运维有资产管理也需要关注一下。
2. 历史遗留问题
到了这里你是不是跃跃欲试，想马上建立完整的安全体系了？估计有人恨不得马上拿扫描器去扫一遍了，别急，就像那首儿童歌曲唱的“葡萄成熟还早得很呐！”，你现在的角色还是救火队长，离建设还早，这跟你的能力和视野没关系，这是客观情况决定的，一个安全没有大问题的公司通常也不会去找一个安全负责人。找安全负责人的公司意味着都有一堆安全问题亟待处理。这里就引申出一个问题，一般情况下都是出了比较严重的安全问题才去招聘安全负责人和建立专职的安全团队的，就是说这些系统曾经被渗透过，或现在正在被控制中，没有人可以确定哪些是干净的，哪些是有问题的，而你加入的时间点往往就是安全一片空白还不确定是不是正在被人搞。有人说系统全部重装，那你不如直接跟老板说全部系统下线，域名注销，关门算了，那样子显然是行不通的，所以防御者不是时时处处都占上风。这个问题只能灰度处理，逐步建立入侵检测手段，尝试发现异常行为，然后以类似灰度滚动升级的方式去做一轮线上系统的后门排查。
3. 初期三件事
一开始的安全不能全线铺开，而是要集中做好三件事，第一件是事前的安全基线，不可能永远做事后的救火队长，所以一定要从源头尽可能保证你到位后新上线的系统是安全的；第二件是建立事中的监控的能力，各种多维度的入侵检测，做到有针对性的、及时的救火；第三件是做好事后的应急响应能力，让应急的时间成本更短，溯源和根因分析的能力更强。
一边熟悉业务，一边当救火队长，一边筹建团队基本就是上任后的主要工作了。如果团队筹建得快，这个阶段2～3个月就可以结束了，但以目前招聘相对难的状况来看可能需要4～6个月。