第8章 安全管理.pptxVIP

第8章 安全管理2019年5月29感谢你的观看本章要点 安全计划 风险分析 安全策略 物理安全2019年5月29感谢你的观看 我们将关注以下4个相关的领域： (1) 计划编制：要进行怎样的前期准备和研究，才能使具体实现满足目前和今后的安全需求？ (2) 风险分析：如何权衡控制带来的好处和引起的开销，以及如何给出进行控制的理由？ (3) 策略：如何建立一个框架，以保证计算机安全的需求能持续地得到满足？ (4) 物理控制：计算环境的哪些方面对安全有影响？ 2019年5月29感谢你的观看8.1 安全计划 自20世纪80年代初期以来，个人计算机的引入和计算能力的普及，改变了人们与计算机工作及交互的方式。特别是，安全责任已经有相当一部分从计算中心转移到用户。但很多用户并未意识到(或是选择忽略)这个责任，所以他们不对已形成的风险进行处理，或者不采取简单措施来防御或缓解问题。 用户会去保护纸上的数据，却往往忽略对电子文档的保护。用户通常都没有意识到使用计算机存在安全风险，而遭受损失。 2019年5月29感谢你的观看8.1 安全计划(续) 凡是使用计算机创建和保存有用信息的机构，都应该执行全面而有效的安全计划。安全计划是一种文档，它描述了一个机构应如何解决其安全需求。随着机构的安全需求的变动，安全计划也要周期性地进行复查和修正。 一份精心制定的、得到管理者支持的安全计划能让人们感到：安全对于机构管理是很重要的(因此，对每个人都是很重要的)。因而，安全计划必须有适当的内容并能产生预期的效果。 因此，我们应讨论安全计划的三方面：计划应该包含哪些内容、由谁来制定以及如何获取支持。2019年5月29感谢你的观看8.1.1 安全计划的内容 安全计划必须解决以下7个问题： (1) 策略：表明计算机安全工作的目标以及为达到这些目标而涉及的人员的愿意程度。 (2) 当前状态：描述在制定计划时的安全状态。 (3) 需求：推荐方法以达到安全目标。 (4) 推荐控制：将控制与在策略和需求中确定的弱点对应起来。 (5) 责任：描述由谁来负责每一项安全活动。 (6) 时间表：确定不同安全功能的完成时间。 (7) 持续关注：指定一个机构以便周期性地更新安全计划。2019年5月29感谢你的观看8.1.1 安全计划的内容(续) 策略 安全计划必须说明该机构在安全方面的策略。安全策略是对目的和意图的高层次描述。策略应该回答下面三个基本问题： (1) 允许谁来访问？ (2) 允许访问系统和机构的哪些资源？ (3) 对于每个资源，应该给予每个用户怎样的访问权限？ 策略还应该说明以下内容： (1) 机构的安全目标。 (2) 安全责任在谁。 (3) 机构的安全承诺。2019年5月29感谢你的观看8.1.1 安全计划的内容(续) 当前的安全状况 机构需要明确自己的弱点，进行风险分析。风险分析(risk analysis)是描述当前的安全状况的基础。安全状况表现为：机构资产清单、资产面临的安全威胁以及保护资产而采取的控制。 安全计划的状况部分对安全责任做了限定。它不仅描述了对哪些资产实施保护，也描述了由谁来负责实施保护。计划也可以注明某些团体可不对安全负责。计划也定义了责任的边界，特别是涉及到网络的时候。 尽管安全计划应该是全面的，但其中也一定存在没考虑到的弱点。安全计划应该详细说明确定新的弱点应遵循的过程，特别地应该解释如何将对新弱点的控制整合到现有的安全规程中去。2019年5月29感谢你的观看8.1.1 安全计划的内容(续) 需求 安全计划的核心是其安全需求集：为保证达到期望的安全级别而为系统增加的功能或性能要求。这些需求通常是来自于机构的需要。有时，这些需要还应符合特定的强制安全需求，这种强制可来自政府机构或商业标准。2019年5月29感谢你的观看8.1.1 安全计划的内容(续) 需求解释的是哪些该完成，而不是如何完成。也就是说，需求应该尽可能地把实现的细节留给设计者处理。图 8.1 安全计划的输入2019年5月29感谢你的观看8.1.1 安全计划的内容(续) 应该保证需求有以下特征： (1) 正确性：需求可理解吗？对需求的说明正确吗？ (2) 一致性：有相互矛盾或模棱两可的需求吗？ (3) 完备性：需求是否解决了所有可能的情况？ (4) 现实性：需求中的要求是否可能实现？ (5) 必要性：对需求的限制有不必要的吗？ (6) 可验证性：能够构造测试，来客观地、结论性地证明需求已得到满足吗？能否以某种方式测量系统及其功能，以评估其满足需求的程度？ (7) 可追踪性：为了在需求改变后还能比较容易地重新进行评估，能否追踪每个需求到与之相关的功能和数据？2019年5月29感谢你的观看8.1.1 安全计划的内容(续) 推荐的控制 安全计划也还应该推荐一些能整合到系统中以满足安全需求的