https://newera17031.activehosted.com/index.php?action=social&chash=19de10adbaa1b2ee13f77f679fa1483a.2906&nosocial=1
https://newera17031.activehosted.com/index.php?action=social&chash=19de10adbaa1b2ee13f77f679fa1483a.2906&nosocial=1

觀點

釐清需求 是善用SIEM的第一步

2013 / 03 / 18
編輯部
釐清需求 是善用SIEM的第一步

APT攻擊與新版個資法正式上路可說是這兩年國內企業相當關注的資安議題,為了應付APT這種進階精密的惡意攻擊,和個資法中保存事件軌跡記錄與舉證的法規遵循需求,不少企業開始尋找LM(Log Management)日誌管理或是SIEM(Security Information Event Management)資安事件管理平台解決方案,由於SIEM多半具備LM功能模組,使得原本認為僅適用在大型企業或特殊產業的SIEM市場出現明顯成長。

不論你是因為攻擊防禦需求考量尋找SIEM,或本身已有LM想再深化應用而評估SIEM產品,我們都希望你能先閱讀本文,以釐清自己真正的需求,以免成為花錢受氣的冤大頭。

 

SIEM的演進
要清楚SIEM與LM的區別,我們可先了解一下SIEM的演變,RSA大中華區技術總監劉君軒提到,SIEM約在10年前開始出現,最初做為日誌的處理、警告、分析與報告的工具。

財團法人資訊工業策進會資安科技研究所技術服務中心主任侯猷珉也指出,早期SIEM平台非常專業,通常是大型電信公司用於監控內部IT環境,像技服中心在8年前引進的SIEM系統,便是美國電信業者VeriSign首次將自身監控系統轉移到其他機構使用的例子,直到後來大型企業開始注重資安問題後,才漸漸有愈來愈多的監控系統被商品化出現在資安市場之中。

一般來說,SIEM架構可以簡單分成前中後三個部分:前端的事件收集器(connector)、中間的日誌管理系統(logger management)和後端的事件關連分析平台(correlation)。

 

事件收集器  跨出SIEM的第一步
前端的事件收集器顧名思義就是用來收集監控環境中各項設備的事件資訊,包括作業系統、網路設備甚至是應用程式的事件記錄。尤其是應用程式的部分最為複雜,例如不同用戶透過網頁應用程式存取後端資料庫時,從資料庫的側錄或稽核工具來看,可能都是使用同一個帳號來與資料庫進行連線,因此需要搭配前端的應用程式記錄,才能找出登入網頁的真正用戶名稱。

不過企業使用的Application眾多,不一定每個程式都提供事件記錄的功能,遇到不具備留存Log功能的AP時,該如何收集資訊?HP資訊安全事業部北亞區資深技術協理蕭松瀛建議,舊有應用程式如果有程式原始碼的話,可以直接修改,沒有的話就需要透過第三方工具(如:Fortify RTA)協助收集記錄,至於新開發的應用程式則可視管理需求規劃設計出統一的日誌格式,或遵照現行其他AP的日誌格式,或是目前通用的CEF(Common Event Format)格式。

事件收集器可以是軟體(agent)也可以是硬體(也就是所謂的agentless),以HP來說則是軟、硬體都有,軟體甚至免費提供,兩者差異點在於,採用軟體(即安裝代理程式)要考量安裝平台支援性,以及是否會影響本機效能的問題,採用硬體收集器雖然沒有安裝平台支援與否的問題,安裝上相對較為簡單,但會多出另一筆硬體購置的費用。

此外,收集器安裝位置也是要注意的地方,一般最簡單直接的方式就是,建置在網路閘道的訊息匯聚之處,但這麼做有可能無法收集到內部網段的設備記錄而影響事件分析的深度,如果將收集器安裝到內部各個網段內,雖然能收到更詳細的資料,但也相對增加硬體建置的成本,而這又會牽扯到另一個關鍵問題 ─ Log收集的範圍與後續規劃的存空間。

Log收集範圍  牽動建置成本的變動
到底哪些Log是需要收集分析且被保留的?RSA資深技術顧問黃政杰以自家客戶的經驗來看,通常國外原廠會搭配國內合作夥伴提供顧問服務,就企業IT環境與稽核需求來決定Log收集的範圍,除了像前面提到收集器的擺放位置外,例如企業若為了個資法稽核需求,就要收應用程式與DB的Log,此外,法定稽核日誌所需保存的年限時間等都會影響Log收集的範圍。

至於儲存空間的規劃上,蕭松瀛提到可用EPS(event per second,每秒事件數)或一天收取日誌量的檔案大小(Log File),加上所需保留天數與儲存資料的壓縮比(有些是10:1),便可大致預估出所需要的儲存空間。由於有些產品的計價是按事件收取量來計費,所以侯猷珉也談到國內有些SOC業者因為考量到授權成本,而與資策會合作開發前端收集器,再利用廠商的SIEM平台來做後端的事件分析。

而收集器所收取的資料還要經過所謂正規化(Normalization),以便之後進行關連式分析,有些產品會在後端才進行正規化,有些則會在前端收集器進行,以減輕後端管理平台的負擔。

