摘要

  • RFC 2350 要求 CSIRT 说明服务对象、报告方式、组织授权、政策和所提供的服务；这些信息界定接口与合理预期，不记录某个具体案件的实际进展。
  • 报告送出、队列接收、事件确认、攻击归因、漏洞根除、系统恢复和多方协调是不同事实，必须由各自的案件证据支持。

一封邮件发往正确的安全响应地址，并不等于收件方已经开始处理。即使发送者使用了服务说明中公布的密钥，时间也处于标注的工作时段，能够确定的仍然只是：发送者按照公开接口提交了信息。邮件是否送达工作队列、是否被确认、是否被分级，仍需运输日志、工单或回执证明。

这正是 1998 年 6 月发布的 RFC 2350（BCP 21）最值得保留的边界。文件试图减少公众对计算机安全事件响应团队的误解，于是提出一套公开说明模板：团队名称和联系方式、时区和工作时间、任务、服务对象、发起组织、权限、事件支持政策、披露规则、通信安全、具体服务、报告表格与免责声明。

它把事前承诺写得更清楚，却没有把承诺变成事后证据。

全天候入口不等于实时响应

RFC 2350 要求团队说明工作时间、节假日安排，以及是否设有 24 小时热线。这让报告者可以判断即时处理是否属于合理期待，但并没有给任何具体提交赋予响应时间。

至少有四个时间点不能混为一谈：报告者发送、公布的系统接收、团队确认、完成初步研判。公开页面可以证明通道与预期开放条件；后面三步必须由案件记录支持。文件还明确指出，支持水平可能随工作负荷和所获信息的完整程度而变化。

因此，“全年无休”不能直接改写为“这次报告被实时受理”。真正有用的记录应包括退信或隔离、工单生成、首次确认、补充材料请求、优先级及交接时间。

报告先于事件成立

RFC 2350 把事件分流描述为对来报进行解释和排序、与现有事件或趋势关联，并协助判断事件是否确实发生以及范围多大。先有输入，再有核实。

后来的 FIRST CSIRT 服务框架 2.1把这一分叉写得更细。初始报告可能需要补充信息，也可能是配置错误、硬件故障或误报；若不属于本团队负责范围，还可能被安全地转交给其他组织。报告受理、事件分析、制品与取证分析各自拥有不同目标与产出。

工单号最多证明某项主张进入流程。它不能证明主张本身为真。要宣布事件成立，必须保留把“来报”提升为“已确认事件”的证据和判断。

服务对象范围不等于控制范围

RFC 2350 要求团队界定 constituency，也就是其服务的用户、站点、网络或组织；同时又单列 authority，要求说明团队的权力来源及边界。社区型团队可能主要提供建议。即使是组织内部团队，也未必有权干预服务范围内的每一套系统。

这个区分决定了“能接报”与“能处置”之间不能画等号。CSIRT 可以给系统负责人提供隔离建议，却没有权限执行隔离；可以联系供应商，却不能强制补丁；可以建议保存设备，却不一定有权取得设备；可以协调恢复，却未必是决定重新上线的一方。

案件记录应把每项动作、执行者、授权者和结果绑定起来。发送建议不是完成遏制；通知删除持久化入口不是证明入口已经消失。

服务清单里的动词并不等价

RFC 2350 将事件响应分为分流、协调与解决。分流负责评估和核实。协调负责依照披露政策分类信息，并按知悉必要通知相关方。解决服务通常属于附加或可选范围，可包括技术协助、根除被利用的漏洞及其影响，以及帮助恢复受影响系统和服务。

这不是一条自动通向“已解决”的流水线。团队可能只提供核心分流，并不负责本地恢复；可能已经发出通知，却没有收到对方确认；可能提出根除方案，却无法操作目标系统。RFC 2350 在“安全考虑”中更直接地说明：它不讨论具体安全事件中的响应与反应，只讨论 CSIRT 对所提供响应的适当说明。

FIRST 框架也分别列出报告受理、事件分析、取证分析、缓解与恢复、事件协调和危机管理支持。它还明确不评价任何团队的能力、容量、成熟度或质量。统一名词并不是绩效审计。

协调语言不能替代归因证据

RFC 2350 要求团队交代与其他 CSIRT、站点和机构如何合作、何时披露何种信息。它没有让一份服务说明获得认定攻击者的能力。

归因可能依赖技术制品、时间线、基础设施、身份线索、情报、替代假设，以及组织或法律层面的证据标准。RFC 3227把证据收集与归档作为独立问题，要求识别所涉系统和证据来源。FIRST 也把已确认事件的分析与取证分析分开。

“本团队接受报告并提供协调”描述的是接口。“本团队将本案归因于某一行为者”则需要带日期的结论、方法、范围、置信度与支撑证据。缺少这些材料时，归因仍未建立。

恢复必须经过验证

RFC 2350 对 recovery 的定义是帮助受影响系统和服务恢复到事件发生前的状态。“帮助”并不自动转移实际操作权和最终签字权。

2025 年 4 月定稿的 NIST SP 800-61 第 3 版列出更贴近运行的证明链：选择并执行恢复动作，检查恢复资产，确认关键服务与正常运行，监测已恢复系统，验证资产完整性，依据标准宣布恢复结束，并完成事件文档。

服务说明中的“提供恢复支持”不能证明这些动作已完成。出现登录页面也不能证明根因已消除、隐藏持久化已移除、数据完整性已恢复或依赖服务已经对齐。

来源与边界

  • RFC 2350：1998 年的核心文件，提供 CSIRT 说明模板并区分服务对象、权限、分流、协调与可选解决服务。
  • FIRST CSIRT 服务框架 2.1：后续服务分类，不评估具体团队的能力、容量、成熟度或质量。
  • NIST SP 800-61 Rev. 3：用于识别当前事件恢复所需的执行与验证证据。
  • RFC 3227：单独讨论证据收集与归档。

本文没有审计任何具体 CSIRT，也没有测量响应速度；它不声称清单中的服务没有发生，只说明清单本身不能证明服务已经在某一案件中发生。