信息安全事件管理v2.0

GB/Z ××××—××××

以下内容的更多信息：

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

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

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

? 它是否属于重大事件（根据组织预先制定的事件严重性衡量尺度）； ? 到目前为止它是如何被处理的。 如果信息安全事件已被解决，报告应包含已经采取的防护措施的详细情况和其他任何经验教训（例如用来预防相同或类似事件再次发生的进一步防护措施）。被更新的报告应该添加到信息安全异常现象/事件数据库中，并通报ISIRT管理者和其他必要人员。

应该强调的是，ISIRT负责妥善保管与信息安全事件相关的所有信息，以备鉴别分析和可能在法庭上作证据之用。例如一个针对IT的信息安全事件，在最初发现事件后，应该在受影响的IT系统、服务和/或网络关闭之前收集所有只会短暂存在的数据，为完整的法律取证调查作好准备。需要收集的信息包括内存、缓冲区和注册表的内容以及任何过程运行的细节，以及：

? 根据信息安全事件的性质，对受影响的系统、服务和/或网络进行一次完整复制，或对日志和

重要文件进行一次低层备份，以备法律取证之用；

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

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

的；

? 用来进行法律取证复制的工具和命令的规范和说明书均应登记归档，并与原始介质一起保存。 在这一阶段如果可能的话，ISIRT成员还要负责将受影响设施（IT设施或其他设施）恢复到不易遭受相同攻击破坏的安全运行状态。 8.5.1.4 进一步的活动

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

? 向负责对内对外沟通的人员通报情况，同时建议应该以什么形式向哪些人员报告什么内容。 一旦尽力完成信息安全事件报告后，应将其输入信息安全异常现象/事件数据库并送达ISIRT管理者。

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

基于信息安全事件管理方案文件提供的指南，负责评估信息安全事件的ISIRT人员应该了解： ? 何时必须将问题上报以及应该向谁报告；

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

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

? 得出信息安全事件属于严重事件的结论； ? 确定出现了“危机”情况时，

应在第一时间将信息安全事件通过人、电话或文本方式报告给相关人员。

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

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

在ISIRT成员作出立即响应，并进行了法律取证分析和通报相关人员后，必须迅速得出信息安全

24

GB/Z ××××—××××

事件是否处于控制之下的结论。如果需要，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系统、语音通信、人员和食宿供应的最长可承受中断时间直接关联。业务连续性战略应该明确标明所要求的：

? 预防、恢复和业务连续性支持措施； ? 管理业务连续性规划的组织结构和职责； ? 业务连续性计划的体系结构和概述。

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

其他可能类型的“危机求助”行动包括（但不限于）启用：

25

GB/Z ××××—××××

? 灭火设施和撤离规程；

? 防洪设施和撤离规程；

? 爆炸“处理”及相关撤离规程； ? 专家级信息系统欺诈调查程序； ? 专家级技术攻击调查程序。 8.5.5 法律取证分析

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

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

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

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

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

? 确保目标系统、服务和/或网络在法律取证分析过程中受到保护，防止其变得不可用、被改变

或受其他危害（包括病毒入侵），同时确保对正常运行的影响没有或最小；

? 对“证据”的“捕获”按优先顺序进行，也就是从最易变化的证据开始到最不易变化的证据

结束（这在很大程度上取决于信息安全事件的性质）；

? 识别主体系统、服务和/或网络中的所有相关文件，包括正常文件、看似（但并没有）被删除

的文件、口令或其他受保护文件和加密文件； ? 尽可能恢复已发现的被删除文件和其他数据；

? 揭示IP地址、主机名、网络路由和Web站点信息；

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

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

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

26

GB/Z ××××—××××

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

? 如果可行，分析物理证据，如查看指纹、财产损害程度、监视录像、警报系统日志、通行卡

访问日志以及会见目击证人等；

? 确保所提取的潜在证据被妥善处理和保存，使之不会被损害或不可使用，并且敏感材料不会

被未授权人员看到。应该强调的是，收集证据的行为要遵守相关法律的规定；

? 总结信息安全事件的发生原因以及在怎样的时间框架内采取的必要行动，连同具有相关文件

列表的证据一起附在主报告中；

? 如果需要，为内部惩罚或法律诉讼行动提供专家支持。 所采用的方法应该记录在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 经验教训

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

? 新的或改变的信息安全防护措施需求。可能是技术或非技术（包括物理）的防护措施。根据

27