胡宇佳
(四川大學計算機學院,成都610065)
隨著信息技術的發展,互聯網公司全力研發新的產品以提高自己的行業競爭力。一般的,在臨近產品發布的時期,公司對內部可能會發生的一切異常的現象以及員工行為都十分敏感。為了確保產品能夠按時安全地發布,公司的核心利益能夠不受影響。公司高層常常會在這樣的時期成立臨時的情報威脅分析小組,這樣的小組可以獲取到公司在一定時期內的所有數據,對這些數據中包含的信息進行提取和分析,并根據分析結果,處理可能存在的各種會對公司安全造成影響的潛在威脅[1]。在這樣的分析過程中,數據的復雜性會影響工作小組對結果的分析。因此,本文采取一定的信息挖掘方法,對數據進行清洗、處理,進而挖掘出一定的規律,從龐大的數據中挖掘出可能存在的異常行為[2]。我們根據該公司提供的員工數據,通過可視分析的方法,幫助該公司找到可能存在的內部威脅情報并給出相應的建議。我們的完成過程分為三個階段:第一個階段是對原始數據進行預處理;第二階段是對數據的可視化;第三階段是對可視化視圖進行可視分析,找到規律并發現問題。
本文的數據處理主要是通過Python,以及Python中的數據處理庫pandas[3]和numpy[4]完成的。根據我們要解決的問題,即發現公司中存在的異常,我們將問題拆解為一下三步:第一步,找到員工的部門劃分方式;第二步,探索員工的正常行為模式;第三步,和正常行為模式對比,確定員工的異常行為模式,以及這些異常之間的關聯。
同部門的員工之間會有一定的郵件往來,因此,我們首先從郵件數據入手,去處理數據。第一步,對垃圾郵件進行處理,主要是將垃圾廣告篩選刪除,這部分主要是通過讀取郵件的主題,將繁體字、含有手機號或者QQ 號的郵件剔除,最后清洗得到完整的員工往來郵件。第二步,從收發件人中,通過正則匹配的方式提取出員工ID。第三步,對主題進行jieba[5]分詞處理,以關鍵詞的形式存儲主題。最終,我們以“發件人-收件人-主題詞”這樣的方式存儲數據,劃分研發、財務和人力資源部門員工。
員工的行為模式,主要包括:員工的正常上下班打卡時間、員工上網的瀏覽模式、員工收發郵件數量、員工上網流量高峰以及員工的端口使用模式這五種。
針對部門的員工劃分,我們將員工ID 提取出來,按照部門進行劃分,并分別統計員工的上下班時間,根據統計得到的結果,考慮以半個小時、一個小時這樣的時間區間去統計打卡的人數,以此確定該部門員工的正常上下班打卡的時間段。
針對員工的上網瀏覽模式,我們將所有員工劃分為研發人員和非研發人員兩類,進行分析,將所有網址拆分成了:娛樂網址和工作網址。娛樂網址包括一些視頻瀏覽和新聞網站,工作網址則是公司的內部網站。然后根據瀏覽的時間和數量,統計某時段中員工瀏覽這些網站的頻次,最終得到員工上網行為模式。
針對員工收發郵件數量、員工的端口模式和員工的上網流量高峰,這些也是按照部門以及一定的時間周期去統計。我們會重點關注部門leader 的行為,以及他們工作期間涉及到的郵件和使用的端口和協議等等。
本文所使用的數據是某公司部2017 年11 月共30天內產生的所有CSV 文件數據,包括員工上下班打卡數據checking(員工id,日期,上班時間,下班時間)、員工間的郵件往來數據email(時間,使用協議,源ip,端口號,目標ip,目標端口號,發件人郵箱,收件人郵箱,主題)、員工的協議使用數據login(協議,目標ip,目標端口,源ip,源端口,登陸狀態,時間,用戶)、員工往來的上下行流量以及使用的協議數據tcpLog(使用時間,結束時間,協議名稱,目的ip,目的端口,源ip,源端口,上行流量和下行流量)以及瀏覽網址數據weblog(時間,源ip,源端口,目的ip,目的端口,域名),共計40w條數據信息。圖形的繪制以Echarts[6]和Gephi[7]為主。
對員工所屬部門及人員結構進行分析,通過郵件主題對員工所屬部門進行分類,并根據員工之間的收發郵件關系輔助證明。我們分別使用旭日圖和玫瑰圖展示不同部門員工經常發送的郵件主題以及某部門發送郵件主題的數量關系;通過Gephi 生成的網絡關系圖展示員工與員工之間的聯系,如圖1 和2 所示。

圖1 三個部門的主題分類

圖2 員工郵件往來關系圖及研發部門展示
通過節點鏈接圖發現可能是BOSS 的員工與其他的各個部門leader 間的聯系和郵件往來,確定最終的大BOSS;通過雷達圖展示重要員工的信息,如圖3-5所示。

圖3 員工部門展示

圖4 BOSS往來郵件展示

