一起看看卡耐基梅隆大学的《安全运营和事件管理的10个教训》：事件响应是整个政府和行业的一项关键需求，因为网络威胁行为者希望通过级联（通常是灾难性）影响来损害组织内的关键资产。例如，2021 年，一名黑客据称访问了佛罗里达州一家水处理厂的计算机系统，并对供水系统投毒。在美国关键的国家基础设施中，77% 的组织在过去三年中发现内部驱动的网络威胁有所增加。2023年IBM 数据泄露成本报告强调了经过充分测试的事件响应计划的关键作用。与那些已经实施并测试了此类计划的公司相比，没有制定经过测试的计划的公司在发生网络攻击时将面临 82% 高出的成本。
SEI CERT 部门的研究人员从其超过 35 年的开发和与全球事件响应和安全团队的合作中汲取了 10 个经验教训。这些经验教训与应对不断变化的网络威胁形势的事件响应团队相关。为了纪念CERT 部门（在我们与事件响应和安全团队论坛的合作中也称为CERT 协调中心）庆祝 35 周年的运营，在这篇博文中，他们回顾了从他们的事件响应和安全团队论坛中吸取的一些经验教训。网络安全事件响应团队 ( CSIRT ) 能力建设经验也适用于其他安全运营领域。
CERT部门1988自成立以来，几乎一直在帮助其他组织发展事件管理和安全运营能力。事实上，最初的CERT协调中心 (CERT/CC) 是在 1988 年对莫里斯蠕虫响应的事后审查中诞生的。在国防高级研究计划局(DARPA)进行的事后分析中，分析人员确定组织需要更好地与计算机事件分析和响应相关的协调和沟通。正如 SEI 出版物《计算机安全事件响应团队 (CSIRT) 实践状况》中所述：
认识到这个问题，DARPA 宣布打算资助建立一个互联网安全事件协调中心。DARPA 选择软件工程研究所作为新中心的所在地，并责成 SEI 建立在安全紧急情况下快速有效地协调专家之间沟通的能力，以防止未来发生此类事件。新中心还负责提高整个互联网社区对安全问题的认识。
这个新中心，CERT/CC，认识到一个组织无法提供这一职能；相反，每个组织都需要自己的团队来了解其使命、资产、威胁和运营。从一开始，CERT/CC 就致力于帮助其他团队站起来并协调联合信息共享的工作，例如事件响应和安全团队论坛 (FIRST)。SEI 于 1996 年在 CERT/CC 内成立了 CSIRT 开发团队（后来的 CSIRT 开发和培训团队以及安全运营团队），正式正式开展了这项工作。该团队为 CSIRT 经理和分析师开发了第一批培训课程，并为 CSIRT 开发了第一批出版物（包括CSIRT 手册）。许多 CSIRT 达到全面运行能力后，他们想知道自己的表现如何。CERT 开发了评估他们是否完成任务或实施正确组件的方法。
多年来，CERT 部门通过培训、指南发布和现场支持帮助组织建立能力。在那段时间里，我们学到了许多关于 CSIRT 开发和维护的经验教训，这些经验教训也适用于安全运营中心 (SOC)。以下各节讨论我们在过去三十多年中吸取的教训。
1.组织必须灵活
每个组织都是不同的，尽管我们的许多学员希望我们告诉他们建立 CSIRT 的“正确方法”，但我们强调许多变量会影响结构、服务和日常运营。因此，需要灵活性，并了解上级组织的使命和流程。组织还必须确定关键资产的位置、它们包含哪些数据、针对它们的风险和威胁、这些资产的泄露或损坏对组织的影响，以及可能存在的缓解措施的限制。同样，行业、法律和隐私合规要求的知识也是必须的。
2.没有一种组织结构适合所有CSIRT
一些 CSIRTS 在其上级组织或选区内执行多项活动，例如事件处理、漏洞分析、恶意软件分析和媒体分析（取证）。在其他情况下，这些任务由必须协同工作的单独组织单位执行。他们需要确定如何共享数据并确定谁扮演什么角色。我们在 SOC 组织结构中看到了同样的事情：不同的组织有不同的 SOC 使命和构成。有些仅专注于监控和检测活动，而另一些则另外执行事件响应和信息共享功能。
3. CSIRT 或事件响应团队不会单独或在真空中运作
团队必须整合到组织中，并确定组织中在事件管理中发挥作用的其他组成部分，例如 IT、防火墙团队、漏洞管理、补丁管理、风险管理、内部风险团队、违规响应团队、隐私、法律、人力资源，甚至培训和媒体关系组成部分。这些团队必须确定他们需要交互的所有组件；定义交互，包括输入、输出、机制、触发器、时间框架和 POC；并将其制度化为标准操作程序。
4.一些做法必须得到普遍考虑
其中一种做法是流程和程序的记录和制度化，以确保工作人员调任其他职位时的运营弹性。所有组织还必须拥有知识管理流程以及捕获和检索从处理事件中学到的信息或通过态势感知活动收集的信息的机制。其他普遍做法包括定义员工角色和职责；明确协调能力、知识、技能和能力 (KSA)；和职业道路进展。
5.识别关键资产是构建流程和服务的起点
CSIRT 必须了解他们正在保护什么以及什么是关键的。我们观察到，如果没有确定优先事项，那么团队成员就会将所有事情视为优先事项。这种心态会压垮团队的工作量并阻碍其成功完成任务。
6.功能和服务比名称和标签更重要
我们观察到，一些组织并未将其实体称为CSIRT，并且随着安全需求的增长，SOC 和网络运营中心 (NOC) 等结构不断发展，所有这些都在事件管理中发挥了作用。您的实体名称并不重要。如果您正在执行以下任何操作（监控、检测、分类、分析或响应），那么您就是我们工作的目标受众。随着时间的推移，我们开始将这些结构称为事件管理功能而不是 CSIRT。
第一个 CSIRT 开发框架特别兴趣小组 (SIG) 创建了一份文档，概述了CSIRT或SOC可以提供的潜在服务，即CSIRT服务框架。请注意，团队应该选择要提供的关键服务，而不是提供全部服务。我们还认识到，某些实体是需要CSIRT头衔的特定类型的团队，例如国家CSIRT或产品安全事件响应团队(PSIRT)。
国家 CSIRT 协调并促进特定国家或经济体的事件处理。他们通常有更广泛的范围和更多样化的支持者。PSIRT 负责对其上级组织生产和提供的产品中的漏洞进行分析。FIRST CSIRT 开发框架特别兴趣小组 (SIG) 有一份供审查的文档草案，其中定义了四种类型的事件管理功能。
7.成功的 CSIRT 需要的不仅仅是好的技术和工具
CSIRT 或事件管理功能以客户服务为导向，必须持续与利益相关者和合作者沟通并建立信任关系。CSIRT 需要具有批判性分析和解决问题能力的员工，他们能够跳出框框思考，并以冷静和深思熟虑的方式适应新的和意外的情况。除了技术技能之外，员工还需要有效的沟通技巧。技能发展应得到高水平培训计划的支持，并进行适当的治理，为跟上该领域的动态性质所需的持续学习和专业发展提供充足的机会。
8. CSIRTS 必须拥有一套明确定义的服务
CSIRT 提供的服务水平将影响执行该服务所需的相应基础设施和组织支持。例如，事件响应人员会前往现场帮助调查或解决事件，还是仅通过电话或电子邮件提供口头帮助？服务水平还将告知三方成员和利益相关者的参与类型以及提供服务所需的技能类型。那些从 CSIRT 或 SOC 接收服务的人需要知道可以提供哪些服务以及不能提供哪些服务。将这种清晰度编码化有助于设定期望并设定所需的通信接口和信息传播任务。
9. CSIRT 必须积极主动
一开始，我们观察到许多 CSIRT 专注于被动响应，但多年来他们变得更加主动。他们通过承担漏洞扫描、安全评估以及旨在发现恶意或异常活动和新威胁的积极研究等任务来体现这种增长。如今，主动方法已经发展到包括威胁搜寻、态势感知、安全意识培训以及与网络情报集成等活动。
10.事件管理能力可以为组织的其他部门提供态势感知
组织内的 CSIRT 或 SOC 应成为任何变更管理委员会、配置管理活动或技术审查委员会的一部分，以在计划和实施基础设施变更或流程变更时提醒组织注意可能的安全威胁。他们还可以向风险管理小组提供有关威胁和风险的信息。作为回报，他们可以使用收到的有关关键资产风险影响的信息来确定分析和响应任务的优先级。此信息还可用于让团队及时了解组织中可能产生安全影响的基础设施变化。
将 CSIRT 经验教训应用于安全运营我们在 CSIRT 能力建设方面的工作已扩展到支持总体安全运营。我们在过去三十多年中吸取的经验教训为扩大对更广泛的安全行动组织环境的支持和指导奠定了基础。事件管理是安全运营的关键要素，安全运营是运营风险管理的基础。所有这些组件必须协调一致并协同工作，以实现有效的网络防御。
我们在事件管理能力开发方面的工作与安全运营保持一致，因此我们不必从头开始开发我们的能力建设工作。安全运营工作可以使用从事件管理/CSIRT 开发中汲取的所有基本流程、方法和经验教训，并在需要时添加更有针对性的安全运营流程和方法。
我们通过 CSIRT 开发以及后来的事件管理能力开发吸取的经验教训适用于安全操作。我们的事件管理评估工具可以轻松评估各类事件管理和安全运营能力。我们使用相同的工具评估了政府、行业和学术机构的各种组织实体，包括事件响应团队、SOC 和网络安全运营中心 (NSOC)。
常见问题和趋势当我们使用事件管理能力评估来评估运营团队时，我们发现了常见的问题领域和趋势。令人惊讶的是，最重要的问题和差距本质上不是技术问题，而是正常的组织问题。最大的问题是从管理层到员工、从事件管理能力到组织其他部门、以及在事件管理活动中发挥作用的群体之间缺乏沟通。其他问题包括
- 缺乏政策和程序
- 缺乏员工培训
- 缺乏管理支持和治理
- 重复或冗余的功能
- 缺乏明确的使命以及相应的角色和责任
正如您所看到的，这些问题与我们的经验教训中涵盖的许多相同概念重叠。随着安全运营领域的不断扩大，该领域内的组织将很容易受到这些相同问题的影响，并且可以利用我们的经验教训来帮助规划其发展战略并避免许多此类问题。
