基于安全大數據的威脅建模與自動化響應

一、隨著企業業務數字化程度的不斷加深，企業數字資產也在成指數增長，數字資產的安全防護已經變得越發重要，您認為現階段企業用戶在日志、數據的處理和安全檢測方面面臨哪些挑戰？

施澤寰：在實際工作中，企業一般會采購不同廠家的安全產品，構建自身的安全防御體系，這也導致了需要采集的數據類型繁雜，所以一般我們前期需要根據規劃（比如根據網絡區域，安全風險，威脅場景等因素），對不同類型的數據（像安全設備、網絡設備、系統日志、應用日志以及流量等數據）進行采集，并在完成相關數據采集之后，再對數據進行范式化。而在范式化的過程中，如果沒有內置的解析規則以及靈活的解析能力，就需要對相應的數據源逐個進行解析，這會耗費大量的實施時間，從而導致在上層應用場景的分析/交付上投入不足。

結合日志易實際經驗，我認為日志處理和安全檢測是一個包含全數據采集、數據清洗、數據存儲查詢、數據分析、威脅建模等一系列環節在內的威脅統一管理的全過程。其面臨的挑戰主要有三個：

一是（用戶環境中的）數據采集以及清洗等日志基礎處理能力的不足。這直接影響到安全威脅檢測模型的構建。在很多環境下，我們看到在進行了日志統一管理之后，實際效果并不突出，可能最終只是淪為了一個日志存儲平臺。安全數據資產得不到真正有效的挖掘和利用，深層價值凸顯不出來，因此對于安全數據資產的深度管理和有效利用是目前日志統一管理所面臨的一個挑戰。

第二個是告警噪聲太多。隨著企業安全管理與防御體系的不斷發展，即使是一些中小企業，每天各類安全設備/系統產生的告警數據都是數以萬計的，在如此量級的數據下，難以通過人工的方式，逐一進行響應處置。同時，也需要從噪聲（安全設備所產生的誤報）中去提取真正的攻擊行為，所以通過基于聚合、統計、關聯分析以及安全場景等模式構建威脅檢測模型，與外部數據（如情報數據，資產信息，漏洞信息等）進行匹配，提升告警精準度是解決這一挑戰的有效途徑。

第三個是安全人員缺乏。隨著企業安全管理與防御體系的不斷發展，絕大部分企業安全人員負責的工作內容也不斷增加，除了各種設備的維護，日常的日報、周報以及月報等，安全合規管理，項目管理等已經耗費大部分人力，更遑論進行常態化的安全運營（如威脅檢測、威脅分析以及威脅響應等）。所以這也是目前MDR市場逐步火熱的一個原因。當然，自動化響應也是企業解決上述一些重復性安全工作的一種解決方案。

我們目前已經在SIEM安全大數據分析平臺中，內置了解析規則庫，支持國內外主流的設備/系統的數據預處理，也支持多種解析方式（如正則解析，劃選解析，KV解析，XML解析，JSON解析，數據脫敏，自定義規則解析，字段補全等方式），可大大提高數據清洗的交付效率。同時，我們還基于不同類型、不同品牌的安全相關數據，定義了一套數據標準，統一對數據進行范式化。

日志易SIEM安全大數據分析平臺邏輯拓撲

二、針對上述問題，目前行業中有哪些SIEM類安全大數據分析平臺解決方案？這些產品都有哪些特點？

施澤寰：以日志易的安全分析平臺為例，它是基于自研的高性能搜索引擎（Beaver）的威脅檢測、響應與分析平臺。Beaver可以滿足企業用戶安全大數據搜索和安全威脅建模基礎需求，并提供了安全態勢，威脅處置，調查分析，資產管理，漏洞管理，規則管理，任務管理，情報管理等能力。基于歷史長周期數據以及實時數據，針對企業內外部威脅進行檢測、分析以及響應，并通過自動化能力，幫助用戶減少發現/響應威脅的時間，提高安全運營效率。

業界有個術語叫做“威脅狩獵”，指的是安全人員產生假設，進而圍繞著這個假設，對安全數據進行主動分析與驗證。一般由某個告警事件/異常事件，如用戶權限發生變更（可疑提權）為出發點，展開調查分析，又或者因某個指標異常，如DNS請求數激增、DNS子域名字段熵值激增，進而展開威脅狩獵。日志易的安全分析平臺基于自研搜索引擎Beaver，并通過SPL（Search Processing Language）靈活及迅速地完成某類威脅的狩獵。SPL語言是專為實現對日志這種非結構化數據進行搜索、分析而開發的處理語言，它實現了數百個SPL函數及指令，全面覆蓋日常安全分析工作的需要，并對接了多種機器學習算法，以實現安全場景的異常檢測。

