计算机安全事件处理指南精编版[25页].docx

《计算机安全事件处理指南精编版[25页].docx》由会员分享，可在线阅读，更多相关《计算机安全事件处理指南精编版[25页].docx（25页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、最新资料推荐计算机安全事件处理指南计算机安全事件处理指南（一）：准备和预防安全事件响应过程从启动准备工作到事件后分析可以分为几个阶段。启动阶段包括建立和培训安全事件响应小组并获得必要的工具和资源。在准备工作中，组织也要以风险评估的结果为基础，通过选择和实施一套控制措施来限制安全事件的发生次数。但是即使在实施了安全控制措施后，残余风险依然不可避免，而且没有哪种控制措施是绝对安全的，所以对破坏网络安全的行为要进行检测，一旦安全事件发生要对组织发出报警。针对安全事件的严重程度，组织可以采取行动，通过对安全事件进行限制并最终从中恢复来减缓安全事件所造成的影响。在安全事件得到适当处理后，组织要提交一份报

2、告，详细描述安全事件的起因、造成的损失以及以后对这类安全事件所应采取的防范措施和步骤。图1描述了安全事件响应的生命周期。图1：安全事件响应生命周期1、准备 安全事件响应方法学通常都要强调准备工作，不仅要建立一个安全事件响应能力，使组织能够从容响应安全事件，而且要通过确保系统、网络及应用足够安全来预防安全事件。虽然预防安全事件一般不属于安全事件响应小组的职责，但是因为它太重要了，以至于现在它已经被认为是安全事件响应小组的基础组件工作。在提出系统安全保护建议时，安全事件响应小组的专长是非常有价值的。本节将针对安全事件处理及预防的准备工作提供指导。1.1 准备处理安全事件 表1列出了在安全事件处理过

3、程中一些有价值的工具和资源。可以看到对安全事件分析有用的具体软件信息以及一些包含对安全事件响应有帮助的信息的网站清单。表1安全事件处理人员所需工具和资源工具/资源安全事件处理人员通信及设施联系信息 用于小组成员及组织内部和外部的其它人员（包括主要联系人和后备人员），比如执法机构和其它安全事件响应小组；这些信息可能包括电话号码、电子邮件地址、公钥（按照下面将要提到的加密软件）、以及验证联系人身份的指令待命信息 用于组织内其它小组，包括问题升级信息安全事件报告机制 比如电话号码、邮件地址和是网上表格，用户可以用它们来报告可以事件；至少要有一种方法允许用户可以用匿名方式报告事件传呼机或移动电话 小组

4、成员要随身携带的通信工具，保证成员在非工作时间也能联系得到。 加密软件 被用于小组成员之间在组织内部、以及和外部机构之间的通信，必须采用经过FIPS 140-2验证过的加密算法作战指挥室 用于集中式通信和协调；如果不需要永久性的作战指挥室，安全事件响应小组应该制定一个流程用来在需要时获得一个临时的作战指挥室。安全存储设施 用于保护证据和其它敏感信息安全事件分析硬件和软件计算机取证工作站1和/或备份设备 用于创建磁盘映象、保存日志文件、保存安全事件其它相关数据笔记本计算机 由于这种计算机便于携带，可用于数据分析、监听数据包及编写报告备用工作站、服务器及网络设备 这些设备可应用于许多用途，比如用备

5、份来恢复系统、测试恶意代码；如果小组难以判断额外设备的费用，可以使用现有的实验设备，或者用操作系统仿真软件来建立虚拟实验室空白介质 比如软盘、只读CD和只读DVD便携式打印机 用于从非网络连接系统中打印日志文件和其它证据副本。数据包监听和协议分析器 捕获并分析可能包含有事件证据的网络流量计算机取证软件 用于分析磁盘映象，查找安全事件证据软盘和光盘存放有程序可靠版本的软盘和光盘，可用它们从系统中收集证据证据收集辅助设备 通过包括笔记本计算机、数字像机、录音机、证据存放袋和标签、证据磁带等来保护证据，以备可能发生的法律行动安全事件分析资源端口列表 包括常用端口和特洛伊木马端口文档 包括操作系统、应

