其他
如何设计信息安全领域的实时安全基线引擎
什么是安全分析 计算框架的选择 引擎设计 实践与展望
Tips:点击「阅读原文」查看原文视频 & 演讲PDF~
一、什么是安全分析
日志采集解析。通过各种方法,从服务器、网关设备、终端、数据库或其它数据源采集各种流量日志、威胁日志、运行日志,和终端日志等数据; 实时安全分析。分析过程主要有安全基线、关联分析、安全规则、威胁情报,和安全知识库; 安全运营和态势感知。这个流程基于安全分析的结果来实现态势可视化、安全运营、多设备安全联动、安全编排等能力。
快速响应。因为安全事件经常是突发的,比如漏洞的披露、病毒的爆发等常常是在很短的时间突然发生,所以需要以非常有效和简单易用的方式来快速地对突发的安全事件进行处理,能第一时间响应客户的需求、应对各类安全事件; 场景定制。因为安全分析和常规的大数据分析场景会有一些不同,安全分析检测的是异常而不是正常,还有领域独有的一些需求,所以这里会涉及到很多领域定制开发的需求。 资源受限。相比常规互联网大数据平台使用方式,安全分析可使用的资源会有很多的限制,通常用户受限于预算和资源的限制,会尽可能地压缩和优化可用计算和存储资源规模,这会导致大量的组件采用混合部署的方式,且将来硬件和集群扩展成本也很高,流程很长。
第一是需要实时分析。安全检测对时延要求严格,攻防双方抢时间差,需要能第一时间检测到异常。同时由于是安全事件驱动,要求解决方案上线快,响应及时,能在最短时间形成防护能力; 第二是需要提供非常丰富的分析语义。安全检测的场景通常比较复杂的,需要提供丰富的安全分析语义,覆盖大部分安全分析场景; 第三个是能灵活部署。因为客户的环境非常复杂,需要能支持各种大数据平台,比如客户自建的,或者是他购买的一些云平台,并且还要有最大的版本兼容性; 第四是需要实现最小的资源使用。支持部署从一到几十甚至上百台节点的集群,在资源占用尽可能小的同时支持大规模,比如上千条分析规则或安全基线同时运行; 最后是运行稳定。安全产品部署在客户侧,需要 7×24 小时不间断运行,需要提供极高的运行稳定性,尽可能减少人工维护和介入,让客户无感知。
场景一,DBA 用户账号登录异常。比如登录位置异常,登录时间异常,使用数据库的行为异常等。比如一个 DBA 用户,通常是在某些时间、某些 IP 或是某些地点登录,但是某天突然在另外一个地方登录了,且时间也不是通常登录时间,那这可能就是一个异常,需要生成异常事件; 场景二,邮件发送附件数量超过常规值。比如安全基线学习部门或者整个公司发送邮件的行为数据,发现某一个用户发送附件的数量和历史学习数据有较大出入,那这可能是一个异常; 场景三,最近账号登录 VPN 服务的次数异常。通过学习用户账号 VPN 历史登录行为,构建安全基线,如果将来发现账号登录异常,则产生异常事件。
二、计算框架的选择
三、引擎设计
底层是部署层,通常是一个大数据集群; 第二层是安全分析层,基于 Flink DataStreaming API 来构建安全基线引擎,Flink 负责底层的分布式计算和事件流发送,具体的业务计算由安全基线引擎来完成。安全基线引擎向用户提供的使用接口为规则和 DSL,用户通过界面来下发规则 DSL 给引擎,引擎根据规则和 DSL 来对事件流进行分析和计算,同时根据规则语义使用外部的数据,比如知识数据、威胁情报、资产和漏洞等; 用户通过第三层的应用层来管理和使用引擎。并基于引擎数据结果态势分析,安全运营,资源监控等具体安全业务。
简单易用,学习成本低,易上手,一个没有研发背景的人也能经过简单学习之后就能上手使用,且符合安全分析人员的直觉思维; 需要提供丰富的数据类型,首先要提供丰富的基础数据类型,其次是安全分析常用的数据比如 IP,各类时间、资产、漏洞、威胁情报、地理位置等提供直接支持,使用者可以不做任何定制就能直接使用各类数据; 提供丰富的语义,尤其对安全分析语义进行增强和定制; 支持扩展,虽然提供的安全分析语义比较全面,支持大部分安全分析场景,但还是会遇到一些无法直接支持的特殊场景,此时就需要以扩展的方式来支持这类需求。
公共表达式优化。对分析语句中相同语义逻辑进行优化,降低重复计算和计算复杂度; 引用数据表优化。一个规则集中可能有上千条分析语句和规则,它们会大量的引用外部数据表数据,需要对表计算进行计算优化,比如 hash 匹配、大规模 IP 匹配优化、大规模正则匹配和串匹配优化等; 常量表达式优化。提高运行性能; 表引用优化。包含引用示例归并和引用语义归并两个部分,降低引用表的资源占用。
第一步是图融合,图融合涉及子图融合,即将规则集中所有子图融合成一个运行图,然后进行图节点语义融合、时间窗口归并、引用公共资源优化; 第二步是数据流优化,降低图规模,减少传输数据量,主要进行 Key 前置、语义等价节点融合、网络吞吐均衡,减少数据倾斜、节点归并,大幅压缩超大图节点数量等操作; 第三步是字段裁剪,降低传输事件大小,进而降低网络 IO 压力,主要包含图上字段推导和裁剪以及字段归并; 最后是代码生成,将分析语句和规则语义生成代码,并将执行图映射到 Flink DataStream API。
第一类是统计类安全极限,包含常见的时间类、频率类、空间类、范围类和多级统计类的安全基线; 第二是序列类,比如指数平滑类和周期类安全基线; 第三是机器学习类的安全基线,比如使用一些聚类算法的安全基线,决策树类安全基线等。
learn 表示学习阶段,在这个阶段基线学习输入的事件流; ready 阶段表示当前时间线已经到了基线的学习截止时间,但是因为延迟时间,基线需要等待一个延迟时间,在这个时间段基线可以继续学习延迟的事件,同时基线可以用于异常检测; close 表示当前时间线到了延迟时间,此时基线不再学习输入的事件,只用于异常检测; expire 表示当前时间线到了基线超时时间,需要基线停止进行异常检测,并删除。
第一种是事件触发计算,每条事件到达之后会触发一次异常检测计算; 第二种是时间触发计算,基线周期会注册时间定时器,时间定时器触发之后会触发相关基线计算流程。
基线异常事件输出发生于基线异常检测过程,当发现异常事件时需要输出对应的事件; 基线内容输出发生于基线学习完成之后需要将基线本身进行输出,用于基线编辑和基线本身异常分析。
首先需要基线是可编辑的,要求分析语言支持基线编辑相关语义,同时基线数据结构的设计需要支持基线编辑的语义,最后是要提供一套基线编辑可视化流程,包含基线展示、修改、删除等功能,用户可以直接在页面进行基线的编辑和下发; 第二是要求基线是可路由的,分析语句和规则在经过编译和图优化之后的真实执行图和页面显示的规则运行会有很大的不同,一个可路由的基线要求实现编译时构建全局基线更新流图、一套运行时基线路由方法,包含执行流图的路由流构建,广播和定向路由的支持,最终实现精确的基线数据分发; 最后还要求基线是可更新的,需要有一套清晰的基线更新语义,定义基线运行周期和计算方法,然后在你基线更新过程中,任何一个位置都可能会发生异常导致更新失败,此时需要设计一套机制能在任何位置失败后将信息反馈用户,用于错误判定和问题修复。
第一是待学习数据全部是历史数据,这需要支持历史数据学习范围探测,和在线基线更新; 第二是待学习的数据全部是实时数据,这要求支持基线自动学习、基线自动检测和基线自动更新; 第三种是刚才举例的这种,也是最复杂的情况,即历史和实时数据融合,这需要支持历史和实时数据边界划分、基线融合、重复数据消除。
第一种是相对于本周期的数据来判断,即与本周期其他数据进行对比,判断是否是噪音; 第二是相比上一个周期,与最近一个周期的数据进行对比,判断是否是噪音; 第三个是相比历史数据,与历史上所有的数据来进行对比来判断是否是噪音; 最后是用户自定义一个噪音判定逻辑,比如设定大于多少小于多少它是噪音。
第一个是稳定性增强,需要动态监控基线运行过程中内存的占用,引擎中可能同时运行了几百上千基线规则,需要能监控每条基线规则内存占用有多少,对于内存占用异常的规则,需要采取内存保护的措施,比如删除一些数据或者将它隔离出来,防止影响其它正常规则的运行,删除的时候可以采用资源优先级的管理,如果优先级比较低,且同时占用大量的资源,就可能会把资源给减少甚至停用规则的运行。引擎同时还对基线计算过程进行监控,监控过程如果发现严重影响图处理性能的慢路径,则采用子图隔离的方式将慢路径对应的子图隔离出来,防止对其它分析流程造成影响; 第二是状态监控,状态监控包含两个部分,第一部分是引擎将执行图所有计算节点的状态数据,比如 CPU、内存、磁盘、输入输出等信息报告给监控服务;第二部分是监控服务将执行图的运行信息处理之后映射为规则状态信息,完成图状态到业务状态的转换。对于大规模执行图和高并发执行的分析任务需要对图状态报告流程进行优化,降低资源占用; 第三是流量控制,引擎的下游业务可能是一些处理能力比较慢的流程,比如数据库写等,此时需要支持流量控制,防止较快的处理流程向较慢的处理流程输入过多的数据而引起资源过度消耗和卡顿,流量控制需要支持主动流量控制、被动流量控制以及时间窗口相关的流量控制,通过用户配置或自动处理来解决前后处理性能不一引起的数据丢失和系统不稳定问题。
四、实践与展望
往期精选