ICS35.020
L 09

中华人民共和国国家标准

GB 17859-1999

信息技术 安全技术

信息安全事件管理指南

Information technology-Security techniques-Information security incident

management guide

（ISO/IEC TR 18044:2004，MOD）

 

 

2007-06-14发布   __________________________________

 中国国家标准化管理委员会　　  　　
中华人民共和国国家质量监督检验检疫总局    发布 

 

目 次

前言 ............................................................................. III
引言  .............................................................................  IV
1 范围  ............................................................................. 1
2 规范性引用文件  ............................................................................. 1
3 术语和定义  ............................................................................. 1
4 缩略语  ............................................................................. 1
5 背景  .............................................................................  2
5.1 目标  .............................................................................  2
5.2 过程  .............................................................................  2
6 信息安全事件管理方案的益处及需要应对的关键问题  .................................................4
6.1 信息安全事件管理方案的益处  ........................................................................5
6.2 关键问题  .............................................................................  6
7 规划和准备  .............................................................................  8
7.1 概述  .............................................................................  9
7.2 信息安全事件管理策略  ............................................................................. 9
7.3 信息安全事件管理方案  ............................................................................. 10
7.4 信息安全和风险管理策略  .............................................................................  13
7.5 ISIRT的建立  ............................................................................. 13
7.6 技术和其他支持  .............................................................................  14
7.7 意识和培训 . ............................................................................. 15
8 使用 ............................................................................. 16
8.1 概述  ............................................................................. 16
8.2 关键过程的概述  .........................................................................17
8.3 发现和报告  ............................................................................18
8.4 事态/事件评估和决策  .......................................................................18
8.5 响应  ............................................................................. 21
9 评审  .............................................................................  25
9.1 概述  ............................................................................. 25
9.2 进一步的法律取证分析  ............................................................................. 25
9.3 经验教训  ............................................................................. 25
9.4 确定安全改进  ............................................................................. 26
9.5 确定方案改进  ............................................................................. 26
10 改进  .............................................................................  26
10.1 概述  ............................................................................. 26
10.2 安全风险分析和管理改进  ............................................................................. 27
10.3 改善安全状况 ............................................................................. 27
10.4 改进方案  ............................................................................. 27
10.5 其他改进  ............................................................................. 27
附录A（资料性附录） 信息安全事态和事件报告单示例 ...........................................................28
附录B（资料性附录） 信息安全事件评估要点指南示例. ......................................................... 35
附录C（资料性附录） 本指导性技术文件与ISO/IEC TR 18044:2004技术性差异及其原因  ............ 38
参考文献  .............................................................................  39

前 言

（略）

引 言

目前，没有任何一种具有代表性的信息安全策略或防护措施，能够对信息、信息系统、服务或网络提供绝对的保护。即使采取了防护措施，仍可能存在残留的弱点，使得信息安全防护变得无效，从而导致信息安全事件发生，并对组织的业务运行直接或间接产生负面影响。此外，以前未被认识到的威胁也可能会发生。组织如果对这些事件没有作好充分的应对准备，其任何实际响应措施的效率都会大打折扣，甚至还可能加大潜在的业务负面影响的程度。因此，对于任何一个重视信息安全的组织来说，采用一种结构严谨、计划周全的方法来处理以下工作十分必要：

. 发现、报告和评估信息安全事件；
. 对信息安全事件做出响应，包括启动适当的事件防护措施来预防和降低事件影响，以及从事件影响中恢复（例如，在支持和业务连续性规划方面）；
. 从信息安全事件中吸取经验教训，制定预防措施，并且随着时间的变化，不断改进整个的信息安全事件管理方法。

信息技术 安全技术
信息安全事件管理指南

1 范围

本指导性技术文件描述了信息安全事件的管理过程。提供了规划和制定信息安全事件管理策略和方案的指南。给出了管理信息安全事件和开展后续工作的相关过程和规程。
本指导性技术文件可用于指导信息安全管理者，信息系统、服务和网络管理者对信息安全事件的管理。

2 规范性引用文件

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

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

3 术语和定义

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

3.1

业务连续性规划 business continuity planning

