高质量解读《互联网企业安全高级指南》三部曲——实践篇

前言：
高效读书，一张逻辑图读懂、读薄书中重点。
注：下面文字只是对逻辑思维图的”翻译“，节省时间，只看图即可。

实践篇逻辑思维图   

1.    业务安全与风控
1.1.    说明
1.1.1.    业务安全的起源是由于黑产的存在
1.1.2.    企业间的恶性竞争，黄赌毒等合规性要求也成为业务安全的驱动力
1.1.3.    本章将描述互联网行业各种典型业务的主要风险和控制方法
1.2.    对抗原则
1.2.1.    相对的风控而非绝对的防黑
拖库只要发生一次就非常严重，但是业务安全，即使漏掉了一些，但解决了大部分的问题，那就算及格了
1.2.2.    增加黑产的成本而非阻断他们的行为
黑产，羊毛党的驱动力就是为了盈利，如果他们投入的成本超过损益点，那就没必要再去攻击你
1.2.3.    永远的情报
知己知彼，百战不殆。了解黑产怎么干活事半功倍，深入敌后比躲在办公室更聪明，并非只有爬虫抓来的大数据才叫情报，蹲在对方的QQ群里也能搞到情报
1.2.4.    方法比技术更重要
技术的对抗是无止尽的，并且会不断地消耗内部的研发资源和IDC资源，改变战场规则可能起到一招退敌的效果
1.2.5.    数据比算法更重要
大数据的典型特征，算法可以不高大上，但是没有数据或数据太少，风控这件事也许你玩不起来
1.2.6.    勤能补拙
也许你没有大数据，但是不断地改变业务逻辑，不断地升级会使对手疲于奔命
自PS3/PSV时代起，sony不再封堵破解，而是以更短的迭代周期，更高的版本发布频率升级操作系统，新的游戏必须运行于高版本系统之上，使破解者疲惫不堪，盗版用户都懒得再破解。谁主导节奏，另外一方就疲惫
1.2.7.    忽略性能、用户体验和成本的风控没有意义
风控本身的意义在于保障正常用户和平台自身，如果正常用户体验受损或大面积误杀，则风控起了反效果
1.2.8.    纵深防御
纵深、多维度、降维防御在风控场景仍然适用，使用漏斗模型，由机器规则处理最原始的数据，逐步筛选过滤，由人工审核做最后一道防线
1.2.9.    杀鸡给猴看
只要条件允许，用法律武器端掉主力，用风控手段扫尾
1.2.10.    人民的战争
教育正常的用户安全意识，动用一切资源和手段反剿黑产，以资鼓励全民情报
1.2.11.    社工库
敌人有的，我也要有
1.3.    账号安全
1.3.1.    说明
账号安全是所有强账号体系应用的基础，强账号体系，如电商、网游、第三方支付、 社交网络、即时通信等，是需要登录后产生数据和交互的应用，而搜索、导航、杀毒客户端不需要登录也能用，则属于弱账号体系应用
1.3.2.    注册
对于羊毛党而言，平时需要“养号”，批量注册一批号放着不用，等到促销之类的活动开始了才用。垃圾注册、虚假小号是垃圾抢购、欺诈钓鱼的源头，账号安全要从源头收紧
对抗垃圾注册一般的手段包括
图片验证码
邮件验证码
短信验证码
语音验证码
电话语音验证码
1.3.3.    登录
登录环节的问题包括：撞库、暴力破解、盗号登录、非常用设备登录、黑产小号和僵尸号登录等
图15-1账号风控架构示意图

