揭秘威胁情报如何护航企业

可在文末扫码加小助手进群交流哦~

阅读原文

跳转微信打开

本文目录

        一、背景挑战

        二、算法介绍

           2.1 整体思路

           2.2 正样本筛选

               2.2.1 特征构造

               2.2.2 孤立森林

           2.3 算法介绍

               2.3.1 VAE

               2.3.2 GANomaly

        三、文末总结

1. 真实异常样例少，由于内部员工越权访问涉密数据或者账号失陷用户攻击是小概率事件，可获取的真实异常事件样本极少; 正、负样本数量极不平衡，历史日志中绝大部分都是正常行为的数据，异常数据所占比例很小，不足以准确描绘异常的特征，无法直接从数据中学到所有异常的特性；

2. 数据标注困难：数据缺少标签，人工标记成本高，可操作性低；

3. 攻击模式不确定：为了规避检测，攻击者可能会将其恶意的行为隐藏在正常的行为中，不易发现; 攻击策略没有固定模式，无法事先预知。

       有监督的方法依赖于准确标注好的数据集进行模型训练，需要充足的正、负样本，然而由于存在如前所述的”三大挑战“，有监督的方法无法发挥作用。因此，我们探索了一些无监督方法在UEBA中进行落地尝试，即VAE和GAN。相比于以往的异常检测方法，这些方法能捕捉用户的动态行为变化，能提高实际应用中的检测准确性。将样本的多维度特征进行评定，可以批量分析账户的异常行为，有助于自适应的持续算法优化。

       实际场景中多数是一些时序数据，需要通过算法的设计自动识别出海量日志数据中的异常样本。此外，场景中往往要检测实体的异常行为，并按其偏离程度排序，便于企业安全管理人员按优先级核实跟踪处理这些异常行为。在UEBA中，很多场景都会用到无监督方法的预测、检测的相关技术，例如：

• 针对主机安全、VPN、OA等日志，检测某个账号在主机或服务器的操作异常，如文件传输数据量是否异常、登录或访问行为等是否异常
  

• 针对数据库审计日志，检测已授权用户对数据库访问是否异常，如越权访问、已授权数据的恶意更改、滥用或泄露行为

• 针对堡垒机、WEB应用防护等日志，检测某个用户或账号访问的内网资源、API数量等是否有行为异常

2.1 整体思路

        VAE和GANonaly这两个模型做异常检测的假设都是一样的，即假定正常数据是服从某一种分布的，而异常数据是不能够拟合进这个分布，因此我们可以用VAE和GANomaly找到正常数据的分布，从而用这个分布来做异常检测。

       无监督学习是为了直接学习数据的分布，而不需要使用结果或者标签，其学习的是特征之间的关系，因此常被用于降维和聚类。由3.1节可知， 我们首先需要筛选一些靠谱的正样本，这里选择孤立森林进行区分。其次，为更好的了解特征间的关系，读者可以使用协方差矩阵分析特征之间的相关度，并通过热力图可视化查看，关联度低的特征可以屏蔽掉。‍‍‍如有需要可额外自行构造一些有效特征。

        热力图反映了数据本身的特征与其他构造特征的相关系数。颜色越深代表两个特征间呈强负相关，颜色越浅（淡白色）则两个特征之间呈强正相关。   

2.2.1  特征构造

        特征构造需要结合相应的安全场景进行分析，最好能明确企业的网络拓扑结构，办公网和生产网检测场景各有侧重点。针对账号登录、资源的访问等，根据时间，ip，部门等特征进行定义。比如可以人工定义一些基于时间的威胁等级特征。

       在实际的业务场景中，员工ID在非工作时间段的行为本身存在一定危险系数，比如存在身份ID被盗用的可能。可以指定凌晨1点~凌晨5点为高危时段。其次，基于群组标签也可以进行相关统计，账号使用过程中常用登录设备、常用访问资源、常用登录地点等，这些特征可以很好的辅助用户实体画像的构建和异常行为的检测。

2.2.2  孤立森林

        孤立森林（Isolation Forest）基于 Ensemble 的异常检测方法，凭借其线性的时间复杂度且精准度较高，在处理大数据时速度快，所以被广泛应用于工业界中结构化数据的异常检测。常见的场景包括：网络安全中的攻击检测、金融交易欺诈检测、疾病侦测、噪声数据过滤（数据清洗）等。

孤立森林的使用需要有一些理论基础：

    1、异常数据占总样本量的比例很小；

    2、异常点的特征值与正常点的差异很大。

       由于算法的设计，孤立森林有以下优点。由于每棵树都是独立的，因此在分布式的系统中加速计算；此外不同于聚类算法找到异常点，它不需要计算点与点之间的距离或者簇的密度，模型为线性时间的复杂度，速度快，系统开销小。

Tips：

1、训练样本中异常样本的比例不宜过高，可能会导致最终结果不理想，因为这违背了该算法的理论基础。因此，其适用于UEBA中常用户行为的检测。

2、训练样本特征维度不宜过高，因为当树的样本量确定之后，树的高度确定了。当样本维度较高时，会存在建完树之后仍有大量的特征信息未被使用，从而导致了算法的准确性。并且高维样本空间中可能会存在一些无关的维度或者噪音维度，这些也会对树的构建产生影响。因此在使用孤立森林前，需要对业务数据中一些噪音或无效特征进行甄别和过滤。

2.3 算法介绍

2.3.1  VAE（Variational Autoencoder)

       VAE是变分自编码器的简称，该模型最开始提出的目的是为了找到训练数据的分布，从而用这个分布来生成数据。从另一个角度而言，如果我们能够找到正常数据的分布，那么我们就可以用这个分布来做异常检测。

1. 先用正常样本去训练VAE模型

2. 输入测试集给VAE，获得重构的测试集数据

3. 计算重构的数据和原始数据的误差，若重构误差大于某个阈值，则认为样本异常   

2.3.2 GANomaly

2.3.3 经验杂谈

       GANomaly和VAE这两者都可以用来做行为异常检测，也都是基于训练数据的分布，但是原生的VAE的鲁棒性比原始的GAN更好，而GAN在调优之后效果比VAE更好。同时，对于模型解码得到的结果需要和初始数据进行相似度计算，得到数据的异常得分。

当然基于VAE模型在工业界使用中也面临着一些问题：

• 运算资源的消耗。真实应用场景中存在机器的资源限制，由于引入了额外的复杂结构以面临数据中难以挖掘的局部异常无疑会造成训练和推理速度的提升。

• 运行速度的效率。该类模型通常用于离线的行为检测，针对实时的检测还需要对模型选取和检测方法进一步优化。

• 阈值的设定。设置异常阈值不符合真实场景中多种指标都需人工指定阈值这一无监督异常检测的通病。因为检测异常是通过对比重构后的结果与原始输入的差距，而这个差距多少就算是异常需要人为定义。

       在UEBA的实践中，我们发现结合孤立森林+GANomaly的方法，在基于”数据库审计日志中用户越权访问、主机审计日志中账号的资源访问”等场景都取得了不错的效果。要注意的是，这些方法多用于离线检测模块。在某些场景中，我们也会采用集成学习、知识蒸馏等方法去降低误报和压缩模型，以提高模型的准确性、可解释性和稳定性。

     为帮助企业更好的应对内部威胁，腾讯安全运营中心（SOC）推出了UEBA分析能力，以帮助客户高效、准确、及时的检测风险，从而提升自身安全防护能力，有效降低内部威胁影响。想要了解更多UEBA技术，请关注腾讯SOC+UEBA相关介绍。

腾讯SOC-UEBA传送门：腾讯安全中心集成UEBA能力解决内部安全威胁

点个在看你最好看

阅读原文

跳转微信打开

结合腾讯SOC在客户侧的运营实践，本文首先介绍安全运营在业界落地中普遍遇到的问题，并分享腾讯SOC在解决该问题时的思路和工作。

企业暴露越来越多的业务在公网，这对于攻击者来说，是一个非常庞大的攻击面。攻击者会在这些攻击面上进行非常多的攻击行为，试图找到突破点。从企业角度，企业购买的各类安全产品会不断的上报“遭受攻击”，每天向SOC报告上百万的安全事件，让安全运营人员疲于应对。

传统的SOC做法是不断的去调整关联规则，希望能通过关联规则来帮助他们快速从海量告警中找出最严重、最该关注的告警。常用的关联规则手段是通过判断是否有A、B、C等事件按某种模式发生，例如A发生10分钟之内，B发生了，可以生产为一条告警。通过良好的规则运营，关联规则能够将百万级的安全事件压缩至千、百条告警。

关联规则一定程度上能够解决海量告警难以下手运营的问题，但依旧存在着一些痛点问题。例如规则需要随着安全态势的改变而改变、对于出厂规则无法覆盖的安全场景，需要依赖专业的安全运营人员添加、运营的时候，需要人工去组织更多的信息来辅助研判、可能还存在一定程度的误报和漏报等问题。

为了解决上述的痛点问题，腾讯SOC提出了用一个能大幅提高运营效率的风险时间线和一个智能的风险评分算法来解决这个问题。它的做法是，首先将海量的安全事件和相关的活动日志接入进来，并根据用户和设备两个维度，将安全事件和网络活动串成一个“行为时间线”，并产品化的展示出来；其次利用算法的手段，对用户和设备进行风险评分，其中重点关注在对安全事件进行价值度评估上。一个安全事件在一个用户那是否值得关注，可以考虑“安全事件是不是一直在被上报，且之前都被忽略”、“安全事件是不是只在一个设备上发生了”、“是否发生了跟该安全事件组合时非常敏感的事件序列”等。

通过智能的风险评分，腾讯SOC将运营海量告警的问题转化为优先级明确的用户/设备的风险处置问题。通过一个用户/设备列表，可以一目了然的看到有风险的设备有哪些，哪些是已经失陷的，哪些是面临高风险的，以及哪些是安全的。在对用户/设备的运营阶段，通过一个包含安全事件和网络活动的风险时间线，运营人员可以快速的感知到这个用户/设备上发生了哪些安全事件、哪些网络活动，这些事件发生的先后顺序是怎么样的，从而可以快速判断是否需要响应。

智能化 自动化 一站式

（长按二维码快速扫描关注）

该账号主要围绕智能化技术如何帮助企业提升网络安全水平展开，内容涉及机器学习、大数据处理等智能化技术在安全领域的实践经验分享，业界领先的产品和前沿趋势的解读分析等。通过分享、交流，推动安全智能的落地、应用。欢迎关注~

阅读原文

跳转微信打开

soc的独特优势在于它有一个最强大脑，它利用多只眼睛汇聚过来的信息，借助自己的平台能力来进行更高级的威胁分析，从而使得它信息更全面、更准确、更能全链路追随威胁及风险。

T-Sec 安全运营中心（专有云）(以下简称腾讯SOC）核心是想提供给企业安全人员一个统一的安全运营和管理平台，让安全人员无论在面对外部攻击者攻击、或者内部账号/设备失陷时，都能高效、及时、精准的感知到，从而能够及时响应安全事件。

这意味着SOC上首先且基础要做的是接入 企业安全相关的数据。国内企业在“纵深防御”的思路指导下，大都配有防火墙，waf，抗D，终端，NTA，DLP等多种安全设备。腾讯SOC内置400+个解析模版，覆盖多个知名厂家，多种类型的安全设备，这使得他能够以最快的速度、最低的成本，几乎无修改的帮客户完成大部分的数据接入和解析工作。

在数据接入工作完成以后，SOC相当于多了许多“眼睛”，这些“眼睛”在各自的“岗位”上去记录数据，提供给SOC让它进行深度加工。相比其他品类的安全产品，SOC的独特优势在于它有一个最强大脑，它利用多只眼睛汇聚过来的信息，借助自己的平台能力来进行更高级的威胁分析，从而使得它信息更全面、更准确、更能全链路追随威胁及风险

在腾讯SOC中，UE风险分析引擎，从用户和设备两个维度去做深度的威胁分析。

它首先将“眼睛”看到的数据进行信息上的完善，将某些缺失的信息通过上下文和其他的平台数据智能化的补充上，重点是用户和设备相关的信息。例如某些设备上出现“访问恶意域名”的告警，最初并不知道是哪个用户操作的，在腾讯SOC的最强大脑中，它可以通过更丰富的数据“联想”到具体某个用户在哪个设备进行了风险操作。

之后，它将每个用户和每个设备的风险时间线梳理出来，时间线上包括敏感的告警事件、风险事件、和网络活动。例如“张三在上午9点从邮件下载了一份文件”，“上午9:05，他被告警：pc上存在恶意的通信活动”。分析引擎基于UE风险时间线进行最深层次的威胁分析。它从算法和专家经验两方面进行分析：（1）行为模式有没有改变，例如登录模式的改变、资源访问范围的扩大、内网渗透行为的出现；（2）有没有安全专家关注的行为序列，例如[“设备被漏洞利用”、“主机上出现后门”、“出现异常的的外连”、“权限的提升行为”]等。

相比其他的安全告警，腾讯SOC想通过“UE行为分析引擎”输出的是更有安全意义的case。这里区别在于“是否有安全意义”。例如主机上可以报“异常时间登录”，但却无法确认是否是恶意的，是否是需要有后续步骤去跟进的。在UE行为分析引擎中，它通过上下文分析的能力，可以确认行为是否是恶意的。例如“异常时间登录”，它历史以来都一直在这个异常的时间点登录，那就忽略风险。如果不是，那就会增加设备的风险度。并且，如果登录行为有其他维度的异常点，或者它上下文存在一些敏感的异常行为，例如异常登录之后，连接内网中陌生的服务器等，那它的风险值会急速攀升，从而能将风险及时告知到客户。

通过UE风险引擎，将风险定位到之后，为了提升客户的安全运营及响应效率，腾讯SOC将用户和设备的风险时间线绘到产品中，它希望客户从腾讯SOC推送的告警中，回到产品中时，仅需要几分钟时间去确认风险，就能完成安全运营，而不是数个小时，多个页面，多个维度的搜集信息。我们想，这是比较理想的安全运营流程。

ps. 如有疑问，欢迎发送消息到【腾讯安全智能】

智能化 自动化 一站式

（长按二维码快速扫描关注）

该账号主要围绕智能化技术如何帮助企业提升网络安全水平展开，内容涉及机器学习、大数据处理等智能化技术在安全领域的实践经验分享，业界领先的产品和前沿趋势的解读分析等。通过分享、交流，推动安全智能的落地、应用。欢迎关注~

阅读原文

跳转微信打开

数据显示，到2022年，30%的5人以上的安全团队将会采用SOAR（安全编排与自动化响应）。你是那30%吗？

跳转微信打开

在基础安全领域中，通过实体画像技术可以从多维度对检测对象进行描绘。这些描绘的成果将成为复杂安全检测，与复杂网络攻击调研的数据基础。

一、什么是实体画像

二、实体画像和基线技术的区别

三、实体画像实现技术介绍

四、实体画像在UEBA中的应用

5、腾讯实体画像技术的独特优势

该账号主要围绕智能化技术如何帮助企业提升网络安全水平展开，内容涉及机器学习、大数据处理等智能化技术在安全领域的实践经验分享，业界领先的产品和前沿趋势的解读分析等。通过分享、交流，推动安全智能的落地、应用。欢迎关注~

阅读原文

跳转微信打开

1.背景介绍Webshell是一种基于web应用的后门程序，是黑客在入侵过程中经常使用的一类恶意工具之一。w

1.背景介绍

Webshell是一种基于web应用的后门程序，是黑客在入侵过程中经常使用的一类恶意工具之一。web渗透中黑客可以利用特定的Webshell获取服务器权限，进而进行服务器文件操作、数据库操作以及盗取用户私密信息等。

业务背景：将基于AI的webshell检测引擎作为重保/护网项目的样本检出插件使用。

业务目标：建立webshell检测模型，对输入样本进行解析和识别，并输出该样本的标签。

2.数据理解及处理

Webshell脚本文件的类型有php、jsp、asp、aspx等，其中php样本占webshell样本的70%左右。

php的简单webshell：

jsp的简单webshell：

      asp的简单webshell:

从PHP源代码层面分析复杂，不适合做一些语言处理的工作，因此无法作为深度学习模型的输入。PHP脚本代码在经过编译后，生成可以直接运行的中间代码OPCODE，也称字节码，具有时序性。

3.特征处理

获取opcode序列及其参数信息，去掉无用信息

4.算法方案

初始方案：TextCNN模型是使用卷积神经网络来处理NLP问题的经典模型

改进方案：加入时序信息，在原来的基础上引入n-gram，构造双输入模型。

n-gram模型基于这样一种假设，第n个词的出现只与前面n-1个词相关，而与其它任何词都不相关，整句的概率就是各个词出现概率的乘积。当 n=2, 一个二元模型（2-gram model)即为 ：