6、用、协议、入侵检测特征码、病毒特征码的文档。网络拓扑图和关键资产清单 比如WEB服务器、邮件服务器、FTP服务器。工具/资源基线 预期网络、系统和应用的行为的基线。关键文件的加密hash 提高安全事件的分析、验证和消除速度安全事件减缓软件介质 包括操作系统引导盘和CD、操作系统介质及应用介质安全补丁 来自操作系统和应用厂商备份映像 存储在二级介质上的操作系统、应用和数据。 许多安全事件响应小组都创建了一个简便工具箱（jump kit），一般是一个轻便的袋子或箱子，里面装有安全事件处理人员在异地调查时可能需要的东西。这种工具箱随时可用，这样在发生严重事件时，安全事件处理人员可以拿起来就走，工具箱

7、中配备了很多表1中所列出的东西。比如每个工具箱中一般都有一台笔记本计算机并安装了适当的软件（如包监听和计算机取证等）。其它重要材料包括备份设备、空白介质、基本网络设备和线缆以及操作系统和应用介质和补丁。因为这种工具箱主要是为了工作方便，所以工具箱中的东西一般不要外借，还要注意保证工具箱中工具得到不断升级和更新（比如笔记本计算机要经常安装新的安全补丁，更新操作系统介质）。组织要在创建和维护一个工具箱的费用和因为更有效和高效地限制安全事件的收益之间取得平衡。1.2预防安全事件 将安全事件发生次数保持在一个合理的数量之下是非常重要的。如果安全控制措施不充分，就可能发生大量安全事件，超出安全事件响应小

8、组的能力，这将使安全事件响应迟缓和响应不完全，从而对组织造成更大的负面业务影响（比如导致更大的破坏、或导致更长时间的服务或数据中断）。一个改善组织的安全生态并预防安全事件的合理方法是定期对系统和应用进行风险评估。这些评估应该确定威胁和弱点合在一起会带来什么样的风险。应该将风险进行优先级排序，风险可以被减缓、转移或直到达到一个合理的总体风险级别时接受它。采纳或至少检查相同组织（认真负责的）的控制策略可以提供合理的信心保证，即别人的哪些工作应该用在本组织里。 经常性地进行风险评估另外一个好处就是确定关键资源，使人们可以重点对其进行监视和响应。组织不能以认为某些资源不重要为借口来忽视其安全性，因为组

9、织安全水平和其最薄弱环节一样。需要注意是，无论风险评估多么有效，它反映的也只是当前的风险而已。由于新的威胁和弱点层出不穷，所以计算机安全是一个持续的、要求工作有效的过程。 就保护网络、系统及应用提出具体建议超出了本文档的讨论范围。尽管安全事件响应小组一般不负责保护资源，但它可以提出合理的安全实践。其它一些文档中在总体安全概念中、操作系统和具体应用指南方面给出了一些建议。下面对网络、系统和应用方面的一些主要建议实践进行简要介绍： 补丁管理 许多信息安全专家都同意很大部分安全事件是因为利用了系统和应用中数量相对较少的弱点所致。大型组织应该落实补丁管理项目来协助系统管理员确定、获得、测试并采用补丁。

10、 主机安全 所有主机都应该被适当加固。除了保证对主机打上正确的补丁外，还应该对主机进行配置，只允许对适当的用户和主机开放尽可能少的服务，即最小特权原则。对于那些不安全的缺省配置（比如缺省口令、不安全的共享）进行重置。当用户试图通过访问受保护资源时，要显示一个警告横幅。主机应该打开审计功能，并记录与安全相关的重大事件。很多组织使用操作系统和应用配置指南来帮助管理员一致且有效地保护主机。 网络安全 应该对网络边界进行配置，对那些不是明确允许的流量加以拒绝。只有那些正确功能所必须的活动才被允许。这包括保护所有的连接点，比如调制解调器、VPN及到其它组织的专线连接。 恶意代码预防 应该在整个组织内采用

