UEBA架构设计之路1

UEBA架构设计之路1：UEBA框架

安全管理 唯品会SRC 

 2019-01-23  5,724

鸣谢

VSRC感谢业界小伙伴——mcvoodoo，投稿精品原创类文章。VSRC欢迎精品原创类文章投稿，优秀文章一旦采纳发布，将有好礼相送，我们已为您准备好了丰富的奖品！

（活动最终解释权归VSRC所有）

前言

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

 

背景

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

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

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

 

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

UEBA架构设计之路2：数据接入和准备

脉搏文库 唯品会SRC 

 2019-01-30  4,568

VSRC感谢业界小伙伴——mcvoodoo，投稿精品原创类文章。VSRC欢迎精品原创类文章投稿，优秀文章一旦采纳发布，将有好礼相送，我们已为您准备好了丰富的奖品！

（活动最终解释权归VSRC所有）

 

 

上篇引言

UEBA通过机器学习对用户、实体进行分析，不管这种威胁是不是已知，也包括了实时和离线的检测方式，能得到一个直观的风险评级和证据分析，让安全人员能够响应异常和威胁。

到底是怎样的整体架构呢？我就不再介绍了，没看过第一篇的朋友，可以点击下面链接，去看第一篇：https://www.secpulse.com/archives/95668.html 

已经看过的朋友，咱继续。

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

三、数据接入和准备

数据类型	数据来源	数据价值
应用日志	本地log文件，log4j，log4net，weblogic，websphere，JBOSS，.NET,PHP	用户活动，欺诈检测，性能
业务处理日志	业务处理日志	客户活动，渠道，订单，账户变动，问题报告
点击流数据	web	可用性分析，用户行为分析，商品分析
配置文件	系统配置文件	基础设施安装、debug、错误、后门木马
数据库审计日志	数据库日志	数据被谁，在什么时间做了修改
文件系统日志	敏感数据存储和共享系统	监控审计敏感数据读取
API日志	各类API	API失败事件、爬取、越权
消息队列	JMS，MQ等	应用程调试问题、日志架构主干问题
操作系统状态和诊断命令	cpu和内存使用状态信息	故障、潜在问题、趋势、事件调查
包/流数据	Tcpdump，tcpflow生成的pacp或流数据，以及其他数据包级和session级信息	性能下降，超时，瓶颈或可疑活动，表明网络可能受到威胁或远程攻击
Syslog	路由、交换、其他网络设备	故障、分析、安全审计
WEB访问日志	WEB服务器	WEB分析
PROXY日志	PROXY	数据泄漏
Windows事件日志	Windows应用、安全和系统事件日志	检测关键应用，安全信息和使用模式
无线数据	DNS lookup记录，协议级信息：header，content和流记录	监控应用性能和可用性，事件调查，网络威胁检测

 

上面这个表举了一些例子，包括数据类型和含义，计算环境内生成大量机器数据，包括性能、诊断信息、操作信息（例如上传、删除、登陆动作）和其他各种类型，可以分析出性能问题、用户操作交互问题、用户行为基线、异常或威胁等。机器数据不仅是日志，还包括配置，API数据，消息队列，事件变更、诊断命令输出，甚至也可以包括工业系统的传感探测等。

事件有很多类别，例如防火墙事件、IDS事件、登陆事件，由各种不同的系统产生，这些系统从路由到Hadoop，再到云服务器等，所以数据格式五花八门，很多数据类型不可预测，传统的SOC不是针对这种数据多样性，速度，体积和可变性设计的，所以很难应对。

另外不同类型的数据包括不同信息，事件所属的通信层（OSI七层来看）越高，事件信息越丰富。网络日志只包括IP之间通信信息，应用日志可具有最丰富的信息，不仅可以获得通信信息，还包括共享等，价值更高。会话层数据可识别用户用什么凭证登陆，使用哪个会话，比下层网络数据更有价值。

 

 

上图则是数据接入和准备阶段的实现，这里包括了多个数据连接器，格式检测，解析器，字段映射器，关系图生成器，身份解析模块和事件视图等。

 

数据连接器   

数据连接器连接各种数据源，提供访问接收功能，数据源可以包括：

1. 身份认证：例如域控制器，SSO，人力资源系统，VPN，DNS，DHCP等;

2. 活动：网关，代理服务器，防火墙，DLP，文件服务器或文件主机活动日志;

3. 安全产品：终端安全，入侵防御系统，入侵检测系统或防病毒;

4. SaaS和移动：例如阿里云，SaaS应用，移动设备; 

5. 外部威胁情报：列入第三方黑名单的IP ，手机号。

 

数据连接器根据数据源，可以分为推/拉/混合。拉机制是基于查询的系统，例如splunk通过向数据源发出指令主动搜集数据，这种需要根据实时性能来定制查询，要考虑数据源的性能问题。对于推送机制的数据源，可以识别数据源输入端口，将数据推进来。还有混合机制，可以接收事件通知并确认，在约定时间通信接收事件。

对于HDFS这种分布式系统由于包括大量数据，优选是减少数据移动节省网络资源，所以对数据连接器的要求是生成多个作业，把作业发送并耦合到HDFS的作业处理集群，从这里接收数据。实际操作例如生成MapReduce作业，发布耦合到YARN，这样数据的移动很少，数据仍然保留在分布式文件系统中。

 

格式检测器   

有种情况是，数据连接器接收到的数据格式未知，分析师还没有设定对数据如何解析，这时候格式检测器就要发挥作用了，需要对数据进行模式匹配以确定格式。这种匹配可以用正则表达式或统计规则，再高级一些可以采用启发式，分层对复杂数据格式进行模式匹配，顺序是先剥离已经识别的格式，例如syslog事件头，再递归执行数据格式化匹配。

格式检测器比较耗资源也很耗时间，其实在安全领域很多数据格式都是预先知道的，例如防火墙日志，所以只要指定数据源和格式，数据接入准备就可以根据已知格式映射数据，并不需要数据格式检测，做的更友善的话，用户可以通过界面指定自动配置。

 

字段映射器

除此之外还有一种办法，分析师可以创建新配置文件片段进行定制，比如对特定数据源，配置文件可以识别哪个字段对应时间戳，哪个对应IP，还可以包括实体、动作、token、事件类型、机器类型等。如果数据是二进制，则可利用标记或解析器。通过自定配置文件，继而可以设置字段映射、字段关联，用于身份解析的指定参数。这么做的好处是系统不需要重新编译或重启。

字段映射器根据预定数据格式解析数据，把数据标记为KEY-value。初始步骤是用正则表达式提取剥离，例如syslog，先用syslog正则表达式去除syslog外壳，显示其中事件消息，然后解析器把数据标记为多个KEY以供进一步处理。

字段映射器把提取到的KEY映射到一个或多个含义字段，可以指定提取令牌中的哪个表示实体，实体可以是用户、设备、应用、会话、URL等，也可指定哪些代表操作事件。对实体的提取可以让分析师知道一些环境信息，比如用户是谁，用户量是多少，哪些应用被用户访问，环境中有多少设备。

 

关系图生成器

关系图生成器识别并记录实体之间的多个关系，为每个事件生成单个关系图的叫做迷你图，图包括很多节点和边，每个节点代表一个实体，每个边表示两个实体的关系，任何事件涉及至少两个关系实体。图生成器可以根据动作来识别实体关系，例如可基于动作、可识别关系表进行比较来识别关系，可识别关系表是可定制的以适应数据源。可能的关系则包括：连接、使用、运行、访问、上传、下载、成功登陆、重新启动、关闭、登录失败、攻击、感染等。例如GET表明用户正在使用特定IP机器访问另一个IP的网站，但在实践中，可识别关系的数量与图的大小直接相关，会影响到平台性能和速度。可识别关系还包括相同类型实体（比如两个用户），或两个不同类型实体（例如用户和设备）的关系。

 

 

如上图，表示用户A使用IP地址10.33.240.240与外部IP74.125.239.107通信，传送了106字节，事件状态码200，HTTP状态为GET的TCP事件，除此之外还包括事件数据的很多附加信息。使用前面的解析器和字段映射器，图生成器可以容易识别并创建关系图。关系图包括实体（用节点表示）、连接的边。

图生成器将关系图附加到关联事件数据，生成的图被记录为事件数据的附加字段，也可单独存储或传到后续节点，传到Kafka之后再经过事件处理引擎进一步处理，事件处理引擎使用机器学习模型执行分析，并根据情况结合关系图进行异常分析。

Kafka可在预定时间段聚合所有事件关系图，当多个事件比较时，异常会更容易识别。例如设备周期性外部通信，但突然出现了多台非周期性的连接，则识别出了异常。所有事件的迷你图，可以组合成更大的复合关系图，计算可以耦合多个关系图。复合关系图可被存储为多个文件，每个文件对应时间段，一般可每天存储，挖掘则一周或一个月。

事件关系图持续合并到复合关系图，复合关系图随时间增长，这就要周期性的从复合关系图中删除老化数据。

节点和边写入按时间命名空间分区的图形文件，每个较小的段与主分区按天合并，合并是指将类似的节点和边合并到同一记录，同时也可增加实体节点权重，这样事件到达的时间顺序就不那么重要了，只要事件有时间戳就可以和正确分区合并，同样可以并行方式在多个节点上创建复合图。

复合图可识别所有时间窗口内的关系，随着事件增加复合关系图大小也会增加。很多单个事件看起来没多大意义，但当事件够多，且所有关系图被组合后，可以提供更多的洞察，随着关系图增加，洞察指标的准确性也逐步增加。

