计算机安全事件处理指南

计算机安全事件处理指南

计算机安全事件处理指南（一）：准备和预防

安全事件响应过程从启动准备工作到事件后分析可以分为几个阶段。启动阶段包括建立和培训安

全事件响应小组并获得必要的工具和资源。在准备工作中，组织也要以风险评估的结果为基础，

通过选择和实施一套控制措施来限制安全事件的发生次数。但是即使在实施了安全控制措施后，

残存风险依然不可避免，而同没有哪种控制措施是绝对安全的，所以对破坏网络安全的行为要进

行检测，一旦安全事件发生要对组织发出报警。针对安全事件的严重程度，组织可以采取行动，

通过对安全事件进行限制并最终从中恢复来减缓安全事件所造成的即响。在安全事件得到适当处

理后，组织要提交一份报告，详细描述安全事件的起因、造成的损失以及以后对这种安全事件所

应采取的防范措施和步骤。图1描述了安全事件响应的生命周期。

图1:安全事件响应生命周期

1、准备

安全事件响应方法学通常都要强调准备工作，不仅要建立一个安全事件响应能力，使组

织能够从容响应安全事件，而且要通过确保系统、网络及应用足够安全来预防安全事件。虽然预

防安全事件普通不属于安全事件响放小组的职贡，但是因为它太重要了，以至于现在它已经被认

为是安全事件响应小组的基础组件工作。在提出系统安全保护建议时，安全事件响应小组的专长

是非常有价值的。本节将针对安全事件处理及预防的准备工作提供指导。

1.1准备处理安全事件

表1列出了在安全事件处理过程中一些有价值的工具和资源。可以看到对安全事件分析

实用的具体软件信息以及一些包含对安全事件响应有匡助的信息的网站清单。

表1安全事件处理人员所需工具和资源

工具/资源

安全事件处理人员通信及设施

联系信息用于小组成员及组织内部和外部的其它人员（包括主要联系人和后备

人员），比如执法机构和其它安全事件响应小组：这些信息可能包括电话号码、

电子邮件地址、公钥（按照下面将要提到的加密软件）、以及验证联系人身份

的指令

待命信息用于组织内其它小组，包括问题升级信息

安全事件报告机制比如电话号码、邮件地址和是网上表格，用户可以用它们来

报告可以事件：至少要有一种方法允许用户可以用匿名方式报告事件

传呼机或者挪移电话小组成员要随身携带的通信工具，保证成员在非工作时间

也能联系得到。

加密软件被用于小组成员之间在组织内部、以及和外部机构之间的通信，必缎

采用经过FIPS1452验证过的加密算法

作战指挥室用于集中式通信和协调；如果不需要永久性的作战指挥室，安全事

件响应小组应亥制定一个流程用来在需要时获得一个暂时的作战指挥室。

委全存储设施用于保护证据和其它敏感信息________________________________

安全事件分析硬件和软件

计算机取证工作站m和/或者备份设备用于创建磁盘映象、保存日志文件、保

存安全事件其它相关数据

笔记本计算机由于这种计算机便于携带，可用于数据分析、监听数据包及编写

报告

备用工作站、服务器及网络设备这些设备可应用于许多用途，比如用备份来

恢复系统、测试恶意代码；如果小组难以判断额外设备的费用，可以使用现有

的实验设备，或者用操作系统仿真软件来建立虚拟实验室

空白介质比如软盘、只读CD和只读DVD

便携式打印机旃从非网络连接系统中打印日志文件和其它证据副本。

数据包监听和协议分析器捕获并分析可能包含有事件证据的网络流量一

计算机取证软件用于分析磁盘映象，查找安全事件证据

软盘和光盘存放有程序可靠版本的软盘和光盘，可用它们从系统中采集证据

证据采集辅助设备通过包括笔记本计算机、数字像机、录音机、证据存放袋和

标签、证据磁带等来保护证据，以备可能发生.的法律行动

安全事件分析资源

端口列表包拈常用端口和特洛伊木马端口

文档包括操作系统、应用、协议、入侵检测特征码、病毒特征码的文档。

网络拓扑图和关键资产清单比如WEB服务渊、邮件服务器、FTP服务器—

工具/资源

基线预期网络、系统和应用的行为的基线。一

关键文件的加密hash提高安全事件的分析、3佥证和消除速度

安全事件减缓软件

介质包括操作系统引导盘和CD、。作系统介质及应用介质

安全补丁来自操作系统和应用厂商

备份映像存储在二级介质上的操作系统、区用和数据厂

许多安全事件响应小组都创建了一个简便工具箱(jumpkit),普通是个轻便的袋了•或者箱子,