11、能检测和阻止恶意代码（如病毒、蠕虫和特洛伊木马）的软件。应该在主机级（如服务器和工作站操作系统）、应用服务器级（如邮件服务器、WEB代理）和应用客户级（如邮件客户端和即时通信客户端）落实恶意代码保护。 用户意识和培训 用户应该了解正常使用网络、系统和应用的政策和流程，从以前安全事件中汲取的经验教训应该和用户共享，这样他们可以看到他们的行为是如何对组织产生影响的。提高用户对安全事件的意识应该可以减少安全事件的频率，尤其是那些恶意代码和违反安全政策的事件。应该培训IT人员，使他们能够根据本组织的安全标准来维护网络、系统和应用。计算机安全事件处理指南（二）：检测和分析图1：安全事件响应生命周期（检测

12、和分析）1、安全事件分类 安全事件的发生的方式多种多样，所以想要制定一个具体的综合流程来处理每一件安全事件是不切实际的。组织能做的最好程度就是从总体上准备处理任何类型的安全事件，对常见安全事件类型的处理则更具体一些。下面所列出的安全事件分类既不是包罗一切的，也不打算为安全事件给出明确的分类，相反，它只给出了一个基本指南来指导如何根据其主要分类来处理安全事件。 下面的事件分类列表并不全面，因为这并不是为了对所有的安全事件进行定义和分类，而仅是为了给大家一个初步的概念来指导大家如何根据事件的不同类型去处理事件： 拒绝服务攻击：一种攻击，通过消耗资源的方式来阻止和破坏对网络、系统或应用经过授权的使用

13、。 恶意代码：能够感染主机的病毒、蠕虫、特洛伊木马或其它基于代码的恶意实体。 未经授权访问：一个人在未经允许的情况下通过逻辑的或物理的方式访问网络、系统、应用、数据或、其它资源。 不当使用：用户违反可接受计算资源使用政策。 复合型安全事件：一个单一安全事件中包含两种或是两种以上的安全事件。此外，有些安全事件可以对应以上多个分类。安全事件响应小组可以根据其传送机制对安全事件进行分类，比如：一个病毒在系统中创建了一个后门，那我们应该把它当作恶意代码安全事件来处理，而不是未经授权访问安全事件，因为恶意代码是唯一用到的传送机制。如果一个病毒创建的后门已经被用于未经授权访问，那么这个事件应该被当作复合型

14、安全事件来处理，因为它用到了两个传送机制。本节主要是针对各种安全事件提出建议实践，后文基于安全事件分类给出了更为具体的建议。2、事件征兆 对于很多组织来说，安全事件响应过程中最困难的一步是准确检测并评估可能的安全事件，即确定一个安全事件是否会发生，如果发生，那它属于什么类型、影响程度如何以及问题的范围。造成这一点很困难主要有以下3个因素： 安全事件可以通过很多不同的方法来检测，并获得不同程度的细节和真实性自动化检测能力有基于网络的和基于主机的入侵检测系统、反病毒软件以及日志分析工具。也可以通过人工方法来检测安全事件，比如用户报告的问题。有些安全事件有隐含的征兆，可以很容易被检测到，而有些如果没

15、有自动工具几乎无法检测到。 安全事件的潜在征兆数量一般都很高，比如组织每天受到上千甚至百万条入侵检测传感器报过来的告警信息并不少见。 对与安全事件相关的数据进行正确而有效的分析往往需要高水平的专业知识和丰富的实践经验。多数组织内，具备这些条件的人很少，并且一般都可能分配到其它工作中去了。 安全事件的征兆可以分为两类：迹象(indication)和前兆(precursor)。前兆是指未来可能发生的安全事件的征兆，而迹象是指已经发生或正在发生的安全事件的征兆。迹象的种类太多，以至于无法一一介绍，以下是其中一些例子：某台FTP服务器发生缓冲区溢出时网络入侵检测传感器报警；反病毒软件发现某台主机被蠕虫