基于n-gram的双输入TextCNN模型：

真实场景：webshell正常页面中的比例可能不足万分之一，正负样本比例差异非常大，导致训练的模型存在一定的偏差。可使用Stacking的方式。

（1）正常样本比例作为初始训练集，训练基分类器。

（2）根据基分类器结果再训练第二个分类器；

采用上述方式可以消除真实场景样本比例差距大的问题。

5.效果展示

阅读原文

跳转微信打开

一、UEBA场景是什么 腾讯御见UEBA（用户实体行为分析）使用一系列分析方法（统计学习、机器学习等）通过

一、UEBA场景是什么

 腾讯御见UEBA（用户实体行为分析）使用一系列分析方法（统计学习、机器学习等）通过分析用户实体相关行为日志，对用户及其实体进行风险监测分析和风险评估，最终识别内部风险用户和风险实体。通过持续跟踪用户和实体的行为，可以全面地了解内部威胁风险，将原始日志、活动、告警、事件与用户和实体关联，构建完整的用于分析、调查的事件上下文。

参考Gartner建议和业界典型方案， UEBA进行分析的数据源需要包括系统/应用日志、用户活动审计日志以及安全设备检测到的风险事件三大类。以腾讯UEBA为例，当前支持分析的数据源包括Linux系统日志、Windows安全事件日志日志、堡垒机审计日志、VPN审计日志、零信任网关审计日志、数据库审计日志，以及天眼云镜HIDS、御界NTA等的安全检测事件。腾讯UEBA的具体场景是按照以上数据源类型进行划分的，每个场景大类下又细分为多个具体检测场景，而我们的UEBA风险事件检测就是基于细分的具体场景进行检测的。

本文主要介绍的是数据库安全场景的探索和实现。

二、数据库安全场景探索

1、数据库审计日志获取

我们常用的免费数据库一般是MySQL，或者是MySQL数据库的衍生版MariaDB。MariaDB虽然被视为MySQL数据库的替代品，但它在扩展功能、存储引擎以及一些新的功能改进方面都强过MySQL，且是完全开源的。MariaDB跟MySQL在绝大多数方面是兼容的，对于开发者来说，几乎感觉不到任何不同。由于我们目前的实际研发环境就是基于MariaDB的，因此我们选择MariaDB作为数据库安全场景探索的开始。

MariaDB_5.5.37版本和MariaDB_10.0.10以后版本的自带适配的audit插件，能够方便地收集数据库的操作。首先查看数据库审计插件存放的目录：

show variables like '%plugin%'

如果server_audit.so安装程序不在plugin_dir的目录下，需要先将server_audit.so下载到plugin_dir的目录下。找到配置文件my.cnf所在的位置，并向my.cnf文件中增加如下配置：

plugin-load=server_audit=server_audit.so

server_audit_logging = ON（打开审计日志开关）

server_audit_file_path = **（审计日志存放路径，该路径下会生成一个server_audit.log文件记录相关操作记录）

server_audit_events = 'CONNECT,QUERY,TABLE'

server_audit_incl_users = test（指定哪些用户的活动将记录，connect将不受此变量影响）

然后重启数据库：

service mysqld restart

查看audit插件的参数情况可以运行命令：

show variables like '%audit%'

2、数据库审计日志分析

配置好数据库审计日志后，就可以在server_audit_file_path下的server_audit.log文件中查看指定用户的活动记录，记录截图如下。

一条审计日志的组成结构如下为[timestamp][serverhost][username][host][connection] [queryid][type][database][object][retcode]。

其中serverhost代表数据库所在的服务主机名，username代表该条记录的操作用户，host代表该操作执行所在的服务器，一般为localhost、127.0.0.1或实际ip地址如192.168.190.111。connection代表该记录所属的连接段id，该字段一般在登录数据库时更新。queryid代表本次操作的id。type取值最常见的有CONNECT,DISCONNECT,QUERY几种。如上图所示，CONNECT代表连接数据库，DISCONNECT代表断开数据库的连接，QUERY代表命令行的查询操作。database代表当前操作的数据库。object代表命令行的具体内容。retcode代表当前操作执行是否成功，如果执行成功则为0，否则为错误代码。

3、包含数据库操作的其他类型日志

     数据库审计日志中的信息能帮助我们识别很多异常行为，但是仍有一些数据库操作无法被记录在数据库审计日志中。例如mysql登录命令mysql -h 127.0.0.1 -u root -p -P 3306，数据库数据导出命令mysqldump -u username -p dbname > dbname.sql等。在这种情况下我们其实是需要记录linux系统的cmd命令，然后对这些命令进行分析检测。

     在我们已支持接入的数据源中，堡垒机日志、HIDS日志中一般是包含cmd命令相关的日志的。因此，在UEBA已经接入业务环境中的堡垒机日志或主机HIDS日志的情况下，如果想审计mysql、mysqldump相关的数据库安全命令，可以直接基于堡垒机或HIDS中的命令日志。

三、数据库安全场景设计和实现

1、场景主体划分

腾讯御见UEBA的分析场景既包括围绕员工/用户行为的行为分析、风险识别，也包括针对特定设备、主机进行的失陷检测、异常行为识别。两者对应的场景设计和实现根据数据源的不同有所不同。

对于从数据库审计日志中获取数据所设计的场景的主体有两种情况，一种是主体既能对应到设备又能对应到用户，另一种是主体只能对应到设备而无法对应到用户。这是因为通过数据库审计日志中的host获取到的ip代表当前登录数据库的设备ip，该ip可以结合设备的其他标识信息映射为设备id，因此数据库审计日志场景的主体是肯定能对应到设备的。但是由于登录数据库的设备很大可能是堡垒机、跳板机这类公共服务器，该公共服务器并不一定能够挂靠到具体某个用户，因此仅根据数据库审计日志数据设计的场景是存在无法挂靠到用户的情况的。

对于从腾讯云堡垒机日志中获取数据所设计的场景，由于堡垒机一般来说都是基于账号登录的，而UEBA中账号一般是可以关联到对应的用户上。这里的用户一般是指运维人员及对应的运维账户。因此根据堡垒机日志设计的场景主体通过用户账号的映射一般可以直接关联到特定的人员。

    上图是UEBA以用户为主体的场景列表，以设备为主体的场景列表和以用户为主体的场景列表基本遵循同一套逻辑。

2、场景设计示例

（1）    提权操作成功

日志类型：数据库审计日志或堡垒机日志

检测方法：审计日志sql语句或堡垒机日志的命令行包含drop database **，且操作成功

（2）    删除数据库成功

日志类型：数据库审计日志或堡垒机日志

检测方法：审计日志sql语句或堡垒机日志的命令行包含drop database **，且操作成功

（3）    短时间频繁清除数据

日志类型：数据库审计日志或堡垒机日志

检测方法：短时间审计日志sql语句或堡垒机日志命令行是否频繁以truncate table开头，或delete from开头

（4）    短时间频繁删除表

日志类型：堡垒机日志

检测方法：短时间审计日志sql语句或堡垒机日志命令行是否频繁以drop table开头

（5）    无密码登录

日志类型：堡垒机日志

检测方法：命令行以mysql开头无-p参数

（6）    明文密码登录

日志类型：堡垒机日志

检测方法：命令行以mysql开头带-p参数且有对应值

（7）    导出mysql数据（数据库备份）

日志类型：堡垒机日志

检测方法：命令行包含mysqldump

3、场景实现说明

4、小结

 本文以数据库安全相关场景为例，介绍了腾讯UEBA的安全场景设计和实现。虽然，文中介绍的数据库场景是基于规则的方式实现的，更具体的来说就是直接基于单条或多条原始日志进行筛选、聚合以实现关键风险行为识别。

但是，在产品中的在其他一些场景中，腾讯UEBA还实现了基于画像的检测、基于机器学习的检测等复杂检测分析方法。基于历史基线、同类群组、序列检测算法、异常检测算法、聚类算法等方法，发现更多异常风险，构建更加丰富可靠的用户实体分析全景。

阅读原文

跳转微信打开

腾讯御见UEBA（用户实体行为分析）面向政务、金融、能源等行业的办公安全、数据安全、员工行为管理，使用一系列

腾讯御见UEBA（用户实体行为分析）面向政务、金融、能源等行业的办公安全、数据安全、员工行为管理，使用一系列分析方法（统计学习、机器学习等高级分析方法）通过分析用户实体（用户、设备、主机等）相关行为日志构建用户实体画像（静态画像、动态画像），然后基于用户实体画像进行风险检测、风险分析、风险评估，最终识别内部风险用户和风险实体。在产品上，提供仪表板和风险时间线能力，帮助感知和运营，提升运营效率。

• 检测某个重要服务器外发的数据大小是否异常

• 检测两个端点之间的通信模式是否异常

• 检测某个账号从服务器下载的数据量是否异常

• 检测某个用户访问的内网资源数量是否异常

• 检测用户每天的首次活跃时间是否有异常

1. 介绍有关时间序列的基本知识。先让大家理解算法上如何看待时间序列这类数据。
   

2. 介绍fbprophet方法的原理。
   

3. 介绍该方法与LSTM方法的效果对比，及分享我们在UEBA中做场景落地时候的收获。

4. 小结。

5. 附录：自动选择拐点时的处理逻辑
   

6. 小彩蛋

其中g(t), s(t),h(t)分别为趋势分量、周期分量、节假日分量，

基于这个思路，首先将这些拐点的改变用向量表示为

其中为在拐点处增长率k的变化大小。那么在时间t处的增长率k会变为。为了使用向量表示，引入一个指示向量.变为. 在偏置项的改变上，在j处也可以调整为：

【至于为什么是这种形式，可以理解为，为当前拐点的时间点，m为一个固定的偏置量，从后退一个偏置量，再将过去拐点未知的扰动量减掉，剩下从语义上来说应为一个本次拐点的扰动大小。之后再利用增长率变化的大小做一个尺度的调整，即为本次拐点位置的扰动量。】

它支持算法人员传入过去和未来的节假日列表，对于每个节假日，支持配置节假日的影响窗口，例如圣诞前前后各一天都算节假日的影响范围。在每个节假日上，配置对观测值的影响大小，即为, 表示第i个节假日的区间。我们假设服从均值为0，方差为的正态分布。

Lstm  拟合预测（10000次）	Fbprophet方法（无调参）

阅读原文

跳转微信打开

目前我们御见UEBA产品最新版本已经发布，上一篇文章我们结合UEBA背后的技术行了简单介绍，本文将对UEBA内部风险相关场景进行介绍，有兴趣欢迎交流。

引子：腾讯御见UEBA（用户实体行为分析）面向政企办公安全、数据安全治理、员工行为管理，使用一系列分析方法（统计学习、机器学习等高级分析方法）通过分析用户实体（用户、应用、设备、主机等）相关行为日志构建用户实体画像（静态画像、动态画像），然后基于用户实体画像进行风险检测、风险分析、风险评估，最终识别内部风险用户和风险实体。御见UEBA是单独的解决方案或产品，也可以作为一种高级分析能力或模块嵌入到御见SOC中。目前我们御见UEBA产品最新版本已经发布，上一篇文章我们结合UEBA背后的技术行了简单介绍，本文将对UEBA内部风险相关场景进行介绍，有兴趣欢迎交流。

1. Gartner对UEBA场景的分析

Gartner认为UEBA随着新的场景出现，主要的一些场景也正在巩固稳定。UEBA解决方案可以支持多种场景。Gartner认为UEBA一些场景，包括监控未授权数据的访问和移动，可疑的权限用户行为，恶意的或未授权的员工行为。UEBA还监控不正常的云资源访问和使用，并且支持对现有的一些产品做更好的检测，例如CASB和IAM。除此之外，UEBA解决方案有时候还能被用作分析一些典型的非网络安全的场景，例如欺诈或者员工监控。

Gartner描述了5大类主要的场景：

1）恶意内部员工

这类场景主要监控员工和外部合作方是否存在异常、恶意或滥用行为。此类场景不会监控分析服务账号或者其他非人为实体，并不面向检测高级威胁，目的只是识别从事恶意活动的内部人员。

本质上，恶意内部威胁是有意损坏公司或组织利益的受信任用户。因为用户恶意的意图不好评估，所以需要从日志中抽取上下文进行行为分析。

2）失陷内部员工和高级威胁

这类场景是指一旦攻击者渗透到组织中并在内部横向移动，就可以快速检测和分析恶意活动。众所周知，高级持续性威胁（APT）和未知威胁（例如0-day攻击）很难被发现，并且通常藏在合法用户或服务帐户之后。这些威胁通常具有复杂的模式，或者其恶意行为还没有被发现过。这使它们难以通过简单的分析（例如模式匹配，阈值或相关规则）进行检测。

但是这些高级威胁中的许多威胁会使得资产的行为与正常行为不同，通常会利用毫无戒心的用户和身份，即受害内部人员。UEBA技术提供一种方法来检测这些威胁，提高信噪比，合并和减少警报量，对剩余警报进行优先级排序以及促进有效的响应和调查。

3）数据外泄

这类场景检测组织中数据的泄漏。此场景通常通过异常检测和高级分析来增强DLP或数据访问管理系统，从而提高其信噪比减少告警量， 并优先处理剩余的告警。

对于其他情况，它们倾向于与网络流量（例如，Web代理）和终端数据集成，并更多地依赖它们，因为对这些数据源的分析可以阐明数据渗漏活动，数据泄露检测用于捕获威胁组织的内部人员和外部黑客。

