NIS2安全评估：范围界定、测试与可靠证据

春季，一家虚构的托管服务提供商的董事会批准了一笔"NIS2渗透测试"预算。这家公司约有四百名员工，在两个欧盟国家设有数据中心，客户中有银行和电信运营商。服务商动作很快：三周后交来一份约一百五十页的报告——扫描器导出结果按OWASP Top 10类别排列，还盖着一个醒目的"已验证"。报告随即被归档。

秋季，一家本身受NIS2约束的大客户发来一份供应链安全问卷。问题颇为棘手：哪些服务纳入了测试范围，为什么是这些？谁授权了主动测试，边界在哪里？哪些发现已经修复，靠什么证明？最关键的是，公司究竟如何评估自身安全措施是否真正有效？那一百五十页报告一个问题也回答不了。钱花了，却拿不出任何可以引用的证据。

这个例子是虚构的，但它准确地点出了真正的任务。NIS2安全评估不是一次性测试，也不是一张"合规"标签。它要产出可核验的证据：哪些控制措施确实在运行，它们在压力下何处失效，哪些问题已修复，修复又是如何确认的。合规、法务和管理层随后依靠这些证据开展工作。下文将讨论如何界定评估范围、各种方法分别能证明什么、如何为发现排序、审查供应商以及选择服务商，使评估结果经得起第一个尖锐问题的考验。

NIS2对组织的要求，以及它并未要求渗透测试做什么

欧盟第2022/2555号指令（即NIS2）并没有规定"每年做一次渗透测试"。其第21条要求基本实体（essential entities）和重要实体（important entities）采取适当且相称的技术、运营和组织措施来管理网络安全风险，并列出这些措施至少应涵盖的领域，其中包括：事件处置、供应链安全、系统获取、开发和维护中的安全（包括漏洞处理与披露）、密码学，以及用于评估风险管理措施本身有效性的政策和程序。

最后这一项，正是技术安全评估发挥作用的地方。渗透测试、配置审查或应用验证能回答"这项措施是否有效"，但都无法替代整个风险管理体系。把NIS2合规简化为一次渗透测试，就是把测量仪器和被测量的对象混为一谈。

适用性应在测试之前确定

NIS2是指令而非条例。成员国须在2024年10月17日前将其转化为国内法，原NIS指令自2024年10月18日起废止。因此，具体义务、主管机关、程序和处罚，必须查阅适用的国内法，并考虑相应实体类别的管辖规则，而不能只看指令文本。

并非每家欧盟企业都受NIS2管辖。欧盟委员会解释说，该指令扩大了行业覆盖范围，并采用规模上限规则：一般而言，所列行业中的中型和大型组织被纳入范围，指令本身还规定某些类别不受规模限制，成员国也可按规定的风险标准认定其他实体。实体分为基本实体和重要实体两类，适用不同的监管制度。所以第一个问题不是"测试什么"，而是"NIS2是否适用于我们、属于哪一类、依据哪国国内法"。回答这个问题的应该是依据官方文本工作的律师，而不是测试服务商。

关于修订还需说明一点。2026年1月，欧盟委员会提出了对NIS2的针对性修订。在立法程序完成之前，这只是提案而非现行法律，以此为基础制定评估计划为时过早。

定期审计、针对性审计与安全扫描并非一回事

第32条规定了主管机关对基本实体的权力：现场与非现场监管、由独立机构或主管机关自身开展的定期和针对性审计、临时审计、安全扫描、信息请求以及要求提供已开展审计的证据。一个重要细节是：针对性审计基于风险评估或其他与风险相关的信息。指令并未设立"所有实体每年一次独立审计"的统一规则。检查的频率和形式取决于国内法和主管机关的决定。

对委托评估的一方来说，实际结论随之而来：报告必须能作为证据出示——范围清晰、注明日期和方法版本、发现经过确认并附有复测结果。当主管机关要求提供审计证据时，一份脱离上下文的扫描器导出结果毫无用处。