16、感染时发出告警；WEB服务器崩溃；用户抱怨上网太慢；系统管理员发现文件名有不寻常字符；用户想求助台报告收到恐吓邮件；某主机记录其日志中的审计配置发生变化；某应用程序的日志记载了来自未知远程系统的多次失败登录尝试；邮件管理员发现有大量可疑内容邮件流入。网络管理员发现网络流量发生不寻常变化。 不要认为安全事件检测只是一种反应式的，有时候组织也可能在安全事件发生之前就检测到有关行为。比如网络入侵检测传感器发现针对一组主机的不寻常端口扫描活动，这很可能就是对某台主机发起拒绝服务攻击的前兆。以下是其它一些有前兆的例子：WEB服务器日志显示，有人使用WEB服务器弱点扫描工具；公开针对组织邮件服务器弱点的一

17、种新黑客攻击；某黑客组织声称要攻击该组织。 不是所有的攻击都可以通过前兆检测到，有的攻击没有前兆，有的攻击前兆则很难被组织发现的。如果在攻击之前发现前兆，那么该组织还有机会通过采用自动或人工方法来改变其安全生态来预防安全事件发生。但是大多数严重情况下，组织可能要确定采取行动，就像已经发生了安全事件，从而尽快减缓风险。很少情况下，组织可以密切监视某些活动，可能是针对特定主机的连接企图或某些网络流量类型。3、前兆和迹象的来源 可以通过许多不同的来源来检测前兆和迹象，最常用的有计算机安全软件的告警、日志、公共渠道获取的信息及人。表2列出了每种分类常见的前兆和迹象来源。表2前兆和迹象的常见来源前兆和迹

18、象来源描述计算机软件告警基于网络和主机的入侵检测系统入侵检测系统就是设计来识别可疑事件并记录相关数据，包括攻击被检测到的日期和时间、攻击类型、攻击来源和目的的IP地址以及用户名（如果可能获得的话）。多数入侵检测系统使用攻击特征库来识别恶意活动，必须要保持更新特征库，从而能检测到最新的攻击。入侵检测系统经常产生误报，即报警有恶意活动发生，但是实际上没有。分析人员应该通过仔细检查记录数据或从其它来源获得相关数据来对入侵检测系统的告警进行人工验证。反病毒软件通常在检测到恶意代码后，反病毒软件就会向被感染主机和中央反病毒控制台发送告警信息。只要保持病毒特征码不断更新升级，目前的反病毒产品能非常有效地检

19、测、查杀或是隔离恶意代码。但是在大型组织中升级特征码是非常繁重的任务。一种解决办法是配置集中式反病毒软件，采用推的方式将特征码升级到各个主机上，而不是靠拉的方式让各主机自己升级。由于不同反病毒软件的检测效果各异，有的组织为了能够提高反病毒的覆盖面和精确度，通常都会使用多种反病毒软件。至少应该在两个层次采用反病毒软件：网络边界（比如防火墙、邮件服务器）和主机层次（比如工作站、文件服务器、客户端软件）。文件完整性检测软件安全事件可能导致重要文件被修改；文件完整性检测软件可以检测到这些变化。它通过一种hash算法来获取目标文件的加密校验和。如果文件被修改或校验和被重新计算过，新旧校验和极可能不会匹配

20、，通过这样就可以检测到文件被修改过。第三方监视服务有的组织花钱请即第三方监视其公众可访问服务，比如WEB、DNS及FTP服务器。这些第三方组织每隔几分钟就会自动尝试访问这些服务。一旦无法访问，他们就会通过业主指定的方式向业主发出警报，比如通过电话、传呼以及电子邮件等方式。有的监视服务还会检查某些特定资源是否被篡改并发出告警，比如网站主页。尽管从运行的角度来看监视服务非常有用，但是它还可以被用来检测拒绝服务攻击和服务器破坏。日志操作系统，服务和应用软件的日志在事件发生时，来自操作系统、服务以及应用（尤其是审计相关数据）的日志通常是非常有价值的。日志可以提供诸如哪些帐号曾经登录过、登录之后都做过什

