预警业务体系建设实践

本文共计5840字，预计阅读时间20分钟。

1起因

2017年安全圈发生了两件大事-- S2-045和Wannacry。相信很多经历过的朋友们都记忆犹新，不分昼夜地做应急响应和安全加固，当时绿盟科技安全服务团队的小伙伴们也是加班加点帮客户解决问题。在此之前，我们的工程人员缺乏处理这种大规模突发性安全事件的经验，面对这两起突发事件时，我们的应对方式是领导亲自带队，协同产品和工程人员连续通宵出解决方案，我相信很多朋友也和我们一样经历过这样的不眠之夜。

如果下次再遇到类似的事件怎么办？再一次动员产品和工程人员熬夜加班？这种体力透支型的支撑方式毕竟不能是常态，因此绿盟科技专业安全服务中心牵头成立专门的小组，目的是达到可以低投入、高效率帮助一线解决突发性安全事件的目标，能真正的帮助客户解决突发威胁而带来的脆弱性问题。安全预警业务就在这样的背景下迈出了第一步，然后一点点完善扩充，最后打通公司内部多个部门和业务流程，成为了公司内部运营的一部分。

图 1.1 安全预警服务方案

2预警文档

2.1 文档模板

初期我们也没有一个明确的规划，当时的出发点只是想帮助一线快速解决问题，最简单的实现方式就是形成标准化的文档并通过内部渠道下发，帮助前场工程师在客户现场做安全加固。所以第一步先要明确文档的内容，制定标准模板。为此我们也翻阅了大量已经公开的预警文章，发现大部分主题是和新漏洞相关的，事件型的预警并不多，因此初期我们的重点也是放到了漏洞预警上。

但是那时的大部分预警文章只能算是漏洞通知，对工程师的价值仅仅是让他们知道又出新漏洞了，并没有指导后续该怎么做 ，很多文章的防护建议也只是升级两个字。仅仅是这样的内容是无法达到我们的目标的，通过与一线的同事们沟通，针对客户对于突发的漏洞，我们总结成以下三点需求：

1. 这个漏洞有什么危害？

2. 我受不受影响？

3. 如果受影响我该怎么办？

针对客户的这三个痛点，对文章的标准模板进行了梳理，有兴趣的朋友可以回顾一下我们发过的历史文章，基本都是按照下面的文章结构编写的：

• 漏洞概述：简述漏洞的危害；
• 影响范围：影响哪些产品和版本；
• 漏洞检测：如何判断我有该漏洞；
• 漏洞防护：如何防护该漏洞。

2.2 文档质量

在预警文档的质量保证方面，我们采用了“慢审+快审+多次交叉校对+惩罚措施”的方法。

初期阶段写了几次预警文档，深刻地体会到想要输出一份高质量的文档绝非易事。大家可以测试一下，找一篇自己曾经写过的文档再仔细阅读，特别是那种没有二次校稿的文档，一定会发现错别字、语句不通顺、逻辑混乱等问题。

为了保证文章的质量，我们采用了先慢审后快审的方法。

所谓慢审就是一字一句的慢速阅读，目标是挑出所有语病，过滤掉所有低级的文字错误，有点像语文考试中的找病句，一篇没有语病的文章是最低标准。

快审则是通过速读的方式，检查文章是否有难以理解的句子，考虑到大部分读者平时看文章都是快速浏览，为了适应用户的速读习惯，我们制定了审核标准：以300字/分钟的阅读速度不会有任何理解障碍。为了达到这个标准，针对快审我们在写文章时采用了以下方法：

• 拒绝长句：如果文章中存在长句，就拆分为多个短句进行表达；
• 拒绝直译：由于每个工程师的英文水平参差不齐，对于英文参考资料直译出来的内容通常是惨不忍睹的，为了避免这种情况，可用意译来代替直译。

一个人的思维总是有局限性的，文档能让自己满意是不行的，还要让全组的同学都满意才可以。初稿完成后发给全组人员共同审核，所有人都觉得没有问题后，才能下发。从初稿到最终定稿，平均每篇文章我们都至少修改过5个版本。