里面装有安全事件处理人员在异地调查时可能需要的东西。这种工具箱随时可用，这样在发生严

术事件时，安全事件处理人员可以拿起来就走，工具箱中配备了不少表1中所列出的东西。比如

每一个工具箱中普通都有一台笔记本计算机并安装了适当的软件(如包监听和计算机取证等)。

其它重要材料包括备份设备、空白介质、基本网络设备和线缆以及操作系统和应用介质和补丁。

因为这种工具箱主要是为了工作方便，所以工具箱中的东西普通不要外借，还要注意保证工具

箱中

工具得到不断升级和史新（比如笔记本计算机要时常安装新的安全补J,更新操作系统介质）。

组织要在创建和维护一个工具箱的费用和因为更有效和高效地限制安全事件的收益之间取得平

衡。

1.2预防安全事件

将安全事件发生次数保持在一个合理的数量之下是非常重要的。如果安全控制措施不充分，

就可能发生大量安全事件，超出安全事件响应小组的能力，这将使安全事件响应迟缓和响应不完

全，从而对组织造成更大的负面业务影响（比如导致更大的破坏、或者导致更长期的服务或者数

据中断）。一个改善组织的安全生态并预防安全事件的合埋方法是定期对系统和应用进行风险评

估。这些评估应该确定威胁和弱点合在一起会带来什么样的风险。应该将风险进行优先级排序，

风险可以被减缓、转移或者直到达到一个合理的总体风险级别时接受它。采用或者至少检查相

同组织（认真负责的）的控制策略可以提供合理的信心保证，即别人的哪些工作应该用在本组

织里。

时常性地进行风险评估此外一个好处就是确定关键资源，使人们可以重点对其进行监视和

响应。组织不能以认为某些资源不重要为借口来忽视其安全性，因为组织安全水平和其最薄弱环

节一样。需要注意是，无论风险评估多么有效，它反映的也只是当前的风险而已。由于新的威胁

和弱点层出不穷，所以计算机安全是一个持续的、要求工作有效的过程。

就保护网络、系统及应用提出具体建议超出了本文档的讨论范围。尽管安全事件响应小组

普通不负责保护资源，但它可以提出合理的安全实践。其它一些文档中在总体安全概念中、操作

系统和具体应用指南方面给出了一些建议。下面对网络、系统和应用方面的一些主要建议实践进

行简要介绍：

补丁管理许多信息安全专家都允许很大部份安全事件是因为利用了系统和应用口数

量相对较少的弱点所致。大型组织应该落实补丁管理项目来办助系统管理员确定、获得、测试并

采用补丁。

主机安全所有主机都应该被适当加固。除了保证对主机打上正确的补丁外，还应该对

主机进行配置，只允许对适当的用户和主机开放尽可能少的服务，即最小特权原则。对于那些不

安全的缺省配置（比如缺省口令、不安全的共享）进行重置。当用户试图通过访问受保护资源时，

要显示一个警告横幅。主机应该打开审计功能，并记录与安全相关的聿大事件。不少组织使用操

作系统和应用配置指南来匡助管理员一致且有效地保护主机。

网络安全应该对网络边界进行配置，对那些不是明确允许的流量加以拒绝。惟独那些

正确功能所必须的活动，被允许。这包括保护所有的连接点，比如调制解调器、VPN及到其它组

织的专线连接。

恶意代码预防应该在整个组织内采用能检测和阻挠恶意代码（如病毒、蠕虫和特洛伊

木马）的软件。应该在主机级（如服务器和工作站操作系统）、应用服务器级（如邮件服务器、

WEB代理）和应用客户级（如邮件客户端和即时通信客户端）落实恶意代码保护。

用户意识和培训用户应该了解正常使用网络、系统和应用的政策和流程，从以前安全

事件中吸收的经验教训应该和用户共享，这样他们可以看到他们的行为是如何对组织产生影响

的。提高用户对安全事件的意识应该可以减少安全事件的频率，特别是那些恶意代码和违反安全

政策的事件。应该培训IT人员，使他们能够根据本组织的安全标准来维护网络、系统和应用。

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

制

限

除

消

恢

和事件后活动

准备复

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

1、安全事件分类

安全事件的发生的方式多种多样，所以想要制定一个具体的综合流程来处理每一件安全

事件是不切实际的。组织能做的最好程度就是从总体上准备处理任何类型的安全事件，对常见安

全事件类型的处理则更具体一些。下面所列出的安全事件分类既不是包罗一切的，也不打算为安

