ITIL中的安全风险评估一章的节选

声明：本文转载自gnaw0725.blogbus.com，更新网址：http://gnaw0725.blog.51cto.com。

ITIL中的安全风险评估一章的节选:

风险管理的作用

风险管理是IT管理者平衡IT系统及数据的保护成本和保护收益的方法，包括：

• 风险评估（Risk Assessment）；
• 风险消减（Risk Mitigation）；
• 持续评价（Continual Evaluation）；

风险管理的作用在于能够为机构完成其使命提供：

• 更安全的IT系统；
• 更有效的IT安全预算；
• IT系统运行认可（Accreditation）依据；

风险管理的关键角色

• 高级管理人员（Senior Management），为风险管理项目提供有效的资源保证，将风险分析的结果运用于管理决策；
• 首席信息官（Chief Information Officer，CIO），将风险管理原则和方法用于IT计划、预算及其执行活动；
• 系统和信息拥有者（System and Information Owners），支持风险管理项目，并将风险管理原则和方法用于其IT系统和数据的保护中；
• 业务和职能管理人（Business and Functional Managers），将风险管理原则和方法用于业务运行和IT采购决策中，以便IT系统能够更安全、有效地支持业务活动；
• 信息系统安全官（Information System Security Officer，ISSO），IT风险管理项目的具体负责人，制定IT系统风险识别、评估和消减的全面方案，并向高级管理人员提供建议；
• IT安全专业人员（IT security Practitioners），包括网络、系统、应用、数据库管理员、计算机专家、安全分析员、安全顾问等，支持和参与相关IT系统的风险管理工作，包括识别系统中的风险并部署适当的防范措施，为系统提供适当的安全保护；
• 安全意识培训师（Security Awareness Trainers），理解风险管理方法并开发风险管理相关的培训材料，在培训项目中为用户提供培训评估方面的教育。

风险评估

• 系统评定（System Characterization）
• 威胁识别（Threat Identification）
• 缺陷识别（Vulnerability Identification）
• 控制分析（Control Analysis）
• 可能性确定（Likelihood Determination）
• 影响分析（Impact Analysis）
• 风险确定（Risk Determination）
• 控制建议（Control Recommendations）
• 结果报告（Results Documentation）

系统评定

• 确定风险评估工作的范围；
• 勾勒运作授权（或认可）边界；
• 提供定义系统风险的重要信息，这些信息主要包括以下类型：
  • 硬件；
  • 软件；
  • 系统接口（如内部和外部连接）；
  • 数据和信息；
  • 支持和使用IT系统的人员；
  • 系统的使命（如IT系统所起的作用）；
  • 系统和数据的关键程度（如系统的价值或对机构的重要性）；
  • 系统和数据的敏感性。

系统评定应收集的信息

• IT系统的功能需求（Functional Requirements）；
• 系统的用户，包括为系统提供技术支持的系统用户（System Users），和使用系统执行业务功能的应用用户（Application Users）；
• 系统安全政策（Security Policy），包括机构政策（Organizational Policy）、政府要求（Federal Requirements）、法律法规（Law）和业界惯例（Industry Practices）；
• 系统安全架构（System Security Architecture）；
• 当前的网络拓扑（Topology）；
• 保护系统和数据可用性、完整性和保密性的信息存储安全措施；
• IT系统相关的信息流图，如系统接口、系统输入和输出流程图（Flowchart）；
• 用于IT系统的技术控制措施，如支持识别（Identification）和认证（Authentication）、访问控制（Access Control）、审计（Audit）、残留（Residual）信息保护、加密（Encryption）的内建或附加安全功能；
• 用于IT系统的管理控制措施，如行为规则（Rules of Behavior）、安全计划（Security Planning）；
• 用于IT系统的运行控制措施，如人事安全（Personnel Security）、备份（Backup）、应急（Contingency）、复原（Resumption）和恢复（Recovery）操作、系统维护（System Maintenance）、离站存储（Off-Site Storage）、用户账户（User Account）建立和删除规程、用户功能隔离（Segregation）控制；
• IT系统的物理安全措施，如设施安全（Facility Security）、数据中心政策（Data Center Policies）；
• IT系统的环境安全措施，如湿度、温度、水、能源、污染和化学品控制。

