正式成為資安分析師Security Analyst之前，其 中一項開始學習的工作便是監控各種設備產生的日誌log，進行日誌分析Log Analysis，每種設備Log的內容不一，例如Windows事件紀錄、Linux主機log、Router/Switch log、甚至網頁伺服器的Apache log、郵件伺服器的Exchange Active Sync Log，各種資安設備如防火牆、UTM、IDS/IPS、代理伺服器Proxy Server的log等等，身為資安人員，認識、了解公司環境裡產生的log，傾聽log告訴我們的訊息非常重要。這次鐵人賽在自我挑戰組有邦友分享在網管人的投書，利用檢視特定日期事件達到檔案稽核的目的，可以參閱：

檔案稽核(上)
https://ithelp.ithome.com.tw/articles/10190711

除了稽核要求，依據不同Log提供的資訊，一般日誌分析還有以下用途：

1. 除錯 Debugging

一般主機或網路設備故障或遭遇問題時都會產生相對應的Log，例如前面連結裡《檔案稽核》一文運用到系統主機的「工作排程器」Task Scheduler，執行自己撰寫的script腳本，如果該系統主機產生事件紀錄Event ID 402 Task Scheduler Service is shutting down，接著卻沒有Event ID 400 The Task Scheduler service has started的紀錄，或者見到Event ID 101 Task Scheduler failed to start，那麼工作排程器應該是出了問題；如果該系統主機出現 Event ID 6008 The previous system shutdown at (Time) on (Date) was unexpected，表示主機曾經不正常關機，可以依據事件紀錄裡的時間日期，尋找故障原因。

有一次我盯著螢幕，轉頭對旁邊的工程師說「某某系統不太對勁，一直產生這個log，你看是不是有問題？」
「亂講，明明沒事。」他開啟了幾個螢幕，翻閱電子郵件，沒有從監控系統收到任何警訊。還在登入系統主機的當下，就發現確實不太對勁，沒多久系統就當機了，約略十分鐘後開發人員developers從另一頭遠遠的走過來，看到我們兩個聚精會神地對著螢幕寫除錯報告，並馬上提供事件來龍去脈，吃驚地道：「你們怎麼（未卜先知）知道系統出錯！？」

除了我在分析日誌的時候發現系統異常，及時回報負責的工程師，在問題擴大前進行處理；也有幾次是大家圍著資深工程師研究到底系統問題出在那裡，憑藉日誌上的時間日期，比對同時間其他系統日誌，找出事故發生的前後因果順序，所以在維持系統運作、除錯上，傾聽日誌的聲音能更快速地找出問題所在，縮短排除故障時間。

2. 預測分析Predictive Analysis:

定期進行日誌分析Log analysis，如果發現紀錄的錯誤日誌有特定規律，那麼也許並非單一事件，必須從整個環境來檢視，了解原因後還可以預防未來發生相同錯誤。例如有一次開發人員回報有時候早上資料庫「有些慢」，必須等到早上八點過後才漸漸好轉，但並非每天都會如此，檢視八點左右的日誌並無發現任何異常行為，最後比對所有相關系統的日誌，發現當備份系統開始備份伺服器的時候，如果資料庫伺服器沒有先備份完畢，剛好備份時間點又卡在資料庫本身正在執行某個script，script運作的時間便會被延後，而那個script其實會聯繫另一伺服器，如果剛好那個伺服器也接著之後正在備份，script的運作又會被延後。所以瞭解其中運作流程後，開發人員調整工作排程，我們也改變備份順序和時間，日後也會特別記得要注意script，確保運作正常，避免將來發生類似問題。

(內容很多，明天待續)

*網路截圖來自medium 文章“Understanding Log Analytics, Log Mining & Anomaly Detection”

「那孩子…正在聽『魚的聲音』…！」- - 岩崎民次《將太的壽司》

附錄：
記錄檔案伺服器存取軌跡　免費達成稽核調閱要求《網管人》http://www.netadmin.com.tw/article_content.aspx?sn=1710030005