4）身份和权限访问管理

这类场景主要监控访问权限和分析用户行为，以识别特权或异常访问。这适用于所有类型的用户和帐户，包括特权用户和服务帐户。组织还可以使用UEBA来清理休眠帐户和用户不必要的权限。

5）事件优先级

这类场景的目标是帮助组织确定生成的警报的优先级，并提供有关应优先处理哪些事的指导。 在这种情况下，UEBA引擎不仅会使用基线模型和威胁模型，而且通常会使用组织的结构信息（例如，资产的关键性以及人员的角色和访问级别）来丰富基准和威胁模型。

2. UEBA内部风险

从Gartner对UEBA主要场景的分析能看出，UEBA主要关注的典型场景是恶意员工风险、失陷员工风险、账号权限管理、数据泄露、告警优先级等，主要是企业内部风险。御见UEBA一方面覆盖这些典型的UEBA场景；另一方面针对客户业务、梳理应用接口、监控应用运行状态，保障客户环境账号安全、办公安全、数据安全和业务安全。下面主要对UEBA主要的场景内部风险进行简单介绍。

1）内部风险定义

内部风险主要是企业内部用户引起的安全风险。内部用户包括：在职员工；离职员工；合作方；供应商等等。主要通过行为分析识别违规用户，失陷用户，恶意用户等等。

恶意用户：对于恶意的内部人员，用户通常是有目的的行为，知道本身的行为可能会对企业造成损害。

违规用户：企业内部员工可能会出现的一些有意无意的违规行为，也可能对企业造成一定的损害，例如存在账号共享、违规操作等等。

失陷用户：企业内部员工可能由于钓鱼邮件或所属设备失陷等导致凭证外泄，攻击者会通过合法的凭证在企业内部做恶意活动而很难被发现。

2）内部风险原因：

下面列了部分可能引起内部风险的原因。

* 内部员工相关岗位有不适当的访问权限：

* 内部员工转岗等情况没有因为更换角色而及时撤销权限；

* 离职员工仍然能远程访问敏感应用或服务器。

* 内部员工对敏感数据有高权限，但是有恶意企图。

* 企业内部敏感数据越来越多：财务报告；客户数据；产品或技术文档；员工数据等。

* 办公全球化增加了数据外泄可能，内部员工的办公地点不局限在本地，能更容易在任何时候任何地点通过VPN,智能网关等工具访问企业内部敏感数据。

* 操作不规范如员工之间共用凭证等行为，也会给企业带来一定的隐患。

3）UEBA内部风险场景

御见UEBA内置了多种风险场景，例如：账号风险、研发凭证外泄风险、离职员工权限风险、内部数据窃取、研发数据泄露风险、内部业务运行风险，下面对这些场景进行简单介绍。

① 账号风险

账号风险主要是指由于内部员工账号引起的风险，例如：账号共享，账号失陷，静默账号等等。

账号失陷：攻击者通过钓鱼邮件，暴力破解，漏洞等方式获取用户的凭证，导致用户账号失陷。进而攻击者通过用户合法的账号访问企业内部应用或数据。及时检测识别账号失陷风险能在引起更严重后果之前进行阻止。

账号共享：内部员工将自己访问数据、应用、资产等的凭证，共享给其他并没有访问权限的员工使用，引起账号共享风险。

账号风险的检测，可以提取账号相关画像特征（例如时间戳，位置，IP，设备等等），通过机器学习算法，以识别与特定帐户正常行为的任何偏差，并相应的响应。这有助于根据异常行为模式来检测任何潜在的帐户泄露或劫持情形，例如：对高风险或敏感对象的异常访问，异常的活动数量，短时间内的请求，来自终止的用户帐户的活动或休眠帐户。通过时间序列或行为分析的机器学习模型识别与用户或同类的正常行为不一致的异常，将基于高级安全分析获得风险评分，风险评估。

优点：

* 通过行为分析检测账号未知的行为异常进而识别账号共享，账号失陷，休眠账号等，而不是通过规则、白名单的方面检测已知威胁等。

* 提供了全面的用户账号行为可视化，全局视角审核异常账号，休眠账号等等。

② 权限滥用

权限滥用通过账号、访问等多种数据关联识别高权限访问滥用行为。一般会从IAM或其他账号权限系统提取账号及访问数据，以识别特权用户以及被授予高权限的普通用户。基于这些数据，UEBA可以检测到可疑行为和滥用行为，例如：使用特权账号为普通账号分配特殊或提升的特权，然后对敏感数据访问。这些异常访问同样会体现在不同的IP，设备，位置异常等等。

优点：

* 识别高权限账号，高权限账号行为全面可视。

* 检测高权限账号滥用行为，减少风险。

③ 数据外泄

敏感数据外泄会对企业造成严重的损失，UEBA通过企业内部业务信息或DLP日志获取敏感数据或应用，结合应用访问等数据，监控敏感数据或应用的访问行为，从而识别数据泄露保护企业数据安全。

数据外泄的主要方式有两种，一种通过接口访问拉取敏感数据，另一种本地访问移动copy外发敏感数据。

UEBA针对通过接口访问拉取敏感数据的情况，分析用户访问敏感数据日志，监控用户访问行为，通过机器学习的方法比较历史基线和同类基线，如行为偏离基线，则识别为访问敏感数据异常风险。

UEBA针对本地敏感数据访问移动copy外发等行为，分析DLP日志，确定DLP告警优先级，降低误报，优先重要告警，同时为用户访问行为提供丰富上下文，便于运营人员更快更直接识别到风险，及时做出反馈，减少企业损失。

UEBA提供了可配置的基线建模平台，方便对敏感数据监控任务的配置及及时检测识别。

优点：

* 通过自学习机器学习模型提供数据访问行为基线，识别敏感数据异常访问。

* 通过风险权重风险评分显著减少DLP告警数量，节省调查时间，降低误报。

④ 业务运行风险

对企业来说，业务的正常运行极为重要。UEBA除了监控用户行为，用户访问业务行为以外，还会梳理企业业务接口，全面可视化化业务接口运行情况。而且通过时间序列等机器学习的方法监控业务访问量是否异常，业务访问用户量是否异常，访问失败数异常，接口是否失活等等。使得企业全面了解业务，及时发现业务运行风险，保障业务正常运行。

优点：

* 梳理企业业务，全面可视化业务运行情况。

* 通过时间序列等机器学习模型，实时监控业务运行状况，及时识别业务运行异常。

3. 结论

御见UEBA为了保障企业账号安全、办公安全、数据安全和业务安全，内置覆盖了典型的UEBA场景，一方面全面可视企业内部员工行为、企业业务接口运行状况，另一方面通过机器学习平台基于多源行为数据对用户和应用构建基线，进一步识别未知的行为异常，快速识别发现风险用户及风险应用，为企业内部安全保驾护航。

除了内置的场景以外，客户还可以通过可配置的机器学习平台快速实现特殊业务场景的分析、检测及监控，在运营过程中不断完善丰富UEBA场景。

该账号主要围绕智能化技术如何帮助企业提升网络安全水平展开，内容涉及机器学习、大数据处理等智能化技术在安全领域的实践经验分享，业界领先的产品和前沿趋势的解读分析等。通过分享、交流，推动安全智能的落地、应用。欢迎关注~

阅读原文

跳转微信打开

目前我们御见UEBA产品最新版本已经发布，上一篇文章我们结合最新版本对御见UEBA产品进行了简单介绍，本文将对腾讯御见UEBA相关技术进行介绍，有兴趣欢迎交流。

 引子：腾讯御见UEBA（用户实体行为分析）面向政企办公安全、数据安全治理、员工行为管理，使用一系列分析方法（统计学习、机器学习等高级分析方法）通过分析用户实体（用户、应用、设备、主机等）相关行为日志构建用户实体画像（静态画像、动态画像），然后基于用户实体画像进行风险检测、风险分析、风险评估，最终识别内部风险用户和风险实体。御见UEBA是单独的解决方案或产品，也可以作为一种高级分析能力或模块嵌入到御见SOC中。目前我们御见UEBA产品最新版本已经发布，上一篇文章我们结合最新版本对御见UEBA产品进行了简单介绍，本文将对腾讯御见UEBA相关技术进行介绍，有兴趣欢迎交流。

一：御见UEBA技术架构

御见UEBA技术架构如下图所示，主要包括3个部分：数据采集，智能检测分析平台，行为风险评估。UEBA采集多源数据例如登录日志，访问日志，其他安全产品日志，流量数据等，并对多源日志进行关联、分析、检测，基于行为分析等多种方法识别政企内部的用户风险和业务风险。

1. 数据采集

UEBA采集的数据源主要有三类：登录日志；访问日志；其他日志。

登录日志：主要记录用户认证登录业务、系统或应用的行为日志。例如：IAM统一认证登录日志，IOA登录认证日志，VPN日志，核心业务登录日志，AD日志，LDAP日志等等；

访问日志：主要记录用户认证登录成功后访问业务、系统或应用产生的行为日志。例如：里约网关访问日志，IOA应用访问日志，堡垒机日志，数据库审计日志，门禁日志，其他核心业务访问日志等等；

其他日志：主要包括其他安全产品日志，流量日志。例如：DLP日志，IOA日志，威胁情报，flow数据，其他安全产品日志等等。

2. 智能检测分析平台

智能检测分析平台为UEBA提供了主要的关联检测分析能力，一方面智能检测模块在产品上以可配置的基线建模平台的形式提供了画像体系构建、行为建模能力；另一方面智能分析模块根据场景进行风险检测、风险评估，并且基于风险评估结果进行动态打分，最终用户实体将以风险分数排序的方式展示给运营人员。

智能检测和智能分析将通过自适应学习、在线学习、离线学习、集成学习、强化学习等方式学习预测。

3. 行为风险评估

行为风险评估主要包括根据特定场景风险评估和用户实体综合风险打分。特定场景风险主要对用户进行恶意用户分析、失陷用户分析、违规用户分析、离职员工风险分析，对业务进行业务滥用分析、数据泄露分析、业务异常分析、业务运行状态监控等分析，最后综合所有的特定场景风险以用户实体的维度综合风险评分。

二：智能检测分析平台 

智能检测分析平台为UEBA提供了主要的关联检测分析能力，智能检测分析平台主要包括4大部分：画像体系，行为建模，自适应风险评估，层次动态打分。智能检测分析平台首先关联多源日志构建画像体系，然后基于完备的画像体系进行行为建模，通过行为建模对用户实体进行行为风险评估，最终将所有用户实体风险事件送入层次动态打分机制，完成用户实体的最终风险评分。

1. 画像体系

御见UEBA分析的对象主要包括用户、设备、资产、应用等等，当多源日志接入以后会自动构建用户实体画像体系，持续丰富更新用户实体的静态画像和动态画像。

用户实体静态画像：及时更新维护用户实体的静态信息，例如：用户身份、部门、岗位、权限、账号；设备归属；资产身份及重要性；应用敏感度等等。

用户实体动态画像：持续监控用户实体行为建立动态画像。

基于Spark计算引擎实时监控用户实体的行为统计提取行为特征，并通过机器学习算法基于分析对象行为特征建立历史基线画像、同类画像及动态分组；分析对象的行为不是静态不变而是随着时间动态变化的，统计画像、历史基线画像和同类画像就构成了分析对象的动态画像，用来刻画分析对象的动态个性。

动态画像例如：用户访问敏感数据的历史频次等等；用户当天访问某个资产的时间，地点，操作行为等等；资产与其他资产通信情况或用户访问资产情况等等；设备当前登录次数，使用状态等等。

2. 行为建模

画像体系构建，一方面实时更新一方面送入行为建模。因为接入海量的多源日志数据并且对每个用户和实体进行实时监控，单机有性能瓶颈问题所以我们基于大数据计算引擎Spark搭建了行为基线建模平台（可配置的基线建模平台），并且支持简单拖拽（不用编写代码）即可快速完成行为建模调试及生成环境上线。可配置的基线建模平台数据流图如下图所示，Spark读取多源数据，经过预处理、数据转换、特征提取、AI引擎、可解释性模块、决策引擎，完成整个行为基线建模流程。下面将通过基线建模、可解释性、时间序列、行为分析等方面介绍。

1) 分布式单体基线建模/群体基线建模

刻画一个用户或一个实体在某些场景下是否有异常，我们一方面可以分析用户实体的历史行为，对历史基线建模（比如1个月），如果当前用户实体行为偏离历史一个月的正常行为，那么我们需要关注分析对象是否出现行为偏离历史行为异常。另一方面可以分析用户同类行为，对同类基线建模（比如同组或者同岗位等），如果当前用户实体行为偏离同类行为，那么我们同样需要关注分析对象是否出现了偏离同类基线行为异常。无论是异于自身历史行为或同类行为，都应该引起关注，所以我们需要对每个分析对象建立同类基线及历史基线。

UEBA通过基于spark的行为基线建模平台分布式并行的对每一个分析对象（用户或应用等实体）基于历史基线建模和对同类基于群体基线建模。

单体基线建模：如上图所示，基线建模平台会根据场景自动收集历史一段时间日志（例如1个月），对每个分析对象历史行为建模，刻画用户历史正常行为模式，以用来预测识别当前分析对象的行为是否异常。

群体基线建模: 如上图所示，基线建模平台会根据场景自动收集分组日志（同组、同部门或同岗位等），对每个分组建立同类基线，客户用户同组正常行为模式，以用来预测识别当前分析对象的行为是否异常。

2) 可解释性

可解释性：企业场景下，为了客户快速定位威胁，检测结果必须具有可解释性。即模型既要有规则没有的发现未知的能力同时要像规则一样有较好的可解释性。

基于数据及检测场景特点，我们将行为建模算法主要分为两类：时间序列建模和行为分析建模。

时间序列建模的可解释性：时间序列有天然的可解释性，将时间序列数据及异常点可视化展示即可，如下图示例可见。

                离群点                                         拐点

行为分析建模的可解释性：我们在行为分析算法后增加z-score可解释性模块，用来解释模型。z-score 可解释性模块的输出是引起异常最重要的特征集合、特征值及偏离程度，这些指标能很好的解释模型结果。

3) 时间序列建模

时间序列建模是将历史数据在时间维度上按先后顺序构建时间序列，并通过一系列相关模型进行建模识别潜在模式，以便对后续数据进行预测或者异常检测。

根据时间序列本身的特点，我们将时间序列分为周期性的时间序列，和非周期性的时间序列。对不同类型的时间序列应用不同的算法建模。例如：周期性的时间序列应用STL, Holt-Winters等算法建模；非周期性的时间序列应用小波变换等算法建模。

根据时间序列异常类型不同，我们将时间序列异常区分为离群点异常，拐点异常，子序列异常。

时间序列建模加上异常检测可实现离群点检测，拐点检测，异常序列检测等功能。因不同特点的时间序列数据没法在同一个算法上达到最好的效果，所以这里的时间序列算法纳入了不同特点算法以适应不同类型的应用。

4) 行为分析建模

