網站首頁 > 熱門病毒專題 > 大型網際網路公司如何防止駭客入侵?(下)
 
標題:大型網際網路公司如何防止駭客入侵?(下)
分類:熱門病毒專題 日期:2018/12/4 上午 10:45:31

大型網際網路公司如何防止駭客入侵?(下)

江民科技  2018/12/3

 

上一期給大家推送過

《大型網際網路公司如何防止駭客入侵(上)?》,

今天將繼續為大家奉上精彩內容~

 

入侵威脅預警是否真的有效?

 

而時下最火爆的AI是否也可以對駭客入侵做出有效的檢測~

 

想知道嗎?那就快來閱讀今天的推送內容吧!

 

 

 

入侵偵測基本原則

 

不能把每一條告警都徹底跟進的模型,等同於無效模型。入侵發生後,再辯解之前其實有告警,只是太多了沒跟過來/沒查徹底,這是“馬後炮”,等同於不具備發現能力。

 

所以對於日均告警成千上萬的產品,安全運營人員往往表示很無奈。我們必須遮罩一些重複發生的相似告警,以集中精力把每一個告警都閉環掉。這會產生白名單,也就是漏報,因此模型的漏報是不可避免的。

 

由於任何模型都會存在漏報,所以我們必須在多個緯度上做多個模型,形成關聯和縱深。

 

假設 WebShell 靜態文本分析被駭客變形繞過了,在 RASP(運行時環境)的惡意調用還可以進行監控,這樣可以選擇接受單個模型的漏報,但在整體上仍然具備發現能力。

 

既然每一個單一場景的模型都有誤報漏報,我們做什麼場景,不做什麼場景,就需要考慮“性價比”。

 

比如某些變形的 WebShell 可以寫成跟業務代碼非常相似,人的肉眼幾乎無法識別,再追求一定要在文本分析上進行對抗,就是性價比很差的決策。如果通過 RASP 的檢測方案,其性價比更高一些,也更具可行性一些。

 

我們不太容易知道駭客所有的攻擊手法,也不太可能針對每一種手法都建設策略(考慮到資源總是稀缺的)。

 

所以針對重點業務,需要可以通過加固的方式(還需要常態化監控加固的有效性),讓駭客能攻擊的路徑極度收斂,僅在關鍵環節進行對抗。起碼能針對核心業務具備兜底的保護能力。

 

基於上述幾個原則,我們可以知道一個事實,或許我們永遠不可能在單點上做到 100% 發現入侵,但是我們可以通過一些組合方式,讓攻擊者很難繞過所有的點。

 

當老闆或者藍軍挑戰,某個單點的檢測能力有缺失時,如果為了“政治正確”,在這個單點上進行無止境的投入,試圖把單點做到 100% 能發現的能力,很多時候可能只是在試圖製造一個“永動機”,純粹浪費人力、資源,而不產生實際的收益。

 

將節省下來的資源,高性價比的佈置更多的縱深防禦鏈條,效果顯然會更好。

 

 

入侵偵測產品的主流形態

 

入侵偵測終究是要基於資料去建模,比如針對 WebShell 的檢測,首先要識別 Web 目錄,再對 Web 目錄下的檔進行文本分析,這需要做一個採集器。

 

基於 Shell 命令的入侵偵測模型,需要獲取所有 Shell 命令,這可能要 Hook 系統調用或者劫持 Shell

 

基於網路 IP 信譽、流量 payload 進行檢測,或者基於郵件閘道對內容的檢查,可能要植入網路邊界中,對流量進行旁路採集。

 

也有一些集大成者,基於多個 Sensor,將各方日誌進行採集後,匯總在一個 SOC 或者 SIEM,再交由大資料平臺進行綜合分析。

 

因此,業界的入侵偵測相關的產品大致上就分成了以下的形態:

 