全事件给出明确的分类，相反，它只给出了一个基本指南又指导如何根据其主要分类来处理安全

事件。

卜面的事件分类列表并不全面，因为这并非为了对所有的安全事件进行定义和分类，

而仅是为了给大家一个初步的概念来指导大家如何根据事件的不同类型去处理事件：

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

过授权的使用。

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

未经授权访问：一个人在未经允许的情况下通过逻辑的或者物理的方式访问网络、系统、

应用、数据或者、其它资源。

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

复合型安全事件：一个单一安全事件中包含两种或者是两种以上的安全事件。

此外，有些安全事件可以对应以上多个分类。安全事件响应小组可以根据其传送机制对安全事件

进行分类，比如：

一个病毒在系统中创建了一个后门，那我们应该把它当做恶意代码安全事件来处理，而不是未

经授权访问安全事件，因为恶意代码是惟一用到的传送机制。"

如果一个病毒创建的后门已经被用于未经授权访问，那末这个事件应该被当做复合型安全事件

来处理，因为它用到了两个传送机制。”

本节主要是针对各种安全事件提出建议实践，后文基于安全事件分类给出了更为具体的建议。

2、事件征兆

对于不少组织来说，安全事件响应过程中最艰难的•步是准确检测并评估可能的安全事

件，即确定一个安全事件是否会发生，如果发生，那它属于什么类型、影响程度如何以及问题的

范围。造成这一点很艰难主要有以下3个因素：

・安全事件可以通过不少不同的方法来检测，并获得不同程度的细节和真实性自动化检

测能力有基于网络的和基于主机的入侵检测系统、反病毒软件以及日志分析工具。也可以通过人

工方法来检测安全事件，比如用户报告的问题。有些安全事件有隐含的征兆，可以很容易被检测

到，而有些如果没有自动工具几乎无法检测到。

，，

•安全事件的潜在征兆数量普通都很高，比如组织每天受到上千甚至百万条入侵检测传

感器报过来的告警信息并不少见。

，，

•对与安全事件相关的数据进行正确而有效的分析往往需要高水平的专业知识和丰富的

实践经验。多数组织内，具备这些条件的人很少，并且普通都可能分配到其它工作中去了。

安全事件的征兆可以分为两类：迹象(indication)和前兆(precursor)。前兆是指未来可

能发生的安全事件的征兆，而迹象是指已经发生或者正在发生的安全事件的征兆。迹象的种类太多,

以至于无法一一介绍，以下是其中一些例子：

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

・反病毒软件发现某台主机被蠕虫感染时发出告警："

•WEB服务器崩溃：”

・用户抱怨上网太慢；”

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

・用户想求助台报告收到吓唬邮件•；”

•某主机记录其日志中的审计配置发生变化：”

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

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

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

不要认为安全事件检测只是一种反应式的，有时候组织也可能在安全事件发生之前就检测

到有关行为。比如网络入侵检测传感器发现针对一组主机的不寻常端口扫描活动，这很可能就是

对某台主机发起拒绝服务攻击的前兆。以卜是其它一些有前兆的例子：

•WEB服务器日志显示，有人使用WEB服务器弱点扫描工具：”

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

•某黑客组织声称要攻击该组织。”

不是所有的攻击都可以通过前兆检测到，有的攻击没有前兆，有的攻击前兆则很难被组

织发现的。如果在攻击之前发现前兆，那末该组织还有机会通过采用自动或者人工方法来改变其

安全生态来预防安全事件发生。但是大多数严重情况下，组织可能要确定采取行动，就像已经

发生了安全事件，从而尽快减缓风险。很少情况下，组织可以密切监视某些活动，可能是针对

特定主机的连接企图或者某些网络流量类型。

3、前兆和迹象的来源

可以通过许多不同的来源来检测前兆和迹象，最常用的有计算机安全软件的告警、日志、

公共渠道获取的信息及人。表2列出了每种分类常见的前兆和迹象来源。

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

前兆和迹象

描述

来源

计算机软件告警

基于网络和主机的入侵检测系统就是设计来识别可疑事件并记录相关数据，包括攻击被检测到

入侵检测系统的日期和时间、攻击类型、攻击来源和目的的IP地址以及用户名（如果可能

获得的话）。多数入侵检测系统使用攻击特征库来识别恶意活动，必须要保

持更新特征库，从而能检测到最新的攻击。入侵检测系统时常产生误报，即

报警有恶意活动发生，但是实际上没有。分析人员应该通过子细检查记录数

据或者从其它来源获得相关数据来对入侵检测系统的告警进行人工验证。

反病得软件通常在检测到恶意代码后，反病毒软件就会向被感染主机和中央反病毒控制