21、么事情等很多有价值的信息。但不幸的是，在大多数事件中，因为被禁用或错误配置，日志并没能提供出证据。为帮助事件处理组织应该在所有系统上要求一个日志基线级别，并且在关键系统上要求更高的日志基线级别。所有系统都应该打开审计功能并记录审计事件，尤其是管理员级别的事件。对所有系统都要定期检查，以验证日志的功能一切正常并符合日志标准。网络设备日志网络设备（比如防火墙、路由器）的日志一般都不用作安全事件前兆和迹象的首要来源。尽管这些设备通常都记录了对连接请求的阻断，但它们很少提供有关活动性质方面的信息。即便如此，在确定趋势（比如企图访问特定端口的数量急剧增加）以及在和其它设备检测到的事件进行关联时，它们还是

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

23、时了解最新的弱点及其被利用方法方面的相关信息可以防止某些安全事件发生，并还可以用来协助对新攻击进行检测和分析。一些专门组织，比如FedCIRC、CERT/CC、IAIP及CIAC等组织会定期通过简报、论坛发帖以及邮件列表的形式发布最新的安全信息。其它组织的安全事件信息其它组织所发生安全事件的报告会提供非常丰富的信息有一些WEB站点和邮件列表可以被安全事件响应小组和安全专业人员利用来共享他们所遇安全事件的相关信息。此外，也有一些组织会获得、合并并分析来自其它组织的日志和入侵检测的告警信息。人组织内部人员用户、系统管理员、网络管理员、安全技术人员及组织内部其他人员可能报告事件征兆。对所有报告信息要

24、进行进一步确认。因为不仅一般用户缺乏专业知识来判断是否发生了安全事件，就算是受过很好培训的专家也会犯错误。一种方法是要问清消息的来源以及消息的可靠性。将这些估计和所提供信息一起加以记录在事件分析中，尤其是在发现冲突数据时非常有帮助。其它组织人员虽然从其它组织人员得到的报告不多，但一定要认真对待。一个经典例子是有一个黑客发现了某系统中的严重弱点后，要么是直接告知该组织，要么是公开发布了这个问题。另一种可能是组织可能被外部第三方告知该组织中有人在攻击它。外界用户可能还报告一些其他迹象，比如网页被篡改、服务被中断。同时，也有可能收到来自其它安全响应小组的事件报告。要建立一个机制来接受来自外部的事件报

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

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

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

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

29、困难的。以下将提供一些建议，使安全事件的分析更简便有效： 描述网络和系统的特征 特征描述是安全事件分析的最好的技术辅助手段之一。所谓特征描述就是对预期活动的特点加以度量，从而更容易地识别其变更。比如在主机上运行文件完整性检查软件并对关键文件生成校验和、对网络带宽利用情况和主机资源使用情况进行监视以确定在各个日期和时间的平均和高峰利用水平。如果描述过程是自动化的，那么活动变更可以被迅速检测并报告给管理员。实际工作中，使用大多数特征描述技术是很难准确检测安全事件的。组织应该将其作为检测和分析技术之一。 了解正常行为 安全事件响应小组应该对网络、系统和应用加以研究，以深入了解其正常行为，这样就可以容

30、易发现那些异常行为。许多入侵检测分析人员在某点上被告知要去确定不平常的事件。但是如果对“平常”没有深入的了解，也就很难定义什么是“不平常”。没有哪个安全事件处理人员可以全面了解整个环境中的所有行为，但是他们起码要知道哪些专家可以解决哪些问题。 使用集中式日志并建立日志保存政策 与安全事件相关的信息通常在几个地方有记录，比如防火墙、路由器、基于网络的入侵检测系统、基于主机的入侵检测系统以及应用日志。组织应该采用一台或几台集中式日志服务器，并且对组织内所有日志设备进行配置，将其日志副本送到中央日志服务器上。安全事件处理人员通过获取所有相关的日志项受益。同时这也为日志提供了一个安全的存放地点，减少了

