深扒：基于 UEBA 的数据使用安全防护

伴随企业业务的不断扩增和电子化发展，企业自身数据和负载数据都开始暴增。然而，作为企业核心资产之一的内部数据，却面临着日益严峻的安全威胁。调查显示，约有 75%的安全威胁是从组织内部发起的。无论是离职员工顺走专利数据，还是心怀怨恨的员工蓄意破坏系统，一再发生的各种安全事件证明，攻破堡垒的最容易的方式往往来自内部威胁。

面对这种威胁，内外双向的安全需求催生了用户实体行为分析（User and Entity Behavior Analytics，UEBA）。对内，传统威胁防御手段不足。对于已经意识到问题紧迫性的企业而言，使用传统的安全技术并未能帮助他们有效解决来自内部的安全问题。

当前，用户实体行为分析(User and Entity Behavior Analytics，UEBA)正作为一种新兴的异常用户检测体系在逐步颠覆传统防御手段，开启网络安全保卫从“被动防御”到“主动出击”的新篇章。本文主要介绍极盾·觅踪如何利用 UEBA 技术在企业的异常用户检测中发挥功能。

作为一种高级网络威胁检测手段，UEBA 是基于大数据驱动、以用户为核心、关联实体资产、采用机器学习算法进行异常分析以发现解决内部威胁的一套框架和体系。相较于传统手段对安全事件的关注，UEBA 更关心人，通过用户画像和资产画像，检测诸如账号失陷、数据泄漏、权限滥用等⻛险，以极高的准确率定位异常用户。 

1.   用户实体的关联

UEBA 属于数据驱动的安全分析技术, 因此, 需要关联大量的用户特征数据。极盾·觅踪只需要简单的配置就可以关联同一个员工在不同系统之间的行为，并且还可以补充组织架构信息，设备信息等, 为数据分析提供更加丰富的特征，如图 1 所示。 

图 1

除此之外, 极盾·觅踪也能自动补充用户的设备特征, 如图 2 所示, 这些都可以作为 UEBA 分析过程中的用户特征。

图 2

2.  行为特征提取

一个低⻛险用户的正常业务活动通常不需要关注，但是一些高⻛险账号的正常操作或者低⻛险账号进行的高危操作则足以值得调查人员关注，更近一步，如果一个高⻛险账号做了一些高危并且不常出现的动作，那就绝对需要安全人员介入调查了。

那么，我们如何界定一个用户⻛险等级是高还是低？

这便是 UEBA 及其算法要解决的核心问题，通过建立动态行为基线发现用户偏离正常模式的行为，并根据⻛险累计的数值判断用户⻛险级别。因此，用户行为特征提取是整个用户行为分析建模的基础，需要结合业务实际需求，找出相关的用户行为，形成符合业务实际情况的建模体系。

大部分情况下, 相比算法层面的精进，有效提取数据特征经常会取得更直接的收益，能够展现数据的基本属性和业务逻辑的特性，甚至仅需要使用简单的模型就能取得很好的结果，而冗余的不相关特征不仅无益于建模，除了会增加模型的复杂度之外，还会降低分析速度。在特征提取的设计中, 过往经验至关重要, 可以帮助分析人员快速建立有效的模型，但是在实际情况中总会遇到一些陌生的场景，缺少经验知识，这时逻辑和方法论显得更为普适。

极盾·觅踪能够自动捕捉一些通用敏感行为, 为异常行为分析提供丰富的特征。如图 3 所示, 极盾·觅踪能够自动识别用户浏览的数据中是否包含手机号, 身份证号等敏感信息, 也能捕捉是否存在复制行为，是否存在文件下载行为等。

图 3

通常有 3 类通用的维度来提取用户行为特征，分别是用户与用户之间行为基线的对比、用户组与用户组之间行为基线的对比、基于用户自身行为基线对比的数据特征提取。

下面以 CRM 系统为例举例说明。

l  用户与用户之间行为基线的对比 

CRM 中有公司现有的客户以及客户的联系方式，这是公司的核心数据通常，我们认为每个用户对客户以及客户的查询次数不应该超过某一个阈值，而这个阈值就由所有用户的行为习惯来决定，因为定的太低，会影响用户的正常使用，而定的太高，容易导致数据泄漏而不自知。

图 4 为某公司的 CRM 系统中用户每天查询客户联系方式的最大次数，由图中可⻅，用户每天查询的客户联系方式次数从 0~10+不等，我们通过核密度估计（Kernel Density Estimation，KDE）计算每天用户请求客户联系方式的概率密度，将概率异常低的点设置为阈值，高于这个阈值，就属于异常查询。使用这种方式可以满足绝大部分的需求, 虽然在实际使用中可能有小部分情况下，需要超过这个阈值，但是我们认为这样做可以较好的兼顾安全与实用。 

图 4

使用核密度函数把它转换为请求次数的概率分布，如下图所示。

图 5

如图中所示，只有在非常小概率的情况下，用户一天需要请求客户联系方式的次数会大于 11，因此我们可以将 11 设置为最大请求次数的阈值，防止数据泄露。 

l  基于用户自身行为基线对比 

还是以 CRM 系统中查询客户联系方式为例，虽然整体上，我们选择了一个较高的值(11，这是所有用户的最高值)作为阈值，但是这并不代表每个用户查询 11 次都属于正常行为，因为很多用户每天只需要查询 3 次以下，这和个人习惯有关。那么当本来只查询 3 次以下的用户突然查询了 9 次时，也是值得关注的事件，这个员工可能要离职或者出于某种目的要窃取数据。 

图 6 为某公司的 CRM 系统的用户, 每天使用该系统查询客户手机号的个数（以三个用户为例）。

图 6

如图中所示, 用户 19 每天查询客户联系方式的请求次数一般在 0~3 次之间, 那么当有一天突然请求了 10 次时,就属于明显的偏离用户自身轨迹的行为, 值得调查人员关注。

针对这种情况,我们可以将用户 ID 和每天查询的次数为特征，针对每个用户的个人习惯进行异常检测，找出偏离个人行为轨迹的异常行为。

l  用户组与用户组之间行为基线的对比 

一般而言，相同⻆色（例如同一个部⻔的员工）之间的行为具有比较多的相似性，而不同⻆色之间行为上可能会出现较大的差异。反应到系统上，就是系统登录事件，访问的⻚面，访问的时⻓等都会有所不同。 

图 7 为某公司的 CRM 系统的用户在登录时间和系统停留时⻓上的散点图。蓝点代表销售，⻩点代表商务人员。由图中可⻅，销售人员更加偏向于每天的早上和晚上访问 CRM 系统， 而商务人员的访问时间则更加集中在 9~18 点之间。这是符合现实逻辑的，销售人员会在早上查看今天要联系的客户, 以及在晚上录入与客户的进展, 而商务人员的工作更加集中在上班时间处理合同, 汇款等问题。

图 7

针对这种情况, 我们就可以通过⻆色,登录时间和登录时⻓这三个特征进行建模, 当用户在非常用时间登录，或者在系统停留的时间异常时, 都属于偏离正常行为轨迹，应该进行异常告警。

除了员工主动的数据窃取之外, 当员工账号被盗时, 也可以利用员工自身的行为习惯来进行异常检测。例如用户 A 通常 1 分钟内访问 2~3 个⻚面, 但是突然之间访问了 30+⻚面, 这就与正常的行为有明显的偏移，具体的建模方式此处不再赘述。 

当然，UEBA 产品并不依赖某个"银弹", 并不是某一个单一的异常点就可以确定一次数据泄漏事件, 以上例子只是为了举例说明，最终必定是一系列异常行为的有机融合。