计算机安全事件处理指南（二）：检测和分析[译文?]

图1：安全事件响应生命周期（检测和分析）

1、安全事件分类

    安全事件的发生的方式多种多样，所以想要制定一个具体的综合流程来处理每一件安全事件是不切实际的。组织能做的最好程度就是从总体上准备处理任何类型的安全事件，对常见安全事件类型的处理则更具体一些。下面所列出的安全事件分类既不是包罗一切的，也不打算为安全事件给出明确的分类，相反，它只给出了一个基本指南来指导如何根据其主要分类来处理安全事件。

    下面的事件分类列表并不全面，因为这并不是为了对所有的安全事件进行定义和分类，而仅是为了给大家一个初步的概念来指导大家如何根据事件的不同类型去处理事件：

    拒绝服务攻击：一种攻击，通过消耗资源的方式来阻止和破坏对网络、系统或应用经过授权的使用。

    恶意代码：能够感染主机的病毒、蠕虫、特洛伊木马或其它基于代码的恶意实体。

    未经授权访问：一个人在未经允许的情况下通过逻辑的或物理的方式访问网络、系统、应用、数据或、其它资源。

    不当使用：用户违反可接受计算资源使用政策。

    复合型安全事件：一个单一安全事件中包含两种或是两种以上的安全事件。
此外，有些安全事件可以对应以上多个分类。安全事件响应小组可以根据其传送机制对安全事件进行分类，比如：

 一个病毒在系统中创建了一个后门，那我们应该把它当作恶意代码安全事件来处理，而不是未经授权访问安全事件，因为恶意代码是唯一用到的传送机制。

 如果一个病毒创建的后门已经被用于未经授权访问，那么这个事件应该被当作复合型安全事件来处理，因为它用到了两个传送机制。
本节主要是针对各种安全事件提出建议实践，后文基于安全事件分类给出了更为具体的建议。

2、事件征兆

    对于很多组织来说，安全事件响应过程中最困难的一步是准确检测并评估可能的安全事件，即确定一个安全事件是否会发生，如果发生，那它属于什么类型、影响程度如何以及问题的范围。造成这一点很困难主要有以下3个因素：

    ●安全事件可以通过很多不同的方法来检测，并获得不同程度的细节和真实性自动化检测能力有基于网络的和基于主机的入侵检测系统、反病毒软件以及日志分析工具。也可以通过人工方法来检测安全事件，比如用户报告的问题。有些安全事件有隐含的征兆，可以很容易被检测到，而有些如果没有自动工具几乎无法检测到。

    ●安全事件的潜在征兆数量一般都很高，比如组织每天受到上千甚至百万条入侵检测传感器报过来的告警信息并不少见。

    ●对与安全事件相关的数据进行正确而有效的分析往往需要高水平的专业知识和丰富的实践经验。多数组织内，具备这些条件的人很少，并且一般都可能分配到其它工作中去了。

    安全事件的征兆可以分为两类：迹象(indication)和前兆(precursor)。前兆是指未来可能发生的安全事件的征兆，而迹象是指已经发生或正在发生的安全事件的征兆。迹象的种类太多，以至于无法一一介绍，以下是其中一些例子：

 ●某台FTP服务器发生缓冲区溢出时网络入侵检测传感器报警；

 ●反病毒软件发现某台主机被蠕虫感染时发出告警；

 ●WEB服务器崩溃；

 ●用户抱怨上网太慢；

 ●系统管理员发现文件名有不寻常字符；

 ●用户想求助台报告收到恐吓邮件；

 ●某主机记录其日志中的审计配置发生变化；

 ●某应用程序的日志记载了来自未知远程系统的多次失败登录尝试；

 ●邮件管理员发现有大量可疑内容邮件流入。

 ●网络管理员发现网络流量发生不寻常变化。

   不要认为安全事件检测只是一种反应式的，有时候组织也可能在安全事件发生之前就检测到有关行为。比如网络入侵检测传感器发现针对一组主机的不寻常端口扫描活动，这很可能就是对某台主机发起拒绝服务攻击的前兆。以下是其它一些有前兆的例子：

 ●WEB服务器日志显示，有人使用WEB服务器弱点扫描工具；

 ●公开针对组织邮件服务器弱点的一种新黑客攻击；

 ●某黑客组织声称要攻击该组织。

    不是所有的攻击都可以通过前兆检测到，有的攻击没有前兆，有的攻击前兆则很难被组织发现的。如果在攻击之前发现前兆，那么该组织还有机会通过采用自动或人工方法来改变其安全生态来预防安全事件发生。但是大多数严重情况下，组织可能要确定采取行动，就像已经发生了安全事件，从而尽快减缓风险。很少情况下，组织可以密切监视某些活动，可能是针对特定主机的连接企图或某些网络流量类型。

 