系统评定的信息收集技术

• 问卷（Questionnaire），如评估人员设计关于管理和运行控制方面的问卷，将其发放给设计或支持系统的技术或非技术管理人员填写，也可以在现场访问中使用；
• 现场访问（On-Site Interviews），与系统支持和管理人员会面了解系统相关信息，并可以现场了解系统的物理、环境和运行安全措施；
• 文档查看（Document Review），政策文档，如法律文件（Legislative Documentation）、上级指示（Directive），系统文档，如系统用户指南、系统管理手册、系统设计和需求文档、采购文档，安全相关文档，如以前的审计报告、风险评估报告、系统测试结果、系统安全计划、安全政策可以提供大量相关信息；
• 使用自动化扫描工具（Automated Scanning Tool），使用如网络扫描工具等技术方法可以快速获得系统配置信息。

问卷主题举例

• 哪些人是合法用户？
• 用户机构的使命？
• 系统在用户使命中的作用？
• 系统对于用户使命有多重要？
• 系统的可用性需求？
• 机构需要什么信息（包括双向的）？
• 系统生成、使用、处理、存取什么信息？
• 信息对于用户使命有多重要？
• 信息流经的路径？
• 系统处理和存储的信息类型（金融、人事、研发、医疗、控制）？
• 信息的敏感级别？
• 系统的哪些信息不应泄漏给哪些人？
• 信息处理和存储的明确地点？
• 信息存储器的类型？
• 如果信息泄漏给非授权人员会给机构带来怎样的潜在影响？
• 信息的可用性和完整性需求？
• 如果系统或信息不可靠会对机构产生什么影响？
• 机构能够容忍的系统停机时间？这个时间大于平均修复/恢复时间吗？用户还有其它处理或通讯选项吗？
• 系统或安全故障会造成人员伤亡吗？

缺陷识别

缺陷识别（Vulnerability Identification）的目的是编写可能被威胁源利用的系统缺陷清单；

识别系统缺陷的方法包括：

• 使用系统评定阶段的信息收集技术；
• 进行系统安全测试；
• 制定安全需求检查列表（Checklist）；

不同阶段的系统其缺陷识别方法有所不同：

• 设计阶段的系统可关注机构安全政策、所计划的安全规程、系统安全需求定义、开发者的产品安全分析报告等；
• 部署阶段的系统还需关注安全设计文档和系统测试报告；
• 运行中的系统还需关注用于保护系统的安全控制和特性。

缺陷识别的信息来源

使用系统评定阶段提到的信息收集技术获得技术和非技术缺陷相关信息，其来源可包括：

• 以前的风险评估文档；
• 系统审计报告、异常报告、安全检查报告以及测试评估报告；
  缺陷列表，如NIST I-CAT缺陷数据库；
• 安全机构的建议，如FedCIRC和美国能源部计算机事件咨询机构公告、SecurityFocus的邮件列表等；
• 厂商建议；
• 系统安全分析报告。

系统安全测试

• 自动化缺陷扫描工具（Automated vulnerability scanning tool ），对网络及其包含的主机的进行检查，以便发现已公布的系统缺陷，需要对结果进行分析以排除误报（False Positives）；
• 安全测试和评价（Security test and evaluation ，ST&E） ，制定并执行测试计划，以检验系统安全控制的有效性，判断其是否满足设计要求、机构安全政策以及行业标准；
• 渗透测试（Penetration testing），以攻击者的角度和方式对系统进行模拟攻击，以检验系统的抗攻击能力。

制定安全需求检查列表