行为分析建模主要包括历史行为分析建模和同类行为分析建模两种模式。

基于历史行为分析建模：基于历史一段时间数据对每个对象建立历史基线，如果企业内部有10W个用户，那么行为分析建模模块会分布式建立10W个基线模型，以用来后续对每个用户识别异常行为。

基于同类行为分析建模：基于同类对象建立同类基线，每个分组建模一个基线模型，例如部门基线，岗位基线等等。

行为分析建模集成了多种算法例如基于推荐的、基于重构的、基于聚类的、基于半监督、有监督等算法，我们可以根据不同场景选择不同算法来快速完成行为分析建模。

三：行为风险评估

1. 自适应风险评估

综合静态画像和动态画像完整的刻画了用户实体，基于画像数据进行行为建模、风险分析、风险评估等等。

用户风险评估：

基于用户画像根据不同场景进行风险评估，进而获得用户的登录风险；访问风险；账号权限滥用风险；数据外泄风险；特殊权限操作风险；账号失陷风险；敏感数据访问风险；数据访问异常风险等等。

用户风险评估将通过实时或离线的方式持续对每个用户的风险场景进行异常检测及关联打分，并最终以风险时间线的形式展示，以备后续进行运营调查。

设备、资产或应用风险评估：

基于应用、设备、资产或应用画像根据不同情况进行风险评估，例如：设备异地登录风险；大量新增设备风险；应用访问次数激增风险；资产外部告警风险；用户访问资产异常风险等等。

应用、设备、资产或应用风险评估将通过实时或离线方式持续对每个设备或资产的风险异常检测及关联打分，并最终以风险时间线的形式展示，以备后续基于风险评估运营调查。

a. 风险评估不同客户不同模型：风险评估需要适配不同客户环境自适应学习，客户环境是复杂的，不同客户使用不同模型，要求我们需要根据客户真实数据训练模型，不能完全依赖模拟数据。

b. 风险评估同一客户不同环境不同模型：即使同一客户环境，风险评估也需要根据时间推移自适应学习， 客户环境下的数据并非静态不变而是动态变化的，例如员工权限变化、员工岗位变化、服务器角色的变更、服务器业务增删等等，这些变化都可能引起之前训练的模型失效。所以即使是同一客户环境下，我们也需要动态适配客户环境，根据时间推移自适应学习。

如何自适应学习：

自适应学习主要采取训练数据更新、模型自适应更新、动态评价三个步骤来实现：

a. 训练数据更新：基于滑动时间窗口将最近的数据纳入到训练数据中。比如：行为异常检测模型需要x天数据进行训练，每次训练使用最近的x天时间窗口的数据。

b. 模型自适应更新：时间序列异常检测我们根据任务调度间隔获取x周最新特征数据做训练同时检测。行为分析异常检测需要根据x天历史或同类行为数据训练，一般训练时间较长，我们根据反馈数据误报升高时动态更新模型。

c. 动态评价：内置场景检测在上线之前我们会对检测能力进行离线评价；然而真实客户环境比较复杂，往往会导致误报增加，如何在不同的客户环境下进行动态评价变得尤为重要。对一部分场景，检测模型会根据测试样例和每次的训练数据动态调整置信度参数控制误报情况。另外提供反馈机制，通过反馈自动学习。

2) 在线学习

对UEBA一部分场景需要及时将风险呈现（例如几分钟之内），对于这部分场景风险评估采取在线学习方式，实时预测识别风险。如下图所示针对一部分实时场景，基于spark streaming在线学习从行为建模中读取实时模型，从画像体系中读取实时画像，在线预测识别风险。

3) 离线学习

对UEBA一部分场景我们需要基于较长时间间隔的画像特征进行建模和预测，比如一天内用户访问行为等，那么我们需要离线建模及预测。如上图所示，基于Spark离线学习同样从行为建模中读取离线模型，从画像体系中读取离线画像特征，基于模型及离线数据识别风险。

4) 集成学习

集成学习可以通过集成多种算法同时对同一个风险场景学习预测，进行风险评估，以达降低误报、预测识别更精准的效果。例如我们可以同时集成单体基线建模和群体基线建模来综合评估用户实体风险。如下图所示：

2. 层次动态打分

经过风险评估以后，会识别出每个分析对象的风险场景及置信度。层次动态打分的输入是所有风险场景及置信度及重要性权重，输出是每个用户实体最终的风险分数。风险场景置信度由风险评估直接给出，风险场景的重要性一般是人工经验指定，但是在不同行业不同客户那里，相同的风险场景的重要性却相差较大。风险分的公式如下：

，其中risks指风险评估检测识别出的用户实体相关场景的风险集合，confidence指风险置信度，severity指风险严重程度，context指风险发生的上下文包括时间、前后关系等等，context主要通过影响severity来影响score。所以严重程度的权重对打分有很重要的作用。

御见UEBA采用层次动态打分的机制，前期主要基于推荐及策略将人工经验融入其中进行风险权重调整再计算出风险总分。后期用户有了长期反馈以后，启动基于强化学习动态打分模型，自动调整风险场景权重及用户实体风险总分。

1) 基于推荐及策略的风险权重调整

基于策略的风险权重调整：

我们融入多种人工经验到策略中自动调整风险权重，例如：时间衰减；相同风险频繁出现动态降低权重；风险上下文命中自动增加权重等等。

基于推荐的风险权重调整：

针对有些特定场景我们可以通过推荐的算法自动预测风险事件权重，例如：首次访问敏感数据风险；

基于推荐算法的主要思路是将用户和同类的历史访问行为及用户上下文信息考虑进去，利用推荐算法FM预测用户访问每个实体的概率。我们将这个概率作为首次访问敏感数据风险场景的重要性权重。

2) 基于强化学习动态打分模型

UEBA部署前期阶段有较少的反馈，所以我们主要通过推荐及策略的方式调整重要性权重进行打分。当后期随着运营人员不断的反馈，前期产生的权重将作为初始参数与反馈的结果一同进入到基于强化学习的动态打分模型中，模型通过持续的奖赏和惩罚，动态调整权重及风险分数。

四：总结

腾讯御见UEBA主要围绕智能检测分析平台构建了支撑UEBA的关联检测分析能力，智能检测分析平台首先关联多源日志构建画像体系，然后基于完备的画像体系进行行为建模，通过行为建模对用户实体进行行为风险评估，最终将所有用户实体风险事件送入层次动态打分机制，完成用户实体的最终风险评分。本文分别对画像体系，行为建模，自适应风险评估，层次动态打分进行了简单介绍，有兴趣欢迎交流。

阅读原文

跳转微信打开

目前我们御见UEBA产品最新版本已经发布，上一篇文章我们结合最新版本对御见UEBA产品进行了简单介绍，本文将对腾讯御见UEBA相关技术进行介绍，有兴趣欢迎交流。

 引子：腾讯御见UEBA（用户实体行为分析）面向政企办公安全、数据安全治理、员工行为管理，使用一系列分析方法（统计学习、机器学习等高级分析方法）通过分析用户实体（用户、应用、设备、主机等）相关行为日志构建用户实体画像（静态画像、动态画像），然后基于用户实体画像进行风险检测、风险分析、风险评估，最终识别内部风险用户和风险实体。御见UEBA是单独的解决方案或产品，也可以作为一种高级分析能力或模块嵌入到御见SOC中。目前我们御见UEBA产品最新版本已经发布，上一篇文章我们结合最新版本对御见UEBA产品进行了简单介绍，本文将对腾讯御见UEBA相关技术进行介绍，有兴趣欢迎交流。

一：御见UEBA技术架构

御见UEBA技术架构如下图所示，主要包括3个部分：数据采集，智能检测分析平台，行为风险评估。UEBA采集多源数据例如登录日志，访问日志，其他安全产品日志，流量数据等，并对多源日志进行关联、分析、检测，基于行为分析等多种方法识别政企内部的用户风险和业务风险。

1. 数据采集

UEBA采集的数据源主要有三类：登录日志；访问日志；其他日志。

登录日志：主要记录用户认证登录业务、系统或应用的行为日志。例如：IAM统一认证登录日志，IOA登录认证日志，VPN日志，核心业务登录日志，AD日志，LDAP日志等等；

访问日志：主要记录用户认证登录成功后访问业务、系统或应用产生的行为日志。例如：里约网关访问日志，IOA应用访问日志，堡垒机日志，数据库审计日志，门禁日志，其他核心业务访问日志等等；

其他日志：主要包括其他安全产品日志，流量日志。例如：DLP日志，IOA日志，威胁情报，flow数据，其他安全产品日志等等。

2. 智能检测分析平台

智能检测分析平台为UEBA提供了主要的关联检测分析能力，一方面智能检测模块在产品上以可配置的基线建模平台的形式提供了画像体系构建、行为建模能力；另一方面智能分析模块根据场景进行风险检测、风险评估，并且基于风险评估结果进行动态打分，最终用户实体将以风险分数排序的方式展示给运营人员。

智能检测和智能分析将通过自适应学习、在线学习、离线学习、集成学习、强化学习等方式学习预测。

3. 行为风险评估

行为风险评估主要包括根据特定场景风险评估和用户实体综合风险打分。特定场景风险主要对用户进行恶意用户分析、失陷用户分析、违规用户分析、离职员工风险分析，对业务进行业务滥用分析、数据泄露分析、业务异常分析、业务运行状态监控等分析，最后综合所有的特定场景风险以用户实体的维度综合风险评分。

二：智能检测分析平台 

智能检测分析平台为UEBA提供了主要的关联检测分析能力，智能检测分析平台主要包括4大部分：画像体系，行为建模，自适应风险评估，层次动态打分。智能检测分析平台首先关联多源日志构建画像体系，然后基于完备的画像体系进行行为建模，通过行为建模对用户实体进行行为风险评估，最终将所有用户实体风险事件送入层次动态打分机制，完成用户实体的最终风险评分。

1. 画像体系

御见UEBA分析的对象主要包括用户、设备、资产、应用等等，当多源日志接入以后会自动构建用户实体画像体系，持续丰富更新用户实体的静态画像和动态画像。

用户实体静态画像：及时更新维护用户实体的静态信息，例如：用户身份、部门、岗位、权限、账号；设备归属；资产身份及重要性；应用敏感度等等。

用户实体动态画像：持续监控用户实体行为建立动态画像。

基于Spark计算引擎实时监控用户实体的行为统计提取行为特征，并通过机器学习算法基于分析对象行为特征建立历史基线画像、同类画像及动态分组；分析对象的行为不是静态不变而是随着时间动态变化的，统计画像、历史基线画像和同类画像就构成了分析对象的动态画像，用来刻画分析对象的动态个性。

动态画像例如：用户访问敏感数据的历史频次等等；用户当天访问某个资产的时间，地点，操作行为等等；资产与其他资产通信情况或用户访问资产情况等等；设备当前登录次数，使用状态等等。

2. 行为建模

画像体系构建，一方面实时更新一方面送入行为建模。因为接入海量的多源日志数据并且对每个用户和实体进行实时监控，单机有性能瓶颈问题所以我们基于大数据计算引擎Spark搭建了行为基线建模平台（可配置的基线建模平台），并且支持简单拖拽（不用编写代码）即可快速完成行为建模调试及生成环境上线。可配置的基线建模平台数据流图如下图所示，Spark读取多源数据，经过预处理、数据转换、特征提取、AI引擎、可解释性模块、决策引擎，完成整个行为基线建模流程。下面将通过基线建模、可解释性、时间序列、行为分析等方面介绍。

1) 分布式单体基线建模/群体基线建模

刻画一个用户或一个实体在某些场景下是否有异常，我们一方面可以分析用户实体的历史行为，对历史基线建模（比如1个月），如果当前用户实体行为偏离历史一个月的正常行为，那么我们需要关注分析对象是否出现行为偏离历史行为异常。另一方面可以分析用户同类行为，对同类基线建模（比如同组或者同岗位等），如果当前用户实体行为偏离同类行为，那么我们同样需要关注分析对象是否出现了偏离同类基线行为异常。无论是异于自身历史行为或同类行为，都应该引起关注，所以我们需要对每个分析对象建立同类基线及历史基线。

UEBA通过基于spark的行为基线建模平台分布式并行的对每一个分析对象（用户或应用等实体）基于历史基线建模和对同类基于群体基线建模。

单体基线建模：如上图所示，基线建模平台会根据场景自动收集历史一段时间日志（例如1个月），对每个分析对象历史行为建模，刻画用户历史正常行为模式，以用来预测识别当前分析对象的行为是否异常。

群体基线建模: 如上图所示，基线建模平台会根据场景自动收集分组日志（同组、同部门或同岗位等），对每个分组建立同类基线，客户用户同组正常行为模式，以用来预测识别当前分析对象的行为是否异常。

2) 可解释性

可解释性：企业场景下，为了客户快速定位威胁，检测结果必须具有可解释性。即模型既要有规则没有的发现未知的能力同时要像规则一样有较好的可解释性。

基于数据及检测场景特点，我们将行为建模算法主要分为两类：时间序列建模和行为分析建模。

时间序列建模的可解释性：时间序列有天然的可解释性，将时间序列数据及异常点可视化展示即可，如下图示例可见。

                离群点                                         拐点

行为分析建模的可解释性：我们在行为分析算法后增加z-score可解释性模块，用来解释模型。z-score 可解释性模块的输出是引起异常最重要的特征集合、特征值及偏离程度，这些指标能很好的解释模型结果。

3) 时间序列建模

时间序列建模是将历史数据在时间维度上按先后顺序构建时间序列，并通过一系列相关模型进行建模识别潜在模式，以便对后续数据进行预测或者异常检测。

根据时间序列本身的特点，我们将时间序列分为周期性的时间序列，和非周期性的时间序列。对不同类型的时间序列应用不同的算法建模。例如：周期性的时间序列应用STL, Holt-Winters等算法建模；非周期性的时间序列应用小波变换等算法建模。

根据时间序列异常类型不同，我们将时间序列异常区分为离群点异常，拐点异常，子序列异常。

时间序列建模加上异常检测可实现离群点检测，拐点检测，异常序列检测等功能。因不同特点的时间序列数据没法在同一个算法上达到最好的效果，所以这里的时间序列算法纳入了不同特点算法以适应不同类型的应用。

4) 行为分析建模

行为分析建模主要包括历史行为分析建模和同类行为分析建模两种模式。

基于历史行为分析建模：基于历史一段时间数据对每个对象建立历史基线，如果企业内部有10W个用户，那么行为分析建模模块会分布式建立10W个基线模型，以用来后续对每个用户识别异常行为。

基于同类行为分析建模：基于同类对象建立同类基线，每个分组建模一个基线模型，例如部门基线，岗位基线等等。

行为分析建模集成了多种算法例如基于推荐的、基于重构的、基于聚类的、基于半监督、有监督等算法，我们可以根据不同场景选择不同算法来快速完成行为分析建模。

三：行为风险评估

1. 自适应风险评估

综合静态画像和动态画像完整的刻画了用户实体，基于画像数据进行行为建模、风险分析、风险评估等等。

用户风险评估：