3、前兆和迹象的来源

    可以通过许多不同的来源来检测前兆和迹象，最常用的有计算机安全软件的告警、日志、公共渠道获取的信息及人。表2列出了每种分类常见的前兆和迹象来源。

表2前兆和迹象的常见来源

前兆和迹象

来源

描述

计算机软件告警

基于网络和主机的入侵检测系统

入侵检测系统就是设计来识别可疑事件并记录相关数据，包括攻击被检测到的日期和时间、攻击类型、攻击来源和目的的IP地址以及用户名（如果可能获得的话）。多数入侵检测系统使用攻击特征库来识别恶意活动，必须要保持更新特征库，从而能检测到最新的攻击。入侵检测系统经常产生误报，即报警有恶意活动发生，但是实际上没有。分析人员应该通过仔细检查记录数据或从其它来源获得相关数据来对入侵检测系统的告警进行人工验证。

反病毒软件

通常在检测到恶意代码后，反病毒软件就会向被感染主机和中央反病毒控制台发送告警信息。只要保持病毒特征码不断更新升级，目前的反病毒产品能非常有效地检测、查杀或是隔离恶意代码。但是在大型组织中升级特征码是非常繁重的任务。一种解决办法是配置集中式反病毒软件，采用推的方式将特征码升级到各个主机上，而不是靠拉的方式让各主机自己升级。由于不同反病毒软件的检测效果各异，有的组织为了能够提高反病毒的覆盖面和精确度，通常都会使用多种反病毒软件。至少应该在两个层次采用反病毒软件：网络边界（比如防火墙、邮件服务器）和主机层次（比如工作站、文件服务器、客户端软件）。

文件完整性检测软件

安全事件可能导致重要文件被修改；文件完整性检测软件可以检测到这些变化。它通过一种hash算法来获取目标文件的加密校验和。如果文件被修改或校验和被重新计算过，新旧校验和极可能不会匹配，通过这样就可以检测到文件被修改过。

第三方监视服务

有的组织花钱请即第三方监视其公众可访问服务，比如WEB、DNS及FTP服务器。这些第三方组织每隔几分钟就会自动尝试访问这些服务。一旦无法访问，他们就会通过业主指定的方式向业主发出警报，比如通过电话、传呼以及电子邮件等方式。有的监视服务还会检查某些特定资源是否被篡改并发出告警，比如网站主页。尽管从运行的角度来看监视服务非常有用，但是它还可以被用来检测拒绝服务攻击和服务器破坏。

日志

操作系统，服务和应用软件的日志

在事件发生时，来自操作系统、服务以及应用（尤其是审计相关数据）的日志通常是非常有价值的。日志可以提供诸如哪些帐号曾经登录过、登录之后都做过什么事情等很多有价值的信息。但不幸的是，在大多数事件中，因为被禁用或错误配置，日志并没能提供出证据。为帮助事件处理组织应该在所有系统上要求一个日志基线级别，并且在关键系统上要求更高的日志基线级别。所有系统都应该打开审计功能并记录审计事件，尤其是管理员级别的事件。对所有系统都要定期检查，以验证日志的功能一切正常并符合日志标准。

