信息安全事件管理指南

信息安全事件管理指南

1 范围

本指导性技术文件描述了信息安全事件的管理过程。提供了规划和制定信息安全事件管理策略和方案的指南。给出了管理信息安全事件和开展后续工作的相关过程和规程。

本指导性技术文件可用于指导信息安全管理者，信息系统、服务和网络管理者对信息安全事件的管理。 2规范性引用文件

下列文件中的条款通过本指导性技术文体的引用两成为本指导性技术文件的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内骞）或修订版均不适用于本指导性技术文件，然而，鼓励根据本指导性技术文件达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用子本指导性技术文件。 GB/T 19716—2005信息技术信息安全管理实用规则(ISO/IEC 17799：2000．MOD)

GB/Z 20986—2007信息安全技术信息安全事件分类分级指南

ISO/IEC 13335-I：2004信息技术安念技术信息和通信技术安全管理第1部分：信息和通信技术安全管理的概念和模型 3 术语和定义

GB/T 19716--2005、ISO/IEC 13335-I：2004中确立的以及下列术语和定义适用于本指导性技术文件。 3.1

业务连续性规划 business continuity planning

这样的一个过程，即当有任何意外或有害事件发生，且对基本业务功能和支持要素的连续性造成负面影响时，确保运行的恢复得到保障。该过程还应确保恢复工作按指定优先级、在规定的时间期限内完成，且随后将所有业务功能及支持要素恢复到正常状态。

这一过程的关键要素必须确保具有必要的计划和设施，且经过测试，它们包含信息、业务过程、信息系统和服务、语音和数据通信、人员和物理设施等。 3.2

信息安全事态 information security event

被识别的一种系统、服务或网络状态的发生，表明一次可能的信息安全策略违规或某些防护措施失效，或者一种可能与安全相关但以前不为人知的一种情况。

3.3

信息安全事件 information security incident

由单个或一系列意外或有害的信息安全事态所组成，极有可能危害业务运行和威胁信息安全。 3.4

信息安全事件响应组(lSIRT)lnformation Security Incident Response Team 由组织中具备适当技能且可信的成员组成的一个小组，负责处理与信息安全事件相关的全部工作。有时，小组可能会有外部专家加入，例如来自一个公认的计算机事件响应组或计算机应急响应(CERT.)的专家。 4缩略语

CERT计算机应急响应组(Computer Emergency Response Team)

ISIRT信息安全事件响应组(Information Security, Incident Response Team) 5背景 5.1 目标

作为任何组织整体信息安全战略的一个关键部分，采用一种结构严谨、计划周全的方法来进行信息安全事件的管理至关重要。

这一方法的目标旨在确保：

·信息安全事态可以被发现并得到有效处理，尤其是确定是否需要将事态归类为信息安全事件；

·对已确定的信息安全事件进行评估，并以最恰当和最有效的方式作出响应； ·作为事件响应的一部分，通过恰当的防护措施——可能的话，结合业务连续性计划的相关要素——将信息安全事件对组织及其业务运行的负面影响降至最小；

·及时总结信息安全事件及其管理的经验教训。这将增加预防将来信息安全事件发生的机会，改进信息安全防护措施的实施和使用，同时全面改进信息安全事件管理方案。 5.2 过程

为了实现5.1所述的目标，信息安全事件管理由4个不同的过程组成： ·规划和准备（Plan and Prepare） ·使用（Use）

·评审（Revew） ·改进（Improve）

(注：这些过程与ISO/IEC 27001:2005中的“规划（Plan）-实施（Do）-检查（Check）-处置（Act）”过程类似.) 图1显示了上述过程的主要活动.

1)应该指出的是，尽管信息安全事态可能是意外或故意违反信息安全防护措施的企图的结果，但在多数情况下，信息安全事态本身并不意味着破坏安全的企图真正获得了成功，因此也并不一定会对保密性、完整性或可用性产生影响，也就是说，并非所有信息安全事态都会被归类为信息安全事件。 5.2.1 规划和准备

有效的信息安全事件管理需要适当的规划和准备。为使信息安全事件的响应有效，下列措施是必要的：

a) 制定信息安全事件管理方案并使其成为文件，获得所有关键利益相关人，尤其是高级管理层对策略的可是化承诺；

b)制定信息安全事件管理方案并使其全部成为文件，用以支持信息安全事件管理策略。用于发现、报告、评估和响应信息安全事件的表单、规程和支持工具，以及事件严重性衡量尺度的细节2），均应包括在方案文件中（应指出，在有些组织中，方案即为信息安全事件响应计划）；

c)更新所有层面的信息安全和风险管理策略，即，全组织范围的，以及针对每个系统、服务和网络的信息安全和风险管理策略，均应根据信息安全事件管理方案进行更新； 规划和准备

d)确定一个适当的信息安全事件管理的组织结构，即信息安全事件响应组（ISIRT），给那些可调用的、能够对所有已知的信息安全事件类型作出充分响应的人员指派明确的角色和责任。在大多数组织中，ISIRT可以是一个虚拟小组，是由一名高级管理人员领导的、得到各类特定主题专业人员支持的小组，例如，在处理恶意代码攻击时，根据相关事件类型召集相关的专业人员。

e)通过简报和/或其他几只使所有的组织成员了解信息安全事件管理方案、方案能够带来哪些益处以及如何报告信息安全事态。应该对管理信息安全事件管理方案的负责人员、判断信息安全是太是否为事件的觉得吃，以及参与事件调查的人员进行适当的培训；

2)应该建立“定级”事件严重性的衡量尺度。例如，可基于对组织业务运行的交际或预期负面影响的程度，分为“严重”和“轻微”两个级别。

f) 全面测试信息安全事件管理方案。

第7章中对规划和准备阶段作了进一步描述。 5.2.2使用

下列过程是使用信息安全事件管理方案的必要过程： a) 发现和报告所发生的信息安全事态（人为或自动方式）；

b) 收集与信息安全事态相关的信息，通过评估这些信息确定哪些事态应归类为信息安全事件；

c) 对信息安全事件作出响应： 1)立刻、实时或接近实时；

2)如果信息安全事件在控制之下，按要求在相对缓和的时闻内采取行动（例如，全面开展灾难恢复工作）；

3)如果信息安全事件不在控制之下，发起“危机求助”行动（如召唤消防队／部门或者启动业务连续性计划）；

4) 将信息安全事件及任何相关的细节传达给内部和外部人员和／或组织（其中可能包括按要求上报以便进一步评估和／或决定）； 5)进行法律取证分析；

6)正确记录所有行动和决定以备进一步分析之用； 7) 结束对已经解决事件的处理。 第8章中对使用阶段作了进一步描述。 5.2.3评审

在信息安全事件已经解决或结束厥，进行以下评审活动是必要的： a) 按要求进行进一步法律取证分析； b) 总结信息安全事件中的经验教训；

c） 作为从一次或多次信息安全事件中吸取经验教训的结果，确定倍息安全防护措施实施方面的改进；

d) 作为从信息安全事件管理方案质量保证评审（例如根据对过程、规程、报告单和／或组织结构所作的评审）中吸取经验教训的结果，确定对整个信息安全事件管理方案的改进。

第9章中对评审阶段作了进一步描述。 5.2.4改进

应该强调的是，信息安全事件管理过程虽然可以反复实施，但随着时间的推移，有许多信息安全要素需要经常改进。这些需要改进的地方应该根据对信息安全事件数据、事件响应以及一段时间以来的发展趋势所作评审的基础上提出。其中包括： a) 修订组织现有的信息安念风险分析和管理评审结果； b) 改进信息安全事件管理方案及其相关文档；

c) 启动安全的改进，可能包括新的和／或经过更新的信息安全防护措施的实施。 第10章对改进阶段作了进一步描述。

6信息安全事件管理方案的益处及需要应对的关键问题 本章提供了以下信息；

·一个有效的信息安全褰件管理方案可带来的益处；

·使组织高级管理层以及那些提交和接收方案反馈意见的人员信服所必须应对的关键问题。

6.1 信息安全事件管理方案的益处

任何以结构严谨的方法进行信息安全事件管理的组织均能收效匪浅。一个结构严谨、计划周全的信息安全事件管理方案带来的益处，可分为以下几类：

a)提高安全保障水平；

b)降低对业务的负面影向，例如由信息安全事件所导致的破坏和经济损失； c)强化着重预肪信息安全事件； d)强化调查的优先顺序和证据； e)有利于预算和资源合理利用； f)改进风险分析和管理评审结果的更新； g)增强信息安全意识和提供培训计划材料； h)为信息安全策略及相关文件的评审提供信息。 下面逐一介绍这些主题。 6.1.1 提高安全保障水平

6.2.7可信运行

任何信息安全事件管理组应该能够有效地满足本组织在功能、财务、法律、策略等方面的需要，并能在管理信息安全事件的过程中，发挥组织的判断力。信息安全事件管理组的功能还应独立地进行审计，以确定所有的业务要求有效地得以满足。此外，实现独立性的另一个好办法是，将事件响应报告链与常规运行管理分离，且任命一位高级管理人员直接负责事件响应的管理工作。财务运作方面也应与其他财务分离，以免受到不当影响。 6.2.8系统化分类

一种反映信息安全事件管理方法总体结构的通用系统化分类，是提供一致结果的关键因素之一。这种系统化分类连同通用的度量机制和标准的数据库结构一起-将提供比较结果、改进警报信息，和生成信息系统威胁及脆弱性的更加准确的视图的能力。3）

3)定义通用系统化分类不是本标准的目的。读者可参考有美滚信息的其他相关资源。 7 规划和准备

信息安全事件管理的规划和准备阶段应着重于：

