觀點

維運篇:DLP上線後的持續優化

2013 / 02 / 18
林文腕
維運篇:DLP上線後的持續優化

DLP系統上線後,不是就可以輕鬆一勞永逸,而是要持續政策微調,降低誤判並提升系統成效,同時將這套工具融入企業管理流程中,才能發揮效益獲得管理階層支持。以下從PDCA角度來談,DLP系統如何維運與優化。

Plan 規劃
資訊安全管理作業要點ISO 27002 (前ISO 17799) 5.1提到管理階層應對資訊安全政策做出承諾,並且提供充份資源,同理當然可以應用在DLP的實作面上。當個資法上路後,PDCA的模式完全可以符合在DLP上,而在建立DLP系統前,除了上述所提獲得相關資源外,必須考量企業通盤的現有架構,以避免重複投資。應包括:
1. 是否有存取控制解決方案(Access Control)
2. 網路閘道過濾(Proxy Server, URL Filter)
3. 資訊資產管理
4. 安全管理流程制度

以上有部份功能已重疊在DLP上,如果只是為了防止外洩,相信大部份的企業在決定導入DLP之前就已使用相關解決方案,但如果是為了完整的記錄保存,DLP的確是一個很好的幫手,不過企業應該先思考為何有這些記錄,就在於防範措拖做的不完善,才會有這些記錄產生,例如:
1. 企業允許使用USB隨身碟嗎?
2. 企業允許上網瀏覽任何網站嗎?
3. 企業允計使用任何網路服務嗎?(IM/FTP/Web HD)
4. 企業允許外部電腦連入並未進行區隔嗎?
5. 企業允許員工存放自己相關的個人檔案嗎?
以上只是舉例而已,如果這些規定已在企業行之有年,還需要DLP嗎?外洩管道千百種,防範漏一不可,而DLP正可以補強以前的外洩漏洞。

當企業選定使用DLP解決方案來補強企業外洩的管道及監控,就要思考整體的佈署架構及政策,包括了:
1. 我的網路出口流量大嗎?
2. 我有很多檔案伺服器或資料庫嗎?
3. 我有很多出差的同仁嗎?
以上三個問題簡單帶出DLP三種模組所延伸出的架構,包括了如果企業使用多閘道ISP的情況,當然DLP可以統一在核心交換器(CoreSwitch)進行管制監控,但分流會更放心,而進行個資盤點時,不管是透過CIFS或NFS進行檔案掃描,皆可能影響企業內部效能,甚至有分段跨WAN的情況,這時就要考量負責進行掃描作業的DLP主機,就要依區域進行佈署,當作業結束後才將盤點結果回送DLP資料庫,以減少掃描作業所發生的網路壅塞情況,而目前很多企業為了有效利用辦公空間,紛紛採用行動辦公室,員工手上就是一台NB行遍天下,所以多久回公司根本無法預料,外洩的情況更不敢想像,所以在每台NB植入監控程式是目前唯一比較好的效果。

當以上的佈署架構考慮完後,就必須考慮DLP政策面了,如同上述,記錄愈多代表原本企業內的安全架構就已不完全,才有可能發生這麼多記錄,所以在建置DLP時,相關人員在討論外洩防護政策尤為重要,包括了:
1. 我該保存每一事件的檔案附本嗎?
2. 我該將每一事件通知到主管嗎?
3. 我該通知稽核或法務人員嗎?
4. 我該通知違反人員嗎?
5. 個資盤點該如何進行?

在計劃保存外洩的相關記錄時,應考慮是否有主管機關及相關法令法規要求,注意保存年限,而儲存的環境也有差異,不管是在線事件、離線備份,空間都必須考慮到,及調閱記錄的速度,都必須考量,否則主管機關要求提供相關記錄,卻因資料還原時間過久,無法達到要求。

所以在資源充足的情況下,在線儲存最有效率,空間不足也可在線擴充,而當空間的問題已規劃完畢後,政策的重點就在於附本是否該儲存?我們可以依不同模組來進行分類,例如是外洩事件,包括上網行為、網頁郵件、網路服務等連結至Internet,檔案附本建議一定要儲存以利完整證據保存;而如果是進行主機的個資盤點,因為目的在於輔助管理人進行個資檔案的盤查,反而不需要儲存附本。

每一事件是否要通知主管,這時就要先把整個企業組織攤開來說明,針對核心單位的外洩事件,建議一定要馬上通知上層主管,如果違反等級為高的情況更要通知再上一層主管,例如金融業對民眾的業務單位、製造業的RD單位、服務的對像為自然人,都應該在第一時間進行通知,而如果外洩是以個資為主,因為有違反個資法的問題,更應追加通知稽核與法務相關人員進行搜證處理。此外每一事件也應該通知當事者,因為人性本善之故,可能是員工不小心發送,也有可能是因為是合作廠商的緣故要進行資料交換,或是主管同意寄送,這些情況都可能要另外列舉一份排除名單。

