“
如何知道自己所在的企業是否被入侵了？是沒人來“黑”，還是因自身感知能力不足，暫時還無法發現？
其實，入侵檢測是每一個大型互聯網企業都要面對的嚴峻挑戰。價值越高的公司，面臨入侵的威脅也越大，即便是 Yahoo 這樣的互聯網鼻祖，在落幕（被收購）時仍遭遇全量數據失竊的事情。
安全無小事，一旦互聯網公司被成功“入侵”，其後果將不堪想象。
基於“攻防對抗”的考量，本文不會提及具體的入侵檢測模型、算法和策略，那些希望直接照搬“入侵策略”的同學可能會感到失望。
但是我們會將一部分運營思路分享出來，請各位同行指點，如能對後來者起到幫助的作用，那就更好了，也歡迎大家跟我們交流探討。
入侵的定義
典型的入侵場景：黑客在很遠的地方，通過網絡遠程控制目標的筆記本電腦/手機/服務器/網絡設備，進而隨意地讀取目標的隱私數據，又或者使用目標系統上的功能，包括但不限於使用手機的麥克風監聽目標，使用攝像頭偷窺監控目標，使用目標設備的計算能力挖礦，使用目標設備的網絡能力發動 DDoS 攻擊等等。亦或是破解了一個服務的密碼，進去查看敏感資料、控制門禁/紅綠燈。以上這些都屬於經典的入侵場景。
我們可以給入侵下一個定義：就是黑客在未經授權的情況下，控制、使用我方資源（包括但不限於讀寫數據、執行命令、控制資源等）達到各種目的。
從廣義上講，黑客利用 SQL 注入漏洞竊取數據，或者拿到了目標域名在 ISP 中的帳號密碼，以篡改 DNS 指向一個黑頁，又或者找到了目標的社交帳號，在微博/QQ/郵箱上，對虛擬資產進行非授權的控制，都屬於入侵的範疇。
針對企業的入侵檢測
企業入侵檢測的範圍，多數情況下比較狹義：一般特指黑客對 PC、系統、服務器、網絡（包括辦公網、生產網）控制的行為。
黑客對 PC、服務器等主機資產的控制，最常見的方法是通過 Shell 去執行指令，獲得 Shell 的這個動作叫做 GetShell。
比如通過 Web 服務的上傳漏洞，拿到 WebShell，或者利用 RCE 漏洞直接執行命令/代碼（RCE 環境變相的提供了一個 Shell）。
另外，通過某種方式先植入“木馬後門”，後續直接利用木馬集成的 Shell 功能對目標遠程控制，這個也比較典型。
因此，入侵檢測可以重點關注 GetShell 這個動作，以及 GetShell 成功之後的惡意行為（為了擴大戰果，黑客多半會利用 Shell 進行探測、翻找竊取、橫向移動攻擊其他內部目標，這些區別於好人的特性也可以作為重要的特徵）。
有一些同行（包括商業產品），喜歡報告 GetShell 之前的一些“外部掃描、攻擊探測和嘗試行為”，並美其名曰“態勢感知”，告訴企業有人正在“試圖攻擊”。
在筆者看來，實戰價值並不大。包括美團在內的很多企業，基本上無時無刻都在遭受“不明身份”的攻擊。
知道了有人在“嘗試”攻擊，如果並不能有效地去行動，無法有效地對行動進行告警，除了耗費心力之外，並沒有太大的實際價值。
當我們習慣“攻擊”是常態之後，就會在這樣的常態下去解決問題，可以使用什麼加固策略，哪些可以實現常態化的運營，如果有什麼策略無法常態化運營。
比如需要很多人加班臨時突擊守著，那這個策略多半在不久之後就會逐漸消逝掉。跟我們做不做這個策略，並沒有本質上的區別。
類似於 SQL 注入、XSS 等一些不直接 GetShell 的 Web 攻擊，暫時不在狹義的“入侵檢測”考慮範圍，建議可以劃入“漏洞”、“威脅感知”等領域，另行再做探討。
當然，利用 SQL 注入、XSS 等入口，進行了 GetShell 操作的，我們仍抓 GetShell 這個關鍵點，不必在乎漏洞入口在何處。
“入侵”和“內鬼”
與入侵接近的一種場景是“內鬼”。入侵本身是手段，GetShell 只是起點，黑客 GetShell 的目標是為了之後對資源的控制和數據的竊取。
而“內鬼”天然擁有合法的權限，可以合法接觸敏感資產，但是基於工作以外的目的，他們對這些資源進行非法的處置，包括拷貝副本、轉移外洩、篡改數據牟利等。
內鬼的行為不在“入侵檢測”的範疇，一般從內部風險控制的視角進行管理和審計，比如職責分離、雙人審計等。也有數據防洩密產品（DLP）對其進行輔助，這裡不展開細說。
有時候，黑客知道員工 A 有權限接觸目標資產，便定向攻擊 A，再利用 A 的權限把數據竊取走，也定性為“入侵”。
畢竟 A 不是主觀惡意的“內鬼”。如果不能在黑客攻擊 A 的那一刻捕獲，或者無法區分黑客控制的 A 竊取數據和正常員工 A 的訪問數據，那這個入侵檢測也是失敗的。
入侵檢測的本質
前文已經講過，入侵就是黑客可以不經過我們的同意，來操作我們的資產，在手段上並沒有任何的限制。
那麼如何找出入侵行為和合法正常行為的區別，將其跟合法行為進行分開，就是“入侵發現”。在算法模型上，這算是一個標記問題（入侵、非入侵）。
可惜的是，入侵這種動作的“黑”樣本特別稀少，想通過大量的帶標籤的數據，有監督的訓練入侵檢測模型，找出入侵的規律比較難。
因此，入侵檢測策略開發人員，往往需要投入大量的時間，去提煉更精準的表達模型，或者花更多的精力去構造“類似入侵”的模擬數據。
一個經典的例子是，為了檢測出 WebShell，安全從業人員可以去 GitHub 上搜索一些公開的 WebShell 樣本，數量大約不到 1000 個。
而對於機器學習動輒百萬級的訓練需求，這些數據遠遠不夠。況且 GitHub 上的這些樣本集，從技術手法上來看，有單一技術手法生成的大量類似樣本，也有一些對抗的手法樣本缺失。
因此，這樣的訓練，試圖讓 AI 去通過“大量的樣本”掌握 WebShell 的特徵並區分出它們，原則上不太可能完美地去實現。
此時，針對已知樣本做技術分類，提煉更精準的表達模型，被稱為傳統的特徵工程。
而傳統的特徵工程往往被視為效率低下的重複勞動，但效果往往比較穩定，畢竟加一個技術特徵就可以穩定發現一類 WebShell。
而構造大量的惡意樣本，雖然有機器學習、AI 等光環加持，但在實際環境中往往難以獲得成功：自動生成的樣本很難描述 WebShell 本來的含義，多半描述的是自動生成的算法特徵。
另一個方面，入侵的區別是看行為本身是否“授權”，而授權與否本身是沒有任何顯著的區分特徵的。
因此，做入侵對抗的時候，如果能夠通過某種加固，將合法的訪問收斂到有限的通道，並且給該通道做出強有力的區分，也就能大大的降低入侵檢測的成本。
例如，對訪問來源進行嚴格的認證，無論是自然人，還是程序 API，都要求持有合法票據。
而派發票據時，針對不同情況做多緯度的認證和授權，再用 IAM 針對這些票據記錄和監控它們可以訪問的範圍，還能產生更底層的 Log 做異常訪問模型感知。
這個全生命週期的風控模型，也是 Google 的 BeyondCorp 無邊界網絡得以實施的前提和基礎。
因此，入侵檢測的主要思路也就有兩種：
根據黑特徵進行模式匹配（例如 WebShell 關鍵字匹配）。
根據業務歷史行為（生成基線模型），對入侵行為做異常對比（非白即黑），如果業務的歷史行為不夠收斂，就用加固的手段對其進行收斂，再挑出不合規的小眾異常行為。
入侵檢測與攻擊向量
根據目標不同，可能暴露給黑客的攻擊面會不同，黑客可能採用的入侵手法也就完全不同。
比如，入侵我們的 PC/筆記本電腦，還有入侵部署在機房/雲上的服務器，攻擊和防禦的方法都有挺大的區別。
針對一個明確的“目標”，它被訪問的渠道可能是有限集，被攻擊的必經路徑也有限。“攻擊方法”+“目標的攻擊面”的組合，被稱為“攻擊向量”。
因此，談入侵檢測模型效果時，需要先明確攻擊向量，針對不同的攻擊路徑，採集對應的日誌（數據），才可能做對應的檢測模型。
比如，基於 SSH 登錄後的 Shell 命令數據集，是不能用於檢測 WebShell 的行為。
而基於網絡流量採集的數據，也不可能感知黑客是否在 SSH 後的 Shell 環境中執行了什麼命令。
基於此，如果有企業不提具體的場景，就說做好了 APT 感知模型，顯然就是在“吹噓”了。
所以，入侵檢測得先把各類攻擊向量羅列出來，對每一個細分場景分別採集數據（HIDS+NIDS+WAF+RASP+應用層日誌+系統日誌+PC……），再結合公司的實際數據特性，作出適應公司實際情況的對應檢測模型。
不同公司的技術棧、數據規模、暴露的攻擊面，都會對模型產生重大的影響。
比如很多安全工作者特別擅長 PHP 下的 WebShell 檢測，但是到了一個 Java 系的公司……
常見的入侵手法與應對
如果對黑客的常見入侵手法理解不足，就很難有的放矢，有時候甚至會陷入“政治正確”的陷阱裡。比如滲透測試團隊說，我們做了 A 動作，你們竟然沒有發現，所以你們不行。
而實際情況是，該場景可能不是一個完備的入侵鏈條，就算不發現該動作，對入侵檢測效果可能也沒有什麼影響。
每一個攻擊向量對公司造成的危害，發生的概率如何進行排序，解決它耗費的成本和帶來的收益如何，都需要有專業經驗來做支撐與決策。
現在簡單介紹一下，黑客入侵教程裡的經典流程（完整過程可以參考殺傷鏈模型）：
入侵一個目標之前，黑客對該目標可能還不夠了解，所以第一件事往往是“踩點”，也就是蒐集信息，加深瞭解。
比如，黑客需要知道，目標有哪些資產（域名、IP、服務），它們各自的狀態如何，是否存在已知的漏洞，管理它們的人有誰（以及如何合法的管理的），存在哪些已知的洩漏信息（比如社工庫裡的密碼等）……
一旦踩點完成，熟練的黑客就會針對各種資產的特性，醞釀和逐個驗證“攻擊向量”的可行性，下文列舉了常見的攻擊方式和防禦建議。
高危服務入侵
所有的公共服務都是“高危服務”，因為該協議或者實現該協議的開源組件，可能存在已知的攻擊方法（高級的攻擊者甚至擁有對應的 0day）。
只要你的價值足夠高，黑客有足夠的動力和資源去挖掘，那麼當你把高危服務開啟到互聯網，面向所有人都打開的那一刻，就相當於為黑客打開了“大門”。
比如 SSH、RDP 這些運維管理相關的服務，是設計給管理員用的，只要知道密碼/秘鑰，任何人都能登錄到服務器端，進而完成入侵。
而黑客可能通過猜解密碼（結合社工庫的信息洩露、網盤檢索或者暴力破解），獲得憑據。
事實上這類攻擊由於過於常見，黑客早就做成了全自動化的全互聯網掃描的蠕蟲類工具，雲上購買的一個主機如果設置了一個弱口令，往往在幾分鐘內就會感染蠕蟲病毒，就是因為這類自動化的攻擊者實在是太多了。
或許，你的密碼設置得非常強壯，但是這並不是你可以把該服務繼續暴露在互聯網的理由，我們應該把這些端口限制好，只允許自己的 IP（或者內部的堡壘主機）訪問，徹底斷掉黑客通過它入侵我們的可能。
與此類似的，MySQL、Redis、FTP、SMTP、MSSQL、Rsync 等等，凡是自己用來管理服務器或者數據庫、文件的服務，都不應該針對互聯網無限制的開放。
否則，蠕蟲化的攻擊工具會在短短几分鐘內攻破我們的服務，甚至直接加密我們的數據，甚至要求我們支付比特幣，進行敲詐勒索。
還有一些高危服務存在 RCE 漏洞（遠程命令執行），只要端口開放，黑客就能利用現成的 exp，直接 GetShell，完成入侵。
防禦建議： 針對每一個高危服務做入侵檢測的成本較高，因為高危服務的具體所指非常的多，不一定存在通用的特徵。
所以，通過加固方式，收斂攻擊入口性價比更高。禁止所有高危端口對互聯網開放可能，這樣能夠減少 90% 以上的入侵概率。
Web 入侵
隨著高危端口的加固，黑客知識庫裡的攻擊手法很多都會失效了。但是 Web 服務是現代互聯網公司的主要服務形式，不可能都關掉。
於是，基於 PHP、Java、ASP、ASP.NET、Node、C 寫的 CGI 等等動態的 Web 服務漏洞，就變成了黑客入侵的最主要入口。
比如，利用上傳功能直接上傳一個 WebShell，利用文件包含功能，直接引用執行一個遠程的 WebShell（或者代碼），然後利用代碼執行的功能，直接當作 Shell 的入口執行任意命令，解析一些圖片、視頻的服務，上傳一個惡意的樣本，觸發解析庫的漏洞……
Web 服務下的應用安全是一個專門的領域（道哥還專門寫了本《白帽子講 Web 安全》），具體的攻防場景和對抗已經發展得非常成熟了。
當然，由於它們都是由 Web 服務做為入口，所以入侵行為也會存在某種意義上的共性。相對而言，我們比較容易能夠找到黑客 GetShell 和正常業務行為的一些區別。
針對 Web 服務的入侵痕跡檢測，可以考慮採集 WAF 日誌、Access Log、Auditd 記錄的系統調用，或者 Shell 指令，以及網絡層面 Response 相關的數據，提煉出被攻擊成功的特徵，建議我們將主要的精力放在這些方面。
0day 入侵
通過洩漏的工具包來看，早些年 NSA 是擁有直接攻擊 Apache、Nginx 這些服務的 0day 武器的。
這意味著對手很可能完全不用在乎我們的代碼和服務寫成什麼樣，拿 0day 一打，神不知鬼不覺就 GetShell 了。
但是對於入侵檢測而言，這並不可怕：因為無論對手利用什麼漏洞當入口，它所使用的 Shellcode 和之後的行為本身依然有共性。
Apache 存在 0day 漏洞被攻擊，還是一個 PHP 頁面存在低級的代碼漏洞被利用，從入侵的行為上來看，說不定是完全一樣的，入侵檢測模型還可以通用。
所以，把精力聚焦在有黑客 GetShell 入口和之後的行為上，可能比關注漏洞入口更有價值。當然，具體的漏洞利用還是要實際跟進，然後驗證其行為是否符合預期。
辦公終端入侵
絕大多數 APT 報告裡，黑客是先對人（辦公終端）下手，比如發個郵件，哄騙我們打開後，控制我們的 PC，再進行長期的觀察/翻閱，拿到我們的合法憑據後，再到內網漫遊。
所以這些報告，多數集中在描述黑客用的木馬行為以及家族代碼相似度上。而反 APT 的產品、解決方案，多數也是在辦公終端的系統調用層面，用類似的方法，檢驗“免殺木馬”的行為。
因此，EDR 類的產品+郵件安全網關+辦公網出口的行為審計+APT 產品的沙箱等，聯合起來，可以採集到對應的數據，並作出相似的入侵檢測感知模型。
而最重要的一點，是黑客喜歡關注內部的重要基礎設施，包括但不限於 AD 域控、郵件服務器、密碼管理系統、權限管理系統等，一旦拿下，就相當於成為了內網的“上帝”，可以為所欲為。
所以對公司來說，重要基礎設施要有針對性的攻防加固討論，微軟針對 AD 的攻防甚至還發過專門的加固白皮書。
入侵檢測基本原則
不能把每一條告警都徹底跟進的模型，等同於無效模型。入侵發生後，再辯解之前其實有告警，只是太多了沒跟過來/沒查徹底，這是“馬後炮”，等同於不具備發現能力。
所以對於日均告警成千上萬的產品，安全運營人員往往表示很無奈。我們必須屏蔽一些重複發生的相似告警，以集中精力把每一個告警都閉環掉。這會產生白名單，也就是漏報，因此模型的漏報是不可避免的。
由於任何模型都會存在漏報，所以我們必須在多個緯度上做多個模型，形成關聯和縱深。
假設 WebShell 靜態文本分析被黑客變形繞過了，在 RASP（運行時環境）的惡意調用還可以進行監控，這樣可以選擇接受單個模型的漏報，但在整體上仍然具備發現能力。
既然每一個單一場景的模型都有誤報漏報，我們做什麼場景，不做什麼場景，就需要考慮“性價比”。
比如某些變形的 WebShell 可以寫成跟業務代碼非常相似，人的肉眼幾乎無法識別，再追求一定要在文本分析上進行對抗，就是性價比很差的決策。如果通過 RASP 的檢測方案，其性價比更高一些，也更具可行性一些。
我們不太容易知道黑客所有的攻擊手法，也不太可能針對每一種手法都建設策略（考慮到資源總是稀缺的）。
所以針對重點業務，需要可以通過加固的方式（還需要常態化監控加固的有效性），讓黑客能攻擊的路徑極度收斂，僅在關鍵環節進行對抗。起碼能針對核心業務具備兜底的保護能力。
基於上述幾個原則，我們可以知道一個事實，或許我們永遠不可能在單點上做到 100% 發現入侵，但是我們可以通過一些組合方式，讓攻擊者很難繞過所有的點。
當老闆或者藍軍挑戰，某個單點的檢測能力有缺失時，如果為了“政治正確”，在這個單點上進行無止境的投入，試圖把單點做到 100% 能發現的能力，很多時候可能只是在試圖製造一個“永動機”，純粹浪費人力、資源，而不產生實際的收益。
將節省下來的資源，高性價比的佈置更多的縱深防禦鏈條，效果顯然會更好。
入侵檢測產品的主流形態
入侵檢測終究是要基於數據去建模，比如針對 WebShell 的檢測，首先要識別 Web 目錄，再對 Web 目錄下的文件進行文本分析，這需要做一個採集器。
基於 Shell 命令的入侵檢測模型，需要獲取所有 Shell 命令，這可能要 Hook 系統調用或者劫持 Shell。
基於網絡 IP 信譽、流量 payload 進行檢測，或者基於郵件網關對內容的檢查，可能要植入網絡邊界中，對流量進行旁路採集。
也有一些集大成者，基於多個 Sensor，將各方日誌進行採集後，彙總在一個 SOC 或者 SIEM，再交由大數據平臺進行綜合分析。
因此，業界的入侵檢測相關的產品大致上就分成了以下的形態：
①主機 Agent 類：黑客攻擊了主機後，在主機上進行的動作，可能會產生日誌、進程、命令、網絡等痕跡，那麼在主機上部署一個採集器（也內含一部分檢測規則），就叫做基於主機的入侵檢測系統，簡稱 HIDS。
典型的產品： OSSEC、青藤雲、安騎士、安全狗，Google 最近也發佈了一個 Alpha 版本的類似產品 Cloud Security Command Center。當然，一些 APT 廠商，往往也有在主機上的 Sensor/Agent，比如 FireEye 等。
②網絡檢測類：由於多數攻擊向量是會通過網絡對目標投放一些 payload，或者控制目標的協議本身具備強特徵，因此在網絡層面具備識別的優勢。
典型的產品：Snort 到商業的各種 NIDS/NIPS，對應到 APT 級別，則還有類似於 FireEye 的 NX 之類的產品。
③日誌集中存儲分析類：這一類產品允許主機、網絡設備、應用都輸出各自的日誌，集中到一個統一的後臺。
在這個後臺，對各類日誌進行綜合的分析，判斷是否可以關聯的把一個入侵行為的多個路徑刻畫出來。
例如 A 主機的 Web 訪問日誌裡顯示遭到了掃描和攻擊嘗試，繼而主機層面多了一個陌生的進程和網絡連接，最後 A 主機對內網其他主機進行了橫向滲透嘗試。
典型的產品： LogRhythm、Splunk 等 SIEM 類產品。
④APT 沙箱：沙箱類產品更接近於一個雲端版的高級殺毒軟件，通過模擬執行觀測行為，以對抗未知樣本弱特徵的特點。
只不過它需要一個模擬運行的過程，性能開銷較大，早期被認為是“性價比不高”的解決方案，但由於惡意文件在行為上的隱藏要難於特徵上的對抗，因此現在也成為了 APT 產品的核心組件。
通過網絡流量、終端採集、服務器可疑樣本提取、郵件附件提煉等拿到的未知樣本，都可以提交到沙箱裡跑一下行為，判斷是否惡意。
典型產品：FireEye、Palo Alto、Symantec、微步。
⑤終端入侵檢測產品：移動端目前還沒有實際的產品，也不太有必要。PC 端首先必備的是殺毒軟件，如果能夠檢測到惡意程序，一定程度上能夠避免入侵。
但是如果碰到免殺的高級 0day 和木馬，殺毒軟件可能會被繞過。借鑑服務器上 HIDS 的思路，也誕生了 EDR 的概念，主機除了有本地邏輯之外，更重要的是會採集更多的數據到後端，在後端進行綜合分析和聯動。
也有人說下一代殺毒軟件裡都會帶上 EDR 的能力，只不過目前銷售還是分開在賣。
典型產品：殺毒軟件有 Bit9、SEP、賽門鐵克、卡巴斯基、McAfee ；EDR產品不枚舉了，騰訊的 iOA、阿里的阿里郎，一定程度上都是可以充當類似的角色。
入侵檢測效果評價指標
首先，主動發現的入侵案例/所有入侵 = 主動發現率。這個指標一定是最直觀的。
比較麻煩的是分母，很多真實發生的入侵，如果外部不反饋，我們又沒檢測到，它就不會出現在分母裡，所以有效發現率總是虛高的，誰能保證當前所有的入侵都發現了呢？
但是實際上，只要入侵次數足夠多，不管是 SRC 收到的情報，還是“暗網”上報出來的一個大新聞，把客觀上已經知悉的入侵列入分母，總還是能計算出一個主動發現率的。
另外，真實的入侵其實是一個低頻行為，大型的互聯網企業如果一年到頭成百上千的被入侵，肯定也不正常。
因此，如果很久沒出現真實入侵案例，這個指標長期不變化，也無法刻畫入侵檢測能力是否在提升。
所以，我們一般還會引入兩個指標來觀測：
藍軍對抗主動發現率
已知場景覆蓋率
藍軍主動高頻對抗和演習，可以彌補真實入侵事件低頻的不足，但是由於藍軍掌握的攻擊手法往往也是有限的，他們多次演習後，手法和場景可能會被羅列完畢。
假設某一個場景建設方尚未補齊能力，藍軍同樣的姿勢演習 100 遍，增加 100 個未發現的演習案例，對建設方而言並沒有更多的幫助。所以，把已知攻擊手法的建成覆蓋率拿出來，也是一個比較好的評價指標。
入侵檢測團隊把精力聚焦在已知攻擊手法的優先級評估和快速覆蓋上，對建設到什麼程度是滿足需要的，要有自己的專業判斷（參考入侵檢測原則裡的“性價比”原則）。
而宣佈建成了一個場景的入侵發現能力，是要有基本的驗收原則的：
該場景日均工單 < X單，峰值 < Y單；當前所有場景日平均
同一個事件只告警首次，多次出現自動聚合。
具備誤報自學習能力。
告警具備可讀性（有清晰的風險闡述、關鍵信息、處理指引、輔助信息或者索引，便於定性），不鼓勵 Key-Value 模式的告警，建議使用自然語言描述核心邏輯和響應流程。
有清晰的說明文檔，自測報告（就像交付了一個研發產品，產品文檔和自測過程是質量的保障）。
有藍軍針對該場景實戰驗收報告。
不建議調用微信、短信等接口發告警（告警和事件的區別是，事件可以閉環，告警只是提醒），統一的告警事件框架可以有效的管理事件確保閉環，還能提供長期的基礎運營數據，比如止損效率、誤報量/率。
策略人員的文檔應當說明當前模型對哪些情況具備感知能力，哪些前提下會無法告警（考驗一個人對該場景和自己模型的理解能力）。
通過前述判斷，可以對策略的成熟度形成自評分，0-100 自由大致估算。單個場景往往很難達到 100 分，但那並沒有關係，因為從 80 分提升到 100 分的邊際成本可能變的很高。
不建議追求極致，而是全盤審視，是否快速投入到下一個場景中去。
如果某個不到滿分的場景經常出現真實對抗，又沒有交叉的其他策略進行彌補，那自評結論可能需要重審並提高驗收的標準。至少解決工作中實際遇到的 Case 要優先考慮。
影響入侵檢測的關鍵要素
討論影響入侵檢測的要素時，我們可以簡單看看，曾經發生過哪些錯誤導致防守方不能主動發現入侵：
依賴的數據丟失，比如 HIDS 在當事機器上，沒部署安裝/Agent 掛了/數據上報過程丟失了/Bug 了，或者後臺傳輸鏈條中丟失數據。
策略腳本 Bug，沒啟動（事實上我們已經失去了這個策略感知能力了）。
還沒建設對應的策略（很多時候入侵發生了才發現這個場景我們還沒來得及建設對應的策略）。
策略的靈敏度/成熟度不夠（比如掃描的閾值沒達到，WebShell 用了變形的對抗手法）。
模型依賴的部分基礎數據錯誤，做出了錯誤的判斷。
成功告警了，但是負責應急同學錯誤的判斷/沒有跟進/輔助信息不足以定性，沒有行動起來。
所以實際上，要讓一個入侵事件被捕獲，我們需要入侵檢測系統長時間、高質量、高可用的運行。這是一件非常專業的工作，超出了絕大多數安全工程師能力和意願的範疇。
所以建議指派專門的運營人員對以下目標負責：
數據採集的完整性（全鏈路的對賬）。
每一個策略時刻工作正常（自動化撥測監控）。
基礎數據的準確性。
工單運營支撐平臺及追溯輔助工具的便捷性。
可能有些同學會想，影響入侵檢測的關鍵要素，難道不是模型的有效性麼？怎麼全是這些亂七八糟的東西？
實際上，大型互聯網企業的入侵檢測系統日均數據量可能到達數百 T，甚至更多。
涉及到數十個業務模塊，成百上千臺機器。從數字規模上來說，不亞於一些中小型企業的整個數據中心。
這樣複雜的一個系統，要長期維持在高可用標準，本身就需要有 SRE、QA 等輔助角色的專業化支持。
如果僅依靠個別安全工程師，很難讓其研究安全攻防的時候，又兼顧到基礎數據質量、服務的可用性和穩定性、發佈時候的變更規範性、各類運營指標和運維故障的及時響應。
最終的結果就是能力範圍內可以發現的入侵，總是有各種意外“恰好”發現不了。
所以，筆者認為，以多數安全團隊運營質量之差，其實根本輪不到拼策略（技術）。當然，一旦有資源投入去跟進這些輔助工作之後，入侵檢測就真的需要拼策略了。
此時，攻擊手法有那麼多，憑什麼先選擇這個場景建設？憑什麼認為建設到某程度就足夠滿足當下的需要了？憑什麼選擇發現某些樣本，而放棄另一些樣本的對抗？
這些看似主觀性的東西，非常考驗專業判斷力。而且在領導面前很容易背上“責任心不足”的帽子。
比如為困難找藉口而不是為目標找方法，這個手法黑客攻擊了好多次，憑什麼不解決，那個手法憑什麼說在視野範圍內，但是要明年再解決？
如何發現 APT？
所謂 APT，就是高級持續威脅。既然是高級的，就意味著木馬很大可能是免殺的（不能靠殺毒軟件或者普通的特徵發現），利用的漏洞也是高級的（加固到牙齒可能也擋不住敵人進來的步伐），攻擊手法同樣很高級（攻擊場景可能我們都沒有見過）。
所以，實際上 APT 的意思，就約等於不能被發現的入侵。然而，業界總還有 APT 檢測產品，解決方案的廠商在混飯吃，他們是怎麼做的呢？
木馬免殺的，用沙箱+人工分析，哪怕效率低一些，還是試圖做出定性，並快速的把 IOC（威脅情報）同步給其他客戶，發現 1 例，全球客戶都具備同樣的感知能力。
流量加密變形對抗的，用異常檢測的模型，把一些不認識的可疑的 IP 關係、payload 給識別出來。當然，識別出來之後，也要運營人員跟進得仔細，才能定性。
攻擊手法高級的， 還是會假定黑客就用魚叉、水坑之類的已知手法去執行，然後在郵箱附件、PC 終端等環節採集日誌，對用戶行為進行分析，UEBA 試圖尋找出用戶異於平常的動作。
那麼，我們呢？筆者也沒有什麼好的辦法，可以發現傳說中的“免殺”的木馬，但是我們可以針對已知的黑客攻擊框架（比如 Metasploit、Cobalt 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 並行，也需要持續地進行迭代。
未來必然是 AI 的天下，但是有多少智能，前面可能就要鋪墊多少人工。願與同行們一起在這個路上繼續探索下去，多多交流分享。
