uebaUEBA架构设计之 (一):UEBA框架

头条星座 2020-03-2688未知admin

  一直以来大家都在用各种技术和机制检测安全,从早期的SOC到SIEM,再到现在大数据驱动的UEBA。UEBA通过机器学习对用户、实体进行,不管这种是不是已知,也包括了实时和离线的检测方式,ueba能得到一个直观的风险评级和,让安全人员能够响应异常和。

  恶意检测一般通过对异常行为设定规则来判断,也会使用各种防御设备流量,例如IDS,WAF等。但这些系统的扩展性始终是个问题,当流量突发增长时很难跟得上,同时基于流量的检测可见性也不够,在交换机的接入层基本上由于成本原因,就无法再进行检测了,更不能通过网段的上下文来辅助,如果巧妙一点,完全可以绕开这些设备。

  软件是另外一种办法,在终端上设备之间的数据,但一样,软件的可扩展性、可见性也不令人满意。

  实际上,如果设备和用户是可信的,现有的很多方法都检测不到。传统安全产品的缺点是无法检测未知和内部,无法扩展,难以处理大数据。而且者总能找到绕过传统安全技术的方法,ueba比如规则驱动的恶意文件签名,沙盒。此外随着数据量的增加,人工越来越慢,响应速度过长。举例来说杀伤链,从入侵到横向到渗透,传统安全产品很联并作出适当响应,容易被大量误报淹没。

  UEBA相对来说具有洞察力和可扩展性,简单说UEBA是大数据驱动,且采用机器学习方法进行安全,能够检测高级、隐藏和内部的行为技术,不需要使用签名或规则。在杀伤链上能关联数据,进行有针对性的发现,这些技术包括机器学习、行为建模、分类、对等组、统计模型和图形。结合评分机制,对比活动,最终实现异常和的检测。同时,UEBA还包括可视化,以可视的方式跨越杀伤链。

  因此UEBA一个特点就是要能处理多个数据源的大量数据,这些数据源格式不同,速率也很快,后续的数据处理能够从结构化/非结构化提取有价值信息,数据处理是数据挖掘和预测领域的延续扩展,也是一门单独的学科:知识发现和数据挖掘。数据源分为实时和离线,实时连续监测传入数据,一般不考虑历史数据和第三方数据关联,因为对性能有影响。

  UEBA检测到的是“异常”,异常是说和预期行为发生了变化,变化不一定是,例如大促活动就会带来变化。异常表示需要引起关注,评估后给出判断,指标则代表了关注度的逐级上升。比如通过数据源产生了100个异常,进一步聚合为10个特征,再次产生了1-2个指标,这种数据扩展的方式让UEBA能够进行异常和检测。

  在机器学习背景下,历史数据和第三方数据都可以用来改进模型,但这些数据要比实时大的多,所以也比较慢。因此一般不把历史数据用在实时处理,即使用也以实时数据为主。实时检测后需要触发动作,ueba例如封IP,锁定账户,杀进程,误报解除等,这些动作可以不是直接拦截,而是提供出来进行人工决策,这些决策的反馈,进一步更新改进模型。

  离线处理可以发现更微妙的异常和,实时处理是有短时间决策约束的,离线在这方面要宽松很多。实时处理的数据是经过过滤的,完整的数据存为离线,因此离线可以有更多属性,跨越时间地理等信息。

  整体视图上,底层是基础设施层,考虑到成本问题,可以使用各种虚拟化。基础设施层则是软件层,一般包括Hadoop,spark,storm等。Hadoop进行分布式存储和处理超大集群数据集,storm是分布实时计算引擎,对数据流进行实时记录计算,Spark是大规模数据处理引擎,把事件收集在一起进行批量处理。

  再则是智能层,这一层主要功能是安全语义层和机器学习层,语义层提取转换加载数据,供给下游消费,机器学习层是语义层的消费者。

  这张图是系统内的一个概念图,数据接收模块是个负责从数据源接收数据的逻辑组件,包括了各种通信的API。ETL做数据准备,把数据接收模块的数据进行预处理,例如添加元数据,目标是为了让下游有效消费。

  ETL把数据处理好,实时传递实时,也通过批处理机构传递给批处理离线。实时数据是流式传输,逐个记录的,离线数据则是在固定时间窗口批量传递,所以离线器还可以进一步获得附加历史数据,实时器的结果和过程数据。

  上图是整体架构了,数据源部分收数据,日志类数据例如用户登录和访问事件,数据可从操作系统和安全系统(如防火墙、安全软件)生成。应用类数据源,根据情况不同有推/拉或混合机制,这里的数据例如HR系统,CRM系统等。最后一个类别是网络数据源,例如流量类,也包括从网络操作系统获取。

  数据源将数据提供给接收器,接收器有各种API和连接器,并且需要能够可选过滤,这部分主要技术是Flume和REST,Flume是开源分布服务,用来收集、聚合、传输大量日志数据。REST是访问大型数据库的界面。

  数据进一步提供给语义处理器解析数据字段,也可补充数据,比如IP和身份的关联,这里的技术实现是Redis。语义处理器中也需要过滤器,对一些无需处理的事件过滤,比如数据在两个IP之间的内部备份,安全上无需进行处理的话则过滤掉。可配置属性也很重要,对数据的解析配置,关联用户和IP,数据属性关联外部属性,也可用来调整过滤器。

  实时可以用Storm或Spark Streaming,这里还有进一步的分工,后面会详细说。不同的机器学习模型可在此进行,并且生成安全相关评分。

  评分后的指标提供给UI用户界面,用户界面中包括可视化地图、警报等,也同时可以直接输出action,监测到的数据持久化存储在数据库。如果安全人员需要调查,则从数据库捞数据。如果是误报,将结果反馈给数据库。

  在事件调查时,安全人员可能需要多种渠道获取数据,因此这里提供一个访问接入层,访问层包括了各种数据库和用户界面的API。

  离线的基础设施包括,SQL访问SQL存储库,存储时间戳的时间序列数据库,图数据库。图表示实体与异常之间的关联,用户之间的交互,时间上的序列,异常节点等,另有一些附加注释。因此图数据是数据的一个重要工具。

  离线批量可以从时间序列、图数据、SQL存储获取数据,也从外部获取三方数据。模型管理则包括模型注册和存储,注册存储模型的类型定义,存储则存储模型状态。

  还有一些零碎模块:模型有个需求是和模块共享,例如跨国,基础设施部署地不同,安全图也可以共享。底层是Hadoop。另外也需要一个控制层,平台自身运作情况。

  在实时处理中分为两个模块,分别代表异常检测和检测阶段,异常的输出给模块,在实践中,这两个阶段可以是相同模块分阶段,用不同模型执行。

  异常检测输出到异常编写器,异常编写器的作用是把异常信息存储到数据库,也同步在时间序列数据库、HBase、图数据库。事件确定异常后,更新事件关联关系图,关系图是按频率例如每天一次聚合。同样异常输出也是一样的存储方式。

  UEBA通过各种交互实体的行为基线检测异常和,通过和基线比较确定,平台则根据数据自适应改变行为基线,支持多个机器学习模型。

  上图是行为基线构建过程,例如人员A使用服务器S1访问源代码服务器,这是日常工作,偶尔也会访问访问服务器S3。因此平台基于人员A的网络访问活动形成基线。人员B也是如此。

  但实际上,不仅可以为用户生成,也可为任何类型实体创建基线,包括用户,组,设备,设备组,应用等。这个例子,也可根据服务器S3生成基于时间的基线。基线可以根据新接收的时间持续更新(包括实时和批量),也即是可自适应的更新。假设人员B开始频繁访问S1服务器,且这种访问被判断为,他的基线则被自动更新。

  通过传入事件数据,与实体基线比较进行检测。变化的阈值可以静态/动态定义,超过阈值则认为异常。比较可以基于多种技术,例如时间序列判断每小时登陆数,机器学习或图,检测有各种机器学习模型执行。

  以上是整体框架。后面的章节则会介绍各种组件的细节,包括数据接入和准备引擎,处理引擎,实时/离线配置,机器学习模型和不同应用,交互等。

  声明:本文来自唯品会安全应急响应中心,版权归作者所有。文章内容仅代表作者观点,不代表安全内参立场,转载目的在于传递更多信息。如有侵权,请联系 。

  到底是什么原因导致安全建设一直没有起色呢?是“落地实施的最后一公里”?还是“顶层治理的开始一公里”问题?

  本文编写于2017年1月,概述了如何将安全性设计到谷的技术基础架构中,这一全球规模的基础架构旨在为谷的...

  BeyondProd是Google基于零信任架构原则重新定义如何连接机器、工作负载与服务的项目,本文为《谷BeyondProd...

原文标题:uebaUEBA架构设计之 (一):UEBA框架 网址:http://www.paydaysbank.com/a/toutiaoxingzuo/2020/0326/22311.html

Copyright © 2002-2020 度日如年新闻网 www.paydaysbank.com 版权所有  

联系QQ:1352848661