·将信息安全事态和事件的报告及处理策略，以及相关方案（包括相关规程）形成正式文件； ·安排合适的事件管理组织结构和人员； ·制定安全意识简报和培训计划。

这一阶段的工作完成后，组织应为恰当地管理信息安全事件作好了充分准备。 7.1概述

要将信息安全事件管理方案投入运行使用并取得良好的效率和效果，在必要的规划之后，需要完成大量准备工作。其中包括：

a)制定和发布信息安全事件管理策略并获得高级管理层的承诺（参见7.2）；

b)制定详细的信息安全事件管理方案（参见7.3）并形成正式文件。方案中包括以下主题： 1) 用于给事件“定级”的信息安全事件严重性衡量尺度。如4.2.1所述，可根据事件对组织业务运行的实际或预计负面影响的大小，将事件划分为“严重”和“轻微”两个级别； 2)信息安全事态4）和事件5）报告单6）（附录A列举了几种报告单）、相关文件化规程和措施．连同使用数据和系统、服务和／或网络备份以及业务连续性计划的标准规程； 3) 带有文件化的职责的ISIRT的运行规程，以及执行各种活动的被指定人员”的角色的分配，例如，包括：

——在事先得到相关IT和／或业务管理层同意的特定情况下，关闭受影响的系统、服务和／或网络；

——保持受影响系统、服务和／或网络的连接和运行； ——监视受影响系统、服务和／或网络的进出及内都数据流；

一—根据系统、服务和／或网络安全策略启动常规备份和业务连续性规划规程及措施； ——监控和维护电子诞据的安全保存，以备法律起诉或内部惩罚之用； ——将信息安全事件细节传达给内部和外部相关人员或组织。 c) 测试信息安全事件管理方案及其过程和规程的使用（参见7.3.5）；

d) 更新信息安全和风险分析及管理策略，以及具体系统，服务或网络的信息安全策略，包括对信息安全事件管理的引用，确保在信息安全事件管理方案输出的背景下定期评审这些策略（参见7.4）；

e)建立ISIRT，并为其成员设计、开发和提供合适的培训计划（参见7.5）；

f)通过技术和其他手段支持信息安全事件管理方案（以及ISIRT的工作）（参见7.6）； g)设计和开发信息安全事件管理安全意识计划（参见7.7）并将其分发给组织内所有员工（当有人员变更时重新执行一次）。

以下各节逐条描述了上述各项活动，其中包括所要求的每个文件的内容。 7.2信息安全事件管理策略 7.2.1 目的

信息安全事件管理策略面向对组织信息系统和相关位置具有合法访问权的每一位人员。

4)报告单由报告人填写（即不蹩由佰息安全事件管理组成员填写）．

5)信息安全事件管理人员使用报告帮编写有关信息安全搴态的初步报告，并保留事件评估等的运行记录，直至事件被完全解决．在每个阶段，都褥更新信息安全攀态／事件数据库。所填写的报告单／信息安全事态／事件数据库记录随后会用于事件的善后工作

6)如果可能，应将．这热报告单制成电子表单（如程安念的web网页上），并tot可与电子形式的信息安全事态／事件数据库链接．在当今世界上，基于纸质的方案耗时费力，不是效率最佳的运行方式；

7.2.2读者

信息安全事件管理策略应经组织高级执行官的批准，并得到组织所有高级管理层确认的文件化的承诺。应对所有的组织成员及组织的合同商可用，还应在信息安全意识简报和培训中有所提及(参见7.7)。 7.2.3 内容

信息安全事件管理策略的内容应涉及以下主题：

a)信息安全事件管理对于组织的重要性，以及高级管理层对信息安全事件管理及其相关方案作出的承诺；

b)对信息安全事态发现、报告和相关事件。概述中应包含对信息安全事态的可能类型，以及如何报告、报告什么、向哪个部门以及向谁报告信息安全事态等内容的归纳，还包括如何处理全新类型的信息安全事态；

c) 信息安全事件评估的概述，其中保罗具体负责的人员、必须采取的行动以及通知和上报等；

d)确认一个信息安全事态为信息安全事件后所应采取的行动的概要，其中应该包括：

1）立即响应； 2）法律取证分析

3）向所涉及人员和相关第三方传达

4）考虑信息安全事件是否在可控制状态下； 5）后续响应； 6）“危机求助”发起； 7）上报标准； 8）具体负责的人员；

e)确保所有活动都得到恰当记录以备日后分析，以及为确保电子证据的安全保存而进行持续监控，以供法律起诉或内部惩罚；

f)信息安全事件得到解决后的活动，包括时候总结经验教训和改进过程； g)方案文件（包括规程）保存位置的详细信息； h)ISIRT的概述，围绕以下主题:

ISIRT的组织结构和关键人员的身份，其中包括由谁负责以下工作： ——向高级管理层简单说明事件的情况： ——处理询问、发起后续工作等； ——对外联系（必要时）。

2）规定了ISIRT的具体工作以及ISIRT由谁授权的信息安全管理章程。章程至少

应该包括ISIRT的任务声明、工作范围定义以及有关ISIRT董事会级发起人及其授权的详细情况；

3）着重描述ISIRT核心活动的任务声明。要想成为一个真正的ISIRT，该小组应

该支持对信息安全事件的评估、响应和管理工作，并最终得出成功的结论。该小组的目标和目的尤为重要，需要有清晰明确的定义；

4）定义ISIRTDE 的工作范围。通常一个组织的ISIRT工作范围应包括组织所有

的信息系统、服务和网络。有的组织可能会于某种原因而将ISIRT工作范围规定得较小，如果是这种情况，应该在文件中清楚地阐述ISIRT工作范围之内和之外的对象；

5）作为发起者并授权ISIRT行动的高级执行官/董事会成员/高级管理人员的身份，

ISIRT被授权的级别。了解这些有助于组织所有人员理解ISIRT的背景和设置情况，且对于ISIRT的信任至关重要。应该注意的是，在这些详细信息公布之前，应该从法律角度对其进行审查。在有些情况下，泄露一个小组的授权信息会使该小组的可靠性声明失效。

i)信息安全事件管理安全意识和培训计划的概述； j必须阐明的法律法规问题的总结9参见5.2.3）。

7.3.1 目的

信息安全事件管理方案的目的是提供一份文件，对事件处理和事件沟通的uochenghe规程作详细说明。一旦发现到信息安全事态，信息安全事件管理方案就开始起作用。该方案被用作以下活动的指南：

· 对信息安全事态作出响应；

· 确定信息安全事态是否为信息安全事件； · 对信息安全事件进行管理，并得出结论；

· 总结经验教训，并确定方案和/或总体的安全需要改进的地方； · 执行已确定的改进工作。 7.3.2读者

应将信息安全事件管理方案告示给组织全体员工，因此，包括负责以下工作的员工： ·发现和报告信息安全事态，可以是组织内任何员工，无论是正式工还是合同工； ·评估和响应信息安全事态和信息安全事件，以及事件解决后必要的经验教训总结、改进信息安全和修订信息安全事件管理方案的工作。其中包括运行支持组（或类似的工作组）成员、ISIRT、管理层、公关部人员和法律代表。

还应该考虑任何第三方用户，以及报告信息安全事件及相关脆弱性的第三方组织、政府和商业信息安全事件和脆弱性信息提供组织。 7.3.3内容

信息安全事件公里方案稳健的内容应包括： a) 信息安全事件管理策略的概述； b) 整个信息安全事件管理方案的概述；

c) 与以下内容相关的详细过程和规程8）以及相关工具和衡量尺度的信息；

1） 规划和准备

——发现和报告发生的信息安全是太（通过人工或自动方式）； ——收集有关信息安全是太的信息；

——使用组织内认可的事态/事件严重性衡量尺度进行信息安全事态评估，确定是否可将它们重新划分为信息安全事件； 2）使用（当确认发生了信息安全事件时）

——将发生的信息安全事件或任何相关细节传达给其他内部和外部人员或组织；

——根据分析结果和已确认的严重性级别，启动立即响应，其中可能包括启动恢复规程和/或向相关人员传达；

——按要求和相关的信息安全事件的严重性级别，进行法律取证分析，必要时更改事件级别；

——确定信息安全事件是否处于可控制状态；

——作出任何必要的进一步响应，包括在后续事件可能需要作出的响应（例如，在实施一次碍难的完全恢复工作中）；

——如果信息安全事件不在控制下，发起“危机求助”行动（如呼叫消防队/部门或者启动业务连续性计划）；

——按要求上报，便于进一步评估和/或决策；

8）组织科自己决定是将所有规程放入到方案稳健中，还是通过附加问价详细阐明全部或部分规程。

——确保所有活动被恰当记录，一遍与日后分析； ——更新信息安全事态/事件数据库；

（信息安全事件管理方案文件应考虑对信息安全事件的立即响应和长期响应。所有的信息安全事件都需要提早评估其潜在负面影响，包括短期和长期影响（例如，在最初的信息安全事件发生一段时间后，可能会出现重大灾难）。此外，对究全不可预见的信息安全事件作出某些响应是必要的，且它们同时需要专门的防护措施。即使在这种情况下，方案文件应该对必要的步骤提供一般性指南。） 3)评审

——按要求进行进一步法律取证分析；

——总结信息安全事件的经验教训并形成文件；

——根据所得的经验教训，评审和确定信息安全的改进；

——评审相关过程和规程在响应、评估和恢复每个铸患安全事件时的效率，根据所总结的经验教训，确定信息安全事件管瑗方案在总体上需要改进的地方；

——更新信息安全事态／事件数据库。

4) 改进——根据经验教训，进行如下改进： ——信息安全风险分析和管理结果；

——信息安全事件管理方案（例如过程和规程、报告单和／或组织结构）； ——整体的安全，实施新的和／或经过改进的防护措施。

