今天，我们将根据最新的数据，简要概述用户和实体行为分析（UEBA）市场 。 根据 Gartner 面向威胁技术的技术成熟度曲线，UEBA 市场正处于“幻灭阶段”的底部，表明该技术已经成熟。 但矛盾的是，UEBA技术投资的普遍增长与独立UEBA解决方案市场的消失同时发生。 Gartner预测UEBA将成为相关信息安全解决方案功能的一部分。 “UEBA”一词可能会不再使用，并被另一个专注于较窄应用领域（例如“用户行为分析”）、类似应用领域（例如“数据分析”）的首字母缩写词所取代，或者只是成为一些新的流行词（例如，术语“人工智能”[AI] 看起来很有趣，尽管它对现代 UEBA 制造商来说没有任何意义）。
Gartner 研究的主要结果可总结如下：
- 用户和实体行为分析市场的成熟性可以通过以下事实得到证实：大中型企业部门使用这些技术来解决许多业务问题；
- UEBA 分析功能内置于各种相关信息安全技术中，例如云访问安全代理 (CASB)、身份治理和管理 (IGA) SIEM 系统；
- UEBA供应商的炒作以及对“人工智能”术语的错误使用，使得客户在不进行试点项目的情况下很难理解制造商的技术和解决方案功能之间的真正差异；
- 客户指出，即使仅考虑基本的威胁检测模型，UEBA 解决方案的实施时间和日常使用也可能比制造商承诺的更加耗费人力和时间。 添加自定义或边缘用例可能非常困难，并且需要数据科学和分析方面的专业知识。
战略市场发展预测：
- 到 2021 年，用户和实体行为分析 (UEBA) 系统市场将不再作为一个单独的领域存在，并将转向具有 UEBA 功能的其他解决方案；
- 到 2020 年，所有 UEBA 部署的 95% 将成为更广泛的安全平台的一部分。
UEBA解决方案的定义
UEBA 解决方案使用内置分析来评估用户和其他实体（例如主机、应用程序、网络流量和数据存储）的活动。
它们检测威胁和潜在事件，通常代表与相似群体中的用户和实体在一段时间内的标准配置文件和行为相比的异常活动。
企业领域最常见的用例是威胁检测和响应，以及对内部威胁（主要是受感染的内部人员；有时是内部攻击者）的检测和响应。
UEBA就像 决定和 按功能划分，内置于特定工具中：
- 解决方案是“纯”UEBA 平台的制造商，包括也单独销售 SIEM 解决方案的供应商。 专注于用户和实体行为分析中的广泛业务问题。
- 嵌入式 – 将 UEBA 功能和技术集成到其解决方案中的制造商/部门。 通常专注于一组更具体的业务问题。 在这种情况下，UEBA 用于分析用户和/或实体的行为。
Gartner 从三个轴看待 UEBA，包括问题解决者、分析和数据源（见图）。
“纯”UEBA 平台与内置 UEBA
Gartner 认为“纯”UEBA 平台是以下解决方案：
- 解决几个具体问题，例如监控特权用户或向组织外部输出数据，而不仅仅是抽象的“监控异常用户活动”；
- 涉及复杂分析的使用，必须基于基本分析方法；
- 提供多种数据收集选项，包括内置数据源机制和日志管理工具、数据湖和/或 SIEM 系统，而无需在基础设施中部署单独的代理；
- 可以作为独立解决方案购买和部署，而不是包含在
其他产品的组成。
下表对这两种方法进行了比较。
表 1.“纯”UEBA 解决方案与内置解决方案
| 类别 | “纯”UEBA 平台 | 其他内置 UEBA 的解决方案 |
| 待解决的问题 | 用户行为和实体分析。 | 数据的缺乏可能会限制 UEBA 只能分析用户或实体的行为。 |
| 待解决的问题 | 旨在解决广泛的问题 | 专门从事有限的任务 |
| Google Analytics（分析） | 使用各种分析方法进行异常检测 - 主要通过统计模型和机器学习，以及规则和签名。 配备内置分析功能，可创建用户和实体活动并将其与他们和同事的个人资料进行比较。 | 与纯 UEBA 类似，但分析可以仅限于用户和/或实体。 |
| Google Analytics（分析） | 先进的分析能力，不仅仅受到规则的限制。 例如，具有动态分组实体的聚类算法。 | 与“纯”UEBA 类似，但某些嵌入式威胁模型中的实体分组只能手动更改。 |
| Google Analytics（分析） | 用户和其他实体的活动和行为的关联（例如，使用贝叶斯网络）以及个人风险行为的聚合，以识别异常活动。 | 与纯 UEBA 类似，但分析可以仅限于用户和/或实体。 |
| 数据源 | 通过内置机制或现有数据存储（例如 SIEM 或数据湖）直接从数据源接收有关用户和实体的事件。 | 获取数据的机制通常只是直接的，并且仅影响用户和/或其他实体。 不要使用日志管理工具/SIEM/数据湖。 |
| 数据源 | 该解决方案不应仅依赖网络流量作为主要数据来源，也不应仅依赖其自身的代理来收集遥测数据。 | 该解决方案可以仅关注网络流量（例如，NTA - 网络流量分析）和/或在终端设备上使用其代理（例如，员工监控实用程序）。 |
| 数据源 | 让用户/实体数据充满上下文。 支持实时收集结构化事件，以及来自 IT 目录（例如 Active Directory (AD) 或其他机器可读信息资源（例如 HR 数据库））的结构化/非结构化内聚数据。 | 与纯 UEBA 类似，但上下文数据的范围可能因情况而异。 AD 和 LDAP 是嵌入式 UEBA 解决方案最常用的上下文数据存储。 |
| 可用性 | 作为独立产品提供列出的功能。 | 如果不购买内置 UEBA 功能的外部解决方案，就不可能购买内置 UEBA 功能。 |
| 资料来源：Gartner（2019 年 XNUMX 月） |
因此，为了解决某些问题，嵌入式 UEBA 可以使用基本的 UEBA 分析（例如，简单的无监督机器学习），但同时，由于能够访问所需的数据，因此总体上比“纯”UEBA 更有效UEBA 解决方案。 与此同时，与内置 UEBA 工具相比，“纯”UEBA 平台正如预期的那样提供更复杂的分析作为主要技术。 这些结果总结于表 2 中。
表2.“纯”和内置UEBA之间的差异结果
| 类别 | “纯”UEBA 平台 | 其他内置 UEBA 的解决方案 |
| Google Analytics（分析） | 解决各种业务问题的适用性意味着一组更通用的 UEBA 功能，重点是更复杂的分析和机器学习模型。 | 专注于较小的业务问题意味着高度专业化的功能，专注于具有更简单逻辑的特定于应用程序的模型。 |
| Google Analytics（分析） | 每个应用场景都需要定制分析模型。 | 分析模型是为内置 UEBA 的工具预先配置的。 内置 UEBA 的工具通常可以更快地解决某些业务问题。 |
| 数据源 | 从公司基础设施的各个角落访问数据源。 | 数据源较少，通常受到代理的可用性或具有 UEBA 功能的工具本身的限制。 |
| 数据源 | 每个日志中包含的信息可能受到数据源的限制，并且可能不包含集中式UEBA工具的所有必需数据。 | 代理收集并传输到UEBA的原始数据的数量和细节可以具体配置。 |
| 建筑 | 它是一个针对组织的完整 UEBA 产品。 使用 SIEM 系统或数据湖的功能可以更轻松地进行集成。 | 每个具有内置 UEBA 的解决方案都需要一组单独的 UEBA 功能。 嵌入式 UEBA 解决方案通常需要安装代理和管理数据。 |
| 积分 | 在每种情况下，手动将 UEBA 解决方案与其他工具集成。 允许组织基于“同类最佳”方法构建其技术堆栈。 | UEBA 功能的主要包已由制造商包含在工具本身中。 UEBA模块是内置的，无法拆卸，因此客户无法用自己的东西替换它。 |
| 资料来源：Gartner（2019 年 XNUMX 月） |
UEBA 作为一个函数
UEBA 正在成为端到端网络安全解决方案的一项功能，可以从额外的分析中受益。 UEBA 是这些解决方案的基础，提供基于用户和/或实体行为模式的强大的高级分析层。
目前市场上，内置 UEBA 功能在以下解决方案中实现，按技术范围分组：
- 以数据为中心的审计和保护，是专注于提高结构化和非结构化数据存储（又名 DCAP）安全性的供应商。
Gartner 指出，在此类供应商中，除其他事项外， ，它提供用户行为分析来监控不同信息存储中非结构化数据权限、访问和使用的变化。
- CASB系统，通过使用自适应访问控制系统阻止不需要的设备、用户和应用程序版本对云服务的访问，提供针对基于云的 SaaS 应用程序中的各种威胁的保护。
所有市场领先的 CASB 解决方案都包含 UEBA 功能。
- DLP 解决方案 – 重点检测关键数据在组织外部的传输或滥用。
DLP 的进步主要基于对内容的理解，较少关注对用户、应用程序、位置、时间、事件速度和其他外部因素等上下文的理解。 为了有效，DLP 产品必须识别内容和上下文。 这就是为什么许多制造商开始将 UEBA 功能集成到他们的解决方案中。
- 员工监控 是记录和重播员工行为的能力，通常采用适合法律诉讼的数据格式（如果需要）。
持续监控用户通常会产生大量数据，需要手动过滤和人工分析。 因此，UEBA 用于监控系统内部，以提高这些解决方案的性能并仅检测高风险事件。
- 端点安全 – 端点检测和响应（EDR）解决方案和端点保护平台（EPP）提供强大的仪器和操作系统遥测
终端设备。可以分析此类与用户相关的遥测数据以提供内置 UEBA 功能。
- 网络诈骗 – 在线欺诈检测解决方案可检测异常活动，这些活动表明通过欺骗、恶意软件或利用不安全连接/浏览器流量拦截对客户帐户造成危害。
大多数欺诈解决方案都使用 UEBA、交易分析和设备测量的本质，并通过更先进的系统通过匹配身份数据库中的关系来补充它们。
- IAM 和访问控制 – Gartner 指出门禁系统供应商的发展趋势是与纯粹的供应商集成，并将一些 UEBA 功能内置到他们的产品中。
- IAM 和身份治理和管理 (IGA) 系统 使用UEBA覆盖行为和身份分析场景，例如异常检测、相似实体的动态分组分析、登录分析和访问策略分析。
- IAM 和特权访问管理 (PAM) – 由于监控管理帐户的使用情况，PAM 解决方案具有遥测功能，可显示管理帐户的使用方式、原因、时间和地点。 可以使用 UEBA 的内置功能来分析这些数据，以确定是否存在管理员的异常行为或恶意意图。
- 制造商 NTA（网络流量分析） – 结合使用机器学习、高级分析和基于规则的检测来识别企业网络上的可疑活动。
NTA 工具不断分析源流量和/或流记录（例如 NetFlow）以构建反映正常网络行为的模型，主要侧重于实体行为分析。
- SIEM – 许多 SIEM 供应商现在都将高级数据分析功能内置到 SIEM 中，或作为单独的 UEBA 模块。 正如文章中所讨论的，从 2018 年到 2019 年迄今为止，SIEM 和 UEBA 功能之间的界限不断模糊 。 SIEM 系统已经变得更擅长分析并提供更复杂的应用场景。
UEBA应用场景
UEBA 解决方案可以解决广泛的问题。 然而，Gartner 客户一致认为，主要用例涉及检测各种类别的威胁，这是通过显示和分析用户行为与其他实体之间的频繁关联来实现的：
- 未经授权的数据访问和移动；
- 特权用户的可疑行为、员工的恶意或未经授权的活动；
- 云资源的非标准化接入和使用；
- 等等
还有许多非典型的非网络安全用例，例如欺诈或员工监控，UEBA 可能是合理的。 然而，他们通常需要 IT 和信息安全之外的数据源，或者对该领域有深入了解的特定分析模型。 UEBA制造商及其客户一致同意的五个主要场景和应用如下所述。
“恶意内部人士”
涵盖此场景的 UEBA 解决方案提供商仅监控员工和受信任承包商的异常、“不良”或恶意行为。 该专业领域的供应商不会监视或分析服务帐户或其他非人类实体的行为。 很大程度上正因为如此，他们并不专注于检测黑客接管现有帐户的高级威胁。 相反，它们的目的是识别参与有害活动的员工。
从本质上讲，“恶意内部人员”的概念源于具有恶意意图的受信任用户，他们寻求对雇主造成损害的方法。 由于恶意意图很难衡量，因此此类中最好的供应商会分析审计日志中不易获得的上下文行为数据。
该领域的解决方案提供商还可以最佳地添加和分析非结构化数据，例如电子邮件内容、生产力报告或社交媒体信息，以提供行为背景。
受损的内部威胁和侵入性威胁
面临的挑战是，一旦攻击者获得对组织的访问权限并开始在 IT 基础设施内移动，如何快速检测和分析“不良”行为。
断言威胁 (APT) 与未知或尚未完全理解的威胁一样，极难检测，并且通常隐藏在合法用户活动或服务帐户后面。 此类威胁通常具有复杂的操作模型（例如，参见文章“”）或他们的行为尚未被评估为有害。 这使得使用简单的分析（例如通过模式、阈值或关联规则进行匹配）来检测它们变得困难。
然而，许多这些侵入性威胁会导致非标准行为，通常涉及毫无戒心的用户或实体（也称为受损的内部人员）。 UEBA 技术提供了一些有趣的机会来检测此类威胁、提高信噪比、整合和减少通知量、确定剩余警报的优先级以及促进有效的事件响应和调查。
针对此问题领域的 UEBA 供应商通常与组织的 SIEM 系统进行双向集成。
数据泄露
本例中的任务是检测数据正在组织外部传输的事实。
专注于这一挑战的供应商通常利用具有异常检测和高级分析功能的 DLP 或 DAG 功能，从而提高信噪比、整合通知量并确定剩余触发器的优先级。 对于其他上下文，供应商通常更加依赖网络流量（例如 Web 代理）和端点数据，因为对这些数据源的分析可以帮助进行数据泄露调查。
数据泄露检测用于捕获威胁组织的内部和外部黑客。
特权访问的识别和管理
该专业领域的独立UEBA解决方案制造商在已经形成的权利体系的背景下观察和分析用户行为，以识别过度特权或异常访问。 这适用于所有类型的用户和帐户，包括特权帐户和服务帐户。 组织还使用 UEBA 来摆脱休眠帐户和高于所需权限的用户权限。
事件优先级
此任务的目标是对技术堆栈中的解决方案生成的通知进行优先级排序，以了解应首先解决哪些事件或潜在事件。 UEBA 方法和工具可用于识别对给定组织来说特别异常或特别危险的事件。 在这种情况下，UEBA 机制不仅使用基本级别的活动和威胁模型，而且还使用有关公司组织结构的信息（例如，关键资源或角色以及员工的访问级别）来填充数据。
UEBA解决方案的实施问题
UEBA解决方案的市场痛点在于其高昂的价格、复杂的实施、维护和使用。 虽然公司正在努力应对不同内部门户的数量，但他们正在获得另一个控制台。 在新工具上投入的时间和资源的大小取决于手头的任务以及解决这些任务所需的分析类型，并且通常需要大量投资。
与许多制造商声称的相反，UEBA 并不是一个可以连续运行数天的“设置好后就忘记它”的工具。
例如，Gartner 客户指出，从头开始启动 UEBA 计划需要 3 到 6 个月的时间才能获得解决该解决方案所针对的问题的初步结果。 对于更复杂的任务，例如识别组织中的内部威胁，该期限会增加到 18 个月。
影响UEBA实施难度以及该工具未来有效性的因素：
- 组织架构、网络拓扑和数据管理策略的复杂性
- 以正确的详细程度提供正确的数据
- 供应商分析算法的复杂性 - 例如，统计模型和机器学习的使用与简单模式和规则的比较。
- 包括预配置分析的数量，即制造商对每项任务需要收集哪些数据以及哪些变量和属性对于执行分析最重要的理解。
- 制造商自动集成所需数据是多么容易。
例如：
- 如果UEBA解决方案使用SIEM系统作为其数据的主要来源，那么SIEM是否从所需的数据源收集信息？
- 必要的事件日志和组织上下文数据是否可以路由到 UEBA 解决方案？
- 如果SIEM系统还没有收集和控制UEBA解决方案所需的数据源，那么如何将它们传输到那里呢？
- 应用场景对于组织来说有多重要，需要多少数据源，以及这项任务与制造商的专业领域有多少重叠。
- 需要何种程度的组织成熟度和参与度——例如，规则和模型的创建、开发和完善； 为评估变量分配权重； 或调整风险评估阈值。
- 与组织当前的规模及其未来的需求相比，供应商的解决方案及其架构的可扩展性如何。
- 是时候构建基本模型、配置文件和关键组了。 制造商通常需要至少 30 天（有时长达 90 天）进行分析才能定义“正常”概念。 加载一次历史数据可以加快模型训练速度。 使用规则可以比使用机器学习更快地识别一些有趣的案例，并使用极少量的初始数据。
- 构建动态分组和帐户分析（服务/人员）所需的工作量在解决方案之间可能存在很大差异。
来源： habr.com