业务连续性规划是指这样的一个过程，即当有任何意外或有害事件发生，且对基本业务功能和支持要素的连续性造成负面影响时，确保运行的恢复得到保障。该过程还应确保恢复工作按指定优先级、在规定的时间期限内完成，且随后将所有业务功能及支持要素恢复到正常状态。
这一过程的关键要素必须确保具有必要的计划和设施，且经过测试，它们包含信息、业务过程、信息系统和服务、语音和数据通信、人员和物理设施等。

3.2

信息安全事态 information security event

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

3.3

信息安全事件 information security incident

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

3.4

信息安全事件响应组（ISIRT）Information Security Incident Response Team

ISIRT是由组织中具备适当技能且可信的成员组成的一个小组，负责处理与信息安全事件相关的全部工作。有时，小组可能会有外部专家加入，例如来自一个公认的计算机事件响应组或计算机应急响应组（CERT）的专家。

4 缩略语

CERT 计算机应急响应组（Computer Emergency Response Team）

ISIRT 信息安全事件响应组（Information Security Incident Response Team）

5 背景

5.1 目标

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

. 信息安全事态可以被发现并得到有效处理，尤其是确定是否需要将事态归类为信息安全事件；
1
. 对已确定的信息安全事件进行评估，并以最恰当和最有效的方式做出响应；
. 作为事件响应的一部分，通过恰当的防护措施——可能的话，结合业务连续性计划的相关要素——将信息安全事件对组织及其业务运行的负面影响降至最小；
. 及时总结信息安全事件及其管理的经验教训。这将增加预防将来信息安全事件发生的机会，改进信息安全防护措施的实施和使用，同时全面改进信息安全事件管理方案。

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

5.2 过程

为了实现4.1所述的目标，信息安全事件管理由4个不同的过程组成：

. 规划和准备（Plan and Prepare）；
. 使用（Use）；
. 评审（Review）；
. 改进（Improve）。

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

5.2.1 规划和准备

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

a) 制定信息安全事件管理策略并使其成为文件，获得所有关键利益相关人，尤其是高级管理层对策略的可视化承诺；
b) 制定信息安全事件管理方案并使其全部成为文件，用以支持信息安全事件管理策略。用于发现、报告、评估和响应信息安全事件的表单、规程和支持工具，以及事件严重性衡量尺度的细节2，均应包括在方案文件中（应指出，在有些组织中，方案即为信息安全事件响应计划）；
c) 更新所有层面的信息安全和风险管理策略，即，全组织范围的，以及针对每个系统、服务和网络的信息安全和风险管理策略，均应根据信息安全事件管理方案进行更新；
d) 确定一个适当的信息安全事件管理的组织结构，即信息安全事件响应组（ISIRT），给那些可调用的、能够对所有已知的信息安全事件类型作出充分响应的人员指派明确的角色和责任。在大多数组织中，ISIRT可以是一个虚拟小组，是由一名高级管理人员领导的、得到各类特定主题2应该建立“定级”事件严重性的衡量尺度。例如，可基于对组织业务运行的实际或预期负面影响的程度，分为“严重”和“轻微”两个级别。 专业人员支持的小组，例如，在处理恶意代码攻击时，根据相关事件类型召集相关的专业人员；
e) 通过简报和/或其他机制使所有的组织成员了解信息安全事件管理方案、方案能带来哪些益处
以及如何报告信息安全事态。应该对管理信息安全事件管理方案的负责人员、判断信息安全事态是否为事件的决策者，以及参与事件调查的人员进行适当培训；
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.1.2 降低对业务的负面影响

结构化的信息安全事件管理方法有助于降低对业务潜在的负面影响的级别。这些影响包括当前的经济损失，及长期的声誉和信誉损失。

6.1.3 强调以事件预防为主

采用结构化的信息安全事件管理有助于在组织内创造一个以事件预防为重点的氛围。对与事件相关的数据进行分析，能够确定事件的模式和趋势，从而便于更准确地对事件重点预防，并确定预防事件发生的适当措施。

6.1.4 强化调查的优先顺序和证据

一个结构化的信息安全事件管理方法为信息安全事件调查时优先级的确定提供了可靠的基础。
如果没有清晰的调查规程，调查工作便会有根据临时反应进行的风险，在事件发生时才响应，只按照相关管理层的“最大声音”行事。这样会阻碍调查工作进入真正需要的方面和遵循理想的优先顺序进行。
清晰的事件调查规程有助于确保数据的收集和处理是证据充分的、法律所接受的。如果随后要进行法律起诉或采取内部处罚措施的话，这些便是重点的考虑事项。然而应该认识到的是，从信息安全事件中恢复所必须采取的措施，可能危害这种收集到的证据的完整性。