网络设备日志

网络设备（比如防火墙、路由器）的日志一般都不用作安全事件前兆和迹象的首要来源。尽管这些设备通常都记录了对连接请求的阻断，但它们很少提供有关活动性质方面的信息。即便如此，在确定趋势（比如企图访问特定端口的数量急剧增加）以及在和其它设备检测到的事件进行关联时，它们还是很有用的。

蜜罐日志（Honey pot log）

有些组织十分关心对安全事件的前兆进行检测，并采取欺骗性的方法，比如蜜罐来收集更好的数据。所谓蜜罐就是除了蜜罐管理员外没有任何授权用户的主机，因为它不提供任何业务功能。所有针对它的活动都可以看做是可以活动。攻击者扫描并攻击蜜罐，就会给管理员留下有关攻击工具和新趋势，尤其是恶意代码方面的数据。但是，蜜罐只是一种补充手段，并不能代替对网络、系统和应用的保护。如果采用了蜜罐，应该由有能力的安全事件处理人员和入侵检测分析人员来管理它。由于目前对使用蜜罐技术的合法性尚未确定，所以各组织在采用蜜罐之前应该先仔细研究相关法律规定。

公众可获得信息

新弱点及利用信息

及时了解最新的弱点及其被利用方法方面的相关信息可以防止某些安全事件发生，并还可以用来协助对新攻击进行检测和分析。一些专门组织，比如FedCIRC、CERT^®/CC、IAIP及CIAC等组织会定期通过简报、论坛发帖以及邮件列表的形式发布最新的安全信息。

其它组织的安全事件信息

其它组织所发生安全事件的报告会提供非常丰富的信息有一些WEB站点和邮件列表可以被安全事件响应小组和安全专业人员利用来共享他们所遇安全事件的相关信息。此外，也有一些组织会获得、合并并分析来自其它组织的日志和入侵检测的告警信息。

人

组织内部人员

用户、系统管理员、网络管理员、安全技术人员及组织内部其他人员可能报告事件征兆。对所有报告信息要进行进一步确认。因为不仅一般用户缺乏专业知识来判断是否发生了安全事件，就算是受过很好培训的专家也会犯错误。一种方法是要问清消息的来源以及消息的可靠性。将这些估计和所提供信息一起加以记录在事件分析中，尤其是在发现冲突数据时非常有帮助。

其它组织人员

虽然从其它组织人员得到的报告不多，但一定要认真对待。一个经典例子是有一个黑客发现了某系统中的严重弱点后，要么是直接告知该组织，要么是公开发布了这个问题。另一种可能是组织可能被外部第三方告知该组织中有人在攻击它。外界用户可能还报告一些其他迹象，比如网页被篡改、服务被中断。同时，也有可能收到来自其它安全响应小组的事件报告。要建立一个机制来接受来自外部的事件报告；这可能只需要设立一个电话号码或电子邮件地址，并将这些信息转发到求助台。