安全需求检查列表包含基本的安全标准，可以被用于系统化地评价和识别资产（包括人员、硬件、软件和信息）、非自动化规程、方法、信息传输的缺陷，如：

• 管理安全方面的职责设定、连续性支持、事件响应、安全控制检查、人事安全措施、风险评估、安全和技术培训、职责分离、系统授权和再授权、系统和应用安全计划等标准；
• 运作安全方面的空气污染（如烟尘、化学物质）控制、电力供应保障、介质访问和处置、外部数据分配和标记、设施（如计算机房、数据中心、办公室）保护、湿度控制、温度控制、工作站、笔记本、独立计算机控制等标准；
• 技术安全方面的通讯（如拨号、互联、路由器）、密码技术、自主访问控制、识别和认证、入侵检测、对象重用、系统审计等标准。

控制分析

• 安全控制可以减少或消除威胁利用系统缺陷的可能性，要确定系统面临的风险就必须对已部署或计划部署的控制进行分析；
• 控制方法可分为技术方法，即计算机硬件、软件或固件中的安全控制机制，非技术方法，即管理和运作控制方法，如安全政策、运作规程、人事、物理、环境安全控制；
• 控制方法还可进一步分为防御控制，如访问控制、加密、身份认证，检测控制，如审计跟踪、入侵检测和检验和；
• 为了更有效率和更全面地对安全控制进行分析，也可以使用缺陷分析中提到的安全需求检查列表的方法。

可能性确定

确定在当前系统环境中，潜在缺陷被利用的可能性，它取决于：

• 威胁源动机和能力；
• 缺陷性质；
• 现有控制的效力；

可能性可被描述为：

• 高，威胁源具有很强的动机和能力，现有控制无效；
• 中，威胁源具有相当的动机和能力，现有控制具有阻碍其利用缺陷的能力；
• 低，威胁源缺乏动机或能力，现有控制能够防止或有效阻碍其利用缺陷的能力。

影响分析

影响分析是确定一次缺陷的成功利用所造成的负面影响程度，它主要取决于：

• 对系统所执行使命（如该系统执行的业务操作）的影响，可以通过业务影响分析（Business Impact Analysis）确定；
• 系统和数据的关键程度（如系统的价值或对机构的重要程度），可以通过资产关键程度分析确定；
• 系统和数据的敏感性，可通过丧失完整性、可用性、保密性的影响分析确定；

系统和信息的拥有者负责确定其系统和信息受到影响的程度，所以影响分析的主要工作是访问系统和信息的拥有者。

定性与定量分析方法

定量分析，对一些有形的损失，如收入、维修费用、恢复费用可以通过定量的方式衡量；

定性分析，对于另外一些影响，如公众信任、机构信誉、形象和长远利益的损失难以使用定量的方法进行衡量，只能通过定性的方法，如：

• 高，可能导致重要有形资产的巨大损失，可能严重损害机构使命、形象和长远利益，或可能造成人员伤亡；
• 中，可能导致有形资产的严重损失，可能损害机构的使命、形象和长远利益，或可能导致人员伤害；
• 低，导致某些有形资产的损失，可能影响机构的使命、形象和长远利益。

风险确定

确定IT系统的风险水平，每一个威胁/缺陷对的风险等级由以下要素决定：

• 该威胁源试图利用缺陷的可能性；
• 该威胁源成功利用缺陷的影响程度；
• 现有或将要部署的安全控制消减风险的能力；

为了确定风险水平，应首先制定风险等级（Risk Scale）和风险矩阵（Risk Matrix） ；

如将系统某缺陷的风险水平表示为高、中、低三级，管理者可以根据风险等级决定对此缺陷采取何种行动，如：

• 高，必须立即采取校正措施；
• 中，必须制定校正计划，并在给定时间内完成校正；
• 低，管理者可以决定接受此风险，也可以采取校正措施进一步降低风险。

风险矩阵

