基于员工日常行为的异常员工可视化分析

数据说明：

数据为一家互联网高科技HighTech公司内部2017年11月共30天的多种监控数据，包括登录日志、页访问日志、邮件日志、打卡日志和TCP流量日志。数据以csv格式按天分类给出，总共120MB（未压缩之前）。各类型日志详细说明如下：

登录日志：

员工通过自己主机或跳板机的应用程序，登录服务器或数据库时生成的日志。例如使用SSH、SCP命令、XSHELL程序或者SFTP传输文件都会产生远程登录日志；客户端应用程序访问数据库时，会产生数据库登录日志。

网页访问日志：

该日志记录了公司内部所有员工的网页访问记录。time是该条记录生成时间，sip是客户端IP，sport是客户端端口，dip是服务器IP，dport是服务器端口，host是服务器域名。如果通过IP地址直接访问网站，不需要DNS服务器解析，则HTTP报头的host字段为空字符串。

TCPLOG日志：

记录公司内部网络活动产生的TCP连接。stime、dtime分别是连接建立和断开时间。proto是IP包头中的协议字段值。sip、dip分别是连接发起者和接受者的IP地址，sport、dport是与之对应的源与目的端口。整个连接过程中，sip向dip发送的总字节数为uplink_length，downlink_length与之相反。员工的登录行为、网页访问行行为、邮件发送或者接收行为等都会产生一条或者多条TCPLOG日志。

邮件日志：

邮件日志记录了经过公司邮件服务器的收发邮件信息。time是邮件的发送时间/接收时间，proto是邮件使用的应用协议。sip、dip分别是连接发起者和接受者的IP地址，sport、dport是与之对应的源与目的端口。from、to分别是邮件的发送者和接收者。邮件内容属于隐私，只提供邮件主题subject。

打卡日志：

记录了公司每个员工每天上下班时间，一行记录中checkin和checkout都为0，表示没来上班。那就是说，没有来公司打卡的员工，也会生成一行考勤记录。另外，如果公司员工当天没来公司上班，次日该员工会收到旷工提醒邮件。

1：分析公司内部员工所属部门及各部门的人员组织结构，列出公司员工的组织结构图。

1．1 公司最高领导的确定

根据11月邮件日志收发记录绘制有向图，如图1.1所示。我们重点关注度大节点，发现1067和kaoqin与其他3个重要节点区域都有联系，且1067往来邮件主题为：介绍、合作、工作汇报、公司发展规划和年度计划等，故推断该节点为公司的最高领导。Kaoqin为发送特定通知的服务器，不属于员工。

图1.1 邮件日志往来关系图

1.2 员工组织结构的确定

图1.2 公司内部员工关系图

图1.2所示为删除无关节点后得到的公司内部员工关系图。从图中可以看出，以1007、1059、1068为中心的节点组成的拓扑结构相似且层级关系都为三级，1013和1041及其相连节点的拓扑结构相似，层级关系为二级。分析节点邮件主题得知，以1007、1059、1068为中心的节点属于研发部门，1013、1041及其相连节点分别属于人事部门和财务部门。节点邮件主题如图1.3所示。

图1.3 重要节点邮件主题云

根据以上分析，人事部门主管为1013，财务部门主管为1041，这两个部门主管直接领导下属员工，研发部门的组织结构分为三级，部门主管分别为1007、1059、1068，1007部门的二级主管为1087、1092、1115、1125、1172、1192、1199、1224和1281；1059部门二级主管为1057、1058、1079、1080、1376、1096、1101、1119、1143、1155、1211、1228和1487；1068部门二级主管为1060、1098、1100、1154、1191、1207和1209。

综上所述，得到图1.4的员工组织结构，其中员工总数为299人。

1.4 公司员工组织结构图

2：分析该公司员工的日常工作行为，按部门总结并展示员工的正常工作模式。

2.1 IP地址对应关系

将邮件日志中的from和sip字段的公司邮箱和源IP进行匹配，得出了员工和服务器与源IP的对应关系如图2.1所示：

（1）员工id与源IP一一对应，且IP地址前三段固定为10.64.105或10.64.106。

（2）服务器与源IP的对应关系为一对一和多对一，例如work的IP为10.116.216.71，kaoqin、notice等IP地址为10.1.4.17。

2.1 IP地址对应关系图

2．2 访问内网行为

图2.2 各部门访问内网情况图

图2.2为三个部门对内部网站的访问情况。其中，财务和人事部门只访问OA.hightech.com和email.hightech.com；研发部门对包含OA、email在内的所有内部网站都有访问记录。

2.3 打卡记录

图2.3 各部门打卡热力图

图2.1所示的打卡热力图是以时间为单位对各个部门30天的打卡记录进行统计的结果。从图中可以看出，财务部门上班打卡时间集中在7：00～8：00，下班打卡时间主要集中在17：00～19：00；人事部门、研发1068和研发1007部门上班打卡时间集中在8：00～9：00，下班打卡时间集中在18：00～20：00；研发1059部门上班打卡时间集中在9：00～10：00，下班打卡时间主要集中在19：00～21：00。

2.4 午休时间推测

图2.4 11月网站访问量图

为了分析公司员工的午休情况，我们从网站访问量和时间出发，将一天时间以30min为间隔划分为各个时段，并统计了30天中各个时段的网站访问量，如图2.4所示。12：30～13：00时段网站访问量显著减少，13：30～14：00时段为网站访问量的局部最低点，14：00之后访问量开始增加。因此推测公司的午休时间为12：30～14：00。

2.5 考勤制度