三层证据：治理、技术与供应链

一项站得住脚的NIS2合规评估在三个层面收集证据，每一层回答各自的问题。

治理层要回答：网络风险是否被理解，是否有责任人，是否得到管理，当前状态能否与目标状态进行比较？缺少这一层，技术发现便无所依托：不清楚它们印证了哪种风险，也不清楚修复需要谁来拍板。

技术层检验已实施的控制措施能否经受授权团队按照成文方法开展的审查。渗透测试、配置审查和应用验证都属于这一层。

供应链层要弄清采购的产品和服务是否经过安全设计和安全交付，以及供应商能否证明这一点。对上例中的提供商而言，这一层是双向的：它既是客户的供应商，同时又是其他厂商服务的使用者。

任何一层的薄弱都会削弱基于其他层得出的结论：没有人负责修复，再完美的渗透测试也毫无价值；控制面板上仍保留着默认管理员密码，再完善的政策也形同虚设。

与风险管理挂钩：用NIST CSF 2.0描述当前与目标概况

NIST网络安全框架2.0（CSF 2.0）是美国框架，而非欧洲法律文件。但它以成果为导向的结构，为评估团队提供了一套中立的词汇，用以描述两个关键概念：组织目前在做什么，以及希望达到什么。区分当前状态与目标状态，是任何差距评估或NIS2就绪评估的基础。

CSF 2.0的几项资源可以直接使用。概况（Profiles）提供描述当前和目标状态的模板。参考资料映射（Informative References）展示NIST各文件在主题上的交叉之处，有助于把治理层面的成果与SP 800-115等技术指南联系起来。快速入门指南（Quick Start Guides）讲解常见任务，CSF 2.0 Tool则便于处理框架内容。它们结合使用，能以结构化、可重复的形式记录差距，而不是自由叙述。

但有一条界线不宜跨越。将CSF成果映射到NIS2第21条义务是一种解释，而不是任何一个框架给出的事实。这种映射应当书面记录，明确写出前提假设，并交由法务或合规部门审核。

再谈谈AI辅助差距分析。模型生成的任何映射都应当视为草稿，在提交给管理层或监管机构之前，必须由既懂框架又了解贵方基础设施的人审核。

范围：纳入哪些服务和资产

在第一个请求抵达系统之前，评估的成败往往已由范围决定。合理的起点不是IP地址清单，而是组织因之受NIS2管辖的服务清单，以及交付这些服务所依托的资产。对于托管服务商，这可能包括客户自助服务面板、虚拟机管理API、备份系统、远程管理通道，以及支持人员接入的后台系统。

接下来要为每组资产选择方法。这一决定需要慎重，因为每种方法产出的证据类型不同，也都有各自的盲区。

例如，没有配置角色、测试数据和授权规则的扫描器可能无法发现：客户只要在请求中换成另一位客户的标识符，就能看到邻居的备份。这类问题需要检查业务规则和访问权限——详见我们关于业务逻辑安全测试的文章。

范围的另一条边界绝不能模糊：主动测试只有在有权批准相关操作的各方明确书面授权的情况下才被允许。如果面板运行在他人的云平台上，备份由承包商保管，就需要单独弄清：哪些可以自行测试，哪些需要所有有权批准受影响资产和环境中相关工作的主体提供额外许可，哪些完全不能碰。任何评估框架都不赋予测试组织并不拥有或控制的系统的权利。

如果你正处于这一阶段——知道哪些服务是关键的，但不确定如何把它们拆分为可测试的资产组和方法——可以在渗透测试范围页面与Pentest.red讨论范围的技术部分。NIS2适用性和法律映射仍由贵方律师负责。

依据NIST SP 800-115开展技术测试

NIST SP 800-115是关于规划和实施技术性信息安全测试与检查、分析发现并制定缓解措施的指南。该文件强调，这些过程服务于不同目的：发现系统或网络中的漏洞，以及验证是否符合政策或其他要求。NIS2评估可以在约定范围内实现其中一项或两项目标：为安全团队识别弱点，并为合规部门提供可核验的证据。

