郑太海：安全团队如何向老板讲清楚长期安全价值

国内很多企业之所以组建安全团队，一开始大多都是因为监管合规的驱动，或者是安全事件驱动，老板不得不配套建设一个安全团队或者设置安全岗位。所以安全团队总会给老板们造成一些固有印象：

这么多年过去了，上述的这些标签一直贴在安全人员的身上。而我们一直以来都是这么去跟老板汇报自己的价值：

上面这些版本的故事，我们已经讲了很多年。但是现在，很多企业老板实际上是怎么想的？他们会问，如果没有安全团队，是不是也不会出事？如果不部署那些堡垒机和各种防护设备，没有各种各样的安全管控，是不是可能也没有问题，因为风险是个概率问题，我们难以将其显性化。

还有一点，在企业里，安全团队汇报的机会不多，一般的公司安全团队一年也就参加一到两次公司决策层的会议。这就会造成一个现象，去年讲过的故事，今年老板忘了，我们又需要重讲一遍。

那么对于安全团队负责人、企业CSO/CISO来说，如何跟老板讲清楚自己团队的长期价值，就成为了一道摆在眼前的必答题，这道题可能会直接影响到大家长期的职业生涯发展。经过这一两年在公司内部的摸索，以及跟上下各层领导的沟通交流，我总结出了一些安全团队转型的思路，与大家分享。

我总结了四个关键词：主动提效、安全自动化、共创共建和业务安全运营。

第一个关键词，是主动提效。安全要深入了解运维和开发的工作场景，共同整合他们的相关资源，打通由于安全管控要求导致的痛点和难点，以及降低他们效率的地方。举个例子，在登录认证环节，安全的要求是关键系统要进行双因素认证。如果公司采用的是密码＋令牌模式，那意味着每次登录都要输入令牌的随机码。如果只站在安全的角度来看，觉得这没什么大问题。而一旦深入运维场景内部，我们就会发现输一次令牌需要等一分钟的时间。我们深入调研之后发现，有一些运维岗位，一天要登录60多个系统，也就是要输入60次令牌码，每输完一次之后就要等一分钟，一天就要耗费一个小时在登录环节，这还没有计算输入错误的情况，不知道有多少安全团队意识到了这个情况。于是我们就想了一些方案，把全公司的SSO认证信息打通，同一级别的应用系统采用同一套认证信息，在一定时间段内，用户只要输入一次令牌吗，在不关闭浏览器的情况下这些系统可以互相跳转。

还有一个典型的场景——账号纳管。相信很多公司会做特权账号纳管，但是他们仅仅是搭了一套平台，统管了账号的密码。站在安全的角度来看，这种做法可以消除弱口令，但是在这个场景下安全团队是否可以再多做一些主动提效的尝试？例如，很多公司上云之后在主机申请环节就要分配账号和密码，那么我们是否能在这个源头就考虑打通主机申请、账号分配和密码纳管的流程？这样用户就可以避免后续繁琐的、割裂的流程申请。

第二个关键词，是安全自动化。相信很多安全和运维团队对漏洞修复这项工作都比较头痛，因为涉及到资产归属确认、方案评估、系统升级、安全验证等一系列环节。如果资产规模大，光是漏洞归属确认就非常耗时耗力。很多企业虽然有CMDB，但面对大批量的漏洞修复，运维部门还是会怨声载道。在这个场景下，是否有可以自动化的地方？我们的做法是联合主机团队和系统运维团队，提前把一些类型的主机漏洞、中间件漏洞修复和验证的操作脚本化，把这些脚本集成到主机的运维平台中，通过统一的平台进行调度，把漏洞下发、升级、验证等环节打通，实现了一键修复和一键验证的效果。

还有一些风险控制场景可以进行自动化。例如，基于UEBA监控终端操作风险，有一个典型的场景是账号共享风险：不同人的账号不能共享，如果A同事用B同事的账号在自己办公电脑上登录，则会产生一条告警信息。这种情况下我们能否通过IAM进行一些自动化的信息捕捉和提醒，检测到浏览器页面的输入框和本地电脑账号不一致时，提前进行弹框提醒，而不用等到行为发生之后再去追责处罚。

第三个关键词，是共创共建，我又把它叫做“安全＋”。

第一个“安全＋”，是安全＋研发。比如，在SDLC流程里，安全人员和研发人员一起写一些经过验证的安全函数和安全的SDK，在鉴权、文件上传等场景下可以供研发直接调用。安全知识库建设也是跟研发一起合作完成的，所以研发人员自己就会有非常强的意愿去使用。

第二个“安全＋”，是安全＋运营。我们跟运营团队共建一个安全运营中台，解决主机运营过程中账号透明的问题。很多公司的历史主机账号和应用账号，动辄成千上万个，所以账号治理成了一个棘手的问题。我们的方案大致思路是把这些账号封装起来，通过运营中台把变更脚本化，操作人员就不用管具体用哪个账号进行的操作，只要他的变更经过了审批，在合法的时间段和环境内实施变更即可。

第三个“安全＋”，是安全＋架构。最近这两年有一个典型的例子，零信任很难在公司通过安全一个部门去推动落地，因为涉及到整体IT架构的变更迭代，所以本质上是个架构问题，但同时其中又有较多的安全属性，所以就需要安全和架构两个团队通力合作。这两年我们跟云架构团队一直在探索微隔离＋IAM＋SDP如何在内部落地，也有一定的成果输出。

最后一个“安全＋”，是安全＋业务。这里的业务，是公司的主营业务，非技术领域的范畴。举个例子，安全团队可以深入到业务一线，共同深度定制一些安全策略的Checklist，然后将其沉淀下来，形成一种安全能力。当有新业务调整或者发布的时候，就可以直接调用这些Checklist进行自检，并且做成自动化的方式嵌入业务流程中，这样就能在业务上线前发现业务规则的漏洞。如果做到了这一点，可以说安全与业务做到了深度融合，那么业务一定程度上也就离不开安全。

如果要做到上面这几点，我认为安全人员要有一个意识：让安全懂业务，比让业务懂安全的门槛低。安全团队在招聘之初，就可以有选择性地招一些有开发背景和运维背景的人员，提前做一些储备。

以上就是安全团队能向老板讲清楚自己价值的几点建议。最后补充一点：我们要把所有的成果进行量化，比如说自动化提效，安全＋研发/运营/架构/业务所形成的一系列成果和数据，能体系化地呈现出来。如果“安全＋”的效果好，这些数据不用安全团队自己去跟老板汇报，研发、运营和业务团队会主动帮我们汇报，并且他们能站在业务的角度讲清楚安全能给他们带来什么价值。用一个词来总结一下我的核心观点——BuSecOps，Bu即Business，就是安全最终要迈向BuSecOps，要跟业务进行深度地绑定，跟业务共生。