风险水平可以由威胁的可能性乘以其影响得到，如将威胁可能性分别设为高（1.0）、中（0.5）、低（0.1）三级，将威胁的影响分为高（100） 、中（50）、低（10）三级，可得到如下风险矩阵：

威胁 可能性	威胁的影响
	低（10）	中（50）	高（100）
高（1.0）	低 10 X 1.0 = 10	中 50 X 1.0 = 50	高 100 X 1.0 = 100
中（0.5）	低 10 X 0.5 = 5	中 50 X 0.5 = 25	中 100 X 0.5 = 50
低（0.1）	低 10 X 0.1 = 1	低 50 X 0.1 = 5	低 100 X 0.1 = 10

控制建议

提供消减风险的控制措施建议，应考虑以下因素：

• 建议选项的有效性（Effectiveness）；
• 法律法规（Legislation and Regulation）；
• 机构政策（Organizational Policy）；
• 运作影响（Operational Impact）；
• 安全性和可靠性（Safety and Reliability）；

控制建议将作为风险消减阶段的输入，风险消减阶段将对这些控制选项进行成本效益（Cost-Benefit）分析，并研究其可行性（Feasibility）和对运作（如性能、用户友好）的影响。

结果报告

• 风险评估结束时，应将其结果记录在正式的风险评估报告中，该报告描述系统面临的威胁和缺陷，风险评测的结果，消减风险的安全控制建议等内容；
• 风险评估报告的目的是帮助高级管理人员作出政策、规程、预算、系统运作和管理更改方面的决策；
• 与审计和调查报告不同，风险评估报告不是寻找系统中的差错，而是对系统风险的全面分析，所以在报告中应将威胁/缺陷对作为观察结果加以记录，以便管理者客观、全面了解系统面临的风险。

风险评估报告的组成

概述

1、简介

• 目的
• 此风险评估的范围

  描述系统组件、要素、用户、地点以及其它与评估有关的系统细节。

2、风险评估方法

简要描述风险评估所使用的方法，如：

• 参与者（如风险评估团队成员）；
• 收集信息所使用的技术（如工具和问卷的使用）；
• 风险等级的制定和描述（如3 X 3、4 X 4、5 X 5风险水平矩阵）；

3、系统评定

评定系统，包括硬件（服务器、路由器、交换机）、软件（如应用程序、操作系统、协议）、系统接口（如通讯链路）、数据、用户。提供连接图或系统输入、输出流程图以明确风险评估工作的范围；

4、威胁描述

汇集和列出潜在威胁源及其威胁活动清单；

5、风险评估结果

列出观察结果（缺陷/威胁对）。每个观察结果必须包括：

• 观察结果编号及其简要描述（如观察结果1:用户系统口令可以被猜测或破解）；
• 威胁源和缺陷对的讨论；
• 现有消减安全控制的识别；
• 可能性讨论和评价（如高、中、低可能性）；
• 影响分析讨论和评价（如高、中、低影响）；
• 基于分析水平矩阵的风险评级（如高、中、低风险）；
• 用以降低风险控制建议或备用选项；

6、总结

观察结果总数。使用表格方式总结观察结果、相关风险等级、控制建议等内容。

风险消减

• 风险消减的任务是对风险评估中所推荐的控制措施进行排序（Prioritizing）、评价（Evaluating）和部署（Implementing），达到以最小的代价部署最合适的控制，将风险降低到机构可接受水平的目的；
• 消除所有风险是不可能或不现实的，机构应该根据风险对机构的影响程度将威胁和缺陷对排序，并根据机构的具体情况确定处理每一项风险的手段；
• 在处理风险时，机构应考虑所有可能的处理选项，包括非技术和管理手段，在各种安全解决方案中选择最适合的方法；

风险消减选项