如果文章发布后发现存在严重问题导致了撤回，必须要有物质上的惩罚，下至员工上至总监对全组进行罚钱，因为交叉校稿的过程中大家都没有发现问题，每个人都有责任，扣罚的金额则充公到部门费用中。经过几次实践发现这种方式非常有效，为了不让自己的错误影响到其他人，每个人都会仔细审核，这也是把个人绩效与团队绩效挂钩的一种方式。

其实平时工作中经常会有写总结、写汇报这种文案类型的工作，对个人来说会写文档也是非常重要的一项软技能，平时在打造自己硬实力的同时，也不要忽视了软实力的提升。

3对内能力建设

3.1 调研

为了避免闭门造车，多看看别人是如何做的也能给自己很多思路。经过大量的调研，我们筛选出十几家有预警业务的厂商，综合各家的优势，分析总结出可以发力的工作点，最后以总结报告和竟商沙盘的方式输出，以便寻找新的工作方向，特别是在业务进入稳定运营期后，可以给自己带来一些破局的思路。下图为竟商沙盘的部分截图，仅供参考：

图 3.1 竟商沙盘

调研是一项持续性的工作，如果发展遇到了瓶颈，就可以考虑做一波调研，看看友商在这段时间有什么变化，当自己不知道该做什么的时候，就多看看别人在做什么。

3.2 情报监控

消息来源对于预警推送是重中之重，为了保证消息的可靠度，我们梳理的监控源都是官方的漏洞发布渠道，比如微软、Oracle这些厂商都是有自己专门发布安全通告的网址。虽然现在的监控来源已经不限于官方了，但是我们的主要参考的内容还是以官方首发的权威通告为准。

初期阶段由于资源有限，我们采取的方法就是最原始的人肉监控，资源充足后才开始做情报监控的工具化，目前监控系统主要推送以下四个来源的内容：

• 官方的漏洞发布：消息可靠且权威，参考价值最高；
• 各类新闻网站：补充事件型情报，补充只有漏洞情报的不足；
• PoC发布平台：查看PoC披露的情况，方便判断漏洞的威胁程度；
• 漏洞发布平台：关注度高的安全漏洞被公开后，保证绿盟不会缺席。

推送方式也有两种，一是通过邮件推送，二是通过微信机器人。邮件方便查阅历史消息和给客户推送；微信机器人则方便实时获取消息保证时效性，两种方式并行可以优势互补。

图 3.2 微信机器人推送

3.3 可量化的评价模型

监测到了公开的情报，接下来该怎么处理，要不要启动预警流程，全靠拍脑袋决策是缺乏说服力的。先举个实际遇到的反例：

针对突发的高危漏洞采用红橙黄蓝风险等级进行划分：

表 3.1 红橙黄蓝风险等级

上述评价标准就属于不可量化的标准，经常会出现的场景是你说是蓝色，他说是黄色，这种标准没有准确的衡量尺度，每个人对广泛、部分、苛刻这类词汇的理解也是不同的，一旦出现评级分歧，最后只能指定大领导去决策。

为了解决这个问题，在是否启动预警的判断标准上可采用一些可以衡量的指标，比如是否有公开的PoC、CVSS评分、互联网开放情况等，这些指标均可以量化，针对漏洞的类型也可以分配不同的权重，比如RCE类型的漏洞权重设置高一些，信息泄露类型的则可以设置低一些，最后依照选择的不同维度计算出一个综合评分，高于阈值就启动预警，如果在实际运行过程中发现有不合理的地方，可以及时调整分数计算规则。经过实践后，当评判标准可以客观反映漏洞的基本情况后，最终将其固化到SOP中，不能轻易改变。

3.4 漏洞分析