6.1.5 预算和资源

定义明确且结构化的信息安全事件管理，有助于正确判断和简化所涉及组织部门内的预算和资源分配。此外，信息安全事件管理方案自身的益处还有：

. 可用技术不太熟练的员工来识别和过滤虚假警报；
. 可为技术熟练员工的工作提供更好的指导；
. 可将技术熟练员工仅用于那些需要其技能的过程以及过程的阶段中。

此外，结构化的信息安全事件管理还包括“时间戳”，从而有可能“定量”评估组织对安全事件的处理。例如，它可以提供信息说明解决处于不同优先级和不同平台上的事件需要多长时间。如果信息安全事件管理的过程存在瓶颈，也应该是可识别的。

6.1.6 信息安全风险分析和管理

结构化的信息安全事件管理方法有助于：

. 可为识别和确定各种威胁类型及相关脆弱性的特征，收集质量更好的数据；
. 提供有关已识别的威胁类型发生频率的数据。

从信息安全事件对业务运行的负面影响中获取的数据，对于业务影响分析十分有用。识别各种威胁类型发生频率所获取的数据，对威胁评估的质量有很大帮助。同样，有关脆弱性的数据对保证将来脆弱性评估的质量帮助很大。
这方面的数据将极大地改进信息安全风险分析和管理层评审结果。

6.1.7 信息安全意识

结构化的信息安全事件管理可以为信息安全意识教育计划提供重要信息。这些重要信息将用实例表明信息安全事件确实发生在组织中，而并非“只是发生在别人身上”。它还可能表明，迅速提供有关解决方案的信息会带来哪些益处。此外，这种意识有助于减少员工遭遇信息安全事件时的错误或惊慌/混乱。

6.1.8 为信息安全策略评审提供信息

信息安全事件管理方案所提供的数据可以为信息安全策略（以及其他相关信息安全文件）的有效性评审以及随后的改进提供有价值的信息。这可应用于适合整个组织以及单个系统、服务和网络的策略和其他文件。

6.2 关键问题

在信息安全事件管理方法中得到的反馈，有助于确保相关人员始终将关注点集中在组织的系统、服务和网络面临的实际风险上。这一重要的反馈通过在事件发生时的专门处理是不能有效得到的。只有通过使用一个结构化的、设计明确的信息安全事件处理管理方案，且该方案采用一个适用于组织所有部分的通用框架，才能更有效得到。这样的框架应该能使该方案持续产生更加全面的结果，从而可以在信息安全事件发生之前迅速识别信息安全事件可能出现的情况——有时，这也被称作“警报”。
信息安全事件管理方案的管理和审核应该能为促进组织员工的广泛参与，以及消除各方对保证匿名性、安全和有用结果的可用性等方面的担忧，奠定必要的信任基础。例如，管理和运行人员必须对“警报”能够给出及时、相关、精确、简洁和完整的信息充满信心。
组织应避免在实施信息安全事件管理方案的过程中可能遇到的问题，如缺少有用结果和对隐私相关问题的关注等。必须使利益相关人相信，组织已经采取措施预防这些问题的发生。
因此，为实现一个良好的信息安全事件管理方案，必须将一些关键问题阐述清楚，这些问题包括：

a) 管理层的承诺；
b) 安全意识；
c) 法律法规；
d) 运行效率和质量；
e) 匿名性；
f) 保密性；
g) 可信运行；
h) 系统化分类。

下面将逐一讨论这些问题。

6.2.1 管理层的承诺

要使整个组织接受一个结构化的信息安全事件管理方法，确保得到管理层的持续承诺，这一点至关重要。组织员工必须能够认识到事件的发生，并且知道应该采取什么行动，甚至了解这种事件管理方法可以给组织带来的益处。然而，除非得到管理层的支持，否则这一切都不会出现。必须将这一理念灌输给管理层，以使组织对事件响应能力的资源方面和维护工作做出承诺。

6.2.2 安全意识

