安全策略讲义课件.pptVIP

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 2.漏洞扫描 每个组织应开发一个识别计算机系统漏洞的程序。通常由安全方面扫描漏洞，由系统管理做补丁。已有一些商业的和免费使用的扫描工具。 程序应确定多长间隔需进行扫描。扫描的结果应传给系统管理来纠错和执行。 3.策略检查 组织的安全策略确定每个系统的安全要求。定期的外部或内部审计用来检查是否和策略一致。在审计时，安全应和系统管理一起工作以检查系统的一致。可以用自动的工具，也可以用手动进行。 4.登录检查 来自各种系统的登录应定期检查。可以和安全员一起以自动方式检查这些登录。 如采用自动工具，程序应规定工具的配置以及希望它如何处理。如采用手动方式，程序应规定多长间隔检查登录文件以及事件类型等。 5.常规监控 一个组织应该有一个程序归档说明何时网络通信监控发生。有些组织可能选择连续执行这种类型的监控，有些则选择随机监控。无论如何，总应进行监控，且归档。 当计算机事故发生时，事故响应程序确定该组织将如何作出反应。根据事故的不同，事故响应程序应确定谁有权处理，以及应该做什么，但无须说明如何做。后者将留给处理事故的人决定。 1.事故处理目标 当处理事故时，事故响应程序应确定该组织的目标，包括保护组织的系统、保护组织的信息、恢复运行、起诉肇事者、减少坏的宣传等。 这些目标不是惟一的，可以有多个目标。关键是要在事故发生前确定组织的目标。 3.2.8 事故响应程序 2.事件识别 识别一个事故或许是事故响应中最困难的一部分。某些事故是显而易见的，如Web站点的外貌被损坏。有些事故可能是由于入侵攻击或用户的误操作，如数据文件的丢失。 在公布事故以前，应由系统管理员做某些检查，以决定事故是否确实发生了。这部分程序能确定某些事件是显而易见的事故。而某些不是显而易见的事故，管理员应确定检查的步骤。 在得到决定事故的更多信息后，应组织一个事故响应组，应包括以下部门：安全、系统管理、法律、人力资源、公共关系等。 3.信息控制 在发布事故消息时，组织要控制应发布什么样的信息。有多少信息需发布取决于该事故对组织及其客户的影响程度。信息发布的方式、方法也应考虑对组织的正面效应。 4.响应 一个组织对事故流的响应直接取决于事故响应程序的目标。例如，保护系统和信息是目标，那么将系统从网络中移走，并进行必要的修复。另一种情况可能是保持系统在网上的在线状态以及继续服务或允许入侵者再回来，这样可对入侵者跟踪并设置陷阱。 5.授权 事故响应的一个重要部分是决定事故响应组的负责人，授权采取行动，包括确定系统是否要离线，以及和客户、新闻机构、律师部门联系等。通常选择一个组织的官员来担任，他可以是事故响应组的成员，也可以是顾问。负责人在事故响应程序开发时就要作出决定，而不是事故发生时决定。 6.文档 事故响应程序应该规定事故响应组建立其行动档案。有两个好处，其一是有助于事故过后了解所发生的事件全过程；其二是如果要起诉，则有助于法律实施，对事故响应组也可作为一本参考手册，有助于他们处理事故。 7.程序的测试 事故响应是很实际的，不能期望第一次使用事故响应程序，每一件事都很完美。因此当开发完事故响应程序后，应广泛征求意见，找出其不足之处并改进。 事故响应程序还需在现实世界中测试，可以做一些模拟攻击，并观察其响应效果。这些测试可事先公布，也可不公布。 配置管理程序规定修改组织的计算机系统状态的步骤。该程序的目的是确定合适的变化不会对安全事故的识别产生不好的影响。因此新的配置要从安全的角度予以检查。 1.系统的初始状态 对于一个新的系统，它的状态应有文档，包括操作系统及其版本、补丁水平、应用程序及其版本。 2.变更的控制程序 当系统变更时，应执行配置控制程序。该程序应在变更实施前对计划的变更进行测试。当提出变更请求时，应将变更前后的程序存档。在变更以后，应更新系统配置以反映系统的新的状态。 3.2.9 配置管理程序 对生成新系统或能力的项目应有一个设计方法，以提供该组织生成新的系统的步骤。在设计之初就要考虑和安全有关的问题，使最后完成的系统能和安全问题相一致。设计过程中，与安全相关的步骤如下： （1） 需求定义 在任何一个项目的需求定义阶段，应将安全需求列入。设计方法应指出组织的安全策略和信息策略的要求。特别是要确定敏感信息和关键信息的要求。 3.2.10 设计方法 （2） 设计 在项目的设计阶段，设计方法应确保项目是安全的。安全人员应成为设计组成员或作为项目设计审查人员。在设计中对不能满足安全要求之处应特别指出，并予以妥善解决。 （3） 测试 当项