单独事件关系图被存储，但尚未被组合时，关系图可以随时进一步更新，例如当前事件已经觉察有异常，则可以更新该事件关联图以包括该信息，这个个体关系图被修改成异常节点，当复合关系图创建时，可用于确定影响的实体。

复合图能让系统执行分析，实体行为可以是一系列、一定量，或由机器学习模型确定。通过明确记录事件关系，关系图生成器在此引入复杂处理引擎，关注与关系的不同部分。

 

身份解析和设备解析

身份解析技术用于跟踪哪个用户，通过哪个网络，登陆到哪个特定设备。在未知威胁检测中用户行为的信息非常重要，但并非所有日志都包含用户信息，典型的例如防火墙日志不会记录用户身份，因此即使特定通信是恶意的，防火墙也不能定位到用户。所以当日志不能捕获用户信息时，就需要身份解析定位用户。

身份解析模块需要观察系统环境（比如基于认证日志）获得信息，智能建立身份解析，这里也可以用到机器学习模型跟踪用户和设备之间的关联概率，这种信息获取可以基于多个接口数据。由机器生成的叫做机器标识符，例如MAC和IP，一台机器可以生成多个机器标识符。用户标识符是用户关联的，例如用户名，电子邮件地址。身份解析模块可以通过用户标识符作为关键字查询数据库解析用户身份，数据库一般是HR系统。用户标识符可以直接被视为用户，这样虽然简单，但问题是用户会使用不同的用户标识符，这样检测会有漏过问题。

机器学习模型有不同阶段，在训练阶段，接收用户和机器标识符，解析模块创建更新关联概率。

 

随着事件增加，模型可以更好的训练关联概率，身份解析模块创建概率图，概率图用来记录当前正在跟踪的每个用户的关联概率，概率图包括外围节点、中心节点和边缘，如上图所示。上面四个圆圈是这台机器的外围节点，下面圆圈代表用户中心节点，节点之间的百分比表示关联概率。

模型是时间顺序概率图，概率随时间变化，也就是说，模型结果是基于时间的，对当前和历史输入有依赖性，在大型企业里，时间依赖性对首次解析用户的场景很有用，然后会被逐渐分配给不同用户。所以身份解析模块可以根据用户在不同时间点启动机器学习模型的不同版本，每个版本有生效周期，用户事件达到后，模型版本依次启动、训练、激活、连续更新、到期。

模型根据事件不断更新，事件本质上是涉及用户和机器标识符的，但也可以根据特定标识符来训练。模型根据事件类型为新事件分配不同权重，当满足标准时认为模型已经经过训练，也可根据事件量和时间窗口来定义。

训练之后（例如关联概率超过置信度阈值时），身份解析模块激活该版本模型，此后的新事件如果满足身份解析的特定标准，则创建新事件与特定用户关联记录。这些标准包括：新事件有机器标识符，或版本处于活动时间段，从经验来看，身份解析技术识别单独的机器标识符效果还不错。

根据用户关联记录，身份解析模块注释新事件，显性连接到特定用户，把用户姓名作为字段添加到事件中，将用户关联记录发送到Redis缓存服务。

解析模块并不只是关联用户和设备，也可以是设备与设备的关联，分为第一机器标识符和第二机器标识符，如果事件只有第一标识符，则解析模块创建关联机器记录，机器标识符在实际中通常被标记为例如张三的笔记本电脑，可以更友好的观察。在这里解析模块变成了设备解析技术。

设备解析技术在DHCP中使用较多，因为DHCP环境的计算机没有静态IP，每台计算机启动时都可能有不同的IP，所以只是用IP关联会导致分析错误。这样就需要创建MAC和IP映射，这种映射在生存租约周期有效，可以根据DHCP日志进行分析，随着日志更新动态建立机器标识符映射。

 

事件丰富器

   类似定制版格式检测器，事件丰富器通过Java添加配置，为事件添加新字段，例如对IP进行地理位置附加，或者对来自服务器的事件进行注释，这样可以区分服务器和网络设备，或者启发式确定用户登陆情况。其他常见的丰富还有黑白名单，Whois查找等。

 

事件视图

事件处理引擎为数据接入准备阶段提供统一访问接口，也即是事件视图。各种不同类型的事件数据会让数据分析平台难以执行自动化分析，因此在这里提供统一，把多个异构数据源创建为同类。

绑定是把非结构化数据转化为结构化数据的过程，绑定的时机选择有两种，一个是早期绑定，数据在传入阶段就被转换为结构化，但早期绑定通常会丢失一些潜在信息，这些信息在案件中可能特别重要，同时也存在技术问题，因为没有办法在这个阶段提供统一的方式访问数据。

二是后期绑定，只是在数据进行操作的时候才绑定。换句话说在数据接入准备阶段没有做任何事，保留了原始事件数据，这样在后期绑定时候才处理，也让系统具有非结构化数据访问的通道。事件视图的实现是Java类，其内容包括订阅事件名称，可以包含多个字段以访问事件的某些属性，机器学习可以根据这些字段识别事件数据的子集，例如serverIP，sourceIP，sourcePort是模型需要的信息。事件视图将方法和事件属性信息关联，比如机器学习用方法来获取事件中URL随机性。事件视图存储在库中，当调用事件视图时进行加载。

数据接入准备阶段可向事件数据添加视图标识符，这个标识符允许下游复杂处理引擎选择接收信息，每个模型的注册表都可指定特定视图标识符，进行选择接收，可以理解为提供了机器学习模型的订阅机制。

 

上面是个防火墙事件，事件到达时首先确定生成事件的机器是X牌防火墙，基于机器类型确定该事件属于防火墙事件，然后基于配置自动添加两个视图标识符：网络和防火墙（这些都是分析师可调）。

  此后下游机器学习模型订阅事件视图，订阅是指允许信息自动路由。通过事件视图可访问的信息有：接口逻辑生成的信息，事件数据集。

 

会话

会话可以和身份解析结合实现，这里有会话跟踪器和会话解析器。监测到会话开始结束时，进行会话关联事件数据的标记，然后利用身份解析或设备解析，在会话窗口内事件都和会话关联，例如RDP和SSH都登陆到另一设备，这就有了相关性，我们称为会话谱系。例如用户在晚上10:13在IP10.245.0.6首次启动AD会话，然后又有一个SSH会话以root登陆新系统，这两个会话都属于这个用户，且有会话延袭，需要会话技术关联。

被跟踪的会话分配会话标识符sessionId和相关标识符correlationId，会话标识符用于标识相同会话，相关标识符查找同一延袭的其他会话，会话跟踪器根据登陆/注销事件跟踪用户会话，会话跟踪器负责在数据库中创建维护状态。

新事件到达，且类型被设置为SessionStart，则表示新会话创建，会话跟踪器将事件存储在会话数据库跟踪，存储包括开始时间、用户标识符、设备标识符、会话ID信息，从事件视图派生的LinkContex。通过新会话，进程线程开始自动在数据库匹配，匹配通过三个字段确定：“from-session-link-context（会话源主机）”，“to-session-link-context（会话目标主机）”和“link-Event time（会话记录时间）。”

如果没有匹配，则通过离线会话扫描附加，这个进程可以配置为每15分钟一次。如果执行身份解析的话，这种识别会更准确。会话过程也可以接收超时事件，在数据库中创建“超时”类别。

UEBA架构设计之路3：复杂事件处理引擎

脉搏文库 唯品会SRC 

 2019-02-01  4,696

鸣     谢

VSRC感谢业界小伙伴——mcvoodoo，投稿精品原创类文章。VSRC欢迎精品原创类文章投稿，优秀文章一旦采纳发布，将有好礼相送，我们已为您准备好了丰富的奖品！

（活动最终解释权归VSRC所有）

 

上篇引言

UEBA通过机器学习对用户、实体进行分析，不管这种威胁是不是已知，也包括了实时和离线的检测方式，能得到一个直观的风险评级和证据分析，让安全人员能够响应异常和威胁。

到底是怎样的整体架构呢？我就不再介绍了，没看过前面篇章的朋友，可以点击下面链接，去看看：

UEBA架构设计之路1：UEBA框架

UEBA架构设计之路2：数据接入和准备

 

已经看过的朋友，咱继续。

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

 

四、复杂事件处理引擎

复杂事件处理引擎跟踪分析数据流，这种数据流是无界的，也即是连续接收开放的数据序列，且终点未知。传统引擎都是基于规则的，规则的特点是计算简单，所以在实时计算中消耗较少。但规则的问题是针对已知结论的模式，对未知攻击无法识别，所以他不需要考虑历史事件。历史事件的增加，会对存储和处理能力都有新的要求。

 

UEBA系统使用基于ML的引擎，分布式训练和多机器学习模型的应用，模型处理事件特征集生成评分和结论。在实时处理中，收到数据，通过机器学习模型，立刻得到结论。事件特征集包括原始数据子集、关联的元数据、原始数据汇总和派生属性、标签以及这些内容的组合。通常事件处理引擎将输入输出都存放在非持久性存储器，提高I / O，减少时延。

 

引擎实时训练且更新模型，并可实时应用。引擎可在实时计算系统上实现，例如Storm可以实现任务的并行性，而不是数据的并行性。Spark和Apache Spark Streaming可以用数据并行来实现，分布式计算系统可以耦合到其他分布式组件，例如于簇的高速缓存Redis，分布式文件系统HDFS等。

 

