【廉環話】安全入侵應對實務—泄露防護篇
原創【51CTO.com原創稿件】不可否認,我們正處在數據爆炸的時代,無論是初創公司還是百年老店,企業里的各種文件每天都在以幾何的數量級增長著。數據在企業內部的存儲和企業之間的流通環境日趨復雜。無論是在數據庫、應用中間件、用戶終端、業務系統和網絡設備上,還是數據的產生、存儲、使用、修改、流轉和銷毀等各個環節,數據泄漏的可能性隨時隨處都會發生。
我們作為企業一線的IT人員,面對這些反復重演的扎心劇情,就算你能拍馬趕到,也往往卻是為時已晚。面對領導的壓力和用戶的抱怨,我們光靠躲進“深夜廚房”吃泡面是顯然不夠的。那么這一次,讓我來給大家靜水流深地切開數據泄漏防護(DLP)這塊“大牛排”,咱們一口、一口地來咀嚼它。
西方理念中常提到“雙人舞”的概念,我們東方人則常談的是圍棋里的兩眼論,那么下面我就從防御和檢測兩個方面來進行深入討論。
識別數據泄露的“災區”
- 有過數據庫管理經驗的小伙伴應該都有這種感受:如今各種安防產品對各種后臺數據庫里的數據可謂是“嚴防死守”,而往往容易造成敏感數據泄漏的形式卻是那些非結構化的內容。說白了就是那些Excel、PPT里的數據,以及PDF和剪貼板的圖片文件等。
- 另一個數據泄露的“災區”是企業的文件與信息的交換平臺,如大家日常頻繁使用的郵件客戶端(如Outlook)和內網協作平臺(如SharePoint)。當前,隨著云平臺的使用,各種企業混合云以及公網上的共享云平臺(如百度云等)都成為了數據被轉移出去的“跳板”。
從管理上杜絕泄漏的發生
- 在生成文檔和數據的時候,應按照最小權限的原則設定好各類屬性的默認值,如attribute默認為私有(private)而非公開(public),可訪問(包括讀/寫/改/刪等權限)的用戶群僅限于創建者所在的部門和組。同時在屬主(屬主不一定是創建者,也可以是日常使用人)的崗位發生變化時(如離職或調崗),要做好接任屬主的接管工作。
- 規范文件、文件夾和數據的命名規則(Naming convention),以便能夠根據其表征名稱迅速定位或追查。
- 對于那些并無屬主或是項目已結束的文檔,本地管理員應及時聯系業務部門做好集中和離線轉移的工作。
- 對于各種非常規的共享方式,如按需添加的服務器或主機文件夾的臨時共享,應予以集中化的記錄。這是在源頭上實施的用戶行為和習慣控制,也是數據泄露防護的最佳實踐之一。
- 培養用戶在處理敏感數據時的遮擋意識和與客戶交換文件時的加密習慣。
從架構上清除泄漏的坑點
- 用戶終端必須使用安全的代理服務器進行上網,以預防惡意軟件、釣魚網站、域名劫持和其他類似的攻擊。
- 入站的電子郵件里如果包含有外部的鏈接,應通過反釣魚技術的鏈接重寫方式發送到管控中心進行健康檢查,從而抵御潛在的垃圾郵件和釣魚攻擊。
- 用戶終端除了本地的硬盤加密之外,還要通過組策略(Group Policy)禁止用戶擅自修改系統設置和安裝軟件。
- 為那些必須連到內網進行協作的上下游合作伙伴,提供非本域的賬號和受限的VPN遠程連接方式。同時,非本域的賬號登錄到企業的無線網絡時,應限制其僅能向外訪問到互聯網,這種單一的訪問路徑與權限。
- 通過在用戶終端上安裝主機測的DLP agent,過濾和監控帶有敏感字段的文檔、數據(如源代碼)、郵件以及剪貼板上的內容,防止用戶通過網絡或移動設備拷貝的方式轉移到不安全的系統、設備甚至是公網的網盤上。
- 在內網中部署網絡級的DLP,以旁路式分析流量,從而識別出im(即時通訊)、http、ftp、telnet和smtp等協議中正文及附件內容。
- 對于如今許多企業都應用到的云服務,可以購置和部署最新類型的DLP,通過與云訪問安全代理 (CASB)的集成,持續監控各種云應用程序中敏感數據內容的添加、修改和刪除。
有“記”無患,未雨綢繆
前面幾期的廉環話,我們有提到對系統和網絡日志的檢測。正所謂巧婦難為無米之炊,那么首先你就要能得到及時且充分的各類日志。在設計或添置日志系統的時候,我們需要捫心自問、或是與部門內成員討論如下與記錄有關的問題:
- 進行了什么操作?
- 誰或是哪個系統(即主體)執行的操作?
- 對誰或是哪個系統(即對象) 執行的操作?
- 何時操作的?
- 操作用到了什么工具?
- 操作后的狀態(如成功與失敗)、結果、或輸出是什么?
在日志分類上,想必大家都能區分出:操作系統日志、應用系統日志、數據庫日志、網絡設備日志和安全設備日志的基本不同。而各類日志所記錄的基本信息也應涵括到:設備/服務本身的啟動/關閉/重啟,用戶的登錄/注銷/密碼修改,服務屬性的配置/變更,關鍵進程/端口的啟動/關閉,權限的切換,以及各種報警/故障信息等。
既然有這么多類型的日志,而且會產生海量的記錄條目,那么我們就需要用一套集中化的日志管理系統,通過使用syslog或syslog-ng之類的開放網絡協議來匯聚歷史信息,從而進行過濾和分析。說到這里,愛思考的小伙伴也許會問了:既然針對的是歷史信息,那么是否有針對實時的呢?我的回答是:還真的有,那就是SIEM(安全信息事件管理),它可以對各類實時的記錄進行事件關聯與趨勢分析。
值得多說一句的是:一般日志管理系統都應該能夠將發送來的、各種格式的日志存儲到一個遵循ansi-sql規范的數據庫中,以方便日后生成適合審計的日志文件。
準確定位,有的放矢
前面我們介紹了各項基礎性的準備工作。Let’s move forward。正所謂沒有絕對的安全。那么一旦不幸發生了數據泄漏事件,我們應該從哪里著手進行檢測甚至是取證呢?在此,我給大家提供一個可參考的速查藍本。
- 在用戶終端上,使用取證工具對電子郵件客戶端、瀏覽器的脫機內容、瀏覽歷史等進行檢查。注意,有些人會使用到不同的瀏覽器(如IE、Chrome、Firefox等),因此一定要逐一檢查每一個瀏覽器的歷史記錄。
- 在代理服務器的相關日志里檢查可疑賬戶訪問過的URL及其服務類型。
- 在可疑用戶使用過的各種外部存儲設備(如U盤、CD、DVD、移動硬盤、智能手機以及SD卡等)上直接或間接(如利用恢復工具)尋找蛛絲馬跡。
- 當然,用戶也可能身處企業之外,通過VPN連進來,或者是在企業內連接到外部的SSH服務器進行數據的收與發。在這種情況下,我們一般只能找到有關連接的記錄證明,卻無法查看到具體傳送的數據內容。
- 除了電子的形式,數據或文件也可能被發送到打印機轉成hard copy。在這種情況下,我們應該對用戶端的假脫機程序或直接在打印機上進行檢查。
- 有時候用戶并非主動泄漏信息,而是其終端上的惡意軟件所致。對此,我們可以結合網上最近針對各類頻發的惡意病毒的相關對策進行逐一識別。這里就不贅述了。
識別關鍵,篩選策略
既然我們屢次提到日志和記錄,那么面對汗牛充棟的“大數據”,應該如何大海撈針呢?我分享給大家如下的特征關鍵點,以便籍此進行篩選策略的制定:
- 新用戶或組的添加,對用戶權限的改變,身份驗證和授權的相關活動。
- 文件及文件夾屬性、注冊表鍵值以及計劃任務(自啟動項)的更改。
- 系統和軟件補丁的安裝和更新,新軟件的安裝、升級與卸載。
- 數據庫對象權限的修改。
- 達到資源門限值(比如CPU、內存、網絡連接、網絡帶寬、磁盤空間等)所導致的應用程序進程的中止、異常或報錯,網絡服務(如DHCP和DNS)的失敗,以及硬件故障等。
- FW/IDS/IPS/AV(防病毒系統)的規則更改和端口調整。
日志元素,抽絲剝繭
在得到了上述篩選過的分類記錄之后,我們可以回顧一下在前面準備設計階段所思考過的問題列表。我們同樣可以進一步將“理想”照進“現實”,著手對如下的日志元素進行分析:
- 操作的類型,包括各種授權、創建、讀取、更新、刪除和網絡連接的接受。
- 操作的屬性,包括流程或事務的名稱或唯一標識號。
- 操作主體的特征,包括用戶名、計算機名、IP地址和MAC地址。
- 操作對象的特征,包括訪問的文件名、訪問數據庫的查詢/定位參數和記錄的唯一標識號、用戶名、計算機名、IP地址和MAC地址。
- 當操作涉及到更新數據元素時,其執行前、后的不同數值。
- 操作執行的日期和時間,包括相對應的時區信息。
- 根據訪問控制機制,被拒絕的相關描述和原因/錯誤代碼。
日志維護,查缺補漏
最后,我給大家分享一下日志系統維護的落地和實操。
- 首先最為重要的、也是經常被運維人員所忽略的是:日志管理系統必須保持其時鐘信息與內網里各臺服務器的時鐘相同步。這可以通過設置NTP來實現,當然運維人員也可以每月檢查確認,并予以記錄。
- 各類日志內容至少需要保存半年,關鍵系統的日志甚至可以延長為一年。
- 任何運維人員不得擅自停用日志服務。如需暫停某項日志記錄,則要走常規的變更管理的流程。
- 運維人員應每周登錄到日志管理系統進行檢查,對日志中的錯誤或可疑項進行記錄。如發現有可疑的事件或無法判斷的內容,應提交給信息安全部門進行分析,處理結果應當被補充標注到例檢中。
- 各類日志文件應被集中管理和存放,同樣需設置相應的日志文件的訪問控制權限,以防止未授權的篡改或刪除。
- 內部審計部門應當定期(如每季度)對日志的采集范圍和篩選策略進行檢查,并對各個系統管理員和操作員的操作記錄進行審計。
小結
隨著技術的不但迭代和升級,現在信息安全業界也出現了端點檢測與響應(EDR)的解決方案。它不但可以基于威脅情報和大數據分析,來發現新的威脅行為或攻擊跡象,還能進行威脅追蹤和數據回溯。
我們做信息安全實務的,不應該只會單純利用各類產品,像“打地鼠”那樣出現一個問題就去解決一個問題,而是應該掌握基本全面的理念和思路,活用技術和產品實現1+1>2的閉環防護效果。各位老鐵,上述的娓娓分析,雖談不上什么庖丁解牛,但整體結構還算比較清晰,相信愛思考、愛做筆記的您已經能畫出一張思維導圖或是系統結構圖了吧?好的,請直接拿去使用吧,不謝!
【51CTO原創稿件,合作站點轉載請注明原文作者和出處為51CTO.com】