31、攻击者在他们要破坏的主机上关闭日志功能或修改日志所带来的后果。此外，要建立并落实日志保存政策来规定日志信息应该保存多久，这对于分析极有帮助，因为老的日志信息可以揭示出侦察活动或以前的类似攻击案例。保留日志的另一个理由是安全事件可能会在几天、几周或甚至几个月后才被发现。日志保存时间的长短取决于几个因素，包括组织的数据保存政策以及数据量的大小。通常，日志数据都应该保存至少几个星期，理想情况下应该至少保留几个月。 开展安全事件关联分析 某个安全事件的证据可能在好几个日志里被捕获到。每个日志里包含有关该安全事件的不同类型数据，防火墙日志可能包含所用到的源IP地址，而应用日志可能包含用户名。网络入侵检测

32、传感器可能会检测到针对特定主机的攻击，但是它无法确定攻击是否成功，安全事件分析人员需要检查主机的日志来确定这一信息。在多个迹象来源之间进行事件关联在验证某个特定安全事件是否发生以及快速将各种信息拼在一起时是非常重要的。使用集中式日志可以使事件关联更加容易和快速，因为它汇集了所有网络、主机、服务、应用及安全设备的日志数据。 保证所有主机时钟同步 像NTP这样的协议可以在主机之间实现时钟同步。这对于安全事件响应来说是非常重要的，因为如果从各设备报告的事件如果时钟配置不一致，那么事件关联就很困难。从证据收集的角度来看，使日志中的时间戳保持一致也是非常重要的，比如本来一个发生在12:07:01的事件，

33、假设有3个设备日志对它进行了记录，如果3个设备的时钟不一致，导致3个日志记录为12:0701、12:10:35和11:07:06，那么后果是可想而知的。 维护和使用信息知识库 知识库中应该包括事件处理人员在安全事件分析中需要迅速参考的信息。尽管可能建一个结构复杂的知识库，但是还是简单的方法比较有效。文本文档、电子表格及相对简单的数据库可以为小组成员之间共享数据提供一个有效而且灵活的机制。知识库中还应该包含许多其它信息，比如： 到恶意代码和欺骗信息的链接；最完备和最新的来源一般是主要的反病毒软件厂商； 到一个被列入垃圾邮件黑名单的域名列表的链接； 前兆和迹象的重要性和真实性解释，比如入侵检测告警

34、、操作系统日志及应用错误码。 利用因特网搜索引擎进行查找 像Google和AltaVista这样的综合因特网搜索引擎可以帮助找到异常活动的相关信息，尤其是扫描。比如分析人员可能会看到一些针对TCP 22912端口的异常扫描。根据“TCP”、“端口”、“22912”进行搜索可能会返回类似活动的日志，甚至是关于该端口号意义的解释。由于大多数与安全事件响应和入侵检测相关的公共邮件列表都有基于网络的文档记录，所以网络搜索引擎也会把这些文档包括在搜索范围之内。安全事件处理人员也可以搜索他们可以访问的非公共邮件列表和专业论坛，联系其它CSIRT，询问他们是否见过类似活动。 使用数据包监听工具来获取更多信息

35、 有的时候，事件记录并没能记录足够的具体信息，使得安全事件处理人员无法确定到底发生了什么事情。在这种情况下，如果该事件是发生在网络间的，最快最有效的方法就是利用数据包监听工具来捕捉该网络中的数据包，从而获取更多的信息。在捕捉之前，应该先配置该工具，只让它捕捉特定类型的数据包，这样可以尽量减少无用信息搀杂其中。同时，数据包监听工具还可以提供最精确，最完整的网络攻击的数据。在有些情况下，如果不使用数据包监听工具将很难对事件进行处理。 考虑数据简化 在很多组织中，只是没有足够的时间来检查和分析所有的迹象。当数据量非常庞大时，人自然就被吓倒并对这些数据不加理会。要推动对安全事件进行有效地检测，人们有必