①主機 Agent 類:駭客攻擊了主機後,在主機上進行的動作,可能會產生日誌、進程、命令、網路等痕跡,那麼在主機上部署一個採集器(也內含一部分檢測規則),就叫做基於主機的入侵偵測系統,簡稱 HIDS

 

典型的產品:國內有很多做入侵偵測類的產品,具體效果各有分說,江民病毒威脅預警在同類型產品中做的較好,感興趣可以關注一下。當然,一些 APT 廠商,往往也有在主機上的 Sensor/Agent,比如 FireEye 等一些產品都做得不錯。

 

②網路檢測類:由於多數攻擊向量是會通過網路對目標投放一些 payload,或者控制目標的協定本身具備強特徵,因此在網路層面具備識別的優勢。

 

典型的產品:Snort 到商業的各種 NIDS/NIPS,對應到 APT 級別,則還有類似於 FireEye NX 之類的產品。

 

③日誌集中存儲分析類:這一類產品允許主機、網路設備、應用都輸出各自的日誌,集中到一個統一的後臺。

 

在這個後臺,對各類日誌進行綜合的分析,判斷是否可以關聯的把一個入侵行為的多個路徑刻畫出來。

 

例如 A 主機的 Web 訪問日誌裡顯示遭到了掃描和攻擊嘗試,繼而主機層面多了一個陌生的進程和網路連接,最後 A 主機對內網其他主機進行了橫向滲透嘗試。

 

典型的產品:LogRhythmSplunk SIEM 類產品。

 

APT 沙箱:沙箱類產品更接近於一個雲端版的高級防毒軟體,通過類比執行觀測行為,以對抗未知樣本弱特徵的特點。

 

只不過它需要一個類比運行的過程,性能開銷較大,早期被認為是“性價比不高”的解決方案,但由於惡意檔在行為上的隱藏要難於特徵上的對抗,因此現在也成為了 APT 產品的核心元件。

 

通過網路流量、終端採集、伺服器可疑樣本提取、郵件附件提煉等拿到的未知樣本,都可以提交到沙箱裡跑一下行為,判斷是否惡意。

 

典型產品:FireEyePalo AltoSymantec、微步。

 

⑤終端入侵偵測產品:移動端目前還沒有實際的產品,也不太有必要。PC 端首先必備的是防毒軟體,如果能夠檢測到惡意程式,一定程度上能夠避免入侵。

 

但是如果碰到免殺的高級 0day 和木馬,防毒軟體可能會被繞過。借鑒伺服器上 HIDS 的思路,也誕生了 EDR 的概念,主機除了有本地邏輯之外,更重要的是會採集更多的資料到後端,在後端進行綜合分析和聯動。

 

也有人說下一代防毒軟體裡都會帶上 EDR 的能力,只不過目前銷售還是分開在賣。

 

典型產品:防毒軟體有江民、SEP、賽門鐵克、卡巴斯基、McAfee EDR產品不枚舉了,騰訊的 iOA、阿裡的阿裡郎,一定程度上都是可以充當類似的角色,相對來說江民EDR專業性更強一些。

 

 

入侵偵測效果評價指標

 

首先,主動發現的入侵案例/所有入侵 = 主動發現率。這個指標一定是最直觀的。

 

比較麻煩的是分母,很多真實發生的入侵,如果外部不回饋,我們又沒檢測到,它就不會出現在分母裡,所以有效發現率總是虛高的,誰能保證當前所有的入侵都發現了呢?

 

但是實際上,只要入侵次數足夠多,不管是 SRC 收到的情報,還是“暗網”上報出來的一個大新聞,把客觀上已經知悉的入侵列入分母,總還是能計算出一個主動發現率的。

 

另外,真實的入侵其實是一個低頻行為,大型的網際網路企業如果一年到頭成百上千的被入侵,肯定也不正常。

 

因此,如果很久沒出現真實入侵案例,這個指標長期不變化,也無法刻畫入侵偵測能力是否在提升。

 