d)事态／事件严重性衡量尺度的细节（如严重或轻微，或重大、紧急、轻微、不要紧）以及相关指南；

e)在每个相关过程中决定是否需要上报和向谁报告的指南；及其相关规程。任何负责信息安全事态或事件评估工作的人员都应从信息安全事件管理方案文件提供的指南中知晓，在正常情况下，什么时候需要向上报错以及向谁报告。此外，还会有一些不可预见的情况可能也需要向上报告。例如，一个轻微的信息安全事件如果处理不当或在一年之内没有处理完毕，可能发展成重大事件或“危机”情况。指南旋定义信息安全事态和事件的类型、上报类型和由谁负责上报。

f)确保所有活动被记录程相成裘单中，以及日出分析指定人员完成所遵守的规程； g) 确保所维护的变更控制制度包括了信息安全事态和事件追踪、信息安全事件报告更新以及方案本身更新的规程和机制； h)法律取证分析的规程；

i)有关使用入侵检测系统(IDS)的规程和指南，确保相关法律法规问题都得到阐述（参见5.2.3）。这些指南中应包含对攻击者采取监视行动利弊问题的讨论。有关IDS的进一

步信息，可参见ISO/IECTR TR947《IT入侵检测框架》和ISO/IEC TR 180434选辑、配置和操作IDS指南》。 j) 方案的组织结构；

k) 整个ISIRT及个人成员的授权范围和责任；

I) 重要的合同信息。 7.3.4 规程

在信息安全事件管理方案开始运行之前，必须有形成迮式文件并经过检查的规程可供使用，这一点十分重要。每个规程文件应指明其使用和管理的负责人员，适当时来自运行支持组和／或ISIRT。这样的规程应包含确保电子证搬的收集和安全保存，以及将电子证据在不间断监控下妥善保管以备法律起诉或内部处罚之需等内容。而且，应有形成文件的规程不仅包括运行支持组和ISIRT的活动，同时还涉及法律取证分析和“危机求助”活动一一如果其他文件（如业务连续性计划）不包括这些内容的话。显然，形成文件的规程应该完全符合信息安全事件管理策略和其他信息安全事件管理方案文件。

需要重点理解的是，并非所有规程都必须对外公开。例如，并非组织内所有员工都需要了解了ISIRT的内部操作规程之后才能与之进行协作。ISIRT应该确保可“对外公开”的指南，其中包括从信息安全事件分析中得出的信息，以易于使用的方式存在，如将其置于组织的内部网上。此外，将信息安全事件管理方案的某些细节仅限于少数相关人员掌握可以防范“内贼”篡改调查过程。例如，如果一个盗用公款的银行职员对方案的细节很清楚，他或她就能更好地隐藏自身的行为，或妨碍信息安全事件的发现和调查及事件恢复工作的进行。 操作规程的内容取决于许多准则，尤其是那些与已知的潜在信息安全事态和事件的性质以及可能涉及到的信息系统资产类型及其环境相关的准则。因此，一个操作规程可能与某一特定事件类型或实际上与某一类型产品（如防火墙、数据库、操作系统、应用程序）乃至具体产品相关联。每个操作规程都应清楚注明需要采取哪些步骤以及由谁执行。它应该是外部人员（如政府部门和商业CERT或类似组织，以及供应商等）和内部人员的经验的反映。 应有操作规程来处理已知类型的信息安全事态和事件。但还应有针对未知类型信息安全事态或事件的操作规程。用于针对此种情况的操作规程需阐明以下要求： ·处理这类“例外”的报告过程；

·及时得到管理层批准以免响应延迟的相关指南； ·在没有正式批准过程的情况下预授权的决策代表。 7.3.5方案测试

应安排信息安全事件管理过程和规程的定期检查和测试，以实现可能会在管理信息安全事态和事件过程中出现的潜在缺陷和问题。在前一次响应评审产生的任何变更生效之前，应对其进行彻底检查和测试。 7.4信息安全和风险管理策略 7.4.1 目的

在总体信息安全和风险管理策略中，以及具体系统、服务和网络的信息安全策略中包括信息安全事件管理方面的内容可达到以下目的：

·描述信息安全事件管理——尤其是信息安全事件报告和处理方案——的重要性； ·表明高级管理层针对适当准备和响应信息安全事件的需要，对信息安全事件管理力”案作出的承诺；

·确保各项策略的一致性；

·确保对信息安全事件作出有计划的、系统的和冷静的响应，从而将事件的负面影响降至最低。 7.4.2 内容

应对总体的信息安全和风险管理策略，以及具体系统、服务或网络信息安全策略进行更新，以便它们清晰阐明总体的信息安全事件管理策略及相关方案。应有相关章节阐述高级管理层均承诺并概述以下内容： ·策略；

·方察的过程，和相关基础设施； ·检查、报告、评估和管理事件的要求。

并明确指定负责授权和／或执行某些关键行动的人员（如切断信息系统与网络的连接或甚至将其关闭）。

此外，策略应要求建立适当的评审机制，以确保从信息安全事件发现、监视和解决过程中得出的任何信息可被用于保证总体信息安全和风险管理以及具体系统、服务或网络的信息安全策略的持续有效的组织结构，并提供这方面工作所必要的协调、管理、发亏和沟通。ISIRT不仅可以降低信息安全事件带来的物理和经济损失，还能降低可能因信息安全事件而造成的组织声誉损害。 7.5.2成员和结构

ISIRT的规模、结构和组成应该与组织的规模和结构相适应。尽管ISIRT可以组成一个独立的小子或部门，但其成员还可以兼任其他植物，因此鼓励从组织内各个部门中挑选成

员组成ISIRT。如第4.2.1和7.1节所述，许多情况下，ISIRT是由一名高级管理人员所镊领的一个虚拟小组。该高级管理人员可以得到各特定主题的专业人员（如擅长处理恶意代码攻击的专业人员）支持，ISIRT根据所发生信息安全零件的类型召唤相关人员前来处理紧急情况。在规模较小的组织中，一名成员还可以承担多种ISIRT角色。ISIRT还可由来自组织不同不蒙（如业务运行部、IT/电信部门、审计部、人力资源部、市场营销部等）的人员组成。

ISIRT管理者应：

·指派授权代表以对如何处理事件作出立即决策；

· 通常有一条独立于正常业务运行的专线用于向高级管理曾报告情况；

· 确保ISIRT全体成员具有必须的知识和技能水平，并确保他们的知识和技能水平可以得到长期保持；

· 指派小组中最适合的成员负责每次事件的调查工作。 7.5.3与组织其他部门的关系

ISIRT管理者及成员必须具有某种登记授权，一遍采取必要措施响应信息安全事件。但是，对于那些可能给整个组织造成经济上或生于上的负面影响的措施，则应得到高级管理层的批准。为此，在信息安全事件管理策略和方案中必须详细说明授予ISIRT组长适当权限，使其报告严重的信息安全事件。

应对媒体的规程和责任也应得到高级管理层批准并形成文件，这些规程应规定： · 由组织中那个不蒙负责接待媒体；

· 该部门如何就一个问题与ISIRT相互交换信息。 7.5.4与外部方建立适当关系。外部放可能包括：

· 签订合同的外部支持人员，如来自CERT；

· 外部组织的ISIRT或计算机事件响应组，或CERT； · 执法机关；

· 其他应急机构（如消防队/部门等）； · 相关的政府部门； · 司法人员；

· 公共关系官员和/或媒体记者； · 业务或白；

· 顾客； ·普通公众。 7.6技术和其他支持

在已经取得、准备并测试了所有必要的技术和其他支持方式后，要对信息安全事件作出快速、有效的响应会变得更加容易。这包括：

·访问组织资产（最好使用最新的资产登记簿）的详细情况，并了解它们与业务功能之间关联方面的信息；

·查阅业务连续性战略及相关计划文件； ·文件记录和发布的沟通过程；

·使用电子信息安全事态／事件数据库和技术手段快速建立和更新数据库，分析其中的信息，以便于对事件作出响应（不过应该认识到，组织偶尔会有要求战使用手工记录的情况）； ·为信息安全事态／事件数据库做好充分的业务连续性安排。

用来快速建立和更新数据库、分析其信息以便于对信息安全事件作出响应的技术手段应该支持：

·快速获得信息安全事态和事件报告；

· 过适当方式（如电子邮件、传真、电话等）通知已事先选定的人员（以及相关外部人员），因而要求对可靠的联系信息数据库（它应该是易于访问的，同时还应该包括纸质文件和其他备份），以及适当时以安全方式将信息发送给相关人员的设施进行维护；

·对已评估的风险采取适当的预防措施，以确保电子通信(无论是通过互联网的还是不通过互联网的)，不会在系统、服务和网络遭受攻击时被窃听；

·对已评估的风险采取适当的预防措施，以确保电子通信（无论是通过互联网的还是不通过互联网的）在系统、服务和网路遭受攻击时仍然可用；

·确保收集到有关信息系统、服务和/或网络的所有数据以及经过处理的所有数据； ·如果根据已得到评估的风险采取措施，利用通过加密的完整性控制措施可帮助确定系统、服务和/或网络以及数据是否发生了变动以及他们的哪些部分发生了变动；

·便于对已收集的归档和安全保存（例如在日志和其他证据离线保存在CD或DVDROM等只读

介质中之前对其使用数字签名）；

·准备将数据（如日志）打印输出，其中包括显示事件过程、解决过程和证据保管链的数据；

被通知的个人/实体

（这一细节应由负责信息安全 信息安全管理者□ ISIRT管理者□ 并声明所需行动的人员填写。 站点管理者□ 信息系统管理者□ 如果需要，可以由机构的信息 （说明哪一站点）