36、要克服上述反应并确保至少要调查那些最让人怀疑的活动。一个有效的策略是对迹象加以过滤，这样那些不怎么重要的迹象类别就不会出现在安全事件的分析中。一个有效的策略是对迹象加以过滤，让那些最重要的迹象类别出现在安全事件的分析中。但是这种方法比较危险，因为新恶意活动可能不在所选择的迹象类别中。但不管怎么说，这种方法比起根本不检查迹象好的多。 经验是不可代替的 比如确定某个活动的企图是非常困难的。你可以想象，当一个安全事件处理人员看到涉及到某台DNS服务器的异常行为，而该行为并非攻击，只是一些异常流量模式或端口号。这一侦察活动会是针对该DNS服务器即将发起的攻击吗？或者是利用该DNS服务器为媒介针对另一台

37、服务器的攻击？或者这只是均衡负载所造成的正常情况？对这一数据可能的解释有很多，而安全事件处理人员可能由于缺乏详细的数据信息，无法最终确定哪个解释是正确的。确定可以活动企图的最好办法是尽可能多地获得安全事件处理经验。安全事件分析是一种技术性非常强的工作，但也是一种艺术。一个经验丰富的安全事件处理人员可以对数据加以检查并迅速对安全事件的严重性产生直觉。 为没有经验的成员编制一个诊断矩阵 制作这样一个矩阵可以有效地帮助求助台、人员、系统管理员及那些自己对前兆和迹象进行分析的人员。它同样对那些经验不足的入侵检测分析人员和安全事件响应小组成员有帮助。表3是从一个诊断矩阵范例中摘出来的，左边列出了潜在症状

38、，其它每列是安全事件分类。矩阵中的每一个格子表明了哪些症状一般与每个安全事件分类有关联及其关联强度。“强度”可以用任何方式给出，从 “有”或“没有”到一个百分比。这个矩阵可以为那些经验较少、虽然能够发觉事件的症状却无法确定是属于哪种事件的人提供很大的帮助，同时也可以被用于培训新成员。该矩阵如果有解释性文字会更有用，比如对每个矩阵项加一个简短的注解以及如何证实每类安全事件。表3 诊断矩阵范例摘录症 状拒绝服务恶意代码未经授权访问不当使用文件、关键、访问企图低中高低文件、不适当的内容低中低高主机崩溃中低中低端口扫描、输入、异常高低中低端口扫描、输出、异常低高中低利用率、带宽、高高中低中利用率、邮件

39、、高低高中中 向其它人寻求帮助 有的情况下，安全事件响应小组无法确定安全事件的全部原则和性质。如果小组缺少足够的信息来对事件进行限制和消除，那么他们就应该咨询内部资源（如信息安全人员）和外部资源（如FedCIRC、其他CSIRT、有安全事件响应专长的承包商），来求得分析、限制和消除安全事件方面的帮助。弄清楚每个安全事件的原因是非常重要的，只有这样，我们才能有效地对安全事件进行限制，并且正确地修补弱点，从而防止同样事件的再次发生。5、安全事件记录 一旦安全事件响应小组怀疑正在发生或已经发生了安全事件，要立即记录有关该安全事件的全部事实 。日志薄是一个简单有效的介质方法，但目前个人数字助理（PDA

40、）、笔记本计算机、录音机以及数码相机也可以用于这种目的。把系统事件、电话交谈记录下来并观察其中变化可以是问题处理更有效、更系统并且更少犯错误。从安全事件被发现到处理完毕过程中所采取的每一步骤都应该加以记录，并注明时间。与安全事件有关的每份文档都应该让安全事件处理人员注明日期并签字。这类性质的信息也可以作为法律诉讼相关证据。如果有可能，事件处理应该至少保持两人一组的工作方式，一个人开展技术工作的同时，另一个人进行日志记录。 安全事件响应小组应该将安全事件状态及其它相关信息一起加以保存记录。为实现这一目的，有必要使用一个应用或数据库系统，以保证能够及时地处理和解决安全事件。比如，安全事件处理人员可

