引言
在企业安全能力建设的日常工作里，有效收敛企业外网高危资产，对保障公司外部安全起着关键作用。其中，WEB 高危服务（例如管理后台、内部系统等）向外开放所带来的风险，是企业面临的重大挑战。传统针对此风险的识别方式主要基于规则，然而，这种方式不仅需要投入大量人力成本用于规则维护，而且由于规则难以覆盖全面，常常出现误报、漏报等情况，导致实际效果欠佳。
借助 “文心大模型” 这一创新工具，企业仅需投入少量资源，便成功解决了高危 WEB 应用服务识别的难题，且准确率达到 70% 以上。本文将详细阐述这一创新性解决方案的原理、实践过程及效果。
传统高危 WEB 服务识别技术剖析
传统的高危 WEB 服务识别技术，是通过整合开源指纹库以及内部产品指纹维护，构建起企业指纹识别库。其核心原理是获取 WEB 应用的 Header、Body、Title、Banner 等信息，并与指纹库中的规则进行比对判别。为实现较好的检出效果，该模式需要持续扩充企业指纹库。
此技术架构主要包含三个层面：
1. 数据层：作为整个架构的基础，数据层承载着公司网络资产与指纹资产。其数据丰富程度，在很大程度上决定了 WEB 服务识别能力的成熟度与覆盖范围。
2. 扫描层：扫描层负责处理数据层的数据，将其解析为固定格式，作为扫描输入源。一般通过端口扫描模块对资产执行端口发现、服务识别以及 CPE 信息获取等操作。在获取有效资产数据后，向资产发起请求以获取服务信息，并与已有的指纹库进行对比判别。具体实现逻辑如下：
1. 利用 WEB 服务解析模块提取所有 WEB 资产的服务信息。
2. 将获取的 WEB 服务信息与指纹数据库进行比对，得出结果。
3. 传递并返回最终结果。
3. 业务层：业务层作为事件运营处置层，通常接收来自其他数据源的输入。安全运营人员对事件进行判别后，将其推送至业务方进行修复，从而完成事件的闭环处理。
高危 WEB 服务识别面临的挑战
从传统高危 WEB 服务识别方案中，我们不难发现存在以下几方面问题：
1. 规则维护的人力困境：检测规则依赖人工编写与维护，在人力资源有限的情况下，如何确保外网高危服务资产的风险得到有效收敛，成为一大难题。】
2. 未知服务的检测盲区：传统方式能够识别和发现已知框架与服务，并转化为检测规则，但面对未知服务或框架时，如何察觉潜在风险，是现有方案难以突破的瓶颈。
接下来，我们将探讨如何借助大模型能力，解决传统方案中的这些痛点。
基于大模型的高危 WEB 应用服务识别设计思路
大模型输入数据处理
在运用大模型识别高危 WEB 应用服务前，需精心规划模型的输入数据格式。从安全工程师的专业视角出发，判断一个 WEB 应用服务是否高危，主要依据 Title、Body、Header 这三类信息，其中 Title 和 Body 尤为关键。由于原始 HTML Body 中往往包含大量无用标签与数据，为保证模型输入数据的纯净度，需对其进行清洗。若原始数据存在较多脏数据，可能导致模型产生噪点，进而影响在真实场景下输出的稳定性。此外，考虑到输入的 Token 限制，还需对较大的原始 HTML Body 进行缩减，以满足 Token 要求
大模型判别规则制定
为使模型准确识别高危服务，前期需制定明确的判别规则，界定高危服务的范围。以下为部分判定案例：
1. 涉及系统管理功能的平台，视为高危服务。
2. 已知不应开放到外网访问的开源系统 / 框架，如 Kibana、ElasticSearch、Grafana、Nacos 等，判定为高危服务。
3. 无效页面、错误页面，如状态码为 404、500、502 的页面以及 nginx/centos 等默认页面，视为非高危服务。
4. 对外提供服务的常规页面，如百度智能云产品、百度网盘等 ToB、ToC 场景下的产品介绍页面，判定为非高危服务。
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"
输入数据源选择与扩充
在完成上述准备工作后，需挑选具有代表性的数据作为初始输入，用于基础模型的识别与训练。训练前期，从内部资产库中精心挑选 100 多条数据，涵盖常见的 WEB 应用框架（如 Grafana、ElasticSearch）、内部高危系统、常规百度对外服务以及通用管理后台页面等。在人工完成数据标记后，初步构建了一个数据源。
为进一步提升模型准确率，采用 self - instruction 方法扩充数据源。此方法借助语境学习（In - context Learning）原理，在 Prompt 中提供数个样例，依托大模型语言基座执行小样本学习。具体操作是对上述 Prompt 进行改造，构造几个预设的对话上下文，使大模型在已有几轮对话的基础上，对新内容进行生成。在此过程中，选用普适性高且性能优越的百度千帆 ERNIE 4.0 Turbo 旗舰模型。
模型微调优化
模型微调的数据量建议在 1k 条左右。本模型基于百度千帆平台进行训练，只需按照平台格式导出数据并进行训练。微调后的模型发布后，不仅回答准确性大幅提升，且能确保输出格式严格符合要求。
完成微调后，后续模型数据录入无需再依赖 Prompt Learning 等方式，可直接使用当前模型进行标注。经人工筛选后，重复训练以实现模型的强化学习。通过这一系列流程，可训练出精准度较高的模型，用于识别外部高危 WEB 应用服务。下面将介绍该模型在真实场景中的实践应用。
大模型高危 WEB 应用服务识别实践
实践架构解析
目前，该方案在公司场景中的架构主要分为两大部分：WEB 资产信息获取和大模型判别。
在服务识别流程的后续模块中进行调用，默认情况下，先对外网资产进行端口发现和服务识别，随后调用资产信息采集 Agent，解析 WEB 资产中的报文、标题等关键信息。经过数据清洗后，通过 API 接口直接对接后端大模型能力进行判定，并将判定结果推送至事件运营中心进行处理。
在模型应用前期，基于人工运营数据对大模型的 Prompt 进行调整，以获取更精准的 Prompt，助力模型提升准确率。经过几轮迭代优化后，模型在无人监督的情况下也能达到较好的精度。以下为训练后实际发现的高危 WEB 应用服务案例展示：
后续迭代优化策略
在前期投入精力获得高精度模型后，后期持续运营迭代过程中，仅需投入少量人力对识别结果进行复核，针对偏差数据进行微调，即可不断提升模型准确率。具体流程如下：在后期人工标记过程中，定期对模型的训练数据进行纠正标记；积累一定数量的数据后，对模型进行微调，以此避免因标记数据不足导致的模型微调效果不佳问题。
后记
在实际安全应用场景中，基于大模型的方法通过较少的数据集，成功训练出效果良好的模型。目前，该模型能够较为精准地判别 WEB 服务是否为高危应用，准确率达到 70%。在实际应用中，成功发现众多业务方管理后台服务和测试环境等高危应用场景外开的情况，有效解决了前文提到的两大难题。在人力资源有限的情况下，只需定期投入部分人力对模型进行标记调整，无需再耗费大量精力维护指纹规则库，便可取得显著成效。
然而，该方案也面临一定挑战。由于大模型缺乏先见知识，在部分场景下，如 ToB 交付业务服务需开放在公网供客户使用的情况，大模型的识别精准度有待进一步提升。未来，仍需持续投入人力完善模型训练，以解决此类场景下的问题，推动企业外网高危 WEB 服务识别技术的不断进步。