然而,企業各種裝置所產生的日誌種類眾多,這就考驗產品的支援能力,一般來說,市場上較有知名度的網路、安全等設備通常都能被接受,至於尚未支援的格式則可透過原廠客製化,或有些廠商會提供工具來協助客戶自訂匯入日誌,但好用與否也是企業評估時所需注意的。

 

符合法規遵循的LM
前端事件收集器在收集到資料後,便傳到中間的日誌管理平台(LM),協助企業進行日誌的搜尋、管理、歸檔、報表產出並確保存取的日誌不被篡改,也就是符合法規遵循所規定事件稽核與記錄留存的部分。

因為稽核人員未必具備IT能力,所以LM的搜尋功能最好儘可能做到簡單易用,以方便稽核人員查詢使用,如果企業有大量歸檔(archive)需求的話,也可以考量搭配其他儲存設備以存放原始日誌。

在產品上LM也分成軟體或硬體兩種形式,以HP為例,軟體的話是按照每天日誌量(即GB/Day)來收費,而硬體則是以每秒事件數(EPS)來計價,所以企業在評估時,除了考量前面所提到日誌收集範圍與儲存空間外,也要考量像是遭到DDoS攻擊時,LM對於超量日誌的處理方式,以免發生日誌遺失的狀況。

企業如果是要因應個資法舉證要求的話,通常只需要建置日誌管理機制即可,但前提是SIEM廠商所提供的LM方案是能夠獨立出來的產品,因為有些廠商將LM視為一個功能模組而包括在SIEM平台之內,不然就是要考量單純LM產品。

相反的,若只要SIEM監控分析功能而不想要LM也行,像HP就能從收集器將日誌直接傳送到後端的資安事件處理平台進行分析,或是有些企業想將資安監控的工作委外,此時收集器便會將日誌傳送到委外廠商的SOC中心,進行即時性的監控分析,如果是這種情況的話,企業也可以在內部環境中另外建置LM,以符合個資法的要求。

從use case角度來看SIEM
後端的關連分析平台可說是SIEM的核心所在,之前收到的所有日誌資料都會送到這個平台中,進行即時性的關連分析,協助人員在最短期間內發現環境內部的異常活動,並按照ruler來發出警告以進行後續的動作處置,同時也提供各式稽核報表與視覺化的監控儀表版,協助人員掌握當下的IT環境。

雖然各家的SIEM都有關連式分析的功能,但侯猷珉也承認這是最難測試的部分,基本上只能請廠商說明是用什麼原理來建立關連式分析的規則?至少要能說明清楚才能加以驗證,如果無法解釋清楚的話,企業就當做沒有這功能。

蕭松瀛則建議企業從use case(使用案例)的角度來評估,也就是「企業想用SIEM做什麼?」例如企業如果想透過SIEM平台來監看內部是否有Botnet活動,便可拿防火牆與IPS的日誌進行比對,再與外部的黑名單去做關連以確定內部主機是否有連接到外部中繼站,又如企業想偵測內部蠕蟲活動的狀況,可以透過IPS與防毒軟體Log比對,偵測內部還有沒有蠕蟲的行為。

另外,也能透過SIEM來製作內部主機的風險評量表,舉例來說,員工電腦發生中毒事件給5分,遭IPS示警給3分,連結外部惡意網路則給1分,然後每月統計加總後便可看出風險最高的主機,再通知維運人員針對這些高風險的電腦詳細檢查、找出潛藏問題,達到事先預防的效果。

蕭松瀛進一步說明,由於每家企業所使用的網路環境、應用程式都不盡相同,因此SIEM平台所使用的關連式分析需具備彈性,才能讓IT人員迅速制訂出ruler以因應各種使用情境,而這種use case的應用也正是最常被客戶問到的重點所在。

由於SIEM主要用來進行即時的事件監控分析,需要對大量事件進行分析過濾,如果所有事件都要放入資料庫的話,在做分析運算時很容易產生效能瓶頸,因此SIEM對於巨量資料(Big Data)的處理效能也是要考量的地方。

像RSA採用Hadoop分散式檔案系統做為平台架構,HP則是在Log進來後建立索引存放在資料庫內,原始的事件日誌則以檔案型態儲存,而非將所有資料都放在資料庫中,當要做關連分析時則是全部在記憶體中處理。例如我們設定一個要將5分鐘內的作業系統與防火牆的Log進行關連的規則,當OS的Log送入時,除了如上述建立索引並將Log寫入檔案外,也會將此Log暫時佇留在記憶體中,等待防火牆的Log送入再進行處理比對,因此在關連比對的過程裡,不需執行資料庫的存取動作,藉此提高關連引擎的處理效能。

而像Novell平台則是採用所謂Message Bus的架構,當事件進來後會直接在記憶體中處理交換,用來進行關連式引擎的分析與產生即時的儀表版資訊等;直到要儲存事件時才會將資料寫入硬碟中,也就是將負擔較重的運算資料都在記憶體中完成,以免產生SIEM在效能上的瓶頸。

 