安全管理者进行调整。） 报告发起人 □ 报告发起人的部门管理者□ 警察 □ 其他□

（例如，帮助台、人力资源部、管理层、内部审计、

执法机关外部CERT等）

具体说明：

涉及的个人

报告发起人 评审人 评审人

签字： 签字： 签字： 姓名： 姓名： 姓名： 角色： 角色： 角色： 日期： 日期： 日期：

评审人 评审人 评审人

签字： 签字： 签字： 姓名： 姓名： 姓名： 角色： 角色： 角色： 日期： 日期： 日期： 附录B

（资料性附录）

信息安全事件评估要点指南示例

B．1概述

本附录给出了信息安全事件负面后果评估和分类的要点指南示例，每项指南分使用1（低级）——10（高级）衡量尺度。（实际上也可能使用其他衡量尺度，比如从1到5，只要各组织采用最适合自身环境的衡量尺度。）

在阅读下列指南之前，应逐一以下要点说明：

·在下面的有些指南示例中，有些条目被标明“无输入”。这是因为指南统一式，从而本附录所示的所有六个类别的负面后果均可用1——10逐级上升的衡量尺度表达。然而某些类别中的某些等级（1~10）上，与相邻较低级别的后果条目相比没有足够的差异来形成一个条目，因此便将它们是为“无输入”。于此类似，在某些类别的高端由于与最高级别后果条目相比没有更严重的后果，因此便将其上的各高端后果条目是为“无输入”。（由此可见，认为取消“无输入”项就可以压缩等级数量在逻辑上是不正确的。）

·对于下面使用了财务数字的指南，所示的范围看起来有些奇怪。在应用这些指南之前。必须用适于组织的货币单位填写它们的财务数字范围。

因此，要使用下面的指南示例，且当从以下方面考虑信息安全事件对组织业务早晨的负面后果时：

· 为授权泄漏信息； · 为授权修改信息； · 抵赖信息；

· 信息和/或服务不可用； · 信息和/或服务遭受破坏；

首先要考虑一下哪些后果类别与实践相关。对于被认为相关的后果，应该使用类别指南来确定其组织业务运的实际负面影响，并作为“数值”项条目填写到信息安全事件报告单中。 B.2 对业务运行造成的财务损失/破坏

信息为授权泄漏和修改、抵赖以及不可用和遭受破坏的后果，可能是财务损失，如因行动迟缓或没有而造成股票下跌、合同欺诈或违反等。同样地，尤其是信息不可用或遭受破坏的后果会中断组织的业务运行。平息和/或从这样的时间中恢复过来需要耗费大量事件和精力。这在有些案例中表现得非常突出，应予以考虑。为了取得一个共同衡量尺度，恢复的时间应以人员的时间单位计算并转换成财务成本。这一成本应该参照组织内适当等级/级别的正常人月成本计算。应该使用一下指南。

a) 导致财务损失/成本为x1或更小； b) 导致财务损失/成本在x1+1和x2之间； c) 导致财务损失/成本在x2+1和x3之间； d) 导致财务损失/成本在x3+1和x4之间； e) 导致财务损失/成本在x4+1和x5之间； f) 导致财务损失/成本在x5+1和x6之间；

g) 导致财务损失/成本在x6+1和x7之间； h) 导致财务损失/成本在x7+1和x8之间； i) 导致财务损失/成本大于x8 组织停业

B.3 商业和经济利益

商业和经济信息必须得到保护，并估算它们对于竞争者的价值以及它们的安全受到危及时可能会给组织的商业利益带来的影响。应该使用以下指南。 a) 对竞争者有种益，但没有商业价值；

b) 对竞争者有利益，其价值为y1或更小(营业额)；

c) 对竞争者有价值，其价值在y1+l和y2（营业额）之间，或者导致财务损失或收入潜力损失，或者给个人或组织带来不当收入或优势，或者破坏对第三方信息的保密承诺； d) 对竞争者有价值，其价值在y2+l和y3之间（营业额）； e) 对竞争者有价值，其价值在弘y3+1和y4之间（营业额）； f) 对竞争者有价值，其价值大于y4十l（营业额）； g) 无输入13）； h) 无输入；

i) 可能极大破坏组织的商业利益，或者极大破坏组织的财务生存能力； j) 无输入。 B．4个人信息

根据我国个人信息保护相关法律法规的规定，组织应对持有和处理的个人信息施以保护，以防它们被未授权泄露，以免造成尴尬，甚至遭到法律诉讼。组织应按相关法律要求，保持个人信息的正确性，因为未授权修改导致错误信息会造成与来授权泄露信息类似的后果。同样重要的是，不得使个人信息不可用或遭受破坏，因为这会导致作出不正确决定或无法在所要求的时问内采取行动，最终造成与未授权泄露或修改信息类似的后果。应该使用以下指南。

a) 给个人带来轻微痛苦（担忧）——气愤、沮丧、失望，僬没有违背法律法规的要求； b) 给个人带来痛苦（担忧）～一气愤、沮丧、失望，但没有违背法律法规的要求； c) 违背法律法规、道德规范或众所周知的有荚保护储息的耍球，给个人带来轻微尴尬；

d) 违背法律法规、道德规范或众所周知的有关保护信息的要求，给个人带来严重尴尬或给群体带来轻微尴尬；

e) 违背法律法规、道德规范或众所周知的有关保护信息的要求，给个人带来严重尴尬； f) 违背法律法规、道德规范或众所周知的有关保护信息的要求，绘群体带来严重尴尬； g) 无输入； h) 无输入； i) 无输入； j) 无输入。 B．5法律法规义务

组织持有和处理的数据应遵从国家相关法律法规规定的义务。不履行这贱义务，I无论有意还是无意，都有可能导致对相关组织或个人采取法律诉讼或行政处罚的行动。这蹙行动有可能导致罚款和／或判刑入狱。应该使用以下指南。 a) 无输入； b) 无输入；

13)“无输入”是指在这一影响等级没有相应条目可供输入。

c) 执法通知、民事诉讼或刑事犯罪，导致z1或更低的财务损失／罚款； d) 执法通知、民事诉讼或刑事犯罪，导致z1+1和z2之间的财务损失／罚款； e) 执法通知、民事诉讼或刑事犯罪，导致z2 +1和z3之间的财务损失／罚款或最高2年监禁；

f) 执法通知、民事诉讼或刑事犯罪，导致z3+1和z4之间的财务损失／罚款或2年以上、10年以下监禁；

g) 执法通知、民事诉讼或刑事犯罪，导致无法限制的财务损失／罚款或10年以上监禁； h) 无输入； i) 无输入； j) 无输入。 B．6管理和业务运行

有的信息十分重要，它的损害可能会危害组织的有效运行。例如，与策略变动相关的信息如果泄露的话，可能会引起公众反应，造成该策略无法实施。与财务或计算机软件相关信

息的修改、抵赖或不可用也有可能对组织的运行带来严麓后果。此外，对承诺的否认也可能会对组织的业务带来负面后果。 应该使用以下指南。

a) 组织的某个部分运行效率低； b) 无输入；

c) 削弱组织及其运行的正常管理； d) 无输入；

e) 阻碍组织策略的有效开发或执行；

f) 使组织在与其他组织进行商业或策略谈判时处于不利地位；

g) 严重阻碍组织重要策略的开发或执行，或者中断或严重干扰组织的重要运行； h) 无输入； i) 无输人； j) 无输入。 B．7声誉损失

信息的未授权泄露和修改、抵赖或不可用，可能会对组织的声誉造成损失，从而导致组织的声望损害、可信度损失以及其他负面后果。应该使用以下指南． a) 无输入；

b) 导致组织内的局部尴尬境地；

c) 负面地影响到与股东、客户、供应商、管理机关、政府部门、其他组织或公众之间的关系，导致当地／地区的负面曝光； d) 无输入；

e) 负面地影响到与股东、客户、供应商、管理机关、政府部门、其他组织或公众之间的关系，导致国家范围内的负面曝光； f) 无输入；

g) 负面地影响到与股东、客户、供应商、管理机关、政府部门、其他组织或公众之间的关系，导致广泛的负面曝光； h) 无输入； i) 无输入；

·攻击者可能会破坏对于追踪他／她本人有用的信息。

一旦作出中断／关闭受攻击的信息系统、服务和／或网络的决定，其迅速和可靠的执行必须在技术上可行。但同时应实施适当的鉴别手段，以使未授权人员无法进行这种活动。

需要进一步考虑的是如何预防事件重演，这通常是行动的重中之重；不难得出结论，攻击者暴露了应该矫正的弱点，仅仅追踪攻击者是不够的。特别是当攻击者是非恶意的且造成的危害小乃至没有危害时，这一点容易被忽视。

对于由非蓄意攻击导致的信息安全事件，应该确定其来源。在采取防护措施的同时，可能有必要关闭信息系统、服务和/或网络，或者隔离相关部分并关闭（在取得相关IT和/或业务管理者的预先同意下）。如果所发现的弱点对于信息系统、服务和/或网络设计来说是根本性的，或者说是一个关键弱点，处理起来可能需要更长时间。

另一个响应措施可能是启用监视技术（如“蜜罐”，参见ISO/IEC TR 18043）。这样的行动应该依照正式成文的信息安全事件管理方案规定的规程进行。

ISIRT成员应对照备份记录来检查因信息安全事件而出现讹误的信息，搞清是否存在篡改、删除或插入等情况。检查日志的完整性是必要的，因为故意行为的攻击者很可能为了掩盖自己的行踪而修改这些日志 8.5.1.3 事件信息更新

无论确定下一步采取什么行动，ISIRT成员都应尽最大能力更新信息安全事件报告，并将其添加到信息安全事态/事件数据库，同时按需要通知ISIRT管理者和其他必要人员。跟新可能包括有关以下内容的更多信息：