無論是邊界突破、還是內網橫向移動等不同場景下的攻擊，都可以通過SPL中的不同函數對相關的安全數據進行分析處理，從而發現可能存在的異常；此外，日志易安全分析平臺，還具有圖分析功能。通過把企業用戶的安全數據以及相關的信息，如資產信息、漏洞信息，可視化為一個攻擊關系圖，從而去發現一些可能存在異常的實體。這些實體可能是一個IP、一個主機、一個用戶或者是某個域名等等，然后再對這些實體進行展開進一步的調查，去發現威脅告警、異常事件與其關聯性，實現對安全威脅與風險的探索與調查分析。所以日志易的特點在于基于自研的自研搜索引擎Beaver，通過SPL（Search Processing Language）與圖分析為用戶提供靈活的安全分析與威脅建模能力，實現不同維度安全數據（安全設備告警，流量、主機日志，應用日志，情報信息，資產信息以及漏洞信息等）的關聯，從而探索企業網絡中可能存在的異常事件，并進行攻擊鏈路回溯。

三、市場上現存的各類安全分析平臺產品主要基于了怎樣的分析和威脅檢測規則？

施澤寰：首先，我們把數據類型概括為兩個維度，一個是網絡維度，如來自防火墻、WAF等網絡、安全設備的數據；以及HTTP、DNS、TLS、SMB、DHCP等協議的流量數據；另外一個是端點維度，如主機系統日志（Linux/Windows/AIX等），HIDS/EDR的數據，基于特定的安全場景、不同的數據源可生成不同的規則。我們的安全分析平臺威脅檢測規則庫主要基于1000+的規則場景庫，而且規則庫也是基于外部態勢、項目實踐以及安全研究，不斷進行更新迭代。

而目前市場，主要有黑名單檢測與白名單檢測兩種思路。黑名單檢測思路一般以聚合、統計、關聯分析（特征匹配，情報關聯、時序關聯等）作為規則場景的主要落地模式。例如：當在某個安全設備（如WAF或IPS）發現了一個攻擊來源，未知攻擊者采用通過該IP地址發起多次不同類型的漏洞利用嘗試，雖然從告警結果上看都未成功，但是此時發現被攻擊的對象（資產），此后在某段時間后（這里的時間周期定義需要衡量）出現了一些異常行為（比如出現新的賬號或原有賬戶出現權限變更等行為），那么從攻擊角度上看，有可能出現WAF Bypass/IPS Bypass等（小概率事件）的情況，那么兩個事件之間會存在關聯性（指的是多次漏洞利用嘗試與賬戶異常行為之間），可以將其配置為關聯規則，當觸發告警時，值得我們更加關注。所以這種安全場景就屬于一個威脅檢測規則。

另一種白名單檢測思路，一般有異常檢測模式。一般來說，在企事業單位中，大部分的事件（比如系統層上發生的事件、網絡層上發生的事件）都是屬于正常事件。而異常事件，一般都是小概率事件。我們需要去發現這些小概率事件，如執行不常見的命令，出現不常見的父子進程，第一次出現的進程，第一次出現的賬戶，靜默賬戶（比如30天沒登錄行為）出現第一次活動等，所以也需要基于歷史的數據構建正常基線，之后再與實時數據進行對比，進而發現異常行為，這也是目前一類規則場景的落地方式。

四、請您結合自身實際經驗，談一談在安全運營中，自動化響應和人工響應應該如何配合？目前在企業中比例分配如何？

施澤寰：基于我們的研究與實踐，我們認為自動化響應實現的前提是要確保告警的準確度，威脅檢測模型要能夠輸出精準的分析，然后再將這些告警交給自動化響應平臺（或者說模塊）去處理。如果告警的誤報率很高，噪聲很大，這種情況下做自動化響應是沒有意義的，反而會影響到業務。所以，SIEM是實施SOAR的前提。

目前的安全事件自動化響應過程是怎樣的？舉個例子，當平臺檢測到了邊界區域一個WEB類的攻擊事件（比如某個簡單場景：某個源地址發起多次SQL注入或某個源地址發起多種不同類型的攻擊向量）后，能夠自動地針對這一攻擊事件中的源地址進行情報查詢判斷，并智能地根據情報查詢結果，判斷該攻擊IP是否已經被標記為惡意標簽；如果它被標記為惡意標簽，并且已經在平臺封禁列表中，系統則結束響應流程；如果不在平臺封禁列表中，則再進一步判斷，該IP地址是第一次出現還是此前出現了多次，并根據它出現的頻率智能化、自動化地聯動邊界安全設備實現不同時長的封禁，這是一個常見的的自動化響應過程。