根据漏洞评价模型评判需要启动预警的漏洞，一定要对漏洞进行分析，个人的技术领域不能覆盖所有类型的漏洞，在研究资源有限的情况下可以拉通具有专项能力的团队一起把事情做起来。绿盟科技内部组建了四大战队和五大实验室，战队经常代表公司参加各类攻防演练、CTF等比赛，实践能力强，联动战队可以实现快速搭建环境和漏洞复现；实验室具有过硬的技术研究实力，可以对漏洞进行深层的原理分析，联动实验室可以结合漏洞的原理分析，研究检测和防护方案。

在漏洞分析过程中，预警可以为战队和实验室提供情报输入，战队产出的环境可丰富漏洞利用实验局，利用方式可丰富武器库，实验室的研究成果可丰富漏洞研究知识库，预警则利用战队和实验室的产出成果快速做检测、防护方案的验证，一举多得。

3.5 产品联动

为客户提供防护方案是预警的初衷，当高危漏洞公开后，及时为产品团队提供输入可辅助产品提高检测和防护能力，在预警过程中产出的漏洞利用方式可以为防护产品团队提供检测防护思路，漏洞利用环境可以为产品提供规则验证。

产品闭环率是我们的考核指标之一，通过该指标可以驱策我们不断推进产品的升级，有利于持续提升产品的检测防护能力，从而提高产品在客户群中的口碑。

3.6 事件型预警

平时预警发布的主题大部分是漏洞相关的，事件型预警虽然不多，但也是我们关注的重点，比如勒索软件爆发、大规模网络攻击爆发等。绿盟科技应急响应团队拥有扎实的一线经验，可为事件型预警提供丰富的案例。

其实应急和预警是分不开的，平时与应急响应部门做好拉通，对于处理各自的工作都会有很大帮助。

3.7 宣传推广

3.7.1 公众号

说到宣传推广，给用户最直观的感知就是绿盟科技安全情报公众号，公众号的内容是以预警为主，偶尔发一些节日祝福、抽奖活动等用户运营性质的内容，从内容上还是专注于安全情报，尽量减少给用户推送无用的消息。早期的文章都是在公司内部推送，并没有对外，公众号开通也只有一年多，不过经过这段时间的运营，公众号已经成为了一个连接公司和用户的接口，通过公众号也给公司带来了一些商务和业务合作的机会。

除了公众号本身，对我们来说最有价值的是公众号后台的数据，公众号是最贴近用户的，相关的数据能比较真实的反映用户的习惯和需求，通过文章阅读量、关注人数和后台留言可以帮助我们分析哪些类型的热点用户最关注。现在我们每周做一次运营数据分析，并在总监例会上汇报。

当然公众号的相关的数据只是一部分，日常的各项工作都可以尝试进行数据化展示，比如情报监控、PoC监控、SLA完成率、产品闭环率等，最终目标是通过数据化的分析提高日常运营效率，并挖掘用户的真正需求。

3.7.2 营销线合作

对外推广，公司的营销线最为专业，直接利用现成的渠道可以快速扩大推送范围，目前对外发送包括但不限于以下渠道：

• 绿盟科技官方微信
• 绿盟科技官方微博
• 绿盟科技博
• 绿盟科技国际版官网
• ……

除了推广渠道，营销线还有专业的UI设计团队，可以帮助我们做好美化的工作，比如公开报告的编辑、宣传彩页设计、字体、排版等方面。同时我们的文章也可以为营销线提供输入，有利于进行品牌推广，双方相辅相成，一直保持着良好的合作关系。

3.7.3 符合法律法规

如果文章是对外公开的，还需要注意版权问题和措辞，这部分特别要引起重视，毕竟现在市场竞争激烈，一旦引起官司就是大事。

图片是有版权的，如果需要引用外部的图片，是需要获得授权的。对此我们的解决方案也很简单，直接氪金购买图片的使用权。

部分字体也需要注意版权问题，比如微软雅黑只允许在Windows上使用，放到别的地方用就会涉及到法律风险，针对字体的问题我们从以下2个方面进行解决：

• 技术方面，通过全局CSS进行字体过滤；
• 管理方面：制定标准模板，对编辑人员进行必要的培训。

除了版权问题，文章在内容上要特别注意不要违反广告法，建议做新媒体的小伙伴们都仔细学习一下广告法，避免踩坑。