• 风险承受（Assumption），接受潜在风险，继续运行系统，或采取措施将风险降低到可接受的水平；
• 风险规避（Avoidance），通过消除风险源或影响（如放弃相关系统功能或在发现风险时关闭系统）的方式规避风险；
• 风险限制（Limitation），通过部署控制措施（如使用支持、防御、检测控制措施）减少威胁利用缺陷造成的负面影响限制风险；
• 风险规划（Planning），通过制定风险消减计划对控制措施进行排序、部署和维护来管理风险；
• 研究和确认（Research and Acknowledgment），通过确认缺陷或错误以及研究校正缺陷的控制措施来降低遭受损失的风险；
• 风险转移（Transference），通过采用其它选项进行补偿以转移风险，入购买保险；

风险消减原则

• 如果存在缺陷（或错误、弱点），则部署保障措施减少缺陷被利用的可能性；
• 如果缺陷可能被利用，则运用多层防护、体系设计和管理控制措施来防止或减少其发生；
• 如果攻击者的成本小于潜在收益，则通过部署保护措施增加攻击者的成本来减少攻击者的动机（如使用系统控制措施限制系统用户的访问权限来减少攻击者的收益）；
• 如果损失过大，则运用设计原则、体系设计，以及技术和非技术保护措施限制攻击范围，以减少潜在损失。

控制部署方法

• 第一步：活动排序，根据风险评估确定的风险水平排定相应部署活动的优先顺序，风险越高，优先级别越高；
• 第二步：控制选项评价，对推荐的控制选项进行可行性（如兼容性、用户接受性）和有效性（如保护程度和风险消减水平）分析，选择有效、可行的控制选项；
• 第三步：成本收益分析，分析控制选项的成本收益；
• 第四步：选择控制措施，根据成本收益分析的结果选择最具成本效益的控制措施，所选择的控制措施应结合技术、运作和管理手段以确保系统安全；
• 第五步：设定工作责任，挑选具有相关技术和能力的人负责所选控制措施的部署工作；
• 第六步：制定保护措施部署计划；
• 第七步，部署所选择的控制措施；

制定保护措施部署计划

保护措施部署计划应包括：

• 风险（缺陷/威胁对）及其风险级别（来自风险评估报告）；
• 推荐的控制措施（来自风险评估报告）；
• 经过排序的活动（高风险项目的优先顺序）；
• 选择部署的控制措施（基于可行性、有效性、机构收益和成本）；
• 部署所选控制措施所需的资源；
• 负责团队和人员清单；
• 数据开始日期；
• 计划中的部署完成日期；
• 维护需求。

保护措施部署计划举例

风险（缺陷/威胁对）
风险水平
推荐的控制措施
优先顺序
选定的控制措施
所需的资源
负责团队/人
开始/完成日期
维护需求/备注

风险（缺陷/威胁对）	风险水平	推荐的控制措施	优先顺序	选定的控制措施	所需的资源	负责团队/人	开始/完成日期	维护需求/备注
非受权用户可以使用Guest账户Telnet服务器XYZ并浏览公司的敏感文件。	高	禁止外来Telnet请求； 禁止敏感文件的“world”访问权限； 禁止Guest账户或设置复杂口令。	高	禁止外来Telnet请求； 禁止敏感文件的“world”访问权限； 禁止Guest账户。	花费10个小时对系统进行重新设置和测试。	张三，XYZ服务器系统管理员， 李四，公司防火墙管理员。	2005年5月17到2005年5月18日	进行周期性的系统安全检查和测试以确保为XYZ服务器提供了足够

 

控制分类

技术类安全控制，涉及到包括硬件、软件、固件在内的系统体系结构、工程学和安全产品包的使用，包括：

