ITIL 資治通鑑

簡單說明了 Event Management 的理論，回到現實世界，來談談我周遊許多公司資訊環境後，常見的管理問題。

個人曾經到訪過一個地方政府資訊單位，該單位規劃出不錯的 Log Center 功能，以 Web Service 為所有軟硬體環境界接的界面，去接收所有 Event 訊息，各系統依照五大類別去分類呼叫，集中整合所有 Log，最後連接 SMS 及 Mail 平台去通知相關承辦人及廠商，進行必要的處理。上述例子是不錯的 Event Management Process Design (落實度還未完整)，成本也相對昂貴，也有比較簡易平實的做法，就是寫 cron-job 全部收進來，再列印報表去審視。

無論是哪種管理流程，個人曾見過的 Event Management 問題如下，供大家參考：

一、Event or Log 未過瀘：
許多組織都了解 Event or Log 保存的重要性，為了怕有疏漏，寧可錯殺一百不可放過一個，沒有 Filtering 機制全部收進來，曾見過一個資訊單位僅一天的 Log 檔案大小就超過 4 GB，光開個檔案電腦幾近當機，更別提如何去區分正常及異常的 Event了…另一個曾見過的例子，某單位資訊人員手機簡訊功能關閉，我好奇問他為何不用? 他回答說，Event 簡訊通知太多太頻繁，他索性就直接關掉了，眼不見為淨…令人啞然失笑，也想起過濾的重要性。

二、Event or Log 未分類：
就管理而言，時間的運用是很重要的，基本上應該遵循 80/20 法則，將大部份心力關注在少數異常的 Event 上，去進行必要的處理。依照個人之前的經驗，所有 Log 集結成一大塊，並在報表上全數登載時，其實日子一久，管理人員常因鬆懈，無法一一去細看，就等於沒看…適度的分類是會容易協助專注於異常 Event 的監控；另外，在資訊安全 ISO 27001 的控制項，也特別關注不同種類的 Log，尤其是 Administrator 及 Fault Log 的保存及監控。

三、Event 的保存期限如何界定?
其實我一直覺得這是很直覺的問題，就 ISO 27001 而言，A.10.10.1 控制項的說明提到，Log 的保存應在「an agreed period」，此言可以是法律上的要求(如檔案法)，或是該組織自行定義合適的期限，端視情況而定。不過有一個客戶問我這個問題時，我提供上述的回答後，他的後續疑問倒是讓我有了不同的思考…他回問說：「是的，我們可以自行定義，不過如果我把 20 多年前的 Log 刪除，哪一天立委跟我調相關資料，若無法提供，你覺得他會放過我嗎?」的確，任何問題扯上了政治，都會變得很複雜…

四、Event 的保存
很多單位收集 Event or Log 在一個公用的資料庫或資料夾，若沒有適當的權限控管，要特別在意非授權竄改的風險(ISO 27001　控制項之一)，畢竟當相關資訊安全事故發生時，若涉及法律責任，正確 Log 資料會是舉證的重要資訊之一。此外，為了降低風險，若預算許可的情況之下，可以進行定期備份或異地備份作業。

(本章節完)