建立一支安全团队
注： 这个题目有一个上下文，就是在我写的企业安全系列里，只针对去互联网公司建立甲方安全团队，不适用于其他场景
如果要去一家公司领衔安全建设，第一个问题就是如何建立安全团队。上面提到不同的公司状况对应的安全建设需求是不一样的，需要的安全团队也是不一样的，所以我按不同的场景来深入这个问题。
在目前国内的市场中，BAT这种公司基本是不需要你去组团队的，对安全负责人有需求的公司大约是从准生态级互联网公司、平台级互联网公司、大型集团的互联网+、千千万万的互联网创业型公司……
如果你在一个小型极客型团队，Youtube被Google收购前只有17个人，在这样的公司你自己就是安全团队，俗称“one man army”，此时一切title皆浮云，需要的只是一个全栈工程师。
对于绝大多数创业型公司而言，就像之前所说的，CSO不一定需要，你拉两个小伙伴一起去干活就行了，今天BAT的安全总监们，当年也都是手把手干活的工程师小伙伴，10多年过去了，工程师熬成了“CSO”大叔。当你的公司变成BAT时，只要你成长的够快，也许下一个就是你自己。
安全的人现在其实很难招，很多企业都找不到安全负责人，所以会有一堆没有甲方安全实操经验或者没有整体安全经验的人被推上安全Team Leader的岗位，对绝大多数公司而言，安全建设的需求都是聚焦于应用的，所以安全团队必然也是需要偏网络和应用的人，大牛显然是没必要的，而懂渗透，有一定网络系统应用攻防理论基础的人是最具培养价值的，除此之外乙方的咨询顾问、搞安全标准的、售前售后等在这个场景下的培养成本都很高，不具有短期ROI所以都不会是潜在的候选者。在安全技术领域里，其实只有两类人会有长期发展潜力：一类酷爱攻防的人，对绕过与阻断有着天生的兴趣，第二类就是可能不是很热爱安全，但是CS基础极好的程序员，这一类放哪里都是牛人，第一类则跟行业相关。粗俗一点的说法找几个小黑客或者委婉的说法找几个会渗透的白帽子就能去做企业安全了？这种观点是不是有人会觉得偏科的厉害了。确实我也认为会渗透跟做企业安全的系统性建设之间还是有比较大的鸿沟的，仅仅是说在有限选择的情况下，假如你不像某些土豪公司一样随便就能招成手，那么可选的替代方案中最具可行性和性价比的是什么，之所以选会渗透懂攻防那是因为具备了在实践层面而不是理论层面真正理解安全工作的基础，在此基础上去培养是非常快的，策略、流程、标准、方法论可以慢慢学，因为这些都不是救火时最需要的技能，而是在和平年代且规模较大的公司才需要的东西。看有些公司的招聘工程师的要求里还写着要证书什么的，不禁感慨一下，很多能做事的“骚年”其实根本没有证书，有证书的人通常适合去做乙方的售前而不是甲方的安全工程师，甲方招聘要求证书的，基本上都是传统行业，互联网行业里这么写的*通常情况下*你也许应该怀疑一下那里的整体水平。当然了这个说法对安全负责人的招聘不成立，因为国内的CTO很少有懂安全的，招聘者其实也不知道安全总监到底需要哪些技能，随便COPY了一个也很正常，高端职位的JD很多时候都是模糊的，除了一个Title之外其他都要聊了才知道，这时候你就不要去嫌弃JD怎么写的这么差，毕竟老板也不懂这事该怎么做，找你就是为了解决这个问题。
单纯攻防型的人在前期培养比较快，但当安全团队随着公司规模和业务快速成长时，思维过于单点的人可能会出现“瓶颈”，后面会提到安全建设实际上是分阶段的，而且是系统性的，视野和思路开阔的人会从工程师中拔尖出来，成为安全Team中的Leader。
对于比较大型的平台级公司而言，安全团队会有些规模，不只是需要工程师，还需要有经验的Leader，必须要有在运维安全，pc端web应用安全以及移动端app安全能独当一面的人，如果业务安全尚无归属或空白地带的话，还需要筹建业务安全团队。
准生态级公司建安全团队这种需求比较少，但因为自己曾被问及这样的问题，所以就把思考的结果写出来。对于这种级别的公司，由于其业务线比较长，研发团队规模通常也比较庞大，整个基础架构也构建于类似云计算的底层架构之上（姑且称之为私有云吧），光有应用安全的人是不够的，安全的领头人必须自己对企业安全理解够深，Leader这一级必须对系统性的方法论有足够的了解，随便举些例子，
（1）在出安全事件时如果leader的第一反应是直接让人上机器去查后门的，
（2）对运维系统变更风险不了解的，
（3）对在哪一层做防御性价比最高不熟悉的，
（4）不明白救火和治病的区别的（这种思路会一度体现在提的安全整改建议上），
诸如此类的状态去担任leader就会比较吃力（Leader上面的安全老大自然也会很吃力）。另外Leader的跨组织沟通能力应该比较高，在这种规模的公司，不是你的安全策略提的正确就一定会被人接受的。团队里还应该有1-2个大牛级人物，所以带队人自己应该是在圈内有影响力的人，否则这些事情实践起来都很难。
实际上当你进入一个平台级公司开始，安全建设早已不是一项纯技术的工作，而技术管理上的系统性思路会影响整个安全团队的投产比。(http://www.ayazero.com/?p=46)
从零开始
本篇就谈一下上任之初要做些什么吧，很多没做过甲方安全的人也许都没有头绪，或者你只是接触甲方安全的一个细分领域而不是全貌，也许我说的能为你省点脑汁，因为开始是最难的，等过了这个阶段找到了感觉后面的路就平坦了。
上任之初你需要三张表。第一张表：组织结构图，这些是开展业务的基础，扫视一下组织结构中每一块安全工作的干系人。例如行政、HR、财务部门是跟公司层面信息安全管理的全局性制度的制定和发布相关的部门，内部审计也跟他们强相关；基础架构的运维团队，运维安全相关的要跟他们合作；研发团队，可能在组织结构中分散于各个事业部、各产品线，不一定叫研发，但本质都是产品交付的团队，应用安全和基础服务器软件安全相关的要找他们，也是SDL实施的主要对象；运营、市场、客服类职能他们可能没有直接的系统权限，但是会有一些诸如CMS的后台权限（被社工的对象），广告的引入发布（挂马的iframe，黑链）等乱七八糟的安全问题的关联者，他们也是某些重大安全事件上升到社会影响的危机管理的公关部门；（大）数据部门，因为安全也要用到大数据，看是复用一套技术架构还是自己搞，这个取决于每个公司的实际状况，有的自己搞，有的则复用；产品部门，一些跟业务安全和风控相关的安全建设要跟他们合作；CXOs这里泛指组织中的决策层，什么问题要借助他们自己拿捏吧，双刃剑。
第二张表：每一个线上产品（服务）和交付团队（包括其主要负责人）的映射。这张图实际就是缩水版的问题响应流程，是日常安全问题的窗口，漏洞管理流程主要通过这些渠道去push，一个安全team的leader通常需要对应一个或若干产品的安全改进。不过这里也要分一下权重，比如支撑公司主要营收的产品需要一个主力小团队去负责其SDL全过程，而边缘性的产品一个小团队可以并发承接好几个甚至10个以上的产品，粒度相对粗一点过滤主要的安全问题即可，通常这样做符合风险管理方法论，但对于深知大公司病又创业过的我来说，还是稍微有些补充的看法，很多成长中的业务，出于起步阶段，没有庞大的用户群，可能得不到公共职能的有力扶持，例如运维、安全等，明日之星的业务完全可能被扼杀在摇篮里，这种时候对有责任心的安全团队来说如何带着VC的眼光选择性的投入是一件很有意思的事。在一个公司里是安全团队的话语权大还是支柱产品线的话语权大？当然是支柱产品，等产品成长起来了再去补安全的课这种事后诸葛亮的事情谁都会做，说的难听一点业务成长起来时自己都能去建安全团队了，不一定再需要公共安全团队的支持。锦上添花还是雪中送炭业务团队的这种感受最后也会反馈给安全团队，so, up 2 u!
第三张表：准确的说应该是第三类，包括全网拓扑，各系统的逻辑架构图，物理部署图，各系统间的调用关系，服务治理结构，数据流关系等，这些图未必一开始就有现成的，促成业务团队交付或者自己去调研都可以，以后的日常工作都需要这些基础材料。如果运维有资产管理也需要关注一下。
到了这里你是不是跃跃欲试，想马上建立完整的安全体系了？估计有人恨不得拿上扫描器去扫一遍了，别急，就像那儿童歌曲唱的“葡萄成熟还早得很呐！”，你现在的角色还是救火队长，离建设还早，这跟你的能力和视野没关系，这是客观情况决定的，一个安全没有大问题的公司通常也不会去找一个安全负责人。找安全负责人的公司意味着都有一堆安全问题亟待处理。这里就引申出一个问题，一般情况下都是出了比较严重的安全问题才去招聘安全负责人和建立专职的安全团队的，就是说这些系统曾经被渗透过，或现在正在被控制中，没有人可以确定哪些是干净的，哪些是有问题的，而你加入的时间点往往就是安全一片空白还不确定是不是正在被人搞，有人说系统全部重装，那你不如直接跟老板说全部系统下线，域名注销，关门算了，那样子显然是行不通的，所以防御者不是时时处处都占上风。这个问题只能灰度处理，逐步建立入侵检测手段，尝试发现异常行为，然后以类似灰度滚动升级的方式去做一轮线上系统的后门排查。
一开始的安全不能全线铺开，而是要集中做好3件事，第一是事前的安全基线，不可能永远做事后的救火队长，所以一定要从源头尽可能保证你到位后新上线的系统是安全的；第二件是建立事中的监控的能力，各种多维度的入侵检测，做到有针对性的、及时的救火；第三件是做好事后的应急响应能力，让应急的时间成本更短，溯源和根因分析的能力更强。
一边熟悉业务，一边当救火队长，一边筹建团队基本就是上任后的主要工作了。如果团队筹建的快，这段阶段2-3个月就可以结束了。
不同阶段的安全建设重点
救火阶段过去之后会进入正式的安全建设期。第一个阶段是基础的安全建设，这一期主要做生产网络和办公网络的网络安全的基础部分。也就是在“不同规模的的企业安全”章节里大中型企业对应的那些需求（当然也包括中小企业的那些），完成的标志一方面是所提的那些点全都覆盖到了，另一方面是在实践上不落后于公司的整体技术步伐，比如运维侧在用puppet，saltstack之类的工具实现了一定程度的自动化运维，那你的安全措施也不好意思是纯手工的对不对，如果产品团队交付已经在用持续集成了，那你是不是也至少提供个带点自动化的代码检查工具，而不是纯肉眼去Ctrl+F？这一部分其实是很多人眼中甲方安全的全部内容，不过我觉得远不能止于此。如果这个场景切换到准生态级公司，也许要变化一下，直接向全线工具自动化看齐，一开始就同步自研必要的工具。
以上算是解决了安全的温饱问题，第二阶段就是要向更广的方向拓展，一是广义的信息安全，以前是在忙于解决不被黑而抽不出身，现在安全相关的事情都要抓起来，从只对接内部IT，运维和研发部门扩展到全公司，跟安全相关的环节需要加入必要的流程，以前下线的硬盘不消磁的现在要重视起来了，以前雇员可以随意的披露公司的信息以后就不可以了，以前雇员离职的账号不回收的现在开始不可能了，以前DBA可以给数据库插条记录然后去电商上买装备的，那种事从此开始要一刀切断，诸如此类的事情还有很多，其实这个时候你可以把ISO27001拿出来看看了。二是业务安全，比如用户数据的隐私保护，之前安全只是作为保障而不是一种前台可见的竞争力，但现在安全需要封装起来对用户可见，对产品竞争力负责，如果公司已经发展到一个很大的平台，盗号问题都解决不了的，我觉得真的需要考虑一下自己的乌纱帽问题。这一部分对安全圈人士而言可能并不高大上，可能没太多值得拿出来炫技的部分，但是我认为这些是务实的安全负责人需要考虑的问题，这些属于经营管理者视角下的一揽子安全问题，如果这些问题不解决而去发明WAF发明HIDS去，尽管可以拿到安全圈来发两篇文章炫耀一下，但从职责上看属于本末倒置，直接影响公司营收的问题需要先解决。之所以把业务安全放在第二阶段而不是去优化安全基础架构是因为投入产出的边际成本，投在业务安全上，这一部分产出会比较直观，对高层来说安全从第一阶段到第二阶段一直是有明显可见的产出，而如果此时选择去优化基础安全能力，这种产出受边际成本递增的影响，效果会极其不确定，而这时候业务安全问题频发，就会被倒逼至两难的境地，一则优化基础安全的工作做了一半，一则又要考虑是否中途转去做点救火的事情，而安全产出是安全团队对公司高层影响力的所在，只有看到持续的产出才会影响力增加，才会有持续的投入，尤其在老板不是技术出身的公司，他也许很难理解你去发明WAF的价值，他只会问盗号这么严重怎么不解决。这个问题从工程师的视角和管理者的视角得出的结论可能完全不同，安全对高层的影响力是安全团队在公司内发展壮大的基础，这是很多甲方安全团队之痛，你可以对比一下自己所在的环境，安全团队的负责人对大方向的把控上是不是做到了可持续发展，好吧，这个问题有点尖锐。
第三个阶段开源工具不足以支撑业务规模，进入自研时代。其实做攻防和研发安全产品完全是两码事，存在巨大的鸿沟，如果拿做攻防的团队直接去做安全工具开发，恐怕挫折会比较多，即便有些研究员擅长做底层的东西，但对于高并发生产环境的服务器工具而言，还是有很大的门槛的。另一方面做攻防和做研发的思路也截然不同，此时其实是在交付产品而不是在树立安全机制，所以要分拆团队，另外招人。
第四个阶段，安全能力对外开放，成为乙方，不是所有的甲方安全团队都会经历这个阶段，故而此处不展开。不过我想最重要的区别是，经营意识，成本意识，运营，整体交付，2B和2C的区别，线下最后一公里。
如何推动安全策略
这是一个在安全负责人的面试中经常被提及的问题，也是在现实生活中甲方团队天天面对的问题。如果你不是正巧在面试，那怎么回答这个问题其实不重要。
首先，推动安全策略必须是在组织中自上而下的，先跟高层达成一致，形成共同语言，对安全建设要付出的成本和收益形成基本认知，这个成本不只是安全团队的人力成本和所用的IDC资源，还包括安全建设的管理成本，流程可能会变长，发布链条会比过去更长，有些产品可能会停顿整改安全，安全特性的开发可能会占用正常的功能迭代周期，程序员可能会站起来说安全是束缚，这些都是需要跟各产品线老大达成一致的，他们要认同做安全这件事的价值，你也要尽可能的提供轻便的方法不影响业务的速度。在规模较大的公司，只有自上而下的方式才能推得动，如果你反其道行之，那我估计安全团队多半在公司是没有地位的，顶多也就是在微博或者技术博客上有些外在的影响力。往下攻略去影响程序员和SA/DBA的难度肯定比往上攻略去影响CXO/VPs的难度小，但如果一开始就选择一条好走的路，实际对安全团队来说是不负责任的，作为Leader自己就是要很苦逼的把这一课给过了，否则安全团队就只能做些补洞、打杂、救火队长的事。
战术层面，在我过去的文章《CSO的生存艺术》http://bbs.chinaunix.net/forum.php?mod=viewthread&tid=1163970中提到一些因势利导的方法，现在回头看这些方法固然值得一用，但也不是最先应该拿出来的。很多时候我认为甲方安全团队思路受限的地方在于：总是把安全放在研发和运维的对立面上，认为天生就是有冲突的。不信回顾一下开会时是不是经常有人对着研发和运维说“你们应该如何如何……应该这么做否则就会被黑……”诸如此类的都反映出意识形态中安全觉得研发就是脑残，运维就是傻叉。为什么我之前用了“合作”一词，其实换个角度，你真的了解开发和运维吗，是不是找到个漏洞就心理高高在上了？你是在帮助他们解决问题，还是在指使他们听你行事，如果你是产品研发的领头人，听到下面的程序员对安全修改怨声载道会怎么想？我的建议是从现在开始不要再用“你们”这个词，而改用“我们”，自此之后便会驱动你换位思考，感同身受，真正成为助力业务的伙伴。其实有些问题处理的好，真正让人感到你提的建议很专业，研发和运维人员不仅会接受，而且会认为自己掌握了更好的编码技能或者安全配置技能而产生正向的驱动力。再通俗一点，如果安全跟研发的人际关系是好的，提什么建议都能接受，如果我认可你这个人，那么我也认可你说的事，反之，本位主义对立，人际关系不好，那不管你提的对不对，老子就是不愿意改，仅仅是迫于CTO的淫威不得不改，但老子心理还是有怨气，老子还是要在代码里留个彩蛋。利用高层的大棒去驱动可能是一种屡试不爽的技巧，但我认为不是上策。
安全策略的推动还依赖于安全建设的有效性，如果大家都看到了安全策略的成效，都认为是有意义的，那么会支持你去进一步推动安全策略的在整个公司的覆盖率和覆盖的维度，反之，如果大家都觉得你只不过是在玩些救火的权宜之计，心理可能会觉得有点low，后续自然也不会很卖力的帮你推，因为没有认同感。所以安全的影响力是不是完全依赖于高层的重视，我觉得有关系，但也跟自己的表现有很大的关系。CTO肯定是要平衡开发运维安全三者的关系的，不会一直倾向性为安全撑腰，而运维和研发的头肯定都是希望有一个强有力的做安全的外援，在别人心中是不是符合需求且值得信赖这个只有自己去评估了。
至于程序员鼓励师，我姑且认为那是一种实施层面的权宜之计，同时反映出安全行业比较缺少既懂技术又情商高那么一点的人。(http://www.ayazero.com/?p=54)
安全需要向业务妥协吗
安全行业5年以下的新人得到的灌输基本都是“安全不可或缺”，老兵们可能也有点“看破红尘”的味道，觉得高层重不重视安全也就那么回事。对乙方来说高声呼吁安全的重要性哪怕是强调的有点过头也可以理解，因为是赖以生存的利益相关者，靠它吃饭，影响股价。而对于甲方，实际上要分几种，第一类认为安全压倒一切，且心口一致。持有这类想法的实际细分为两种人，第一种对安全行业涉猎不深，还停留在原始的执念阶段，第二种人的思想可以表达为“业务怎么样与我无关，只要不出安全问题，业务死了都无所谓”，这两种从表象上看都属于第一类，而第二类人口头唱安全重要，但心里还是会妥协。以上这些都是甲方安全团队中形形色色的区别。
撇开上述观念，先看安全管理的本质是什么？安全的本质其实是风险管理，绝对的安全可能吗，说绝对安全本身就是个笑话。就像袁哥说的哪怕是Fireeye这样的公司也一样会被APT，原因是攻防不对等，防御者要防御所有的面，而攻击者只要攻破其中一个面的一个点就可以了，公司几千人的客户端行为不是安全管理员能决定和预测的。在所有的面上重兵布防可不可以，理论上可以但实际绝对做不到。接近于绝对安全的系统是什么样的？尽可能的不提供服务、提供服务也只提供最单调的数据交互模型，尽可能少的表现元素，那样的话还是互联网吗，还有用户体验可言吗？而且安全和成本永远要追求一个平衡。假设一个大中型互联网公司的安全建设成本从0-60分需要1000w，60-80分需要2000w，80-90分需要5000w，90-95分需要2亿，这种边际成本递增是很多公司无法承受的，只能追求最佳ROI，虽然最佳ROI难以衡量，但绝大多数人的理性决定了不会拿出收入的50%去投安全建设。
既然安全建设的本质是以一定的成本追求最大的安全防护效果，那一定是会有所妥协的。于是反过来揣摩一下那些说宁可业务死也要做安全的观点的初衷是什么呢，也许你猜到了，怕担责任！因为业务死了安全团队不担责任，他们可以说“你看安全不是没出问题嘛！”这固然是一种保护自己的方法，但是从公司的角度看这就有待商榷了，我认为安全本质还是为业务服务，如果业务死了，即使安全做的再好也没价值，更准确一点说，安全需要为业务量身定制，如果业务要轻装上阵，你给他重甲也不行，只能穿防弹背心。安全做的过于重度都是不合适的。相对而言第二类人拥有更加积极的心态，坚持原则又懂得给业务让路，只是要把握好分寸，避免自己的好心被人利用，成为安全问题不整改的免责窗口，那样就事与愿违了。
安全做的不称职的表现，除了“无视业务死活”，还包括：用户体验大打折扣，产品竞争力下降；公司内部流程大幅增加，严重影响工作效率；限制太多员工满意度严重下降，人员流失；规章制度太多，以至于公司文化显得不近人情……这些都属于安全做过头的表现。
有的人出发的太久，以至于忘了初衷是什么。
那么哪些可以妥协，哪些必须坚守底线呢？高危漏洞，有明显的利用场景，不能妥协。重要的安全特性，比如公有云中的VPC，底层缺少一个安全特性，直接会导致安全建设的上层建筑失去了“地基”，整个都不牢靠了，这种还是要坚持，可以不精致，但必须有。
对于不痛不痒的漏洞，以及待开发的安全功能，如果开发周期很长，受众群体很少，使用该功能的用户比例极少，边缘性产品，只影响某个中间版本到下个版本被其他机制完全取代了，诸如此类的情况可以考虑酌情妥协。当然这还会涉及到另一个话题在不同的维度解决问题，这个之后再展开。
妥协并非退让，而是大局观，试想公司业务没有竞争力时，做安全的一样面临窘境，无论如何都要看主营业务的脸色，与其被动跟随不如快出半个身位。（http://www.ayazero.com/?p=56）