安全团队在企业中的几个身份 – 作者:huangle0914-安全小百科

很多安全团队都希望公司高层能更重视安全，但更多时候安全团队需要先认清自己再公司内的身份。这是让公司领导重视安全团队的前提。笔者认为，安全团队至少要担任如下几个身份：

1、能力的提供者；

2、一类问题的解决者；

3、服务+协作者。

一、能力的提供者

安全团队具备的最直接的能力当然是专业的安全能力，包括：漏洞挖掘、安全策略制定、应急响应、代码审计、甚至是SDL等等。这些不用多说，这一节的关键词不是“安全能力”，而是“专业”。既然公司有了专职的安全团队，大家对这个团队的期望一定是专业的。专业不仅仅指的是专业知识，也包括视角的专业。

举个例子，一个业务即将上线，业务场景是这样的，用户上传一张照片，这个应用将这个照片转变成特定风格。在这个场景里，我们不仅要对这个应用做漏洞扫描，源码审核等常规安全手段。还要考虑到用户是否会上传色情照片？政治敏感照片？我们的审核流程是什么样的？是先审后发，还是先发后审？如果是先发后审，我们的风险有多大？

如果是先审后发，是人工审核还是利用图片识别接口审核？一旦出现图片识别接口失效或漏报我们有没有应急策略？面对可能的风险我们选择接受还是放弃这个业务上线？

上述问题都是需要安全部门提出并解答的，就算不能解答也要给出选项，并说明每个选项带来的后果，以便高层领导选择。

二、一类问题的解决者

我们从一个简短的故事开始：

我的一个朋友在公司里遇到了这么一个情况：

某天的一个入侵事件由运维无意中发现，通知我的这位朋友之后，又由运维主导解决了这次事件。事后，运维部门的同事提出了这样一个问题：事件是我们发现的，也是我们解决的。那要你安全团队有什么用？

我听他讲到这之后，心中一惊。暗想我要是遇到这种情况可能就跟人家杠上了，说公司不投资源啊，政策跟不上啊，之类的。反正不是我的问题。但是我那个朋友云淡风轻的说了一句“我的责任是让这类事儿不再发生”。

是的，安全部门有时候看起来用处确实不大，但我们要对内树立我们自己的价值，之前说的识别并解决公司核心问题是一个。这里又提出一点，我们要根据已经发生的事，制定安全策略，让这类事件不再发生。

虽然事后补救总是感觉不完美，但是从我个人的经验上看，在大多数企业内，如果安全团队真的能保证任何一类（可以是很细的分类）的安全事件都只发生一次。那绝可以把安全做的非常好。

再介绍一个笔者亲身的经历——安全数据分析。

在启动这项工作的时候，我的要求是先把之前的安全事件都分析一遍，为什么黑客能绕过我们的检测策略。第一步开发任务就是把这方面的工作补齐，这一步做完之后我就可以对内宣布，之前所有发生过的入侵事件，如果再次发生，我会第一时间发现。也就是说，就算我们可能被入侵，也不会跟之前的一样。然后我们再根据数据分析的全景图（第一步开发过程中设计的），进行有一定前瞻性的开发。这么做的好处有两个。

一是之前发生过的问题，一般来说都是大概率再发生的，除非事件之后可以通过防御手段100%实现防御（这里探讨的事数据分析工作，所以暂不探讨防御问题）。针对大概率事件做数据分析性价比就比较高。

二是解决之前发生过的问题，在汇报工作的时候比较容易体现价值。毕竟你彻底解决了一个曾经发生过的问题，和你试图想解决一个臆想中可能发生的问题相比，前者价值一定更高。

解决一类问题的笔者目前很重要的工作方式之一，它不是一种具体的方法或策略，是贯穿始终的一种解决问题的思路。这方面的工作我们在《体系化应急》一文中介绍过，不再赘述。

三、服务者+协作者

前文提到过，安全团队对内本质上是一个服务团队。其实服务心态说起来简单，做起来还是挺难的。因为甲方安全团队很对时间都在跟服务商或者厂商这类乙方打交道，一不小心就被捧的飘飘然，就算没那么严重也可能习惯于俯视的视角。所以，我们需要做的不仅仅是认清对内服务者的身份，还要调整好心态。

一旦我们回到服务者的心态，很多事情其实就没有那么复杂了。我们提供的服务需要被服务者的认可。

但服务者不代表万事顺从，我们仅仅少稍稍放下身段达成我们的目标而已。最终实现目标是要靠协作的。尤其是安全部门，很少有什么工作可以部门内独立完成的。比如：

安全策略，需要运维部门配合下发吧，就算边界安全设备也归安全管，但主机IPtable难道也要收回权限？

漏洞处理就更不用说了，运维和开发不修，你有啥办法？就算能明确责任主体，一旦发生安全事件，最好的结局就是不受罚，总不能还因为这事给你发奖金吧。

安全数据分析也一样，分析到的任何事件，除非边界策略一条能搞定（前提还得是边界安全设备归安全管），其他的都得运维配合。

风控就更不用多说了吧，需要协调的都不仅仅是技术部门了。

从笔者的经验上看，没有那个技术部门像安全部门一样面对如此大量的协作工作，所以以服务者的心态和协作者的身份在公司内部沟通工作是非常重要的。