与传统规则引擎比，能够识别未知模式，能够结合历史数据且不让计算负担过重。不仅可使用无监督模型，还可支持监督、半监督。引擎基于历史事件训练决策树，这种情况下决策树优先于规则，因为可以基于历史事件序列决策。引擎也可训练状态机，状态机不仅基于历史事件序列训练，也能应用。在处理特征集时可以跟踪实体多个状态，每个运行时状态表示实体历史，而不必跟踪实体的每个历史事件。

 

模型执行多种类型的分析，来自上下文各种事件数据源，各种关联的细粒度级别。举例来说，模型可对特定实体的行为分析，事件的时间序列分析，实体活动的图形相关性分析，实体对等分析和组合。原始事件数据源包括网络设备、应用服务、消息服务、终端设备等，上下文设置包括网络场景、登陆场景、文件访问场景、应用执行场景和组合。模型的输出则包括异常、威胁、威胁指示，并且通过多种手段呈现输出。

 

   对实体的行为分析手段有很多，例如：

1. 概率后缀树（PST）

2. 协同过滤

3. 基于内容的推荐分析

4. 使用文本模型的白名单和黑名单统计匹配

5. 熵/随机性/ n-gram分析的分层时间记忆过程

6. 统一资源定位符

7. 网络资源定位符和域（AGD）

8. 罕见分类特征/关联分析

9. 实体的身份解析模型

10. 陆地速度异常/地理位置分析

11. 离散时间序列数据的贝叶斯时间序列统计基础（基于可变记忆马尔可夫模型和上下文树加权）

12. 周期性模式的动态阈值分析

 

   基于图形的实体活动分析的方法也很多：

1. 命令和控制检测分析

2. 信标检测器

3. 设备，IP，域和用户信誉分析

4. 横向移动检测器

5. 用户/设备的动态指纹识别

6. 相似性和页面排名的实体分组

7. 社交邻域图聚类

8. 在线分布式聚类

9. 二分和通用图聚类

 

 

上图是事件处理引擎框架图，无界数据流作为输入，模型观察每个事件特征，得出结论。整个组件包括高速缓存组件、分布式文件系统、消息传递平台和纷飞时计算系统。也能支持对关系数据库的访问例如mysql，非关系存储访问HBase，事件序列数据库和图数据库。高速缓存组件也是分布式的，我们是在REDIS实现。

分布式文件系统将数据存在计算集群上，通过集群聚合提供带宽，包括了名称节点和数据节点，数据节点使用文件访问协议（块协议或文件协议）服务，这里是用Hadoop分布式文件系统（HDFS）实现。

分布式文件系统存储模型注册表、模型存储、模型执行代码库，有的设计也会把执行代码库作为模型注册表的一部分。模型注册表存储模型定义，用途是训练和应用机器学习模型的工作流。模型存储则表示机器学习模型、版本状态，模型状态将特征处理成结论。模型代码执行库存储处理逻辑和事件视图关联过程逻辑。

消息传递平台提供引擎和外部系统通信，这里是Kafka，负责接收无界流，高速缓存组件和分布式文件系统的数据发送到模型。

分布式计算系统是实时数据处理引擎，也是分布式计算集群，负责协调多个节点线程。每个计算节点是N个woker。

 

1、模型架构

引擎实现多个相同类型的学习模型，定义要训练和应用的工作流程，类型有模型注册表的模型类型来定义。

 

 

 模型执行代码包括：

1. 模型程序逻辑：描述了相关线程的数据结构和过程逻辑，程序逻辑参考训练和审议逻辑。

2. 模型训练逻辑：将数据变成模型状态的更新，随着数据的更多输入可以更新模型状态。

3. 模型审议逻辑：将数据转换成决策结论。

4. 模型程序模板、模型训练模板、模型审议模板：所有类型模型之间的共享逻辑，可以限制为模型程序必须经过训练和审议逻辑。

 

2、模型类型定义器

 

模型类型定义用来训练应用模型的各种配置，其中包括模型类型标识符、模型类型名称、用于训练流程的处理模式指定器、审议模式指定器、模型输入类型配置、模型类型拓扑，处理模式指定器指明处理模式是实时还是离线。

输入类型配置：指定模型类型订阅哪些事件视图，事件特征集可以用视图标签来标记，引擎使用标签订阅提供给相关线程处理。

模型类型拓扑：引擎将线程分发给不同worker。指定同类模型的数据分配，这种分配既可以是数据互斥分区，也可是重叠。结合实际来理解，拓扑可以指定按照用户组分组数据，也可按照特征分组数据。

 

3、分布式计算系统 

分布式计算系统实现集群资源管理，这里用的是YARN，集群资源管理实现计算平台引擎（例如Storm或Spark Streaming），在引擎上的进程可以访问数据访问层。数据访问层则提供关系数据库、图数据库、菲关系数据库、时间序列数据库、高速缓存组件、分布式文件系统。

分布式计算平台引擎可以实现模型执行引擎，然后模型执行引擎初始化模型相关线程，每个线程则是训练、审议的一系列程序指令。每个线程由分布式计算平台引擎独立管理。数据访问层可以使线程能够访问模型类型定义、模型存储、事件特征集。

 

4、拓扑

引擎基于拓扑选择数据和线程给worker，称为基于拓扑的分配。这里将拓扑和执行平台做了分离，拓扑负责分配维护定向非循环图（DAG）结构，这个结构的好处是可以动态执行线程和数据依赖，这样线程能在worker之间自由移动，可以提高模型处理性能。DAG还对安全、可伸缩性和模块化有益，在伸缩性上能够做到高速缓存、负载平衡、复制聚合数据流，模块化则在你对特定模型更新的时候，只影响相关worker。

 

5、模型训练流程

 

worker执行与模型关联的训练过程，如果模型状态还未存储，则根据训练逻辑产生模型状态。

当数据提供附加特征时，重新训练模型。一种是在没有相同输入数据递归或迭代情况下训练，一种则涉及增量。训练进行特征集隔离，仅重新训练其中这一部分。

接下来则训练到什么时候为止，则由模型准备逻辑来确定了，模型准备逻辑定义有多种，已经训练了多少事件、持续时间、模型状态是否收敛（阈值变化）等。模型不同逻辑也不同，当训练足够时，进入标记状态准备部署。

 

6、模型审议流程

 

模型审议线程处理时间窗口数据流，计算最近时间窗口的分数。引擎可在训练的同时继续创建新版本做模型审议，模型审议也可不暂停不重启重新配置。

接下来模型审议基于分数形成结论，分数与恒定阈值比较，或与动态基线比较得出结论。

一方面结论聚合存储，即可存在系统中，也可被分到分布式文件系统。另一方面将结论通过消息平台发布，使其他审议或训练模型可利用结论。

当结论表明威胁存在，生成用户界面元素触发消息动作指令，例如要求中止应用，拉黑流量或者账户。另一方面也需要分析师反馈结论，这时可根据反馈更新模型。

接下来检查健康情况，将计算得分和安全结论与其他模型比较，以确定偏差情况，如果超过一定百分比，则将健康状态置为失败，并且退出自身。

 

7、离线注意事项

 处理引擎有实时和离线两种，离线有更多时间，因此主要用来处理更大量的数据，所以离线处理引擎的需求有两个，一是与分布式数据集群交互，而不是复制、移动数据；二是利用各种编程模型，例如MapReduce。

基于需求一，则要求系统可以发出指令，查询、操作HDFS连接器，因为下游处理可以取决于事件顺序，典型的场景如用户行为基线构建，所以HDFS连接器可以按照顺序检索存储事件。

需求二，离线模型可以被简化，以便和MapReduce兼容。简化模型可以映射到多个副本，每个副本仅处理特定数据集。然后可将副本所有生成信息缩减回模型，这样就获得了单个副本处理完整数据集相同的结果。也就是说，可简化模型可以并行处理数据。根据模型不同，训练阶段可能会缩小，但评分不会缩小。

离线处理引擎和HDFS连接器协作，直接访问存储在HDFS中的数据。这个功能的实现需要作业控制器，作业控制器在这里作为引擎管理器，和连接器一起使用。作业控制器使连接器针对HDFS数据库运行查询，并选择处理，典型场景是指定时间范围的查询，按事件时间排序。

有些类型的日志文件是高优先级的，需要连接器优先处理，通常这种高优先是丰富信息事件，能够提高整体分析的准确性。例如为了启用身份解析，优先处理DHCP日志，然后把用户数据和设备关联的日志，最后才是其他文件，连接器指定其排序。

对检索到的数据，作业控制器位引擎启动启动作业，跟踪进度，在完成和失败时标记。分析完成后，作业控制器可以执行其他任务，例如导出身份解析结果，导出时间序列数据，或推送到Kafka。

作业控制器对文件的检索可以基于时间，例如每小时一次或每天一次，连接器检索后，将批处理文件传给作业控制器，作业控制器又启动引擎分析。

引擎的另外一个合作是和目录编目，目录编目是个耦合到HDFS的数据库，让连接器能够确定解析文件和顺序。当连接器检索时间范围内的文件，首先引用数据库中的表directoryCatalog，检查是否存在需要处理的行，并存储它在数据库中运行的最后时间lastRunTime。如果连接器在directoryCatalog中找不到任何行，则爬取当前目录查看是否有需要处理的文件，遇到文件后检索文件的修改时间，如果早于lastRunTime则丢弃，否则进行解析。

如果连接器按照升序记录事件，则停止解析返回第一事件的时间。如果降序，连接器寻找文件结尾检索第一事件时间。如果未确定排序，连接器解析整个文件并返回第一事件时间。然后在数据库增加一条，包含文件名、第一个事件的时间。

离线引擎可以对实时中不可用的信息进行分析，例如复合关系图，因此离线引擎可以使用机器学习模型处理复合图投影。