检查与测试

SP 800-115中一个有用的区分是检查（examinations）与测试。检查分析文档、配置和日志，不干扰在线系统的运行。测试则主动作用于系统：发送请求、尝试绕过认证、利用漏洞。检查可以减少对运行系统的干扰；成本和风险取决于范围、访问条件与技术。测试则补充系统实际行为的观察证据。好的评估计划会为每组资产写明所选技术并说明理由，包括每种技术无法发现什么。

该指南本身是对各项技术优点与局限的概述，而非现成的测试方案；任何单一技术都不够。

三个阶段与实践延伸

从形式上看，SP 800-115将评估分为三个阶段。规划：范围、资产清单、授权、交战规则和成功标准。执行：检查和测试本身。执行后：分析发现、提出缓解建议并编写报告。为了构建NIS2证据库，还可以加上一个在正式框架中并非独立阶段的实践延伸：指定责任人和期限、复测并记录结果。

1. 服务与范围确定使组织受NIS2管辖的服务、其所依托的资产，以及附有理由说明的测试边界。
2. 授权与计划有权批准相关操作的各方的书面授权、交战规则、测试窗口、紧急联系人，并为每组资产选定检查与测试。
3. 执行文档与配置检查加上主动测试；每项操作都被记录下来，以便复现。
4. 执行后分析确认发现、剔除误报、映射到适用的CWE和带版本号的ASVS要求，并评估对服务的影响。
5. 修复与复测指定责任人和期限，然后用相同技术再次检查；档案记录的是复测结果，而不是修复承诺。

前四步对应SP 800-115的各阶段，最后一步是实践延伸——没有它，评估只是一份问题清单。

SP 800-115发布于2008年9月，因此其技术目录需要用有关应用和弱点的最新资料加以补充。但它从规划经执行到分析的结构与工具无关，至今仍能为评估提供站得住脚的框架。

测试环境与生产环境

另一个问题是在哪里测试。测试环境更安全，但在那里得到的结果并不会自动适用于生产环境：版本、配置、集成、服务账户权限乃至启用的防护措施都可能不同。如果测试在预发布环境进行，报告应明确说明，并描述其与生产系统的差异。生产环境测试——包括其专门的限制、时间窗口和回滚计划——须在工作开始前写入交战规则。

应用层：OWASP ASVS、WSTG与HTTP机制

基本实体和重要实体的服务往往通过Web应用和API触达客户，因此应用层值得深入检查，而不是匆匆一瞥。采购方在这里有三种不同的工具，务必不要混淆。

ASVS：共同的衡量标尺

OWASP应用安全验证标准（ASVS）为测试技术安全控制提供基础，并列出安全开发要求。其宣称的目标是借助一项可用于商业用途的开放标准，统一市场在"Web应用安全验证"名义下提供的覆盖范围和严格程度。对采购方而言，它可以说是整套资料中最有用的文件：借助它可以比较不同服务商实际检查了什么。

在ASVS 5.0.0中，每项要求都有数字编号。编号可能随版本变化，因此OWASP建议引用时加上版本前缀，例如v5.0.0-1.2.5。要求以CSV、JSON等机器可读格式发布。如果要求报告使用带版本号的编号，适用的应用控制发现就能追溯到具体要求。这保持了比较标准；复测环境和前提条件是否可比，仍须另行核实。如何围绕这样的标尺构建应用审计，可参阅我们关于应用安全审计的详细介绍。

WSTG与Top 10：测试程序与安全意识

OWASP Web安全测试指南（WSTG）是一套测试程序：具体如何测试认证、会话管理和输入处理。原始材料所依据的已发布版本为4.2。如果说ASVS回答"必须满足什么"，WSTG回答的就是"如何检查"。

