范文一:风险评估概念
安全风险评估的少数派报告
2003-07-28 00:00:00.0 $page.getAuthor()
■ 本报记者 徐莉 如果说安全市场本身在中国仍处于方兴未艾的阶段,那么,安全风险评估就只 能算作尚在萌芽的种子。因为,作为更高级别的服务,安全风险评估更像安全系统这道 门上的一把锁,需要有个大前提。换句话说,只有企业的 IT 系统足够复杂,安全需求达 到一定级别,这把锁才会派上用场。尽管很多人看好安全风险评估的未来,但是,目前 国内提供真正安全风险评估服务的却只有少数企业。不过,通过对这些企业的采访,我 们印证了大多数人的设想——安全风险评估确是一支开始萌芽的“潜力股”。 提起 2002 年年底的互联网大会,启明星辰首席技术官刘恒至今印象深刻。在那 次会议上,作为安全专题的讲演者之一,刘恒颇为有趣地体会了一回什么叫英雄所见, 因为与刘恒一样,另外三名安全专家也不约而同选择了同一个演讲主题——安全风险评 估管理。 在会后的交流中,四位“英雄”半开玩笑地指出:“既然大家都看好安全风险评 估市场,那索性将 2003 年定名为安全风险评估年。” 半年多时间过去了,市场为这个带有玩笑性质的预测做了最好的注脚。“进入 2003 年后,公司关于安全风险评估的单子明显增多,200 万以上的项目正在执行的有两
个,”刘恒说。在记者的追问下,刘恒对市场做了一个保守估计:“以 2003 年上半年的 落单情况看, 安全风险评估市场的总额应该在八千万到一个亿的样子。 ”安络科技的 CTO 谢朝霞对这个问题的回答很干脆: “用在安全风险评估上的投资能占用户总投资的 1%~ 5%,电信和金融用户能达到 3%~5%。”按此比例换算,仅银行市场,每年用于网络安全 评估的费用将超过几个亿。 我们无意求证这些数字的精确程度,因为这不重要。重要的是,从这些最前沿 市场中人的判断,我们看到了安全风险评估正在从概念走向应用,从空中楼阁走向触手 可及。而对那些已经开始这项业务却无斩获或将要开始却有迷茫的企业来说,先行成功 者的体验无疑是最可宝贵的。 安全风险评估的内涵与外延 什么是安全风险评估?夸张地讲,一千个人有一千个答案。 这些答案或许没有 本质区别,但是,因为现阶段的市场尚没有一个明确的定义,每个人对安全风险评估的 理解,将会因为内涵与外延的不同,呈现溢出或缺损的现象。或许,从用户的需求角度, 更容易将这个问题讲明白,也更具有现实意义。 作为一家电子商务公司的网管,小路深感责任重大。自从 2001 年成立以来,公 司网络多次受到来自黑客的攻击,最严重的一次,业
务因此停顿了 24 小时。为此,小路 需要经常上网查找最新安全动态。到目前为止,仅在 IE 浏览器上,小路就已经打了不下 7 个补丁。但是,从 IE 浏览器、Apache HTTP Server、到域名软件 BIND,都可能是下一 个风险的发源地。“风险无处不在,”小路说,“如果想到种种可能性,真会让人晚上 睡不着觉。”为了让小路和公司领导都能睡上好觉,2003 年初,小路所在的公司请了一 家专业公司为自己的网络系统作安全评估,合同期为一年,除了最开始两个月对系统、 网络、应用作全面地扫描和评测外,在后面的 10 个月里,安全公司将全面检测小路公司 网络流量的进出情况,并将最新发布的安全漏洞以及补丁情况及时通报给小路。一旦发 生问题,服务商承诺在 1 个小时内做出反应。 小路公司的要求几乎涵盖了安全风险评估的大部分内容。如漏洞扫描,可以划 归脆弱性分析; 评测过程,可以算作威胁分析、风险分析。通常来讲,风险咨询公司都 会从资产调查开始,逐步进行脆弱性分析、威胁分析、风险分析,针对风险提出解决方 案,并提供业务连续性综合办法。有些咨询公司,还会应客户的要求,为加固后的网络 系统做二次评估。 从范围上看,安全风险评估又可分为基线风险评估、非正式(快速)风险评估、 详细风险评估与综合风险评估。其中,基线评估通常会在启动一个系统建设项目之前开 始。非正式评估是针对具体问题,通过工具和人的经验,找到问题,提出解决办法。详 细评估则需从物理系统上、数据上以及管理等方面进行全面的评测。绿盟科技工程部安 全工程师于慧龙认为,目前,国内第二种评估比较多。 从评估主体上看,安全风险评估又可分为自评、国家授权的专业评估机构评测 和以服务商为主体的市场化评估行为。“目前,国内缺乏相关网络安全定级标准,因此, 国家还没有设定这样的专业评估机构,”北京中科网威技术中心副总经理吴云坤说。
作为目前市场最主要的群体,安全服务公司提供的评估又可分为两大类:评估 加固与评估咨询。“中小客户通常喜欢采用前者。”刘恒说,“他们通常会就网络现状 做一个调查,从主机到网络到安全设备,全面查找安全漏洞,然后,要求咨询公司提供 加固服务。大客户则需要全面掌握网络安全的情况,要求服务商从系统到管理,提出全 面的风险管理办法。” 自测系统安全的几个渐进方法
普通 系统 测试 敏感性系统 的实 类别 的实施周期 施周 期 网络 3 个月 映射 脆弱 性扫 描 渗透 性测 试 安全 测试 与评 估 解码 日志 检查 完整 性检 查
工 复 作 风 杂 任务和作用 难 险
性 度
确定网络结构、使用中的主机个数和软 12 个 中 中 中 件确定未经授权但却连接在网络上的主 月 机确定打开的端口确定未经授权的服务 确定网络结构、使用中的主机和软件确 定需要进行脆弱性分析的计算机在分析 3 个月~6 个 12 个 高 高 中 目标的计算机中找出可能被攻击的漏洞 月 月 确定 OS 和主要应用软件是否及时升级或 者打补丁 决定测试目标,确定脆弱性等级,以及 12 个 可能产生的破坏程度检查系统人员在发 12 个月 高 高 高 月 生安全问题时的响应速度、对安全政策 的执行情况以及安全方面的基础知识等 发现设计、实施、以及运行中存在的安 至少 3 年一 至少 3 全问题从物理措施、保险等各个角度, 次, 或在系统 年一 高 高 高 重新部署安全措施,来保证安全制度的 做出大的改 次 实施评估系统文件与实际状况之间的差 变的时候 异性 确认生成密码的原则是有效且可行的确 12 个 1 个月 低 低 低 认用户是否按照系统制订的原则设置密 月 码 1周 1周 中 中 低 确保系统按照设定的原则运行
1 个月或根 据实际需要 1 个月 低 低 低 发现未经授权的文件修改 随时进行 1 周或 1 周或根据 根据 病毒 需要随时进 需要 低 低 低 在病毒发作前,发现并删除病毒 检测 行 随时 进行
拨号 12 个月 检测
12 个 低 低 中 发现非法 Modems,阻止未经授权的进入 月
细节之中见真章 很多情况下,细节决定结果。特定到安全风险评估领域,在完成最初的认知之 后,今天的服务商们,又有谁,不是力争在细节上打败对手? 如果三年前,有人提到安全风险评估概念,那他多半是指漏洞扫描。即便在今 天,很多企业仍将这个原本宏大的评估概念狭义地限定为漏洞扫描与修补。如果是这样, 服务公司很难区分彼此,“现成的扫描工具与产品有很多,我们自己也可以买来工具做 扫描,”作为用户,深圳电信的陈波对此狭义理解也很不能接受。 事实上,真正的安全评估服务价值远远超越简单的扫描。 最基本的,网络安全风险是动态的。仅从 2001 年 12 月到 2002 年 12 月,关于 SQL 服务器上的漏洞,就有 11 个报告。而这期间,跟踪漏洞报告及时与否,就显得格外 重要。一些专家还明确指出,在使用 SQL 服务器的时候,不要将 1433 端口和 1434 端口 打开。如果一定要联接,就不要采用 SQL 服务器,除非你能保证在第一时间打补丁。为 了这个“第一时间”,小路所在的公司才会找来专业公司帮忙。 除了硬件系统、 网络、 操作系统等的安全风险评估外, 应用的安全评估更显“真 功夫”。湖北移动梦网部的张明峻认为,应用系统安全隐患很多。 作为非标准化的软
件产品,很多应用在开发过程中都缺乏对安全问题的统筹考 虑。“1.0 版本的软件通常会有很多安全方面的问题,”一个专家警告说。在升级过程 中,某证券公司的网络管理员发现,自从公司的股票交易系统升级后,用户投诉开始增 多。很多用户反映,在输入账户、密码、端口号码以及代理服务器的地址后,却无法进 入交易系统。经过查证,请来解决问题的安全服务公司发现,因为新版本与原来的网络 环境,包括安全系统不匹配,用户无法通过防火墙。“因为证券公司有五个不同的防火 墙。在这种情况下,只有在防火墙上新打开一个入口,用户才能进入系统,”服务工程 师说。 最后,在服务公司的建议下,这个证券公司选择使用另外一个应用系统。“这 是一个明智的选择,否则,这个应用将带来潜在的安全隐患,”谢朝霞评价说。 能在事前帮助用户排除风险固然不错,但并非每个用户都会做出同样的选择, 当发生问题时,作为安全风险评估公司,是否能在最短的时间,排除其他可能性,从应 用层面找到问题症结,同样至关重要。 另外,无论自己提供安全产品与否,作为提供服务的安全公司,不要忘了,网 络安全产品本身同样可能存在漏洞。去年,在为政府部门检测一个安全评估工具时,一 家安全风险评估公司发现了扫描软件自身存在漏洞,这个漏洞,在某种程度上,使整个 网络暴露在危险之中。
实践者的方法论 实践需要理论指导,但市场往往等不得成熟理论的出台,就已经急切地凭着直 觉向前奔去。不过,聪明的实践者总能在忽左忽右的摸索中找到平衡点,进而形成自己 的方法论,高明的,更会在日后成为完整理论的奠基者。 在采访中,众多被调查者一致认为,眼下安全风险评估市场最大的问题之一是 缺乏评估标准,这个答案几乎是此次采访中唯一例外的“标准”答案。 从目前的市场情况看,有关安全的标准已有一大堆,如美国 TCSEC、BS7799、 ISO15408、ISO/IEC17799 和 ISO13335 等。但具体到安全风险评估上,每个标准却都有 其局限性。按照于慧龙的说法,ISO15408,虽然在功能上比较全面,但却没有安全管理 方面的规范,对系统评测方面的规范也不足;ISO13335,因为制订的时间早,与目前的 市场情况有些脱节; BS7799, 虽然详尽但非常复杂, 虽然全面但不够有针对性。 BS7799 由 派生出来的 ISO17799,强调了针对性,却在安全评估方面比较简单,缺乏对照的标准。 来自实战的经验表明,在评估过程中,咨询工程师最常面对的问题是,资产多 重要才算重要?什么样的系统损失可能构成什么样的经济损失?怎样的技术体系达到怎
样的安全等级?一个病毒中断了邮件系统,企业因此造成的经济损失和社会影响如何计 算?如果黑客入侵,尽管没有造成经济损失,但企业的名誉损失又该如何衡量? 事实上,这些问题将从各个角度决定一个系统安全评估的结果。在没有一个相 关标准的情况下,各家公司更多的是参考国外标准,凭借各自积累的经验、与用户多做 沟通来解决。有心的公司,更是将这些经验累计下来,形成文档,总结出各自的咨询规 范。谢朝霞说:“通过三年的时间,我们积累了一个巨大的知识库和工具库,新来的员 工,借助这些手段,也能很快进入工作状态。”启明星辰则将这些宝贵的工作总结出来, 与国际上的先进产品结合起来,做成有针对性的评估软件产品。 从发展过程看,国内安全风险评估市场经历了三个阶段:1、不注重标准,2、 过于依赖标准,3、跨越标准。“我们现在处于第三阶段,在具有适应性特点的国家标准 出台之前,我们先在内部制定具有可操作性的行为规范,”刘恒说。 清内忧难于除外患 在受过黑客攻击和病毒的“洗礼”之后,很多用户开始在防御外来风险方面提 高了警戒,但是,在漏洞更多、管理更复杂的内部风险方面,大多数企业仍疏于防范, 或缺少规则。与之相对应的,内部安全风险评估难度也就更高。 按照北京中科网威技术中心副总经理吴云坤的说法,系统越复杂,企业越需要 风险评估,评估过程也会更有挑战性。 对一个 B2B 或 B2C 的网站来说,它的网络结构可以统一归类为单点对多点模式。 但内部的网络结构,则通常属于多点对多点。业务部与业务部之间、业务部与办公室之 间,每个人与每个人之间,都将连接在一起。“关联点越多,系统越复杂,”吴云坤说, “相应的工作流也呈现多样化和多角度的形态。”因此,在提供安全评估的过程中,服
务商必须对企业内部的业务流程、管理模式有相当的了解,才能切中要害。 据有关机构统计,目前,国内银行与网络相关的经济犯罪 100%属于内部作案或 内外勾结。这样一个触目惊心的数字令人不禁想到,银行业内部的安全防范是怎样的脆 弱。 通过为一些银行用户做评估,谢朝霞发现,很多风险出在管理上,如银行的生 产环境与网络开发环境本应该严格分开,非业务操作人员进出营业现场应该有严格的登 记制度。但是,在实际中,很多技术开发人员随便出入生产现场。最早的一起银行网络 安全事故,就是因为开发人员偷看了操作人员登录密码,偷走了 26 万元现金。就是这样 一些与网络、与技术没有本质关联的问题,造成了大量事实上的安全风险。还有一
些银 行,基础设施落后,有些甚至还在使用安全性很差的 HUB,这种产品,只要随便连通到 一个端口上,就可监看所有的信息流量。 这些问题其实反映出同一个本质,即用户内部安全防范意识淡薄。因此,对安 全评估供应商来说,打破常规,改变观念也是评估过程中需要解决的问题之一。 需求篇 多汁的酸桔子 柳传志曾说过一句话,利润像海绵里的水,是挤出来的。这句话放在任何一个 成熟市场都很合适。不过,作为一个全新启动的领域,安全风险评估市场更像一个多汁 但尚未成熟的桔子,汁液虽然丰富,但要想吃得好,需要先了解桔子的成分,然后想出 各种新方法,或蒸或煮或加糖,重要的是,只有打破常规,才能提前品尝好味。 茶杯里的大象 从最初的市场需求看,国内的安全风险评估出产于安全事故。如黑客入侵,病 毒发作,网络“无缘无故”的瘫痪,用户靠自己的力量解决不了,于是开始从外部寻求 帮助。 但是,从这个需求点开始,服务公司往往帮助用户发现更多的安全隐患,就像 “事故”这个小茶杯里装入了“评估”这头大象,拾遗补缺式的简单要求牵扯出的是一 系列评测、分析与整体解决方案的需求。 随着网络大环境与企业小网络环境的日趋复杂,各种“茶杯”多了起来。如黑 客大战爆发,网络投资前的安全评估,企业领导对不断扩大的网络安全现状的了解需求, 行业领头羊或总部的拉动作用、大行业的引导作用等,都可能促成一个评估合同的产生。 除此之外,政策的原因,如某个行业整体提升网络安全的需求,大事件的发生,如两会 期间的网络安全问题,也会诱发短期需求。但真正促成这个市场发展的因素仍来自企业 认识的提高以及网络变得复杂后,为保证网络可用性、可靠性、保密性,不得不借助外 部力量的切实要求。 “因为政策、因为各种外在因素促成的需求是不可靠的,这样的用户,即使签
了单,未来开发潜力也不会很大,”刘恒说。事实上,安全评估市场的可重复性很强, 就像检查身体一样,不可能一次检查,一劳永逸。因此,了解现有用户需求动机,洞察 用户发展潜力,对供应者来说,是获得事半功倍效果的关键之一。 增加手中的筹码 相比较而言,国内的网络安全评估市场远比国外滞后。从根本上讲,网络整体 发展阶段的不同造成了这种差异。从不少概念片里看到的,如用手机买票,通过机场免 费系统查找出租车,无需见面就签合同、买卖商品(包括企业间的大订单),事实上已 经成为很多美国人生活中的必要组成。而我们,尽管在信息获得上已经对网络构成依赖, 但是,就买卖
行为而言,更多的还是发生在网外,最多上网买个图书与 CD,多数情况下, 还会选择货到付款。 正是因为国外这种无处不在、随手可用的网络现状,带来方便的同时,也催生 了意愿之外的副产品——网络安全隐患。当然,你无需低估人类的智慧,因为紧随其后 的,就是各种针对安全的产品与服务的诞生和发展。 网络环境的区别,或许是国内外网络安全风险评估市场巨大差异的本质原因。 因为这样的环境,由此衍生的各种服务又反过来对评估市场带来新的动力。 如 B2B 业务的发展。很多国外企业为了向客户证明自己的网络是安全的,在建 立 B2B 业务之前,纷纷寻找第三方安全风险评估公司,为自己的网络安全做评估,有些 在遵循评估公司的建议,修补网络后,还会进行二次评估,确定自己网络安全的等级, 最终赢得用户的信任。 另外,随着近年来网络安全事件频繁发生,有关网络安全保险的业务开始萌芽。 从保险公司的角度,费率的制定,与客户网络的安全等级大有关系,网络越安全,费率 越低。如果企业能证明自己的网络非常安全,就有可能以极低的价格获得保险。而这一 现象,同样促进安全风险评估市场的发展。作为国内安全风险评估供应商,或许可以通 过与保险公司合作的方式,从侧面拉动市场的发展。 先摘够得着的果子 如果按照每年几个亿计算,今天的安全风险评估市场只能算作小菜。就国内市 场来看,电信行业显然是“第一个吃螃蟹的人”。根据 IDC 的调查,2003 年,亚太电信 公司花在网络安全上的开支将占整个 IT 开支的 15%。40%的受访者表示,他们面对的安 全问题有所增加。对各种新技术、新服务体验的意愿,让中国的电信市场成为全世界供 应商眼中“最可爱的人”。就安全风险评估市场来说,电信同样给了供应商希望,并起 到了“带头”作用。“今年,我们几个大的评估单子都是来自电信,”刘恒说。 紧随其后的是金融,包括银行、证券和保险。在这一点上,南北供应商认识不 一,谢朝霞认为,银行在商务上的风险最大,因此,对网络评估的需求也最强烈。从安 络科技的业务组成上看,来自银行与证券的用户最多,电信其次。刘恒则指出,在安全 风险评估业务上,今年,电信市场真正启动了。金融领域零散的单子虽然不少,但整个 行业的大规模启动应该在明年。而吴云坤则认为,未来,随着安全评估标准的确定,银
行将会以自评为主。“因为银行的业务系统大多是自己开发完成的,交给外面的公司做 评估,反而增加了安全风险。” 政府方面,总体来看,目前在安全风险评估上的需求还不很明确。
但随着电子 政务的进一步发展,与之相关的网络安全方面的需求必然会有所加强。 各种各样的网站对安全风险评估的需求也开始放大。除了自身技术能力比较雄 厚的新浪、网易等,不少网站也开始借助外力,评估自己网络的安全情况。 产品服务化和服务产品化是两个发展趋势,我们希望在这其中找准自己的位置。 ——北京中科网威 吴云坤 越是新开发的应用,越需要进行安全评估。 ——安络科技 谢朝霞 服务篇 风口浪尖上的淘金者 概念多,服务少 早在 2000 年,绿盟科技就提出了 NSPS 安全服务体系,由此以后,市场上有关 安全评估、安全服务的概念如雨后春笋,在各种各样的安全公司落地生根。 不过,提出概念容易,提供服务却难。而国内市场对有偿服务的接受程度过低 也一直为企业界所诟病。在这样不利的外在环境和小我的局限面前,大部分企业更多地 将评估等服务作为概念或者辅助手段,目的在于推进其主体业务——产品的销售。即便 今天,无论是卖防火墙的,还是卖控制网关的,大部分以产品起家的安全公司,在安全 风险评估这个环节,仍有“挂羊头,卖狗肉”之嫌。从采访的情况看,目前,能够提供 完整而真实的安全风险评估的企业并不多。 坚定者的殊途同归 无论是最早提出安全服务概念的绿盟,还是爆发力十足的启明星辰,他们的共 同之处在于是安全服务的坚定实践者。 在 2000 年就把服务作为自己的主营业务,绿盟无疑走过一段并不平坦的路。尽 管在适应市场的过程中,绿盟也陆续推出相关的网络入侵检测产品、抗拒绝服务产品。 但这些产品也多是围绕服务需要开发的,目的在于形成与服务的互动。应该说,绿盟自 始至终都是安全服务的坚持者。最为业界津津乐道的是,绿盟网罗了不少高手,这些网 络安全的守护者,构成了绿盟最难被人超越的技术壁垒。 成立于 1996 年的启明星辰在安全检测产品方面一直有着骄人的成绩。 迄今为止, 已经承担了国家级、部级重点信息安全科研项目三十多项。从 2002 年开始,启明星辰开
始逐渐加大安全风险评估服务的投入力度。“2003 年上半年,安全风险评估的单子比预 计的翻了一倍,”刘恒说。凭借多年的技术积累与良好的客户关系,启明星辰在评估市 场可谓厚积薄发,雄厚的人才储备,使启明星辰一出手就占了先机。 服务好坏,响应速度显然是服务一个重要的衡量指标。因此,本地化在服务中 更易突现其作用。地处深圳的安络科技在南方市场因此具有优势。而中国市场向来南方 先行的特征,又让安络科技比别人更有机会积累宝贵的评估经验。“目前,来自评估的
业务已经占到总收入的 60%,”谢朝霞说,“客户多来自银行和电信,单子很多,规模 一般在几万到几十万。”具体到评估内容,安络强调应用系统的安全评估与安全管理的 规范上。而这一点,对供应商的行业理解要求很高。 另外,安氏在安全风险评估方面业务开展得也比较早,通过代理 ISS 的几个检 测工具,安氏早期获得了不错的市场口碑。与安氏类似,玛赛网络也曾在这个市场显山 露水,并为业界培养了不少人才。但是,因为人事变动等原因,玛赛已经被投资方—— 亚信收回,它下一步的市场举动还有待观察。而原来以产品为主的中科网威,近期开始 向服务倾斜,并召集了不少精英,意欲在这个潜力巨大的市场一展身手。 安全评估很重要,应该每年至少做一次。我们对目前得到的服务基本满意,但 就是价格太贵了。 ——深圳电信 陈波 目前,数据业务占的比例还不高,相关的网络攻击虽然有,但并未构成太大的 威胁。因此,安全风险评估对我们来说,还不是眼下最要紧的事。 ——湖北移动 张明峻
信息系统安全风险评估应用:评估过程
育龙网 WWW.CHINA-B.C0M 2009 年 05 月 21 日 来源:互联网
育龙网核心提示: 信息的安全防范工作一直是整个信息系统安全防范工作中 的重点之一。在本文中就以信息安全风险评估对象中的网络操作痕迹信息检查为
信息的安全防范工作一直是整个信息系统安全防范工作中的重点之一。在本文 中就以信息安全风险评估对象中的网络操作痕迹信息检查为评估项目, 来说明一次安全风险 评估该如何具体地去做。 一、安全风险评估准备阶段 在每次风险评估开始之前,一个最好的保证评估过程顺利完成,评估结果真实有效的 方法, 就得为此制定一个风险评估策略。 但如果只是对某个独立的或者是临时决定的小评估
项目进行风险评估, 而且你和你的评估团队以前经常对些小评估项目进行风险评估, 那么, 只要为它做一些相应的准备工作就可以直接进行评估了。 风险评估策略的具体内容是根据实际的评估对象和评估项目来决定的,因此,不同的 评估对象的风险评估策略是不相同,就是同一评估对象,如果评估的具体项目不同,其风险 评估策略也不会相同。 1、制定风险评估策略 一个好的风险评估策略,应当包括下列所示的内容: (1)、指定评估小组成员 信息风险评估小组担负着机构的风险评估工作,其成员要能代表整个机构。同时,成 员必需在人员安全评估(确定某个人员可以信任风险评估工作)通过后确定。具体的成员应 当包括:IT 部门主管、风险评估负责人、系统或网络管理员、信息安
全技术人员,还可以 包括安全产品供应商代表及合作伙伴代表等。 评估人员确定后,就要分配相应的评估任务给具体的人员。确定每个评估人员各自的 职责,所要承担的法律责任,并做成文档分发到每个评估人员手中。同时,要为评估任务指 定一个总的负责人,来监督整个评估过程,并协调处理评估过程中出现的临时状况。还要说 明评估结果的填写和上报方式, 如说明每个评估人员完成自己的评测任务, 填上评测结果后, 当上交给风险评估负责人时,还应当与负责人一同签名才能有效。 (2)、确定风险评估的范围和目的 确定风险评估的范围也就是指指定具体的评估对象和评估项目,风险评估的目的就是 指此次风险评估要达到的期望值。 风险评估的目的和范围是相辅相成的, 只有指定了评估对 象中评估项目的风险评估目的, 才知道需要什么样的评估任务来达到这个目的, 也就圈定了 具体的评估范围。 也只有确定了风险评估的范围和目的, 我们的风险评估才能有的放矢地进 行。 在本例中,我们的评估对象是信息安全风险评估;评估项目是网络操作痕迹信息检查; 评估的目的是检查网络中遗留的网络操作痕迹信息中是否含有机构内部机密;具体的评估任 务有:
①、检查机构内部员工 WEB 数据库和缓存中的内容; ②、检查机构内部员工是否通过个人主页、博客、论坛,以及发布网络求职简历的方 式,透露了机构的组织结构,或其它机构内部机密信息; ③、调查机构内部员工是否在使用私人电子邮箱,并且在法律允许的条件下,检查员 工是否通过机构分配的电子邮件发送机构内部机密信息; ④、了解机构内部员工的计算机技术水平,以及了解计算机技术水平较高的员工所处 的部门及其操作权限; ⑤、调查机构内部员工是否在工作时间使用即时通信工具,并在法律条件允许的条件 下监控即时通信的内容; ⑥、使用互联网搜索引擎查找网络中是否存在与机构相关的机密信息,或者可以在各 种特定的新闻组、论坛及博客中搜索; ⑦、检查机构内部员工是否在使用 P2P 软件,在法律条件允许下审查 P2P 通信内容。 (3)、确定本次评估任务的开始和结束的具体日期和时间,如有可能,还有决定具体 的风险评估时间,并在风险评估文档中留出相应的位置用来标明评估工作的开始和结束时 间。 (4) 考虑一些在风险评估过程中可能发生的情况, 、 以不影响正常的业务为基本条件。 应当为此制定一个应对有可能造成业务中断,或造成真实安全事件发生事件时的应急措施。 2、根据评估项目和要完成的评估任务制作风险评估表单 风险评估表单
就是在一张表单上将要评估的项目及评估任务一一列出,然后在进行具 体的风险评估时,就可以按表单中的内容来依次进行。 图 2.1 就是网络操作痕迹信息检查评估项目的风险评估表单。 图 2.1 网络操作痕迹信息检查的风险评估表单 信息安全风险评估
评估项目: 网络操作痕迹信息检查 评估的目的: 检查网络中遗留的网络操作痕迹信息中是否含有机构内部机密 评 估 任 务 红勾 顺序 评 估 任 务 描 述 结果描述 结束时间 评估人 备注 1 检查机构内部员工 WEB 数据库和缓存中的内容 2 检查机构内部员工是否通过个人主页、博客、论坛,以及发布网络求职简历的方式, 透露了机构的组织结构,或其它机构内部机密信息 3 调查机构内部员工是否在使用私人电子邮箱,并且在法律允许的条件下,检查员工是 否通过机构分配的电子邮件发送机构内部机密信息 4 了解机构内部员工的计算机技术水平,以及了解计算机技术水平较高的员工所处的部 门及其操作权限 5 调查机构内部员工是否在工作时间使用即时通信工具,并在法律条件允许的条件下监 控即时通信的内容 6 使用互联网搜索引擎查找网络中是否存在与机构相关的机密信息,或者可以在各种特 定的新闻组、论坛及博客中搜索 7 检查机构内部员工是否在使用 P2P 软件,在法律条件允许下审查 P2P 通信内容
备注: 评估开始时间:年 月 日 时 分 评估结束时间:年 月 日 时 分 项目负责人: 3、考虑完成评估任务时会用到的各种工具,并准备妥当。 这些工具应当是切合本次风险评估任务的,并且在已经通过在某个实验环境中测试已 经证明其有效。在本次风险评估中,会对机构内部人员进行网络操作行为监控,因此,得为 它准备相应的网络操作行为分析设备, 或者是安装有网络操作行为分析软件的计算机, 最好 当然是笔记本电脑。同时,还应当准备好所将设备连接入目标网络的所需的线缆,以及其它 与此次风险评估相关的所有工具和文档,并将它们统一管理。 一个风险评估策略不仅可以包括上面已经列出的这四个方面,还可以在其中添加与评 估任务实际需求相关的内容, 例如加入说明此次评估任务的具体流程和细节, 各种注意事项 等等。 并要求所有的评估人员, 严格按照这个风险评估策略中的内容来进行具体的评估工作。 一个风险评估策略是一个需要技术和经验并重的工作,而且需要考虑的内容很多,一 个人不可能将风险评估项目相关的所有方面考虑周到。因此,在制定风险评估策略时,应当 发动所有评估人员,以及评估对象的使用人员和设备供应商代表等一起来分析制定。 对于
信息系统风险评估来说,如果准备工作越充分,后续的风险评估过程就越有效率, 评估过程中出现的错误就越少, 评估的最终给果就越真实有效。 如果在准备过程中疏忽了某 些内容, 特别是制定的安全风险评估策略出现考虑不周的情况, 要是没能在执行风险评估前 检查出来,就会使最终的风险评估结果偏离实际,这样就会让我们空担心一场,或空欢喜一 场。 二、安全风险检测阶段 当所有风险评估工作的事前准备工作全部妥善完成后,就可以按风险评估策略中确定 的日期和时间, 开始对指定的评估对象的评估项目做相应的安全风险评估。 安全风险的评估 过程就是使用具体的方法, 来解答在准备阶段制定的评估项目表单中所有列出的评估任务的 过程。
要完成风险评估表单列出的评估任务,需要使用一些针对某个评估任务的具体解决方 法。解决评估任务的方法有很多种,包括问卷调查、访谈、模拟社会工程攻击、使用风险评 估工具(包括软硬件方式的工具)、审查各种日志、审查各种设备和安全设备的配置文档, 以及使用实际的模拟或真实的攻击来检验等方法, 都可以用来解答评估项目中所需要完成的 评估任务。 其中的某些方法只对某个评估任务有效,而一些工具可能一次自动完成多个项目。为 了能减少使用工具产生的误报和漏洞, 可以使用二种以上的工具来检测同一个评估任务, 或 者使用手工测试的方式来确认检测结果的真实性。 同时,在进行某些评估任务的评估工作时,例如系统弱点扫描,应当从由外向内看和 由内向外看的两个方式分别进行。 进行由外向内看的测试时, 是试图从组织网络边界的外部 检测系统, 它能为我们提供一个从外部攻击相同的方式来审视系统的安全性。 而进行由里向 外看测试时,我们就应该从内部人员对系统使用权限的角度,去审查系统的安全性,此时, 我们会得到比由外向内看更多的安全信息。 恰当地使用这两种方式, 能将目前大部分的安全 威胁都考虑进来。 每个风险评估项目中的所有评估任务,如没有特殊要求,就必需按照风险评估表单中 排列的顺序来进行。这是因为在评估过程中,当前的评估任务完成后产生的结果,可能会用 来作为下一个任务的检测条件。 如果此时评估的顺序相互置换, 那么就会造成错误的最终评 估结果。 在本文中的网络操作痕迹信息检测评估项目中,所有的评估任务都是由内向外看的方 式来进行的。 这些评估任务可以通过机构员工档案审查, 检查员工使用的计算机中的浏览器 COOKIE,检查机构 WEB 服务器缓存,审查机构边界位置网络操作行为管理
设备的各种日志, 通过网络搜索引擎,通过搜索一些独特的位置(如新闻组、博客及论坛)来完成。同时,还 可以通过模拟发送机密信息的方式, 审查已有的网络操作行为监控设备是否能拦截它发送到 互联网中, 是否能够限制员工使用即时通信软件和 P2P 软件, 员工是否可以突破封锁等任务。 并且检验网络操作行为监控设备是否能将违规行为记录到相应的日志当中, 能否提供有效的 警报,收到警报能否产生有效的拦截等等。 有时,会将所有的评估任务分配给几个人来进行,因此,当某个评估人员完成属于他 (她)的评估任务后,就应当在评估任务答案后评估人一栏中签上他的名字。当所有评估任 务完成后, 将已经填入评测答案和评估人签名的风险评估表单上报给评估负责人, 经评估负
责人确认并签字后, 这个风险评估表单中的内容才能算真正有效, 并在风险评估表单中填入 评估结束时间。然后就可以进入下一个风险评估环节。 三、信息系统安全风险评估对象风险检测结果分析及给出评估报告阶段 当评估项目的所有评估任务完成后,就应当组织整个评估人员,将风险评估表单中每 个评估任务的评测结果分析并汇总,给出一个具体安全和风险等级。然后,通过分析目前可 以使用的安全防范技术, 从机构可以接受的安全风险防范投入成本出发, 同时给出一个相应 的安全风险解决方案, 并在解决方案中说明方案实施后能解决的风险, 达到的具体安全等级, 以及仍然存在的风险状况等内容。所有的这些信息都可以一个报告文件的方式记录下来。 每个信息系统安全风险评估报告都是针对某个具体的评估对象而言的。在本文的实例 中, 应当给出一个包括下列内容的风险评估报告, 其它评估对象的风险评估报告给出的内容 至少也应当包括下列所示的内容: 1、列出完成的评估任务清单; 2、列出评估对象目前存在的威胁和弱点,给出具体的安全和风险等级; 3、列出防范这些检测到的威胁和弱点的保障措施; 4、说明这些安全建议是属于物理、管理、还是技术控制; 5、说明实施这些给出的安全建议后会带来的效果; 6、说明每一个具体的安全建议,能将风险减少到什么程度; 7、安全修补后,评估对象能达到什么样的安全等级; 8、安全修补后,还有什么风险没能完全控制,应当如何进一步控制; 9、说明实施这些安全修补措施具体应当花费的安全成本。 有些时候,风险评估报告中不一定要求给出具体的安全修补建议。但是,当检测到的 弱点可能给机构信息系统带来中等或高等安全风险时, 就应当按要求给出针对性的安全解决 方案安全
风险评估报告的内容可以作为安全策略的一个强有力的补充, 你甚至可以将它们的
处理建议加入到已有的安全策略当中, 以保证安全策略的强壮性。 安全风险评估报告同时也 可以作为上报给机构领导或评估小组领导的书面报告, 你可以在报告中标出哪些方面是必需 要修补的,以便能让上级领导赞同你的建议。 这样,你要确保你的安全风险评估报告的有效性和权威性。有效性说明这份报告是在 真实检测和分析的基础上形成的, 而且时间与报告的时间相吻合。 权威性是指这份报告应当 出自整个评估小组在检测分析之上, 并不是某个人凭空想象造出来的。 并且有整个参与人员 的所有手工签名, 以及标出所有评估都是参照某个国家或国际标准来评定具体安全和风险级 别的。 四、后期安全维护阶段 后期安全维护其实只是信息系统安全风险评估过程中的一个附加阶段。对于专门的风 险评估机构或安全公司来说, 当给出具体的安全风险评估报告后, 就表明此次风险评估任务 全部结束。但是,对于评估对象所在的机构来说,安全风险评估工作的结束,只是表示另一 个重要的任务,安全修补任务的开始。 后期安全维护就是按照风险评估报告中给出的安全修补建议,决定实施额外的管理和 安全防范措施, 以便能修正现有的安全策略, 降低目前存在的弱点可能被威胁利用后带来的 风险水平。 在安全修补实施的过程中,如果有些安全弱点不能按要求进行修补,你应当将它们记 录下来,并上报给机构技术负责人。 另外,非常重要的一点就是:在所有的安全修补工作按要求全部完成后,一定要按本 文所描述的风险评估过程重新对修补后的评估对象进行一次复查评估, 以便确认修补后评估 对象是否真正达到了期望的安全水平。同时,也能给出仍然不能防范的安全弱点,以及这些 弱点目前应当如何应对才能降低发生的可能。 从这里我们就可以看出,信息系统安全风险评估是一个风险评估准备、风险评测、给 出风险报告与后期维护四者之间不断循环往复的处理过程。
范文二:火灾风险评估概念辨析
第一章 火灾风险评估概念辨析
学习要求
通过本章学习,应了解火灾风险识别事故致因理论基本内容、火灾危险源可能带来的风险和控制危险发生的措施,掌握第一类火灾危险源和第二类火灾危险源分类方法,熟练辨识常见的第一类火灾危险源和第二类火灾危险源。
本章介绍了火灾风险识别的事故致因理论,系统介绍第一类火灾危险源和第二类火灾危险源的分类和识别过程。
火灾风险评估是查找评估对象面临的火灾风险的来源的一个过程。火灾风险识别是开展火灾风险评估工作所必需的基础环节,只有充分、全面地把握评估对象所面临的火灾风险的来源,才能完整、准确地对各类火灾风险进行分析、评判,进而采取针对性的火灾风险控制措施,确保将评估对象的火灾风险控制在可接受的范围之内。一般情况下,火灾风险的来源不是一成不变的,而是与评估对象的特点息息相关。此外,由于人们对火灾风险概念的认识不同,对火灾风险来源的理解也会存在差异,因此最终的风险识别结果也会发生一些变化,但是这种变化通常不会影响最终的评估结果,只是评估过程因人而异。总体而言,火灾风险的来源与火灾的发生发展过程密切相关,而由于火灾的发生发展过程具有一定的随机性,因此,火灾风险评估也具有较强的动态特性。
第一小节 第一节 火灾风险评估概念辨析
本节介绍火灾隐患、火灾危险源、火灾风险、火灾风险源、火灾危险性等火灾风险评估相关概念,具体对火灾隐患与火灾风险、火灾危险源与火灾风险源以及火灾危险、火灾
危险性与火灾风险之间的差异进行了辨析。
一、火灾隐患与火灾风险
‘’火灾隐患‘’ 是消防监督管理中常用的一个词语,又可以分为一般火灾隐患和重大火灾隐患。根据资料,较早的定义分别为:一般火灾隐患是指存在违反消防法律法规行为,这种行为有导致火灾的可能性或在火灾时会产生一定的危害后果;重大火灾隐患是指严重违反消防法律、法规行为,可能导致火灾或在火灾发生时造成重大人员伤亡或者重大财产损失。根据这两个定义,火灾隐患是首先是一种违反法律法规的行为;其次,在定义中对发生火灾的可能性及火灾发生后导致的后果进行了度量。《重大火灾隐患判定方法》(GA 653—2006)对重大火灾隐患进行了定义:重大火灾隐患是指违反消防法律法规,可能导致火灾发生或火灾危害增大,并由此可能造成特大火灾事故后果和严重社会影响的各类潜在不安全因素。从上述定义看,火灾隐患本身属于火灾风险的一个方面,但是与火灾风险相比,后者涵盖了前者的内容。比前者更为全面。开展火灾风险评估,首先就是要进行火灾隐患排查,但是火灾隐患排查不完全等同于火灾风险评估。一般情况下,凡是存在火灾隐患的地方,就一定会有火灾风险;但是有火灾风险的地方,不一定有火灾隐患。例如,在一些古文物建筑和城镇中的一些老旧场所中可能导致但火灾隐患定义是分别对火灾发生可能性和火灾后果进行度量的。最近有文献对火灾隐患和重大火灾隐患进行了定义,但没有对一般火灾隐患进行定义。其中:火灾隐患是指可能导致火灾发生或火灾危害增大的各类潜在不安全因素;重大火灾隐患是指违反消防法律法规,可能导致火灾发生或火灾危害增大,并由此可能造成特大火灾事故后果和严重社会影响的各类潜在不安全因素。然而,修改后的火灾隐患定义没有反映出违反法律法规这一前提,从字面上看,“患”本身就是一种不利的事情,应该进行治
理。但是从火灾隐患的定义表述中,并没有指明违反法律法规这一前提,既使存在不安全因素,也有可能未有相应的执法依据,只能通过协商解决。从上述定义看,火灾隐患本身属于火灾风险的一个方面,但是与火灾风险相比,后者涵盖了前者的内容,比前者更为全面。开展火灾风险评估,首先就是要进行火灾隐患排查,但是火灾隐患排查不完全等同于火灾风险评估。一般情况下,凡是存在火灾隐患的地方,就一定会有火灾风险;但是有火灾风险的地方,不一定有火灾隐患。例如:在一些古文物建筑和“城中村”等老旧场所中,由于年代较为久远,这些建筑在建时还没有相应的建筑消防设计规范,或者随着消防设计规范的修订,可接受水平的提高,一些原本符合消防设计规范的建筑而变得不符合规范,但是又没有相应的规范和法规对此进行说明。从这个意义上来说,这些建筑不存在火灾隐患,但是存在着很高的火灾风险。因此说,这二者既有联系,又有区别。火灾隐患与火灾风险的关系如图 5-2-1 所示。
二、火灾危险源与火灾风险源
早期的安全著作将影响系统安全的因素统称为危险源,分为第一类危险源和第二类危险源。按照二类危险源理论。按照危险源在事故发生、发展过程中的作用,危险源可分为以下两类:
第一类危险源是指产生能量的能量源或拥有能量的载体。它的存在是事故发生的前提,没有第一类危险源就谈不上能量或危险物质的意外释放,也就无所谓事故。由于第一类危险源在事故时释放的能量是导致人员伤害或财物损坏的能量主体,所以它决定着事故后果的严重程度。
第二类危险源是指导致约束、限制能量屏蔽措施失效或破坏的各种不安全因素。它
是第一类危险源导致事故的必要条件,如果没有第二类危险源破坏第一类危险源的控制,也就不会发生能量或危险物质的意外释放。第二类危险源出现的难易决定事故发生可能性的大小。
根据上述危险源分类,火灾中的第一类危险源包括可燃物、火灾烟气及燃烧产生的有毒、有害气体成分;第二类危险源是人们为了防止火灾发生、减小火灾损失所采取的消防措施中的隐患。对于第一类火灾危险源,人们普遍接受。按照上述表述,火灾自动报警、自动灭火系统、应急广播及疏散系统等消防措施属于第二类危险源。因此,对火灾危险源进行界定,将其含义限定为引起火灾的一些因素,同时引入火灾风险源的概念,则会容易理解。应该说,关于危险源和风险源的概念,来自不同的两个方向。危险源首先来自于理论上的定义,而风险源则来自于实践的需要,采用由实践向理论的提升,将会有更大的适用性。火灾危险源与火灾风险源的关系如图 5-2-2 所示。
三、火灾危险、火灾危险性与火灾风险
危险所表达的是某事物对人们构成的不良影响或后果等,它强调的是客体,是客观存在的随机现象;风险表达的则是人们采取了某种行动后可能面临的有害后果,
强调的是客
体,是人们将遭受的危害或需要承担的责任;’而危险性不仅指火灾事件发生的可能性,而且也包括火灾危险的程度及产生危害的后果。进步研究认为:火灾危险不仅指火灾事件的可能性,而且也包括火灾危险的程度及产生危害的后果,它强调的是客体(火灾事件本身),是客观存在的随机现象;火灾风险是对火灾引起人的生命、健康、财产和环境遭受潜在危害后果的认识,火灾风险的大小通常用火灾发生的几率乘以火灾后果的期望值来衡量。它表达的是人们采取了某种行动后可能面临的危害后果,强调的主体(火灾的危害对象),隐含人们将遭受的危害或需要承担的责任。而根据的英文翻译,似乎最初使用火灾危险性这一概念时表达的就是目前所关注的火灾风险。这些不同概念的相似性可能会导致推广和普及火灾风险评估作用的怀疑,因此,有必要对其作进一步的界定。
为了对火灾危险、火灾危险性和火灾风险这3个相似概念进行界定,此处将火灾危险、火灾危险性和火灾风险分为三个层次。火灾危险作为第一个层次,是火灾风险的基本来源,关心的目标对象能否着火的问题。如果不存在火灾危险,则火灾风险则不会存在。例如:在一幢满桌椅的建筑内,如果不使用明火、无任何电气线路和用电设备,以及无其它任何起火的原因存在,则可以认为该建筑根本不存在任何火灾风险。火灾危险性作为第二个层次,回答的是物质能否着火以及着火后会有多大的规模。在《建筑设计防火规范》(GB50016-2014)中有很多地方提及到火灾危险性,例如:“表 3.1.1 生产的火灾危险性分类” 和“表
3.1.3 贮存物品的火灾危险性分类”,从其内容看,主要是从物质的闪点、爆炸极限以及其它发生氧化燃烧或爆炸的条件进行分类,重点是针对物质的物理属性。因此,如此进行界定在大多数情况下是适用的。火灾风险作为第三个层次,回答的是物质着火的概率以及火灾发生后的预期损失情况。火灾危险、火灾危险性和火灾风险之间的关系如图 5-2-3 所示。采用这三个层次的界定,一般情况下可以解释火灾危险源评估、火灾危险性评估和火灾风险评估之间的区别。
范文三:研究报告风险评估概念
风险评估(Risk Assessment) 是指,在风险事件发生之前或之后(但还没有结束),该事件给人们的生活、生命、财产等各个方面造成的影响和损失的可能性进行量化评估的工作。即,风险评估就是量化测评某一事件或事物带来的影响或损失的可能程度。
目录
什么是风险评估
风险评估任务
风险评估过程注意事项
风险评估的三种可行途径
1. 风险评估的
常用方法
风险评估项目建议书格式
什么是风险评估
风险评估任务
风险评估过程注意事项
风险评估的三种可行途径
1. 风险评估的
常用方法
风险评估项目建议书格式
展开
编辑本段什么是风险评估
从信息安全的角度来讲,风险评估是对信息资产(即某事件或事物所具有的信息集)所面临的威胁、存在的弱点、造成的影响,以及三者综合作用所带来风险的可能性的评估。作为风险管理的基础,风险评估是组织确定信息安全需求的一个重要途径,属于组织信息安全管理体系策划的过程。
编辑本段风险评估任务
风险评估的主要任务包括:
识别组织面临的各种风险
评估风险概率和可能带来的负面影响
确定组织承受风险的能力
确定风险消减和控制的优先等级
推荐风险消减对策
编辑本段风险评估过程注意事项
在风险评估过程中,有几个关键的问题需要考虑。
首先,要确定保护的对象(或者资产)是什么,它的直接和间接价值如何,
其次,资产面临哪些潜在威胁,导致威胁的问题所在,威胁发生的可能性有多大,
第三,资产中存在哪里弱点可能会被威胁所利用,利用的容易程度又如何,
第四,一旦威胁事件发生,组织会遭受怎样的损失或者面临怎样的负面影响,
最后,组织应该采取怎样的安全措施才能将风险带来的损失降低到最低程度,
解决以上问题的过程,就是风险评估的过程。
进行风险评估时,有几个对应关系必须考虑:
每项资产可能面临多种威胁
威胁源(威胁代理)可能不止一个
每种威胁可能利用一个或多个弱点 编辑本段风险评估的三种可行途径
在风险管理的前期准备阶段,组织已经根据安全目标确定了自己的安全战略,其中就包括对风险评估战略的考虑。所谓风险评估战略,其实就是进行风险评估的途径,也就是规定风险评估应该延续的操作过程和方式。
风险评估的操作范围可以是整个组织,也可以是组织中的某一部门,或者独立的信息系统、特定系统组件和服务。影响风险评估进展的某些因素,包括评估时间、力度、展开幅度和深度,都应与组织的环境和安全要求相符合。组织应该针对不同的情况来选择恰当的风险评估途径。目前,实际工作中经常使用的风险评估途径包括基线评估、详细评估和组合评估三种。
基线评估
如果组织的商业运作不是很复杂,并且组织对信息处理和网络的依赖程度不是很高,或者组织信息系统多采用普遍且标准化的模式,基线风险评估(Baseline Risk Assessment)就可以直接而简单地实现基本的安全水平,并且满足组织及其商业环境的所有要求。
采用基线风险评估,组织根据自己的实际情况(所在行业、业务环境与性质等),对信息系统进行安全基线检查(拿现有的安全措施与安全基线规定的措施进行比较,找出其中的差距),得出基本的安全需求,通过选择并实施标准的安全措施来消减和控制风险。所谓的安全基线,是在诸多标准规范中规定的一组安全控制措施或者惯例,这些措施和惯例适用于特定环境下的所有系统,可以满足基本的安全需求,能使系统达到一定的安全防护水平。组织可以根据以下资源来选择安全基线:
国际标准和国家标准,例如BS 7799-1、ISO 13335-4;
行业标准或推荐,例如德国联邦安全局IT 基线保护手册;
来自其他有类似商务目标和规模的组织的惯例。
当然,如果环境和商务目标较为典型,组织也可以自行建立基线。
基线评估的优点是需要的资源少,周期短,操作简单,对于环境相似且安全需求相当的诸多组织,基线评估显然是最经济有效的风险评估途径。当然,基线评估也有其难以避免的缺点,比如基线水平的高低难以设定,如果过高,可能导致资源浪费和限制过度,如果过低,可能难以达到充分的安全,此外,在管理安全相关的变化方面,基线评估比较困难。
基线评估的目标是建立一套满足信息安全基本目标的最小的对策集合,它可以在全组织范围内实行,如果有特殊需要,应该在此基础上,对特定系统进行更详细的评估。
详细评估
详细风险评估要求对资产进行详细识别和评价,对可能引起风险的威胁和弱点水平进行评估,根据风险评估的结果来识别和选择安全措施。这种评估途径集中体现了风险管理的思想,即识别资产的风险并将风险降低到可接受的水平,以此证明管理者所采用的安全控制措施是恰当的。
详细评估的优点在于:
1、组织可以通过详细的风险评估而对信息安全风险有一个精确的认识,并且准确定义出组织目前的安全水平和安全需求;
2、详细评估的结果可用来管理安全变化。当然,详细的风险评估可能是非常耗费资源的过程,包括时间、精力和技术,因此,组织应该仔细设定待
评估的信息系统范围,明确商务环境、操作和信息资产的边界。
组合评估
基线风险评估耗费资源少、周期短、操作简单,但不够准确,适合一般环境的评估;详细风险评估准确而细致,但耗费资源较多,适合严格限定边界的较小范围内的评估。基于次实践当中,组织多是采用二者结合的组合评估方式。
为了决定选择哪种风险评估途径,组织首先对所有的系统进行一次初步的高级风险评估,着眼于信息系统的商务价值和可能面临的风险,识别出组织内具有高风险的或者对其商务运作极为关键的信息资产(或系统),这些资产或系统应该划入详细风险评估的范围,而其他系统则可以通过基线风险评估直接选择安全措施。
这种评估途径将基线和详细风险评估的优势结合起来,既节省了评估所耗费的资源,又能确保获得一个全面系统的评估结果,而且,组织的资源和资金能够应用到最能发挥作用的地方,具有高风险的信息系统能够被预先关注。当然,组合评估也有缺点:如果初步的高级风险评估不够准确,某些本来需要详细评估的系统也许会被忽略,最终导致结果失准。
编辑本段风险评估的常用方法
在风险评估过程中,可以采用多种操作方法,包括基于知识(Knowledge-based)的分析方法、基于模型(Model-based)的分析方法、定性(Qualitative)分析和定量(Quantitative)分析,无论何种方法,共同的目标都是找出组织信息资产面临的风险及其影响,以及目前安全水平与组织安全需求之间的差距。
基于知识的分析方法
在基线风险评估时,组织可以采用基于知识的分析方法来找出目前的安全状况和基线安全标准之间的差距。
基于知识的分析方法又称作经验方法,它牵涉到对来自类似组织(包括规模、商务目标和市场等)的“最佳惯例”的重用,适合一般性的信息安全社团。采用基于知识的分析方法,组织不需要付出很多精力、时间和资源,只要通过多种途径采集相关信息,识别组织的风险所在和当前的安全措施,与特定的标准或最佳惯例进行比较,从中找出不符合的地方,并按照标准或最佳惯例的推荐选择安全措施,最终达到消减和控制风险的目的。
范文四:第10讲风险评估的概念
第十讲风险评估的概念
风险评估是对信息资产面临的威胁、存在的弱点、造成的影响,以及三者综合作用而带
来风险的可能性的评估。
作为风险管理的基础,风险评估(Risk Assessment)是组织确定信息安全需求的一个重
要途径,属于组织信息安全管理体系策划的过程。风险评估的主要任务包括: ?
?
?
?
? 识别组织面临的各种风险 评估风险概率和可能带来的负面影响 确定组织承受风险的能力 确定风险消减和控制的优先等级 推荐风险消减对策
在风险评估过程中,有几个关键的问题需要考虑。首先,要确定保护的对象(或者资产)
是什么?它的直接和间接价值如何?其次,资产面临哪些潜在威胁?导致威胁的问题所在?
威胁发生的可能性有多大?第三,资产中存在哪里弱点可能会被威胁所利用?利用的容易程
度又如何?第四,一旦威胁事件发生,组织会遭受怎样的损失或者面临怎样的负面影响?最
后,组织应该采取怎样的安全措施才能将风险带来的损失降低到最低程度?
解决以上问题的过程,就是风险评估的过程。
这里需要注意,在谈到风险管理的时候,人们经常提到的还有风险分析(Risk Analysis)
这个概念,实际上,对于信息安全风险管理来说,风险分析和风险评估基本上是同义的。当
然,如果细究起来,风险分析应该是处理风险的总体战略(它包括风险评估和风险管理两个
部分,此处的风险管理相当于本文的风险消减和风险控制的过程),风险评估只是风险分析
过程中的一项工作,即对可识别的风险进行评估,以确定其可能造成的危害。 进行风险评估时,有几个对应关系必须考虑:
?
?
? 每项资产可能面临多种威胁 威胁源(威胁代理)可能不止一个 每种威胁可能利用一个或多个弱点
更详细的内容,我们会在后面逐步展开。
范文五:航天器概念设计风险评估
A RISK EVALUATION APPROACH FOR SAFETY IN AEROSPACE PRELIMINARY DESIGN Joseph R. Fragola
Science Applications International Corporation
265 Sunrise Highway, Suite 22
Rockville Centre, NY 11570
516-764-5218/764-5286
Blake F. Putney
Science Applications International Corporation
4920 El Camino Real
Los Altos, CA 94022
650-960-5948/960-5965
ABSTRACT
The preliminary design phase of any program is key to its eventual successful development. The more advanced a design the more this tends to be true. For this reason the preliminary design phase is particularly important in the design of aerospace systems. Errors in preliminary design tend to be fundamental and tend to cause programs to be abandoned, or to be changed fundamentally, and at great cost later in the design development.
In the past aerospace system designers have used the tools of systems engineering to enable the development of designs which were more likely to be functionally adequate. However to do so has meant the application significant resources to the review and investigation of proposed design alternatives. This labor intensive process can no longer be afforded in the current design environment. The realization has led to the development of an approach that attempts to focus the tools of systems engineering on the risk drivers in the design. One of the most important factors in the development of successful designs is adequately addressing the safety and reliability risk. All too often these important features of the developed design are left to afterthoughts as the design gives sway to the more traditional performance focus. Thus even when a successful functional design is forthcoming significant resources are often required to reduce its reliability and safety risk to an acceptable level.
In the USA NASA has clearly indicated, in the aftermath of the Challenger accident and more recent Mars Mission failures, that safety and reliability risks taken to enhance performance are no longer acceptable. Further, NASA has advanced policies, goals, and requirements which are extremely challenging in the risk area. The question is how can these goals be met in a developed design, and more importantly in the near term, how can NASA select design alternatives at the preliminary design stage which are more likely to meet these challenging reliability and safety risk requirements within schedule and cost constraints?
The issue is extremely challenging and confounding to NASA and its supporting contractors. However the recent completion and broad based circulation of the integrated shuttle risk assessment throughout NASA has indicated a potentially feasible approach to address this issue. This approach, which will be discussed in this paper, builds upon the experience base of the integrated shuttle risk assessment and its recent expansions and applications to the evaluation of newly proposed launcher designs. The approach used the shuttle developed PRA models and associated data sets as functional analogs for new launcher functions. The concept being that the functions of any launcher would be characterized by the associated models developed for those functions on the shuttle. Once this functional decomposition and reconstruction has been accomplished a proposed new design is compared on a function by function basis and specific design enhancements that have significant promise of reducing the functional risk over the shuttle are highlighted. The potential for enhancement is then be incorporated into those functions by suitable modification of the shuttle models and or the associated quantification data sets representing those design features addressed by the new design. The level of risk reduction potential is then estimated by those component failure modes and mechanisms identified for the shuttle function and eliminated in the new design. In addition heritage data that would support the claims of risk reduction for those failure modes and mechanisms that remain albeit at a reduced level of risk are applied.
While this “lego block” functional comparison approach would not suffice to allow for adequate absolute estimates of potential risk it is felt that it has been shown to be sufficient to allow NASA to investigate the risk relative risk reduction potential of proposed alternative designs. This paper presents an implementation of this approach and its application to
the evaluation of shuttle upgrades and selected 2nd
generation launcher designs. The evaluation not only addresses the potential safety and mission risk reduction potential of the proposed designs but also the risk of their development.
Background
NASA Ames Research Center has initiated a project,
supporting the 2nd
Generation Reusable Launch Vehicle (RLV) Program, to develop an advanced suite of conceptual design tools. The tools will be developed within an object-oriented framework to enable integrated multi-disciplinary, multi-fidelity analysis. The new integrated process as well as the individual “plug and play” tools will be inserted into the Reusable Space Transportation System (RSTS) conceptual analysis environment. In order to meet the program requirements for vehicle and crew safety, new analysis capabilities are being developed and integrated within this framework to provide an assessment of risk of failure of given concepts.
In the past aerospace system designers have used the tools of systems engineering to enable the development of designs that were more likely to be functionally adequate. However to do so has meant the application significant resources to the review and investigation of proposed design alternatives, as can be seen in Figure -1[1]
and the consideration of risk and safety impacts is considered afterwards, perhaps after key aspects of the design are frozen. Because of the comprehensive, but unfocused, nature of the traditional systems engineering process much of the expended effort may be wasted on portions of the design that are not key performance discriminators.
Applications of risk analysis are emerging to provide managers a means of focusing programs on key performance drivers, be they cost, safety, or reliability. Lack of focus can result in considerable difficulties when trying to meet risk goals for a program, and can lead to considerable re-work causing overruns or program cancellation if risk drivers are inadequately considered.
Since risk analysis has typically been performed on detailed design for verification purposes, it has been performed at the component level, typically with Fault Trees and has been viewed as very expensive. In the past designers have hesitated to perform risk analysis on design concepts due to lack of design specifics to allow for analysis with fault trees and component level data. The Risk Oriented Optimization Tool (ROPOT) discussed in this paper was developed to determine if a risk analysis developed from the risk drivers of the shuttle could provide useful program insights
management for a conceptual design.
Figure 1. Potential Overruns when Phase A and B
are Underfunded. In the case of the 2nd
Generation RLV, cost and safety are primary performance drivers, specific risk goals for the program have been established, and significant development risks may be associated with the achievement of both safety risk and cost goals. The focus the project reported here was the development of a risk/safety tool to support the preliminary design phase of the program, and to provide a basis for understanding the safety benefits of new technology, plumbing the design space for attractive design alternatives, and understanding the development risk trades that are inherent to the maturation of the program.
ROPOT Description
The objective of the project was to provide an integrated safety analysis capability for the RSTS environment. Initially as a separate capability but with the longer-term goal of seamless integration with multi-disciplinary performance analysis tools. The combination of these tools will allow the designer to visualize not only the functionality of the design being reviewed under nominal conditions but also the robustness of the design against probabilistically credible failure events. The scope of this task includes the development of a prototypical tool that allows for the evaluation of safety and reliability metrics (specifically Loss of Crew, and Loss of Vehicle) for the space shuttle, the space shuttle upgraded designs, and new RLV (Bimese) designs based upon space shuttle heritage. The tool was developed to interface with analogous physical design tools (e.g. geometric and finite element structural), phenomenological tools (e.g. Computational Fluid Dynamics tools addressing the Aerodynamic and Aerothermodynamic environment), and economic assessment tools (e.g. Net Present Value and Real Options Valuation of alternatives), so as to seamlessly fit into the set of tools envisioned to support the efforts of the NASA Inter-Center Systems Analysis Team (ISAT). A prototype tool was developed in Microsoft Excel.
Although the prototype version of the tool was developed for launchers, its modular nature allows it to be applied to many different technologies.
The Risk Model
The issue of ensuring enhanced reliability and safety in the next generation of launchers is extremely challenging and confounding to NASA and its supporting contractors. However the recent completion and broad based circulation of the integrated shuttle risk assessment throughout NASA[2] indicated to the SAIC team a potentially feasible approach to address this issue. This approach builds upon the experience base of the integrated shuttle risk assessment and its recent expansions and applications to the evaluation of newly proposed launcher designs.
The Shuttle PRA was first evaluated to highlight elements of the shuttle design identified as drivers. Once this was completed, a new structure was developed in a hierarchical fashion. In this hierarchy the depths to which an element was represented was indicative of its risk contribution, and details necessary to capture future conceptual design alternatives. For example, as can be seen from the resulting hierarchy represented in Figure 2 a Shuttle Based risk model is applicable to the Bimese with minimal changes. This implies that the shuttle and its PRA have the potential, if properly structured, to be representative of a more general class of launchers at least for the LOC and LOV end states.
Whether or not this potential could be actualized depends, of course, on the extent of modification of the risk model necessary to allow the shuttle model to be used as a surrogate for a proposed new launcher. These modifications would be expected to take, and did take, two forms: 1) a modification of the frequency of failure of the same basic events in the proposed new design, and 2) the elimination or addition of elements and their
failure contribution.
Figure 2. Loss of Vehicle Model Structure It is expected that the design process of the 2nd Generation RLV will generate many different design alternatives in attempting to meet its cost and safety goals. The risk model will support risk calculations to evaluate the benefit of investments in all aspects of the design. During the evaluation of multiple alternatives it was discovered that the concept of developmental difficulty could provide useful insights to a decision maker. “Difficulty” represents the risk of failing to complete the development process on time to meet the program schedule. Specifically the benefits provided by the promised improved performance or reduced cost of developmental designs must be “discounted”, in the economic sense of the term, by the probability that it will be developed and deployed according to the required deployment date. The more creative the design, the scantier its heritage, and the earlier the phase of its development, the riskier the development.
The quantitative approach employed here to evaluate the developmental risk and thereby the difficulty of development has been generated by SAIC over the past several years[3],[4]. The approach is based upon the systematic evolution of the TRL meter shown in Figure 3 is discussed in the above references and is also heuristically derived from experience.
Log normal distributions are used as a basis for calculating the probability that a specific design element will be successfully deployed at a desired time (achievability). Here the product of the achievability of each developmental element is the overall achievability of the program. The program difficulty at the desired time is the complement of the overall achievability. It should be noted that the concept of difficulty could be applied to all performance measures of a developmental system, not just safety.
Integ.
Figure 3. TRL Barometer Risk Insights A key aspect of applying results of risk assessments is an understanding of how key system elements contribute to risk, and how changes in their reliability change risk. This information provides to user with an intuition about how the risk surface behaves. In this sense the key elements can be viewed as multiple dimensions in the risk space.
The Importance Measure approach is used in traditional risk assessment and it is useful when applied to an existing system. In this case it is not generally feasible to change multiple elements, and large improvements in the system design are difficult to achieve. However, in the early design phases of a system, all system elements are open to improvement, and can be improved in combination with others. This reduces the usefulness of Importance Measures. For example if the Main Engine is identified as contributing 30% to the risk, an improvement program may be put into place to increase engine reliability as much as possible. However, as the engine is improved, other risk contributors may become more important. Continued investment in improving the engine (generally with diminishing returns) will not bring as much benefit as efforts to improve the new dominant risk contributors. This process of switching efforts between elements to achieve an optimal solution generates what is termed a risk “trajectory” through the risk space defined by the set of all achievable values of the risk elements.
A path between the existing or baseline design to an alternative design solution is the risk trajectory. The process of examining various risk trajectories, and understanding how the risk contributors change along the trajectory provides the user without intuition of how risk behaves in the design regime. This information can then be used to sculpt an optimal design/operational solution.
As an example of the usefulness of the risk trajectory concept consider Figure 4 shows how the LOV probability improved as the engine improves holding other design elements constant.
Figure 4. Shuttle Risk Improvement from SSME
Improvement The Figure demonstrates how the LOV probability reduction flattens out as the engine failure rate approaches 3.0 E-7. In this case, improving the engine alone beyond the 3.0 E-7 range will have small relative safety benefit.
Figure 5 below illustrates the same effect for the Bimese
configuration.
Figure 5. Illustration of the Effect of Improvement
of Engine Reliability on Risk In the Bimese case the LOC probability improvement rolls off at 1E-7, showing risk reduction value for a factor of three greater reduction in engine risk. This is primarily due to the fact that the same Engine is included in both the Orbiter and the Booster designs. The risk surface can be further examined by varying other parameters that contribute to risk. The example given in Figure 6 shows how Shuttle risk improves with reliability improvements in the SRB (.3,.5,.7 improvement factors), and the replacement of the Hydrazine powered flight controls with an electric APU (EAPU). This figure illustrates how multiple improvements can be viewed as constituting a trajectory over the risk surface.
Figure 6. Shuttle Improvement Trajectory Design
Trades
Examining how risk changes with design alternatives is useful, but it does not provide the whole story. Risk reduction is not free. Each potential change involves development and operational costs, and difficulty in deploying a new system. Design choices made to improve a system to reduce risk must take into account the development required. To account for alternatives at varying stages of maturity the concept of “difficulty” is introduced. Eventually difficulty can be an input to cost models and the actual economic value of design alternatives can be assessed. Difficulty can be added as another axis in the risk space.
Once the risk space is developed, it can be visualized in various ways. It can be viewed as a carpet plot or from
above as a scatter plot. In this latter case each possible solution has a Risk and Difficulty. Inclusion of uncertainties will create vertical uncertainty error bars around each point and indicate where there is potential overlap between alternatives. Each solution can then be examined to investigate the risk drivers for that particular design alternative.
In evaluating the merit of various design solutions the decision-maker is aided by better understanding how a particular solution compares to the fundamental system
goals. For 2nd
Gen the fundamental goals are 1,000 dollars per pound to orbit, and LOC risk of less than 1 in 10,000 missions. Therefore plots relating a design to cost and risk are appropriate. As mentioned above a key input for the economic calculations is the development schedule. Here difficulty plays a key role. An example of the usefulness of the difficulty concept is provided below.
A risk space was generated for Loss of Crew (LOC), and Loss of Vehicle (LOV). The model generated a risk probability, and a difficulty for 150 design alternatives. In this example it was assumed that system needed to be deployed in 5 years. The resulting scatter plot in Figure 7 shows the results.
Risk vs Difficulty (1-p(achievement)) Space
Difficulty
P r o b a b i l i t y
Figure 7. Risk Difficulty Space Quantified at 5
Years The difficulty factor was based on the assumption of a deployment date of 5 years hence. The resulting plot indicated that there is a wide variation in the difficulty in achieving the lowest risk, and that there are some relatively easy solutions that gain most of the risk reduction benefits. Future displays of this information will allow the user to select a point and display the underlying variables, and generate line segments illustrating how risk and difficulty change by changing design alternatives. A chart of this type could be provided to program managers to help them view the difficulty in achieving the Risk goal. Incidentally, this approach and chart format can be used for any quantitative design goal.
Figure 8 Illustrates the risk surface quantified with a development time of 7 years. As can be seen in the figure, by extending the development time for the vehicle, the program manager reduces the difficulty of
developing alternatives, and a number of additional low difficulty design alternatives become attractive.
Risk vs Difficulty (1-p(achievement)) Space
1.00E-03
2.00E-03
3.00E-03
4.00E-03
5.00E-03
6.00E-03
7.00E-03
Difficulty
P r o b a b i l i t y
Figure 8. Risk Difficulty Space Quantified at 7
Years
A Summary of Insights
As a result of the study the following insights were gained:
1) The development of a risk-based design tool to
aid in programmatic design decision-making is feasible. 2) A simplified “Lego Block” model of the shuttle
can be developed from the PRA 3) The lego block model can be extended to
alternative vehicles by experienced experts within reasonable time and resource constraints 4) Risk Surfaces and Multiple Dimension
Visualizations provide powerful illustrations of the trade space
5) This modeling concept is a viable basis for
development of risk tools for future programs
References
[1] Shishko, R. et.al., “NASA Systems Engineering
Handbook”, SP-6105, June 1995, NASA/JPL, Pasadena, CA. [2] Fragola, J. R., et al., Probabilistic Risk Assessment
of the Space Shuttle: A Study of the Potential of Losing the Vehicle During Nominal Operations, Volume I Final Report, SAIC/NY95-02-25, 28 February 1995. [3] Fragola, J.R. and Maggio, G., “Application of
Probabilistic Program Planning to an Advanced Radiographic Hydrodynamics Facility”, ESA Risk Management Workshop, 30 March – 2 April 1998, ESA/ESTEC, Noordwijk, The Netherlands. [4] Fragola, J.R., “A Heritage Approach to Risk Based
Design”, Presented at the International Mechanical Engineering Conference and Exposition/ASME/SERAD, November 5-10, 2000, Walt Disney World Dolphin, Orlando, Florida.