离线引擎首先定位复合关系图，然后获取复合图投影，投影包括与机器关联用户的图，以便跟踪横向移动。投影可以是很复杂的，实体关联的用户图，用户网站活动图。

复合关系图投影模型在后面会有继续说明。

UEBA架构设计之路4：异常、威胁指标和威胁

安全建设 唯品会SRC 

 2019-03-01  2,812

上篇引言

UEBA通过机器学习对用户、实体进行分析，不管这种威胁是不是已知，也包括了实时和离线的检测方式，能得到一个直观的风险评级和证据分析，让安全人员能够响应异常和威胁。

到底是怎样的整体架构呢？我就不再介绍了，没看过前面篇章的朋友，可以点击下面链接，去看看：

 

UEBA架构设计之路1：UEBA框架

UEBA架构设计之路2：数据接入和准备

UEBA架构设计之路3：复杂事件处理引擎

 

已经看过的朋友，咱继续。

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

 

五、异常、威胁指标和威胁

系统平台检测首先异常，进一步基于异常形成威胁。还有一个名词是威胁指标，是指安全威胁的潜在中间级别，安全威胁指标又可分为底层威胁、威胁指标、顶级威胁。之所以这样逐步演进，目标是为了减少误报，降低噪音。

 

上图是威胁识别处理流程，为了减少误报，整个流程先处理大量事件检测异常，进一步处理得到威胁指标，最后处理多个威胁指标识别出真正的威胁。

异常表示预期行为发生了变化，变化不一定威胁，但表示了可能引起关注的事件，由于大型系统中异常是海量的，所以在这一步无法进行人工介入调查。例如传入了1亿个事件，产生了100个异常，进一步处理则得到10个威胁指示，再被进一步处理得到1-2个威胁。

 

1、异常检测

 

上图是异常检测流程，从ETL接收数据，异常模型处理数据。异常模型包括模型处理逻辑，定义了给事件打分的过程，同时也定义模型状态。异常模型可以有多个类型，例如横向移动、黑名单、恶意软件、罕见事件等。

之后进行评分，评分也是异常模型的处理逻辑完成，将异常相关程度量化。打分是一定范围的值，例如0-10，0表示最小异常，10表示最大。

如果异常分数满足阈值，输出异常指示。阈值不是静态的，应该基于场景可变，所谓场景例如事件数据量、预定义事件是否存在、异常检测量等。

 

2、识别威胁指标

 

威胁指示的生成和异常流程一样，不再赘述。

 

3、识别威胁指标——实体关联

 检测到的异常通常与多个实体相关，比如发现多个设备异常，而设备又和多个用户相关，这些异常组成异常数据集。在上图中的小方框里，异常1与7个各类实体关联，但是异常2、3、4则只和一个单独实体对应。所以从整体上来看，异常1由于关联较多，所以威胁指标评分更高。换句话说，检测到的关联实体越多则威胁越大。在前面阶段的异常检测级别是没有这个范围视图的，因为异常模型是基于每个实例来处理，也即是异常模型是基于特定实体，而威胁指标则涉及整体范围。这是其中的差别。

 

4、识别威胁指标——异常持续时间

 在时间段t0到tn阶段检测到异常1～N，实际场景中表示短时间内发生大量异常，异常具有开始时间和结束时间，如果检测到的异常持续时间满足标准，则识别为威胁指标。

 

5、识别威胁指标——罕见度分析

 

罕见度分析也可以理解为稀有度分析，如果事件确定为罕见，则检测为异常。这种异常检测是局部稀有性分析，在特定实体的背景下观察事件罕见性。基于本地异常汇集成全局稀有性分析，这样异常的数量就是严重程度的重要指标。全局稀有性模型和本地稀有性模型是相同的处理逻辑的模型，不同在于一个是检测集合，一个是检测单个实体。

 

6、识别威胁指标——关联异常

 

关联异常是指用不同模型检测同样的数据，同一个数据被稀有度分析模型检测出异常，也被其他模型检测出异常，这样的组合观察能提供更多视图，基于这种组合的结果打分。

上面的关联是并行的，另外一种组合是串行，第一个模型处理完交给第二个模型，例如先看是否有关联异常，再看是否稀有度异常。

 

7、识别威胁指标——异常数据丰富

 除了内部检测模型，还可使用诸如威胁情报之类的外部数据，例如检测到实体连接外部木马远控服务器。通过外部信息合并，可增加置信度，并且在一些情况下识别威胁指示。

 

8、识别威胁

 

首先，威胁指示符数据的子集和预定义的安全性场景相关联，根据相关性识别出候选威胁。相关性我们后面再解释，可以理解为类似恶意软件威胁范围关联，或者杀伤链关联组件实体。

接下来把威胁指示数据和预先配置的预设规则比较，例如内部威胁可以和专家规则关联。然后生成模式匹配的分数。如果满足标准则识别为安全威胁。

 

六、复合关系图

复合关系图总结了整个网络所有角度来看安全，复合关系图可以表示各种实体以及异常节点，然后各种模型可以使用复合关系图检测威胁。

 

迷你图生成后，复合关系图把同类型进行压缩合并为一条，分配到不同投影。每个投影代表复合关系图子集，例如运维部门的登录、web访问、文件访问、跳板机活动就是一个投影。投影存在Hadoop集群中，基于时间戳细分存储，相关文件存在集群附近提高访问效率。通过关联复合关系图可进一步识别异常，例如邻域计算算法来识别一组异常，基于时间窗口的异常和置信度度量等。

 

从数据源接收事件数据，然后ETL解析生成关系信息。这个过程把每个事件的实体和关系生成一个迷你图，每个迷你图对应节点和边。拓扑引擎对迷你图进行处理检测异常，图聚合器把迷你图和异常组合到复合关系图，图库组件处理底层图数据库存储，图合并组件运行后台作业，周期性将新数据合并到复合关系图。

 

 

上面是一个复合关系图，有用户U1-U11，设备IP1-IP7，异常节点I1-I4。其中I1、I2、I4的异常都指向了设备IP3，I1、I2、I4同时还分别连接到了U4、U5、U7、IP5，这些说明它们是可疑用户。因此决策引擎可以识别一组节点表示的威胁。

 

上图表示了复合关系图存储投影的过程，复合关系图的每个边（关系），图库组件检查边的类型以确定所属投影，例如登录投影、网站访问投影、异常投影等。确定后将特定边分配给投影。

 

图库组件进一步将投影分解为多个文件，每个文件存储特定时间段记录，再精细一些，将投影分为对应到天的目录，每个目录对应到小时。这个粒度也可以动态调整，例如对过去两个月，分解为每小时。对两个月前的记录，分解为每周，随着时间推移则进行合并。

这里的异常关系也是复合关系图的一个子集，包括用户进行异常活动的边，每个投影根据时间戳存储，系统识别时间戳后将其相邻存储，提高网络读取效率。

 

复合关系图的威胁检测过程：

1. 接收事件数据

2. 生成事件特定关系图（迷你图）

3. 获取异常数据并存储

4. 将特定关系图压缩组合

5. 将特定关系图与异常数据组合成复合关系图

6. 从复合关系图和时间范围，使用模型分析

7. 模型分析后，将复合关系图转换为异常关系图，识别安全威胁

8. 确认异常

UEBA架构设计之路5： 概率后缀树模型

Web安全 唯品会SRC 

 2019-03-18  5,390

上篇引言

UEBA通过机器学习对用户、实体进行分析，不管这种威胁是不是已知，也包括了实时和离线的检测方式，能得到一个直观的风险评级和证据分析，让安全人员能够响应异常和威胁。

到底是怎样的整体架构呢？我就不再介绍了，没看过前面篇章的朋友，可以点击下面链接，去看看：

UEBA架构设计之路1：UEBA框架

UEBA架构设计之路2：数据接入和准备

UEBA架构设计之路3：复杂事件处理引擎

UEBA架构设计之路4：异常、威胁指标和威胁

 

已经看过的朋友，咱继续。

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

 

七、概率后缀树模型

传统技术只关注单一事件，但实际上单一事件正常，并不代表整体正常。在UEBA中，用了许多模型来发现异常，概率后缀数则是对异常序列进行检测的方法。序列可以对任何符号检测（符号是指特定类型的安全事件，例如连接失败、密码重置、文件访问等，机器可以观察到的事件）。事件类型符号用单个字符（例如，x，y，z）或整数（例如，0,1）表示，概率后缀数Probabilistic Suffix Tree，本文简化为PST模型。

 

具体来说：给定多个符号的观察窗口，则PST模型可预测下一个符号，通过异常计数识别异常。PST模型需要训练才能更准确预测，可以有一组特定历史符号训练，这组训练量要能确定预测是否可信。训练通常包括固定时间、固定数量、自动训练等方法，固定时间和固定数量都好理解，自动训练则是直到模型满足某个标准，例如收敛、得分向量和其他模型比较等标准。为了把计算复杂度保持在合理程度，训练也可小量，只训练四到五个符号。这种序列分析方法利用了“可以记忆”的PST特性。PST模型的序列生成过程可被建模为可变长度马尔可夫链，类似于有限状态自动机生成。PST模型的存储容量可以通过历史符号的最大长度来控制，历史符号则是概率后缀树的深度，并且是马尔可夫链长度。

 