4、安全事件分析

    如果能够保证上报来的每一个前兆和迹象的信息都是准确的，那么安全事件的检测和分析将是非常容易的事。但不幸的是，目前这是不可能的。比如当用户抱怨说某台服务器无法提供服务通常就是不准确的，还有，众所周知，目前的入侵检测系统都会产生大量误报，即不正确的迹象。这些例子说明了是什么造成安全事件的检测和分析如此困难。应该对每个迹象加以评价以确定它是否合理。更糟的是，人和自动来源可能每天都会带来大量的迹象报告。要从所有这些迹象中找出那少数真正发生的安全事件是一件另人畏惧的任务。

    即使迹象是准确的，这也并不意味着一定发生了安全事件。有些迹象，比如一台WEB服务器崩溃，或是某些核心文件被篡改，可能是因为很多原因造成的，包括人为错误。然而假定出现一个迹象，人们有理由怀疑可能发生了一个安全事件并采取相应行动。通常情况下，安全事件处理人员在没有确定事件是否属实的时候都应该先假定它是真的发生了。有的时候要想确定某个特定事件是否真的是安全事件是一个判断问题，可能有必要与其它技术和信息安全人员合作出决定。很多情况下，情形的处理方式都一样，不管它是否与安全相关。比如如果某个组织每12个小时网络就会失去和因特网的连接，而且没有人肯定原因，有关人员就会希望尽快解决问题，并使用同样的资源来诊断问题，而不管它产生的原因。

    有些事件很容易被检测到，比如明显地篡改网站主页。但是很多安全事件并没有如此明显的症状。水平高的攻击者都会小心地隐藏自己的痕迹而不被发现，即使是那些水平不高的攻击者也因为他们所使用的工具都功能非常强大并具有很好的隐蔽性，所以也很难被发现。安全事件发生的唯一迹象可能是像一个系统配置文件被作了一点点改动这样小的征兆。在安全事件处理过程中，检测可能是最困难的工作。安全事件处理人员负责对那些模糊、矛盾和不完整的症状加以分析，以确定到底发生了什么。尽管有些技术方案可以使检测工作容易些，但是最好的弥补是建立一支具备高水平技术、经验丰富的员工的小组来有效并高效地对前兆和迹象加以分析并采取适当行动。没有经过培训的合格人员，就不可能有效地展开安全事件检测和分析工作，并且可能造成成本高昂的错误。

    安全事件响应小组应该尽快对每一个安全事件进行分析和验证，并对所采取每一步骤进行记录。当安全事件响应小组认为某个事件已经发生时，他们应该迅速展开最初的分析工作来确定安全事件的范围，比如哪些网络、系统和应用受到影响；是谁或什么发起了该安全事件；安全事件的发生状态如何（比如用到了什么样的工具和攻击方法、利用了什么弱点）。最初分析应该为小组提供足够的信息来对后续活动进行优先排序，比如安全事件的限制以及对安全事件后果的深入分析等。如果仍有疑虑，安全事件处理人员应该作好最坏的打算，直到其它分析显示有出入。