·信息安全事件是什么样的情形；

·它是如何被引起的——由什么或谁引起； ·它带来或可能带来什么危害；

·它对组织业务造成的影响或潜在影响；

·它是否属于重大事件（根据组织预先制定的事件严重性衡量尺度） ·到目前为止它是如何被处理的。

如果信息安全事件已被解决，报告应包含已经采取的防护措施的详细情况和其他任何经验教训（例如用来预防相同或类似事件再次发生的进一步防护措施）。被更新的报告应该添加到信息安全事态/事件数据库中，并通报ISIRT管理者和其他必要人员。

应该强调的是，ISIRT 负责妥善保管与信息安全事件相关的所有信息，以备鉴别分析和可能在法庭上作证据之用。例如一个针对IT的信息安全事件，在最初发现事件后，应该在受影响的IT系统、服务和/或网络关闭之前收集所有只会短暂存在的数据，为完整的法律

取证调查做好准备。需要收集的信息包括内存、缓冲区和注册表的内容以及任何过程运行的细节，以及：

· 根据信息安全事件的性质，对受影响的系统、服务和/或网络进行一次完整复制，或对日志和重要文件进行一次低层备份，以备法律取证之用；

·对相邻系统、服务和网络的日志（例如包括路由器和防火墙的日志）进行收集和评审； ·将所有收集到的信息安全地保存在只读介质上；

·进行法律取证复制时应有两人以上在场，以表明和保证所有工作都是遵照相关法律法规执行的；

·用来进行法律取证复制的工具和命令的规范和说明书均应等级归档，并与原始介质一起保存。

在这一阶段如果可能的话，ISIRT成员还要负责将受影响设施（IT设施或其他社火）恢复到不易遭受相同攻击破坏的安全运行状态。 8.5.1.4 进一步的活动

如果ISIRT成员确定的确发生了信息安全事件，还应采取如下其他需要措施，如： ·开始法律取证分析；

·向负责对内对外沟通的人员通报情况，同时建议应该以什么形式向哪些人员报告什么内容。

一旦尽力完成信息安全事件报告后，应将其输入信息安全事态/事件数据库并送达ISIRT管理者。

如果组织内的调查工作超出了预定时间，应产生一份中间报告。

基于信息安全事件管理方案文件提供的指南，负责评估信息安全事件的ISlRT人员应该了解：

·何时必须将问题上报以及应该向谁报告；

·ISIRT进行的所有活动均应遵循正式成文的变更控制规程。

当常规通信设施（如电子邮件）存在问题或者被认为存在闻题（包括系统被认为可能处于攻击之下），而且：

·得出信息安全事件属于严重事件的结论；

·确定出现了“危机”情况时，

应在第一时间将信息安全事件通过人、点火或文本方式报给相关人员，

ISIRT管理者在同组织的信息安全负责人及相关董事会成员/高级管理人员保持联络的同时，被认为有必要同所有相关方（组织内部的和外部的）也应保持联络（参见7.5.3和7.5.4）。

为了确保这样的联络快速有效，有必要实现建立一条不完全依赖于受信息安全事件影响的系统、服务和/或网络的安全通讯渠道，包括制定联系人不在时的备用人选或代表。 8.5.2事件是否处于控制下

在ISIRT成员作出立即响应，并进行了法律取证分析和通报相关人员后，必须迅速得出信息安全事件是否处于控制之下的结论。如果需要，ISIRT成员可以就这一问题征求同事、ISIRT管理者和/或其他人员或工作组的意见。

如果确定信息安全事件处于控制之下，ISIRT成员应启动需要的后续响应，并进行法律取证分析和向相关人员通报情况（参见8.5.3、8.5.5和8.5.6），直至结束信息安全事件的处理工作，使受影响的信息系统恢复正常运行。

如果确定信息安全事件不再控制之下，ISIRT成员应启动“危机求助行动”（参见8.5.4）。 8.5.3后续响应

在确定信息安全事件处于控制之下、不必采取“危机求助”行动之后，ISIRT成员应确定是否需要对信息安全事件作出进一步响应以及作出什么样的响应。其中可能包括将受影响的信息系统、服务和/或网络恢复到正常运行，然后，该人员应该将有响应细节记录到信息安全事件报告单和信息安全事态/事件数据库中，并通知负责采取相关行动的人员。一旦这些行动成功完成后，应该将结果细节记录到信息安全事件报告单和信息安全事态/事件数据库中，然后结束信息安全事件处理工作，并通知相关人员。有些响应旨在预防同样或类似信息安全事件再次发生。例如，如果信息安全事件的原因是IT硬件或软件故障，而且没有补丁可用，应该立即联系供应商。如果信息安全事件涉及到一个已知的IT脆弱死那个，则应装载相关的信息安全升级包。任何被信息安全事件突现出来的IT配置问题均应得到妥善处理。降低相同或类似IT信息安全事件再次发生可能性的其他措施还包括变更系统口令和关闭不用的服务。

响应行动的另一个方面涉及IT系统、服务和/或网络的监控。在对信息安全事件进行评估之后，应在适当的地方增加监视防护措施，以帮助发现具有信息安全事件症状的异常和可疑事态。这样的监视还可以更深刻地揭露信息安全事件，同时确定还有哪些其他IT系统受到危及。

启动相关业务连续性计划中特定的响应可能很必要。这一点既适用于IT信息安全事件，同时也适用于非IT的信息安全事件。这样的响应涉及业务的所有方面，不仅包括那些与IT

直接相关的方面，同时还应包括关键业务功能的维护和以后的回复——其中包括（如果相关的话）语音通信、人员级别和物理设施。

响应行动的最后一个方面是恢复受影响系统、服务和/或网络。通过应用针对已知脆弱性的补丁或禁用易遭破坏的要素，可将受影响的系统、服务和/或网络恢复到安全运行状态。如果因为信息安全事件破坏了日志而无法全面了解信息安全事件的影响程度，可能要考虑对整个系统、服务和/或网络进行重建。这种情况下，启动相关的业务连续性计划十分必要。 如果信息安全事件是非IT相关的，例如由火灾、洪水或爆炸引起，就应该依照正式成文的相关业务连续性计划开展恢复工作。 8.5.4“危机求助”行动

如8.5.2所述，ISIRT确定一个信息安全事件是否处于控制下时，很可能会得出事件不在控制之下，必须按预先制定计划采取“危机求助”行动的结论。

有关如何处理可能会在一定程度上破坏信息系统可用性／完整性的各类信息安全事件的最佳选择，应该在组织的业务连续性战略中进行标识。这些选择应该与组织的业务优先顺序和相关恢复时间表直接相关，从而也与IT系统、语音通信、人员和食宿供应的最长可承受中断时间直接关联。业务连续性战略应该明确标明所要求的： ·预防、恢复和业务连续性支持措施； ·管理业务连续性规划的组织结构和职责； ·业务连续性计划的体系结构和概述；

业务连续性计划以及支持启动计划的现行防护措施，一旦经检验合格并得到批准后，便可构成开展“危机求助”行动的基础。

其他可能类型的“危机求助”行动包括（但不限于）启用： ·灭火设施和撤离规程； ·防洪设施和撤离规程； ·爆炸“处理”及相关撤离规程； ·专家级信息系统欺诈调森程序； ·专家级技术攻击调查程序； 8.5.5法律取证分析

当前面的评估确定需要收集证据时——在发生重大信息安全事件的背景下，ISIRT应进行法律取证分析。这项工作涉及按照正式文件规定的程序，利用基于IT的调套技术和工具，对指定的信息安全事件进行信息安全事件管理过程中迄今为止更周密的分析研究。它应该以

结构化的方式进行，应该确定哪些内容可以用作证据，进而确定哪些证据可以用予内部处罚，哪些证据可以用于法律诉讼。

法律取证分析所需设备可分为技术（如审计工具、证据恢复设备）、规程、人员和安全办公场所4类。每项法律取证分析行动都应完全登记备案，其中包括相关照片、审计踪迹分析报告、数据恢复日志。进行法律取证分析人员的熟练程度连同熟练程度测试记录一起应登记备案。能够表明分析的客观性和逻辑性的任何其他信息也都应记录在案。有关信息安全事件本身、法律取证分析行动等的所有记录以及相关的存储介质，都应保存在一个安全的物理环境中并遵照相关规程严加控制，以使其不至被未授权人员接触，也不会被篡改或变得不可用。基于IT的法律取证分析工具应该符合标准，其准确性应能经得起司法推敲，而且要随着技术的发展升级到最新版本。ISIRT工作的物理环境应提供可做验证的条件，以确保证据的处理过程不会受人质疑。显然，ISIRT要有充足的人员配备才能做到在任何时候都能对

信息安全事件作出响应。，而且在需要时“随叫随到”。

随着时间的推移，难免会有人要求对信息安全事件（包括欺诈、盗窃和蓄意破坏）的证据重新审理。因此，要对ISIRT有所帮助，就必须有大量基于IT的手段和支持性规程供ISIRT在信息系统、服务或网络中揭开“隐藏”信息——其中包括看似像是已被删除、加密或破坏的信息。这些手段成能应付已知类型信息安全事件的所有已知方面（并且当然被记录在ISIRT规程中）。

当今，法律取证分析往往必须涉及错综复杂的联网环境，调查工作必将涵盖整个操作环境，其中包括各种服务器——文件、打印、通信、电子邮件服务器等，以及远程访问设施。有许多工具可供使用，其中包括文本搜索工具，镜像软件和法律取证组件。成该强调的是，法律取证分析规程的主要焦点悬确保证据的完好无缺和核查无误，以保证其经得起法律的考验，同时还要保证法律取证分析在原始数据的准确拷贝上进行，以防分析工作损害原始介质的完整性。

