首页 | 新闻资讯 | 培训认证 | 安全管理 | 病毒分析 | 安全协议 | 网络安全 | 防火墙 | 黑客技术
DB安全 | Web安全 | 入侵检测 | 安全审计 | 设备安全 | 备份恢复 | 安全标准 | 法律法规 | 无线安全
OS安全 | PKI与PMI | 病毒防治 | 隔离网闸 | XML安全 | 网管专区 | 经典案例 | 技术论坛 |  
+ 文章搜索 +
当前位置:首页>>安全管理>>风险分析>>正文
关键字:
范 围:
※推荐文章※
信息技术系统的风险管理指南 (六)
作者: 文章出处: 发布时间:2007-01-23 点击: 字体: 【
自动化弱点扫描工具被用来对一组主机或一个网络进行扫描,以找出已知的弱点(比如系统允许匿名FTP、sendmail中继等)。但是要注意到有些由自动化弱点扫描工具识别出来的潜在弱点可能不表示系统环境中的真实弱点。比如有些这类扫描工具不是根据现场环境和要求来对潜在弱点进行评级。有些由这类扫描工具标记出来的弱点在特定现场可能并不真是一个弱点,因为它们所在环境就要求这么配置它。因此这种测试方法可能产生误报。

  ST&E是另一种用来在风险评估过程中识别IT系统弱点的技术,它包括制定并执行测试计划(比如测试脚本、测试流程、和预期的测试结果)。系统安全测试的意图是测试IT系统的安全控制在操作环境中的有效性,其目的是保证所采用的控制满足批准的软件和硬件安全规范,并实现了机构的安全策略和业界标准。

  穿透性测试可以用来补充对安全控制的检测,并保证IT系统的不同方面都是安全的。当在风险评估过程中采用穿透性测试时,可以用它评估IT系统抵抗故意规避系统安全的能力,其目的是从威胁源的角度来对IT系统进行测试,以识别出IT系统保护计划中可能被疏忽的环节。这类可选安全测试的结果将有助于对系统弱点的识别。

2.3.3 开发安全需求核对表

  本步中,风险评估人员确定为IT系统所规定的、在系统特征描述中所收集的安全要求是否被现有的或所计划的安全控制满足。一般情况下,系统安全要求可以用表格形式表示,其中对每项要求都有一个解释,解释系统设计或实现确实满足或没有满足安全控制要求。
安全要求核对表包含了基本的安全标准,可以用来对与给定系统相关的资产(人员、硬件、软件、信息)弱点、非自动化流程、过程、信息传输在下列安全方面进行系统化地评价和识别:

  • 管理
  • 操作
  • 技术

表2-3列出了被建议的安全准则,它们用于在每个安全方面对IT系统弱点进行识别。
表格 2-3安全核对项目

  本过程生成的结果是安全要求核对表。可以通过下列政府条例和安全方针等来源(但不限于这些)来编辑这样一个核对表:

  • 1987年计算机安全法案
  • 联邦信息处理标准发布物(FIPS)
  • 2000年11月OMB A-130号通告
  • 1974年隐私法案
  • 已评估IT系统的系统安全计划
  • 机构的安全策略、指南、和标准
  • 业界惯例

NIST SP800-26,《IT系统安全自我表现评估指南》中提供了一个扩充的调查问卷,其中包含了针对一个系统或一组互连系统的具体安全控制目的,这些系统是可以被测试和度量的。控制目的可以根据从安全和隐私方面的法律、政策、以及指南中找到的长期要求直接抽象出来。

  核对表(或调查问卷)的结果能够作为一致性和非一致性评价的输入。这个过程识别了系统、过程、和流程的薄弱环节,它们表示了潜在的弱点所在。

 步骤三的输出--有可能被潜在的威胁源所攻击的系统弱点(观测报告7)清单

2.4 步骤四:控制分析

  本步的目标是对已经实现的、或计划实现的控制进行分析,机构通过这些控制来减小或消除威胁攻击系统弱点的可能性(或概率)。

  要产生一个总体可能性评级来说明一个潜在弱点在相关威胁环境(步骤五中)下被攻击的可能性,就必须要考虑到当前已经实现或计划实现的安全控制。比如,如果威胁源的兴趣或能力级别很低、或如果有有效的安全控制可以消除或减轻危害后果,那么一个弱点(比如系统或流程中的薄弱环节)被攻击的可能性就低。