使用风控系统对比用户画像检测登录地域来源、IP属性、可信设备、登录频率、代理使用习惯等从而推送不同复杂等级的验证码或开启多因素认证或根据离线数据，即一段时间内的请求（行为）异常，以及其他业务风控子系统判断的行为异常，再调用风控的接口推送二次认证要求做人机识别
对于大规模的扫号、暴力破解，除了依赖于机器规则外，还应准备手工策略和应急预案
风控服务依赖于很多数据，例如设备指纹、IP信誉库、黑产手机号等，获取这些数据是一个比较庞大的工程，对于大型企业而言相对容易获取，中小企业在不借助第三方数据 合作的情况下，自己去抓取数据成本会非常高
1.3.4.    密保/密码找回
平台应提供多种密码保护手段，并在用户界面显眼处提示或安全教育。还应确保平台的密码找回/密码重置等功能不存在逻辑漏洞可以被绕过，或发生过度信息披露
在认证设备之间提供异地登录提醒、异常登录提醒、破解账号提醒。对密码找回业务进行人机识别，防止批量找回、密码重置等接口的机器行为
1.3.5.    多因素认证
要的操作必须使用2FA （双因素认证）或MFA （多因素认证），例如密码找回、密码
重置、安装证书等
1.3.6.    多设备登录
多设备登录时，应保证同平台不能“串号”——同一账号可以在PC端和APP端同时登录，但不能在两个PC端登录同一账号，或不同的手持设备上登录同一账号
多设备同时登录时应支持交叉认证，例如PC端的可疑登录自动发起2FA请求到手机端，经由手机端确认后才能从PC端登录
1.3.7.    账号共享体系
绝大多数互联网平台都采用SSO的账号共享体系，在开放平台业务上使用Oauth、 Openid等联合认证协议
Oauth等协议坑比较多，非常容易岀问题
内部在对账户数据的使用上也容易不遵守规范，过度共享和滥用账户数据，这些都需要在相关的应用安全开发标准中约束
1.4.    电商类
1.4.1.    恶意下单
下商品但不付款，旨在侵占库存
一般的对策是高峰时段下单使 用验证码，下单后一段时间不付款订单自动失效，限制下单频率，有风控数据源可以对恶意账户进行标记，冻结下单
1.4.2.    黄牛抢票
黄牛一般事前批量注册小号，抢购前准备好抢单机器人程序
对于恶意养号，风控系统一般会根据小号、僵尸号平时的行为与正常账户的区别标注、登录的途径、登录地域、登录设备指纹、收货地址来分类标记，抢购开始前就能在 账号层面冻结掉
在活动开启前如果抢单程序是针对既有页面逻辑的，可以临时更换业务逻辑使抢单程序失效。在抢购过程会使用验证码做人机识别
1.4.3.    刷优惠劵和奖励
首先要在账号层面根据大数据标记账户恶意灰度，其次优惠券跟账号绑定，无法流通和交易。跟网游中的经济体系数值类似，建立阶梯模型，给优质账户高额回馈，给低信誉 账户小额优惠
1.4.4.    反价格爬虫
价格爬虫主要是竞争对手比价
1.4.5.    反欺诈
根据账户注册信息的真实性、登录设备的真实性、绑卡异常、账号异常，结合自有或第三方历史征信数据综合判断欺诈的可能性
1.4.6.    信息泄露
信息泄露有几大来源，撞库、用户信息过度展现和披露、开放平台API滥用、供应链上下游信息泄露，“内鬼”兜售内部数据
1.4.7.    交易风控
账户安全
账号安全中部分
客户端安全
反钓鱼
反木马
认证机制
证书PKI
令牌
多因素认证
风险评估
账户历史行为
账户历史征信数据
交易和账户异常
漏斗模型筛选，机器规则+人工审核
交易风控在传统安全（包括认证、账户、KMS、PK1、客户端完整性等）基础上还需要 由3大组成部分
用户数据、交易数据
来自传统金融行业的风险管理
基于大数据的风控平台
交易风控团队需要两拨人
一拨来自传统金融行业
一拨来自互联网
1.5.    广告类
1.5.1.    因为点击欺诈非常严重，数据作假水分很高，所以目前都是按广告效果、实际订单效果收费，以前的CPM、CPC模式都不行，基本都是CPA为主，但是即便是CPA，广告联 盟有时候还是跟黑产玩一样的
1.6.    媒体类
1.6.1.    媒体类的问题主要是黄赌毒、舆情安全：基础的手段包括：敏感字过滤、设置举报功能、加上人工审核
1.6.2.    高级的手段本质上就是搜索引擎的技术：抓取样本，用机器学习的方法做特征识别
1.7.    网游类
1.7.1.    游戏行业除了盗号盗充外，最主要的问题就是反外挂、私服、打金工作室。总结一下有几个层面的保护手段
客户端
对于flash等瘦客户端最主要的技术是代码混淆，用于对抗反编译后逆向游戏的逻辑和网络协议
对于大型客户端游戏，对抗的方式主要是加密加壳，以及各种二进制反调试手段
网络封包
对抗重放型攻击，具体实现方式可以参考大多数rest API的安全设计，如何防止packet replay攻击，原理基本类似
服务端校验
把大部分逻辑验证放在服务端，同时校验时钟同步等
人机识别
通过定期弹出验证码或回答问题实现前端的人机识别，后端根据地图移动轨迹，鼠标轨迹，物品使用速度等做人机识别
产品内容设计
物品与账号绑定
运营数据监控
通过运营数据，如虚拟装备产出数量，个人成长速度等监控发现异常行为
私服
主要的根源在于供应链管理，研发到运营的交付过程，研发的信息安全管理，运营平台的防黑建设，研发团队集体跳槽的知识产权保护，主创人员敏感异动预警，竞业协议，保密协议等
1.7.2.    游戏是将互联网用户流量转化为金钱变现能力最强的业务，故而黑产的分工也比较成熟，所以对抗上也需要各种情报，姑且不去加上威胁情报的大帽子了，这是一个需要发动广大群众进行持久对抗的大课题
1.8.    云计算
1.8.1.    这里站在云计算平台厂商的角度来看，而不是站在租户的立场上看的。主要问题是 CaaS ( Crime as a service)
1.8.2.    对于云平台的监管
一方面手不能伸得太长，触及用户隐私数据
一方面又要做治理。对于租户使用云平台开展黄赌毒业务的，可以参考媒体类的解决方案
1.8.3.    如何为租户的风控提供便利是一个长期而有挑战的课题
2.    大规模纵深防御体系设计与实现
2.1.    说明
2.1.1.    技术篇中对大型互联网生产网络的安全解决方案分类进行了描述，但对于具体公司的安全建设如何上手可能很多人还是缺乏对整体架构和切入点的认知
2.1.2.    本章通过具体的例子展示如何进行整体化安全建设，以及从哪里入手由点带面的布局，并最终实现体系化建设需要的大部分任务
2.2.    设计方案的考虑
2.2.1.    检测和防护的角色
很多人提到一个问题，“既然是纵深防御，好像入侵检测的部分居多，而防护的部分比较少”，这确实是目前大型互联网安全体系的现状
客观一点说，如果你熟悉甲方的安全建设，阻断也并不只有WAF这个单一的角色，所谓防护是由一系列手段叠加后的效果，包括但不仅限于如下手段
安全域划分/VPC/VLAN隔离
OS 加固,比如目录的 wrx 权限，cgroup+namespace+chroot
最前端的抗DDoS防护
4层防火墙的过滤
2.2.2.    不同视角下的设计方案
数据流视角
在理论篇中提到过大型互联网入侵感知和防御体系的思路类似于从各个维度釆集数据，然后用大数据（包含机器学习的方式）最终生成攻击告警信息
图16-1展示了常见的入侵感知数据源采集的维度，对应的是生产网络环境，而非办公网络环境