OWASP Top 10（2025年版）是一份提升安全意识的文件，反映了对Web应用最关键风险的广泛共识。OWASP自己称其为迈向安全开发文化的第一步。因此，"应用已按OWASP Top 10测试"这句话应理解为意识层面的覆盖，而非验证深度。我们虚构例子中的那份报告正是如此。

检查成本低廉的HTTP机制

MDN文档介绍了几种协议层机制，验证成本很低。内容安全策略（CSP）允许定义页面可以加载哪些资源，有助于发现和缓解跨站脚本和数据注入等攻击。CORS规定浏览器何时允许脚本读取另一来源的响应，不能替代服务器端授权。跨源资源策略（CORP）限制响应在跨源no-cors请求中的使用，并有助于降低部分跨站读取风险，包括与推测执行有关的风险。若要快速初步检查配置，MDN推荐使用Mozilla的HTTP Observatory。

会话值得在计划中单列一行。HTTP协议本身不在请求之间保存状态，但这并不妨碍应用在其之上构建完整的会话——例如在服务器端存储会话并通过cookie与浏览器关联，或在请求头中传递令牌。因此需要检查的是具体实现：cookie属性、会话有效期与撤销、与用户的绑定、注销和修改密码时的行为。

发现排序：CWE Top 25与漏洞利用信号

一项评估如果给出数百条发现却没有合理的修复顺序，几乎帮不上任何人。MITRE发布的2025年CWE Top 25列出了以CVE记录形式公布的漏洞背后最危险的弱点。MITRE指出，这些弱点往往容易发现和利用，可能导致系统被完全接管、数据被窃取或应用运行中断。

两份配套清单让图景更加清晰。2025年CWE Top 10 KEV弱点清单对CISA已知被利用漏洞（KEV）目录中漏洞背后的弱点进行排名——也就是攻击者实际在用的那些。MITRE还公布了接近进入Top 25的弱点，并特别指出某些类别（例如命令注入）尤其受到攻击者关注。

实践方法如下。在适用时将技术弱点映射到CWE编号；其他发现记录合适的判断标准并说明不适用的原因，然后沿两个维度排序：利用信号，以及对范围内具体服务的影响。在可达性相近时，如果对服务的影响更大，虚拟机管理API中的漏洞可能比内部维基中的漏洞更紧急。但维基暴露的密钥和权限可能改变顺序；属于KEV弱点清单中的CWE类别，并不证明某项具体发现已被利用。根因分析还有第二个好处：它能显示在开发生命周期的哪个环节可以消除一整类缺陷——比如注入或内存安全错误——而不是逐个修补。关于如何建立这样的顺序，详见我们关于基于风险的漏洞优先级排序的文章。

CISA也印证了同样的类别：其"设计即安全"警示（Secure by Design Alerts）专门讨论消除跨站脚本、操作系统命令注入和目录遍历，CISA与FBI的联合警示则涉及缓冲区溢出的利用。这些类别应在适用于被测技术时纳入测试计划与报告分类。

供应商与产品："设计即安全"与"需求即安全"

NIS2明确将供应链安全列为风险管理领域之一，止步于自身边界的评估会漏掉这一层。CISA的材料在这方面提供了有用的支撑。

CISA的立场是：网络安全的负担不成比例地落在了消费者和小型组织身上，而非技术制造商身上。"设计即安全"（Secure by Design）原则要求制造商把客户安全视为核心业务要求：产品应默认安全，多因素认证、日志记录和单点登录等功能应免费提供。

签署"设计即安全"承诺（Secure by Design Pledge）的制造商承诺为实现七项关键目标作出真诚努力，CISA公布其进展报告。这为供应商审查提供了可以索取的具体材料。但签署的承诺只是承诺，而非独立验证。它决定应该提出哪些问题，而不能替代回答。