在训练PST模型之后，能够可靠预测下一个符号。换句话说，给定多个符号历史，PST模型可针对实体看到下一个符号的整个概率分布，下一个符号的概率标示为P（下一个I历史），也称之为预测。例如，PST模型生成P(a|aabcd)=0.1, P(b|aabcd)=0.8, P(c|aabcd)=0.1, 和P(d|aabcd)=0，这个意思是，给定历史“aabcd”，预测下一符号是“a”的概率为10％，“b”是80％，“c”是10％，“d”不可能是下一个符号。如果下一个符号是“d”，由于“d”的概率非常低，所以该事件是罕见的，则触发异常。当PST模型预测符号出现概率小于阈值（例如0.1%）时，异常符号出现。

 

上图是PST模型训练示例，PST的深度是3。

 

由于不同类型实体行为特征不同，为了进一步增强预测准确性，PST模型可以首先建立特定实体基线，使用连续预测的分析窗口来构建这个基线，说人话就是：对于特定实体，了解特定窗口有多少异常事件时是正常的。

 

当PST模型训练完成后，记录下一个符号预测结果，利用这个额外的基线预测剖面图层，PST模型可以更加稳健抵御噪声，降低误报。换句话说，假设在分析窗口有10个异常符号是正常的，那么模型可以通过基线预测剖面学习，减少误报概率。分析窗口表示为“W”，分析窗口的长度可以表示为| W |。

 

上图说明概率后缀树的模型的训练，基线预测的建立，以及模型版本的激活。

 

分析窗口可以根据需要调整，例如对阈值低于长度的预测数量比率R计数来评估分析窗口，R也就是稀有分数。举例来说，长度为10的分析窗口内，有4个预测值低于0.01％，则该分析窗口中异常事件的比率R为4/10（或R = 0.4）。

 

PST模型准备就绪之后，通过将分析窗口滑动一定时间长度，收集每个分析窗口内的预测。时间长度标示为基线预测分析阶段图，然后用柱状图观察比率，柱状图记录了特定用户的常用R，也即是一段时间内重复执行每个分析窗口的预测，这个时间段时分析窗口长度的N倍（即，N×| W |）。在PST模型ready后的一段时间内，跟踪每个分析窗口的R并存储在柱状图，这个学习的柱状图表示为“H”，利用这个柱状图，任何新的R，PST模型就可以产生P（R | H）。P（R | H）是在给定先前Rs的历史的情况下看到具有比率R窗口的概率，以这种方式，可以构建特定实体的基线预测。

 

构建柱状图后，激活PST模型开始检测，进入了评分阶段，为了检测异常，首先记录稀有序列。具体来说，激活模型后，使用目标窗口识别稀有序列。类似基线分析阶段评分过程，PST模型生成预测并计算给定目标窗口的比率R，对目标窗口进行评分。为了更好的预测精度，可将目标窗口的大小设置为与分析窗口相同，在为目标窗口生成R之后，PST模型参考柱状图找到具有该级别的至少R窗口概率，如果该概率（即，P（R | H））低于某个阈值（，则PST模型确定该特定目标窗口是异常，并记录该异常窗口。

 

另外在实际中，也可使用可疑窗口扩大技术，这样可以完全的捕获异常。当目标窗口具有具有足够低概率的R时，启动窗口收集过程，可疑窗口扩大技术目的是扩展异常活动窗口，尝试在单个窗口内尽可能多包括相关异常。这个技术让原始目标窗口发现异常时扩展到指定大小，但需要注意，窗口可以扩展的时间越长，所需的内存就越大，展开的窗口可以表示为“E，“其中| E | 等于或大于| W |。

 

为了实现可疑窗口扩大，在检测到目标窗口中的异常R时，PST模型固定目标窗口的起点并开始增加窗口的大小。当正常R的下一个窗口时，异常窗口的收集过程停止。

 

将上述收集的异常窗口与稀有窗口的数据库进行比较，每次有一个新的稀有窗口时，引用该数据库以检查过去是否存在任何“类似”罕见窗口。这种罕见窗口缓存技术的基本原理是：过去多次观察到的罕见窗口往往比罕见的活动窗口“异常”，这种活动窗口与之前不同，例如对是否共享帐户的发现就可使用此技术。

 

对于给定的序列，为了确定系统之前是否已经看到，PST模型能够将两个序列相互比较，通过使用两个度量的组合，余弦相似性和Jaccard相似性。

 

PST-SIM：余弦相似性（PST-SIM）的PST实现是表示两个序列的两个向量之间的余弦相似性。每个载体由通过训练每个序列的分离PST而学习的概率组成，PST-SIM度量可用于捕获两个序列的频繁子序列之间的相似性。

 

JAC-SIM：Jaccard相似性的PST实现（也称为Jaccard索引）是两个序列中符号之间的Jaccard相似性。它可以定义为JAC-SIM（A，B）= | A交点B | / | A union B |该JAC-SIM度量对于少数不同符号的存在给予了更多权重，不考虑符号的出现频率和顺序。

 

因为观察到这两个度量具有不同的目标，所以采用两个度量的组合。PST-SIM强调符号分布的更大整体图像，并评估了分布的相似程度。而JAC-SIM对两个序列之间符号的存不存在更敏感。换句话说，与另一个序列相比，一个序列中存在的新符号越多，JAC-SIM结果就越不同。相反，如果仅缺少几个符号，并且其余的公共符号在两个序列中以相同或相似的方式出现，则PST-SIM结果不受少数缺失符号的影响。通过Sim（S1，S2）= 0.5×PST-SIM（S1，S2）+ 0.5×JAC-SIM（S1，S2）计算两个序列之间的相似性。

 

为了查看PST训练是否已开始收敛到另一个PST时，需要比较两个PST。PST包含训练中使用的所有符号的条件和边际概率。因此，比较两个PST的一种方法是对两个PST进行矢量化，并逐个比较它们相应的概率。在对PST进行矢量化之后，产生两个概率矢量，可以使用合适的矢量相似性度量（例如，欧几里德距离或余弦相似度）来比较两个PST。

 

考虑具有三个可能符号{x，y，z}和深度为2的PST的情况，意味着PST模型最多查看两个历史符号以预测下一个符号。假设边际概率是P（x）= 0.8，P（y）= 0.15，并且P（z）= 0.05，并且条件概率是P（x | xx）= 0.7，P（y | xx）= 0.3，P（z | y）= 1.0，依此类推。然后，对于两个序列A和B，表1是两个序列的PST的两个概率向量的示例。

 

	P（x）	P（y）	P（Z）	P（X | XX）	P（Y | XX）	P（Z | Y）	. . .
PST-A	0.8	0.15	0.05	0.7	0.3	1	. . .
PST-B	0.6	0.4	0	1	0.4	0.8	. . .

 

对于每个稀有序列，也就是矢量化PST，PST摘要保持在稀有窗口高速缓存。由于序列的PST摘要包括所有概率信息，因此可以将PST摘要视为罕见的窗口签名。表示罕见序列的PST摘要可用于与另一序列进行比较。另外对于每个罕见窗口，罕见窗口缓存保持已经观察到稀有窗口的次数的记录，可以保存多天。通过这种方式，当出现新的罕见窗口时，PST模型则检查稀有窗口缓存确定之前是否出现了新的罕见窗口，如果是肯定的话，有多少次、多少天不同。这个信息可用于确定新稀有窗口是否需要发出警报。

 

上图是概率后缀树模型的一个正常行为序列，和下面这个比较一下：

 这个图则是异常行为序列，从这两个图可以看出，即使在多用户协作的复杂环境，PST模型也可区分出异常。而异常则可以再用户交互这里呈现给用户，如下图。界面包括文本描述，哪个用户异常，什么样的异常，窗口内多少个事件，持续时间等。

 

此外可向用户显示异常序列时间轴，如下图按照时间轴显示，用户可在每个时间轴点击进行交互。

 

 以这些方式，PST模型可让整个系统确定：事件序列是否偏离预期基线，从而发现异常。并提供直观方式让用户接收警报，理解相关信息作出决定。

UEBA架构设计之路6： 图聚类

安全建设 唯品会SRC 

 2019-05-06  4,375

上篇引言

UEBA通过机器学习对用户、实体进行分析，不管这种威胁是不是已知，也包括了实时和离线的检测方式，能得到一个直观的风险评级和证据分析，让安全人员能够响应异常和威胁。

到底是怎样的整体架构呢？我就不再介绍了，没看过前面篇章的朋友，可以点击下面链接，去看看：

 

UEBA架构设计之路1：UEBA框架

UEBA架构设计之路2：数据接入和准备

UEBA架构设计之路3：复杂事件处理引擎

UEBA架构设计之路4：异常、威胁指标和威胁

UEBA架构设计之路5： 概率后缀树模型

 

已经看过的朋友，咱继续。

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

 

 

八、图聚类

图聚类是在复合关系图或投影上，识别图中的节点簇。例如检测设备相似性，检测实体活动基线偏差，这种节点簇可以方便的用于横向移动或账户被盗。簇可以表示一组用户，这些用户倾向于访问一组设备，决策引擎可以捕捉到那些有分歧的行为，比如用户访问了其他设备，这样就出现了异常。

 

图聚类的需求是：高效、高度可扩展、并行，通过机器学习模型实现，并可在实时和离线运作。

 

自动集群簇识别计算图上节点L1范数值，在一维上为节点分配位置（1D）网格。然后基于1D网格上节点的分配位置来识别图中节点集群。具体来说，通过将1D网格上的节点迭代重新定位到每个节点的L1范数最小的位置来创建节点组，以这种方式找到1D网格上节点的最佳位置之后，位于1D网格上相同位置的每组节点表示群集。

 

其流程为：

1. 按任意顺序遍历图，将所有节点映射到1D网格上

