作为个体如何做安全运营

0x00 写在前面

年底了给自己放个假,跑到了北极圈来吹冷空气,同时希望自己运气能够好一点看到高端版“光污染”,虽然人放假了,但是对于安全的思考不能停下。

不知道因为啥去年安全圈最火的词除了ATT&CK(是不是ATT & Calvin Klein也说不定,不知道一个运营商和一个稍微高端一点的品牌能碰出什么东西)之外,无外乎安全运营了,火到什么程度,2019年各个安全大会上都单独为其开设了分论坛或者专门的议题,虽然个人认为安全服务商(在这里尽量不提甲乙方说法,姑且称之为安全需求方和安全服务提供商吧,这样听起来高大上一点)谈论安全运营有点“开拓市场”的意思,但是种种迹象表明安全运营确实已经到了一个不得不提的时候,原因主要是因为现在的安全行业在政府监管机构、安全服务提供商、以及各种法律法规制度的要求下,建设期实际上大家都差不多了,无外乎就是中小型企业买买买,大型企业自己研究,超大型企业做个标杆出来,安全市场需要新的增长点,对于安全服务提供商来说,盒子设备什么的各家都有,服务就变成了一个营收的重点,好的安全服务提供商会从安全服务侧汲取足够丰富的case转换成产品或者某一功能,but目前的国情是:趁手的装备没有,只能依靠人,而且首要目的是以满足国家监管要求为主,所以只要满足了监管的需求,很多客户可能会出于成本的考虑见好就收,但是安全服务提供商不能这么认为啊,客户见好就收了我们去哪儿挣钱啊?所以安全服务提供商可能会结合国外的一些安全风向标“筛选”出客户的“需求”,然后着重发力,换取新的增长点。而对于客户而言,安全建设的已经差不多了,如果写第二年工作计划的时候还写需要建设然后汇报到TC或者是技术老大们的大会的时候,最高的技术head就会问了,按照你的描述都建设的差不多了,咋还建设呢?如果要是建设完了,那么实际上安全基本上也就做完了(毕竟国家层面上满足互联网接入对应的安全合规标准即可对外提供互联网服务),安全团队是不是就能“咔嚓”掉了?既能够节省预算还能够缩减HC,两全其美。于是这个时候各个公司的安全负责人开始拼了命的搜集新的业务点来证明安全对于业务的价值,在这一环节中,基础安全往往会作为一个兜底一般的存在来证明我们的安全做的还可以,至于其他部门嘛,大家都晓得。这个时候一个需要谈运营,另一个需要谈运营,既然这样,那么我们就一块讲运营吧。以上均为本人的猜测,如有雷同不胜感激。

今天在这里不想谈宏观上安全运营如何去做,谈论那个的话我的boss会更专业一点,我的level不够,所以只能谈论作为一个普普通通的安全需求端的安全运营工程师,如何做好本职工作。以下内容可能是本人的主观认为,不一定正确。

0x01 安全服务和安全运营

回到正题,如果把这个subtitle换成人话,就变成了一个很多初入行的安全从业者都会问的问题:甲方安全工程师和乙方安全工程师区别是什么?在这里通过个人的短暂从业经历,甲方安全运营工程师和乙方安全服务工程师实际上有以下的两个区别:

考核方式的不同:甲方安全运营工程师考核往往是产出为主, 所谓产出,不同岗位和不同岗位的产出实际上是不尽相同的,具体我们后面会详细阐述;而乙方工程师,考核的一个核心指标是客户满意度,客户满意了一切都好说,转换成硬性指标就是客户满意率(正向指标)和客诉率(负面指标),但是由于绝大多数乙方安全服务工程师实际上都是出事儿才会想到,所以这种使用长期考核的指标往往不太适用。

价值实现的不同:无论是对于安全服务提供商还是安全需求方而言,工程师所感的所有事情凑是价值变现(虽然这话不是我说的但是我非常认同),因为正确的价值是雇佣关系的前置条件,换句话说就是,雇主所需要的价值你不能实现,你们之间就不会产生雇佣关系。甲方的安全运营工程师的价值更多的是用来解决企业业务在运行期间所有的安全问题,而乙方安全服务工程师所变现的路子就多了,比如说为企业拓宽知名度,为客户解决某一类问题,打通客户的渠道等,具体的需求和具体的岗位有关。