图16-1 数据维度包括
网络（安全）设备：防火墙、WAF、NIDS，在大型IDC环境中这些产品的形态可能不一定是“盒子”。而是分布式软件，module或agent的形式
OS层：HIDS数据，系统原生日志，以及应用层日志
运行时环境：例如JVM、Zend等解释器的定制日志，在形式上它也属于OS层面可以釆集的数据
数据层：对应的是数据库、缓存以及大型的分布式数据库中间件代理所产生的访问和安全告警
漏洞信息：由网络扫描器或主机本地agent搜集的漏洞信息
资产和配置管理数据：iplist等属于基础数据.如果这类数据不正确，对于多维度数据关联以及发现问题后的处理流程都有很大的障碍
这张图里没有标识岀来的实际上还有另外一部分：第三方威胁情报数据（例如IP信誉、 恶意域名和灰色URL等）
但据笔者观察，大多数企业的安全建设还没有成熟到对常规维度的数据榨干的地步，所以威胁情报这部分通常没有被放在紧急且重要的位置
服务器视角
以Web服务环境下的各个功能服务器为例，描述安全产品部署的选择性问题，因为并不是所有的服务器都需要千篇一律地部署所有的安全产品
图16-2是一个抽象的大中型Web服务架构

通常SLB软件负载均衡（7层）可能会同时充当一些WAF的角色，需要装载对应的WAF模块和人机识别模块（采集业务安全数据）
后端的App server应用服务器，例如Java或PHP或node.js等本身首先是一个Linux OS环境，需要HIDS主机层的入侵检测
因为有应用跑在上面，所以需要RASP运行时环境的沙箱模块，一般情况下还需要一个大数据日志釆集的agent用于收集系统和应用层面的实时日志（Flume是一款流行的大数据agent）
再后面的中间件不是一个直接对外暴露的服务，更多关注系统的自身状态是否存在入侵可疑，所以需要HIDS和一个大数据日志收集agent
IDC视角