对于组织接受一个结构化的信息安全事件管理方法而言，另一个重要的问题是安全意识。即使要求用户参与信息安全事件管理，但是用户如果不了解自己以及自己所在部门会从该结构化的信息安全事件管理中得到哪些益处，他们的参与很可能不会有太好效果。
任何信息安全事件管理方案都应该具有意识计划定义文件，并在文件中规定以下细节：

a) 组织及其员工可以从结构化的信息安全事件管理中得到的益处；
b) 信息安全事态/事件数据库中的事件信息及其输出；
c) 提高员工安全意识计划的战略和机制；根据组织的具体情况，它们可能是独立的，或者是更广泛的信息安全意识教育计划的一部分。

6.2.3 法律法规

以下与信息安全事件管理相关的法律法规问题应在信息安全事件管理策略和相关方案中进行阐述。

a) 提供适当的数据保护和个人信息隐私。一个组织结构化的信息安全事件管理，必须考虑到满足我国在数据保护和个人信息隐私方面的相关政策、法律法规的要求，提供适当的保护，其中
可能包括：
1) 只要现实、可行，保证可以访问个人数据的人员本身不认识被调查者；
2) 需要访问个人数据的人员在被授权访问之前，应签订不泄露协议；
3) 信息应被仅用于获取它的特定目的，如信息安全事件调查。

b) 适当保留记录。按国家相关规定，组织需要保留适当的活动记录，用于年度审计，或生成执法所用的档案（如可能涉及严重犯罪或渗透敏感政府系统的任何案件）。
c) 有防护措施以确保合同责任的履行。在要求提供信息安全事件管理服务的合同中，例如，合同中对事件响应时间提出了要求，组织应确保提供适当的信息安全，以便在任何情况下，这些责任都能得到履行。（与之相应，如果组织与某外部方签订了支持合同（参见7.5.4），如CERT，
那么，应该确保包括事件响应时间在内的所有要求均包含在与该外部方签订的合同中。）
d) 处理与策略和规程相关的法律问题。应检查与信息安全事件管理方案相关的策略和规程是否存在法律法规问题，例如，是否有对事件责任人采取纪律处罚和/或法律行动的有关声明。
e) 检查免责声明的法律有效性。对于有关信息事件管理组以及任何外部支持人员的行动的所有免责声明，均应检查其法律有效性。
f) 与外部支持人员的合同涵盖要求的各个方面。对于与任何外部支持人员（如来自某CERT）签订的合同，均应就免责、不泄露、服务可用性、错误建议的后果等要求进行全面检查。
g) 强制性不泄露协议。必要时，应要求信息安全事件管理组的成员签订不泄露协议。
h) 阐明执法要求。根据相关执法机构的要求，对需要提供的信息安全事件管理方案相关的问题，进行明确说明。如，可能需要阐明如何按法律的最低要求记录事件以及事件文件应保存多长时间。
i) 明确责任。必须将潜在的责任问题以及应该到位的相关防护措施阐述清楚。以下是可能与责任问题相关的几个例子：
1) 事件可能对另一组织造成影响（如泄露了共享信息），而该组织却没有及时得到通知，从而对其产生负面影响；
2) 发现产品的新脆弱性后没有通知供应商，随后发生与该脆弱性相关的重大事件，给一个或多个其他组织造成严重影响；
3) 按照国家相关法律法规，对于像严重犯罪，或者敏感的政府系统或部分关键国家基础设施被渗透之类案件，组织没有按要求向执法机关报告或生成档案文件；
4) 信息的泄露表明某个人或组织与攻击相关联。这可能会危害所涉及的个人或组织的声誉和业务；
5) 信息的泄露表明可能是软件的某个环节出了问题，但随后发现这并不属实。

j) 阐明具体规章要求。凡是有具体规章要求的地方，都应将事件报告给指定部门；
k) 保证司法起诉或内部处罚规程取得成功。无论攻击是技术性的还是物理的，都应采取适当的信息安全防护措施（其中包括可证明数据被篡改的审计踪迹），以便成功起诉攻击者或者根据内部规程惩罚攻击者。为了达到目的，就必须以法院或其他处罚机关所接受的方式收集证据。
证据必须显示：

1) 记录是完整的，且没有经过任何篡改；
2) 可证明电子证据的复制件与原件完全相同；
3) 收集证据的任何IT系统在记录证据时均运行正常。

