3.3　如何推动安全策略

这是一个在安全负责人的面试中经常被提及的问题，也是在现实生活中甲方团队天天面对的问题。如果你不是正巧在面试，那怎么回答这个问题其实不重要。

1. 公司层面

首先，推动安全策略必须是在组织中自上而下的，先跟高层达成一致，形成共同语言，对安全建设要付出的成本和收益形成基本认知，这个成本不只是安全团队的人力成本和所用的IDC资源，还包括安全建设的管理成本，流程可能会变长，发布链条会比过去更长，有些产品可能会停顿整改安全，安全特性的开发可能会占用正常的功能迭代周期，程序员可能会站起来说安全是束缚，这些都是需要跟各产品线老大达成一致的，他们要认同做安全这件事的价值，你也要尽可能的提供轻便的方法不影响业务的速度。在规模较大的公司，只有自上而下的方式才能推得动，如果你反其道行之，那我估计安全团队多半在公司是没有地位的，顶多也就是在微博或者技术博客上有些外在的影响力。往下攻略去影响程序员和SA/DBA的难度肯定比往上攻略去影响CXO/VPs的难度小，但如果一开始就选择一条好走的路，实际对安全团队来说是不负责任的，作为团队领导你必须直面困难，否则安全团队就只能做些补洞、打杂、救火队长的事。

2. 战术层面

在我过去的文章“CSO的生存艺术”http://bbs.chinaunix.net/forum.php?mod= view-thread &tid=1163970 中提到一些因势利导的方法，现在回头看这些方法固然值得一用，但也不是最先应该拿出来的。很多时候我认为甲方安全团队思路受限的地方在于：总是把安全放在研发和运维的对立面上，认为天生就是有冲突的。不信回顾一下开会时是不是经常有人对着研发和运维说“你们应该如何如何……应该这么做否则就会被黑……”诸如此类的都反映出意识形态中安全人员觉得研发就是脑残，运维就是傻叉。为什么我之前用了“合作”一词，其实换个角度，你真的了解开发和运维吗，是不是找到个漏洞就心理高高在上了？你是在帮助他们解决问题，还是在指使他们听你行事，如果你是产品研发的领头人，听到下面的程序员对安全修改怨声载道会怎么想？我的建议是从现在开始不要再用“你们”这个词，而改用“我们”，自此之后便会驱动你换位思考，感同身受，真正成为助力业务的伙伴。其实有些问题处理的好，真正让人感到你提的建议很专业，研发和运维人员不仅会接受，而且会认为自己掌握了更好的编码技能或者安全配置技能而产生正向的驱动力。再通俗一点，如果安全跟研发的人际关系是好的，提什么建议都能接受，即如果我认可你这个人，那么我也认可你说的事；反之，如果人际关系不好，那不管你提的对不对，我就是不愿意改，仅仅是迫于CTO的压力不得不改，但我心理还是有怨气，我还是想在代码里留个彩蛋。利用高层的大棒去驱动可能是一种屡试不爽的技巧，但我认为不是上策。

安全策略的推动还依赖于安全建设的有效性，如果大家都看到了安全策略的成效，都认为是有意义的，那么会支持进一步推动安全策略在整个公司的覆盖率和覆盖维度；反之，如果大家都觉得你只不过是在玩些救火的权宜之计，心理可能会觉得有点疲劳，后续自然也不会很卖力帮你推，因为没有认同感。所以安全的影响力是不是完全依赖于高层的重视，我觉得有关系，但也跟自己的表现有很大的关系。CTO肯定要平衡开发、运维、安全三者的关系，不会一直倾向性为安全撑腰，而运维和研发的头肯定都是希望有一个强有力的做安全的外援。在别人心中是不是符合需求且值得信赖这个只有自己去评估了。

至于程序员鼓励师，我姑且认为那是一种实施层面的权宜之计，同时反映出安全行业比较缺少既懂技术且情商又高的人。