是否涉及这个视角纯粹取决于规模，业务规模稍微大一点就会自然牵扯到跨IDC，跨全球区域这些问题
安全感知对应的技术架构也会随业务形态产生相应的变化
对于涉及敏感国家和地区受限于数据保护遵从与合规性需求时，可适当釆用区域分治原则，使所在region的安全大数据在本region内计算完毕，不跨region传输
逻辑攻防视角
从抽象的纯攻防视角如图16.4所示

对于企业的生产网络而言，最外围的威胁如下：1)4层流量型DDoS ； 2) DNS瘫痪；3 )链路劫持。对应最外层的主要防御手段是抗 DDoS
抗DDoS之后的第一道防御模型是快速收敛入口，减小攻击面，通常的手段是4层防火墙，5元组ACL过滤或利用Web服务的反向代理只对外开放TCP 80等主要服务端口， 其余全部对互联网禁止
在4层协议过滤之后，攻防模型进入第7层应用层协议对抗，1）HTTP∕HTTPS协议， 防御手段是WAF ； 2）非HTTP协议，主要使用N1DS，在节约成本的前提下也可以省略这 个措施转而采用服务加固和强审计的方式做妥协方案；3） CC等7层DDoS攻击，使用7 层的抗DDoS做人机识别，通常是类似WAF的软件模块
在7层协议的更后端是应用代码的运行时状态，这个层次比7层的CGI更底层，在比较大规模的生产环境中，一般以检测webshell为主，在小规模环境下可以采取相对重度的方式用RASP模块检测OWASP TOP 10漏洞中的大多数类型
再往后的攻击模型，介于应用层攻击到系统层攻击之间，包括：直达数据库的恶意攻 击（SQL注入或拖库），SSH的暴力破解，直接调用系统命令但仍未获得完全系统权限的 webshell指令执行，对应的防御模型抽象为SQL审计、系统日志分析、webshell检测
在攻击链的末端，最后一层攻击模型是获取系统权限，防御者模型则是检测提权和 rootkit,对应的解决方案通常是HIDS的功能。到这里基本完成了入侵过程的全部对抗。虽 然从攻击的角度看攻击还没完，但后面的横向渗透等攻击所对应的防御模型也基本都涵盖在前述的层次逻辑之中
2.3.    不同场景下的裁剪
2.3.1.    说明
以上“全套”设计对于大多数企业而言还是太贵了，在业务规模和安全投入没有达到理想化水平之前，只能做一些妥协和裁剪，但是这种裁剪还是要追求有限安全总投入（钱、 人员编制，内部支撑团队）水平下的最大安全效果
2.3.2.    IDC规模大小的区别
对裁剪影响最大的便是IDC规模，因为它决定安全的总投入
对于绝大多数既称不上海量，又不那么小的平台来说，可以有很多省钱的渠道，比如
4层抗DDoS的成本很高，不一定要自己去建这种能力，7层抗DDoS也可依赖于第三方，仅仅是不要对效果有过分的期望
如果没有条件做网络分光，那就干脆忘了这事吧，扫描器+Web日志分析也能顶用
自研Hids是奢侈品，如果你的公司市值尚未超过100亿美元，建议还是用现成的开源产品，比如OSSEC或者OSquery
RASP也是个奢侈品，衡量的标准是如果你WAF尚且不能很好地利用，就不要去弄 RASP了，当然规模比较小，对并发性能要求不苛刻的业务环境，花钱买商业产品也是一种思路
SQL审计也有点小奢侈，如果你在CGI层能有比较大的自信解决SQL注入问题， 那也可以忽略这个产品
2.3.3.    不同的业务类型
如果业务流量中大部分都是HTTP类型的，那么应该重点投入WAF、RASP和Web 扫描器，NIDS/NIPS可以省略，如果有条件搞BIDS，应该优先关注用户态检测，比如 webshell和提权
如果非HTTP协议例如SSH、MySQL等通用协议而非私有协议占多数，网络的部分可以考虑NIDS，数据库部分可以使用SQL审计
如果消息接口、远程过程调用、数据缓存和持久化中私有协议占多数，则不用考虑NIDS和SQL审计，而应转向HIDS。私有协议对入侵者来说是一道门槛，被渗透的概率不高，所以更多关注操作系统本身就行
对于大量的非Web业务，例如很多存储节点，也只需要关注操作系统的入侵，更多的在HIDS ± 投入，重点在后门程序和Rootkit检测
2.3.4.    安全感的底线
无论如何追求性价比，安全感总是有一个底线的，在生产网络的安全管理中，这个底线就是
入侵者能随意操纵数据库/用户数据（不一定需要数据库权限，也不一定需要系统的root权限）
渗透到达了操作系统这一层（得到shell了，无论是普通用户还是root）
作为防御方我一定要对上述两种情况有所掌控，最起码在这两个环节上具备一定的入侵感知能力，不至于发生了如此严重的事情还是没有半点告警
对应在整体方案上无论如何裁剪，在安全团队的能力不是特别惨淡的情况下，还是尽可能地在数据库（或DAL，数据访问层）和主机这两个层面设防
3.    分阶段的安全体系建设
3.1.    说明
3.1.1.    理论篇中提过安全体系建设是一个分阶段逐步推进的过程，本章就这一过程应如何分解以及分解后的重要部分展开描述
3.2.    宏观过程
3.2.1.    企业的安全体系建设是一个从“0”到“1”的过程，这种过程采用分步走战略，图 17-1展现了安全整体建设的“次第”