2. 创建一组在一维网格中相同位置的节点，通过最小化L1范数，找到每个节点的最优位置

3. 根据节点的内部/外部边缘比例检测每个组中的簇

4. 根据节点的内/外边缘配分，检测每组的簇

5. 移动外部边缘>内部边缘的每个节点，在1d网格中向左或向右移动一个位置（浮点）

6. 如果有浮点，遍历所有浮点与集群合并

7. 如果无浮点，输出

 

初始过程是输入任何图，例如下面这种。这个过程可在图构建时就执行，假设边缘权重由整数表示，而不是浮点数，在适当的加权后，节点之间的多个关联被折叠成单个边缘的权重。

 

第一步，逐个节点遍历图，并将节点映射到一维网格上，任何顺序都可以，但广度优先搜索最方便。从遍历图得到的一维网格是：

 

每个节点内的数字表示被广度遍历的顺序，形成了最后的位置。

 

第二步，在将节点映射到1D网格之后，迭代最小化每个节点的L1范数以在1D网格上找到其“最佳”位置，创建在1D网格上具有相同位置的节点组（范数是向量空间中的每个向量分配严格正长度或大小的函数，零向量除外），L1范数是在节点的每个候选位置与所候选位置之间沿着1D网格的各个距离（绝对）的总和，候选位置是直接连接到图中所有节点的位置，最佳位置是该节点在1D网格中的位置。因此将所有节点映射到1D网格之后，将首先尝试确定节点1的最佳位置，为此在其每个候选位置中计算节点1的L1范数，节点1直接连接到图形中的节点2,5和6 ，因此节点1的候选位置是网格上的节点2,5和6占据的位置。计算节点1中每个候选位置的L1范数，并选择L1范数最小的位置作为节点1的最佳位置。如果节点1保持在1D的初始位置，其L1范数将被计算为网格上位置1和位置2,5和6之间沿着1D网格的绝对距离的总和，即：位置1处的节点1的L1范数是L1。范数1,1 = | 1-2 | + | 1-5 | + 1-6 | = 10。相反，如果要将节点1移动到1D网格上的节点5的位置，则位置5处的节点1的L1范数将被计算为L1-Norm 1,5 = | 5-2 | + | 5 -5 | + 5-6 | = 4。

 

在例子中的验证结果是节点1的L1范数在网格上的位置5处是最小的图，节点1移动到节点5的位置。节点的最佳位置可能在后续迭代改变，但节点可以沿着1D网格重新定位。

 

 

在第二步处理完所有节点后，节点占据网格上的相同位置，这些节点构成节点组，集群簇。但在得出这个结论之前，进程查找每个节点组与外部有更强连接的任何节点，一旦发现则沿着1D网格重新定位。

 

第四步，基于节点的内部到外部边缘比率来检测每个组中的实际集群，节点分为内部边缘和外部边缘，内部边缘是同节点组内，外部边缘是连接到节点组外。如果某节点有外部边缘，总和权重超过内部边缘总重，即：内部/外部边缘比率小于1，则在下一阶段将节点沿着1D网格向左或向右移动一个位置（方向无关紧要），从当前节点移除该节点。以这种方式重新定位的节点称为“浮动器”，所以在后续步骤中存在任何浮动点，则遍历所有浮动点与现有集群合并。如果没有浮动点，则输出识别的簇，输出是给给到其他机器学习模型、决策引擎、用户界面等。

 

 

三次迭代后，节点位置如上图，可以看出确定了三个集群，节点1-5，节点7-11，节点12-14。

 

除了高效，高度可扩展和可并行化之外，这个过程也是增量的，如果在图上添加节点，不必把整个图形重新映射，通过最小化L1范数，可以将新添加的节点直接插入到1D网格中。

 

上述聚类识别技术可用于识别基本上任何类型的图中的聚类。但有个特殊情况，这个情况是二分图，二分图是一个图，节点分为两个不相交的集合，分为正常节点和伪节点，他们形成了两个独立集，这样每条边连接一个正常节点和一个伪节点。在二分图里，正常节点表示用户，伪节点表示用户访问的设备，这种二分图对横向移动检测很有用。

UEBA架构设计之路7： 横向移动检测

安全建设 唯品会SRC 

 2019-05-10  3,169

上篇引言

UEBA通过机器学习对用户、实体进行分析，不管这种威胁是不是已知，也包括了实时和离线的检测方式，能得到一个直观的风险评级和证据分析，让安全人员能够响应异常和威胁。

到底是怎样的整体架构呢？我就不再介绍了，没看过前面篇章的朋友，可以点击下面链接，去看看：

 

 

UEBA架构设计之路1：UEBA框架

UEBA架构设计之路2：数据接入和准备

UEBA架构设计之路3：复杂事件处理引擎

UEBA架构设计之路4：异常、威胁指标和威胁

UEBA架构设计之路5： 概率后缀树模型

UEBA架构设计之路6： 图聚类

 

已经看过的朋友，咱继续。

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

 

 

九、横向移动检测

用户可疑横向移动，通常说明用户证书密码被盗，或设备已被木马控制。横向移动检测是基于用户和设备之间的关系，给各设备分配相似性得分，设备和用户之间是关系，而相似性得分说明设备和用户的相似性。另外也基于登陆事件和设备分类元数据，解释相关性。当用户与常用设备相似性得分有明显差别时，检测出异常。

 

机器学习模型在这里的作用是生成分类元数据，分配相似性分数。下图则是横向移动检测框架图：

 

机器学习模型分析事件数据，图上是一个登陆投影，基于这个投影，模型为每个设备和用户生成分类元数据，分类元数据的作用是解释用户与设备的相关性，表示用户是普通用户、管理员或系统账号，对设备则可以表示办公终端、服务器、打印机等。所以上层模型可以实现自动识别用户、设备类型。

机器学习模型识别用户与设备之间的关系，如果事件数据包括登录相关，则模型可将使用关系指示为用户登陆事件。右侧是关系图，左边组是用户，右边组是设备节点，两组是不相交集合。二分图中每个边都将用户和设备相连，另外关系还表示事件时间顺序。

 

基于使用关系，模型给设备分配相似性得分，相似性得分指示哪个设备被相同或类似用户组使用。换句话说，相似用户登陆设备倾向于具有相似性得分。

 

上图是用户和设备的二分图示例，左侧是用户节点，右侧是设备节点，U11、U13登陆到S21，U11、U12登陆到S22，U12和U13登陆到S23，因此S21、S22和S23是与用户相似组关联。这个相似用户组就是U11、U12、U13。

 

注意U12在登陆到S24的时候是个虚线，表示特定登陆，而登陆S24的只有U14，这和U21、U22、U23显著不同了，这种差异反映在相似性得分分别为0.31、0.30和0.33。而S24相似性得分只有0.06。

 

当U12登陆到S24（虚线），模型确定S24得分0.06，无法满足常用设备相似性得分标准，这个标准可自定义，本例假设为0.255.这时模型检测到异常。

 

模型进一步分计算用户异常分数来判断异常，异常分数表示威胁相关可能性，可基于设备相似性得分的统计度量差异来计算，例如平均值。在这个例子中，设备S24相似度得分0.06，S22和S23平均得分0.315，相似性得分差异为0.255，模型把0.255和额外权重0.1相加得到0.355的异常得分，额外权重意思是这个设备的资产重要性。由于0.355超过0.3的阈值，所以报出异常。

 

不止于此，模型可基于用户的基线检测异常，这个基线包括用户和设备的相似性，例如U12的基线，与S22和S22相似性得分差异是0.03，并且小于阈值0.1。基线还包括登陆失败、成功、访问成功、访问失败等。

 

模型可以以各种方式向设备分配相似性得分，上图是过程。模型接收二分图，对设备D4分哦诶初始权重值1，这个过程可以随机，权重值也可以不等于1。

第二步，模型6300在设备节点D4处保持初始权重值1的百分比（15％），并且将D4的初始权重值1的剩余部分沿着D4的边缘均等地分配到节点U2，U3和U6。这个分配过程可视为马尔可夫链过程。在每个步骤中，值分配具有15％的概率（因此也称为“概率百分比”）以保持与前一步骤中相同。 值分配具有（100％-15％= 85％）概率跟随节点的边缘移动到另一节点。

第三步，节点D4保持权重值0.15（= 1 * 15％），剩余部分均等分配给U2、U3、U6，每个节点接收权重值0.283（= 0.85 / 3）。