图2.5 各部门迟到早退时间点推测图

通过邮件日志中的考勤信息结合员工打卡信息绘制图2.5，红色圆点表示该月迟到最早时间点，蓝色圆点为早退最晚时间点，绿色圆点为离迟到早退时间点最近的正常上下班打卡时间点。绿色与红色圆点之间的时段中，可以找到一点最有可能的迟到临界时间点，蓝色与绿色圆点之间时段也可以找到一点最有可能的早退临界时间点。

因此可以推测出，财务部门规定8：00之后打卡为迟到，17：00之前打卡为早退；人事部门规定9：00之后为迟到，18：00之前为早退；研发部门中，1007部门9：00之后打卡为迟到，18：00之前为早退，1059部门10：00之后打卡为迟到，19：00之前为早退，1068部门在这30天中无早退记录，只能推断该部门9：00之后打卡为迟到。

2.6 加班情况

进一步分析打卡日志，我们统计了11月每天各部门打卡人数，如图2.6。可见该月周一至周五各部门均为全勤，4个周末的打卡的人数较少，其中财务部门在19日、25日和26日出勤率如图2.6右侧所示，该部门这三日打卡人数比重与周一至周五接近，猜测财务部要进行月末结算，有加班情况。其他部门正常工作周期为周一到周五。

2.6 公司每日打卡情况组合图

3：找出至少5个异常事件，并分析这些事件之间可能存在的关联，总结认为有价值的威胁情报，并简要说明你是如何利用可视分析方法找到这些威胁情报的。

3.1 警告邮件异常

图3.1 邮件往来与邮件主题关系图

通过数据清洗筛选邮件日志的subject，我们认为服务器发送的警告类主题邮件，如“EmergencyDataBaseFatalError!”、“安全邮件崩溃”、“互联网资产监控报警”、和“重要提醒”这4种都为值得关注的subject。接收这些主题的员工可能存在异常。

因此，根据异常主题匹配得到图3.1的员工id，分别为1184、1164、1455、1098、1207、1487等。

3.2 辞职异常

我们猜测在公司新产品临近发布的这段时间里，有辞职意向的员工可能会存在威胁。

通过筛选邮件日志主题，发现id为1487、1281和1376的员工发送过主题为“【辞职信】”的邮件，如图3.2所示。

图3.2 辞职异常员工图

3．3 无打卡有“Tcp/Login”日志记录异常

图3.3 公司未全勤日打卡人数与有“Tcp/Login”日志的员工个数统计图

根据打卡日志、登录日志和TCPLOG日志，我们猜测，如果出现有员工无打卡记录但是登录日志和TCPLOG日志有记录的这种情况，可能是一种异常事件。

由问题二得知该月周一到周五都为全勤，因此通过广度优先搜索算法统计了周末打卡的人数和有“Tcp/Login”日志记录的人数，得到图3.2。可以看出，这8天中均有“Tcp/Login”日志有记录但未打卡的情况。筛选这8天的打卡日志、登录日志和TCPLOG日志，找出了9个有这类异常的员工，如图3.3所示,异常员工id分别为1494、1147、1328、1334、1211、1284、1283、1376和1487。

图3.4 有“Tcp/Login”日志未打卡员工展示

3.4 登录日志错误异常

在登录日志中，如果登录服务器或数据库失败，会在state字段显示error，推测30天中登录失败次数多的人可能存在异常。

将源IP与员工id对应，发现登录操作中只包含研发部员工。统计了研发部门各员工使用7中不同协议登录失败的总次数，如图3.4所示。其中，7种协议累计登录失败次数和使用ssh失败次数top3的员工id为1211、1228和1080。

图3.5 11月研发部门登录操作失败统计图

3.5 登录日志源IP与user不匹配异常

图3.6 异常登录他人账号人员关系图

如果登录日志中出现源IP与登录用户id不对应的情况，即源IP对应的员工id与登录日志user中的id不同，且多次连续登录结果都显示为失败，则怀疑可能有人使用他人用户名并尝试破译密码来登录服务器或数据库。

由问题二中得知了IP的对应关系，因此，我们使用Python中的字符串匹配算法对源IP和员工id进行了匹配，发现有上述异常情况，如图3.6所示。其中，id为1487的员工多次使用1080、1211和1228的用户id尝试登录服务器A，并在一段时间内连续登录失败，该员工在11月6日最后一次使用1228的id的登录状态为成功。11月24日，1487再次使用1228的id成功登录了服务器B。在同一时间，出现了服务器B使用1228的id成功访问服务器A的情况，推测服务器B到A的访问记录也为1487的操作。

根据上述5个异常事件，得到图3.7各异常员工关系图。

图3.7 各异常与员工对应关系图

总结异常事件之间关系如下:

（1）异常1涉及的员工共有26人，其中只有1184和1363为人事部门员工，其他都为研发部门，异常3中提到的员工全部为研发部门。研发部门与财务和人事部门相比，更有可能得到新产品研发相关的重要数据，因此安全威胁存在于研发部门的可能性也就更大。

（2）1284在异常1和3中都有记录，异常2中发送辞职申请的1376和1487又出现在异常3中，且1487在异常1、2、3、5中都出现过。因此，在异常中出现频率越高的人，越有可能存在安全威胁。

（3）在异常5中1487登录服务器使用的用户名1080、1211、1228，与异常4中登录失败次数top3的员工id完全吻合，这三个员工出现多次登录错误的情况，极有可能是1487在尝试破译他们的服务器登录密码造成的。因此，1487是所有异常员工中安全威胁最大的人。