对安全事件进行分析和验证是很困难的。以下将提供一些建议，使安全事件的分析更简便有效：

    ●描述网络和系统的特征 特征描述是安全事件分析的最好的技术辅助手段之一。所谓特征描述就是对预期活动的特点加以度量，从而更容易地识别其变更。比如在主机上运行文件完整性检查软件并对关键文件生成校验和、对网络带宽利用情况和主机资源使用情况进行监视以确定在各个日期和时间的平均和高峰利用水平。如果描述过程是自动化的，那么活动变更可以被迅速检测并报告给管理员。实际工作中，使用大多数特征描述技术是很难准确检测安全事件的。组织应该将其作为检测和分析技术之一。

    ●了解正常行为 安全事件响应小组应该对网络、系统和应用加以研究，以深入了解其正常行为，这样就可以容易发现那些异常行为。许多入侵检测分析人员在某点上被告知要去确定不平常的事件。但是如果对“平常”没有深入的了解，也就很难定义什么是“不平常”。没有哪个安全事件处理人员可以全面了解整个环境中的所有行为，但是他们起码要知道哪些专家可以解决哪些问题。

    ●使用集中式日志并建立日志保存政策 与安全事件相关的信息通常在几个地方有记录，比如防火墙、路由器、基于网络的入侵检测系统、基于主机的入侵检测系统以及应用日志。组织应该采用一台或几台集中式日志服务器，并且对组织内所有日志设备进行配置，将其日志副本送到中央日志服务器上。安全事件处理人员通过获取所有相关的日志项受益。同时这也为日志提供了一个安全的存放地点，减少了攻击者在他们要破坏的主机上关闭日志功能或修改日志所带来的后果。此外，要建立并落实日志保存政策来规定日志信息应该保存多久，这对于分析极有帮助，因为老的日志信息可以揭示出侦察活动或以前的类似攻击案例。保留日志的另一个理由是安全事件可能会在几天、几周或甚至几个月后才被发现。日志保存时间的长短取决于几个因素，包括组织的数据保存政策以及数据量的大小。通常，日志数据都应该保存至少几个星期，理想情况下应该至少保留几个月。

    ●开展安全事件关联分析 某个安全事件的证据可能在好几个日志里被捕获到。每个日志里包含有关该安全事件的不同类型数据，防火墙日志可能包含所用到的源IP地址，而应用日志可能包含用户名。网络入侵检测传感器可能会检测到针对特定主机的攻击，但是它无法确定攻击是否成功，安全事件分析人员需要检查主机的日志来确定这一信息。在多个迹象来源之间进行事件关联在验证某个特定安全事件是否发生以及快速将各种信息拼在一起时是非常重要的。使用集中式日志可以使事件关联更加容易和快速，因为它汇集了所有网络、主机、服务、应用及安全设备的日志数据。

    ●保证所有主机时钟同步 像NTP这样的协议可以在主机之间实现时钟同步。这对于安全事件响应来说是非常重要的，因为如果从各设备报告的事件如果时钟配置不一致，那么事件关联就很困难。从证据收集的角度来看，使日志中的时间戳保持一致也是非常重要的，比如本来一个发生在12:07:01的事件，假设有3个设备日志对它进行了记录，如果3个设备的时钟不一致，导致3个日志记录为12:0701、12:10:35和11:07:06，那么后果是可想而知的。

    ●维护和使用信息知识库 知识库中应该包括事件处理人员在安全事件分析中需要迅速参考的信息。尽管可能建一个结构复杂的知识库，但是还是简单的方法比较有效。文本文档、电子表格及相对简单的数据库可以为小组成员之间共享数据提供一个有效而且灵活的机制。知识库中还应该包含许多其它信息，比如：

        ◆到恶意代码和欺骗信息的链接；最完备和最新的来源一般是主要的反病毒软件厂商；

        ◆到一个被列入垃圾邮件黑名单的域名列表的链接；

        ◆前兆和迹象的重要性和真实性解释，比如入侵检测告警、操作系统日志及应用错误码。

    ●利用因特网搜索引擎进行查找 像Google和AltaVista这样的综合因特网搜索引擎可以帮助找到异常活动的相关信息，尤其是扫描。比如分析人员可能会看到一些针对TCP 22912端口的异常扫描。根据“TCP”、“端口”、“22912”进行搜索可能会返回类似活动的日志，甚至是关于该端口号意义的解释。由于大多数与安全事件响应和入侵检测相关的公共邮件列表都有基于网络的文档记录，所以网络搜索引擎也会把这些文档包括在搜索范围之内。安全事件处理人员也可以搜索他们可以访问的非公共邮件列表和专业论坛，联系其它CSIRT，询问他们是否见过类似活动。

    ●使用数据包监听工具来获取更多信息 有的时候，事件记录并没能记录足够的具体信息，使得安全事件处理人员无法确定到底发生了什么事情。在这种情况下，如果该事件是发生在网络间的，最快最有效的方法就是利用数据包监听工具来捕捉该网络中的数据包，从而获取更多的信息。在捕捉之前，应该先配置该工具，只让它捕捉特定类型的数据包，这样可以尽量减少无用信息搀杂其中。同时，数据包监听工具还可以提供最精确，最完整的网络攻击的数据。在有些情况下，如果不使用数据包监听工具将很难对事件进行处理。

    ●考虑数据简化 在很多组织中，只是没有足够的时间来检查和分析所有的迹象。当数据量非常庞大时，人自然就被吓倒并对这些数据不加理会。要推动对安全事件进行有效地检测，人们有必要克服上述反应并确保至少要调查那些最让人怀疑的活动。一个有效的策略是对迹象加以过滤，这样那些不怎么重要的迹象类别就不会出现在安全事件的分析中。一个有效的策略是对迹象加以过滤，让那些最重要的迹象类别出现在安全事件的分析中。但是这种方法比较危险，因为新恶意活动可能不在所选择的迹象类别中。但不管怎么说，这种方法比起根本不检查迹象好的多。

    ●经验是不可代替的 比如确定某个活动的企图是非常困难的。你可以想象，当一个安全事件处理人员看到涉及到某台DNS服务器的异常行为，而该行为并非攻击，只是一些异常流量模式或端口号。这一侦察活动会是针对该DNS服务器即将发起的攻击吗？或者是利用该DNS服务器为媒介针对另一台服务器的攻击？或者这只是均衡负载所造成的正常情况？对这一数据可能的解释有很多，而安全事件处理人员可能由于缺乏详细的数据信息，无法最终确定哪个解释是正确的。确定可以活动企图的最好办法是尽可能多地获得安全事件处理经验。安全事件分析是一种技术性非常强的工作，但也是一种艺术。一个经验丰富的安全事件处理人员可以对数据加以检查并迅速对安全事件的严重性产生直觉。

    ●为没有经验的成员编制一个诊断矩阵 制作这样一个矩阵可以有效地帮助求助台、人员、系统管理员及那些自己对前兆和迹象进行分析的人员。它同样对那些经验不足的入侵检测分析人员和安全事件响应小组成员有帮助。表3是从一个诊断矩阵范例中摘出来的，左边列出了潜在症状，其它每列是安全事件分类。矩阵中的每一个格子表明了哪些症状一般与每个安全事件分类有关联及其关联强度。“强度”可以用任何方式给出，从 “有”或“没有”到一个百分比。这个矩阵可以为那些经验较少、虽然能够发觉事件的症状却无法确定是属于哪种事件的人提供很大的帮助，同时也可以被用于培训新成员。该矩阵如果有解释性文字会更有用，比如对每个矩阵项加一个简短的注解以及如何证实每类安全事件