谈到这里有时候就会不由自主的想起几个段子,诸如甲方都不懂安全不懂技术,乙方都就是来干活的,都是人肉扫描器等等,以上确实不乏很多键盘侠的评论,但是我们作为行内人,首先先说是不是在说对不对。

技术对于安全这个行业来说是不是必须得足够牛逼才能做好:从周围的人以及自己实际的工作情况来看,不一定是技术牛逼就能做好安全,虽然会有人反驳你看人家xxxx多厉害能挖出那么六的利用链干穿VMWare虚拟化,技术不行的人能挖出那么六的洞么。但是站在甲方安全的角度上考虑,结果就是:忽略,我们穷用不起vmware,利用链是VMWare的私有协议,我们用的开源的所以不影响。这个时候我们拆解成上面提到的两个点,安全服务提供商可能真的觉得这个利用链很牛逼,当然也的确很牛逼,但是站在甲方安全运营的角度上看,我们连资产都没有,何谈牛逼不牛逼,就算牛逼,实际上也跟我们没有关系,最多朋友圈点个赞转发一下就完了。在甲方看来,绝大多数工作可能就是去修复一些很低级的漏洞,而且是重复性的修复,修复方案也确实是xx漏洞通知里面的升级或禁用组件,但是实际情况是,不是所有的东西都会让你轻松地去升级和停用。对应到上面所说的考核方式而言,该漏洞趋势收敛并且新增的风险可控才是比较有成就感的事儿,至于挖出了一条利用链,可能或许没准八成真的有价值吧。

安全服务就是人肉扫描器:不是,首先第一,安全服务的价值建立在中小型企业在权衡资金预算和服务SLA之后认为采购安全服务是比较省钱且效果还不错的方法。所以安全服务本质上是去解决企业实际的安全问题去的,是有价值的,而价值恰恰就是能够帮助企业解决实际的安全问题,所以单单说“人肉扫描器”有点不公正不客观。

0x02 如何做一个好的安全运营工程师

虽然以下说的这些我可能现在自己都还没有做好,但是可以给大家一个参考,可能不一定对。

A. 对标意识:对标顾名思义就是找到标杆然后学习他们怎么做的,其中的难点在于如何寻找正确的标杆和拆解其实现方式。举个例子:在思考如何去做开源组件漏洞管理这件事的时候,我们首先干的事情不应该是一拍脑袋立刻说出一套能跑通的方案(方案是可行但是不一定是高效的,虽然这种问题我现在还会犯),而是要去了解同行们是怎么做的,同体量下公司是如何去做的,AT是如何去做的,Google、Amazon、Microsoft这些是怎么去做的。对标思维可以解决以下的几个问题:

(1)我们目前这一块的安全能力在同档次公司里面大致是一个什么样的水平

(2)我们离国内同行的水平大概有多远,他们是如何做的

(3)我们离世界一流的同行差别有多远,他们做的那些我们可以复用

第一个问题有助于正确了解我们的现状和我们期望要达成的目标,第二、三个问题可以帮助我们正确的了解到业界的工程最佳实践范本和运营模式,能够把握未来一段时间的建设方向,随着企业体量的增长会慢慢用得到的,但是也不要照本宣科,比如说Google为了安全定制了OS和芯片,这个学习成本太高了,而且用不到这么高安全级别的,可以先备着。

B. OKR思维:我们既然已经知道了我们需要做什么,这个时候我们需要根据上面调研的结果将一个大目标拆解成为若干个可以量化的小目标。讲真这一部分真的是有点困难,很大一部分原因是因为目前很多安全运营工程师都是从安全服务工程师转化而来,case by case的工作模式使其没有了对长远考核的了解,说白了就是之前一个客户的问题解决了就完了,下一个继续,在下一个继续,但是现在你要为解决负责了,不可能是一个case就完事儿了,长期的运营需要有对比的数据才能评价你做的好坏。在拆解目标的时候往往会收到来自老大的各种challenge,比如说为什么要用这个指标去衡量你做的好坏,如果这个指标做的很差说明了什么问题,别人来做这个工作指标是不是会和你的一样,在这里又回到了前面的问题,价值实现。在boss看来,他可能不懂这方面的具体实现,当然他也没有必要去懂,因为你是这一块的专家,他只需要做的是在符合公司安全规划的前提下来判断你说的指标是否真的能证明你工作的好坏,这个套路不仅能在日常工作规划,晋升答辩的时候也会遇到,比如说晋升答辩的组长专长是做数据库,而你的日常工作是做安全运营,这个时候如果他因为不了解你的技术而不认可你说的东西,岂不是很冤?(这一块是一个很难熬的过程)