台发送告警信息。只要保持病毒特征码不断更新升级，目前的反病毒产品能

非常有效地检测、查杀或者是隔离恶意代码。但是在大型组织中升级特征码

是非常繁重的任务。一种解决办法是配置集中式反病毒软件，采用推的方

式将特征码升级到各个主机上，而不是靠拉的方式让各主机自己升级。由

于不同反病毒软件的检测效果各异，有的组织为了能够提高反病毒的很盖

面和精确度，通常都会使用多种反病毒软件。至少应该在两个层次采用反

病毒软件：网络边界（比如防火墙、邮件服务器）和主机层次（比如工作

站、文件服务

器、客户端软件）。

文件完整性检测软安全事件可能导致重要文件被修改：文晔完整性检测软件可以检测到这些变

件化。它通过一种hash算法来获取目标文件的加密校验利。如果文件被修改或

者

校验和被重新计算过，新旧校验和很可德不会匹配，通过总样就“J以检恻到

文件被修改过。

第三方监视服务目的组织花钱请即第二方监视其公众可访问服务，比如WEB、DNS及FTP

服务器。这些第三方组织每隔几分钟就会自动尝试访问这些服务。一旦无法

出告警，比如网站主页。尽管从运行的角度来看监视服务非常实用，但是它

还可以被用来检测拒绝服冬■攻击和服务器破坏。

日志

操作系统，服务和在事件发生时，来自操作系统、服务以及应用（特别是审计相关数据）的日

应用软件的日志志通常是非常有价值的。日志可以提供诸如哪些帐号曾经登录过、登录之后

都做过什么事情等不少有价值的信息。但不幸的是，在大多数事件中，因为

被禁用或者错误配置，日志并没能提供出证据。为匡助事件处理组织应该在

所有系统上要求一个日志基线级别，并且在关键系统上要求更高的日志基线

级另h所有系统都应该打开审计功能并记录审计事件•，特别是管理员级别的

事件。对所有系统都要定期检查，以验证日忐的功能•切正常并符合旦志标

网络设备日志优，

网络设务（比如防火墙、路由器）的U志普通都不用作安全事件前兆和迹象

的首要来源。尽管这些设备通常都记录了对连接请求的阻断，但它们很少提

供有关活动性质方面的信息。即便如此，在确定趋势（比如企图访问特定端

口的数量急剧增加）以及在和其它设备检测到的事件进行关联时，它们还是

很实用的。

蜜罐日志（Honey；彳些组织1•分关心对安全事件的前兆进行检测，并采取欺骗性的方法，比如

potlog）蜜罐来采集更好的数据.所谓蜜罐就是除了蜜罐管理员外没有任何授权用户

的主机，因为它不提供任何业务功能。所有针对它的活动都可以行做是可以

活动。攻击者扫描并攻击蜜罐，就会给管理员留卜有关攻击工具和新趋势，

特别是恶意代码方面的数据。但是，蜜罐只是一种补充手段，并不能代替对

网络、系统和应用的保护。如果采用了蜜罐，应该由有能力的安全事件处理

人员和入侵检测分析人员来管理它。由于目前对使用蜜罐技术的合法性尚未

确定，所以各组织在采用蜜罐之前应该先子细研究相关法律规定。

公众可获得信息

新弱点及利用信息及时了解最新的弱点及其被利用方法方面的相关信息可以防止某些安全事件

发生，并还可以用来协助对新攻击进行检测和分析。一些专门组织，比如

FedCIRC、CERT®/CC、IAIP及CIAC等组织会定期通过简报、论坛发帖以及

邮件列表的形式发布最新的安全信息。

其它组织的安全事其它组织所发生安全事件的报告会提供非常丰富的信息有•些WEB站点和

件信息邮件列表可以被安全事件响应小组和安全专业人员利用来共享他们所遇安全

事件的相关信息。此外，也有一些组织会获得、合并并分析来自其它组织的

日志和入侵检测的告警信息。

人

组织内部人员用户、系统管理员、网络管理员、安全技术人员及组织内部其他人员可能报

告事件征兆。对所有报告信息要进行进一步确认。因为不仅普通用户缺乏专

业知识来判断是否发生了安全事件，就算是受过很好培训的专家也会犯错误。

一种方法是要问清消息的来源以及消息的可靠性。将这些估计和所提供信息

一起加以记录在事件分析中，特别是在发现冲突数据时非常有匡助。

其它组织人员虽然从其它组织人员得到的报告不多，但一定要认真对待。•个经典例子是