所以,我們一般還會引入兩個指標來觀測:

■藍軍對抗主動發現率

■已知場景覆蓋率

 

藍軍主動高頻對抗和演習,可以彌補真實入侵事件低頻的不足,但是由於藍軍掌握的攻擊手法往往也是有限的,他們多次演習後,手法和場景可能會被羅列完畢。

 

假設某一個場景建設方尚未補齊能力,藍軍同樣的姿勢演習 100 遍,增加 100 個未發現的演習案例,對建設方而言並沒有更多的幫助。所以,把已知攻擊手法的建成覆蓋率拿出來,也是一個比較好的評價指標。

 

入侵偵測團隊把精力聚焦在已知攻擊手法的優先順序評估和快速覆蓋上,對建設到什麼程度是滿足需要的,要有自己的專業判斷(參考入侵偵測原則裡的“性價比”原則)。

 

而宣佈建成了一個場景的入侵發現能力,是要有基本的驗收原則的:

■該場景日均工單 < X單,峰值 < Y單;當前所有場景日平均,峰值 ,超出該指標的策略不予接收,因為過多的告警會導致有效資訊被淹沒,反而導致此前具備的能力被干擾,不如視為該場景尚未具備對抗能力。

■同一個事件只告警首次,多次出現自動聚合。

■具備誤報自學習能力。

■告警具備可讀性(有清晰的風險闡述、關鍵資訊、處理指引、輔助資訊或者索引,便於定性),不鼓勵 Key-Value 模式的告警,建議使用自然語言描述核心邏輯和回應流程。

■有清晰的說明文檔,自測報告(就像交付了一個研發產品,產品文檔和自測過程是品質的保障)。

■有藍軍針對該場景實戰驗收報告。

■不建議調用微信、短信等介面發告警(告警和事件的區別是,事件可以閉環,告警只是提醒),統一的告警事件框架可以有效的管理事件確保閉環,還能提供長期的基礎運營資料,比如止損效率、誤報量/率。

 

策略人員的文檔應當說明當前模型對哪些情況具備感知能力,哪些前提下會無法告警(考驗一個人對該場景和自己模型的理解能力)。

 

通過前述判斷,可以對策略的成熟度形成自評分,0-100 自由大致估算。單個場景往往很難達到 100 分,但那並沒有關係,因為從 80 分提升到 100 分的邊際成本可能變的很高。

 

不建議追求極致,而是全盤審視,是否快速投入到下一個場景中去。

 

如果某個不到滿分的場景經常出現真實對抗,又沒有交叉的其他策略進行彌補,那自評結論可能需要重審並提高驗收的標準。至少解決工作中實際遇到的 Case 要優先考慮。

 

 

影響入侵偵測的關鍵要素

 

討論影響入侵偵測的要素時,我們可以簡單看看,曾經發生過哪些錯誤導致防守方不能主動發現入侵:

■依賴的資料丟失,比如 HIDS 在當事機器上,沒部署安裝/Agent 掛了/資料上報過程丟失了/Bug 了,或者後臺傳輸鏈條中丟失資料。

■策略腳本 Bug,沒啟動(事實上我們已經失去了這個策略感知能力了)。

■還沒建設對應的策略(很多時候入侵發生了才發現這個場景我們還沒來得及建設對應的策略)。

■策略的靈敏度/成熟度不夠(比如掃描的閾值沒達到,WebShell 用了變形的對抗手法)。

■模型依賴的部分基礎資料錯誤,做出了錯誤的判斷。

■成功告警了,但是負責應急同學錯誤的判斷/沒有跟進/輔助資訊不足以定性,沒有行動起來。

 

所以實際上,要讓一個入侵事件被捕獲,我們需要入侵偵測系統長時間、高品質、高可用的運行。這是一件非常專業的工作,超出了絕大多數安全工程師能力和意願的範疇。

 

所以建議指派專門的運營人員對以下目標負責:

■資料獲取的完整性(全鏈路的對賬)。

■每一個策略時刻工作正常(自動化撥測監控)。

■基礎資料的準確性。

■工單運營支撐平臺及追溯輔助工具的便捷性。

 

可能有些同學會想,影響入侵偵測的關鍵要素,難道不是模型的有效性麼?怎麼全是這些亂七八糟的東西?

 

實際上,大型網際網路企業的入侵偵測系統日均資料量可能到達數百 T,甚至更多。

 

涉及到數十個業務模組,成百上千台機器。從數位規模上來說,不亞於一些中小型企業的整個資料中心。

 

這樣複雜的一個系統,要長期維持在高可用標準,本身就需要有 SREQA 等輔助角色的專業化支持。

 

如果僅依靠個別安全工程師,很難讓其研究安全攻防的時候,又兼顧到基礎資料品質、服務的可用性和穩定性、發佈時候的變更規範性、各類運營指標和運維故障的及時響應。

 

最終的結果就是能力範圍內可以發現的入侵,總是有各種意外“恰好”發現不了。

 

所以,筆者認為,以多數安全團隊運營品質之差,其實根本輪不到拼策略(技術)。當然,一旦有資源投入去跟進這些輔助工作之後,入侵偵測就真的需要拼策略了。

 

此時,攻擊手法有那麼多,憑什麼先選擇這個場景建設?憑什麼認為建設到某程度就足夠滿足當下的需要了?憑什麼選擇發現某些樣本,而放棄另一些樣本的對抗?

 

這些看似主觀性的東西,非常考驗專業判斷力。而且在領導面前很容易背上“責任心不足”的帽子。

 

比如為困難找藉口而不是為目標找方法,這個手法駭客攻擊了好多次,憑什麼不解決,那個手法憑什麼說在視野範圍內,但是要明年再解決?

 

 

如何發現 APT

 

所謂 APT,就是高級持續威脅。既然是高級的,就意味著木馬很大可能是免殺的(不能靠防毒軟體或者普通的特徵發現),利用的漏洞也是高級的(加固到牙齒可能也擋不住敵人進來的步伐),攻擊手法同樣很高級(攻擊場景可能我們都沒有見過)。

 

所以,實際上 APT 的意思,就約等於不能被發現的入侵。然而,業界總還有 APT 檢測產品,解決方案的廠商在混飯吃,他們是怎麼做的呢?

 

木馬免殺的,用沙箱+人工分析,哪怕效率低一些,還是試圖做出定性,並快速的把 IOC(威脅情報)同步給其他客戶,發現 1 例,全球客戶都具備同樣的感知能力。

 

流量加密變形對抗的,用異常檢測的模型,把一些不認識的可疑的 IP 關係、payload 給識別出來。當然,識別出來之後,也要運營人員跟進得仔細,才能定性。

 

攻擊手法高級的,還是會假定駭客就用魚叉、水坑之類的已知手法去執行,然後在郵箱附件、PC 終端等環節採集日誌,對使用者行為進行分析,UEBA 試圖尋找出用戶異於平常的動作。

 

那麼,我們呢?筆者也沒有什麼好的辦法,可以發現傳說中的“免殺”的木馬,但是我們可以針對已知的駭客攻擊框架(比如 MetasploitCobalt Strike)生成的樣本、行為進行一些特徵的提取。

 

我們可以假設已經有駭客控制了某一台機器,但是它試圖進行橫向擴散的時候,我們有一些模型可以識別這個主機的橫向移動行為。

 

筆者認為,世界上不存在 100% 能發現 APT 的方法。但是我們可以等待實施 APT 的團隊犯錯,只要我們的縱深足夠的多,資訊足夠不對稱,想要完全不觸碰我們所有的鈴鐺,絕對存在一定的困難。

 