基于用户画像根据不同场景进行风险评估，进而获得用户的登录风险；访问风险；账号权限滥用风险；数据外泄风险；特殊权限操作风险；账号失陷风险；敏感数据访问风险；数据访问异常风险等等。

用户风险评估将通过实时或离线的方式持续对每个用户的风险场景进行异常检测及关联打分，并最终以风险时间线的形式展示，以备后续进行运营调查。

设备、资产或应用风险评估：

基于应用、设备、资产或应用画像根据不同情况进行风险评估，例如：设备异地登录风险；大量新增设备风险；应用访问次数激增风险；资产外部告警风险；用户访问资产异常风险等等。

应用、设备、资产或应用风险评估将通过实时或离线方式持续对每个设备或资产的风险异常检测及关联打分，并最终以风险时间线的形式展示，以备后续基于风险评估运营调查。

a. 风险评估不同客户不同模型：风险评估需要适配不同客户环境自适应学习，客户环境是复杂的，不同客户使用不同模型，要求我们需要根据客户真实数据训练模型，不能完全依赖模拟数据。

b. 风险评估同一客户不同环境不同模型：即使同一客户环境，风险评估也需要根据时间推移自适应学习， 客户环境下的数据并非静态不变而是动态变化的，例如员工权限变化、员工岗位变化、服务器角色的变更、服务器业务增删等等，这些变化都可能引起之前训练的模型失效。所以即使是同一客户环境下，我们也需要动态适配客户环境，根据时间推移自适应学习。

如何自适应学习：

自适应学习主要采取训练数据更新、模型自适应更新、动态评价三个步骤来实现：

a. 训练数据更新：基于滑动时间窗口将最近的数据纳入到训练数据中。比如：行为异常检测模型需要x天数据进行训练，每次训练使用最近的x天时间窗口的数据。

b. 模型自适应更新：时间序列异常检测我们根据任务调度间隔获取x周最新特征数据做训练同时检测。行为分析异常检测需要根据x天历史或同类行为数据训练，一般训练时间较长，我们根据反馈数据误报升高时动态更新模型。

c. 动态评价：内置场景检测在上线之前我们会对检测能力进行离线评价；然而真实客户环境比较复杂，往往会导致误报增加，如何在不同的客户环境下进行动态评价变得尤为重要。对一部分场景，检测模型会根据测试样例和每次的训练数据动态调整置信度参数控制误报情况。另外提供反馈机制，通过反馈自动学习。

2) 在线学习

对UEBA一部分场景需要及时将风险呈现（例如几分钟之内），对于这部分场景风险评估采取在线学习方式，实时预测识别风险。如下图所示针对一部分实时场景，基于spark streaming在线学习从行为建模中读取实时模型，从画像体系中读取实时画像，在线预测识别风险。

3) 离线学习

对UEBA一部分场景我们需要基于较长时间间隔的画像特征进行建模和预测，比如一天内用户访问行为等，那么我们需要离线建模及预测。如上图所示，基于Spark离线学习同样从行为建模中读取离线模型，从画像体系中读取离线画像特征，基于模型及离线数据识别风险。

4) 集成学习

集成学习可以通过集成多种算法同时对同一个风险场景学习预测，进行风险评估，以达降低误报、预测识别更精准的效果。例如我们可以同时集成单体基线建模和群体基线建模来综合评估用户实体风险。如下图所示：

2. 层次动态打分

经过风险评估以后，会识别出每个分析对象的风险场景及置信度。层次动态打分的输入是所有风险场景及置信度及重要性权重，输出是每个用户实体最终的风险分数。风险场景置信度由风险评估直接给出，风险场景的重要性一般是人工经验指定，但是在不同行业不同客户那里，相同的风险场景的重要性却相差较大。风险分的公式如下：

，其中risks指风险评估检测识别出的用户实体相关场景的风险集合，confidence指风险置信度，severity指风险严重程度，context指风险发生的上下文包括时间、前后关系等等，context主要通过影响severity来影响score。所以严重程度的权重对打分有很重要的作用。

御见UEBA采用层次动态打分的机制，前期主要基于推荐及策略将人工经验融入其中进行风险权重调整再计算出风险总分。后期用户有了长期反馈以后，启动基于强化学习动态打分模型，自动调整风险场景权重及用户实体风险总分。

1) 基于推荐及策略的风险权重调整

基于策略的风险权重调整：

我们融入多种人工经验到策略中自动调整风险权重，例如：时间衰减；相同风险频繁出现动态降低权重；风险上下文命中自动增加权重等等。

基于推荐的风险权重调整：

针对有些特定场景我们可以通过推荐的算法自动预测风险事件权重，例如：首次访问敏感数据风险；

基于推荐算法的主要思路是将用户和同类的历史访问行为及用户上下文信息考虑进去，利用推荐算法FM预测用户访问每个实体的概率。我们将这个概率作为首次访问敏感数据风险场景的重要性权重。

2) 基于强化学习动态打分模型

UEBA部署前期阶段有较少的反馈，所以我们主要通过推荐及策略的方式调整重要性权重进行打分。当后期随着运营人员不断的反馈，前期产生的权重将作为初始参数与反馈的结果一同进入到基于强化学习的动态打分模型中，模型通过持续的奖赏和惩罚，动态调整权重及风险分数。

四：总结

腾讯御见UEBA主要围绕智能检测分析平台构建了支撑UEBA的关联检测分析能力，智能检测分析平台首先关联多源日志构建画像体系，然后基于完备的画像体系进行行为建模，通过行为建模对用户实体进行行为风险评估，最终将所有用户实体风险事件送入层次动态打分机制，完成用户实体的最终风险评分。本文分别对画像体系，行为建模，自适应风险评估，层次动态打分进行了简单介绍，有兴趣欢迎交流。

阅读原文

跳转微信打开

腾讯御见UEBA面向政企办公安全、数据安全治理、员工行为管理，使用一系列分析方法通过分析用户实体（用户、应用、设备、主机等）相关行为日志构建用户实体画像，然后基于用户实体画像进行风险检测、风险分析、风险评估，最终识别内部风险用户和风险实体。

引子：腾讯御见UEBA（用户实体行为分析）面向政企办公安全、数据安全治理、员工行为管理，使用一系列分析方法（统计学习、机器学习等高级分析方法）通过分析用户实体（用户、应用、设备、主机等）相关行为日志构建用户实体画像（静态画像、动态画像），然后基于用户实体画像进行风险检测、风险分析、风险评估，最终识别内部风险用户和风险实体。御见UEBA是单独的解决方案或产品，也可以作为一种高级分析能力或模块嵌入到御见SOC中。目前我们御见UEBA产品最新版本已经发布，本文会结合最新版本对御见UEBA进行简单介绍。

一、背景

2019 verizon数据泄露调查报告指出，34%的数据泄露涉及企业内部人员。内部人员对企业构成了特殊的威胁，传统安全产品无法检测，因为他们有权限访问内部系统，通常能够绕过安全措施，从而给安全团队造成安全盲点。大多数网络安全专家都认为，企业网络安全系统中最薄弱的环节是其员工。据网络安全咨询公司CrowdStrike研究发现，百分之五到百分之十的员工会点击钓鱼邮件，点击钓鱼邮件受害者的计算机将自动运行恶意程序并被完全控制，攻击者进而通过合法的身份账号做数据窃取等不法操作而不被发现。内部威胁，内部人员风险对企业安全尤其重要。

攻击变得越来越复杂，传统安全解决方案大多基于规则的单点检测，往往检测不到或发现更多未知威胁。针对越来越复杂的攻击，需要打破单点检测引入行为分析等高级分析方法。

在SANS研究所最近的一项调查中，受访者确定了安全组织的三大优先事项：更好的调查功能，更多具有调查能力的人员进行运营和发现数据与信息的能力。运营压力大运营人力不足是最常见的安全运营中心（SOC）挑战。

企业面临的安全挑战主要有以下几个方面：

1. 内部威胁对企业安全尤其重要；2.攻击越来越复杂；3.运营人力不足。

UEBA解决方案从多个来源接收数据并所有数据源关联在一起，使用统计学习、机器学习等高级分析方法，对用户和实体正常行为建模，识别偏离正常行为的风险用户和风险实体，实体包括应用，主机，设备等。最后通过风险打分的形式将风险高的用户实体优先呈现给运营人员，而不会被大量告警淹没。UEBA的机器学习等高级分析方法通过行为建模进行自我调整，发现未知风险。 

二、UEBA现状及发展趋势

用户和实体行为分析（UEBA）是企业安全性中增长最快的领域之一，据Gartner称，其年复合增长率为48％。

Gartner 2019年“Market Guide for User and Entity Behavior Analytics”指出:

① 用户和实体行为分析技术已经被大中型企业在一系列使用案例中的使用所证明。

Gartner主要从3个维度定义UEBA（场景，分析方法，数据源），如下图所示：

数据：UEBA采集多源数据，例如事件日志，用户上下文数据，网络流量等等；关联更多的数据能更好刻画用户实体的行为活动，能更好的通过分析方法识别未知风险。

场景：UEBA需要清楚的定义检测或解决的场景，明确每个场景输出才能体现产品价值。

分析方法：多种分析方法，从传统的基于规则到UEBA采用的一系列分析方法包括规则、统计学习、有监督、无监督、深度学习、GAN等高级分析方法。

② UEBA可以是一种解决方案的单独产品，也可以作为UEBA特性嵌入到其他安全产品中。未来UEBA将以提供高级分析能力或模块的方式逐渐嵌入到SIEM等安全产品中。

如“Technology Insight for the Modern SIEM”中所述，在2018年和2019年迄今为止，我们看到SIEM工具和UEBA工具之间的界限越来越模糊。 SIEM借助UEBA在分析方面变得更好，并且可以提供检测复杂的场景。 同时，UEBA供应商将重点放在更好的数据管理和可操作性上，这使它们更接近SIEM。

在这项研究中跟踪的UEBA产品供应商中，已经有一半还提供了SIEM产品，通常以不同的模块的形式提供它们，以提供更完整的威胁检测技术。

同样，一些SIEM供应商也逐渐将UEBA模块嵌入到SIEM中或提供高级分析功能。

③ 一些买家发现，UEBA的部署需要较多的时间和精力，添加新的或自定义的检测场景可能很艰巨，需要数据科学和分析方面的专业知识。

三、腾讯御见UEBA及产品特性

腾讯御见UEBA（用户实体行为分析）面向政企办公安全、数据安全、员工行为管理，使用一系列分析方法（统计学习、机器学习等高级分析方法）通过分析用户实体（用户、应用、设备、主机等）相关行为日志构建用户实体画像（静态画像、动态画像），然后基于用户实体画像进行风险检测、风险分析、风险评估，最终识别内部风险用户和风险实体。

御见UEBA是单独的解决方案或产品，也可以作为一种高级分析能力或模块嵌入到御见SOC中。御见UEBA提供两种方式：一种是UEBA单独产品；一种是嵌入到御见SOC作为UEBA模块，并给产品提供高级分析能力。

1. 政企办公安全: 保障企业办公系统安全，支持企业远程办公风险监测。

2. 数据安全治理：构建企业内部数据泄露和业务数据窃取的统一监控平台。

3. 员工行为管理：及时发现违规、实陷和恶意员工，构建员工多维度画像，从内部保障企业安全。

违规用户：

① 存在账号共享情况，共享账号带来风险；

② 内部高权限用户进行违规操作，违规退改；

③ 部分用户大量进行敏感查询并泄漏敏感信息。

失陷用户：

① 账号丢失；

② 账号被暴力破解。

恶意用户：

① 用户进行非法高危操作：删除数据、修改业务信息；

② 用户利用逻辑漏洞干扰正常业务；

③ 用户窃取敏感数据信息。

产品特性：

御见UEBA有以下产品特性：

① 人员风险可视，行为可追溯

利用统一的员工身份，全面追踪风险员工行为，刻画人员行为画像（静态画像、动态画像），直观感知人员风险。

② 应用数据打通，发现潜在威胁

移植SOC关联分析安全经验，关联多个应用数据，复原用户完整风险操作，识别更多潜在威胁。

③ 灵活的自定义仪表，满足各类监控需求

支持自定义仪表板，提供丰富的各类风险数据监控。

④ 应用统一安全管控，全局视角

提供全局视角，告别单一应用单独管控，企业所有应用纳入统一安全体系。

⑤ 丰富的安全场景和模型

内置4大类20余种安全场景，覆盖账号安全、办公安全、数据安全和业务安全。

⑥ 自定义机器学习检测框架

系统支持自定义行为基线建模能力。为了缓解UEBA的部署添加新的或自定义的检测场景，需要数据科学和分析方面的专业知识，费时费力的问题，我们提供自定义机器学习检测平台，可以直接拖拽不用编写代码，方便便捷完成基线建模调试及生产环境模型部署。

四、腾讯御见UEBA的产品架构

御见UEBA的产品架构如下图所示：

用户应用数据采集：UEBA从多个数据源采集数据供后续关联分析，比如应用访问日志，堡垒机日志，主机风险日志，数据库审计日志等等。

风险智能检测：将多源数据输入到风险智能检测引擎进行数据分析，通过统计学习、有监督无监督、异常检测等方法构建单体行为基线、群体行为基线以检测用户应用偏离基线等潜在风险。

用户应用风险输出：通过统计学习、机器学习等一系列分析方法识别应用风险、数据风险、人员风险、计算环境安全风险。

风险监控调查：统计各项应用运营指标，企业应用整体运营状况一目了然。持续监控应用运行风险，应用安全心中有数；多种算法规则感知企业应用风险，应用和人员风险全面感知。

五、腾讯御见UEBA主要功能

腾讯御见UEBA提供多源数据接入、日志检索、用户实体画像、用户实体风险分析、用户权限梳理、应用业务梳理、用户实体风险评分、仪表盘、AI检测平台等多种功能。

其中核心功能主要有：用户实体画像、用户实体风险分析、用户权限梳理、应用业务梳理、用户实体风险评分等。

特色功能有：AI自定义检测平台（可配置的基线建模平台）

下面结合UEBA产品，进行简单介绍。

御见UEBA会从用户和应用的视角，基于多源日志进行大数据分析，刻画用户实体静态画像和动态画像，并基于画像信息进行风险评估，并利用用户实体的综合风险分排序及风险画像信息、风险评估信息进行进一步运营调查。

用户实体风险评分：风险量化评分会经过风险打分，风险合并等多种方式明确需要优先处理的人员和应用，减轻运营人员运营压力。

行为分析首页

用户实体画像：御见UEBA分析的对象主要包括用户、设备、资产、应用等等，建立用户实体画像库，持续丰富更新用户实体的静态画像和动态画像。

       用户静态画像                           应用静态画像

           用户动态画像                         应用动态画像

用户/应用行为风险评估: 综合静态画像和动态画像完整了刻画用户实体，后续可基于画像数据进行风险检测、风险分析、风险评估等等；并以操作行为时间线及风险原因数据下钻举证的形式展现。

      操作行为时间线                       风险评估原因举证