3.8 赋能

为了将产出的价值最大化，将漏洞的处置方式形成经验，上传到知识库供所有工程师查阅。同时联动培训部门组织全公司范围内的在线课程分享，快速将漏洞复现、漏洞分析、漏洞防护的经验传递到一线，做好知识沉淀，实现最大化的赋能。

3.9 跨部门协作

为了避免重复造轮子，公司已经拥有的能力就没必要再去自己建设了，专业的事就交给专业的团队做，充分利用现有的资源，可以使各部门的产出价值最大化。

通过上文描述的各项工作可看出我们还是做了不少部门拉通的事情，根据实际遇到的各种场景总结了以下2点经验，在做跨部门沟通时可提高合作的成功率：

• 保证双方的目标一致，明确双方都是为了更好的业绩而努力，设置互锁绩效，共同对结果负责；
• 忌讳光吃不吐，别人在为你提供输出的同时，你也要为别人提供输入。

总之就是别人帮你完成指标的同时，你也要帮别人完成指标，互惠互利才能建立长期的合作关系。

在实际运营中，预警已经渗透到公司的多种业务流程中，比如公司级应急响应、安全运营等，同时我们也联动其他部门一同建立预警体系。预警一定程度上成为了打通部门墙的润滑剂，跨部门合作也成为了预警日常工作中的重要组成部分。

图 3.3 跨部门协作

3.10 团队设置

确定了具体的业务方向，就需要建设能推动业务的梯队，针对上述各种业务内容，组建预警团队时，将成员分为以下职能方向：

• 情报分析师：审核各种渠道收集到的情报，对情报进行定级和研判，提供各种技术方面的支撑，特别是针对重大威胁提供检测和防护方案；
• 工具开发人员：情报监控工具化、内部业务自动化，能让机器做的事情就尽量把人力解放，针对重大威胁提供一键检测和修复工具；
• 运营：负责跨部门协调，各种数据化分析和公众号运营；
• 产品经理：竟商分析，需求分析，探索产品化的模式。

这里的职能设置仅仅是适合我们自己的情况，不一定适用于各个场景，团队组建最终的目标还是要能推动业务，只要能达成目标的设置都是合理的。另外团队建设并不是一成不变的，需要不断适应新变化，我们的团队最初并是不是现在的样子，也是在实践中不断明确方向并看清自己的定位。

一句话总结我们的团队定位和目标：以技术为基础，通过运营打通研究、产品、营销、应急响应、培训等团队，当突发漏洞发生时快速向一线赋能，同时探索服务产品化的道路，最终形成对公司和客户的漏洞生命周期管理能力。

这一节最后补充一张整体运营流程图：

图 3.4 预警业务运营流程

4服务产品化

4.1 定制化项目

预警如何为客户产生价值一直是我们思考的问题，对于一些有预警需求的客户，我们承接了定制预警项目，通过实际的客户需求来寻找产品化的道路。

4.2 产品试水

有了一些实际客户的需求，我们尝试进行了产品设计，一期阶段只是将产出的文档公开化，依托绿盟云开发了文章展示平台，同时提供用户订阅功能，访问方式如下：

https://cloud.nsfocus.com/#/secwarning/secwarning_news

图 4.1 预警展示平台

一期上线后，我们积极与各个区域的T级销售进行沟通，了解到基于用户资产的定制预警是当前用户的通用需求，在信息爆炸的时代，只关注与自己相关的信息会大大提高效率。目前我们定位的预警服务产品的方向是结合资产管理、情报能力、威胁发现、安全加固，最终在客户侧将漏洞生命周期管理落地。

目前二期的原型设计已经完成，进入了开发阶段，对于服务产品我们有标准的管理流程，每双周进行进度review，以保证产品能按照进度保质保量交付。

图 4.2 服务产品管理流程

服务产品是我们从对内提供能力向对外提供能力转型的重要抓手，能在一线落地，帮助客户解决安全问题的宗旨，从始至终贯穿在所有预警工作中。