我目前就职于一家私企的安全部，主要做安全审计的工作，很多公司的离职流程没有考虑过员工的异常行为审计，18年我在逛微博的时候看到google的一条新闻，审计人员发现一名员工在离职前大量访问了某个产品的设计图，基于这个发现最后查出的确是这个员工在离职前窃取了谷歌的机密技术。

看到这条微博的时候我正在做公司内部的数据安全评估，发现了不少问题，其中就有员工在离职前期大量访问或者下载数据的问题，因此我也想要在公司内做离职员工的审计。

审计的前提是日志数据，关键是审计规则，前期我基于堡垒机的操作和公司内wiki系统日志来做基础数据，重点关注mysqldump、download、select等这些和数据导出、下载、查询相关的关键词，当员工提出离职申请时，就会触发离职审计，查看近1个月内是否有出现访问异常。

如果这1个月内出现某天访问量超过之前访问的平均数，那么就作为一个异常，需要人工去判断是否符合工作需求。

这是一个很简单的审计规则，基于数据下载操作的请求数来做，但其中存在很多盲点：

1、获取数据的方式不只是从数据库中拿，也可通过内部业务系统或者接口

2、员工如果真有心收集公司敏感数据将是一个长期的过程，不太可能集中在离职前一段时间做

3、由于安全并不了解每个员工的工作日常，异常操作需要员工领导来确认

光是以上三个问题就能牵扯出一大堆其他问题，如果数据安全管理、内部系统接口调用链路、账号权限管理、日常业务日志监控等没做好，这三个问题也解决不了。

从2018年到2019年，我们也面对了很多困难，特别是日志标准化这一点，至今没有解决，但是当前的离职员工审计，范围比初始扩大了几倍，每日日志量也由万级到达了千万级。这段时间里我开始接触UEBA，计划将离职员工审计转型为员工行为监控。

这面临的一个问题就是，需要将异常行为归纳为可以匹配全部数据的规则集，于是我和我的同事开始了建立员工基线的漫长道路。

我们基于办公网流量、VPN等数据梳理出时间、用户、部门、账号、请求（hostname、url_path、request、response、dst_ip、dst_port）、来源（src_ip、src_port）、mac地址，这一部分作为待审计数据实时接入ELK。

对公司内所有的业务系统、数据库、接口基于数据等级和属性进行分类，一共分为5类，level=1是一级敏感数据，需要重点关注，属性是指这个系统归属于什么部门。这些数据存入mysql中，由于安全部可以查看到DNS、F5和数据库管理平台，因此我们每天更新一次这些数据，目前还无法做到全自动化更新，有些仍需要和对应负责人确定业务系统的详细功能和url。

另一方面，就是最重要的员工基线，一部分来自于权限系统、一部分来自于我们每月更新一次的办公网流量抓包。

前期的准备工作是又长又臭，但是如果不这样做，也无法做好UEBA了。

目前这套员工行为监控初具雏形，以下是现有的3条规则：

1、src_ip与用户名匹配——针对入网管控

2、hostname与员工的系统权限基线匹配——针对权限过大管控

3、request与员工账号基线匹配——针对账号多人使用

规则很少，但我也想分享出来，因为这三个规则是实践出的真知，每一条都是我和同事在千万条日志中人工肉眼揪出来的。我们在UEBA上要做的工作还很长很多。

网上也看过不少员工行为监控的方案，但公司的实际情况与方案中的前提条件相差甚远，所以啊，安全架构很重要，前期如果没有考虑到或者图省事儿，后期的工作量陡然增加。