C. 数据驱动:

被老大喷的最多的一句就是为啥没有数据?受之前case by case的工作影响,数据积累这一部分往往是最难受的,难受点不在于数据放到哪儿,而是在于关键指标的选取和趋势输出。选对指标这件事儿其实说容易也容易说难也挺难的,但是积累量化这件事儿,说起容易做起来更难,并不是把数据做简单的可视化罗列就完事儿了。必须要能够解释每一次波动,大的趋势的背后你都做了那些工作才会产生这类波动。这样才能在老大认可你罗列的指标的情况下来判断你工作做的好不好。

D. Think Ahead:

其实这一部分相当于猜老板的心思,举个例子,比如说boss让你去收集pypi源下面所有的恶意包情报来做入侵检测。虽然只是用鼠标在平台上点几下或者是写个一次性脚本就能解决的事儿,但是boss的本意其实并不是这样。我们难道只有pypi源?其他的源就不会有问题?我们一共会有多少个源?这些源的上游数据是怎么来的?上游数据是否有安全审核机制?审核机制是否能够发现恶意包投毒的问题?等等等等。实际上经过一系列的场景假设和反复设问之后,我们最后会发现boss实际上是想让你解决供应链投毒的一类问题,而非简单地一次性跑个脚本。就算这些做完了,增量如何控制?如何运营?通过哪些指标可以判断威胁收敛?通过反复的设问和FAQ会发现事情的本质并没有想象当中的那么简单,但是我们也能够逐渐发现新的风险点。

E. 产品心态:

国内的安全公司有一个非常大的特点:不搭配安全服务几乎没人会用。一方面是因为国内确实缺乏很多专业的安全产品经理解决交互和风险可视化问题(“地图炮”并不能正确指示风险),另一方面就不好直接说出来了,明眼人应该能看懂,毕竟老外的产品在易用性和功能性上都领先国内一大截,而且老外的安全服务实际上不是直接卖人,而是SOC+产品+分析师的方式落地的。但是会到甲方视角,在甲方做安全最忌讳的事情实际上就是能力断层,也就是所谓的你离职之后公司在这一领域都黄了。所以能力落地的最好方式就是产品和运营,产品的易用性直接决定了运营难度的高低,安全产品的质量实际上才是衡量安全能力的一个有效指标。

0x03 最后说的

文章内容不针对任何人、任何公司,仅供娱乐,想要参考也可以但是要慎重,比如在安全服务提供商做安全服务区提产品可能会有一些人认为你疯了,而且有可能是direct leader,在客户面前承认产品有缺陷并承诺会修复这个问题可能会被人打小报告给大boss说你在说产品的坏话。

实际上目前国内安全行业跟国足情况差不了太多,国足最大的问题不是教练不够大牌,最大的问题之一是青训接不上啊,年轻人没人会踢球或者不愿意去踢球。信息安全专业的应届生受一些安全圈的大黑客的影响毅然决然的从事漏洞挖掘、安全研究领域,而自我认知较强的一些人可能认为自己成不了大佬便早早转行或者是投身于安全服务行业。安全运营呢?喂各位同学,请给安全运营一点机会好不好啊,别这么看不起安全运营好不好。国内安全行业的现状我个人用一句话总结吧(仅代表个人观点):大学生被一群挖漏洞和渗透的大佬的猛如虎的操作弄得十分羡慕,便毅然决然投身安全行业,结果发现自己离大佬的差距不是后天可以跟上的,遂进入安全服务行业,干了几年后发现待遇和之前看到的不一样于是想转战甲方,结果面试的时候懵逼了,数据量化?OKR?对标?不好意思都没听过。而甲方呢?我们也想招人啊。。


我可能是在芬兰喝到了假酒,该文章说不准什么时候就删了。也许呢?


说到招人,我们现在正在诚招各位大佬,只要是能力强的都可以试试,不管是蓝军还是红军。

发布于 2020-01-02