l) 阐明与监视技术相关的法律问题。必须依照国家相关的法律阐明使用监视技术的目的。有必要让人们知道存在对其活动的监视，包括通过监控技术进行的监视行动，十分重要。采取行动时需要考虑的因素有：什么人/哪些活动受监视、如何对他们/它们进行监视以及何时进行监视。有关入侵检测系统中监视/监控活动内容的描述可参见ISO/IEC TR 18043。
m) 制定和传达可接受的使用策略。组织应对可接受的做法/用途做出明确规定、形成正式文件并传达给所有相关用户。例如，应使用户了解可接受的使用策略，且要求用户填写书面确认，表明他们在参加组织或被授予信息系统访问权时，了解并接受该策略。

6.2.4 运行效率和质量

结构化的信息安全事件管理的运行效率和质量取决于诸多因素，包括通知事件的责任、通知的质量、易于使用的程度、速度和培训。其中有些因素与确保用户了解信息安全事件管理的价值和积极报告事件相关。至于速度，报告事件所花费的时间不是唯一因素，还包括它处理数据和分发处理的信息所用的时间（尤其是在警报的情况下）。
应通过信息安全事件管理人员的支持“热线”来补充适当的意识和培训计划，以便将事件延迟报告的时间降至最低。

6.2.5 匿名性

匿名性问题是关系到信息安全事件管理成功的基本问题。应该使用户相信，他们提供的信息安全事件的相关信息受到完全的保护，必要时，还会进行相应处理，从而使这些信息与用户所在组织或部门没有任何关联——除非协议中有相关规定。
信息安全事件管理方案应该阐明这些情况，即必须确保在特定条件下报告潜在信息安全事件的人员或相关方的匿名性。各组织应做出规定，明确说明报告潜在信息安全事件的个人或相关方是否有匿名要求。ISIRT可能需要获得另外的、并非由事件报告人或报告方最初转达的信息。此外，有关信息安全事件本身的重要信息可从第一个发现到该事件的人员处获得。

6.2.6 保密性

信息安全事件管理方案中可能包含敏感信息，而处理事件的相关人员可能需要运用这些敏感信息。那么在处理过程中，或者信息应该是“匿名的”，或者有权访问信息的人员必须签订保密性协议。如果信息安全事态是由一个一般性问题管理系统记录下来的，则可能不得不忽略敏感细节。 此外，信息安全事件管理方案应该做出规定，控制将事件通报给媒体、业务伙伴、客户、执法机关和普通公众等外部方。

6.2.7 可信运行

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

6.2.8 系统化分类

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

3 定义通用系统化分类不是本标准的目的。读者可参考有关该信息的其他相关资源。

7 规划和准备

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

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

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

7.1 概述

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

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

4报告单由报告人填写（即不是由信息安全事件管理组成员填写）。
5信息安全事件管理人员使用报告单编写有关信息安全事态的初步报告，并保留事件评估等的运行记录，直至事件被完全解决。在每个阶段，都需更新信息安全事态/事件数据库。所填写的报告单/信息安全事态/事件数据库记录随后会用于事件的善后工作。
6如果可能，应将这些报告单制成电子表单（如在安全的web网页上），并且可与电子形式的信息安全事态/事件数据库链接。在当今世界上，基于纸质的方案耗时费力，不是效率最佳的运行方式。
7在规模较小的组织中，可指派一个人承担多个角色。

——在事先得到相关IT和/或业务管理层同意的特定情况下，关闭受影响的系统、服务和/或网络；
——保持受影响系统、服务和/网络的连接和运行；
——监视受影响系统、服务和/或网络的进出及内部数据流；
——根据系统、服务和/或网络安全策略启动常规备份和业务连续性规划规程及措施；
——监控和维护电子证据的安全保存，以备法律起诉或内部惩罚之用；
——将信息安全事件细节传达给内部和外部相关人员或组织。

c) 测试信息安全事件管理方案及其过程和规程的使用（参见7.3.5）；
d) 更新信息安全和风险分析及管理策略，以及具体系统、服务或网络的信息安全策略，包括对信息安全事件管理的引用，确保在信息安全事件管理方案输出的背景下定期评审这些策略（参见7.4）；
e) 建立ISIRT，并为其成员设计、开发和提供合适的培训计划（参见7.5）；
f) 通过技术和其他手段支持信息安全事件管理方案（以及ISIRT的工作）（参见7.6）；
g) 设计和开发信息安全事件管理安全意识计划（参见7.7）并将其分发给组织内所有员工（当有人员变更时重新执行一次）。

