企业动态

    本文4236字阅读约需11分钟

    全球的安全运营团队正在被大量的告警淹没。最新的调查显示，众多安全运营团队认为SOC的首要任务是“降低误报”。

    通过主动降噪、告警去重、归纳合并等策略，可以成功将告警数量从每天十万条降至每天800条左右。

    一、告警过载困扰全球SOC分析师

    最近的一项全球调研显示，超过80％的安全运营团队认为，他们的工作及家庭生活正在受到告警过载带来的严重影响。

    受访者表示：正在被大量的告警淹没，并承认他们对自己能够确定告警优先级和及时做出响应动作没有信心。平均而言，受访者有超过四分之一的时间都在处理误报。同时也揭示了当前的现实情况：安全工具无法帮助安全团队处理来自于众多安全系统的告警。

    许多人承认在面对巨大的告警过载压力时，曾选择关闭告警（43％）、离开计算机（43％）、寄希望于团队其他成员介入（50％）、甚至选择忽略（40％）。

    研究显示，告警过载引发的疲劳和焦虑，还影响了他们的家庭生活，在情感上造成了巨大的损失。70％的受访者声称自己在工作之外也感到巨大压力，以至于无法停歇或放松，并且对朋友和家人感到烦躁。

    波耐蒙研究所（PonemonInstitute）在2020年和2021年分别发布了两份题为《SOC的经济学：出效果到底要花多少钱》的系列调研报告。

    在针对大型企业安全运营中心（SOC）管理者的682份的有效问卷中，有88％的受访者（2020年是84％）认为SOC排名第一的首要任务是“降低误报”，而安全厂商更加看重和强调的“告警监测”、“威胁检测”能力，仅仅排在第五名和第八名。

    这样的调研结果与我们的固有认知存在较大差异，然而这就是事实，是众多安全运营团队的真实诉求。

    二、什么造成了告警过载

    原因一：安全设备和产品众多，导致海量数据输入和数据重复。

    随着国内大型企业和机构安全建设的逐渐成熟，采购和投入使用的安全设备和产品越来越多，安全运营中心（SOC）需要监管爆炸式增长的海量数据和各类资产信息。

    调研报告显示：SOC监管最多的安全产品依次是防火墙、IPS/IDS、认证系统、威胁情报、邮件安全、云安全、EDR、漏扫、中间件、终端安全等产品。除了十种典型安全产品，SOC还经常需要监管诸如：数据库审计、上网行为管理、堡垒机、4A认证、VPN认证、零信任认证等众多审计类产品的海量数据和告警。

    数据量的增长同时又引发了严重的数据重复现象。由于单个安全产品的能力越来越趋向于多样化、多功能，势必造成了部分安全产品的能力重合，例如NGFW、UTM、IPS、流量探针等网络安全设备可能对同一份网络流量，都能检测出常见的网络攻击事件，其内容也大同小异，一旦重复部署，对于SOC分析师和运营人员的工作量却造成了数倍的增长。这是造成告警过载的首要原因，且呈现出日益加剧的趋势。

    原因二：安全运营工具未能对海量告警有效降噪、去重、归类合并

    安全运营平台类产品正迅速得到普及。作为安全运营的重要工具，安全运营平台产生的初衷是帮助安全团队管理爆炸式增长的数据和各类信息，以实现一站式的告警监测和多源的日志管理。

    然而，多数平台并未有效地解决因数据量过大和数据重复引发的告警过载问题。其本质在于平台缺乏对于各安全产品上报的告警数据进行有效的质量评估、过滤、去重和归类合并，也就是平台未能自动地对那些明显无效、质量差、价值低的数据进行筛选过滤，也未能有效地对重复或反复发生的告警进行自动化地去重和归类合并。

    原因三：人是SOC运营成功关键，而招人、育人、留人都很难。

    波耐蒙研究所发表的调研结果表示，人（分析师）是SOC成功的关键，也是SOC支出的大头。但分析师的雇佣成本也很高，SOC需要的人多、人贵，而招人、育人、留人都很难。

    调查显示，招聘到一名分析师平均耗时3.5个月，培训要花费3.8个月，但分析师的平均供职时间只有27.2月（2年左右），人员的流动性也很高。

    从分析师的角度来讲，他们的工作也很辛苦。70％的受访者承认，由于告警过载、信息太多、7X24X365待命等问题，很快就会精疲力竭，直接促使了人员的流失和招聘困难，进而导致更多的告警无人分析和及时响应，加重了SOC的失效，从而形成恶性循环。

    平衡告警过载带来的压力，缓解运营人员的工作负担，已成为SOC急需解决的问题。

    三、如何应对告警过载

    1、理性选择需要监测的数据源

    首先，安全团队应理性评估各类安全产品的能力覆盖范围和数据重合度，安全产品并非采购的越多越好，如不合理规划和分配各安全产品的职能，避免安全能力的重合，难免会造成不必要的浪费。

    对于明显重复的数据，例如捕获相同流量的FW、IPS、流量探针，我们认真做了数据质量评估，并选择了过滤，保留数据最全、质量最好、检出率最高的设备告警，作为告警首要呈现来源和主要分析对象，其他日志仅用于存储和辅助分析，不作为首要分析的对象。

    案例：国内某大型金融机构，拥有超过5万台终端/服务器、多家分公司、多个数据中心及海外办公区，安全基础建设相对成熟，拥有数百种的网络安全设备和审计类产品，其安全运营中心（SOC）每天仅收到的网络威胁告警就数以十万计，安全团队承认，他们最多处理全部告警的十分之一，压力可想而知。

    我们分析发现其DMZ区受到外部攻击的告警数据存在严重重复现象，经过严格的数据质量评估后决定仅监控WAF上报的告警数据，其数据质量相对最高，包含完整的请求响应体、payload信息、以及攻击是否成功阻断等关键信息。对于重复上报的NGFW的数据不再作为首要分析对象，成功减少了40%的重复告警。

    2、主动降噪无效告警

    常见的极易引发无效告警的几点因素：

    已阻断的攻击，无效攻击

    下级DNS服务器的请求，定位不到终端

    DHCP分配IP引发的告警，定位不到终端

    负载均衡、代理服务器，转发请求，定位不到真实来源

    案例：某部委官方网站，每天遭受的扫描和探测行为频发，来自防火墙、流量探针、WAF告警数量数以万计，经过分析发现，大多数攻击告警的响应码为0，-99，下行字节数为0，TCP连接状态为TMO，原因是由于绝大多数的攻击已被WAF成功阻断，没有响应流量。

    通过奇安信NGSOC平台建立过滤规则，将这些关键字段的无效值直接过滤掉，对于防火墙、IPS的告警，通过筛选“是否阻断”字段的值，仅保留“放行”“允许”的告警，作为首要分析对象，帮助分析师确定告警优先级。成功减少了90%的无效告警。

    3、深度关联资产信息，去除重复告警

    告警重复现象还表现为因负载均衡、代理服务器、多级DNS服务器等设备将网络请求进行转发，转发前后的流量同时被捕捉到。流量中的攻击事件被网络安全设备（IPS、流量探针、WAF）重复检测，造成告警数量的翻倍，例如，常见的恶意域名请求事件，下级DNS服务器对上级DNS服务器的域名请求同样产生了告警，且无法定位真实请求源，这类告警是典型的既重复又无效的告警。

    我们将告警关联了请求源IP属于客户的下级DNS服务器的告警，进行了过滤，减少了约50％恶意域名请求的告警数量。此外还分析发现，由于该企业的NGINX代理服务器的转发前后的流量都被捕获到，转发后的请求流量就存在告警重复且无法定位攻击源的问题，难以在第一时间对来自互联网的攻击者进行定位和封禁，因此我们也对其进行了过滤，凡是攻击源来自于NGINX服务器代理地址的告警，都不做首要关注目标，只关注请求转发前的攻击事件。

    这类告警优化策略，建立在对企业资产信息的充分了解之上，我们必须掌握企业的一些关键资产信息，尤其是对于容易引起告警重复、误报的资产信息都要有清楚的认知，并通过运营工具将这些信息与告警进行自动关联过滤，例如客户定期漏扫、云监测、资产探查等等服务其实都会周期性的引发告警，在不清楚这些资产信息的情况下，势必给分析师带来很大的误导和困扰。

    案例：某企业内网，RDP登录失败告警频发（RDP爆破），服务器数量多达上万台，告警数量巨大，客户虽明确规定需要通过40台堡垒机才能直接连接服务器，但落实困难，急需揪出哪些绕过堡垒机直接RDP连接服务器的疑似爆破行为，这类作为重点关注事件，而堡垒机与服务器连接失败事件，多为管理员的手误行为，不作为首要关注。通过奇安信NGSOC关联规则的关联客户资产信息，过滤出源IP来自于非堡垒机，而目的IP为客户核心业务资产的服务器IP的RDP登录失败行为，精准定位违规和疑似内网横移行为。

    4、告警归类合并

    通过上述的降噪和过滤策略，告警数量已经显著下降至每日数千条，减少了约94％的无效、重复告警，但对于人员有限的SOC分析师来讲，数量还是不低，仍然很担忧因无法一一查看这些告警而被迫忽视真正高危的安全事件。

    继续分析告警类型不难发现，很多告警虽不重复，但却是反复发生，例如常见的弱口令事件、信息泄漏事件、敏感目录访问事件、未授权访问事件等，此类事件并非攻击性质的事件，而是属于脆弱性事件或称之为管理疏忽事件，这类事件因涉及太多的主机、用户和服务，因此引发的告警数量非常多，单纯的按照IP、用户名、主机名去归并也不能完全解决问题。此类事件应当被合理的归纳总结，而不是面面俱到的一一展示，避免造成告警的堆积，淹没掉其他更具分析价值的真实攻击事件。

    我们积极地调整检测规则的“归并策略”，使此类告警在规定时间窗口内产生的所有告警合并为一个事件，并做好事件分类，使这类脆弱性事件不与其他网络攻击事件混为一谈。

    客户只需周期性的查看该事件并督促该事件中涉及的所有用户和主机责任人进行整改即可。此外，还需对不同的类型的事件进行了分类和定级，例如威胁情报事件的可信程度极高应该首先被关注，内网攻击事件优先于外部攻击事件，重点资产的安全事件优先于用户终端的安全事件等等，这些合理的分类和定级，能帮助分析师确立优先级，并定向地去查看。

    至此，我们通过主动降噪、告警去重、归纳合并等策略成功将告警数量从每天十万条，降至每天800条左右，平均每1亿条日志仅呈现给分析师34条高度归纳总结后的事件，作为SOC分析师调查分析的入口。

    安全运营平台作为大型企业一站式告警监测与多源日志的管理平台，在这些优化工作中扮演了重要的角色。我们一直认为，如果只是不经加工的日志存储和不经过滤的告警呈现，那与过去没有平台的时候何异啊？一个优秀的运营工具一定要更加智能地帮助安全团队去解决非核心业务，让安全分析师能够将更多精力和时间专注于告警分析和事件响应这种核心业务上，不要被告警过载问题所困扰。至少在当下的技术体系和运营现状下，工具仍无法代替人，那么工具就一定要帮助到人。

    笔者深知这些技巧和经验还不足以解决安全运营中的全部问题，安全分析师的工作繁重而劳累，希望谨以此文能够一定程度上帮助到更多企业和国内稀缺的安全分析师。

    关于作者

    Goldman，虎符智库特约作者，奇安信NGSOC威胁建模团队成员，研究方向为Windows域安全、账号安全、UEBA、ATT&CK擅长构建用户异常行为分析模型，长期从事威胁建模工作，协助企业发现用户违规和异常行为等内部威胁。