表3 诊断矩阵范例摘录

症 状

拒绝服务

恶意代码

未经授权访问

不当使用

文件、关键、访问企图

低

中

高

低

文件、不适当的内容

低

中

低

高

主机崩溃

中

低

中

低

端口扫描、输入、异常

高

低

中

低

端口扫描、输出、异常

低

高

中

低

利用率、带宽、高

高

中

低

中

利用率、邮件、高

低

高

中

中

 

●向其它人寻求帮助 有的情况下，安全事件响应小组无法确定安全事件的全部原则和性质。如果小组缺少足够的信息来对事件进行限制和消除，那么他们就应该咨询内部资源（如信息安全人员）和外部资源（如FedCIRC、其他CSIRT、有安全事件响应专长的承包商），来求得分析、限制和消除安全事件方面的帮助。弄清楚每个安全事件的原因是非常重要的，只有这样，我们才能有效地对安全事件进行限制，并且正确地修补弱点，从而防止同样事件的再次发生。

5、安全事件记录

    一旦安全事件响应小组怀疑正在发生或已经发生了安全事件，要立即记录有关该安全事件的全部事实 。日志薄是一个简单有效的介质方法，但目前个人数字助理（PDA）、笔记本计算机、录音机以及数码相机也可以用于这种目的。把系统事件、电话交谈记录下来并观察其中变化可以是问题处理更有效、更系统并且更少犯错误。从安全事件被发现到处理完毕过程中所采取的每一步骤都应该加以记录，并注明时间。与安全事件有关的每份文档都应该让安全事件处理人员注明日期并签字。这类性质的信息也可以作为法律诉讼相关证据。如果有可能，事件处理应该至少保持两人一组的工作方式，一个人开展技术工作的同时，另一个人进行日志记录。

    安全事件响应小组应该将安全事件状态及其它相关信息一起加以保存记录。为实现这一目的，有必要使用一个应用或数据库系统，以保证能够及时地处理和解决安全事件。比如，安全事件处理人员可能会接到与前一天所解决的安全事件相关的紧急电话，而当时的安全事件处理人员已经休假去了，通过访问安全事件数据库，事件处理人员可以快速了解安全事件。这种数据库系统应该包括以下内容：

    ●安全事件的当前状态

    ●安全事件总结

    ●所有安全事件处理人员在此安全事件中所采取的行动

    ●其它涉及各方的联系信息（比如系统拥有者、系统管理员）

    ●在调查该安全事件中所搜集到的证据清单

    ●安全事件处理人员的建议

    ●下一步要采取的步骤（比如等待系统管理员给应用打补丁）

    安全事件处理组还应该小心保护与安全事件相关的，因为这些数据中经常会包括一些敏感信息，比如被利用弱点方面的数据、最近的安全违反活动及那些可能采取不适当行动的用户。要减少敏感信息被不适当外泄的风险，要小组应该保证严格限制对安全事件数据的管理，比如只有经过授权的人员才能访问安全事件数据库。与安全事件相关的电子邮件以及像安全事件报告这样的文档应该加密，保证只有发送方和目标收件人才能读懂。