而人工響應主要是指通過人工來針對一些不在自動化安全知識庫（或者說不存在對應的Playbook）中的安全事件或者說一些可疑線索進行響應處置。人工響應也包括了分析工作（類似于前面提到的威脅狩獵），因為這是一個基于不同安全場景下，分析各種問題并做出決策的過程，而從我們看來，自動化響應前期需要人工響應的驗證，判斷某類安全事件是否可以采用固化的自動化分析響應流程，同時也需要企業單位各個部門（比如由安全部門主導，業務相關部門，網絡相關部門參與）之間去進行評審，對流程無異議后，便可形成自動化響應流程。

所以自動化響應和人工響應之間的配合，以現實環境來看，很難達到對所有的安全事件都進行自動化響應。而自動化是由人工分析響應衍生出的產物，人工響應始終具有重要意義。具體的分配情況，在具備安全運營相關技術與流程制度的前提下，我們認為80%的安全事件應該交給自動化響應流量進行處理，人工專注于20%的安全事件的深層關聯分析與響應。

五、市場上的主流安全分析平臺產品都是如何實現流程編排和自動化響應（SOAR）的，其技術路線是什么？

施澤寰：國外SOAR市場相對國內市場較為成熟，目前我們看到主要有兩種技術路線，一種為以Case Management為目的，以Splunk Phantom為代表，一種是融合了Chat ops的理念，也衍生出如作戰室的功能，以Demisto（被Palo Alto收購，改名為Cortex XSOAR）為代表，但其最終要達到的目的都是相同的。即降低對安全事件的處置時間，提高響應效率。

其中Case Management的方式來看，以Event（事件）和Case（某個事件或者某些事件形成的）作為驅動，通過定義好的Playbook（劇本）來實現整個流程的自動化響應。這種技術路線實現層級和理念也非常明確，更接近一種決策思路，所以要實現SOAR的能力，也就是要具備可視化流程編排（通過拖拉拽的方式，快速定義劇本）、組件化（應用管理）能力和任務管理能力。

從架構而言，第一層級是劇本（Playbook），其中包含了流程的決策步驟（如過濾、判斷、格式化以及人工審核等基礎能力）和應用組件（如某類安全設備的某個接口，自定義的API接口）；第二個層級是應用，即集合了某個產品的所有接口，可在Playbook中提供選擇調用；第三個層級是動作（Action），即對應著具體的某個接口，比如情報查詢接口、IP查詢接口；第四個為資產，比如說企業中部署了10個防火墻，這就是10個資產，在編排Playbook的時候，需要定義和哪一個資產進行聯動；第五個層級為用戶，系統在對資產進行聯動的時候，需要安全設備上一個有相應響應權限的賬戶去進行聯動。

而在聯動的過程中一般會有兩類動作，一個是“讀”的動作，一個是“寫”的動作。“讀”的動作就是通過接口從安全設備或其他第三方系統中獲取信息；“寫”的動作就是通過接口，往安全設備或其他第三方系統添加/更新/刪除新的策略，比如說，把某個IP地址寫到防火墻的黑名單中以此來實現對惡意IP的阻斷，通過用戶來實現權限控制。

第二種路線其實與第一種殊途同歸，融合了Chat ops的理念。在某個安全事件發生之后，在對其進行響應處置過程中，需要增強各個部門之間或不同人員之間的協作，并能較為智能地推薦合適的處置動作。這種路線就是將這一邏輯和理念延伸到SOAR中來，其實就是結合攻防對抗歷史經驗，通過加強安全體系中各個產品和模塊之間的主動調用和深度配合，來實現更智能的自動化響應。

六、您認為未來安全響應處置的發展趨勢是什么？會有哪些新的發展特點？

施澤寰：未來安全響應處置從我們的研究與實踐情況來看，還是會朝著自動化與智能化的方向發展，應用場景（不僅僅只是一系列的分析判斷后，去封禁IP/鎖定賬戶）也會越來越豐富。而且隨著安全編排與自動化響應的發展會幫助安全人員從重復性的安全運營工作（比如威脅管理）中脫離出來，讓安全人員能把更多的精力投入到安全分析層面的工作中去，由此來發現一些潛在的或者威脅更大的安全風險，這種風險對企業造成的危害性往往會更大，所以我們也認為，對威脅狩獵場景的探索也會進一步深入。

同時，自動化響應也可以更加智能。舉例來說，平臺在觸發告警之后，可以基于過往同類型的案例進行綜合評估，為用戶推薦一個合適的處置策略和解決方案。所以，在我們看來，自動化和智能化是未來安全響應處置的兩個發展特點。