以下各节逐条描述了上述各项活动，其中包括所要求的每个文件的内容。

7.2 信息安全事件管理策略

7.2.1 目的

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

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的概述，围绕以下主题：
1) ISIRT的组织结构和关键人员的身份，其中包括由谁负责以下工作：

 

——向高级管理层简单说明事件的情况；
——处理询问、发起后续工作等；
——对外联系（必要时）。

2) 规定了ISIRT的具体工作以及ISIRT由谁授权的信息安全管理章程。章程至少应该包括ISIRT的任务声明、工作范围定义以及有关ISIRT董事会级发起人及其授权的详细情况；
3) 着重描述ISIRT核心活动的任务声明。要想成为一个真正的ISIRT，该小组应该支持对信息安全事件的评估、响应和管理工作，并最终得出成功的结论。该小组的目标和目的尤为重要，需要有清晰明确的定义；
4) 定义ISIRT的工作范围。通常一个组织的ISIRT工作范围应包括组织所有的信息系统、服务和网络。有的组织可能会出于某种原因而将ISIRT工作范围规定得较小，如果是这种情况，应该在文件中清楚地阐述ISIRT工作范围之内和之外的对象；
5) 作为发起者并授权ISIRT行动的高级执行官/董事会成员/高级管理人员的身份，以及ISIRT被授权的级别。了解这些有助于组织所有人员理解ISIRT的背景和设置情况，且对于建立对ISIRT的信任至关重要。应该注意的是，在这些详细信息公布之前，应该从法律角度对其进行审查。在有些情况下，泄漏一个小组的授权信息会使该小组的可靠性声明失效。
i) 信息安全事件管理安全意识和培训计划的概述；
j) 必须阐明的法律法规问题的总结（参见5.2.3）。

7.3 信息安全事件管理方案

7.3.1 目的

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

. 对信息安全事态作出响应；
. 确定信息安全事态是否为信息安全事件；
. 对信息安全事件进行管理，并得出结论；
. 总结经验教训，并确定方案和/或总体的安全需要改进的地方；
. 执行已确定的改进工作。

 

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/IEC TR 15947《IT入侵检测框架》和ISO/IEC TR 18043《选择、配置和操作IDS指南》；
j) 方案的组织结构；
k) 整个ISIRT及个人成员的授权范围和责任；
l) 重要的合同信息。

7.3.4 规程

在信息安全事件管理方案开始运行之前，必须有形成正式文件并经过检查的规程可供使用，这一点十分重要。每个规程文件应指明其使用和管理的负责人员，适当时来自运行支持组和/或ISIRT。这样的规程应包含确保电子证据的收集和安全保存，以及将电子证据在不间断监控下妥善保管以备法律起诉或内部处罚之需等内容。而且，应有形成文件的规程不仅包括运行支持组和ISIRT的活动，同时还涉及法律取证分析和“危机求助”活动——如果其他文件（如业务连续性计划）不包括这些内容的话。显然，形成文件的规程应该完全符合信息安全事件管理策略和其他信息安全事件管理方案文件。 需要重点理解的是，并非所有规程都必须对外公开。例如，并非组织内所有员工都需要了解了ISIRT的内部操作规程之后才能与之进行协作。ISIRT应该确保可“对外公开”的指南，其中包括从信息安全事件分析中得出的信息，以易于使用的方式存在，如将其置于组织的内部网上。此外，将信息安全事件管理方案的某些细节仅限于少数相关人员掌握可以防范“内贼”篡改调查过程。例如，如果一个盗用公款的银行职员对方案的细节很清楚，他或她就能更好地隐藏自身的行为，或妨碍信息安全事件的发现和调查及事件恢复工作的进行。

操作规程的内容取决于许多准则，尤其是那些与已知的潜在信息安全事态和事件的性质以及可能涉及到的信息系统资产类型及其环境相关的准则。因此，一个操作规程可能与某一特定事件类型或实际上与某一类型产品（如防火墙、数据库、操作系统、应用程序）乃至具体产品相关联。每个操作规程都应清楚注明需要采取哪些步骤以及由谁执行。它应该是外部人员（如政府部门和商业CERT或类似组织，以及供应商等）和内部人员的经验的反映。
应有操作规程来处理已知类型的信息安全事态和事件。但还应有针对未知类型信息安全事态或事件的操作规程。用于针对此种情况的操作规程需阐明以下要求：

