建立一支安全团队

在安全技术领域里，其实只有两类人会有长期发展潜力：一类酷爱***的人，对绕过与阻断有着天生的兴趣，第二类就是可能不是很热爱安全，但是CS基础极好的程序员，这一类放哪里都是牛人，第一类则跟行业相关。


单纯***型的人在前期培养比较快，但当安全团队随着公司规模和业务快速成长时，思维过于单点的人可能会出现“瓶颈”，后面会提到安全建设实际上是分阶段的，而且是系统性的，视野和思路开阔的人会从工程师中拔尖出来，成为安全Team中的Leader。


对于比较大型的平台级公司而言，安全团队会有些规模，不只是需要工程师，还需要有经验的Leader，必须要有在运维安全，pc端web应用安全以及移动端app安全能独当一面的人，如果业务安全尚无归属或空白地带的话，还需要筹建业务安全团队。


从零开始


本篇就谈一下上任之初要做些什么吧，很多没做过甲方安全的人也许都没有头绪，或者你只是接触甲方安全的一个细分领域而不是全貌，也许我说的能为你省点脑汁，因为开始是最难的，等过了这个阶段找到了感觉后面的路就平坦了。

上任之初你需要三张表。第一张表：组织结构图，这些是开展业务的基础，扫视一下组织结构中每一块安全工作的干系人。例如行政、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中提到一些因势利导的方法，

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

安全需要向业务妥协吗

哪些可以妥协，哪些必须坚守底线呢？高危漏洞，有明显的利用场景，不能妥协。重要的安全特性，比如公有云中的VPC，底层缺少一个安全特性，直接会导致安全建设的上层建筑失去了“地基”，整个都不牢靠了，这种还是要坚持，可以不精致，但必须有。

对于不痛不痒的漏洞，以及待开发的安全功能，如果开发周期很长，受众群体很少，使用该功能的用户比例极少，边缘性产品，只影响某个中间版本到下个版本被其他机制完全取代了，诸如此类的情况可以考虑酌情妥协。

妥协并非退让，而是大局观，试想公司业务没有竞争力时，做安全的一样面临窘境


转自：https://www.secpulse.com/archives/33912.html