• 支持型，用以支持其它安全控制措施的安全功能通用支撑机制，如对用户、进程和信息资源的标识，密钥生成、分发、存储和维护等密钥管理，系统设置、更改等安全管理，残留信息保护、最小特权、进程分离、模块化设计、分层设计等系统设计和部署方面的系统保护安全措施等；
• 防御型，防止安全事件的发生，如口令、PIN、令牌、数字证书等身份鉴别手段，授权管理，MAC、DAC等访问控制策略执行，抗抵赖服务、基于密码技术的通信保护和事务隐私保护措施；
• 检测和恢复型，检测安全事件的发生并进行恢复，如审计、入侵检测和控制、完整性验证、安全状态恢复、病毒检测和清除等；

  管理类安全控制，涉及到信息保护政策、指导方针、标准的制定，包括：

• 防御型，安全责任的设定、安全计划的制定和维护、实施职责分离、最小特权等人事安全控制，进行安全意识和技能培训等；
• 检测型，实施背景调查、岗位轮换等人事安全控制，定期对安全控制进行检查，定期的系统审计，持续性的安全管理，对残留风险的接受等；
• 恢复型，如业务连续性计划的支持、制定、测试和维护，识别、报告、响应、处理安全事件及其准备工作的事件响应机制等。

  运作类安全控制，涉及到校正可能被潜在威胁源利用的运作缺陷，包括：

• 防御型，如介质访问和处置，系统外数据分发，软件病毒控制，计算设施保护，线缆及布线间保护措施，数据和系统备份规程，离站存储规程，笔记本、个人电脑、工作站保护措施，灭火器、喷淋系统、气体灭火系统等消防措施的使用规程，对不间断电源和备用发电机的需求，空调、散热器等温度、湿度控制措施的运行等；
• 检查型，如入侵探头、闭路监视系统、警报等物理安全控制措施的使用，火警等环境安全控制措施的使用；

成本收益分析

确定部署控制措施带来的影响；

确定不部署控制措施带来的影响；

估计部署费用，其中应包括：

• 硬件和软件购置费用；
• 部署控制措施可能导致系统有效性（如性能或功能）降低带来的损失；
• 部署附加政策和规程的成本；
• 部署政策、规程和服务的附加人工费用；
• 培训费用；
• 维护费用；

评估部署费用和收益以确定部署控制措施对于机构是否合算。

成本效益分析原则

虽然不同机构的风险接受能力不同，但在确定是否采纳某项控制措施时都遵循以下原则：

• 如果控制措施降低风险的能力超出需要，应考虑是否有其它更经济的选项；
• 如果控制成本大于风险降低的收益，则应考虑其它方法；
• 如果控制措施不能有效降低风险，则应考虑其它控制措施或增加控制措施；
• 如果控制措施提供足够的风险降低能力，并具有成本效益，则应使用这种控制措施；

由于控制措施的部署成本容易量化，而不部署控制措施造成的影响往往难以量化，所以在决定是否采纳控制措施时，高级管理人员扮演重要的决策角色。

控制措施的作用和残留风险

部署控制措施可以通过以下方式降低风险：

• 清除某些系统缺陷从而减少了威胁源/缺陷对的数量；
• 降低威胁源的能力和动机，如增加物理安全保护措施；
• 降低负面影响的程度，如限制用户访问权限从而限制缺陷的影响范围；

通常无论怎样保护系统也无法将系统的风险降低到零，部署控制措施后仍然存在的风险被称为残留风险，如果残留风险低于机构可接受的风险，机构高层管理人员或其它受权人员应接受残留风险并授权系统的运行，否则应继续前述风险管理步骤进一步降低风险。

持续评价

• 由于系统自身的不断扩充和变化，新技术的出现，以及系统应用环境如人员和安全政策的变化都可能使系统面临风险发生变化，所以风险管理活动应该是持续的以便能够适应这些变化；
• 
  风险评估工作应该至少每三年进行一次，在系统或其应用环境发生重大变化时，应该随时进行新的风险评估和相关安全控制措施部署工作。

风险管理的成功要素

• 高级管理层的积极参与；
• IT团队的全面参与和支持；
• 风险评估团队的专业素质；
• 用户的理解和配合；
• 对IT相关风险的持续评价和评估。