. 处理这类“例外”的报告过程；
. 及时得到管理层批准以免响应延迟的相关指南；
. 在没有正式批准过程的情况下预授权的决策代表。

 

7.3.5 方案测试

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

7.4 信息安全和风险管理策略

7.4.1 目的

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

. 描述信息安全事件管理——尤其是信息安全事件报告和处理方案——的重要性；
. 表明高级管理层针对适当准备和响应信息安全事件的需要，对信息安全事件管理方案作出的承诺；
. 确保各项策略的一致性；
. 确保对信息安全事件作出有计划的、系统的和冷静的响应，从而将事件的负面影响降至最低。

 

7.4.2 内容

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

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

 

并明确指定负责授权和/或执行某些关键行动的人员（如切断信息系统与网络的连接或甚至将其关闭）。
此外，策略应要求建立适当的评审机制，以确保从信息安全事件发现、监视和解决过程中得出的任何信息可被用于保证总体信息安全和风险管理以及具体系统、服务或网络的信息安全策略的持续有效。

7.5 ISIRT的建立

7.5.1 目的

建立ISIRT的目的是为评估和响应信息安全事件并从中总结经验教训等工作提供具备合格人员的组织结构，并提供这方面工作所必要的协调、管理、反馈和沟通。ISIRT不仅可以降低信息安全事件带来的物理和经济损失，还能降低可能因信息安全事件而造成的组织声誉损害。

7.5.2 成员和结构

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

ISIRT成员应该便于联系，因此，每个成员及其备用人员的姓名和联系方式都应该在组织内进行登记。例如，一些必要的细节应清晰记入信息安全事件管理方案的文件中，包括规程文件和报告单，但可以不在策略声明文件中有所记载。
ISIRT管理者应：

. 指派授权代表以对如何处理事件做出立即决策；
. 通常有一条独立于正常业务运行的专线用于向高级管理层报告情况；
. 确保ISIRT全体成员具有必需的知识和技能水平，并确保他们的知识和技能水平可以得到长期保持；
. 指派小组中最适合的成员负责每次事件的调查工作。

 

7.5.3 与组织其他部门的关系

ISIRT管理者及成员必须具有某种等级授权，以便采取必要措施响应信息安全事件。但是，对于那些可能给整个组织造成经济上或声誉上的负面影响的措施，则应得到高级管理层的批准。为此，在信息安全事件管理策略和方案中必须详细说明授予ISIRT组长适当权限，使其报告严重的信息安全事件。
应对媒体的规程和责任也应得到高级管理层批准并形成文件。这些规程应规定：

. 由组织中哪个部门负责接待媒体；
. 该部门如何就这一问题与ISIRT相互交换信息。

7.5.4 与外部方的关系

ISIRT应与外部方建立适当关系。外部方可能包括：

. 签订合同的外部支持人员，如来自CERT；
. 外部组织的ISIRT或计算机事件响应组，或CERT；
. 执法机关；
. 其他应急机构（如消防队/部门等）；
. 相关的政府部门；
. 司法人员；
. 公共关系官员和/或媒体记者；
. 业务伙伴；
. 顾客；
. 普通公众。

7.6 技术和其他支持

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

. 访问组织资产（最好使用最新的资产登记簿）的详细情况，并了解它们与业务功能之间关联方面的信息；
. 查阅业务连续性战略及相关计划文件；
. 文件记录和发布的沟通过程；
. 使用电子信息安全事态/事件数据库和技术手段快速建立和更新数据库，分析其中的信息，以便于对事件作出响应（不过应该认识到，组织偶尔会有要求或使用手工记录的情况）；
. 为信息安全事态/事件数据库做好充分的业务连续性安排。

 

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