法律取证分析的整个过程应包括以下相关活动：

·确保fl标系统、服务和/或网络在法律取证分析过程中受到保护，防止其变得不可用、被改变或受其他危害（包括病毒入侵），同时确保对正常运行的影响没有或最小；

·对“证据”的“捕获”按优先顺序进行，也就是从最易变化的证据开始到最不易变化的证据结束（这在很大程度上取决于信息安会事件的性质）；

·识别主体系统、服务和／或网络中的所有相关文件，包括正常文件、看似（但并没有）被删除的文件、口令或其他受保护文件和加密文件； ·尽可能恢复已发现的被删除文件和其他数据； ·揭示IP地址、主机名、网络路由和Web站点信息；

·提取应用软件和操作系统使用的隐藏、临时和交换文件的内容； ·访问受保护或被加密文件的内容（除非法律禁止）；

·分析在特别（通常是不可访问的）磁盘存储区中发现的所有可能的相关数据； ·分析文件访问、修改和创建的时间； ·分析系统／服务／网络和应用程序日志；

·确定系统／服务／网络中用户和／或应用程序的话动； ·分析电子邮件的来源信息和内容；

·进行文件完整性检查，检测系统特洛伊木马搬原来系统中不存在的文件；

·如果可行，分析物理证据，如查指纹、财产损害程度、监视录像、警报系统日志、通行卡访问日志以及会见目击证人等；

·确保所提取的潜在证据被妥善处理和保存，使之不会被损害或不可使用，并且敏感材料不会被未授权人员看到。应该强调的疑，收集证据的行为要遵守相关法律的规定； ·总结信息安全事件的发生原因以及在怎样的时间框架内采取的必要行动，连同具有相关文件列表的证据一起附在主报告中；

·如果需要，为内部惩罚或法律诉讼行动提供专家支持。 所采用的方法应该记录在ISIRT规程中。

ISIRT应该充分结合各种技能来提供广泛的技术知识（包括很可能被蓄意攻击者使用的工具和技术）、分析／调查经验（包括如何保存有用的证据）、相关法律法规知识以及事件的发展趋势。 8.5.6通报

在许多情况下，当信息安全事件被ISIRT确定属实时，需要同时通知某些内部人员（不在ISIRT/管理层的正常联系范围内）和外部人员（包括新闻界）。这种情况可能会发生在事件处理的各个阶段，例如，当信息安全事件被确认属实时，当事件被确认处于控制之下时，当事件被指定需要“危机求助”时，当事件的处理工作结柬时以及当事件评审究成并得出结论时。

为协助必要时通报工作的顺利进行，明智的做法是提前准备一些材料，到时候根据特定信息安全事件的具体情况调整材料的部分内容，然后迅速通报给新闻界和／或其他媒体。任何有关信息安全事件的消息在发布给新闻界时，均应遵照组织的信息发布策略。需要发布的消息应由相关方审查，其中包括组织高级管理层、公共关系协调员和信息安全人员。 8.5.7上报

有时会出现必须将事情上报给高级管理层、组织内其他部门或组织外人员／组织的情况。这可能是为了对处理信息安全事件的建议行动作出决定，也可能是为了对事件作出进一步评估以确定需要采取什么行动。这时应遵循8.4描述的评估过程，或者，如果严重问题早就凸现出来，或许已经处于这些过程之中了。在信息安全事件管理方案文件中应有指南可供那些可能会在某一时刻需要将问题上报的人员（即运行支持组和ISIRT成员）使用。 8.5.8活动日志和变更控制

应该强调的是，所在参与信息安全事件报告和管理的人员应该完整地记录下所有的活动以供日后分析之用。这些内容应该包含在信息安全事件报告单和信息安全事态／事件数据库中，而且要在从第一次报告单到事件后评审完成的整个过程中不断更新。记录下来的信息应该妥善保存并留有完整备份。此外，在追踪信息安全事件以及更新信息安全事件报告单和信息安全事态／事件数据库的过程中所做的任何变更，均应遵照已得到正式批准的变更控制方案进行。 9评审 9.1概述

信息安全事件解决完毕并经各方同意结束处理过程后，还须进一步进行法律取证分析和评审，以确定有哪些经验教训需要汲取以及组织的整体安全和信息安全事件管理方案有哪些地方需要改进。

9.2 进一步的法律取证分析

在事件被解决后，可能依然需要进行法律取证分析以确定证据。此项工作应由ISIRT使用8.5.5建议的工具和规程进行。 9.3 经验教训

一旦信息安全事件的处理工作结束，应该迅速从信息安全事件中总结经验教训并立即付诸实施，这一点十分重要。经验教训可能反映在以下方面：

· 新的或改变的信息安全防护措施要求。可能是技术或非技术（包括物理）的防护措施。根据总结出来的经验教训，可能需要迅速更新和发布安全意识简报（给用户和其他人员），以及迅速修订和发布安全指南和/或标准；

· 信息安全事件发生过程中所获得的相关信息应该用来进行事件发展趋势发生模式的分析。这一点对于根据以往经验和文字资料尽早确定信息安全事件以及警告进一步会引发哪些信息安全事件来说，十分有效。

此外，还应充分利用政府部门、商业CERT和供应商提供的信息安全事件和相关脆弱性评估和安全测试应不仅限于受信息安全事件影响的信息系统、服务和/或网络的脆弱性，同时确保没有新的脆弱性被引入。

值得强调的是，脆弱性评估应定期进行t而且倍息安金事传发生后对脆弱性的褥次评估应是这一持续评估过程的一个组成部分（而并非替代）。

应该对信息安全事件作出分析总结，并呈递到组织管理层的信息安令管理协调小组和／或组织总体信息安全策略中定义的其他管理协调小组的每次会议，t。 9.4 确定安全改进

在信息安全事件解决后的评估过程中，根据需要可能确定新的或改变的防护措施。改进建议和相关防护措施需求可能因财务或运作上的原因不能立即付诸实施，在这种情况下应该作为组织的长期目标逐步实行。例如，换用一种更安全更强固的防火墙短期内可能在财务上行不通，但是必须将其看做组织早晚要达到的长期信息安全目标（参见10.3）逐步实行。例如，换用一种更安全更强固的防火墙短期内可能在财务上行不通，但是必须将其看作组织早晚要达到的长期信息安全目标（参见10.3）。 9.5确定方案改进

在事件解决之后，ISIRT管理者或其代表应该评审所发生的一切以进行评估，从而“量化”对信息安全事件整体响应的效果。这样的分析旨在确定信息安全事件管理方案的哪些方面成功地发挥了作用，有哪些方面需要改进。

响应后分析的一个重要方面是将信息和知识反馈到信息安全事件管理方案中。如果事件相当严重，应在事件解决后尽快安排所有相关方召开会议。这样的会议应该考虑以下因素：

·信息安全事件管理方案规定得规程是否发挥了预期作用？ ·是否有对发现事件有帮助的规程或方法？ ·是否确定过对相应过程有帮助的规程或工具？

·在事件发现、报告和响应的整个过程中向所有相关方的事件通报是否有效？

会议结果应记录归档，各方一致同意的任何行动都应适当地遵照行事（参见第10.4节）。 10 改进 10.1 概述

“改进”阶段的工作包括执行“评审”阶段提出的建议，即改进安全风险分析和管理结果、改善安全状况和改进信息安全事件管理方案。下面各条将逐一阐述这些主题。

10.2 安全风险分析和管理改进

根据信息安全事件的严重程度和影响，在评估信息安全风险分析和管理评审的结果是，必须考虑新的威胁和脆弱性。作为完成信息安全风险分析和管理评审更新的后续工作，引入更新的或全新的防护措施可能是必要的。

10.3 改善安全状况

遵照“评审”阶段（参见9.4）提出的改进建议和对许多信息安全事件的分析，更新的和/或全新的防护措施需要启动。如9.3所述，这些措施可能是技术或非技术（包括物理）的防护措施，并可能需要迅速更新和发布安全意识简报（给用户和其他人员），以及迅速修订和公布安全指南和标准。此外，对组织的信息系统、服务和网络应定期进行脆弱性评估，以帮助确定脆弱性和提供一个对系统/服务/网络持续加固的过程。

另外，在一次事件之后立即进行的信息安全规程和文件评审更有可能是以后会被要求的一种响应。在一次信息安全事件之后，相关的信息安全策略和规程应参考事件管理过程中收集的信息和识别的任何问题来进行更新。确保组织全体人员知悉信息安全策略和规程的更新是ISIRT以及组织信息安全管理者的一个长期持续目标。 10.4改进方案

对信息安全事件管理方案中被确定需要改进的地方(参见9.5)，需要认真评审和判断，然后据此修订更新方案文件。信息安全事件管理过程、规程和报告单的任何更改都应经过全面检查和测试后方可投入使用。 10.5其他改进

“评审”阶段可能还会确定其他需要改进的方面，如信息安全策略、标准和规程的变更，IT硬件和软件配置的变更等。

附录A

（资料性附录） 信息安全事态和事件报告单示例 信息安全事态和事件报告 填写说明

信息安全事态和事件报告单的设计旨在向相关人员提供有关信息安全事态和事件（如果事态被确定为信息安全事件）的信息。

如果你怀疑有信息安全事态正在发生或已经发生——尤其是可能会对组织的财产或声誉带来巨大损失或损害的事态，你应立即按照组织的信息安全事件管理方案规定的规程填写和提交一份信息安全事态报告单。

你提供的信息将被用来启动对事态的适当评估，从而确定是否受将该事态归类为信息安全事件，以及是否需要采取补救措施预防或限制损失或损害。如果时间紧迫，你可以不必在这时填写完本报告单的所有栏目。