业务/账号梳理: 对客户的业务及账号进行梳理，直观展示应用系统业务接口和当前用户账号使用情况，列举静默账号等风险账号，梳理各接口访问及失活接口等风险状况，发现被安全运营人员忽视的业务接口，了解自身业务攻击面。

         账号梳理                             账号详情

         业务梳理                             业务详情

可配置的基线建模平台：产品集成了可配置的行为基线建模平台用来进行行为基线建模，平台内置了30+种特征提取转换函数、6种统计算子；7种行为基线建模算法；3种策略去误报方法；用户只需要通过简单拖拽的方式即可完成基线建模，无需编写代码。

可配置的基线建模平台的优点：

①清晰明确的向客户展示基线建模过程中所使用的数据、特征、算法、策略等各个模块信息及整个基线建模的流程。

②开放基线建模能力给用户，直接拖拽不用编写代码即可快速完成基线建模。

     场景自定义                            基线建模任务流

六、御见UEBA典型场景

御见UEBA内置了4类20多种典型场景以覆盖账号安全、办公安全、数据安全和业务安全，包括账号风险，离职员工权限风险，内部数据窃取，研发凭证外泄风险，研发数据泄漏风险，研发运维恶意操作等等。

账号风险：针对企业员工VPN、OA等办公应用账号被攻击者窃取的风险监控。

离职员工权限风险：针对离职员工仍然具有权限，登录办公应用或业务系统的风险监控。

内部数据窃取：针对企业员工对内部OA、HR等系统数据的异常访问和窃取风险监控。

研发凭证外泄风险：针对研发运维账号外泄，存在外部异常登录行为的监控。

研发数据泄漏风险：针对内部源代码、数据库等研发数据泄漏风险的监控。

研发运维恶意操作：针对研发运维人员的高风险操作检测，以及异常行为预警。

典型场景示例：

1. 用户账号失陷检测

① 内部人员误点钓鱼邮件，泄露账号密码。

② 黑客使用内部账号密码登录OA、营销、财经等多个内部系统，寻找有价值数据，找到数据后尝试大量下载。

③ 御见UEBA通过对内部人员进行行为画像，建立安全基线，检测到多种行为异常，关联分析发现疑似内部人员账号失陷，及时告警。

④ 安全运营人员及时联系员工确认，并封禁该员工权限。

⑤ 安全运营人员借助应用安全中心对该账号行为进行审计，确认涉及的内部系统，查询其他内部系统监控记录，确认最终影响范围。

2. 应用数据泄露检测

① 应用出现逻辑漏洞。

② 黑客通过该暴露的漏洞，大量获取应用数据。

③ 黑客为绕过访问频率限制，控制多个账号去尝试获取数据。

④ 御见UEBA通过应用整体运行监控，发现应用访问量异常、访问用户量异常，同时发现部分用户访问行为异常，及时告警。

⑤ 运营人员根据告警判断出现数据泄露，根据应用安全中心风险检测结果定位到风险接口，协助修复漏洞，防止进一步数据泄露。

⑥ 根据检测得到的多个黑客控制的风险账号的行为记录，以及应用的访问记录和数据访问记录，评估数据泄露规模，进行进一步总结整改。

参考资料：

2019Gartner, Market Guide for User and Entity Behavior Analytics

2019Gartner, Market Trends: UEBA Providers Must Embrace Specialization

2019Verizon, 2019 Data Breach Investigations report

该账号主要围绕智能化技术如何帮助企业提升网络安全水平展开，内容涉及机器学习、大数据处理等智能化技术在安全领域的实践经验分享，业界领先的产品和前沿趋势的解读分析等。通过分享、交流，推动安全智能的落地、应用。欢迎关注~

阅读原文

跳转微信打开

腾讯御见UEBA面向政企办公安全、数据安全治理、员工行为管理，使用一系列分析方法通过分析用户实体（用户、应用、设备、主机等）相关行为日志构建用户实体画像，然后基于用户实体画像进行风险检测、风险分析、风险评估，最终识别内部风险用户和风险实体。

引子：腾讯御见UEBA（用户实体行为分析）面向政企办公安全、数据安全治理、员工行为管理，使用一系列分析方法（统计学习、机器学习等高级分析方法）通过分析用户实体（用户、应用、设备、主机等）相关行为日志构建用户实体画像（静态画像、动态画像），然后基于用户实体画像进行风险检测、风险分析、风险评估，最终识别内部风险用户和风险实体。御见UEBA是单独的解决方案或产品，也可以作为一种高级分析能力或模块嵌入到御见SOC中。目前我们御见UEBA产品最新版本已经发布，本文会结合最新版本对御见UEBA进行简单介绍。

一、背景

2019 verizon数据泄露调查报告指出，34%的数据泄露涉及企业内部人员。内部人员对企业构成了特殊的威胁，传统安全产品无法检测，因为他们有权限访问内部系统，通常能够绕过安全措施，从而给安全团队造成安全盲点。大多数网络安全专家都认为，企业网络安全系统中最薄弱的环节是其员工。据网络安全咨询公司CrowdStrike研究发现，百分之五到百分之十的员工会点击钓鱼邮件，点击钓鱼邮件受害者的计算机将自动运行恶意程序并被完全控制，攻击者进而通过合法的身份账号做数据窃取等不法操作而不被发现。内部威胁，内部人员风险对企业安全尤其重要。

攻击变得越来越复杂，传统安全解决方案大多基于规则的单点检测，往往检测不到或发现更多未知威胁。针对越来越复杂的攻击，需要打破单点检测引入行为分析等高级分析方法。

在SANS研究所最近的一项调查中，受访者确定了安全组织的三大优先事项：更好的调查功能，更多具有调查能力的人员进行运营和发现数据与信息的能力。运营压力大运营人力不足是最常见的安全运营中心（SOC）挑战。

企业面临的安全挑战主要有以下几个方面：

1. 内部威胁对企业安全尤其重要；2.攻击越来越复杂；3.运营人力不足。

UEBA解决方案从多个来源接收数据并所有数据源关联在一起，使用统计学习、机器学习等高级分析方法，对用户和实体正常行为建模，识别偏离正常行为的风险用户和风险实体，实体包括应用，主机，设备等。最后通过风险打分的形式将风险高的用户实体优先呈现给运营人员，而不会被大量告警淹没。UEBA的机器学习等高级分析方法通过行为建模进行自我调整，发现未知风险。 

二、UEBA现状及发展趋势

用户和实体行为分析（UEBA）是企业安全性中增长最快的领域之一，据Gartner称，其年复合增长率为48％。

Gartner 2019年“Market Guide for User and Entity Behavior Analytics”指出:

① 用户和实体行为分析技术已经被大中型企业在一系列使用案例中的使用所证明。

Gartner主要从3个维度定义UEAB（场景，分析方法，数据源），如下图所示：

数据：UEBA采集多源数据，例如事件日志，用户上下文数据，网络流量等等；关联更多的数据能更好刻画用户实体的行为活动，能更好的通过分析方法识别未知风险。

场景：UEBA需要清楚的定义检测或解决的场景，明确每个场景输出才能体现产品价值。

分析方法：多种分析方法，从传统的基于规则到UEBA采用的一系列分析方法包括规则、统计学习、有监督、无监督、深度学习、GAN等高级分析方法。

② UEBA可以是一种解决方案的单独产品，也可以作为UEBA特性嵌入到其他安全产品中。未来UEBA将以提供高级分析能力或模块的方式逐渐嵌入到SIME等安全产品中。

如“Technology Insight for the Modern SIEM”中所述，在2018年和2019年迄今为止，我们看到SIEM工具和UEBA工具之间的界限越来越模糊。 SIEM借助UEBA在分析方面变得更好，并且可以提供检测复杂的场景。 同时，UEBA供应商将重点放在更好的数据管理和可操作性上，这使它们更接近SIEM。

在这项研究中跟踪的UEBA产品供应商中，已经有一半还提供了SIEM产品，通常以不同的模块的形式提供它们，以提供更完整的威胁检测技术。

同样，一些SIEM供应商也逐渐将UEBA模块嵌入到SIEM中或提供高级分析功能。

③ 一些买家发现，UEBA的部署需要较多的时间和精力，添加新的或自定义的检测场景可能很艰巨，需要数据科学和分析方面的专业知识。

三、腾讯御见UEBA及产品特性

腾讯御见UEBA（用户实体行为分析）面向政企办公安全、数据安全、员工行为管理，使用一系列分析方法（统计学习、机器学习等高级分析方法）通过分析用户实体（用户、应用、设备、主机等）相关行为日志构建用户实体画像（静态画像、动态画像），然后基于用户实体画像进行风险检测、风险分析、风险评估，最终识别内部风险用户和风险实体。

御见UEBA是单独的解决方案或产品，也可以作为一种高级分析能力或模块嵌入到御见SOC中。御见UEBA提供两种方式：一种是UEBA单独产品；一种是嵌入到御见SOC作为UEBA模块，并给产品提供高级分析能力。

1. 政企办公安全: 保障企业办公系统安全，支持企业远程办公风险监测。

2. 数据安全治理：构建企业内部数据泄露和业务数据窃取的统一监控平台。

3. 员工行为管理：及时发现违规、实陷和恶意员工，构建员工多维度画像，从内部保障企业安全。

违规用户：

① 存在账号共享情况，共享账号带来风险；

② 内部高权限用户进行违规操作，违规退改；

③ 部分用户大量进行敏感查询并泄漏敏感信息。

失陷用户：

① 账号丢失；

② 账号被暴力破解。

恶意用户：

① 用户进行非法高危操作：删除数据、修改业务信息；

② 用户利用逻辑漏洞干扰正常业务；

③ 用户窃取敏感数据信息。

产品特性：

御见UEBA有以下产品特性：

① 人员风险可视，行为可追溯

利用统一的员工身份，全面追踪风险员工行为，刻画人员行为画像（静态画像、动态画像），直观感知人员风险。

② 应用数据打通，发现潜在威胁

移植SOC关联分析安全经验，关联多个应用数据，复原用户完整风险操作，识别更多潜在威胁。

③ 灵活的自定义仪表，满足各类监控需求

支持自定义仪表板，提供丰富的各类风险数据监控。

④ 应用统一安全管控，全局视角

提供全局视角，告别单一应用单独管控，企业所有应用纳入统一安全体系。

⑤ 丰富的安全场景和模型

内置4大类20余种安全场景，覆盖账号安全、办公安全、数据安全和业务安全。

⑥ 自定义机器学习检测框架

系统支持自定义行为基线建模能力。为了缓解UEBA的部署添加新的或自定义的检测场景，需要数据科学和分析方面的专业知识，费时费力的问题，我们提供自定义机器学习检测平台，可以直接拖拽不用编写代码，方便便捷完成基线建模调试及生产环境模型部署。

四、腾讯御见UEBA的产品架构

御见UEBA的产品架构如下图所示：

用户应用数据采集：UEBA从多个数据源采集数据供后续关联分析，比如应用访问日志，堡垒机日志，主机风险日志，数据库审计日志等等。

风险智能检测：将多源数据输入到风险智能检测引擎进行数据分析，通过统计学习、有监督无监督、异常检测等方法构建单体行为基线、群体行为基线以检测用户应用偏离基线等潜在风险。

用户应用风险输出：通过统计学习、机器学习等一系列分析方法识别应用风险、数据风险、人员风险、计算环境安全风险。

风险监控调查：统计各项应用运营指标，企业应用整体运营状况一目了然。持续监控应用运行风险，应用安全心中有数；多种算法规则感知企业应用风险，应用和人员风险全面感知。

五、腾讯御见UEBA主要功能

腾讯御见UEBA提供多源数据接入、日志检索、用户实体画像、用户实体风险分析、用户权限梳理、应用业务梳理、用户实体风险评分、仪表盘、AI检测平台等多种功能。

其中核心功能主要有：用户实体画像、用户实体风险分析、用户权限梳理、应用业务梳理、用户实体风险评分等。

特色功能有：AI自定义检测平台（可配置的基线建模平台）

下面结合UEBA产品，进行简单介绍。

御见UEBA会从用户和应用的视角，基于多源日志进行大数据分析，刻画用户实体静态画像和动态画像，并基于画像信息进行风险评估，并利用用户实体的综合风险分排序及风险画像信息、风险评估信息进行进一步运营调查。

用户实体风险评分：风险量化评分会经过风险打分，风险合并等多种方式明确需要优先处理的人员和应用，减轻运营人员运营压力。

行为分析首页

用户实体画像：御见UEBA分析的对象主要包括用户、设备、资产、应用等等，建立用户实体画像库，持续丰富更新用户实体的静态画像和动态画像。

       用户静态画像                           应用静态画像

           用户动态画像                         应用动态画像

用户/应用行为风险评估: 综合静态画像和动态画像完整了刻画用户实体，后续可基于画像数据进行风险检测、风险分析、风险评估等等；并以操作行为时间线及风险原因数据下钻举证的形式展现。

      操作行为时间线                       风险评估原因举证

业务/账号梳理: 对客户的业务及账号进行梳理，直观展示应用系统业务接口和当前用户账号使用情况，列举静默账号等风险账号，梳理各接口访问及失活接口等风险状况，发现被安全运营人员忽视的业务接口，了解自身业务攻击面。

         账号梳理                             账号详情

         业务梳理                             业务详情

可配置的基线建模平台：产品集成了可配置的行为基线建模平台用来进行行为基线建模，平台内置了30+种特征提取转换函数、6种统计算子；7种行为基线建模算法；3种策略去误报方法；用户只需要通过简单拖拽的方式即可完成基线建模，无需编写代码。

可配置的基线建模平台的优点：

①清晰明确的向客户展示基线建模过程中所使用的数据、特征、算法、策略等各个模块信息及整个基线建模的流程。

②开放基线建模能力给用户，直接拖拽不用编写代码即可快速完成基线建模。

     场景自定义                            基线建模任务流

六、御见UEBA典型场景

御见UEBA内置了4类20多种典型场景以覆盖账号安全、办公安全、数据安全和业务安全，包括账号风险，离职员工权限风险，内部数据窃取，研发凭证外泄风险，研发数据泄漏风险，研发运维恶意操作等等。

账号风险：针对企业员工VPN、OA等办公应用账号被攻击者窃取的风险监控。

离职员工权限风险：针对离职员工仍然具有权限，登录办公应用或业务系统的风险监控。

内部数据窃取：针对企业员工对内部OA、HR等系统数据的异常访问和窃取风险监控。

研发凭证外泄风险：针对研发运维账号外泄，存在外部异常登录行为的监控。

研发数据泄漏风险：针对内部源代码、数据库等研发数据泄漏风险的监控。

研发运维恶意操作：针对研发运维人员的高风险操作检测，以及异常行为预警。

典型场景示例：

1. 用户账号失陷检测

① 内部人员误点钓鱼邮件，泄露账号密码。

② 黑客使用内部账号密码登录OA、营销、财经等多个内部系统，寻找有价值数据，找到数据后尝试大量下载。

③ 御见UEBA通过对内部人员进行行为画像，建立安全基线，检测到多种行为异常，关联分析发现疑似内部人员账号失陷，及时告警。

