今天，我們將根據最新的數據，簡要概述使用者和實體行為分析（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 中，或作為單獨的 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 天）進行分析才能定義「正常」概念。 載入一次歷史資料可以加快模型訓練速度。 使用規則可以比使用機器學習更快地識別一些有趣的案例，並使用極少量的初始資料。
- 建立動態分組和帳戶分析（服務/人員）所需的工作量在解決方案之間可能存在很大差異。
來源： www.habr.com