如果你是评审已全部或部分填写的事态报告单的一名运行支持组成员，你将被要求审查是否需将该事态归类为信息安全事件。如果该事态被归为事件，你应尽可能将更多的信息填入信息安全事件报告单，且将信息安全事态和事件报告单一并转交给ISIRT，无论该信息安全事态是否被归类为事件，都应及时更新信息安会事态／事件数据库。

如果你是评审由运行支持组转变的信息安全事态和事件报告单的一名ISIRT成员，你应随着调查的进展不断更新事件报告单的内容，同时对信息安全事态／事件数据库进行相应更新。

请遵照以下指南来完成报告单；

·如果可能，报告单应以电子方式10）填写和提交。（当默认的电子报告机制（如电子邮件）存在问题或被认为存在问题时（包括认为可能出现系统受攻击且报告单可以被未授权人员读取的情况时）。应该使用备用的报告方或。备用方式可能包括通过人、电话或文本消息传递）；

·只提供你本人了解的事实———一不要为了完成报告单中的栏目凭推测填写。如果你不能肯定你提供的信息，请清楚地著名该信息没有被确认，以及使你认为它可能真实的依据； ·你应该提供你的全部详细联系信息。为了就你的报告进一步向你了解情况，就必须与你联系——不管是马上还是以后。

如果你后来发现自己提供的侄何信息有不准确、不完整或误导性的地方，你应及时纠正并重新提交报告。

10)只要可能，就应将这些报告制成电子表格（如在安全的web网页上），并且可与电子形式的信息安全事态／事件

．数据库链接．在当今世界上，运行基于纸质的方案

会耗时费力，不是效率最佳的运行方式。

信息安全事态报告

事态日期： 事态编号11）：

相关事态和／或事件标识号（如果有的话）：

报告人的详细情况

姓名： 地址： 单位： 部门： 电话： 电子信箱：

根据相关业务连续性计划，通过以下方式将信息系统、服务和/或网络恢复正常运行； ——良好的备份规程；

——清晰可靠的备份； ——备份测试； ——恶意代码控制

——系统和应用软件的原始介质； ——可启动介质；

——清晰、可靠和最新的系统和应用程序补丁；

一个受到攻击的信息系统、服务或网络可能无法正常运转。因为，只要可能，并考虑到已受评估的风险，响应信息安全事件必需的任何技术手段（软件和硬件）都不应依赖于组织的“主流”系统、服务或网络的运行。如果可能，它们应该完全独立。

所有技术手段都应认真挑选、正确实施和定期测试（包括对所做备份的测试）。 应指出的是，本节所描述的技术手段不包括哪些用来直接检测信息安全事件和入侵并能自动通知相关人员的技术手段。有关这些技术内容的描述参见ISO/IEC TR 15947《信息技术 安全技术IT 入侵检测框架》以及ISO/IEC 13335《信息技术 安全技术信息和通信技术安全管理》。 7.7 意识和培训

信息安全事件管理是一个过程，它不仅涉及技术而且涉及人，因此应该得到组织内有适当信息安全意识并经过培训的员工支持。

组织内所有人员的意识和参与，对于一个结构化的信息安全事件管理方法的成功来说，至关重要。鉴于此，必须积极宣传信息安全事件管理的作用，以作为总体信息安全意识和培训计划的一部分。安全意识计划及相关材料应该对所有人员可用，包括新员工，以及相关第三方用户和合同商。应为运行支持组和ISIRT成员，以及如果必要的话，包括信息安全人员和特定的行政管理人员，制定一项特定的培训计划。应该指出的是，根据信息安全事件类型、频率及其与事件管理方案交互的重要程度的不同，直接参与事件管理的各组成员需要不同级别的培训。

安全意识简报应该包括下列内容：

·信息安全事件管理方案的基本工作机制，包括它的范围以及安全事态和事件管理“工作流程”；

·如何报告信息安全事态和事件；

·如果相关的话，有关来源保密的防护措施； ·方案服务级别协议；

·结果的通知——建议在什么情况下采用哪些来源； ·不泄泄漏协议规定的任何约束；

·信息安全事件管理组织舫授权及报告流程； ·由谁以及如何接受信息安全攀件管理方案的报告。

在有些情况下，将有关信息安全事件管理的安全意识教育细节包括在其他培训计划（如面向员工的培训计划或一般性的总体安全意识计划）之中是可取的做法。这样的安全意识教育方法断以为特定人群提供极具价值的背景信息，从而改进培训计划的效果和效率。 在信息安全事件管理方案开始运行之前，所有相关人员必须熟悉发现和报告信息安全事态的规程，且被选人员必须十分了解随后的过程。还应该有后续的安全意识简报和培训课程。培训应该得到运行支持组和ISIRT成员、信息安全员和特定的行政管理员的具体练习和测试工作的支持。 8使用 8.1 概述

运行中的信息安垒事件管理由“使用”和“评审”着两个主要阶段组成，在这之后是“改进”阶段，即根据总结出来的经验教训改善安全状况。这些阶段及其相关过程在5.2中有简要介绍。“使用”阶段是本章描述的内容，随后的第9章和第10章将分别描述“评审”和“改进”阶段。

图2示出了这3个阶段及其相关过程。 8.2关键过程的概述 使用阶段的关键过程有：

a) 发现和报告发生的信息安全事态，无论是由级织人员／顾客一起的还是自动发生的（如，防火墙警报）

b) 收集有关信息安全事态的信息，由组织的送行支持组人员9）进行第一状评估，确定该事态是属于信息安全事件还是发生了误报；

c) ISIRT进行第二次评估，首先确认该事态是否属于信息安全事件，如果的确如此，则作出立即响应，同时启动必要的法律取证分析和沟通活动。 d) 由ISIRT进行评审以确定该信息安全事件是否处于控制下：

1) 如果处于控制下，则崩动任何所需要的进一步的后续响应，以确保所有相关信息准备完毕，以供事件后评审所用；

2) 如果不在控制下，则采取“危机求助”活动并召集相关人员，如组织中负责业务连续性的管理者和工作组；

e) 在整个阶段按要求进行上报，以便进一步评估和／或决策；

f) 确保所有相关人员，尤其是ISIRT成员，正确记录所有活动以备后面分析所用； g) 确保对电子证据进行收集和安全保存，同时确保电子证据的安全保存得到持续监视，以备法律起诉或内部处罚所需；

h) 确保包括信息安全事件追踪和事件报告更新的变更控制制度得到维护，从而使得信息安全事态/事件数据保持最新。

9)一般来说，不要期望运行支持组人员就是安全专家． 图2信息安全事态和事件处理流程图

所有收集到的、与信息安全事态或事件相关的信息应保存在由ISIRT管理的信息安全事态／事件数据库中。每个过程所报告的信息应按当时的情况尽可能保持完整，以确保为评估和决策以及其他相关措施提供可靠基础。

一旦发现和报告了信息安全事态，那么随后的过程应达到以下目的。

· 以适当的人员级别分配事件管理活动的职赍，包括专职安全人员和非专职安全人员的评估、决策和行动；

· 制定每个被通知人员均需遵守的正式规程，包括评估和修改报告，评估损害，以及通知相关人员

（至于每个人的具体行动由事件的类型和严重程度来决定）；

·使用指南来完整地将一个信息安全事态记入文件，如果该事态被归类为信息安全事件，那随后采取的行动也应记入文件，并更新信息安全事态／事件数据库。 指南涉及：

·8.3讨论的信息安全事态发现和报告；

·8.4讨论的评估和决策（确定是否应将信息安全事态归类为信息安全事件）； ·8.5讨论的对信息安全事件的响应，包括： ——立即响应；

一一评审以确定信息安全事件是否在控制之下； ——随后响应； ——“危机求助”行动； ——法律取证分析； ——沟通； ——上报问题； ——记录各项行动。 8.3 发现和报告

信息安全事态可以被由技术、物理或规程方面出现的某种情况引起注意的一人或多人发现。例如，发现可能来自火/烟探测器或者入侵（防盗）警报，并通知到预先指定位置以便有人采取行动。技术型的信息安全事态可通过自动方式发现，如由审计追踪分析设施、防火墙、入侵检测系统和防病毒工具在预设参数激发的情况下发出的警报。

无论发现信息安全事态的源头是什么，得到自动方式通知或直接注意到某些异常的人员要负责启动发现和报告过程。该人员可以是组织内任何一名员工。无论是正式员工还是合同工，该员工应遵照相关规程，并使用信息安全事件管理方案规定得信息安全事态报告单在第一时间把信息安全是爱报告给运行支持组和管理层。因此，所有员工要十分了解并且能够访问用于报告各种类型的可能的信息安全事态的指南——其中包括信息安全事态报告单的格式以及每次事态发生时应该通知的联系人的具体信息，这一点直观重要。（所有人员至少要知晓信息安全事件报告单的格式，这有助于他们理解信息安全事件管理方案。）

如何处理一个信息安全事态于该事态的性质以及它的意义和影响。对于许多热来说，这种决定超出了他们的能力。因此，报告信息安全事态的人员应尽量使用叙述性文字和当时可用的其他信息完成信息安全是太报告单，必要的话，与本部门管理者取得联系。报告单最好是电子格式的（例如以电子邮件或web表单的方式提交），应该安全地发送给指定的运行支持组（它最好应提供7×24h服务），并将一份拷贝给ISIRT管理者。附录A给出了一份信息安全事态报告单的示例模板。

应该强调的是，在填写信息安全事态报告单的时间，不是一种好做法。如果报告人对报告单上某些字段中的数据没有信心，在提交时应加上适当的标记，一遍后来沟通时修改。还应该认识到，有些电子报告机制（如电子邮件）本身就是明显的攻击对象。