有一个黑客发现了某系统中的严重弱点后，要末是直接告知该组织，要末是

公开辟布了这个问题。另一种可能是组织可能被外部第三方告知该组织中

有人在攻击它。外界用户可能还报告一些其他迹象，比如网页被篡改、服

务被

中断。同时，也有可能收到来自其它安全响应小组的事件报告。要建立一个

机制来接受来自外部的事件报告：这可能只需要设立一个电话号码或者电子邮

件地址，并将这些信息转发到求助台。

4、安全事件分析

如果能够保证上报来的每一个前兆和迹象的信息都是准确的，那末安全事件的检测和分

析将是非常容易的事。但不幸的是，目前这是不可能的。比如当用户抱怨说某台服务器无法提供

服务通常就是不许确的，还有，众所周知，目前的入侵检测系统都会产生大量误报，即不正确的

迹象。这些例子说明了是什么造成安全事件的检测和分析如此艰难。应该对每一个迹象加以评价

以确定它是否合理。更糟的是，人和自动来源可能每天都会带来大量的迹象报告。要从所有这

些迹象中找出那少数真正发生的安全事件是一件另人畏惧的任务。

即使迹象是准确的，这也并不意味着一定发生了安全事件。有些迹象，比如一台WEB服

务器崩溃，或者是某些核心文件被篡改，可能是因为不少原因造成的，包括人为错误。然而假定

出现一个迹象，人们有理由怀疑可能发生了一个安全事件并采取相应行动。通常情况下，安全

事件处理人员在没有确定事件是否属实的时候都应该先假定它是真的发生了。有的时候要想确

定某个特定事件是否真的是安全事件是一个判断问题，可能有必要与其它技术和信息安全人员

合作出决定。不少情况下，情形的处理方式都一样，不管它是否与安全相关。比如如果某个组

织每12个小时网络就会矢去和因特网的连接，而且没有人肯定原因，有关人员就会希翼尽快

解决问题，并使用同样的资源来诊断问题，而不管它产生的原因。

有些事件很容易被检测到，比如明显地篡改网站主页。但是不少安全事件并没有如此明

显的症状。水平高的攻击者都会小心地隐藏自己的痕迹而不被发现，即使是那些水平不高的攻击

者也因为他们所使用的工具都功能非相强大并具有很好的障蔽性，所以也很难被发现。安全事件

发生的惟一迹象可能是像一个系统配置文件被作了一点点改动这样小的征兆。在安全事件处理过

程中，检测可能是最艰难的一匚作。安全事件处理人员负责对那些含糊、矛盾和不完整的症状加以

分析，以确定到底发生了什么。尽管有些技术方案可以使检测工作容易些，但是最好的弥补是建

立一支具备高水平技术、经验丰富的员工的小组来有效并高效地对前兆和迹象加以分析并采取适

当行动。没有经过培训的合格人员，就不可能有效地展开安全事件检测和分析工作，并且可能造

成成本高昂的错误。

安全事件响应小组应该尽快对每一个安全事件进行分析和验证，并对所采取每一步骤进

行记录。当安全事件响应小组认为某个事件己经发生时，他们应该迅速展开最初的分析工作来确

定安全事件的范围，比如哪些网络、系统和应用受到影响；是谁或者什么发起了该安全事件：安

全事件的发生状态如何（比如用到了什么样的工具和攻击方法、利用了什么弱点）。最初分析

应该为小组提供足够的信息来对后续活动进行优先排序，比如安全事件的限制以及对安全事件

后果的深入分析等。如果仍有疑虑，安全事件处理人员应该作好最坏的打算，直到其它分析显示

有出入。

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

•描述网络和系统的特征特征描述是安全事件分析的最好的技术辅助手段之一。所谓特

征描述就是对预期活动的特点加以度量，从而更容易地识别其变更。比如在主机上运行文件完整

性检查软件并对关键文件生成校验和、对网络带宽利用情况和主机资源使用情况进行监视以确定

在各个日期和时间的平均和高峰利用水平。如果描述过程是自动化的，那末活动变更可以被迅速

检测并报告给管理员。实际工作中，使用大多数特征描述技术是很难准确检测安全事件的。组织

应该将其作为检测和分析技术之一。

・了解正常行为安全事件响应小组应该对网络、系统和应用加以研究，以深入了解其正

常行为，这样就可以容易发现那些界常行为。许多入侵检测分析人员在某点上被告知要去确定不

寻常的事件。但是如果对“寻常”没有深入的了解，也就很难定义什么是“不寻常”。没有哪个

安全事件处理人员可以全面了解整个环境中的所有行为，但是他们起码要知道哪些专家可以解决