圖5 關鍵員工的相關屬性圖
在對員工日常行為進行分析總結時,通過折線圖和極坐標圖對11 月的員工打卡時間進行展示,并通過郵件中的遲到早退信息發現三個部門的規定上下班時間,同時注意到研發部門的上下班時間分兩種;通過詞云的方式展示研發部門與非研發部門訪問過的網站,并通過環圖展示出他們最常訪問的10 個網站;通過氣泡圖展示三個部門員工每三天的收發郵件數量;通過折線圖展示員工上網的高峰時間以及協議上下行分布情況,發現員工發郵件的高峰。

圖6 員工上下班打卡時間

圖7 員工打卡時間段統計
我們根據check 中的打卡日志,做出了三個部門的打卡時間圖,其中紅色代表研發部門,黑色代表財務部門,淺藍色代表人力資源部門,然后通過對時間軸的縮放,展示出一個月打卡的時間段和人數。同時我們也對員工一個月的打卡時間段進行了統計,可以看出研發部門員工的打卡時間段在8:00-9:45、18:00-21:00頻繁;財務部門員工的打卡時間段在7:00-7:45、17:00-19:15 頻繁;人力資源部門員工的打卡時間段在8:15-8:45、18:00-20:45 頻繁。在此基礎上,我們對包含了遲到早退主題的郵件進行分析,發現人力資源部門最晚上班時間為9:00,最早下班時間為18:00;財務部門最晚上班時間為8:00,最早下班時間為17:00。研發部門正常上下班時間分兩種:以1059 為領導的小組工作時間為10:00-19:00,以1007 和1068 為領導的小組工作時間為9:00-18:00。

圖8
圖8 可以看出研發部門常用的工作網站是emali.hightech.com,git.hightech.com、OA.hightech.com、jira.hightech.com 等內部網站,非研發部門的常用工作網站是 emali.hightech.com、OA.hightech.com、www.baidu.com、www.google.com、www.yahoo.com、ju.taobao.com 等,他們使用搜索引擎查詢信息,也會訪問淘寶等其他網站。

圖9 部門員工收發郵件數
如圖9 所示,我們按部門統計員工每三天的收發郵件數量。發現人力資源部門每三天的個人收發件區間在25-210 之間;財務部門每三天的收發件區間在25-245 之間;研發部門每三天的收發件數分為2 個團體,其中普通員工的收發件數在0-200 之間,員工id為1060、1087、1092、1098、1100、1154、1191、1207、1209的員工每三天的收發件數在300-1450 之間。

圖10 員工11月上下行流量圖

圖11 員工某天上下行流量示例
我們首先將E-mail 文件中的郵件主題和checking文件打卡信息結合,發現打卡系統存在異常。存在員工請假成功、員工已經辭職,但仍被判定為曠工的情況,這種誤判可能會影響員工積極性,值得關注。
然后,觀察到郵件主題存在EmergencyDataBaseFatalError,對tcpLog 文件統計分析,發現該類郵件集中發送的時間段內,存在四種數據庫崩潰的情況。

圖12 數據庫預警時間前后的數據庫流量和
圖10 可以看出產生流量的時間區間為4:00-22:00,再與郵件日志信息匹配,發現4:00-6:00 為系統自動發件時間,員工則在8:00-10:00、12:00-16:00 為上下行流量高峰期,10:00-12:00 為上下行流量緩和期。圖12 可以看出在周六的時候,SMTP 協議的上行流量達到每周的峰值,有可能員工們在這一天通過郵件往來匯報一周的工作情況等,郵件使用頻率高。
接下來,對login 文件分析,發現其中有許多登陸失敗的狀態,統計各個協議登錄的頻率和成功率。發現11/04 該天的成功率明顯低于其他日期。進一步分析該天協議對應的IP 服務器,尋找端口問題。

圖13 所有協議登錄的頻率與成功率
對tcplog 文件進一步細化分析,對每個協議在一個月內的上下行流量進行了繪圖。

圖14 所有協議上下行流量
可以發現,在7 號的mongodb 協議和15 號的FTP協議存在明顯的高峰異常。分別對其中流量排名前五的IP 進行單點追蹤,找出了這些IP 在一個月內的下行流量使用情況。可以看出,10.64.105.107 在15 號的FTP 文件傳輸下行流量異常;10.64.105.192 在15 號和22 號的FTP 文件傳輸有下行流量異常。

圖15 FTP協議的月下行流量
最后,對HTTP 協議的上下行流量分析,發現存在部分不活躍的服務器(超過十五天沒有訪問過HTTP協議),提取這些IP 進一步對它們在其他協議上的流量分析分析,這些不活躍服務器中的大部分都沒有連接過其他協議。綜合上述異常,我們發現打卡離職人員中,ID 為1487 的員工也擔任著接收EmergencyData-Base 郵件并對數據庫進行維護的責任,這個時候重要人物的離職可能會對公司造成影響。
本文所選取的數據可視分析[9]方案從不同的角度對數據集進行分析,得到的結果可以從多方面驗證員工分組的有效性;我們從實際出發,盡可能多地從各方面展示員工的正常工作模式;我們考慮與網絡有關的方方面面,去挖掘網絡日志背后的信息和故事。使用戶可以從多個維度對數據進行分析,得到問題的答案,挖掘潛在的信息價值[8]。