6、安全事件的优先排序

    对安全事件处理进行优先排序可能是安全事件处理过程中最关键的一个决定点。由于资源的限制，安全事件不应该按照先来先处理的原则进行处理，而应该按照以下两个因素来对安全事件的处理进行优先排序：

    ●安全事件当前和潜在的技术影响 安全事件处理人员不仅应该考虑安全事件目前的负面技术影响（比如对数据的未经授权的用户级访问），而且还要考虑在安全事件没有被立即限制时，它未来的可能技术影响（如根破坏）。比如，某个蠕虫病毒正在组织的网络中传播，它当前的影响还非常小，但是可能在几个小时内蠕虫流量可能导致网络资源被耗尽。

    ●受影响资源的关键程度 受安全事件影响的资源（比如防火墙、WEB服务器、因特网连接、用户工作站以及应用）对组织的的关键程度各不相同。资源的关键程度取决于其数据或服务、用户、与其它资源的信任关系和相互依赖程度以及可视性（比如一个公众WEB服务器相对于一个内部部门的WEB服务器）。许多组织已经通过业务连续性计划工作或他们的服务等级协定（SLA，其中规定了恢复每个关键资源最多用多长时间）确定了资源的关键性。只要可能，安全事件响应小组就应该获取并重用有关资源关键性方面的现有有效数据。

    结合受影响资源的关键性和安全事件当前工作和潜在的技术影响，就可以确定安全事件的业务影响，比如用户工作站的根破坏可能导致生产率的轻微下降，而对公众WEB服务器未经授权的用户级访问则可能在营收、生产率、服务访问、名声及保密数据的泄露（如信用卡号、社会安全号）等方面产生重大损失。小组应该根据安全事件所产生的业务影响估计来优先排序对各个安全事件的响应。比如，与安全无关的不当使用安全事件一般不需要要比其它安全事件晚些处理，因为其业务影响相对较低（第7章将详细介绍如何进行优先排序）。

    组织应该用像表4中的矩阵范例那样的格式来记录优先排序指南。每列的开头列出资源的关键性，每行的开头列出技术影响分类。矩阵中的每个值规定了安全事件响应小组要开始对安全事件作出响应的最长时间。这可以被认为是安全事件响应的一个SLA。一般来说，SLA不规定解决安全事件的最长时间，因为处理安全事件所需要的时间长度差异很大，往往不在安全事件响应小组的控制之中。组织应该根据其自身需求及其资源关键性确定方法来定制这种矩阵。比如组织可能有好几个关键性分类，比如像不会带来损失的病毒感染轻微安全事件最好交给当地IT人员来处理，而无须找安全事件响应小组。理想上最好有两个版本的矩阵：一个用于标准工作日发生的安全事件，另一种用于非工作日发生的安全事件。

表4 安全事件响应SLA矩阵

安全事件的当前影响可能的未来影响

当前受影响的资源，以及未来可能受事件影响的资源

高（如因特网连接、公众WEB服务器、防火墙、客户数据）