当默认的电子报备机制（如电子邮件）存在阔越或被认为存在问题（包括认为可能出现系统受攻击且报告单可以被未授权人员读取的情况）时，应该使用备用的沟通方式。备用方式可能能包括通过人，电话或文本消息．当调查初期就明显表明，信息安全事态极有可能救确定为信息安全事件，特别是重大事件时，尤其应该使用上述备用方式。

应该指出的是，尽管在多数情况下，信息安全事态必须向上报告以便于运行支持组采取措施，但偶尔也会有在本部门管理者协助下直接在本地处理信息安全是太的情况。一个信息安全事态可能很快就被确定为误报，或者被解决达到满意的结果。在这种情况下，报告单应填写完毕后报告给本部门管理者

以及运行支持组和ISIRT，一遍记录归档，如计入信息安全事态/事件数据库中，在这样的情况下，可以由报告信息安全事态结束的人员完成信息安全事件报告单所要求的一些信息——及时这种情况属实，那么信息安全事件报告单也应该填写完整并上报。 8.4 事态/事件评估和决策 8.4.1第一次评估和初始决策

运行支持组中负责接收报告的人员应签收已填写完毕的信息安全事态报告单，将其输入到信息安全事态/事件数据库中，并进行评审。该人员应该从报告信息安全事态的人处得到详细说明，并从该报告人活其他地方进一步收集可用的任何必要和已知信息。随后，运行支持组的该人员应该进行评估，以确定这个信息安全事态是属于信息安全事件还是仅为一次误报。如果确定该信息安全事态属于误报，应将信息安全事态报告单填写完毕并发送给ISIRT，供添加信息安全事态/事件数据库和评审所用，用时将拷贝发送给事态报告人及其部门管理者。

这一阶段收集到的信息和其他证据可能会在将来用于内部处罚或司法起诉过程。承担信息收集和评估任务的人员应接受证据收集和保存方面的专门培训。

出了记录行动的日期和事件外，全面记录下列内容也是必要的： ·看见了什么、做了什么（包括使用的同居）以及为什么要这么做；

·“证据”所处的位置；

·如何将证据归档（如果可行的话）

·证据材料的存储/安全保管以及随后对其进行访问的细节。

如果确定信息安全事态很可能是一个 信息安全事件，而且运行支持组成员具有适当资质，则可以进行进一步评估。这可能引发必要的不就措施，例如确定应该增加哪些应急防护措施并制定适当人员执行。显然。当一个信息安全事态被确定为重大信息安全事件（根据组织内预先制定的时间严重性衡量只读）时，应该直接通知ISIRT管理者。显而易见，如果出现“危机”情况，应该及时宣布，例如通知业务连续性管理者可能需要启动业务连续性计划，同时还应通知ISIRT管理者和高级管理层。但最可能的情况是，必须将信息安全事件直接指派给ISIRT进行进一步评估和采取措施。

无论决定下一步要采取什么行动，运行支持组成员都应尽可能地将信息安全事件报告单填写完整。附录A给出了一个信息安全事件报告单的实力模板。信息安全事件报告单影使用叙述性文字，应尽可能确认和描述一下内容：

·该信息安全事件属于什么情况；

·事件是被如何引起的——由什么情况或由谁引起； ·事件带来的危害或可能带来的危害； ·事件对组织业务造成的影响或潜在影响；

·确定该信息安全事件是否属于重大事件（根据组织预前制定的时间严重性衡量尺度）； ·到目前为止是如何处理的。

当从以下几个方面考虑信息安全事件对组织业务的潜在或实际负面影响是： ·未授权泄漏信息； ·未经授权修改信息； ·抵赖信息；

·信息和/或服务不可用； ·信息和/或服务遭受破坏。

首先要考虑哪些后果与之相关，例如： ·对业务运行造成的财务损失/破坏； ·商业和经济利益； ·个人信息；

·法律法规义务； ·管理和业务运行； ·声誉损失。

对于那些被认为与信息安全事件相关的后果，应使用相关分类指南确定潜在或实际影响，并输入到信息安全事件报告单中。附录B给出了要点指南，该指南给出组织划分自身信息安全事件后果等级的要点示例。该后果等级可作为组织实施GB/Z 20986--2007《信息安会技术信息安全事件分类分级指南》的参考依据，有助于确定信息安全事件分级中“系统损失”这一参考要索的级别，结合“信息系统的重要程度”和“社会影响”，可明确信息安全事件的级别大小。

如果信息安全事件已被解决，报告中应该详细记录已经采取的防护措施和从事件中总结出的经验教训（例如，用来防止同样或类似事件再次发生的防护措施）。

一旦报告单填写完毕后，应将其送达ISIRT作为信息安全事态／事件数据库和评审的输入。

如果调查时间可能超过一周，应产生一份中间报告。

应该强调的是，根据信息安全事件管理方案文件提供的指南，负责评估信息安全事件的运行支持组人员应了解：

·何时必须将问题上报以及应该内潍报告；

·运行支持组进行的所有活动应遵循正式成文的变更控制规程。

当默认的电子报告机制（如电子邮件）存在问题或被认为存在问题（包括认为可能出现系统受攻击且报告单可以被未授权人员读取的情况）时，应该使用备用方式向ISIRT管理者报告。备用方式可能包括通过人、电话或文本消息传递。当信息安全事件属于重大事件时，尤其应该使用这种备用方式。 8.4.2第二次评估和事件确认

进行第二次评估以及对是否将信息安全事态归类为信息安全事件的决定进行确认是ISIRT的职责。ISIRT接收报告的人员应该；

·签收由运行支持组尽可能填写完成的信息安全事态报告单； ·将报告单输入信息安全事态/事件数据库； ·向运行支持组寻求任何必要的澄清说明； ·评审报告单内容；

·从运行支持组、信息安全事态报告单填写入或其他地方进一步收集可用的任何必要和已知信息。

如果信息安全事件的真实性或报告信息的完整性仍然存在某种程度不确定，ISIRT成员应该进行一次评估，以确定该信息安全事件是否属实还是仅为一次误报。如果信息安全事件被确定为误报，应完成填写信息安全事态报告、将其添加到信息安全事态／事件数据库中并送达ISIRT管理者。同时还应将报告的拷贝送达运行支持组、事态报告人及其部门管理者。 如果信息安全事件被确定是真实的，ISIRT成员（包括必要的合作伙伴）成进行进一步的评估，以尽快确认：

·该信息安全事件是什么样的情形，是如何被引起的——由什么或由谁引起，带来或可能带来什么危害，对组织业务造成的影响或潜在影响，足否属于重大事件（根据组织预先制定的事件严重性衡量尺度而定）；

·对任何信息系统、服务和／或网络进行的故意的、人为的技术攻击，例如： —一系统，服务和／或网络被渗透的程度，以及攻击者的控制程度； ——攻击者访问——可能复制、篡改或毁坏了一一哪些数据； ——攻击者复制、篡改或毁坏了哪些软件；

·对任何信息系统、服务和／或网络的硬件和／或物理位置进行的故意的、人为的物理攻击，例如：

——物理损害造成了什么直接和间接影响（是否设置了物理访问安全保护措施？）； ·并非直接由人为活动引起的信息安全事件，其直接和阅接影响（例如，是因火灾而导致物理协同开放？是因某些软件或通信线路故障或人为错误而使信息系统变得脆弱？）； · 到目前为止信息安全事件是如何被处理的。

当从以下方面评审信息安全事件对组织业务的潜在或实际负新影响时： ·未授权泄露信息； ·未授权修改信息； ·抵赖信息；

·信息和／或服务不可用； ·信息和／或服务遭受破坏；

有必要确认哪些后果与之相关，如以下示例类别： ·对业务运行造成的财务损失／破坏；

·商业和经济利益； ·个人信息； ·法律法规义务； ·管理和业务运行； ·声誉损失。

对于那些被认为与信息安全事件相关的后果，应使用相关类别的指南确定潜在或交际影响，并输入到信息安全事件报告单中。附录B绘出了要点指南，该指南给出组织划分自身信息安全事件后果等级的要点示例。该后果等级可作为组织实施GB/Z 20986—2007《信息安全技术 信息安全事件分类分级指南》的参考依据，有助于确定信息安全事件分级中“系统损失”这一参考要素的级别．结合“信息系统的重要程度”和“社会影响”，可明确信息安全事件的级别大小。 8.5响应 8.5.1 立即响应 8.5.1.1概述

在多数情况下，ISIRT成员的下一步工作是确定藏鼹响应措施，以处理信息安全事件、在信息安全事件单，记录细节并输入信息安全事态/事件数据库，以及向相关人员或工作组通报必要的措施。这可能导致采取应急防护措施（例如在得到相关IT和／业务管理者同意后切断／关闭受影喻的信息系统、服务和／或网络）和／或增加已被确定的永久防护措施并将行动通报相关人员或工作缀。如果这不能这么做，则应根据组织预先确定的信息安全事件严重性衡量尺度确定信息安全事件的严重程度，如果事件足够严重，应直接上报组织相关高级管理人员。例如，如果事件明显是一种“危机”情况，应通知业务连续性管理者以备可能启动业务连续性计划，同时还要通知ISIRT管理者和高级管理层。 8.5.1.2措施示例

这是一个在信息系统、服务和／或网络遭到故意攻击的情况下，采取相关的立即响应措施的例子如果攻击者不知道自．己已处于监视之下，可保留与互联网或其他网络的连接，以： ·允许业务关键应用程序正常运转； ·尽可能多地收集有关攻击者的信息。

但是在执行这一决策时，必须考虑以下因素：

·攻击者可能会意识到自己受到监视，很可能采取行动进一步毁坏受影响信息系统、服务和／或网络以及相关数据；

本文来源：https://www.bwwdw.com/article/oirf.html