面向采购方，CISA发布了关于软件采购谈判的"需求即安全"（Secure by Demand）指南、面向运营技术所有者和运营者的单独"需求即安全"指南，以及与澳大利亚ASD's ACSC联合发布的关于选择安全且可验证技术的指南。这些材料很容易转化为问卷和合同要求。可以问供应商：多因素认证、日志记录和单点登录是包含在基础产品中还是单独收费？是否签署了承诺，最新进展报告显示了什么？是否有覆盖自有代码和开源依赖的内存安全路线图？哪些漏洞类别（如注入或目录遍历）已在架构层面消除，而不是逐个修复？如何测试并分阶段推送更新，以免破坏客户系统？

评估第三方供应商（包括SaaS）的方法，详见我们关于第三方风险安全评估的文章。

结果验收与复测

验收把评估结果与采购方的决策联系起来。正是在这里决定了组织最终得到的是证据，还是仅仅一份文件。最好事先约定服务商交付哪些成果物，以及按什么标准验收。

复测值得特别关注。无人验证的修复只是一种声明：修复可能堵住了一个入口却留下了相邻的另一个，也可能在下一次发布中回退。复测原始情况与约定变体，并记录环境、日期和结果，才能在已测范围内形成证据。这种检查如何进行、什么才算确认，详见我们关于渗透测试修复验证的文章。

档案中应记录所用每一份资料的版本以及评估日期。标准在变，系统也在变，一年后需要比较的是可比的东西。

最好事先商定的取舍

任何评估设计都要有所取舍。覆盖广度与对最关键服务的检查深度相互竞争：同样的预算，可以用扫描器扫遍整个边界，也可以人工深入剖析两个关键系统。清单有助于系统化覆盖，但若不分析相互作用，也可能漏掉弱点链；成本比较取决于深度和访问条件。一次性测试更容易采购，却会随系统变化而过时。证据库不能替组织化解这些两难，但能让它们显性化——这样选择就能向管理层说明理由。

每个框架各有职能，没有一个能提供完整覆盖：SP 800-115规定测试周期，ASVS设定可验证的应用要求，CSF 2.0提供治理语言，Top 10则代表意识层面。

如何为NIS2评估选择服务商

只有在确定范围和证据要求之后，比较提供NIS2合规或就绪评估的服务商才有意义。你购买的是证据质量，而不是标签。

请每位候选者说明其方法所依据的资料及版本：例如NIST SP 800-115的生命周期、依据ASVS 5.0.0的应用验证、依据2025年CWE Top 25的分类。索取一份匿名化的报告样本，检查适用的发现是否带有版本化的ASVS编号和CWE映射，其他发现是否有明确的判断标准，检查与测试是否分开，是否披露了技术局限和测试环境，修复建议中是否包含复测。还要询问服务商如何记录授权和交战规则，以及如何处理生产系统。

对于"一次测试就能让组织符合NIS2"的承诺要保持警惕。合规取决于适用的法律义务和主管机关的评估。渗透测试可以为此提供信息，但它不是认证、鉴证，也不是保证意见。对服务商关于资质、客户和能力的说法，应独立核实。

如果你想讨论这类评估的技术部分——测试范围内的服务、应用验证、复测——在贵方基础设施中会是什么样子，可以查看我们的渗透测试服务介绍，并在渗透测试范围页面描述任务。法律适用性、认证以及工业系统相关工作，应另行与具备相应资质的专业人士讨论。

结语：经得起追问的评估

回到开头的提供商。它需要的不是更厚的报告，而是客户四个问题的答案：测试了什么、为什么；谁授权的；修复了什么、靠什么证明；如何评估措施的有效性。每个答案都是可保存、可复核的独立成果物。

工作顺序自然而然地形成：依据国内法确认适用性，构建当前与目标概况，从服务推导范围，按SP 800-115各阶段选择检查与测试并取得书面授权，依据ASVS 5.0.0验证应用，按CWE和利用信号排序，复测，并向关键供应商提问。

技术资料做不到的，是判定法律适用性。那是指令官方文本、国内法和律师的问题。将这两个问题区分开来、要求发现可追溯并注明版本、按方法而非标签选择服务商的组织，从NIS2评估中得到的将不是档案柜里的一个文件夹，而是切实降低风险的基础。