1、汲取经验
学习和改进是安全事件响应中最重要也是最经常被忽略的部分。每个安全事件响应小组都应该不断进步以应对新的威胁、适应新的技术并汲取经验教训。许多组织都发现在发生严重安全事件后和各相关方面共同举办一次“经验汲取”会议，对改善安全措施以及安全事件处理过程本身是非常有帮助的。这类会议通过回顾发生何种事件、采取了何种活动来解决问题以及解决程度如何等提供一次机会来给安全事件作出结论。这类会议应该在安全事件发生后的几天内举行。在会议中要回答的问题有：
●到底发生了什么安全事件，在什么时间发生的？
●在安全事件处理中员工和管理人员的表现如何？是否遵循了书面流程？是否充分？
●哪些信息是最迫切需要的？
●是否有任何所采取的措施会影响恢复工作？
●如果下次发生同类安全事件，员工和管理层需要有哪些改进？
●可以采取哪些纠正措施来防止未来同类安全事件的发生？
●还需要哪些工具来对未来安全事件进行检测、分析和减缓？
对小的安全事件要进行有限的安全事件后分析，同时要想到那些通过影响比较大的新攻击方法所展开的攻击。在发生了严重攻击后，往往都值得召开一次事后会议，该会议应该超越小组和机构边界，提供一种信息共享机制。召开此类会议中一个主要的考虑是要保证合适的人员参加。不仅仅是要邀请那些已经涉足被分析事件的人员，而且也要考虑邀请那些对将来合作有帮助的人。
这类会议是否能成功还取决于会议的日程安排。在会议之前，收集参与人员的期望和需求（包括被提议要讨论的话题）可以使参与人员的需求得到满足的可能性提高。此外，在会议开始之前或过程中确定好顺序规则可以将混乱降低到最小。安排一个或多个经验丰富的调解人员可以产生很好的效果。最后，要记录协议主要点和活动项目，并通报给那些没有参加会议的方面。
经验汲取会议还有其它的好处，这些会议的报告是培训新小组成员的极佳材料，告诉他们那些经验丰富的小组成员是如何对安全事件作出响应的。对安全事件响应政策和流程进行更新是经验汲取过程的另一个重要方面。对安全事件处理方式的事后分析常常能暴露遗漏的步骤或某个流程中的不当之处，并成为变更的推动力。因为信息技术性质的变更和人员的变更，安全事件响应小组应该每隔一段指定时间检查所有的安全事件处理相关文档和流程。
另一个重要的安全事件后活动是针对每个安全事件创建一个随后的报告，这对将来使用非常有用。首先，该报告提供了一个参考，用于协助处理类似安全事件。创建一个正式的事件年表（包括像系统日志信息这样的时间戳信息）也是出于很重要的法律原因，如同为由于软件和文件丢失、硬件破坏以及人员成本而带来的损失进行金钱方面的估计。这些估计可能作为日后像美国总检查长办公室等实体进行起诉活动的基础。后续报告应该按照记录保存政策中所规定的时间进行保存。
2、使用收集到的数据
经验汲取活动应该产生与每个安全事件相关的一套主观和客观数据。一段时间后，这些被收集的安全事件数据应该在多个方面都有用。这些数据，尤其是事件总耗费时间和成本可能会被用来说明安全事件响应小组额外资金的合理性。安全事件特征研究可能会揭示出系统安全弱点和威胁，以及安全趋势的变化。这些数据也可以反馈会风险评估过程中，并最终指引着对补充安全控制的选择和实现。对这些数据的另一种善加利用的方法是对安全事件响应小组的成功加以度量。如果安全事件数据得以适当收集和存放，它应该提供几种对安全事件响应小组成功性（或至少是活动）的度量方法。进一步说，那些被要求对安全事件信息进行报告的组织（比如像联邦机构）要收集必要的数据来满足其要求。
组织在收集数据的时候应该着重于收集那些对提起诉讼有用的数据，而不是仅仅因为数据可以获得就收集它们。比如，对每周发生的预端口扫描次数进行计数，并在年末产生一张图表显示端口扫描增长了八个百分点，这类活动没有多大意义，而且十分浪费时间。数据本身不能提供任何信息，了解它们如何对组织的业务过程形成威胁才是重要的。组织应该根据报告要求和预期投资回报来决定收集什么样的安全事件数据（比如在相关弱点被利用之前识别新的威胁并减缓它们），与安全事件相关的可能度量包括：
●所处理安全事件的数量 处理的安全事件数量多并不一定更好，比如因为采用了更好的网络和主机安全控制而不是因为安全事件响应小组忽视，使得所处理的安全事件数量减少。处理安全事件的数是对安全事件响应小组工作量的最好度量，而不是对小组工作质量的度量。针对每个安全事件分类（如未经授权的访问）生成单独的安全事件计数要更有效些。也可以利用子分类来提供更多的信息。比如，由内部人员发起的未经授权的访问安全事件可能促使在人员背景调查和计算资源滥用方面更强的政策规定，并对内部网络采取更强的安全控制（如对更多的内部网络和主机采取入侵检测软件）。
●每个安全事件所耗费时间 对每个安全事件，可以用几种方式来度量其时间：
▲在处理安全事件中所花费的总劳动量；
▲从安全事件发生到处理完毕的时间；
▲安全事件处理过程中的每个阶段的时间；
▲从安全事件响应小组作出响应到提交最初的安全事件报告用了多长时间。
●对安全事件的客观评估 对已解决安全事件所作出的响应可以加以分析，以确定其效果如何。以下是一些对安全事件进行客观评估的例子：
▲对安全事件日志、表格、报告以及其它安全事件文档进行检查，看是否符合已经建立的安全事件响应政策和流程；
▲确认安全事件的哪些前兆和迹象被记录了下来，从而确定安全事件如何被有效地记入日志了；
▲确定安全事件在被发现前是否已经产生了破坏；
▲确定安全事件的真正起因是否已被找到；
▲计算安全事件所带来的金钱损失；
▲确定采取哪些措施（如果有的话）可以预防这类安全事件。
●对安全事件的主观评估 安全事件响应小组成员可能会被要求对其自己的以及其他成员和整个小组的绩效进行评估；另一个有价值的输入源是被攻击资源的拥有者，用来确定拥有者是否认为安全事件已得到有效处理，以及结果是否令人满意。
除了采用这些测度方法来对小组是否成功进行度量外，组织还会发现定期对其安全事件响应项目进行审计非常有用。通过审计可以发现问题和缺陷，然后加以纠正。最低限度上，安全事件响应审计应该依据现有的适用条例、政策及最佳实践对以下项目进行评价：
●安全事件响应政策和流程；
●工具和资源；
●小组模式和结构；
●安全事件处理人员培训和教育；
●安全事件文档和报告；
●本节前面所讨论的对成功与否的度量。
3、证据保存
组织应该建立安全时间证据应该保存多长时间的政策。多数组织选择在安全事件结束后将所有证据保存几个月或几年。在创建政策过程中应该考虑以下因素：
●起诉 如果对攻击者进行起诉是可能的，那么可能需要对证据加以保存，直到所有的法律动作结束为止。有些情况下，这可能会经历几年时间。而且现在看起来没有意义的证据可能在将来变得非常重要。比如，如果攻击者能够根据从一次攻击中收集到的知识又发起更为严重的攻击，那么来自第一次攻击的证据在解释第二次攻击是如何实现时就非常关键。
●数据保存 多数组织都有数据保存政策，规定某些类型的数据要保存多久。比如，某个组织规定电子邮件消息最多保存180天。如果磁盘映像中包含几千封电子邮件，组织可能不希望此映像的保存期超过180天，除非确实有必要。一般记录时间表（GSR）24规定安全事件处理记录应该保存三年。
●成本 作为证据存放的原始硬件（如硬盘、遭破坏系统）以及用来保存磁盘映像的硬盘和其它设备对多数组织来讲都不贵。但是，如果组织常年保存着大量这种设备，那成本就高了。组织还必须保留专门的计算机，可以使用这些被保存的硬件（如硬盘）和介质（如备份磁带）；一旦所存放证据不能被读出，那么它也就失去它的价值了。
4、安全事件处理核对表
表1中的核对表给出了在安全事件初期处理过程中的主要步骤。表中的各项仅提到了对安全事件的检测和分析；在这些完成之后，安全事件处理人员应该使用核对表来配合特定类型的安全事件。表2中针对不属于任何一个分类的安全事件处理给出了一个一般性核对表。
要注意实际步骤可能会随被处理安全事件类型及每个事件的性质而不同。比如，如果安全事件处理人员通过对迹象进行分析（表1，步骤1.1）。核对表在应该执行的主要步骤上为安全事件处理人员提供了一个指南。这并不意味着总是要遵循严格的步骤顺序。
表1 初期安全事件处理核对表
|
动作 |
完成 |
|
|
检测与分析 |
||
|
1 |
确认是否发生安全事件 |
|
|
1.1 |
分析安全事件的前兆和迹象 |
|
|
1.2 |
寻找相关信息 |
|
|
1.3 |
展开搜索（比如通过搜索引擎、知识库等） |
|
|
1.4 |
一旦安全事件处理人员相信发生了安全事件，开始对调查进行记录并收集证据 |
|
|
2
|
根据类别（比如拒绝服务攻击、恶意代码、未经授权访问、不当使用、复合型安全事件）对安全事件进行分类 |
|
|
3
|
遵循适当的安全事件分类核对表；如果安全事件不属于任何一个类别，遵循一般性核对表 |
|
5、建议
下面对本节关于安全事件处理的主要建议做一个总结：
●获取在安全事件处理中可能有价值的工具和资源 如果安全事件响应小组拥有各种工具和资源，那么他们就能更为有效地处理安全事件。这些工具和资源比如有：联系簿、加密软件、网络图、备份设备、计算机犯罪取证软件、端口列表及安全补丁。
●通过保证网络、系统以及应用充分安全来预防安全事件的发生 预防安全事件不但对组织有好处，而且可以减少安全事件响应小组的工作负担。开展定期风险评估并将已知风险降低到可接受的程度对减少安全事件的数量非常有效。用户、IT人员及管理层对安全政策和流程的意识也是很重要的。
●通过不同类型计算机安全软件产生的报警来识别前兆和迹象 基于网络和主机的入侵检测系统、反病毒软件及文件完整性检测软件都可以对事件的征兆进行检测。每种软件都可以检测到其它类型软件所无法检测到的安全事件。所以，建议同时使用多种计算机安全软件。第三方的监视服务也是很有用的。
●为外部组织报告安全事件建立相关机制 有些外部组织希望将安全事件报告给本组织；比如他们可能认为组织内部有人对他们进行攻击。组织应该公布一个电话号码及电子邮件地址，使外部组织能通过它们来报告安全事件。
●在所有系统中建立日志和审计的基线级别，并在关键系统上建立更高的基线级别 操作系统、服务和应用中的日志往往在安全事件分析中提供帮助，尤其是如果启动了审计功能时。日志可以提供许多重要的信息，比如哪些帐号曾经被访问过以及做过了什么动作。
●描述网络和系统的特征 特征描述对预期行为级别的特征进行度量，使得模式发生变化时能更容易被发现。如果特征描述过程是自动方式的，那么预期行为级别的偏差就能被迅速检测并报告给管理人员，从而更快速地检测到安全事件和运行中发生的问题。
●了解网络、系统以及应用的正常活动 对正常活动有了解的小组成员应该能够更容易发现异常活动。获得这种知识的最佳途径是对日志项和安全报警进行检查；事件处理人员应该熟知典型数据并能够对异常项目进行调查，从而获取更多的知识。
●使用集中式日志并制定日志保存政策 与安全事件相关的信息可能被记录在几个地方。组织应该采用集中式日志服务器，并对各个设备加以配置，将其日志项副本发送到中央服务器上。这对小组有好处，因为他们可以一次就访问到所有日志项，而且对单台主机上的日志进行改动不会影响那些已经发给中央服务器的数据。日志保存政策非常重要，因为旧的日志项可能显示以前的类似事例或相关活动。
●开展事件关联 某个安全事件的迹象可能被几个日志捕获到，在对收集安全事件所有可获得信息并证实是否发生安全事件时，在多个来源之间对事件进行关联可能有非常重要的作用。集中式日志使事件关联更加容易和快捷。
●保持所有主机的时钟同步 如果报告事件的设备时钟不一致，事件关联就非常困难。时钟差异还会产生证据有效性问题。
●维护和使用信息知识库 在事件分析过程中，安全事件处理人员需要快速引用信息。集中式的知识库提供了一个一致性的、可维护的信息来源。知识库应该包括一般性信息，比如常用端口号以及到病毒信息的连接、历史安全事件的前兆和迹象数据。
●为缺少经验的员工建立一张诊断矩阵表 咨询台人员、系统管理员及新来的安全事件响应小组成员在确定可能发生什么类型的安全事件时可能需要求得帮助。诊断矩阵中列出了安全事件分类以及与每个分类相关的症状，它可以在确定发生何种类型的安全事件以及如何证实安全事件方面提供指南。
●一旦安全事件响应小组怀疑发生了事件发生时，立即开始记录全部信息 对从安全事件被检测到最终解决全过程中所采取的每一个步骤都应该进行记录，并标明时间。因为，如果需要诉诸法律，这些都将成为呈堂证供。对所采取的步骤加以记录还可以使问题的处理更加有效率、系统化，并且可以减少出错的几率。
●保护安全事件数据 安全事件数据可能包括像安全弱点、安全违规及可能进行了不适当操作的用户等敏感信息。小组应该确保对安全事件数据的访问无论是逻辑上还是物理上都要严格适当。
●基于受影响资源和关键性以及安全事件的技术影响，根据业务影响对安全事件进行优先级排序 由于受资源的限制，对安全事件不能按照先来先处理的方式进行处理。相反，组织应该建立书面指南，描述基于安全事件当前及潜在的业务影响，小组必须如何快速地对安全事件作出响应并应该采取什么行动。这种指南节省了安全事件处理人员的时间并向管理层和系统拥有者提供了他们所采取行动的依据。组织应该为那些小组不能在指定时间内对安全事件作出响应的情形建立一个事件升级过程。
●在组织的安全事件响应政策中包含安全事件报告相关规定 组织应该规定哪些安全事件必须报告、何时报告以及报告给谁。最常要通知到的对象CIO（首席信息官）、负责信息安全的领导、本地信息安全官员、组织内部的其它安全事件响应小组以及系统拥有者。
●建立政策和流程对安全事件进行限制 要迅速有效地控制安全事件，以限制其带来的业务影响。组织应该对可接受的风险进行定义，以此限制安全事件并改进安全政策和流程。安全事件的限制策略应根据安全事件类型的不同而不同。
●遵循已建立的流程来收集和处理证据 小组应该清晰记录证据是如何得以保存的对证据应该随时都能加以解释。小组应该同法律人员和执法人员碰头，就证据处理问题进行讨论，并根据讨论结果制定流程。
●从系统中捕获易失性数据作为证据 这包括网络连接清单、进程、登录会话、被打开文件、网络端口配置及内存内容。仔细运行从可信介质中选择的指令，可以在不损坏系统证据的情况下收集必要的信息。
●通过完整的取证磁盘映像而非文件系统备份来获取系统的即时快照信息 应该在经过清理的写保护或一次性写介质上制作磁盘映像。对于调查和取证目的来讲，这个过程要优于文件系统备份。制作映像是有好处的，因为对映像进行分析要比在原始设备上进行分析安全的多，因为它不会改变原始内容。
●在重大安全事件结束后举行经验汲取会议 在改进安全措施和安全事件处理过程本身方面，经验汲取会议非常重要。
文章来源： 摘自 NIST Special Publication 800-61
发布单位： 北京交通大学信息安全体系机构研究中心