而個資盤點是個資法施行細則中最先要求的一項作業,個資散落在各個主機與端點中,連個資檔案的管理者可能都不知有多少檔案在系統中,但盤點的過程中可能會影響網路、影響主機效能(因有開檔檢查內容之情形),而主機數量眾多,要一二天完成絕非易事,適當以排程方式進行掃描作業才是上策,例如比較核心的主機,每天存取頻率是占全主機量的前1/4,可以安排離鋒時間進行掃描,例如晚上或假日,而其他主機則可以分散在不同的辦公時間進行掃描,另外如果是分公司架構的情況,也可以類似的情況來制訂政策。

Do 執行
在上線階段,應依企業有限資源列出優先順序,以確保外洩風險能有效被處理與控制,在計劃階段我們已明列必須建置與注意的事項,在上線時,明確界定哪些外洩事件不應該發生,所以依ISO27001所提之實作風險處理計劃以達成各項控制目標是必要的,例如不同產業所界定的風險也有不同,如果是以民眾資料為主,個資當然為首要目的,但製造業反而是RD資料才是生財命脈,此外每日、週、月甚至年應明確識別各模組外洩事件的指標(例如每周事件低於5件),在上線時才能有效控制以達成目標,當然指標依據可在POC階段時訂定量化有效值,而政策當然也是依不同模組而進行監控,DLP政策並非像Firewall一樣,一條政策訂了就再也不更動,有效的觀察與微調政策,才是讓DLP運行順暢並有效防止外洩事件及事後追蹤。

而在規劃階段,已針對DLP系統進行災難回復計劃,達成量化的控制目標,是本項的目的,包括了:
1. 多久執行一次備份與還原
2. 部份災難重建演練(資料庫損毀、主機故障、網路斷線等)
3. 完整還原測試(磁帶系統還原全部系統)
4. 災難演練之過程記錄
且需考量可容許之服務中斷時間:(範例)

管理策略

關鍵性作業

營運持續管理策略

可容許之服務中斷時間

權責人員

網路監控

確保個資由任何網路協定外洩時能監控並防止。

上班時間

4小時

機房管理人員(OP)

個資盤點

盤點作業執行時網路連線不中斷及防止強制中斷。

上班時間

8小時

稽核或法遵人員

使用者端監控

全天24小時持續監控使用者行為及防止服務中斷。

上班時間

2小時

DLP管理者

資料來源:本文作者整理

災難發生時應以最重要模組回復為優先考量(依企業習性不同而有所差異),並考量營運持續管理程序
1. 緊急應變:事件發生時,應依事件發生之類型參照各緊急應變處理程序進行處理。
2. 矯正及預防:如回復時間超過可容忍之服務中斷時間,須進行矯正預防管理程序,辦理矯正預防作業。


Check檢核 有效降低事件誤判率

當DLP上線運行一段時間後,不同企業觀察事件的頻率可能有所差異,短則一個月,長則會超過半年以上,為了有效降低事件誤判率,DLP的事件判斷來源,可能是由個資資料庫而來,進而產生指紋檔進行辯識,然而產生的過程中,可能因指紋檔更新的排程,出現時間差而造成外洩事件,所以格式判斷法就是第二個選擇,例如常見的金融卡號碼格式、身份證號碼格式,來增加阻擋條件,而誤判率高的政策,也會在這個階段做全面性的檢討,是否格式的嚴謹度要再加強,或是有其他政策的替代方案。

而在災難演練報告所呈現的資料中,是否有異常的情況也是必須考量,例如資料量太大、磁帶空間不足、在線磁碟異常、服務中斷、硬體故障等這些有可能發生的情況。在檢查的過程中,如果是想到什麼就檢查什麼,一定會有遺漏,所以設計一份檢核表是必須的,包含DLP相關資訊(版本、修正套件)、硬體資訊、政策清單、服務資訊、使用空間、災難演練記錄,而檢查人員當然不可以是DLP管理者,因為涵蓋的層面太多,管理者可能不只一人,為了客觀起見,建議由稽核暫代此一職務,以保持公正立場。

此外評估維護廠商也是另一個考量的目標,包含這一服務年度是否有相關缺失,例如:
1. 服務人員水準不足
2. 服務時間過於冗長
3. 未能提供進階的諮詢

Action 行動
在查核DLP目前的狀況後,並針對系統中不同存在之風險,就要採取行動,然而行動有可能會增加相關的資源,此時主管的再度支持就更為重要,DLP在先期導入時,主管也許很支持,但是如果定期審查作業時並未提出相關的效益,主管也許就覺得DLP系統可有可無,此時要再增加認同感可能就會失敗,所以在查核行動尤其重要,並且要點出DLP系統目前現況缺失及可強化防止外洩風險的強度為主要,例如可能因為企業擴增辦公室,又或者網路節點變多,所以DLP就需要增加監控點,來強化預防外洩的可能,增加政策以降低誤判率。又或者DLP在線存放事件的空間不足,是否要增加在線式擴充系統?技術移轉課程是否要增加受訓人員,以避免人力外流或有管理者請假突發事件情況?而維護廠商在評估之後,是否要求增加服務項目,提昇服務水準(服務時間由5*8提升至7*24)?這些都可以在檢核過後來進一步行動,以提升DLP系統的整體運作架構。

當要行動時,就要重新參考計畫(Plan),以進行循環的方式,讓DLP系統在企業內中,不會形成一套只是擺好看的系統。
本文作者為系統整合商資安顧問