2.4.1到2.4.2节分别讨论了安全控制方法、控制分类、和控制分析技术。

2.4.1 控制方法

  安全控制包括对技术和非技术方法的运用。技术类控制是那些融入到计算机硬件、软件、或固件中的保护措施(比如访问控制机制、标识和鉴别机制、加密方法、入侵检测软件等等);非技术控制包括管理类和操作类控制,比如安全策略、操作流程、人员、物理、和环境安全。

2.4.2 控制分类

  对控制的技术和非技术方法分类可以更进一步分类成为预防性的或检测性的。这两个子类别可以按如下解释:

  • 预防类控制禁止试图对安全策略的冲突,包括访问控制、加密和鉴别;
  • 检测类控制对安全策略的冲突或试图冲突发出警告,包括审计追踪、入侵检测方法和校验和。

4.4节进一步从实现的角度对这些控制进行了解释。在风险减缓过程中实现这些控制是在风险评估过程中发现当前或计划中的控制之不足的直接结果。

2.4.3 控制分析技术

  如同 2.3.3节中所讨论,开发一个安全要求核对表或使用一个已有的核对表将有助于以一个有效的和系统化的方式对安全控制进行分析。安全要求核对表可以用来验证安全一致性,也可以验证不一致性。因此为反映机构控制环境的变化(比如安全策略、方法、和要求的变化),有必要对核对表进行更新以保证其有效性。

 步骤四的输出--IT系统已经实现或计划实现的控制清单,用以降低系统弱点被攻击的可能性,从而降低这类负面事件的影响。

2.5 步骤五:可能性分析

  要产生一个总体可能性评级来说明一个潜在弱点在相关威胁环境(步骤五中)下被攻击的可能性,下列支配因素应该被考虑到:

  • 威胁源动机和能力
  • 弱点性质
  • 安全控制的存在和有效性
    一个潜在弱点被一个给定威胁源攻击的可能性可以用高、中、低来表示。表3-4描述了这三个可能性级别。

              表格 2-4可能性定义

第步骤五的输出--可能性级别(高、中或低)

2.6 步骤六:影响分析

  度量风险级别的下一主要步骤是确定对弱点一次成功的攻击所产生的负面影响。在开始影响分析之前,有必要获得以下必要信息(2.1.1节中讨论过):

  • 系统使命(比如IT统运行的过程);
  • 系统和数据的关键性(系统对机构的价值和重要性);
  • 系统和数据的敏感性。


  这些信息可以现有的机构文档中获得,例如使命影响分析报告或资产关键性评估报告。使命影响分析(对有些机构又称为业务影响分析[BIA])根据对资产关键性和敏感性定量或定性的评估,将对机构资产相关的破坏级别进行排序。资产关键性评估对关键或敏感的机构信息资产(比如硬件、软件、系统、服务、以及相关的技术资产)进行识别和排序,从而为机构关键使命提供支持。

  如果这些文档不存在,或对机构IT资产的类似评估还没有进行,那么可以根据要求的保护级别来确定系统和数据的敏感性,以保持系统和数据的可用性、完整性和保密性。不管用何种方法来确定系统及其数据的敏感程度,系统和信息所有者都是确定其系统和信息影响级别的负责人。因此,在分析影响时,适当的途径是同系统和信息所有者面谈。

  因此对安全事件的负面影响可以用完整性、可用性、和保密性三个安全目标(其中一个或几个)的损失或降低来描述。下面列出了每个安全目标的简要描述以及它们没有被满足的后果(或影响):

返回顶部↑】 【推荐好友】 【查看评论
用户名: 新注册) 密码: 匿名评论 [查看评论] 发表评论
评论内容:(不能超过250字,需审核后才会公布,请自觉遵守互联网相关政策法规。
  Copyright © 2004-2005 infosecurity.org.cn . All Rights Reserved
版权所有:中国信息安全组织 系统管理:webmaster@infosecurity.net.cn
本站部分资源来自互联网,如有侵犯您的版权或其他问题,请通知管理员,我们会尽快处理!