3.2.2.    不同阶段
这一阶段
第一阶段是基础安全策略的实施，这一部分看上去不那么高大上，却是ROI最高的部分
这一部分大多属于整改项，不需要太多额外的投入就可以规避80%的安全问题，即使一个企业没太多安全预算，做不到全线业务实时入侵感知，也能有一个底线的基础保障，这一阶段总体上属于“饿不死”
这二阶段
第二阶段是进入系统性建设，也就是第二篇中涉及的各个维度的安全防御手段
除了技术上，还包括流程和审计需求。这是一个相对体系化的雏形，对于不是特别大的互联网公司而言，开源软件+商业解决方案一般可以应付
在这个阶段，如果对象是大型互联网公司，则应该直接进入自研之路，同步开始研发安全产品，例如HIDS、大数据平台等，自研迟早是一个无法回避的现实需求
这三阶段
系统化建设，安全运维和SDL成体系之后，可以选择性关注业务安全的问题
这四阶段
当安全运维、产品安全（SDL）、业务安全都初步成体系之后是不是安全的整体建设就算完了呢？显然不是。有这些点和面只能说是有了骨架，顶多只能算一层厚薄不均的防御网，薄弱点仍然容易被穿透，因此接下来的工作是进入运营环节，也就是所谓的PDCA的工作，把每一个防御点打磨到极致
最后
当以上点和面的建设都打磨得差不多的时候，安全建设进入“自由发 挥区间”，这个区间做的事往往跟平台的经营状况，业务的市场地位，业务的全球化属性有很大的关系
3.2.3.    对整体的建设次第有了大致的介绍后，下面对一些关键环节做进一步描述
3.3.    清理灰色地带
3.3.1.    列举了一些常见的安全诉求，最初始的阶段都需要解决这些问题
第一阶段
资产管理的灰色地带（例如，资产管理系统数据不准确，运维和安全都不知道线上有某个IP，遗漏了安全检查和监控；一批新采购的服务器因为业务侧的紧急扩容需求急急忙忙上线，漏掉了安全扫描，诸如此类的）
安全措施的覆盖率和健康状态，例如HIDS的安装覆盖率，边缘IDC节点的服务器是否有
ACL的有效性。例如，为调试某个应用开了条临时策略，事后忘了回收了
这些问题涉及配置管理、上下线流程、安全监控的范畴，所以在流程和技术上都需要审查。另一方面即使有了流程也不完全可依赖，因为基于人的流程是会犯错的，基于机器 的流程才稍微可信点
第二阶段
清理远程登录弱口令
清理Web应用：SQL注入、文件上传点，struts2等RCE漏洞，管理后台对外，管理后台弱口令，统计第三方开源Web程序如discuz 的版本及其对应漏洞
清理服务端口：盘点不必要的服务和协议，排查高危端口
解决了上述问题，再投入或者同步进行纵深防御+入侵感知体系建设，才会事半功倍
3.4.    建立应急响应能力
3.4.1.    以下分别从组织、流程、技术体系三方面解释互联网企业的应急响应能力（SRC），参见图17-2