41、能会接到与前一天所解决的安全事件相关的紧急电话，而当时的安全事件处理人员已经休假去了，通过访问安全事件数据库，事件处理人员可以快速了解安全事件。这种数据库系统应该包括以下内容： 安全事件的当前状态 安全事件总结 所有安全事件处理人员在此安全事件中所采取的行动 其它涉及各方的联系信息（比如系统拥有者、系统管理员） 在调查该安全事件中所搜集到的证据清单 安全事件处理人员的建议 下一步要采取的步骤（比如等待系统管理员给应用打补丁） 安全事件处理组还应该小心保护与安全事件相关的，因为这些数据中经常会包括一些敏感信息，比如被利用弱点方面的数据、最近的安全违反活动及那些可能采取不适当行动的用户。要减少敏感

42、信息被不适当外泄的风险，要小组应该保证严格限制对安全事件数据的管理，比如只有经过授权的人员才能访问安全事件数据库。与安全事件相关的电子邮件以及像安全事件报告这样的文档应该加密，保证只有发送方和目标收件人才能读懂。6、安全事件的优先排序 对安全事件处理进行优先排序可能是安全事件处理过程中最关键的一个决定点。由于资源的限制，安全事件不应该按照先来先处理的原则进行处理，而应该按照以下两个因素来对安全事件的处理进行优先排序： 安全事件当前和潜在的技术影响 安全事件处理人员不仅应该考虑安全事件目前的负面技术影响（比如对数据的未经授权的用户级访问），而且还要考虑在安全事件没有被立即限制时，它未来的可能技术

43、影响（如根破坏）。比如，某个蠕虫病毒正在组织的网络中传播，它当前的影响还非常小，但是可能在几个小时内蠕虫流量可能导致网络资源被耗尽。 受影响资源的关键程度 受安全事件影响的资源（比如防火墙、WEB服务器、因特网连接、用户工作站以及应用）对组织的的关键程度各不相同。资源的关键程度取决于其数据或服务、用户、与其它资源的信任关系和相互依赖程度以及可视性（比如一个公众WEB服务器相对于一个内部部门的WEB服务器）。许多组织已经通过业务连续性计划工作或他们的服务等级协定（SLA，其中规定了恢复每个关键资源最多用多长时间）确定了资源的关键性。只要可能，安全事件响应小组就应该获取并重用有关资源关键性方面的现

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

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

46、，以及未来可能受事件影响的资源高（如因特网连接、公众WEB服务器、防火墙、客户数据）中（如系统管理员的工作站、文件和打印服务器、XYZ应用数据）低（如用户工作站）根级访问15分钟30分钟1小时未经授权的数据修改15分钟30分钟2小时对敏感数据的未经授权访问15分钟1小时1小时未经授权用用户级访问30分钟2小时4小时服务不可用30分钟2小时4小时烦人的事130分钟本地IT人员处理本地IT人员处理 如果一个安全事件影响多个资源（如系统、应用和数据），那么可能有多个矩阵项适用于该事件。安全事件处理人员可以确定所有适用的矩阵项并首先采取最紧急的行动。比如，如果恶意代码获造成对高关键性资源（30分钟响应）的未经授权用户级访问以及对低关键性资源（1小时响应）的系统破坏，处理人员应该首先解决高关键性资源上的问题，然后解决低关键性资源上的问题。事件处理人员可能希望在指定的一个小时最大期限内调查一下低关键性资源，特别是如果小组认为其中可能含有对其它资源事件处理有帮助的信息时候。 矩阵方法鼓励组织去仔细考虑安全事件响应小组在各种环境下应该如何作出反应。通过提供一个安全事件处理决定框架，这些矩阵节省了安全事件处理人员的时间。在安全事件过程中，处理人员经常要承担很大的压力，非常难以作出决策。安全事件处理人员应该能根据其判断对该矩阵作出变化，尤其是在不可预