未知威脅的防禦
前面提到,許多企業希望藉由SIEM平台來做到對未知攻擊的防禦,以儘早發現企業內部的潛在威脅,因此各家SIEM廠商也開發出各種方式以解決此問題。劉君軒認為只基於日誌為主的分析效果有限,要發現未知攻擊的話,最好能結合更多資料以協助辨識新型的攻擊行為,所以RSA結合之前所併購的NetWitness網路封包鑑識產品,完整保留網路封包並還原可疑行為。

至於HP則是透過Pattern Discovery功能來達到對未知攻擊的防禦,企業可選擇設備種類(如:IPS、防火牆等),並設定偵測的期間與對象(如:IP、連接埠等),以類似資料探勘的方式建立出這段時間、這些設備的行為模式,再由IT人員檢視這些pattern裡有沒有異常或入侵行為,如果有的話IT人員則可點選滑鼠右鍵產生相對的ruler進行防護。蕭松瀛表示,企業可一次選擇好幾種設備,設備種類越多、pattern內容就越深。

 

人員是否具備事件處理經驗
以上所談的都是以產品本身為主的介紹,但企業在評估SIEM還要考量到另一個重要的因素 ─ 人。


我們了解SIEM是SOC所賴以運作的基礎監控平台,而SOC通常都配置有一、二、三線技術人員負責維運監控與處理突發事件,撇開其他不說,企業可能要先想到是否有具備基本資安觀念的一線7x24小時輪班維運人員配置,即使有,還要考量是否具備二線分析人員的能量,以便當有事件發生且一線維運人員無法處理時時,能即時聯絡到二線分析人員進行緊急處置。

但蕭松瀛提到目前國內企業最常見的問題就是缺乏二線分析人員,當發生資安事件時,通常都是找原廠技術人員來協助處理,造成由廠商來擔任二線分析人員的窘境。這種情況並非長久之計,因為不同企業的IT架構都有自己的作業流程,所以即便找來廠商的技術人員協助企業執行二線處理的工作,也可能會因為對企業流程的不熟悉而影響到對事件的分析判斷,更別談到在緊急處理過後,可能還需要再交由三線的資料人員,針對事件發生的原因過程進行更深入的分析研究,找出企業潛在漏洞以避免重蹈覆轍。

雖然SIEM能將原本許多需要手動完成的工作予以自動化,但仍然需要足夠的專業人力來維持SIEM的運作,因此SIEM廠商也都有提供人員培訓的服務,劉君軒表示RSA會提供3天的訓練課程來教導像如何自訂關連式分析的產品使用操作,但他也提醒這並不包括事件處理與如何分析的方式,而這也意謂著企業IT人員得先具備一定的事件處理經驗才能妥善運用SIEM產品。

至於HP則設計有為期兩週的導入諮詢服務,包括人員的面談以協助企業進行能力分級,並可依照一、二、三線不同人員所需的技術能力來安排相關培訓課程,課程內容甚至細微到幫企業做好SOC人員座位的編排等,看到這,或許企業可先衡量自己是否有意願負擔這樣的人力配置需求。

 

先採用委外服務累積事件處理經驗
侯猷珉從資策會執行政府專案的經驗建議,如果企業現階段缺乏具備相關事件處理經驗的人員時,可考慮先採用服務委外的方式來進行網路資安的監控。

由於政府在政策上希望多培植國內資安產業的技術能量,因此將目前政府機構的網路安全、惡意程式監看等監控作業多數委由民間資安業者的SOC代管,而原本提供政府機關資安事件管理系統的G-SOC(Government- Security Operation Center,國家資通安全防護管理平台)則逐漸退居第二線,針對一些特別的攻擊行為從綜合角度收集分析,並進行像黑白名單等資訊分享。

侯猷珉認為,採用SOC委外服務的話,企業就無需負擔昂貴的相關設備投資,且能從服務過程中漸漸累積內部人員事件處理的經驗,如果日後對服務不滿意的話,也能夠更換其他的服務廠商。但如果是自己購買SIEM平台,之後因為人員專業或是無法負擔大量的維運人力而想找委外廠商來託管SOC的話,就可能因為接手廠商所使用的設備不同造成既有投資的浪費。



資安,是做口碑的
如果評估各項條件後企業依然打算導入SIEM,最後一定要做的就是POC驗證,不過侯猷珉和蕭松瀛都同意,如果企業選的是市場上前幾家知名SIEM產品,通常POC也不會有太大問題,侯猷珉更坦言通常POC能看到的就是,確定產品介面設計上是否順眼?使用操作上是否順手?其他像巨量資料分析時所遇到的效能問題,則需要累積一定的資料量才能看得出來,所以最後還是得靠「口碑」。

因為目前有能力使用SIEM的單位不多,使用者的口碑具有相當參考價值,與其因為價格因素而使用一些不知名的SIEM產品或委外廠商的服務,到最後花錢受氣,還不如先仔細想好企業是否真正有此需求?自家IT人員是否已具備足夠條件,而不是一窩蜂的盲從評估,這才是真正有益的做法。