哪些问题。

〃

・使用集中式日志并建立日志保存政策与安全事件相关的信息通常在几个地方有记录，

比如防火墙、路由器、基于网络的入侵检测系统、基于主机的入侵检测系统以及应用日志。组织

应该采用一台或者几台集中式日志服务器，并旦对组织内所有日志设备进行配置，将其日志副本

送到中央日志服务器上。安全事件处理人员通过获取所有相关的日志项受益。同时这也为1志

提供r一个安全的存放地点，减少r攻击者在他们要破坏的主机上关闭日志功能或者修改H志

所带来的后果。此外，要建立并落实日志保存政策来规定日志信息应该保存多久，这对于分析

极有匡助，因为老的日志信息可以揭示出侦察活动或者以前的类似攻击案例。保留日志的另一

个理由是安全事件可能会在儿天、几周或者甚至几个月后才被发现。日志保存时间的长短取决

于几个因素，包括组织的数据保存政策以及数据量的大小。通常，日志数据都应该保存至少几

个星期，理想情况下应该至少保留几个月。

・开展安全事件关联分析某个安全事件的证据可能在好几个日志里被捕获到。每一个日

忐里包含有关该安全事件的不同类型数据，防火墙日志可能包含所用到的源IP地址，而应用

日志可能包含用户名。网络入侵检测传感器可能会检测到针对特定主机的攻击，但是它无法确

定攻击是否成功，安全事件分析人员需要检查主机的日志来确定这一信息。在多个迹象来源之

间进行事件关联在验证某个特定安全事件是否发生以及快速将各种信息拼在•起时是非常重要

的。使用集中式日志可以使事件关联更加容易和快速，因为它汇集了所有网络、主机、服务、

应用及安全设备的日志数据。

・保证所有主机时钟同步像NTP这样的协议可以在主机之间实现时钟同步。这对于安全

事件响应来说是非常重要的，因为如果从各设备报告的事件如果时钟配置不一致，那末事件关联

就很艰难。从证据采集的角度来看;使口志中的时间戳保持一致也是非常重要的，比如本来一个

发生在12:07:01的事件，假设有3个设备日志对它进行了记录，如果3个设备的时钟不一致，

导致3个日志记录为12:070R12:10:35和11:07:06,那末后果是可想而知的。

，，

•维护和使用信息知识库知识库中应该包括事件处理人员在安全事件分析中需要迅速

参考的信息。尽管可能建一个结构复杂的知识库，但是还是简单的方法比较有效。文本文档、电

子表格及相对简单的数据库可以为小组成员之间共享数据提供一个有效而且灵便的机制。知识库

中还应该包含许多其它信息，比如：

-1

♦到恶意代码和欺骗信息的链接；最完备和最新的来源普通是主要的反病毒软

件厂商；

♦到一个被列入垃圾邮件黑名单的域名列表的链接；

♦前兆和迹象的重要性和真实性解释，比如入侵检测告警、操作系统日志及应

用错误码。

・利用因特网搜索引擎进行查找像Google和AltaVista这样的综合因特网搜索弓擎可

以匡助找到异常活动的相关信息，特别是扫描。比如分析人员可能会看到一些针对TCP22912

端口的异常扫描。根据“TCP”、“端口”、“22912”进行搜索可能会返回类似活动的日志，甚

至是关于该端口号意义的解释。由于大多数与安全事件响应和入侵检测相关的公共邮件列表都有

基于网络的文档记录，所以网络搜索引擎也会把这些文档包括在搜索范围之内。安全事件处理人

员也可以搜索他们可以访问的非公共邮件列表和专业论坛，联系其它CSIRT,问询他们是否见过

类似活动。

•使用数据包监听工具来获取更多信息有的时候，事件记录并没能记录足够的具体信

息，使得安全事件处理人员无法确定到底发生了什么事情。在这种情况下，如果该事件是发生在

网络间的，最快最有效的方法就是利用数据包监听工具来捕捉该网络中的数据包，从而获取更多

的信息。在捕捉之前，应该先配置该工具，只让它捕捉特定类型的数据包，这样可以尽量减少无

用信息搀杂其中。同时，数据包监听工具还可以提供最精确，最完整的网络攻击的数据。在有些

情况下，如果不使用数据包监听工具将很难对事件进行处理。

・考虑数据简化在不少组织中，只是没有足够的时间来检查和分析所有的迹象。当数据

量非常庞大时，人自然就被吓倒并对这些数据不加理会。要推动对安全事件进行有效地检测，人

们有必要克服上述反应并确保至少要调查那些最让人怀疑的活动。•个有效的策略是对迹象加以