中（如系统管理员的工作站、文件和打印服务器、XYZ应用数据）

低（如用户工作站）

根级访问

15分钟

30分钟

1小时

未经授权的数据修改

15分钟

30分钟

2小时

对敏感数据的未经授权访问

15分钟

1小时

1小时

未经授权用用户级访问

30分钟

2小时

4小时

服务不可用

30分钟

2小时

4小时

烦人的事[1]

30分钟

本地IT人员处理

本地IT人员处理

 

如果一个安全事件影响多个资源（如系统、应用和数据），那么可能有多个矩阵项适用于该事件。安全事件处理人员可以确定所有适用的矩阵项并首先采取最紧急的行动。比如，如果恶意代码获造成对高关键性资源（30分钟响应）的未经授权用户级访问以及对低关键性资源（1小时响应）的系统破坏，处理人员应该首先解决高关键性资源上的问题，然后解决低关键性资源上的问题。事件处理人员可能希望在指定的一个小时最大期限内调查一下低关键性资源，特别是如果小组认为其中可能含有对其它资源事件处理有帮助的信息时候。

    矩阵方法鼓励组织去仔细考虑安全事件响应小组在各种环境下应该如何作出反应。通过提供一个安全事件处理决定框架，这些矩阵节省了安全事件处理人员的时间。在安全事件过程中，处理人员经常要承担很大的压力，非常难以作出决策。安全事件处理人员应该能根据其判断对该矩阵作出变化，尤其是在不可预见或异常环境中。

    组织还需要建立一个升级过程，以备在安全事件响应小组不能在规定时间内对安全事件做出响应。导致这种情况有很多原因，比如手机或呼机坏了；相关人员可能个人有急事或者安全事件处理人员午夜回答完问题后又睡着了。升级过程应该规定应该等多长时间，如果没有人响应时该怎么做。一般来说，第一步是重复联系，比如呼叫同一个手机号。短时间后，可能15分钟后，主叫方应该将安全事件升级到更高的层次，比如安全事件响应小组经理。如果那个人在某一时间内没有响应，那么再次将安全事件升级到更高级别的管理人员那里。不断重复这一过程，直到得到回应为止。

7、安全事件的通知

    当安全事件被分析完并优先排序好后，安全事件响应小组需要通知组织内的适当人员，有时也包括组织之外的适当人员。及时的报告和通知可以使相关人员发挥其作用。在目前信息安全威胁的数量和复杂性情况下，合作处理安全事件可能是最好的方法。安全事件响应政策应该包括安全事件报告规定，至少要规定向谁在什么时间必须报告什么内容（比如最初通知、经常性的状态更新）。不同机构的通知要求也各不相同，通常要向以下各方报告：

    ●首席信息主管

    ●信息安全主管

    ●本地信息安全官

    ●组织内其它安全响应小组

    ●系统拥有者
    
    ●人力资源部门（涉及到员工的情况下，比如通过邮件骚扰）

    ●公共事务物部门（对那些可能引发公共事务的安全事件）

    ●法律部门（对那些可能涉及法律问题的安全事件）

    在安全事件处理过程中，安全事件响应小组可能需要随时向某些相关人员通知安全事件的最新情况。某些情况下，比如发生了大规模恶意代码感染事件，小组可能需要在整个组织范围内发出通知。小组应该计划并准备几个通信方法，并对特定事件选择最适当的方法。比如，如果邮件服务器被恶意代码破坏了，那么小组应该不要再通过邮件发出事件更新消息。可能的通信方法有：

    ●电子邮件

    ●WEB站点（基于内联网）

    ●电话

    ●亲自出马

    ●语音信箱（比如为安全事件更新配置专门的语音信箱，并随时更新事件最新情况）

    ●书面通知（比如在公告栏或门上张贴通知，在每个入口点发出通知）

    文章来源： 摘自 NIST Special Publication 800-61
　　发布单位： 北京交通大学信息安全体系机构研究中心