一、引言
在日常企業安全能力建設中，收斂企業外網高危資產，以保障公司外部安全是企業安全的重要工作。WEB 高危服務（如：管理後臺、內部系統等）外開是企業所面臨的一個重要風險。針對該風險，傳統的方式是基於規則進行識別，該方式需要投入大量人力成本進行規則維護。由於規則難以覆蓋全面，經常出現誤報、漏報，效果不佳的問題。
透過“文心大模型”，僅投入少量資源，解決了高危 WEB 應用服務識別的問題，並且準確率達到了 70% 以上，下面將詳細為大家介紹。
二、傳統高危 WEB 服務識別技術
傳統高危 WEB 服務識別技術透過收集開源指紋庫和內部產品指紋維護構建成了一套企業指紋識別庫，其主要原理是透過獲取 WEB 應用的 Header、Body、Title、Banner 等資訊，對比指紋庫規則進行判別，該模式下需要源源不斷地擴充企業指紋庫來達到較好的檢出效果。傳統的高危 WEB 服務識別技術架構如下圖所示：
該架構主要包含三部分，分別為資料層、掃描層和業務層。其中資料層作為整個架構的基石，承載著公司網路資產和指紋資產，其資料豐富程度很大程度上決定了 WEB 服務識別能力的成熟度和覆蓋廣度。
掃描層通常對資料層資料進行處理，解析成固定格式的資料作為掃描輸入源。一般情況下，利用埠掃描模組對資產發起埠發現，服務識別，CPE 資訊獲取等操作。在獲取了一批有效的資產資料之後，對資產發起請求獲取服務資訊，並對比已有指紋庫進行判別。其主要實現邏輯如下圖所示：
- 透過 WEB 服務解析模組對所有 WEB 資產服務資訊進行提取
- 獲取到 WEB 服務資訊後透過與指紋 DB 對比獲取結果
- 返回傳遞最終結果
圖：指紋規則示例
業務層作為事件運營處置層，通常接受其他資料來源的輸入，安全運營人員判別事件後，將其推送給業務方進行修復，從而完成事件閉環。
三、高危 WEB 服務識別面臨困難點
在第二章裡瞭解了傳統高危 WEB 服務識別的技術原理以及方案，那麼從方案中可以發現會存在以下幾點問題：
- 檢測規則依賴人工編寫維護，在人力資源有限的情況下，如何保障外網高危服務資產的風險得以收斂？
- 我們可以識別和發現已知框架和服務並將其轉為檢測規則，那麼面對未知服務/框架我們如何能夠發現潛在風險？
那麼接下來，我將會圍繞以上兩點問題進行展開，討論如何透過大模型能力幫助公司解決傳統方案的痛點。
四、大模型高危 WEB 應用服務識別設計思路
在前面我們講到了，傳統檢測方案依賴與人工維護指紋規則來保障檢測能力的成熟度。那麼在當下文生文大模型飛速發展的情況下，是否可以透過訓練大模型等方式來識別高危 WEB 應用服務呢？答案是顯然的。
4.1. 大模型輸入
在開始正式訓練模型識別高危 WEB 應用服務前，我們需要考慮好模型的輸入資料格式。從安全工程師的視角來看，判斷一個 WEB 應用服務是否為高危應用主要從以下幾個方面：Title，Body、Header 等三類資訊，其中較為重要的是 Title，Body 兩塊。由於原始的 HTML Body 中會包含較多無用標籤和資料，因此我們需要在原始資料基礎上繼續清洗，以保證最終模型輸入的資料是相對較為乾淨的。如果原始資料中包含較多的髒資料，可能模型會產生噪點，最終影響到真實場景下的輸出不穩定。除此之外，由於輸入的 Token 限制，需要對較大的原始 HTML Body 進行縮減以滿足 Token 要求。
圖：輸入資料清洗示例
4.2. 大模型判別規則
為了訓練模型，告訴模型哪類服務是高危服務，需要在前期制定好模型判別規則約束好高危服務的範圍有哪些，可以透過提前界定好的規則判斷 WEB 應用是否為高危服務，下面是幾個判定案例：
- 系統涉及到管理功能的平臺視為高危服務。
- 已知的開源系統/框架不應該開放到外網訪問的視為高危服務，比如：Kibana、ElasticSearch、Grafana、Nacos 等。
- 無效頁面、錯誤頁面視為非高危服務，比如：狀態 404,500,502 等以及 nginx/centos 等 default page 頁面。
- 對外提供服務的常規頁面，產品介紹頁面視為非高危，比如：百度智慧雲產品、百度網盤等 ToB、ToC 場景。
4.3. Prompt 構造
在上面我們定義好了部分判別規則後，需要構造模型理解的 Prompt 指導大模型如何進行服務判別，Prompt 的好壞影響著大模型的效能。一個好的 Prompt 上下文能夠充分利用大模型的背景語料知識，並在 Prompt 提示下的特定工作內容中獲得更好的表現。經過後期的觀察表現，我們提煉出來了以下一部分 Prompt 作為模型指導，其內容如下所示：
"現在有一份從網站首頁提取的資料，請你根據這份資料判斷該網站是否屬於高危服務，並給出響應的判斷理由。\n\n"+....."## 要求：\n" +"1.充分考慮資料中每一個欄位，發現可能象徵著風險的關鍵字。\n" +....."## 判斷依據：\n" +"高危服務主要指代暴露後可能對公司資訊系統造成危害對服務。\n" +"1. 對於管理後臺登入、控制皮膚、資料庫皮膚等頁面，應當判定為高危服務。\n" +......"非高危服務指正常對外開放，提供各種功能的服務。\n" +"1. 對於常規的網站服務、普通使用者登入等頁面，判定為非高危服務。\n" +....."## 輸出格式\n" +"{\"reason\": \"<判斷為高危或非高危的具體理由>\", \"isDangerous\": <true或false>}\n\n\n\n\n"
4.4. 輸入資料來源
在準備好以上的工作之後，我們需要挑選一批資料作為初始資料投餵給基礎模型識別與訓練。前期資料來源需要保證資料的質量具有代表性，確保模型能夠直觀從資料來源中構建出我們想要的結果。因此我們在訓練前期，透過內部的資產庫，挑選了 100 多條具有代表性的資料作為初始輸入，這裡包含常見的 WEB 應用框架（Grafana、ElasticSearch）、內部高危系統、常規百度對外服務和通用管理後臺頁面等。
在前期人工完成資料標記之後，我們已經基本完成了一個初版的資料來源。為了提升模型的準確率，需要增加資料來源來滿足模型瞭解足夠的知識。因此後期採用了 self instruction 的方法，直接呼叫大模型打標，並進行人工複核。
self instructe 用的是所謂語境學習 (In-contextLearning) 的方法，透過在 Prompt 中提供數個樣例，依賴大模型預言基座，執行小樣本學習。具體方式就是將上述的 Prompt 進行改造，構造幾個預先設定好的對話上下文，讓大模型在已經進行了幾輪對話的前提下對新的內容進行生成。此處對話直接使用普適性較高且效能優越的旗艦模型：百度千帆 ERNIE 4.0 Turbo。
4.5. 模型微調
微調的資料量被建議在 1k 條左右。由於本模型使用的是百度千帆平臺進行訓練，按照格式匯出資料在千帆平臺上訓練即可。得到的模型釋出後，相較於原始模型能夠更加準確地回答，並且確保了輸出格式的準確，嚴格按照樣式。
微調完成後，對於後續模型資料的錄入，就無需再透過之前的 Prompt Learning 等方式，直接使用當前模型進行標註，人工篩選後重複訓練進行模型強化學習。
透過以上流程，我們基本上可以訓練出來一個較為精準的模型幫助我們識別外部高危 WEB 應用服務。接下來講解一下訓練後的模型在真實場景下的實踐。
五、大模型高危 WEB 應用服務識別實踐
目前該方案在公司場景中的架構如下圖所示：
該架構主要分為兩部分：WEB 資產資訊獲取和大模型判別。
目前應用在服務識別的下一模組進行呼叫，預設情況下進行外網資產埠發現和服務識別後，呼叫資產資訊採集 Agent 解析 WEB 資產中包含的報文、標題等關鍵資訊，經過資料清洗之後由 API 介面直接請求對接後端大模型能力進行判定；根據判定結果推送至事件運營中心運營。
那麼在模型前期，會基於人工運營的資料對大模型進行 Prompt 調整，用來確保獲得更加精準的 Prompt 幫助模型提升準確率。前期經過幾輪迭代之後，模型可以在無人監督的情況下得出較好的精度。以下為訓練後真實發現的高危 WEB 應用服務案例：
圖：高危服務識別案例1
圖：高危服務識別案例2
5.1. 後續迭代最佳化
在前期我們花費時間得到一個精度較高的模型後，在後期持續運營迭代過程中，只需投入少量人力複核識別結果，對偏差資料進行微調，可以不斷完善提升模型準確率。流程如下圖所示：
在後期人工標記過程中，可以定期對模型的訓練資料進行糾正標記；積攢一批次的資料對模型進行微調，可以在一定程度上避免由於標記資料不足而導致的模型微調結果不理想的情況。
六、後記
在實際的安全使用場景中，該方式透過較少的資料集訓練出較好的模型效果。目前能夠以較為精準的知識判別 WEB 服務是否為高危應用，目前準確率達到：70%。同時在實際應用過程中，內部也發現了很多業務方的管理後臺服務和測試環境等高危應用場景外開的情況，能夠有效地解決如上提到的兩點問題，在人力資源有限的情況下，只需要定期投入部分人力對模型進行標記調整，同時無需關注維護指紋規則庫就可以達到較為顯著的效果。 除此之外該方案面臨最大的一個問題在於大模型並不具備先見知識，對於部分場景下的 WEB 應用缺乏真實的理解，比如 ToB 交付業務服務應該需要開放在公網提供給客戶等場景下，大模型識別目前精準度還待提升。未來還需要持續投入人力完善模型訓練，解決該場景下的問題。
七、AI+安全產品推薦
將大模型與程式碼安全相結合實現安全左移，也是百度安全實踐的重要方向。我們基於百度文心快碼（Baidu Comate）建設了 IDE 安全能力，可在編碼過程中實現漏洞掃描和自動修復，幫助研發人員以最小成本解決安全問題。
如果對產品感興趣，詳情可點選參考程式碼安全智慧體文件（https://cloud.baidu.com/doc/COMATE/s/Jm3due9vf#4-%E5%AE%89%E5...）。