④ 安全运营人员及时联系员工确认，并封禁该员工权限。

⑤ 安全运营人员借助应用安全中心对该账号行为进行审计，确认涉及的内部系统，查询其他内部系统监控记录，确认最终影响范围。

2. 应用数据泄露检测

① 应用出现逻辑漏洞。

② 黑客通过该暴露的漏洞，大量获取应用数据。

③ 黑客为绕过访问频率限制，控制多个账号去尝试获取数据。

④ 御见UEBA通过应用整体运行监控，发现应用访问量异常、访问用户量异常，同时发现部分用户访问行为异常，及时告警。

⑤ 运营人员根据告警判断出现数据泄露，根据应用安全中心风险检测结果定位到风险接口，协助修复漏洞，防止进一步数据泄露。

⑥ 根据检测得到的多个黑客控制的风险账号的行为记录，以及应用的访问记录和数据访问记录，评估数据泄露规模，进行进一步总结整改。

参考资料：

2019Gartner, Market Guide for User and Entity Behavior Analytics

2019Gartner, Market Trends: UEBA Providers Must Embrace Specialization

2019Verizon, 2019 Data Breach Investigations report

该账号主要围绕智能化技术如何帮助企业提升网络安全水平展开，内容涉及机器学习、大数据处理等智能化技术在安全领域的实践经验分享，业界领先的产品和前沿趋势的解读分析等。通过分享、交流，推动安全智能的落地、应用。欢迎关注~

阅读原文

跳转微信打开

无论是对于使用机器学习服务的用户，还是研发机器学习模型的算法工程师，机器学习的可解释性都是十分重要的。对于用户而言，由于许多关键的系统、服务都逐渐开始使用机器学习技术

写在前面：  

在腾讯安全的产品团队，随着产品的不断丰富，算法工程师面临越来越多的算法解释性问题。例如我们做流量侧的异常检测，不仅要给出算法判定的异常流量对，还要给出异常指标、给出大盘数据分布情况、要能够拉出原始流量，还要给出友好的解释语言，例如http流量中，某个通信对用了较多不常见的UA，且一直返回失败等。更复杂的情况，面对深度模型、集成模型等，我们也需要给用户提供有指导意义的、准确的样本解释。

起初在面对解释复杂模型的问题时，我曾一度认为这件事情是不可行的，起码不应该由工业界的人来做，因为当时理所当然的认为这是机器学习的理论研究范畴，而像深度模型的理论研究，众所周知的没有什么进展。而后，有一次跟别人讨论模型可解释性的问题，有同事简单介绍了模型无关的解释方法的思想，当时还认为“模型无关的解释”没有逻辑。但是后来，事实证明“模型无关的解释”完全可行，并且在一些产品中，该类解释方法更有实际价值。之后，为了扫除这个知识盲区，系统的了解了一下对这个问题的研究与成果，在这里尝试概括性的输出一下，正文如下：

引言：

无论是对于使用机器学习服务的用户，还是研发机器学习模型的算法工程师，机器学习的可解释性都是十分重要的。对于用户而言，由于许多关键的系统、服务都逐渐开始使用机器学习技术，例如人脸识别认证、信贷业务评审、视频内容审核、智能语音服务、智能医疗等，用户尤其是被“拒绝”的用户十分需要充足的理由来帮助他们理解自己为什么被拒绝。“如果我认为我是一个良好公民，而某一天突然被高铁站的人脸识别拒绝而导致我乘不了高铁，并且不附带任何解释，那么无论如何都是不可接受的，这对整个社会来说都将会是个灾难。”而对于算法工程师而言，理解模型更是一种基本素养，它可以帮助优化模型、控制模型，从而避免模型不可控的情况“在一些关键的服务中，模型不可控是非常可怕的”。

本文主要基于“interpretable machine learning”的内容，结合实际的产品研发，做了新的梳理，希望能帮助机器学习在产品中的良好落地。本文将内容组织为：（1）确定解释的程度；（2）选用合适的解释方法；（3）具有代表性的解释方法；（4）解释中用到的可视化手段；四个主要部分。

一、确定需要解释到哪种程度

当要解释模型的时候，首先需要考虑的是对“谁”解释，解释什么问题。这个决定了我们需要对模型解释到哪种程度，也会很大程度上影响我们选用的解释方法。明显的，当我们面对关键的服务，例如银行、医疗、安防、交通等，与面对一般的服务，例如推荐、匹配等，其需要解释的程度是不一样的。关键服务对可解释性的要求较高，而一般服务则没有那么强。另外，当给算法工程师做模型解释服务时，需要在特征及特征交互、联合概率等极细粒度的尺度上去做，以保证严谨和灵活性。

二、选用怎样的解释方法

目前的模型解释方法已经有一些成果，不过他们在解释类别、解释效果、计算量等方面大有不同。在介绍具体的解释方法之前，首先总结现有的研究结论，将这些方法做一个分类梳理，如下：

（1）本质上是否可解释：

A:本质上可解释：

       它指的是在应用中，由于使用了结构简单、容易理解和分解的模型，而使得对结果的解释可以基于模型本身的结构构成、计算逻辑进行解释。例如线性模型一类方法的预测结果可以简单视为多个特征的加权和，而树模型一类的方法可以视为多条规则的组合等。在实际中，如果对模型可解释性要求比较高，则可以直接选用较为简单的模型进行开发。

B:本质上难解释（事后解释）：

       由于模型复杂度和模型能力是息息相关，所以实际应用中，为了得到更好的性能，我们很多情况下不得不用一些复杂的模型，这也导致了模型结果缺乏可解释性。

       事后解释指的是针对这些较复杂的、本质上不可解释的模型，例如深度模型、广义非线性模型等，进行样本解释的一类方法。它的思路是，既然原模型不可解释，那就先忽略掉原模型，仅仅基于它的输出，进行基于样本或利用代理模型进行解释。由于实际中大部分的模型都是难解释的模型，因为该类方法也是使用的最为广泛的一类方法。

（2）是否是针对特定模型的解释：

A:基于特定模型的解释：

       它指的是针对某种特定类型的模型进行解释，从而针对性的解决特定模型输出结果的解释方法，该模型一般适用于本质上可解释的模型，并且通用性较低。

B:模型无关的解释：

       它指的是不管训练过程用了哪种模型，都可以对结果进行解释，与事后解释的方法类似，使用的较为广泛。

（3）是否支持对全局样本的解释：

A:针对局部样本的解释：

       它指的是针对某些样本，进行单独的解释，该类方法一般会依赖目标样本及其邻域进行解释，例如利用代理模型、数据原型等方法解释目标样本，但该类方法由于仅仅依赖部分样本，也导致它不能通用到每一个样本身上，需要对每一个样本进行单独的解释训练。如经典的LIME方法就是针对局部样本的解释。

B:全局样本的解释：

       该类解释方法能够适用于面对的所有样本，具有通用性。本质上可解释的模型，一般可以进行全局样本的解释。

（之前理解固执的认为解释模型只能从本质上进行解释才叫解释，经过了解之后，发现模型无关的解释才比较值得期待。之前可能还是太算法思维了。）

三、具有代表性的解释方法

        以下简单介绍下几种代表性的解释方法的核心思想，不涉及细节。

（1）针对线性模型的解释

这里指的线性模型是g=f(a0+a1*x1+a2*x2+...+a9*x9)，其中f为一个单调映射函数。特别的，当f为x-》x的映射时，g是一个线性回归模型，而f是一个概率映射时，g是一个逻辑回归模型。

由于线性模型具有“输出与特征的加权和相关”的特点，所以线性模型中可以很方便的拆解各个特征。针对线性模型，一种普遍的研究思路是“将单独一个特征的取值增加一个单位，而保持其他特征的取值不变，以观察输出的变化”。类似于一个偏导的概念。该偏导数能够说明某个特征对输出的影响，从而解释样本。

但线性模型也有问题，它要求“单独增加一个特征的值，而保持其他的特征取值不变”，这个要求会使得产生一些不合理的数据样本，从而使得解释具有一定的偏差。

（2）树模型

树模型的工作模式为根据特征的取值进行样本划分，最后使得每个区域的样本满足截止条件。树模型的工作模式比较简单，因此针对树模型的解释只需要简单的将样本划分过程可视化出来即可得到不错的效果。（线性模型和树模型常用作其他黑盒的代理模型）

（3）反事实解释

反事实解释的表述模式为“如果发生X，那么Y就会发生。”它寻找到Y结果的边界，并基于已有的数据样本，做最小的特征改动，越过边界，以生成反事实来进行解释，并且为了解释的效果，通常会选择一些符合常识、明显的特征生成反事实。例如解释银行贷款的场景时，可以使用该解释方式，“如果小明年龄大于25岁，那么他会申请到贷款。”反事实解释比较重视样本间的对比性，解释通俗易懂，比较友好。

（4）原型与批判

原型解释是面向算法工程师的一种解释方法，它能够帮助算法工程师了解数据分布。它的思路是在密度较高的区域寻找到原型，距离原型较远的数据点为批判。由此可见，原型与批判是一种基于密度的方法，它将质心当作原型，离群点当作批判。将该思路用到可解释性上时，算法工程师可以直接将原型和批判样本点分别打印出来，以理解数据分布。例如在做性别分类的时候，查看原型是否分别是两个性别的代表，而批判则可以帮助算法工程师理解，是什么样的badcase。（数据分布本身就是决定机器学习性能的因素，因此基于原型与批判的方法虽然看上去不是直接解释模型的方法，但实际却是很实用的方法，因为直接把正例和反例拉出来做对比很直观）

（5）基于相似度的解释

推荐系统中经常使用该类方法做推荐解释，例如购买A的人也购买了B，你的朋友小明点评了这个电影等。基于相似度的解释是非常友好的一类方法，但它比较依赖用户对参照实体的理解，例如假如没有朋友小明，就无法根据参照物做出解释。

（6）LIME方法

 LIME是一种基于模型代理的局部样本解释方法，思路是针对要解释的样本点，重新在样本点处建立一个本质上可解释的模型。在建立代理模型的时候，使用的是原模型的输入和输出，将待解释样本点附近的点赋予较大的权重，并将拟合原模型的输出作为代理模型的优化目标。得到代理模型之后，再基于代理模型进行样本的解释。需要注意的是，LIME方法是基于特定样本的解释，这意味着，在某个样本点训练的代理模型，不能使用到其他样本点上。对于所有待解释的样本，LIME方法都需要重新训练代理模型，这在实际中导致了较大的计算量。

（7）Shapley值

Shapley值是另一种比较经典的解释方法，并且它是唯一具有扎实理论的解释方法。它使用全部的特征作为输入，并将特征之间的所有可能组合作为联盟。一个联盟指的是特征之间的一种组合。Shapley值指的是所有可能的联盟中特征值的平均边际贡献。对于这些联盟中的每个联盟，我们都计算带有或不带有某个特征取值的预测值，并取其差值，以获得边际贡献。Shapley值是边际贡献的（加权）平均值。例如，如果用X1,X2,X3,X4共同预测Y。某个样本的观测为X1=0,X2=2,X3=0,X4=1, 针对这个样本，度量X1=0对于预测的贡献Shapley值，（假设X1是一个二分类特征，取值0/1）。首先利用X2, X3, X4得到【‘’，‘X2=2’，‘X3=0’，‘X4=1’，‘X2=2 ,X3=0’, ‘X2=2 ,X4=1’,’ X3 =0,X4=1’, ‘X2=2 ,X3=0,X4=1’】的联盟，然后针对每一个联盟，将X1的取值替换（X1=1），计算预测值Y，并与将忽略X1(X1=0或X1=1，类似于边缘概率的概念)特征值时，联盟的预测值取差值，将该差值当作边际贡献。最终X1某个特征值的贡献为所有边际贡献的加权平均值。Shapley值可以估计某个特征的取值对预测的贡献大小，并且在估计的过程中，考虑到了特征之间可能的交互。缺点是，计算量可能会略大，尤其是特征维度较高的时候。不过，现在有一种TreeSHAP方法，它可以计算精确的Shapley值，并且速度很快。

四、解释中用到的可视化手段

以下列举了部分具有代表性的可视化手段，用于专业的模型解释可视化。个人觉得很有参考价值，但不太适用于面对普通用户的解释，门槛比较高。针对用户的解释，还是要尽量接地气，如一辆自动驾驶汽车，报告其突然停车的原因(“孩子越过马路的概率为70%”);信用违约程序，向银行员工解释为何拒绝信用申请(“申请人的信用卡过多，并且从事不稳定的工作。”);一个机械臂，解释了为什么它把物品从传送带上搬到垃圾桶里(“物品底部有裂缝。”)。

（1）  SHAP解释力图：针对单个样本的解释，蓝色表示增加效应，红色表示减少效应，长条的长短表示Shapley值。

（2）特征重要性可视化：特征重要性可以由多种特征重要性计算方法得到。

（3）特征概要图：如下图，图中每个点为一个样本，点的颜色和位置与Shapley解释力图类似。

（4）SHAP特征依赖图：横轴是特征取值，纵轴为Shapley值。是将特征概要图中某个特征拉出来展示。

（5）个体条件期望（ICE，Individual Conditional Expectation）图：横轴是特征取值，纵轴。每个实例显示一条线，该线显示了特征更改时实例的预测如何改变。

（6）局部累积效应图（ALE，Accumulated Local Effects Plot）图：下图为一个二阶局部累积效应图，它能够展示具有强相关性的两个变量对目标的联合效应。

结语：       

解释模型这个问题，考虑好面对谁解释真的挺重要。之前偏执的认为就应该从本质上解释，就是因为没考虑到“面对的受众需不需要我这么严谨的去跟他解释”。这个问题的回答，大部分都应该是否定的吧。因此，产品中，完全可以把它当成一个产品问题解决掉。但抛开面对普通用户的解释，面对我们算法工程师自己，可能我们需要往数据探索上做，去可视化特征及特征之间的交互效应，有点像探索模型边界，让它变的可控，不过这个暂时还没有那么多精力，只能闲时学习了。

最后摘抄两段话分享出来，表达对这个方向的期待吧：

 “当它与底层的机器学习模型分离时，使可解释性自动化变得容易得多。与模型无关的可解释性的优点在于其模块化。我们可以轻松地替换底层的机器学习模型。我们可以轻松地替换解释方法。”

“模型训练的自动化已经是一个显而易见的趋势。这包括自动工程和特征选择，自动超参数优化，不同模型的比较以及模型的集成或堆叠。结果是最佳可能的预测模型。当我们使用与模型无关的解释方法时，我们可以将它们自动应用于自动机器学习过程中出现的任何模型。在某种程度上，我们也可以使第二步自动化:自动计算特征重要性、绘制部分依赖关系、训练代理模型等等。没有人会阻止你自动计算所有这些模型解释。实际的解释仍然需要人类。想象一下:你上传了一个数据集，指定了预测目标，并且只需按一下按钮，就可以训练出最佳的预测模型，并且程序会吐出对该模型的所有解释。”

阅读原文

跳转微信打开