过滤，这样那些不怎么重要的迹象类别就不会浮现在安全事件的分析中。一个有效的策略是对迹

象加以过滤，让那些最重要的迹象类别浮现在安全事件的分析中。但是这种方法比较危（wei）险,

因为新恶意活动可能不在所选择的迹象类别中。但不管怎么说，这种方法比起根本不检查迹象好

的多。

・经验是不可代替的比如确定某个活动的企图是非常艰难的。你可以想象，当一个安全

事件处理人员看到涉及到某台DNS服务器的异常行为，而该行为并非攻击，只是一些异常流量模

式或者端口号。这一侦察活动会是针对该DNS服务器即将发起的攻击吗？或者是利用该DNS服务

器为媒介针时另•台服务器的攻击？或者这只是均衡负载所造成的正常情况？利•这•数据可能

的解释有不少，而安全事件处理人员可能由于缺乏详细的数据信息，无法最终确定哪个解择是

正确的。确定可以活动企图的最好办法是尽可能多地获得安全事件处理经验。安全事件分析是

一种技术性非常强的工作，但也是一种艺术。一个经验丰富的安全事件处理人员可以对数据加

以检查并迅速对安全事件的严重性产生直觉。

・为没有经验的成员编制一个诊断矩阵制作这样一个矩阵可以有效地匡助求助台、人

员、系统管理员及那些自己对前兆和迹象进行分析的人员.它同样对那些经验不足的入侵检测分

析人员和安全事件响应小组成员有匡助。表3是从一个诊断矩阵范例中摘出来的，左边列出了潜

在症状，其它每列是安全事件分类。矩阵中的每一个格子表明了哪些症状普通与每一个安全事件

分类有关联及其关联强度,“强度”可以用任何方式给出，从“有”或者“没有”到一人百

分比。这个矩阵可以为那些经验较少、虽然能够发觉事件的症状却无法确定是属于哪种事件的

人提供很大的匡助，同时也可以被用于培训新成员。该矩阵如果有解释性文字会更实用，比如

对每一个矩阵项加一个简短的注解以及如何证实每类安全兽件。

表3诊断矩阵范例摘录

症状拒绝服务恶意代码未经授权访问不当使用

文件、关键、访问企图低中高低

文件、不适当的内容低中低高

主机崩溃中低中低

端口扫描、输入、异常高低中低

端口扫描、输出、异常低高中低

利用率、带宽、高高中低中

利用率、邮件、高低高中中

・向其它人寻求匡助有的情况下，安全事件响应小组无法确定安全事件的全部原则和性

质。如果小组缺少足够的信息来对事件进行限制和消除，那末他们就应该咨询内部资源（如信息

安全人员）和外部资源（如FedCIRC.其他CSIRT、有安全事件响应专长的承包商），来求得分

析、限制和消除安全事件方面的匡助。弄清晰每一个安全事件的原因是非常重要的，惟独这洋，

我们才干有效地对安全事件进行限制，并且正确地修补弱点，从而防止同样事件的再次发生。

5、安全事件记录

一旦安全事件响应小组怀疑正在发生或者己经发生了安全事件，要即将记录有关该安全

事件的全部事实o日志薄是一个简单有效的介质方法，但目前个人数字助理（PDA）、笔记本

计算机、录音机以及数码相机也可以用于这种目的。把系统事件、电话交谈记录下来并观察其

中变化可以是问题处理更有效、更系统并且更少犯错误。从安全事件被发现到处理完毕过程中

所采取的每一步骤都应该加以记录，并注明时间。与安全事件有关的每份文档都应该让安全事

件处理人员注明日期并签字。这种性质的信息也可以作为法律诉讼相关证据。如果有可能，事

件处理应该至少保持两人一组的工作方式，一个人开展技术工作的同时，另一个人进行日志记

录。

安全事件响应小组或该将安全事件状态及其它相关信息一起加以保存记录。为实现这一

目的，有必要使用一个应用或者数据库系统，以保证能够及时地处理和解决安全事件。比如.安

全事件处理人员可能会接到与前一天所解决的安全事件相关的紧急电话，而当时的安全事件处

理人

员已经休假去了，通过访国安全事件数据库，事件处理人员可以快速了解安全事件。这种数据库

系统应该包括以下内容：

・安全事件的当前状态

•安全事件总结

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

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

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

•安全事件处理人员的建议

・下一步要采取的步骤（比如等待系统管理员给应田打补丁）

安全事件处理组还应该小心保护与安全事件相关的，因为这些数据中时常会包拈一些敏