甚至,攻擊者如果需要小心翼翼的避開所有的檢測邏輯,可能也會給對手一種心理上的震懾,這種震懾可能會延緩對手接近目標的速度,拉長時間。而在這個時間裡,只要他犯錯,就輪到我們出場了。

 

前面所有的高標準,包括高覆蓋、低誤報,強制每一個告警跟進到底,“掘地三尺”的態度,都是在等待這一刻。抓到一個值得敬佩的對手,那種成就感,還是很值得回味的。

 

所以,希望所有從事入侵偵測的安全同行們都能堅持住,即使聽過無數次“狼來了”,下一次看到告警,依然可以用最高的敬畏心去迎接對手(告警虐我千百遍,我待告警如初戀)。

 

 

AI 在入侵偵測領域的正確姿勢

 

最近這兩年,如果不談 AI 的話,貌似故事就不會完整。只不過,隨著 AI 概念的火爆,很多人已經把傳統的資料採擷、統計分析等思想,比如分類、預測、聚類、關聯之類的演算法,都一律套在 AI 的帽子裡。

 

其實 AI 是一種現代的方法,在很多地方有非常實際的產出了。以 WebShell 的文本分析為例,我們可能需要花很長很長的時間,才能把上千個樣本裡隱含的幾十種樣本技術類型拆分開,又花更長的時間去一一建設模型(是的,在這樣的場景下,特徵工程真的是一個需要更長時間的工作)。

 

而使用 AI,做好資料打標的工作,訓練、調參,很快就能拿到一個實驗室環境不那麼過擬合的模型出來,迅速投產到生產環境上。熟練一點可能 1-2 個月就能做完了。

 

在這種場景下,AI 這種現代的方法,的確能極大的提高效率。但問題是,前文也提到過了,駭客的攻擊黑樣本、WebShell 的樣本,往往極其稀缺,它不可能是完備的能夠描述駭客入侵的完整特徵的。

 

因此,AI 產出的結果,無論是誤報率還是漏報率,都會受訓練方法和輸入樣本的影響較大,我們可以借助 AI,但絕對不能完全交給 AI

 

安全領域一個比較常見的現象是,將場景轉變成標記問題,要難於通過數學模型把標記的解給求出來。

 

此時往往需要安全專家先行,演算法專家再跟上,而不能直接讓演算法專家“孤軍奮戰”。

 

針對一個具體的攻擊場景,怎麼樣採集對應的入侵資料,思考這個入侵動作和正常行為的區別,這個特徵的提取過程,往往決定了模型最終的效果。特徵決定了效果的上限,而演算法模型只能決定了有多接近這個上限。

 

此前,筆者曾見過一個案例,AI 團隊產出了一個實驗室環境效果極佳,誤報率達到1/1000000 WebShell 模型,但是投放到生產環境裡初期日均告警 6000 單,完全無法運營,同時還存在不少漏報的情況。

 

這些情況隨著安全團隊和 AI 工程師共同的努力,後來逐漸地解決。但是並未能成功的取代原有的特徵工程模型。

 

目前業界有許多產品、文章在實踐 AI,但遺憾的是,這些文章和產品大多“淺嘗輒止”,沒有在真實的環境中實踐運營效果。

 

一旦我們用前面的標準去要求它,就會發現,AI 雖然是個好東西,但是絕對只是個“半成品”。真正的運營,往往需要傳統的特徵工程和 AI 並行,也需要持續地進行反覆運算。

 

 

網路急速發展的時代

網際網路公司

著很好的發展市場和未來

但是在發展的路上

總要必不可免的要注意

網路安全問題

網際網路公司不僅要注意的是

公司本身的網路安全

更要保護好用戶的隱私安全

這樣不僅可以保護好自身的安全問題

也會贏得更多的用戶信賴~

 

Bye!!

 
 
 
CopyRight  © 江民科技 1996 - 2021 版權所有 All Rights Reserved
總代理:六合國際實業有限公司 E-mail: jiangmin@jiangmin.com.tw