对每个节点，模型沿边分配，直到D1-D6的权值收敛。对于D4，模型对其保持0.023(=0.15*15%)的权值，并将0.042(=(0.15*85%)/3分配给U2、U3和U6。U2，模型保持权值0.042(=0.283*15%)，并将0.120(=(0.283*85%)/2分配给D1到D4。

 

同样，对于U3，模型保持权值0.042(=0.283*15%)，将0.241(=(0.283*85%)/1分配给设备D4。对于用户节点U6，模型在用户节点U6上保持0.042(=0.283*15%)的权值，并将0.120(=(0.283*85%)/2分配给设备节点D4-D6。

 

模型继续迭代过程，直到D1-D6处的权重值收敛。在迭代的步骤中，对于每个节点，模型在节点处保持15％的权重值，然后沿边将剩余的权重值均等地分配给其他节点。收敛标准可以是指示这种收敛的任何标准，例如，当每个节点处的两个连续步骤之间的权重值的变化小于阈值时，模型可以确定迭代过程达到收敛。

最后，迭代过程达到收敛时，显示具有收敛权重值的最终步骤的状态。D1-D6的收敛权重值是分配给这些设备的相似性得分。

 

 上图从A到D线了模型确定相似性二分图的示例。在A中，6610和6611有很多共同用户，因此趋向于接近的相似性得分。

 

图B，6620和6621有多个共享专用用户28和29，专用用户是仅和6620、6621交互的用户，因此20和21趋向于接近的相似性得分。

 

图C，6630和6631仅有单个共享用户37，因此6630和6631具有较大差异的相似性得分。

 

图D，6641、6642、6643是与用户类似的基团（N1），而6644、6645、6646也是类似的基团(N2)。如果把用户37移除，则基团分为两部分。用户37是连接到两组的唯一用户，与N2的6645交互，和N1的6642交互，触发组外访问异常，因为6642的6644的相似性分数差异很大。

检测到的组外异常，表示用户的可疑横向移动。基于异常，模型可以进一步确定异常是否导致安全威胁，如上图。其中U代表用户，D代表设备，A代表异常节点，这个图表达了：用户节点U6701访问了不常见的D6703。模型并不只是登陆关系，还包括其他类型诸如黑名单异常等。

 

A6704表示信标异常，信标异常意思：D6703设备周期性向与用户节点U 6705用户相关联发送可疑信标消息。

 

6720圈出来的部分是威胁的关系路径，从用户节点U6701和异常节点A6702开始，以异常节点A6706和设备节点D6707结束，D6707表示关键资源设备，可能是域控之类。威胁沿着关系路径，由一系列异常组成。

UEBA架构设计之路8： 恶意软件检测

安全建设 唯品会SRC 

 2019-05-27  2,907

VSRC感谢业界小伙伴——mcvoodoo，投稿精品原创类文章。VSRC欢迎精品原创类文章投稿，优秀文章一旦采纳发布，将有好礼相送，我们已为您准备好了丰富的奖品！

（活动最终解释权归VSRC所有）

 

上篇引言

UEBA通过机器学习对用户、实体进行分析，不管这种威胁是不是已知，也包括了实时和离线的检测方式，能得到一个直观的风险评级和证据分析，让安全人员能够响应异常和威胁。

到底是怎样的整体架构呢？我就不再介绍了，没看过前面篇章的朋友，可以点击下面链接，去看看：

UEBA架构设计之路1：UEBA框架

UEBA架构设计之路2：数据接入和准备

UEBA架构设计之路3：复杂事件处理引擎

UEBA架构设计之路4：异常、威胁指标和威胁

UEBA架构设计之路5： 概率后缀树模型

UEBA架构设计之路6： 图聚类

UEBA架构设计之路7： 横向移动检测

 

已经看过的朋友，咱继续。

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

 

十、恶意软件检测

 通过对网络流量的分析，可以观察到恶意软件的痕迹，例如恶意软件会定期向控制端发送信息。

1、恶意软件通信检测过程

 

 左上方接收到事件数据，其中自适应过滤器会根据动态白名单过滤掉无关紧要事件，举例来说，虽然我们不知道xx.com这个域名是好是坏，但分析得知网络上大多数用户经常访问xx.com，因此推断xy.com为良性，所以对xy.com进行恶意域名关联分析没必要。动态白名单能够简化计算，减少误报。

 

接下来继续处理事件数据生成特征分数，并生成实体基线。特征分数包括多个，每个分数则是根据不同特征生成。这里包括定时分析、语义分析、通信统计、排序分析、实体关联分析、推荐分析和其他各种。每个分析生成一个或多个分数，例如时序分析可以生成两个分数，一个是关联通信周期性分析，另一个是关联通信间隔时间的方差。

 

实体基线还可通过全局证据收集丰富取证数据，例如内部黑名单或外部WHOIS数据，通过证据收集进入证据数据，这里的数据可对特征分数模型产生影响。实体基线还包括分数归一化，涉及归一化多个特征分数，以便在异常分数生成阶段进行后续处理。

 

接下来生成异常分数，如果异常分数满足标准，则过程结束。

 

2、生成要素分数和实体配置文件

特征分数是基于每个实体计算的，也即是实体和恶意软件关联可能性量化评估模型，模型分为处理逻辑和模型状态，生成特征和生成异常分数可以是同一个模型，常用特征分数模型是监督和无监督，监督模型由人工开发训练样例以有效生成特征分数，每个特征分数是一段范围内的值，例如0-10。

 

前面也说到特征分数是基于每个实体计算的，也会生成多个特征分数，下面这个表列出了xy.com的特征分数f1到fn。

	定时分析	通信统计	语义分析	其他分析
实体	f 1	f 2	f 3	f n
xy.com	5.2	4.0	3.2	7.8

 

上面是简化的，实际情况中特征可能包括几百个，与实体关联的特征分数标示为特征向量f = {f 1 f 2 f 3。。。f n }。xy.com的实体配置文件可以表示为特征向量，f = {5.2 4.0 3.2。。。7.8}。

 

举一些例子有助于理解，语义分析：通过分析关联域名字符排序，这个字符排序生成了置信度。通信统计可以是通信周期性、通信间隔时间变化、通信顺序检测利用链、传输进出比率统计。定时分析，恶意软件定期从外部接收控制消息。这些分析基于安全知识，得到的评分标识了恶意软件关联性。

 

但随着对抗升级，恶意软件也不再是基于静态域名，而是机器不断生成新域名通信。这里的特征是高度熵或随机性，分析字符中的熵或随机性方法则是通过n-gram分析，可以使用语言域名的大量词汇来训练用于n元语法分析的机器学习模型，通过训练开发出n-gram概率列表。换句话说，n-gram分析模型可以观察域名字符序列，可以参考国外的一个n-gram分析：

 

人肉查看，左右域名的哪个概率更低？显然是左边，n-gram概率模型要实现的就是这个见解。

分析一定时间内，实体定时的通信消息，基于特征分配分数，其中特征分数代表了置信水平。根据安全知识，高周期性的通信不太可能是人为生成，而是机器生成。在数据传输统计上，通过进出比率能够了解到通信目的，出方向大于进方向可以指示数据泄漏。

 

3、生成异常分数

异常分数基于实体基线得到，可将异常分数概念化为实体所有特征分数的组合。生成异常分数是一个集合学习过程，应用多个模型处理多个特征。生成异常分数可以是简单的计算特征分数的加权线性组合，异常分数可以简单表示为：异常分数= ∑i = 1 n ⁢ ⁢wi fi

 

其中w i是每个特征分数f i的加权因子，并且异常分数仅是多个特征分数中的每一个与加权因子的总和。加权因子w i取决于很多因素，例如实体类型、用户配置项、要素分数。

 

应用集合学习，能够实现更好的预测性能并减少误报，适用于集成学习的则是随机森林，整个过程则是：根据多个机器学习模型处理多个实体基线，分配多个中间异常分数。

 

4、异常检测和通知

一旦生成异常分数，如果满足指定标准，则检测到异常，前面我们说异常分数可以是0-10，标准在这里可定义为大于等于6则为异常。但指定标准不一定静态的，可根据事件数据量、用户配置等动态变化。

 

如果检测到异常，则输出异常指示线是个用户，示例输出如：

 

域名	通信分数	定时分数	7层分数	NLP分数	建议
www.abc.com	高	中	中	无	优先级：高，通信正常，活跃
www.frejghrf.com	0	中	0	高	优先级：低，防火墙拦截
www.baidu.com	无	无	无	无	无

 

最后的建议是根据前面得分进行解释，而在得分上分为高中无，也可以是数字。www.abc.com 通信分数为高，表示通信正常且未拦截，因此建议中是高优先级处理。这个建议根据人工给定规则生成。

 

检测到的异常存储在异常图数据结构中，异常图数据结构表示关联实体的多个节点，以及链接节点中的多个边。

UEBA架构设计之路9： 信标检测

Web安全 唯品会SRC 

 2019-07-23  2,062

上篇引言

UEBA通过机器学习对用户、实体进行分析，不管这种威胁是不是已知，也包括了实时和离线的检测方式，能得到一个直观的风险评级和证据分析，让安全人员能够响应异常和威胁。

到底是怎样的整体架构呢？我就不再介绍了，没看过前面篇章的朋友，可以点击下面链接，去看看：

 

UEBA架构设计之路1：UEBA框架

UEBA架构设计之路2：数据接入和准备

UEBA架构设计之路3：复杂事件处理引擎

UEBA架构设计之路4：异常、威胁指标和威胁

UEBA架构设计之路5： 概率后缀树模型

UEBA架构设计之路6： 图聚类

UEBA架构设计之路7： 横向移动检测

UEBA架构设计之路8：恶意软件检测

 

已经看过的朋友，咱继续。

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

 

 

信标检测

恶意软件有很多检测方法，例如根据每个IP通信双方的流量检测，其中包括IP黑名单、发生频率等手段，但这些技术都有缺点。如果这些传出流量的IP是一个开放接口，就很可能产生误报，但最大的问题是网络中的服务数量越多，复杂度越高，而且对于实时监控也是个挑战。

恶意软件需要和控制服务器通信接受指令，而且这个通信是定期的。恶意软件生成的流量和用户生成有不同模式，但大多数技术都无法识别这个区别，因此这里是可以检测恶意软件的特征。

传出流量可能包括用户流量如网站访问、电子邮件、下载软件。还会包括合法/非法机器流量，例如应用更新、设备时间同步、心跳、恶意软件流量掺杂。机器流量有一些信标特征，所谓新标是指周期性、规律性信号发送。

技术上需要区分用户和机器流量，如果是机器流量则需判定流量是良性还是异常，有一些方法例如启发式、白名单确定是否良性。但实际上还有更多参数，例如请求数量、周期性、web对象数量、目的IP、目的端口数等。

 

 

上图是一个设备在17秒内的传出流量示意图，传出包括用户和机器流量两类。当用户活动时生成大量连接请求，当用户不活动时进入静默期，我们需要检测静默期，分析流量异常。

第一个用户网页访问，在4秒内生成接近50个请求，请求发给不同服务器获得网页、图像、CSS等，网页完成后流量迅速下降到0。也就是：连接数量迅速增加或减少。

紧接着进入机器流量，请求较低，一直都未超过10。也就是：与用户流量比，请求量低。此外连接更有周期性，每2秒出现一次。

总结为：用户活动有明显流量增加，连接请求多，非周期性。机器流量则具有周期性。

 

区分机器和用户的参数示例：

1. 时间段内连接数量

2. 连接周期性

3. 连接不同IP数量

4. WEB请求数量

5. 目的地端口数量

6. 目的地URI

 

 

 

假设对上图中的终端计算机出流量进行检测，终端计算机的出方向分别是内外部网络，系统通过流量日志检测，流量内容包括网络流量、IP流量、Web流量等，例如Web流量包含HTTP消息，可以和目的IP，目的URI，端口号，GET或POST等参数相关联。IP流量可以和目的IP地和端口号之类的参数相关联。

流量分析模块检测是否机器流量。如果是，则交给异常检测模块判断良性还是异常。确定异常，则传递给威胁分析模块，并生成警报。

在检测机器流量部分，流量分类模块分析流量中的连接请求，确定用户流量还是机器流量，可以按照20秒时间分组。然后根据前面说到的参数判断，例如周期性，分组中每个连接请求的之间周期平均值，如果超过阈值则确定为机器流量，否则是用户流量。如果目的IP呈现多样性，超过指定阈值则确认为用户流量。同样还有，下载的web对象超过阈值、端口数量超过阈值等。流量分类模块可以配置为一个或多个参数。

异常检测模块进一步检测异常，从机器流量中提取信标数据，信标数据可以理解为目的IP、目的端口之类的参数，如果是HTTP连接则进一步提取GET、POST、URI。将信标数据和已知信标类型比较，确定是否异常。

 

 

上图是信标类型的高速缓存示例，异常检测模块把信标类型存在这里，然后进行比较匹配。如果匹配到，则将信标数据添加到类型中。通常恶意软件会定期和远控端发送信标，信标之间的间隙会小于指定阈值，连接请求之间的长间隙通常可以归属良性，例如定期更新应用，但这类远不如恶意软件的信标频繁。

 

在上图中，信标类型第一次出现在在时间t，第二次出现在时间（t + x）等，异常检测模块负责确定出现次数和之间的时间，如果组频率满足周期性标准，例如平均时间（平均值（x，y，z））满足指定的定时阈值，异常检测模块确定该组对应于其他组是异常。当组重复但周期性不满足时，例如平均定时（平均（x，y，z））不满足指定的定时阈值，异常检测模块确定组是否至少出现第二阈值数量，第二阈值数是否大于第一阈值数的时间，如果组发生第二次阈值，则确定为异常。如果两各周期阈值都不满足，则是良性。

 

整个过程如上图，首先流量分类模块接收流量，然后进行分组分析，分组通常根据时间段，细节接下来会说。

第三步确认这些访问是否归属在白名单，以减少误报，白名单包括IP、URI、目的端口等。如果是白名单，则不再监控。如果不是白名单，则进入第四步判断是否用户/机器流量，用户流量放过，机器流量进入异常检测。

 

分组过程图，第一步识别第一个连接请求，识别出后形成组，把这个请求添加到这个组。继续监控后续连接，确定后续连接是否满足分组标准，满足则添加到组。不满足则返回。

上图是用户/机器流量判断流程图，首先流量分析模块根据参数分析请求，然后判断是否用户流量，如果IP多样性超过阈值或下载web对象超过阈值，则判断为用户流量，用户流量停止分析返回。如果不是用户流量，则判断为机器流量。

UEBA架构设计之路10： 稀有度分析 

2019-08-05 12:00

12

鸣 谢

VSRC感谢业界小伙伴——mcvoodoo，投稿精品原创类文章。VSRC欢迎精品原创类文章投稿，优秀文章一旦采纳发布，将有好礼相送，我们已为您准备好了丰富的奖品！

（活动最终解释权归VSRC所有）

上篇引言

UEBA通过机器学习对用户、实体进行分析，不管这种威胁是不是已知，也包括了实时和离线的检测方式，能得到一个直观的风险评级和证据分析，让安全人员能够响应异常和威胁。

到底是怎样的整体架构呢？我就不再介绍了，没看过前面篇章的朋友，可以点击下面链接，去看看：

已经看过的朋友，咱继续。

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

稀有度分析

稀有度分析可以用来检测事件异常，通过计算数据特征的稀有度分数确定得分。在实际应用中，这些特征包括：流量字段的用户名、源区域、目标区域、端口、应用名、接收设备IP等。这些特征可以有高基数，例如端口号特征就具备多个值：22、20、23、25、80等。流量特征例如80端口比其他端口更频繁。

稀有度是该特征相对其他值发生概率的函数，主要考虑与该特征一样，或不太可能的值，以确定相对概率，然后计算稀有度分数，已知方法主要是delta方法。

稀有度分析也可确定多个特征的稀有度分数，特征对（X，Y）的稀有度分数表示当“Y = p”时观察到的“X = a”罕见程度，或当“X”时观察“Y = p”的罕见程度= a。例如，数据从A到B，从C到B，从D到B，，当目标区域为B时，稀有度分析可以观察源区域A的罕见程度。

稀有性分析的模型可以通过模型注册表订阅事件视图，通过事件视图模型访问流量数据，执行分析，流量中任何一个事件包括一个或多个特征，特征跟踪模块负责识别相关特征并计数，例如端口特征会多次出现，其中一些特征都有相同的端口号，第一数量事件是80，第二数量可能是20、22、23。因此特征跟踪模块存储计数和事件特征对。

稀有性确定模块确定每个特定值的稀有度分数，首先根据与特定值可能/不可能的概率来确定，概率则根据每个值总出现次数相关确定，同时从特征跟踪模块获得计数数据。

确定概率后，稀有度确定模块计算稀有度分数的概率置信区间，例如在95%处计算，稀有度分数可以是0-1之间的值，用delta方法计算置信区间，delta方法确保稀有度分数介于0和1之间。

稀有性确定模块识别特征值集合，对于特定值，稀有度确定模块确定该组值的出现次数与特定值的总和，表示为“k”。确定特征的出现总数，表示为“n”。确定稀有度分数特征值的特定值作为（k，n）的函数，例如，作为二项式（k，n）的置信区间。举例来说地理特征，从网络连接发起的IP位置，跟踪各国家出现次数：US：100，UK：30，IN：20，RU：3，CN：2，JP ：1，地理位置特征为US的事件发生了100次，稀有度确定模块将RU作为观察概率RU，CN，JP之和的罕见性，CN和JP出现的数量比RU少。因此稀有度分数确定为二项式的置信区间（k = 6且n = 156），其中k表示RU出现总和以及出现次数多于少于RU值的出现次数，n表示特征地理位置的总发生次数，RU的稀有度分数表示其他值观察值RU是罕见的。

异常检测模块基于稀有分数是否满足标准来确定异常，稀有度标准可以是得分阈值，异常计数阈值的元组，分数阈值指定稀有分数的阈值，异常计数阈值指定被识别为异常次数的阈值。如果特定值被识别为异常次数超过阈值，则异常检测模块不识别为异常。如果特定值已经发生足够的次数，也可以确定特定值不再被视为异常，因此可以动态地调整稀有度标准。

上图是用于确定事件是否异常的特征对表，事件包括特征有：事件类，也就是事件类别; UA; 设备，可以是IP、用户等。如图所示，如果上面略出的特征满足稀有性标准，则确定异常。确定稀有度可增加一些附加参数，例如异常特征对数量，事件特征对等。

上图是稀有度标准阈值，阈值包括分数阈值、特征计数阈值、异常计数阈值，参数包括稀有特征、稀有特征对和忽略。例如端口到应用的数据发送，得分阈值为0.001，特征计数阈值为1，异常计数阈值50，有特征、稀有特征对、忽略设置为空。这些阈值可被配置，如果特征大量出现被识别为异常，则系统应可动态调节阈值。

上图是根据稀有度分数确定异常的过程图。特征跟踪模块首先识别流量特征，可以是VPN，IP归属地等。第二步识别一组特征值，这个组出现概率不超过特定值的概率，也就是说，特征跟踪模块识别流量中可能和不可能值的集合，而不是特征的特定值。

第三步，稀有性确定模块确定稀有度分数，也就是该组值出现概率的函数。第四步，确定是否满足稀有度标准，满足标准则判断异常，否则返回。

确定稀有度分数的流程则是：

1. 特征跟踪模块识别一组特征值，例如前面提到的例子，特征跟踪模块确定已经发生多于或少于RU位置的集合，其次是CN和JP，特定值RU和值组CN和JP的出现之和确定为（k = 6）。
2. 特征跟踪模块确定特征的总发生次数，确定地理位置特征的出现总数，为（n = 156）。
3. 稀有度确定模块通过计算参数（k，n）的置信区间来确定稀有度分数
4. 稀有度确定模块8将RU的稀有度分数确定为参数的95％置信区间（k = 6且n = 156）。RU的稀有度分数表示相对于其他位置，观察到地理位置的发生为RU是罕见的。