英国政府网络安全部门近期发布了一份重量级新指南，旨在助力全球企业强化其运营技术（OT）和工业控制系统（ICS）硬件的安全防护。这份由可信互联网络-物理系统研究所（RITICS）精心编纂的指南，汇总了一系列建议与最佳实践，旨在帮助企业有效抵御针对嵌入式技术的潜在攻击。
RITICS明确指出，OT/ICS网络与传统IT网络在运行机制上存在诸多本质差异。相较于IT网络主要关注数据机密性的保护，OT安全的核心则在于确保设备的可用性和完整性，而非数据访问权限的控制。网络事件响应计划（IRP）虽需兼顾IT与ICS/OT系统的需求，但必须充分考量ICS/OT环境的独特性与关键差异。针对这一挑战，RITICS小组向管理员提出了针对OT网络采取差异化策略与事件应对机制的建议。ICS/OT系统与网络对可用性和完整性有着极高的要求，因此事件响应程序需精心设计，以确保在取证收集过程中与系统的交互方式得当。这些考量因素应被详尽记录在专为ICS/OT定制的响应计划中，该计划还需灵活适应ICS/OT运营商资产中使用的不同系统，如不同站点、工业流程或系统功能等。RITICS警告称，攻击事件几乎难以避免，迟早会降临到大多数企业头上。因此，正确识别并隔离攻击，将是减轻损害的关键所在。“运营、工程和维护团队最为了解您的系统及其运作方式。”RITICS强调，“对这些团队进行可疑行为报告的培训，并营造鼓励报告可疑行为的文化氛围，是一项至关重要的长期组织任务。这不仅将提升事件检测的覆盖率，还有助于增强那些非全职担任网络安全角色人员的网络安全意识。”归根结底，RITICS指出，保护OT和ICS的关键并不在于企业拥有哪些安全保护措施，而在于如何正确实施这些措施，并有效分析从事件中收集的数据。“无论ICS/OT运营商在威胁检测技术部署、服务或内部能力建设方面做出何种选择，他们都应对自身环境当前的日志记录和监控覆盖范围有清晰的认识。”RITICS总结道，“这是识别潜在差距、改进日志记录和监控覆盖率的关键。更重要的是，它为事件响应团队（无论其构成如何）提供了清晰的图景，明了在何处以及如何收集日志，以促进深入分析”。工业控制系统与操作技术环境中的网络事件响应规划考虑因素指南本指南旨在帮助组织了解在工业控制系统（ICS）/操作技术（OT）系统中需要特别考虑的因素，并更好地准备ICS/OT环境中的网络事件响应。它旨在补充并应结合英国国家网络安全中心（NCSC）的一般事件响应与管理指南，重点关注ICS/OT环境特有的方面。拥有一个有效的事件响应计划也支持NCSC网络安全评估框架（CAF）中的多个成果。本文末尾列出了本指南中涵盖的相关良好实践指标（IGPs）的概要。如果您负责ICS/OT资产的管理或维护，本文将帮助您应对在采用成熟的事件响应规划流程时可能遇到的挑战。根据NCSC的指导，重要的是要假设您的ICS/OT系统将来会被攻破，这可能是由于：此外，尽管做出了最大努力，ICS/OT环境往往与信息技术（IT）环境缺乏隔离，或者在ICS/OT环境内部缺乏分段。值得注意的是，对于受《网络与信息系统安全规定》（NIS-R）管辖的关键服务运营商（OES），他们将通过NCSC的CAF进行监管，并必须能够在其ICS/OT环境中访问适当的日志记录和监控。对于那些受英国健康与安全执行局（HSE）OG86附录2第D节管辖的运营商，该节详细说明了事件响应规划的要求。虽然网络事件响应计划（IRPs）应涵盖IT和ICS/OT系统，但必须考虑ICS/OT环境中的关键差异因素。因此，在本文中，我们将详细介绍ICS/OT事件响应准备和规划中的具体关注点。从应对高调网络攻击的经验中汲取的教训清楚地表明，准备工作至关重要，例如乌克兰电网遭受的网络攻击分析中的E-ISAC/SANS防御用例。在考虑ICS/OT网络事件响应计划中的角色和责任时，需要考虑以下几点：
*对于ICS/OT，无论哪个团队进行分析和/或收集工作，角色和责任都应明确界定。这特别重要，因为与工厂运营、安全以及与生产、质量和安全相关的决策制定有关，需要识别和消除威胁并建立信心，使系统能够恢复到安全运行状态。*保留的应急响应公司应能够提供在危险环境中操作自如的资源支持。在某些情况下，这些资源可能需要获得在工业现场操作的认证，因此您应考虑使用哪些公司以及如何培训他们，包括任何必要的健康和安全入职培训、毒品和酒精检查等。
*工厂运营
有关角色和责任的更多信息，请参阅NCSC关于构建网络安全事件响应团队（CSIRT）的指导。制定一个描述ICS/OT整个事件响应生命周期中通信流程的ICS/OT特定事件响应决策树或操作手册将有助于明确所需的角色和责任，以及如何将关键利益相关者整合进来并调用或停用。行动点：开发一个ICS/OT特定的事件响应决策树/操作手册。建立跨职能的事件响应团队，成员来自IT安全部门和ICS/OT部门。预先指定负责协调沟通、决策和任务分配的团队负责人。这些个人和团队可以在实现的安全通信渠道和信息共享平台上共享相关威胁情报、妥协指标（IOCs）和取证调查结果。行动点：识别并培训关键人员，以担任IT和ICS/OT团队之间的协调点。ICS/OT系统和网络通常对可用性和完整性有严格要求，需要事件响应程序考虑如何与系统交互以进行取证收集。这些考虑应记录在ICS/OT特定响应计划中，该计划可能需要满足不同ICS/OT运营商环境（如不同站点、工业流程或系统功能）中的不同系统。行动点：创建一个针对您ICS/OT环境的特定IRP*范围：考虑ICS/OT网络事件响应计划是否强制执行，是否涵盖您的所有ICS/OT环境，还是基于站点或业务部门。如果是后者，请考虑团队之间的互动点和升级路径。*事件响应流程描述：涵盖事件的完整生命周期。使用已建立的框架，如SANS PICERL框架（如图1所示）或NIST.SP.800-61r2。*记录和报告事件的模板：如果您是关键服务运营商（OES），请制作报告要求的模板，以帮助IR团队确保他们及时捕获正确的信息。美国网络安全和基础设施安全局（CISA）发布了一份出色的文档，详细说明了ICS/OT网络事件响应计划中应包括哪些内容。信息专员办公室提供了关于OES报告要求的更多详细信息，尽管在英国，每个主管当局可能有具体的要求——例如，能源安全与净零排放部（DESNZ）为能源部门提供了基于阈值的指导（见附件D）。除了本文后面提到的练习ICS/OT IRP外，还需要为计划中确定的负责人员提供有关计划内容的培训和意识提高。行动点： 为参与ICS/OT IRP的工作人员提供培训和意识提高，以便他们更好地履行其职责。
从ICS/OT网络中检测网络安全事件一直是ICS/OT运营商面临的长期挑战，特别是对于那些设计时未考虑安全性的遗留系统。能够从ICS/OT中检测、关联和分析事件对于能够响应和从事件中恢复至关重要。
关于ICS/OT环境中支持事件检测的日志记录和监控的进一步指导和见解可在ICS COI网站上找到。运营商还利用安全运营中心（SOC）的概念，配备专门的SOC分析师，他们将全天候监控事件。NCSC提供了有关SOC及其功能和角色的额外指导。运营、工程和维护团队最了解您的系统及其行为。培训这些团队报告可疑行为，并建立一个鼓励报告可疑行为的文化是一项必要的长期组织活动，这将增加事件检测覆盖率，并帮助提高那些不全职从事网络安全工作的人员的网络安全意识。行动点： 在ICS/OT网络事件响应计划中记录您环境中的事件检测示例。包括通知有助于在整个组织中强化安全文化，并定期审查ICS/OT网络事件响应计划以检查事件检测能力的有效性。网络监控、主机日志记录或安全设备（如防火墙）中的安全事件可用于ICS/OT监控团队检测和响应事件。这可以采取对事件采取果断和具体行动的形式，或激活事件响应计划以召集团队并进行更详细的调查。对于ICS/OT运营商来说，雇用和留住执行监控功能的ICS/OT安全专家可能具有挑战性。可以考虑第三方监控安排来补充ICS/OT运营商的组织能力。支持选项包括将ICS/OT监控解决方案集成到企业SOC中（请参阅NCSC相关指导），或将监控外包给托管安全服务提供商。网络安全事件的来源也可以来自组织外部。ICS/OT运营商可以利用信息共享和分析中心（ISAC）等社区通知安排，监控NCSC CISP通知并订阅NCSC的早期预警系统。NCSC网站上还提供有关威胁信息的更多信息。英国政府还发布了一份文件，帮助政府部门了解他们应如何处理威胁信息，运营商也会发现该文件很有用。
检测 - 技术
如果基于IT，ICS/OT系统的检测能力可以依赖于部署端点检测和响应（EDR）解决方案，这些解决方案通常部署在整个企业网络中（尽管经常由于业务/风险决策而选择不启用响应解决方案）。在主动扫描或基于主机的代理被禁止、不切实际或危险的情况下，被动网络监控通常是一个很好的解决方案，以最大限度地减少对ICS/OT系统和资产的干扰。
无论ICS/OT运营商在威胁检测技术部署、服务或内部能力方面做出何种选择，他们都应该清楚地了解今天其环境中存在哪些日志记录和监控覆盖范围。这对于帮助了解潜在差距和改进日志记录和监控覆盖范围至关重要。更重要的是，它为事件响应团队（无论其组成如何）提供了清晰的画面，了解从哪里以及如何收集日志以促进分析。
行动点：开发一个收集管理框架，有时称为日志库存，这是确定环境中存在哪些日志记录和监控的文档结果。这可以包括记录网络监控当前部署的位置、配置了日志转发的主机等信息。该文档还可以列出可以从哪些资产进行取证收集。例如，可能部署的监控很少，但指出可以从哪里手动收集日志或图像对于事件响应团队来说仍然非常有用。
分诊
分诊 - 确定关键系统
ICS/OT运营商应拥有明确记录的库存，以确定关键系统和资产。这些可能是通过业务连续性规划活动、风险管理活动、桌面演练、关键资产分析或CCE活动确定的。无论它们是如何形成的，都应用于确定对ICS/OT运营而言最重要的事项，从而向事件响应团队通报在执行分诊和取证收集时应优先考虑的领域。
分诊 - 范围和规模
ICS/OT运营商应关注如何确定事件的范围，包括受影响的系统、站点或业务部门数量以及事件的严重程度。这对于帮助确定内部和外部所需资源、需要通知的团队以及需要启动的监管报告至关重要。对于收集取证证据或执行任何额外监控的团队来说，这也是至关重要的。在工业环境中收集取证证据并将其转移到可以进行分析的地方通常是一个具有挑战性的过程，需要花费大量时间和专门资源（NIST在美国开发的一个有用资源可以在这里找到）。能够以及时和战略性的方式进行收集将减轻事件响应团队的负担，并帮助他们在响应工作中保持敏捷。
行动点： 在ICS/OT网络事件响应计划中记录事件响应团队可以在哪里找到ICS/OT特定取证收集程序。
行动点： 提前计划考虑哪些收集工具可以使用，由谁使用以及如何使用，以及如何将收集到的证据安全地传输到可以进行分析的地方。
采取响应行动
采取响应行动 - 增加威胁
应制定计划以暂时增强网络和信息系统的安全性。您可能会选择在新风险或更高风险水平（例如，大规模爆发的极具破坏性的恶意软件）出现时实施这些计划，这些信息来自组织的安全意识和威胁情报来源。
采取响应行动 - 控制
能够实施控制方法可以为响应团队在事件期间提供一些快速的响应选项。工业环境中的控制方法应提前明确并达成一致，以便能够以授权的方式迅速实施。ICS/OT运营商应使用区域和渠道模型来帮助确定在哪里以及如何实施控制。在考虑和采取行动实施控制措施时必须谨慎，因为实施控制措施的责任几乎肯定在于系统的授权运营商，而不是事件响应团队。事件响应团队需要提供建议，而不应越权承担工厂运营责任。提前制定、测试和达成一致的控制方法将明显简化事件期间需要做出的决策。
应考虑断开受恶意软件感染的SCADA服务器/工作站和人机界面（HMI）与ICS/OT网络的连接。理想情况下，这些方法（可能围绕断开网络与IT/DMZ/供应商远程访问/站点孤岛模式的连接）也将清楚描述对工厂运营的影响，以便利益相关者能够做出基于风险的决策。例如，如果该位置的工厂断开连接，将失去对X系统的可见性，或Y服务将受到影响。这些行动将支持：
如果在更广泛的IT/企业业务网络中检测到威胁且尚未到达ICS/OT环境，则隔离ICS/OT环境。
防止恶意软件连接到其命令和控制网络。
阻止已建立的任何远程访问。
行动点： 在ICS/OT网络事件响应计划中记录如何在整个ICS/OT环境中实施控制。在ICS/OT网络事件响应计划中提供有关这些行动及其后果和潜在后果的信息。例如，切断与系统的链接可能会降低攻击者进一步横向移动的风险，但也可能导致操作人员对系统或对该网络段的安全监控的可见性丧失。拥有详细的网络映射文档，定义ICS/OT环境中所有进出连接的目的，包括哪些连接对于维持正常运营至关重要，哪些可以安全断开，将有助于更快地实施控制措施。另一项支持更快控制措施的活动是预先定义一个单独的防火墙策略，该策略将连接限制在必要的最小范围内，以便在强制/控制点快速安装。
采取响应行动 - 恢复
如果分析确定需要恢复措施，将需要一个记录良好的系统恢复安排。ICS/OT运营商通常会利用控制系统供应商或集成商来支持恢复和还原工作。与控制措施一样，事件响应团队应向运营团队提供建议和指导，运营团队将负责做出恢复决策和行动。
对于许多ICS/OT运营商来说，将依赖供应商来支持从备份恢复的过程。同时，也需要及时访问备份（对于可编程逻辑控制器（PLC）等，还需要编程软件将程序下载到PLC）。对于许多ICS/OT包，很可能使用标准硬件和操作系统。但是，对于其他供应商解决方案，将需要更专门的硬件。这将需要ICS/OT运营商在IT恢复/补救方面给予额外考虑。此外，同一ICS/OT站点通常会使用同一或类似系统的多个版本（这可能意味着制作相关资产的备份更具挑战性）。应考虑资产可能需要更换，因为它们已被损坏，或者更快的响应将是更换资产。
作为执行系统恢复安排的记录良好的一部分，对于ICS/OT运营商来说，了解将系统恢复到已知良好状态需要多长时间将非常有用，因为运营商可能会根据知道将需要2小时来擦除并将已知良好的备份恢复到其ICS/OT系统，而不是2周，而采取不同的步骤。
确保安全和完整性的系统恢复时间因素可能非常重要，此外，还需要考虑实现这一目标所需的资源（时间/专业知识/软件/硬件）。
同样重要的是，要确保ICS/OT运营商知道如果其系统受到影响，他们是否能够完全重建系统。特别是鉴于许多ICS/OT环境的遗留性质，了解是否有可行的同类备件，或者如果例如一个基于旧版Windows的HMI制造商被收购，原始软件副本不再存在，将采取什么措施，这一点非常重要。
行动点： 在ICS/OT网络事件响应计划中记录支持系统和工业过程恢复和还原所需的支持，包括供应商和/或系统集成商的联系方式。ICS/OT运营商可能已经制定了存储和测试备份映像以及从业务连续性规划和灾难恢复程序中获取备件的安排。如果这些已经存在，请考虑它们是否可以在响应网络事件时使用。例如，考虑如何测试映像以确保备份也未被攻陷，并考虑如何验证控制工作以确保替换系统不会被引入仍然被攻陷的网络中。
行动点： 将业务连续性计划（BCP）和灾难恢复计划（DRP）的输出引用到ICS/OT网络事件响应计划中，列出或提供文档参考，说明如何创建、存储和测试备份。
跟踪和报告
跟踪和报告 - 时间线
构建事件的时间线对于无论是IT还是ICS/OT环境中的网络安全事件，还是由于系统故障或配置更改错误导致的操作事故，都至关重要。ICS/OT运营商应制定安排，确保事件响应团队在整个事件过程中记录事件时间线。
需要记录的关键信息包括：
事件发生的时间，包括检查系统时间是否同步或进行了漂移调整。
从利益相关者处收到信息的时间。
采取行动的时间以及分配给谁。
行动点： 创建一个模板，事件响应提供者可以使用该模板记录和跟踪事件详细信息，并在ICS/OT网络事件响应计划中包含该模板（或其引用）。
跟踪和报告 - 沟通
ICS/OT通常执行构成企业核心收入的业务功能，并将执行防止危险情况（如失控、人员保护或防止不受控制的环境排放）的功能。因此，事件响应团队必须能够就攻击或恶意软件对运营和执行安全功能的系统造成的潜在影响向运营和安全人员提供建议。事件响应团队建议在事件响应调查期间牢记这一点，并在定期的事件响应更新电话会议中积极考虑并记录这一点。事件响应团队与其他利益相关者（包括运营、健康与安全代表、工程和维护团队）之间的定期和清晰沟通至关重要。
跨团队的沟通应涵盖并定期回顾：
使用模板可以帮助这些讨论，并参考记录在ICS/OT网络事件响应计划中的预定义和一致的事件严重性矩阵。NCSC的事件管理指导中提供了事件严重性矩阵的示例。ICS/OT特定的示例可能是：
在开发此矩阵时，可以考虑Mitre ATT&CK ICS特定框架中“影响”战术下的12种技术。需要了解与ICS/OT环境特定的事件报告和合规义务相关的监管要求。指定人员应根据适用的法规和标准通知监管机构，提供有关事件和补救工作的及时准确信息。指定人员应与法律团队密切合作，以处理与事件响应相关的法律和监管考虑因素，如保留可能用于法律诉讼的证据和遵守数据保护法。
行动点：决定并记录与您的ICS/OT运营一致的ICS/OT事件严重性矩阵。
经验教训
与任何事件响应或项目收尾一样，花时间讨论、记录和传播经验教训对于提高组织的能力至关重要。这对于ICS/OT事件响应也不例外，但在此提供以确保不会被遗忘。建议在任何经验教训活动中考虑以下领域：
哪些方面做得好，我们可以庆祝团队的能力和承诺？
我们如何确保能更好地保护和检测攻击向量？
做出决策时有哪些阻碍因素？
在监控和日志记录覆盖方面需要进行哪些改进？
发现了哪些新的关键资产？（并反馈到分诊过程中）。
经验教训 - 测试能力
虽然从真实事件中学习非常有用，但测试组织执行事件响应的能力的最佳方式莫过于进行测试。通常，“演练”一词会让人觉得演练必须涉及大量的规划和关键运营人员从日常工作中抽身出来的时间。然而，演练可以并且应该包括一系列的演练、桌面演练、概念演练，直至全公司或全行业的演练。NCSC提供了制定有效网络安全演练步骤的指导。测试能力的一些示例包括：
使用决策和中断或类似情况的游戏化。
概念演练排练
团队演练网络事件响应计划和/或程序
通用场景桌面演练
针对运营商使用的系统、操作和程序定制的桌面演练
行业范围的演练，如PowerPlay和GridEx
桌面演练对于测试运营商激活ICS/OT事件响应团队的能力以及与包括企业通信、运营和法律团队在内的其他团队合作的能力非常有用。对于ICS/OT，通常需要确保运营商具有足够的网络安全成熟度，然后才能进行合理规模的桌面演练（即半天到一天的活动，涉及多个团队）。在这些情况下，运营商会从执行更接近现实演练或概念排练的通用桌面演练中受益，例如，在场景引导下进行主导演练，以及执行一些基本的必要步骤。演练和演练流程虽然强度较低，但仍然在练习ICS/OT网络安全事件响应计划难以应对的方面提供了巨大帮助，比如取证收集，确定某个事件是否值得宣布为网络安全事件。
关键行动点总结
在本指南中，我们总结了针对ICS/OT环境的以下关键行动点：
开发ICS/OT特定的事件响应决策树/剧本。
识别和培训关键人员，以作为IT和ICS/OT团队之间的协调点。
创建针对您ICS/OT环境的ICS/OT网络安全事件响应计划。
为参与ICS/OT事件响应计划的工作人员提供培训和意识提升。
将您环境中的事件检测示例记录在ICS/OT网络安全事件响应计划中。这些通知有助于加强整个组织的安全文化，定期对ICS/OT网络安全事件响应计划进行审查可以检查事件检测能力的有效性。
开发日志管理框架，有时称为日志清单，这是确定环境中存在哪些日志和监控的文档结果。这可以包括记录当前部署网络监控的位置、哪些主机配置了日志转发等信息。该文档还可以用于列出可以从哪些资产执行取证收集。例如，即使部署的监控较少，指出可以在哪里手动收集日志或镜像对于事件响应团队来说仍然非常有用。
在ICS/OT网络安全事件响应计划中记录事件响应团队可以查找ICS/OT特定取证收集程序的位置。
提前规划考虑哪些收集工具可以使用，由谁使用，如何授权使用，以及如何将收集到的证据安全传输到分析位置。
在ICS/OT网络安全事件响应计划中记录如何在ICS/OT环境中实施隔离，包括相关行动及其后果。例如，切断与系统的连接可能会减少攻击者进一步横向移动的风险，但也可能导致操作人员对系统的可见性丧失或安全监控对该网络段的可见性丧失。拥有详细的网络映射文档，其中定义了ICS/OT环境中所有进出连接的用途，包括哪些连接对于维持正常操作至关重要，哪些可以安全断开，将有助于更快地进行隔离活动。另一个支持更快隔离活动的活动是预定义一个单独的防火墙策略，将连接限制在最低限度，以便在强制/隔离点快速安装。
在ICS/OT网络安全事件响应计划中记录恢复系统和工业流程所需的支持，包括供应商或系统集成商的联系信息。ICS/OT运营商可能已经制定了存储和测试备份映像以及从业务连续性规划和灾难恢复程序中获取备件的安排。如果这些已经存在，请考虑它们是否可用于响应网络安全事件。例如，考虑如何测试映像以确保备份没有被同时破坏，以及如何验证隔离措施以确保不会将受感染的系统引入仍然被攻陷的网络。
将业务连续性计划（BCP）和灾难恢复计划（DRP）的输出内容引用到ICS/OT网络安全事件响应计划中，列出或提供文档引用，说明备份的创建、存储和测试位置。
创建一个模板，事件响应提供者可以使用该模板记录和跟踪事件详细信息，并将其（或其引用）包含在ICS/OT网络安全事件响应计划中。
决定并记录与ICS/OT操作相对应的ICS/OT事件严重程度矩阵。
至少每年安排一次ICS/OT事件响应演练。这可以是IT和ICS/OT事件响应的综合演练（注意大多数针对ICS/OT环境的威胁首先来自IT/企业环境。此外，越来越多的ICS/OT由混合IT和ICS/OT SOC功能进行监控。因此，事件响应演练需要涵盖的范围应超出运营团队，应强调网络安全事件，因此其他安全专家也必须参与。演练活动的一个关键部分是审查结果，以检查事件响应计划的有效性。
资源
本文中提到了各种ICS/OT特定的事件响应和管理资源。此外，还有以下资源可供参考：
**国际自动化协会（ISA）**拥有大量资源，支持运行ICS/OT环境的组织，通过其“工业控制系统应急指挥系统（ICS4CS）”计划改进对影响行业的网络安全事件的管理。
CISA提供了基于网络安全的威胁向量场景，包括勒索软件、内部威胁、网络钓鱼和工业控制系统入侵。
**欧洲网络与信息安全局（ENISA）**拥有各种ICS/OT资源，如“工业控制系统领域CERT最佳实践指南”。
**美国国家标准与技术研究院（NIST）**提供了支持事件响应的资源，如《计算机安全事件处理指南》和《运营技术（OT）数字取证和事件响应（DFIR）框架》。
CAF IGP摘要
本文讨论的措施对以下CAF（v3.2）IGPs做出了贡献：
A3.a 资产管理：确定和理解运行基本功能所需交付、维护或支持的网络和信息系统，包括数据、人员和系统，以及任何支持基础设施（如电源或冷却）。
B4.b 安全配置：安全配置支持基本功能运行的网络和信息系统。
B4.d 漏洞管理：管理网络和信息系统中的已知漏洞，以防止对基本功能产生不利影响。
B5.a 弹性准备：为在不利影响后恢复基本功能的运行做好准备。
C1.c 生成警报：监控数据中潜在安全事件的证据被可靠识别并触发警报。
C1.e 监控工具和技能：监控人员的技能、工具和角色（包括外包的）应反映治理和报告要求、预期威胁以及他们需要使用的网络或系统数据的复杂性。监控人员需要了解他们需要保护的基本功能。
D1.a 响应计划：您拥有基于彻底风险评估的最新事件响应计划，该计划考虑了您的基本功能并涵盖了一系列事件场景。
D1.b 响应和恢复能力：您有能力执行事件响应计划，包括有效限制对基本功能运行的影响。在事件发生时，您拥有及时的信息来做出响应决策。
D1.c 测试和演练：您的组织通过利用影响您（和其他组织）的过往事件以及基于威胁情报和风险评估的场景来测试响应计划。
D2.a 事件根本原因分析：发生事件时，必须采取措施了解其原因，并采取适当的补救措施。
D2.b 利用事件推动改进：您的组织利用从事件中获得的经验教训来改进安全措施。
关注六方云公众号，后台回复“实践指南”获取原文英文版PDF