作为一名安全运营人员，每天总会处理各种各样的安全事件/告警，而其中最为常见的莫过于SQL注入告警。而面对SQL注入告警时最重要的就是确定是否注入成功。本文简单归纳总结如何通过流量日志快速判断SQL注入是否成功。

导语  作为一名安全运营人员，每天总会处理各种各样的安全事件/告警，而其中最为常见的莫过于SQL注入告警。而面对SQL注入告警时最重要的就是确定是否注入成功，但不同类型的SQL注入确定的方法又不一样，有些是通过一个请求就可以确定是否注入成功而有些则需要观察多个请求后才能确定是否成功。而本文则是简单归纳总结如何通过流量日志快速判断SQL注入是否成功。

文章大纲

• 不同数据库的区别

• 常见SQL注入方式

• 布尔类型注入

• 错误类型注入

• 联合类型注入

• 堆叠类型注入

• 时间类型注入

• 总结

一、不同数据库的区别

这里主要关注的是在SQL注入上的差别，而不是功能、性能上的差别。

1.字符上的区别

不同数据库对于同一个字符都可能有不同的含义和处理方式，因此同样的注入payload在不同数据中会有不一样的表现形式。

下面简单举例：

 “+”号：在MSSQL中，“+”号代表字符串拼接，因此“a+b”的结果是“ab”.

空格：  在MySQL中，空格代表字符串拼接，因此“a b”的结果是“ab”.

“||”号：  在Oracle中，“||”号代表字符串拼接，因此“a||b”的结果是“ab”.

以MySQL数据库为例，演示“+”号和空格拼接字符串的区别：

2.函数上的区别

对于同一个功能，不同的数据库中的函数名可能不一样。

以时间函数为例，

在MySQL中的函数名为“sleep()”，

在MSSQL中则是使用语句的形式“waitfor {Delay 'time'|Time 'time'}”,

而Oracle中则是使用“DBMS_LOCK.SLEEP()”

以MySQL和MSSQL为例，演示两者不同的区别（时间延迟）：

MySQL中，使用“sleep”函数：

 MSSQL中，使用“waitfor delay”

3. 结构特点上的区别

不同的数据库在设计上总会有着自己的特点，而这些特点往往会被攻击者用于进行注入或者更进一步的攻击。

• MySQL-Information库

在MySQL数据库中，最具有特色的莫过于Information库了，因为这个库中保存了大量的敏感数据，小至字段名、表名和数据库名，上至敏感配置和用户密码你都能在其中找到。

 通过information库获取已有表名：

• MSSQL-xp_cmdshell

每当提起MSSQL时就不得不提xp_cmdshell，因为通过它可以在系统上执行任意系统命令。虽然在后来的版本中被默认关闭，总可以通过各种手段进行开启。

开启前后对比：

开启前：

开启后：

• oracle-漏洞

在众多数据库中，oracle对于权限的管理是最为严格的，因此攻击者在对oracle数据库进行注入时往往需要进行提权操作。而oracle数据库本身的设计是较为完善的，所以往往需要利用数据库本身的漏洞进行提权。

已有的oracle漏洞

二、常见SQL注入方式

SQL注入有多种不同类型的注入方式，最为简单的分类就是根据有无回显来进行分类。但实际中为了能够更加高效的对SQL事件/告警进行确认，因此我们需要更加细分。

• 布尔类型注入

 该类型的注入主要依赖于表达式、函数或查询的结果是否正确从而影响页面输出结果来判断是否存在注入。

简单举例说明，下面假设对参数id（数值类型）进行攻击，后端数据库是mysql：

表达式类型：?id=1 and 0

从运算符上分析，1和0做and运算的结果是0，此时数据库应该查询id为0的结果。但对于后端处理逻辑而言“ and 0”这部分数据理应是无效的（正确过滤情况下），因此应该查询id为1的结果。此时攻击者只要通过判断页面显示id为1还是id为0的结果就可以初步判断这里是否存在注入点。

函数类型： ?id=1 and length(username()>5)

从上面给出的payload可以看出，当攻击者需要进一步获取信息时往往会用到数据库中内置的函数（或通过查询语句获取）。然后通过预先设置好的条件来控制页面的输出结果。

从流量日志上进行可以发现该注入方法除了攻击payload中出现相关表达式/函数以外，更重要的一个特点是会对同一个注入点出现多次且次数较为稳定的尝试。

为什么会同一个注入点会出现多次尝试？

这是因为攻击者在对某些信息做枚举尝试。前面说了，该方法只会影响页面的输出结果而不会直接显示想要获取的结果，因此需要做大量尝试才能确定结果。攻击者在这种情况下需要进行两个阶段的循环尝试：

循环一：确定要获取数据的长度。

循环二：确定要获取数据的值。

为什么次数较为稳定？

这里的次数是指循环二中的尝试次数，正常情况下数据库中的保存值（如数据库名、表名、字段名或其他敏感信息）都是特定字符范围的，最为常见的就是a-zA-Z0-9加一点常见的标点符号。因此对于攻击者而言只需要遍历一次对应位置的常见字符就能确定该位置的具体值。

过程举例

• 错误类型注入

出现错误类型注入时往往是攻击者最开心的，因为该方法利用成本低无需大量的尝试，同时能够在返回的数据中看到想要的结果。

该方法在流量日志中进行确认时需要把重心放在返回的数据包中，但一般情况下数据往往是通过十六进制进行保存的，因此无法直接关键词搜索需要先进行解码。在解码后需要确定攻击者所要获取的数据是否出现在返回数据包中。一般情况下所获取的数据往往会被对应数据库的错误信息而包围，因此一旦在返回的数据包中出现数据库的错误信息则很大可能情况是被攻击成功的。

错误信息中包含攻击者要获取的信息：

• 联合类型注入

该类型的注入方法与布尔类型注入方法有共通点：也是需要页面结果来进行确定。但略微不同的是所查询的结果是会出现在返回的数据中。

该类型的注入方法在payload上会带上“union”，因此较好识别。在进行确认时需要关注返回数据中是否出现payload中所查询的数据。同时攻击者在攻击过程中会出现少量用于确定字段数的尝试，而在尝试中一般会用“null”进行填充（mysql数据库为例）。确定字段数的原因是因为“union”关键字的前后两个查询语句的字段数需要一致，而用“null”填充则是可以避免因为字段类型不同而导致错误。

• 堆叠类型注入

直接从名字上可能稍微有点难以理解该类型的具体注入方法，但换个角度解释的话就能更好的理解：payload中一定会出现“;”分号，且分号后面跟的是一个完整、能直接执行的SQL语句。

在实际过程中堆叠类型注入确实比较少见的，因为这与后台查询所用的api有所关联，但直接在数据库是能够执行成功的。

在流量侧中该类型的注入因为可以执行完整的SQL语句，因此既可能是有页面回显的，也有可能是没有页面回显的，要根据所使用的payload进行确定。

• 时间类型注入

该类型比较特殊，需要计算请求包和返回包的时间戳之差来判断，而不是单纯的通过返回包的数据特征。这里的时间戳是指http请求中所记录的时间，而不是指事件/日志自身的时间戳。而具体的时间范围则要查看payload中所使用的时间，一般而言都是5秒左右。

实际流量日志中会有多个时间戳：

三、总结

实际中攻击者所采用的攻击手法变化多端，因此只能简单介绍常见注入方法的特点，以便在面对大量此类告警时如何能够快速的进行是否注入成功的判断。后面我们会进一步介绍如何通过自动化的方法来进行处理。

该账号主要围绕智能化技术如何帮助企业提升网络安全水平展开，内容涉及机器学习、大数据处理等智能化技术在安全领域的实践经验分享，业界领先的产品和前沿趋势的解读分析等。通过分享、交流，推动安全智能的落地、应用。欢迎关注~

阅读原文

跳转微信打开

本篇主要介绍基于SOC机器学习检测框架的时间序列建模的一个场景：可疑外网IP周期连接检测。

导语  基于Spark的SOC ML检测平台是为企业安全运营人员打造的一站式机器学习检测服务平台，为用户提供从数据预处理、特征转换、特征提取、模型训练、模型预测、异常结果可视化到用户实时反馈的全流程可配置（无需编写代码）可直接运用于生产环境的智能威胁检测服务。

本篇主要介绍基于SOC机器学习检测框架的时间序列建模的一个场景：可疑外网IP周期连接检测。

一、SOC机器学习检测框架及时间序列建模简述

企业里的威胁检测主要针对细分安全场景进行检测，场景多且不同企业关注场景可能不同。我们针对于企业威胁检测的特点构建了统一的SOC机器学习检测框架，框架的目的有两个:

• 支撑SOC内置场景检测，丰富UEBA模块，增强SOC安全检测能力。

• 提供客户自定义场景功能，以满足客户自定义场景发现未知威胁的能力。

基于SOC机器学习检测框架的内置检测场景:

时间序列异常检测：

时间序列分析是将历史数据在时间维度上按先后顺序构建时间序列，并通过一系列相关模型进行建模识别潜在模式，以便对后续数据进行预测或者异常检测。

根据时间序列本身的特点，我们将时间序列分为周期性的时间序列和非周期性的时间序列。对不同类型的时间序列应用不同的算法建模。

例如：周期性的时间序列应用STL, Holt-Winters等算法建模；非周期性的时间序列应用小波变换等算法建模。

本文将介绍SOC机器学习框架支撑的一个内置场景检测：可疑外网IP周期连接。在该检测场景中，受感染/受控机器会定时访问外网IP，基于这种周期性较强的特征，我们主要基于结合历史数据和安全策略来检测可疑行为。

二、可疑外网IP周期连接（RecurringRare IP Access）

可疑外网IP周期连接（RecurringRare IP Access）是指在特定的局域网内部（如企业内网），存在某个主机，在某段历史时间中有周期性地访问外部的稀有IP，且内网的其他主机几乎没有或者从不访问该IP。则该主机访问该外网IP的行为便是可疑外网IP周期连接行为。

可疑外网IP周期性连接行为属于Command&Control攻击阶段，可覆盖的场景包括但不仅限于特定的恶意软件定期与外网C&C服务器通信；定时脚本执行等。

业界相关场景检测方法：

目前对于时间序列的周期性检测方式主要包含传统的统计分析以及心跳检测方式。

传统的统计分析方式主要以人为设定周期采样分段，然后计算每段的均值方差，基于统计规则来判断是否包含周期分量。传统的心跳检测主要以判断TCP心跳包的情况，在设定的时间段内判断连接是否存在，从而推断心跳周期。

同时也有基于信号处理的心跳检测方法，如单独使用FFT计算时间序列的幅频关系，从而验证时间序列的周期性进行心跳检测。

而现有技术方案存在的缺陷主要有如下几点：

• 基于数学统计和传统心跳检测的检测方法需要经验知识来人为设定周期阈值，容易被绕过。对于时间序列的周期相似性缺少校验，无法有效地判断周期是否合理，周期结果会与实际时间序列不符。

• 而单独使用FFT方法对于时变信号的时间序列检测效果较差，无法有效验证周期的合理性。

基于SOC ML检测框架的方法如下图所示：

三、检测方法

针对可疑外网IP周期性访问场景，检测的整体流程如下图所示。

3.1 特征预处理

以内网源IP和外网目的IP作为主要观察对象进行特征提取。提取的特征值为TCP的传输数据大小，并以n分钟为时间粒度进行累加统计，作为最终特征。

以源IP，目的IP，时间戳（分钟为粒度），传输数据大小的特征值形式构成时间序列数据模型。再利用平滑滤波器对时间序列进行降噪平滑处理。特别地，当时间序列为稀疏时间序列时，不做降噪平滑处理。

3.2 FFT_DTW时间序列相似性周期检测

相似性周期检测算法主要分为两步，首先利用FFT（FastFourier Transform，快速傅里叶变换）对时间序列进行周期检测。获取时间序列的周期值T。其次，以获取的周期T对时间序列进行分段，利用DTW（DynamicTime Warping，动态时间规整）分析各周期片段的相似性。并根据相似性结果来判断最终整个时间序列是否为周期相似的。

1） 利用FFT将时间序列转换到频域。并计算获取幅频关系。对于周期时不变时间序列，即我们主要的检出对象，基于FFT的周期检测将会是准确高效的，如下图所示。左图中的周期为1440min。

然而FFT对于时变信号以及非周期时间序列的周期检测结果需要作进一步验证进行排除。

2） 利用DWT算法对时间序列的周期片段进行相似性检测。

假设有两个时间序列x(t₁),y(t₂),他们的时间长度分别为n和m，则可以构成一个n*m的矩阵D(i,j)，其中每个矩阵的值d(i,j)为x(i)与y(j)的欧氏距离，如下图所示。DTW的目的是找到从D(0,0)到D(n,m)之间的路径。且该最小值为这两个时间序列的相似度值。

利用计算出来的T周期，对原始数据进行切片分段。如果输入序列为N，则可以分成N/T个片段。特别地，由于DTW对于稀疏时间序列的相似性检测的参考性较低。因此为了确保检测的有效性，对于稀疏时间序列进行单独的统计对比。而对于非稀疏时间序列进行DTW相似度计算。

比较两个相邻时间单元的相似度，也就是求相邻单元的DTW距离。假如有N个时间单元的话，就需要求N-1次距离。将所有的距离值保存到列表中，根据设置的阈值，就可以判断出是否具有周期性。

当阈值大于相似度值时，说明两个片段相似，否则不相似；而对于整体的时间序列周期而言，我们会得到N-1个相似度值的结果列表，其中超过一定占比的结果为相似时，则判定整个时间序列为周期性相似序列；否则只判定为周期性序列。

3.3 策略制定

对FFT_DTW相似性周期检测算法的结果进行规则过滤。针对可疑外网IP周期连接的规则策略具体如下：

• 获取可疑结果中所有的外网目的IP记录；

• 统计固定时间内正常流量访问这些外网目的IP的内网IP去重计数normal_count；

• 设置策略阈值normal_th，当normal_count>normal_th时，判定该外网IP被访问次数较多，排除可疑性。

最终输出策略过滤后的可疑外网IP周期连接检测结果。

四、检测效果

检测结果示例：

示例一：检测到某内网IP一周内定时与外网某稀有IP通信

描述：内网某IP每天下午15:14:00通过TCP定时与外网某IP发生通信。最近一次通信时间为2019-11-18 15:14:00。

示例二：检测到某内网IP两周内保持与外网某稀有IP的通信连接，传输数据呈周期性。

描述：内网某IP自2019-11-06开始通过TCP定时与外网某IP保持两周时间的通信，且传输数据大小呈周期相似性。周期为1440分钟，即1天。

示例三：检测到某内网IP在一天内每隔6小时向外网某稀有IP发送一次数据。

描述：内网某IP自2019-11-07晚21:40:00起，每隔6小时定时向外网某稀有IP发送一次大小为175byte的数据。

该账号主要围绕智能化技术如何帮助企业提升网络安全水平展开，内容涉及机器学习、大数据处理等智能化技术在安全领域的实践经验分享，业界领先的产品和前沿趋势的解读分析等。通过分享、交流，推动安全智能的落地、应用。欢迎关注~

阅读原文

跳转微信打开