PPT《第8章 安全管理》

第8章 安全管理 本章要点 安全计划 风险分析 安全策略 物理安全 我们将关注以下4个相关的领域: (1) 计划编制:要进行怎样的前期准备和研究,才能使具体实现满足目前和今后的安全需求? (2) 风险分析:如何权衡控制带来的好处和引起的开销,以及如何给出进行控制的理由? (3) 策略:如何建立一个框架,以保证计算机安全的需求能持续地得到满足? (4) 物理控制:计算环境的哪些方面对安全有影响? 8.

1 安全计划 自20世纪80年代初期以来,个人计算机的引入和计算能力的普及,改变了人们与计算机工作及交互的方式.特别是,安全责任已经有相当一部分从计算中心转移到用户.但很多用户并未意识到(或是选择忽略)这个责任,所以他们不对已形成的风险进行处理,或者不采取简单措施来防御或缓解问题. 用户会去保护纸上的数据,却往往忽略对电子文档的保护.用户通常都没有意识到使用计算机存在安全风险,而遭受损失. 8.1 安全计划(续) 凡是使用计算机创建和保存有用信息的机构,都应该执行全面而有效的安全计划.安全计划是一种文档,它描述了一个机构应如何解决其安全需求.随着机构的安全需求的变动,安全计划也要周期性地进行复查和修正. 一份精心制定的、得到管理者支持的安全计划能让人们感到:安全对于机构管理是很重要的(因此,对每个人都是很重要的).因而,安全计划必须有适当的内容并能产生预期的效果. 因此,我们应讨论安全计划的三方面:计划应该包含哪些内容、由谁来制定以及如何获取支持. 8.1.1 安全计划的内容 安全计划必须解决以下7个问题: (1) 策略:表明计算机安全工作的目标以及为达到这些目标而涉及的人员的愿意程度. (2) 当前状态:描述在制定计划时的安全状态. (3) 需求:推荐方法以达到安全目标. (4) 推荐控制:将控制与在策略和需求中确定的弱点对应起来. (5) 责任:描述由谁来负责每一项安全活动. (6) 时间表:确定不同安全功能的完成时间. (7) 持续关注:指定一个机构以便周期性地更新安全计划. 8.1.1 安全计划的内容(续) 策略 安全计划必须说明该机构在安全方面的策略.安全策略是对目的和意图的高层次描述.策略应该回答下面三个基本问题: (1) 允许谁来访问? (2) 允许访问系统和机构的哪些资源? (3) 对于每个资源,应该给予每个用户怎样的访问权限? 策略还应该说明以下内容: (1) 机构的安全目标. (2) 安全责任在谁. (3) 机构的安全承诺. 8.1.1 安全计划的内容(续) 当前的安全状况 机构需要明确自己的弱点,进行风险分析.风险分析(risk analysis)是描述当前的安全状况的基础.安全状况表现为:机构资产清单、资产面临的安全威胁以及保护资产而采取的控制. 安全计划的状况部分对安全责任做了限定.它不仅描述了对哪些资产实施保护,也描述了由谁来负责实施保护.计划也可以注明某些团体可不对安全负责.计划也定义了责任的边界,特别是涉及到网络的时候. 尽管安全计划应该是全面的,但其中也一定存在没考虑到的弱点.安全计划应该详细说明确定新的弱点应遵循的过程,特别地应该解释如何将对新弱点的控制整合到现有的安全规程中去. 8.1.1 安全计划的内容(续) 需求 安全计划的核心是其安全需求集:为保证达到期望的安全级别而为系统增加的功能或性能要求.这些需求通常是来自于机构的需要.有时,这些需要还应符合特定的强制安全需求,这种强制可来自政府机构或商业标准. 8.1.1 安全计划的内容(续) 需求解释的是哪些该完成,而不是如何完成.也就是说,需求应该尽可能地把实现的细节留给设计者处理. 图8.1 安全计划的输入 8.1.1 安全计划的内容(续) 应该保证需求有以下特征: (1) 正确性:需求可理解吗?对需求的说明正确吗? (2) 一致性:有相互矛盾或模棱两可的需求吗? (3) 完备性:需求是否解决了所有可能的情况? (4) 现实性:需求中的要求是否可能实现? (5) 必要性:对需求的限制有不必要的吗? (6) 可验证性:能够构造测试,来客观地、结论性地证明需求已得到满足吗?能否以某种方式测量系统及其功能,以评估其满足需求的程度? (7) 可追踪性:为了在需求改变后还能比较容易地重新进行评估,能否追踪每个需求到与之相关的功能和数据? 8.1.1 安全计划的内容(续) 推荐的控制 安全计划也还应该推荐一些能整合到系统中以满足安全需求的控制.推荐的控制将解决实现的问题:系统将如何设计和开发才能满足安全需求. 实现的责任 在安全计划中,应该有一个部分确定哪些人负责实现安全需求.该文档有助于协调开发者之间的个人责任.同时,明确了由谁负责尚未满足的需求或尚未解决的弱点.也就是说,几乎注明了当发现新的弱点或引入新的资产时,谁来负责实现对它们的控制. 8.1.1 安全计划的内容(续) 可以考虑按角色分配职责: (1) 个人计算机用户可以对自己机器的安全负责.也可以这样做:安全计划可以指定一个人或一个小组充当个人计算机安全的协调员. (2) 项目领导者可以对数据和计算的安全负责. (3) 管理者负责监督人员实现安全措施. (4) 数据库管理员负责对数据的访问以及数据库中数据的完整性. (5) 信息官员可以负责监督数据的创建和使用,这些官员也可以负责数据的保留和正确处置. (6) 人事部职员可以负责涉及到雇员的安全问题. 8.1.1 安全计划的内容(续) 时间表 一个全面的安全计划是不可能能够马上全部执行的.安全计划包括时间表,它表明了计划的组成部分何时及如何实施.这些日期是时间节点,使得管理者可以跟踪实现的进展.如果实现是一个分阶段的开发过程,安全计划也应该描述如何随着时间的推移,逐步实现安全需求. 8.1.1 安全计划的内容(续) 持续关注 安全计划必须要求周期性地复查安全状况.随着用户、数据和设备的变化,新的问题将会产生.此外,当前的控制方法可能过时或失效.应该周期性地仔细检查和更新对象清单和控制列表,并重新进行风险分析.安全计划应该根据日历时间或根据系统变化的性质来安排复查的时间周期. 8.1.2 安全计划编制组成员 对于任何一个复杂的任务,上述行为都很可能需要一个代表了所有相关人员利益的计算机安全计划编制组来执行.编制组的大小取决于计算组织的大小、复杂程度和对安全的要求程度.编制组的成员都应该与描述的计算机安全各个方面相关.无论安全计划编制组是如何组织的,它都必须代表下列群体: (1) 计算机硬件群体. (2) 系统管理员. (3) 系统程序员. (4) 应用程序程序员. (5) 数据录入人员. (6) 物理安全人员. (7) 用户代表. 8.1.3 安全计划的承诺 一个没有得到任何机构承诺(commitment)的计划只能被束之高阁,对计划的承诺意味着,安全功能得以实现,安全活动能得以执行.计划成功需要三方发挥作用: (1) 计划编制组必须对受计划影响的每一群人的需求了如指掌. (2) 受到安全建议影响的人必须理解,安全计划将如何影响他们使用系统和进行商业活动. (3) 管理方必须承诺使用和实施这个系统的安全措施. 8.1.3 安全计划的承诺(续) 培训和宣传能够帮助人们理解和接受安全计划.如果人们理解所建议控制的必要性并且认为这种控制是合理的,他们就将正确有效地使用这些控制.如果人们认为控制很麻烦、变化太多或不利于提高生产率,那么他们将避开这些控制. 管理承诺是通过理解来获得的.安全计划必须用一种使那些管理者能够理解的语言来描述安全风险.应该避免使用专用的技术术语,应该让读者清楚在系统支持的环境中发现的那些安全风险的性质.管理者也必须根据方便和费用进行优化选择.管理者通常对投资控制保持沉默,直到意识到这些控制的价值. 8.1.4 业务持续计划 业务持续计划(business continuity plan)支持在发生计算机安全事故时业务如何继续运作.业务持续计划处理的情况具有以下两个特征: (1) 灾难性情况:在这种情况下,所有计算功能或计算功能的一个主要部分突然变得不可用. (2) 持续长时间:中断可能会持续很长的一段时间,以使业务遭受损失. 8.1.4 业务持续计划(续) 业务持续计划在很多情况下是很有帮助意义的. 如下面的例子: (1) 一场大火烧毁了整个公司的网络. (2) 一个关键软件组件的看似永久的失效会使得计算系统不可用. (3) 业务必须处理某些服务突然中断的情况,这些服务包括电力、电信、网络访问和其他重要服务. (4) 一场水灾使得网络支持方面的关键职员不能到达操作中心. 处理这类灾难的关键是提前计划、提前准备、提前找出在计算技术不能使用时能使业务维持下去的方法.在业务持续计划中,步骤是: 8.1.4 业务持续计划(续) 评估业务影响 为了评估失败对业务的影响,可以先问两个关键的问题:(1) 关键资产是哪些? (2) 什么将会导致这些系统使用的中断? 开发策略 持续策略研究如何保护关键资产.在一些情况下,数据备份、冗余硬件或是可供选择的手工操作已经足够了.在理想情况下,没有任何损失地将业务继续下去.但由于灾难性的失败,通常只有一部分业务功能能够保留下来.在这种情况下,必须开发一种策略,而这种策略是适合于业务和客户的.由于是提前做计划的,所以,能够充分地考虑可能的情况和评估可能的选择.策略分析的结果是根据情况选择最好的行动. 8.1.4 业务持续计划(续) 开发计划 业务持续计划说明了几个重要的事情: (1) 当事故发生时,由谁来管理? (2) 该做什么? (3) 由谁来具体完成? 业务持续计划要解决的问题是:在发生灾难时,如何使关键业务活动维持在某种水平上.它关注的是使业务能够维护下去.它是基于资产调查的,这个调查只集中于小部分关键资产和一些严重的弱点,这些弱点会长期或不定期地对操作构成威胁.业务持续计划关注的是业务,以及在灾难期如何保持业务在某种程度上运转.紧急情况处理不属于计划的范畴. 8.1.5 事故响应计划 事故响应计划(incident response plan)告诉职员如何处理安全事故.与业务持续计划相比,事故响应计划的目标是处理当前的安全事故,不考虑业务的问题.但对一个特定的事件,它可能没有灾难那么严重(也就是说,它可能不会使业务瘫痪),但可能是严重的安全破坏.一个事故可以是一个单一事件,一系列事件或是一个正在发生的问题. 事故响应计划应该:定义事故的组件、确定由谁负责进行管理、描述行动计划. 事故响应 计划通常有三个阶段:预先计划、触发和处理事故.当然,在情况减轻后进行复查很有用,本次事故可以导致对以后事故响应的改善. 8.1.5 事故响应计划(续) 预先计划 在所有的计划功能中,预先计划是最好的,因为它使人们能够有条不紊、轻松地进行逻辑思考.如果机构没有做事故计划,就有可能发生混乱.根据准备好了的事故响应计划,每个人都事先接受培训,在发生故障时呼叫指定的领导者.领导者决定下一步该做什么,但他首先应该确认安全事故是真的发生了,而绝不能是一个安全事故的误报.确定事故后,可以请求响应小组帮助. 8.1.5 事故响应计划(续) 响应小组 响应小组由对事故做出响应的人组成.响应小组可能主要包括: (1) 指导者(director):对事故负责的人,他决定采取什么行动和什么时候结束响应. (2) 技术领导者(lead technician):指导和协调响应.技术领导者决定注意力集中于什么地方,分析有关情况的哪些数据,并且也由他请求其他技术人员帮助分析. (3) 顾问(advisor):合适的法律、人力资源或公共关系方面的职员. 8.1.5 事故响应计划(续) 计划需要考虑下面这些问题: (1) 法律问题:事故将会造成一定的法律后果.在一些国家,计算机入侵是非法的,所以法律执行官员必须介入调查.在另一些国家,你得自己做决定是否要求法律执行官员参与. (2) 保留证据:对安全事故最常见的反应是对事故原因进行假设:它是由内部原因引起的,或仅仅是一种意外.当处理可能的事故时,在 抹灰尘取指纹 之前,要尽可能少地做有关的事情. (3) 记录:记住做过的事情可能会很困难,但必须尽可能地去做. (4) 公共关系:在处理一个事故时,你的机构应该确定一个唯一的发言人.如果机构有太多的人发言,那么就可能令人迷惑. 8.1.5 事故响应计划(续) 事故解决之后 事故响应小组会举行一次事故之后的复查会来考虑两件事情: (1) 要采取某个安全控制吗? (2) 事故响应计划能正常运行吗? 8.2 风险分析 我们可以通过考察以下三个方面来区分风险: (1) 和事件有关的损失(A loss associated with an event):如损失安全,损失时间,降低质量,损失金钱,失去控制,失去协定等.这些损失被称为风险冲击(risk impact)2) 事件发生的可能性(The likelihood that the event will occur):当风险概率为1时,我们称之为问题(problem)3) 能改变结果的程度(The degree to which we can change the outcome):风险控制(risk control)包括一系列降低或消除风险的行动. 8.2 风险分析(续) 可以这样来度量一个风险的影响,即把风险冲击乘以风险概率,得出风险暴露量(risk exposure).我们能够认识、限制、规避或者转移风险,但是不可能杜绝风险.通常,减小风险有三个策略:1) 规避(avoiding)风险:通过改变安全需求或其他系统的特征来实现.2) 转移(transferring)风险:通过将风险分配到其他系统、人、组织或资产来实现;