. 快速获得信息安全事态和事件报告；
. 通过适当方式（如电子邮件、传真、电话等）通知已事先选定的人员（以及相关外部人员），
因而要求对可靠的联系信息数据库（它应该是易于访问的，同时还应包括纸质文件和其他备
份），以及适当时以安全方式将信息发送给相关人员的设施进行维护；
. 对已评估的风险采取适当的预防措施，以确保电子通信（无论是通过互联网的还是不通过互联网的），不会在系统、服务和网络遭受攻击时被窃听；
. 对已评估的风险采取适当的预防措施，以确保电子通信（无论是通过互联网的还是不通过互联网的），在系统、服务和网络遭受攻击时仍然可用；

. 确保收集到有关信息系统、服务和/或网络的所有数据以及经过处理的所有数据；
. 如果根据已得到评估的风险采取措施，利用通过加密的完整性控制措施可帮助确定系统、服务和/或网络以及数据是否发生了变动以及它们的哪些部分发生了变动；
. 便于对已收集信息的归档和安全保存（例如在日志和其他证据离线保存在CD或DVD ROM等只读介质中之前对其使用数字签名）；
. 准备将数据（如日志）打印输出，其中包括显示事件过程、解决过程和证据保管链的数据；

. 根据相关业务连续性计划，通过以下方式将信息系统、服务和/或网络恢复正常运行：

——良好的备份规程；
——清晰可靠的备份；
——备份测试；
——恶意代码控制；
——系统和应用软件的原始介质；
——可启动介质；
——清晰、可靠和最新的系统和应用程序补丁。
一个受到攻击的信息系统、服务或网络可能无法正常运转。因此，只要可能，并考虑到已受评估的风险，响应信息安全事件必需的任何技术手段（软件和硬件）都不应依赖于组织的 “主流”系统、服务或网络的运行。如果可能，它们应该完全独立。
所有技术手段都应认真挑选、正确实施和定期测试（包括对所做备份的测试）。
应指出的是，本节所描述的技术手段不包括那些用来直接检测信息安全事件和入侵并能自动通知相关人员的技术手段。有关这些技术内容的描述可参见ISO/IEC TR 15947《入侵检测框架》以及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一般来说，不要期望运行支持组人员就是安全专家。

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

. 以适当的人员级别分配事件管理活动的职责，包括专职安全人员和非专职安全人员的评估、决策和行动；
. 制定每个被通知人员均需遵守的正式规程，包括评估和修改报告，评估损害，以及通知相关人员（至于每个人的具体行动由事件的类型和严重程度来决定）；
. 使用指南来完整地将一个信息安全事态记入文件，如果该事态被归类为信息安全事件，那随后采取的行动也应记入文件，并更新信息安全事态/事件数据库。

指南涉及：

. 8.3讨论的信息安全事态发现和报告；
. 8.4讨论的评估和决策（确定是否应将信息安全事态归类为信息安全事件）；
. 8.5讨论的对信息安全事件的响应，包括：

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

8.3 发现和报告

信息安全事态可以被由技术、物理或规程方面出现的某种情况引起注意的一人或多人发现。例如，发现可能来自火/烟探测器或者入侵（防盗）警报，并通知到预先指定位置以便有人采取行动。技术型的信息安全事态可通过自动方式发现，如由审计追踪分析设施、防火墙、入侵检测系统和防病毒工具在预设参数被激发的情况下发出的警报。
无论发现信息安全事态的源头是什么，得到自动方式通知或直接注意到某些异常的人员要负责启动发现和报告过程。该人员可以是组织内任何一名员工，无论是正式员工还是合同工。该员工应遵照相关规程，并使用信息安全事件管理方案规定的信息安全事态报告单在第一时间把信息安全事态报告给运行支持组和管理层。因此，所有员工要十分了解并且能够访问用于报告各种类型的可能的信息安全事态的指南——其中包括信息安全事态报告单的格式以及每次事态发生时应该通知的联系人的具体信息，这一点至关重要。（所有人员至少要知晓信息安全事件报告单的格式，这有助于他们理解信息安全事件管理方案。）
如何处理一个信息安全事态取决于该事态的性质以及它的意义和影响。对于许多人来说，这种决定超出了他们的能力。因此，报告信息安全事态的人员应尽量使用叙述性文字和当时可用的其他信息完成信息安全事态报告单，必要的话，与本部门管理者取得联系。报告单最好是电子格式的（例如以电子邮件或web表单的方式提交），应该安全地发送给指定的运行支持组（它最好应提供7×24h服务），并将一份拷贝