2015年，Gartner将UBA正式更名为UEBA（用户及实体行为分析），并于2016年将其定义为未来十大安全技术方向。此后四年中，UEBA发展迅速，大多数国外头部厂商均已完成了在UEBA方面的布局。
Gartner 2020年CC报告《Critical Capabilities for SIEM》提出：UEBA能力是SIEM成熟度的重要评价指标。
国内SIEM/SOC大厂均试图在此方向上能有所建树，期望利用新的技术手段来弥补传统安全检测方式基于特征匹配的不足，进而发现更高阶的新型未知威胁或内部违规风险。
但是国内成熟度较高的UEBA产品或者带有UEBA功能的SIEM/SOC类产品，笔者并未实际见到，往往“存在价值”远远大于“实际价值”。网上的各类宣传也仅仅停留在场景和功能上，并没有什么具体的实施案例和实施过程，更鲜有介绍实施过程中的各类问题。笔者决定用自己的实践经历，分享一些导致UEBA落地困难甚至无效的原因。
从数据分析的角度，而非产品形态的角度，可以把问题总结为三大类：第一，数据质量问题；二，场景问题；三，模型迭代问题。今天我们只谈第一个，数据质量几乎决定着一切。
1、什么企业适合做UEBA
如果需求匹配不上，大概率最后的结果就是做不成或者做出来没效果。
适合哪些企业？
首先，应当拥有相对“稳定”的内部员工；
其次，企业应该拥有较高价值的“敏感数据”；
最后，企业内部的安全规定和管理手段“落实相对困难”，企业有很明确的防范“信息泄漏”、“数据篡改”、“职权滥用”等实际的需求。
简单来说客户的关键诉求必须是“发现异常的人和发现人的异常”。
判断客户有没有实现UEBA的基础，首先企业本身就应该已经具备完整且健全的身份认证和权限控制体系，其次企业应借助原有的安全能力，例如IAM\\\\4A、ICG\\\\NBM、零信任认证体系等一系列以人为核心的管理工具,这些管理工具所记录的用户数据是UEBA最有价值的输入。
2、好的数据来源
什么是好的数据？没数据，一切都是美好的想象，没有好的数据会让你实现UEBA的道路异常艰难甚至完全无效。
首先，IAM\\\\4A、ICG\\\\NBM，这类成熟“身份认证和访问管理”类工具是最好的数据来源，因为他们的数据都是以“人”为核心，每条记录都能定位到具体的人，而不是一个IP、一台主机、一个账号。成熟的DLP系统能够完整的记录文档数据的流转和操作，往往也能定位到具体的人，这对于想用UEBA技术去应对“数据泄漏”“数据窃取”“越权操作”等问题，是最好的数据来源。
其次，各应用系统自身的访问操作记录也是好的数据来源，目标清晰、噪音少，访问记录、操作记录清晰可见，无需人工去分辨。
最后，最差的数据来源就是网络流量日志和主机日志。因为难以准确分辨出哪些是人的行为，哪些是业务行为，即便区分开来，也难以定位到一个具体的人，往往你的研究对象就会被迫从一个“人”变成了一个IP或一台主机。那么最后做出来的是什么？还是用户及实体行为分析吗？单纯数据处理和人工降噪就是一个不小的课题，至于网上大量文章宣传基于网络流量日志简简单单利用几种机器学习算法就做出各种场景的案例，其可信程度还有待商榷。
3、用户和实体的定位
谁是用户？谁是实体？这个问题，如果解答不了，直接动摇UEBA的根基。你都不知道你分析的对象是谁，你分析出来的结果会是什么？
上个问题我们已经提到好的数据来源能帮助你定位用户，排除噪音，把分析师的精力集中在数据分析上而不是数据处理上，但很多时候你只能拿到最糟糕的数据去做一件“容不得半点沙子”的事情，那结果可想而知。
假设你只能用网络流量日志去做UEBA，那么“U”和“E”怎么定位，谁是用户？谁是实体？谁是需要关注的？谁是不需要关注的？这种问题，只有完全了解业务和资产的客户才能答复你，没有别的更好办法。此时，数据治理专家需要做大量的日志富化工作，将已知的用户信息、资产或业务信息与网络流量中的IP地址做映射，以增强日志的可分析性。至于什么人工智能自动识别，我不敢说不可能，我只能说没见过。
4、VPN、NAT地址转换问题规避
你确定你以为的“用户”和“实体”不会变吗？
一个典型的场景，如果企业内部用户允许使用VPN账号，那么用户IP就会被随机分配，而不是固定的，业务系统的访问记录也会变得无章可循，此时我的内心是几乎崩溃的，因为无法统计这些“用户”的在长周期内的历史基线，除非VPN日志的质量极高，每条记录都能够准确记录具体的“人”而不是IP，否则你要不停的映射IP和人的关系，然而市面上多数VPN日志也最多只能关联到分配IP和登录源IP的关系，依然没有记录到“人”。还有对于负载均衡、NAT的情况，也是类似，很难定位到“实体”到底是谁。
一旦遇到类似情况，数据治理专家，往往需要通过IP分配关系动态表去做“实时映射”对日志进行“动态富化”，这无疑会增加技术门槛、工作量、同时也提高了出错率，抬高了实施成本，需尽量避开这类日志作为UEBA的数据来源。
5、漏扫及其他安全设备的噪音过滤
你真的清楚噪音的全部来源吗？
有些噪音可能是致命的，当你的UEBA训练模型在跑着统计算法时，来一个漏扫在内网中进行了一次“例行检查”，制造了各种爆破、探测、上传文件的操作，这些无效数据都会默默的记录到你的统计模型中，导致你的模型失真，例如常见的登录频次、访问频次、时间段、流量大小、文件传输规律等等，这些结果都会严重偏离实际的人为基线。应将此类数据进行过滤，避免混入训练数据，影响训练结果。还包括各种传统安全设备，例如准入系统、终端安全、网检等等都可能会与交换机、终端，进行频繁的交互和连接，会产生大量的“背景数据”，一旦学习过程混入这些“脏数据”，也无法得到理想的结果。如果想做好这些数据清洗工作，减少噪音的干扰，又取决于你对企业IT资产的可见性和对业务的了解。
所以安全圈流行的一句话“不懂业务，就不可能懂安全”现在想想，也不无道理。
6、无效访问数据过滤
无效的WEB访问和响应记录，需要计算吗？
对于用户WEB访问请求、应用系统的响应日志， 流量往往存在特征为响应码 = 404、500、0，TCP标记为TMO，上、下行字节数 = 0 等代表着无效访问、无响应、被阻断、连接超时等无效数据，话不多说，通通应该被过滤掉。这些细节的把握粒度，往往决定着最终的模型精度，如果不能考虑周全，那么基线结果的失真和严重的告警误报一定会教你重新做人。怎么定义“无效数据”并没有什么好的“参考书”，都是反复的试错换来的经验教训。
7、非活跃时间段及假期日排除
非活跃时间段的数据或者假期数据应该被计算到模型里吗？
非活跃时间段甚至假期时段的用户操作或应用的受访问频次往往大幅低于正常值，这段时间内的数据如果被平均，势必严重拉低基线结果平均值，导致模型的失真，进而产生大量的误报。对于这种情况，数据治理专家也需要提前设定好训练数据的“可用时间范围”，例如“非活跃时间段”定义为每天凌晨，这部分的数据不计入训练数据，或进行单独计算单独比较，还要考虑正常的双休日及每年的法定节假日的业务数据应被自动过滤掉，不纳入训练数据集，或进行单独计算单独比较，以此来进一步提升模型的精准度和异常行为发现的可信度。
8、数据断流监控
你确定你的数据源会兢兢业业的给你持续发送全量数据吗？
如果上述7个问题对你来说都不是问题，那么你一定具备好的数据来源，不用费这么大劲去做数据治理或者你已经是一位成功的数据治理专家了，但是还有一个问题会被大多数人忽视——数据断流。
千辛万苦做好的数据治理流程和统计算法，想不到源头上出了鬼，设备发送的数据突然停发了或者暂时断流了几小时又恢复了，都会导致你的基线结果失真。这种“停发”和“断流”的情况，就必须做好实时监控和风险提示，还有一种更难得“节流”问题，或许就很难发现了。例如数据源原本记录1000名用户的行为日志，但是从某个时间点起突然莫名丢失掉了其中200名用户的行为日志，这就很难发现了，但带来的问题依然是模型失真进而引发误报严重，并且只是少部分用户的失真，这就非常难以发现，往往还要监控数据量的变化趋势是否正常。
所以，一个优秀成熟的UEBA产品必须要严格监控它最重要的输入——日志，无论是停发、断流还是难以发现的节流，都必须做到有效的监控并且第一时间进行风险提示，否则上述的全部工作都会白费。
9、结语
本文从数据层面介绍了影响UEBA落地的若干影响因素，每一个不利因素带来的负面影响都可能导致最终的实践效果不佳，需要数据治理工程师精心的“调教”，才能把好数据质量这道关。
如果说数据是精细甄选的“食材”，那么场景就是“菜谱”，是UEBA的“魂”。场景直接决定了该用什么数据，该用什么算法，以及如何迭代等一系列问题。下一篇，我将介绍UEBA的典型应用场景及方案，敬请期待。
关于作者
GoldMan，虎符智库特约作者，奇安信NGSOC威胁建模团队成员，研究方向为 Windows域安全、账号安全、UEBA、ATT&CK擅长构建用户异常行为分析模型，长期从事威胁建模工作，协助企业发现用户违规和异常行为等内部威胁。
声明：本文来自安全内参，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