3.4.2.    组织
SRC不只是一个提交漏洞给奖励反馈的平台，更是一个黑白两道关系维系的渠道，有了关系渠道，就能在第一时间有偿获知
较成熟的SRC团队还做一件事情：漏洞根因和影响面分析，再后面的流程 SRC团队基本不再干预
3个典型职能部门工作分工
运维
运维团队负责跟系统、数据库、中间件、网络基础架构相关的补丁和配置更改的具体实施工作，例如第三方开源服务器软件Nginx、OpenSSL. MySQL 的漏洞
产品开发团队
产品团队负责产品相关的代码级别的漏洞修复（如果是自己开发的产品的漏洞）
安全部门中的防御体系建设小组
安全防御体系建设小组负责在相关的入侵感知体系中update对应该漏洞的检测规则
3.4.3.    流程
一般性的漏洞跟普通的bug修复流程一样，由安全部门接口转交业务线接口，之后由业务部门修复后提交新版本进行发布，遵循的就是普通Devθps发布流程
对于比较严重的漏洞，通常由安全、运维、产品3个职能的Leader组织一个会议，制定专门的漏洞修补和应急计划
SLA——根据漏洞类型和影响程度决定，一般性的漏洞也不必连夜修复。高危漏洞， 有实际攻击面的会连夜赶工，高危漏洞全网push补丁可要求在24小时内完成
假如短时间内无法修复，使用临时规避措施，前端设备提供“虚拟补丁”即一条针对该漏洞的阻断规则（前提是有这种能力），或者短期内关闭某些功能，添加访问控制手段 作为临时规避措施
3.4.4.    技术
发现得快依赖于入侵感知体系，从HIDS、RASP、WAF、SQL审计等各个维度，这是互联网安全防护体系的核心
修得快则依赖于持续集成和自动化发布工具的支持，开发人员如何一键发布，属于互联网公司每天的日常活动
同样，自动化运维能力主要属于运维的职责，但也会影响漏洞修复和安全策略实施的效率
总结，实际上有3件事：1 ）发现的快；2）修的快；3）修不了，临时规避
3.5.    运营环节
3.5.1.    很多人以为某一个漏洞没检测出来或者某一个检测手段不够深入解决起来都很简单， 确实站在单点技术的角度，如果仅从攻与防来看可能不是很难，但问题在于场景切换到大规模的服务器网络，这个问题的解会复杂化
首先是覆盖率的问题，入侵检测手段的demo往往只占30%的工作量
通过生产环境的性 能和可用性要求，并且灰度推广到全网达成90%以上的覆盖率，大约占30%的工作量
而防御模型本身的优化，数据质量的优化，检测规则的优化占40%以上的工作量
3.5.2.    图17-3是可以作为漏报的根因分析流程，防御体系建设的一大过程就是跟逃逸和绕过既有的安全策略做对抗

3.5.3.    如果一个安全事件没有发现，攻击者获得了权限但所有的安全机制都没产生告警，那就要追溯这个过程，尝试还原整个攻击路径，并分析没有抓到的原因， 通常有以下几个环节
首先，单点的检测手段不足是绝大多数人都会想到的，可能是检测规则写得不够好，对某些情况没有考虑到
单点的检测深度如果没有问题，那么可能的原因是单维度的数据不足以捕捉事件， 或者单维度数据不足以精确剔除误报，这个时候就要引入其他维度的数据作对比
在大型互联网中，单点的深度和检测维度都没有问题，而是出问题的机器上还没安装和运行相关的检测产品，全网的部署覆盖率才50%，剩下的50%在这几个维度是裸奔，所以被人捅了马蜂窝
以上都没问题，但是安全产品本身处在亚健康状态：进程挂了，模块挂 了，数据同步漏了••••••最后的结果就是岀问题时正好漏过了……一方面可能是因为产品本身的健壮性比较差，另一方面可能是设计不够好，体积臃肿，垃圾数据大堆，真正的数据利用率很低
覆盖率100%，但是数据质量不高，导致的误报很多，有价值的信息也被淹没了
质量不高有两层含义
第一层数据源跟检测目标的相关性不强，传统的SOC里采集了大量的数据，但很多信息不是安全强相关，也不足以判断到底发生了什么，这种数据就没什么用
第二层含义是模糊告警太多，很多中低风险疑似触发安全策略的告警，需要通过手工做大量验证，整体上ROI很低
如果以上都没问题，那最后只有两种可能
一种是整体安全机制存在缺陷
整体机制的问题涉及推倒重来， 是一个很大工程，这个必须要由安全负责人去决策
一种是人为的解读能力缺失，或者是人的事件处理流程上存在问题
人的问题，一方面需要提升对攻防的认知
一方面需要改进流程和过程方法论
上全部闭环后通常能在一轮又一轮螺旋式的迭代中不断地改进既有安全体系的能力， 所谓十年攻防积累很多都是背后看不见的功夫，这将占据了日常主要的工作量