感信息，比如被利用弱点方面的数据、最近的安全违反活动及那些可能采取不适当行动的用户。

要减少敏感信息被不适当外泄的风险，要小组应该保证严格限制对安全事件数据的管理，比如只

有经过授权的人员才干访问安全事件数据库。与安全事件相关的电子邮件以及像安全事件报告这

样的文档应该加密，保证惟独发送方和目标收件人材干读懂。

6、安全事件的优先排序

对安全事件处理进行优先排序可能是安全事件处理过程中最关犍的一个决定点。由于资

源的限制，安全事件不此该按照先米先处埋的原则进行处埋，而此该按照以下两个因素来发安全

事件的处理进行优先排序：

•安全事件当前和潜在的技术影响安全事件处理人员不仅应该考虑安全事件目前的负

面技术影响（比如对数据的未经授权的用户级访问），而且还要考虑在安全事件没有被即符限制

时，它未来的可能技术影响（如根破坏）。比如，某个蠕虫病毒正在组织的网络中传播，它当前

的影响还非常小，但是可能在几个小时内蠕虫流量可能导致网络资源被耗尽。

・受影响资源的关犍程度受安全事件影响的费源（比如防火墙、WEB服务器、因特网连

接、用户工作站以及应用）对组织的的关键程度各不相同。资源的关键程度取决于其数据或者服务、

用户、与其它资源的信任关系和相互依赖程度以及可视性（比如一个公众WEB服务器相对于一个

内部部门的WEB服务器）。许多组织已经通过业务连续性计划工作或者他们的服务等级协定（SLA,

其中规定了恢复每一个关键资源最多用多长期）确定了资源的关键性。只要可能，安全事件响应

小组就应该获取并重用有关资源关键性方面的现有有效数据。

结合受影响资源的关键性和安全事件当前工作和潜在的技术影响，就可以确定安全事件

的业务影响，比如用户工作站的根破坏可能导致生产率的轻微下降，而对公众WEB服务器未经授

权的用户级访问则可能在营收、生产率、服务访问、名声及保密数据的泄露（如信用上号、社会

安全号）等力血产生重大损失。小组应该根据安全事件所产生的业务影响估计米优先排序对各个

安全事件的响应。比如，与安全无关的不当使用安全事件普通不需要要比其它安全事件晚些处理，

因为其业务影响相对较低（第7章将详细介绍如何进行优先排序）。

组织应该用像表4中的矩阵范例那样的格式来记录优先排序指南。每列的开头列出资源

的关键性，每行的开头列出技术影响分类。矩阵中的每一个值规定了安全事件响应小组要开始对

安全事件作出响应的最长期。这可以被认为是安全事件响应的一个SLA。普通来说，SLA不规

定解决安全事件的最长期，因为处理安全事件所需要的时间长度差异很大，往往不在安全事件

响应小组的控制之中。组织应该根据其自身需求及其资源关键性确定方法来定制这种矩阵。比

如组织可能有好几个关键性分类，比如像不会带来损失的病毒感染轻微安全事件最好交给当地

TT人员来处理，而无须找安全事件响应小组。理想上最好有两个版本的矩阵：一个用于标准

工作日发生的安全事件，另一种用于非工作日发生的安全事件。

表4安全事件响应SLA矩阵

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

安全事件的当前影响可能

的未来影响高（如因特网连接、中（如系统管理员的工1E低（如用户工作站）

公众WEB服务器、站、文件和打印服务器、

防火墙、客户数据）XYZ应用数据）

根级访问15分钟30分钟1小时

未经授权的数据修改15分钟30分钟2小时

对敏感数据的未经授权访15分钟1小时1小时

问

未经授权用用户级访问30分钟2小时4小时

服务不可用30分钟2小时4小时

烦人的事[1]30分钟本地IT人员处理本地IT人员处理

如果一个安全事件影响多个资源（如系统、应用和数据i,那末可能有多个矩阵项合用于该

事件。安全事件处理人员可以确定所有合用的矩阵项并首先采取最紧急的行动。比如，如果恶意

代码获造成对高关键性资源（30分钟响应）的未经授权用户级访问以及对低关键性资源（1小时

响应）的系统破坏，处理人员应该首先解决高关键性资源上的问题，然后解决低关键性资源上的

问题。事件处理人员可能希翼在指定的一个小时最大期限内调查一下低关键性资源，特殊是如果

小组认为其中可能含有对其它资源事件处理有匡助的信息时候。

矩阵方法鼓励组织去子细考虑安全事件响应小组在各种环境下应该如何作出反应。通过凫供

一个安全事件处理决定框架