III-1a风险管理程序和评估

批准日期:2011年9月16日
生效日期:2011年9月16日
负责人:首席信息安全官
负责办公室:[U]科技信息安全办公室
修订历史:版本1.0; dated September 12, 2011
相关法例及大学政策: 

• 政策I-1资讯科技的可接受使用(AUP)
• 2016年金沙集团贵宾会-金沙贵宾会尊享一刻信息技术战略计划

审查期限:5年
覆检日期:2011年9月12日
相关人群:教职员工

目的

定义了信息安全相关风险管理的标准策略, 以及为安全规划和遵从性工作制定的基线术语. 风险管理活动的目标包括:

• 建立一个风险意识的文化通过有效的, 系统所有者与运营和项目团队(包括IT)之间金沙集团贵宾会-金沙贵宾会尊享一刻安全风险的持续对话
• 信息和信息系统的识别和分类
• 通过使用标准术语和定性概率和影响定义，使所有团队成员参与风险识别.
• 确保系统所有者了解信息系统的前20%或前5个风险, 并通过安全计划采取适当的风险管理步骤
• 确保适当的注意力集中在问题上
• 明确信息安全办公室在管理全企业信息安全风险中的作用.

范围

本标准适用于所有高校信息技术和信息管理系统，以应对企业和系统风险. 所有信息系统(包括外包IT服务)都应经过 一些 信息安全风险管理评估水平. 被认为对金沙集团贵宾会-金沙贵宾会尊享一刻具有重要价值的信息系统, 包括但不限于需要正式项目管理的IT系统, 应当接受 正式的 本政策中定义的风险管理活动.

取消

不适用.

过程语句

一般

所有对金沙集团贵宾会-金沙贵宾会尊享一刻具有重要价值的信息系统都应接受一定程度的信息安全风险管理评估. 风险管理是一种系统生命周期方法，而不是单一时间点的评估. 系统所有者有责任确保对大学的风险得到充分管理, 并使学校没有不可接受的风险.

在大学环境中，有两种主要的风险变体是常见的. 这就是企业风险和系统风险. 企业安全风险是高校运行中所有信息的共性, 这些风险的识别和管理 受制于执行管理层的风险承受能力 大学的. 信息安全办公室负责支持总统办公室和教务长, 通过大学技术服务副总裁/首席信息官, 在企业安全风险管理方面, 通过部署大学范围内的项目, 控制, 实践, 和政策. 系统安全风险涉及特定的系统和业务流程, 哪个部门通常只有一个部门或系统所有者. 系统所有者, 如资讯系统保安计划所定义, 负责确保遵守大学范围内的风险管理活动和系统特定的风险.

本程序概述了在信息安全背景下管理风险的规定方法.

过程

该大学使用两种标准方法的组合来管理信息安全风险:持续风险管理(CRM)和OCTAVESM风险评估方法. 这些方法被设计为“受支持的自助服务”程序, 在信息安全办公室分析师的协助下, 系统所有者及其操作和项目团队被授权识别和管理其计算环境的信息安全风险.

在客户关系管理的识别和分析阶段，OCTAVE方法被嵌入到客户关系管理方法中, 通常被称为风险评估.

持续风险管理(CRM)

CRM方法是一种迭代和定性的风险管理框架，适用于大学研究的动态环境, 教育, 支持IT系统和基础设施. CRM定义了用于管理安全风险的标准术语和流程. CRM是由软件工程研究所为软件工程组织开发的, 该方法在信息安全风险管理中具有较好的应用价值. 风险管理过程的基础是为任何特定系统制定风险清单, 以及相关的行动，以解决最严重的风险, 要么就地的，要么计划好的, 由系统所有者. 这通常以风险清单的形式实现，包括在系统的信息安全计划中.

改进的SEI OCTAVESM风险评估方法

OCTAVE方法, 由软件工程研究所(SEI)开发, 定义在风险评估过程中使用的基本威胁概要. 该大学已经修改了基于OCTAVE威胁配置文件识别条件和后果的方法. 这些概要文件是为系统的关键资产开发的, 并使用可视化工具来开发风险清单. 使用的OCTAVE威胁类别包括:

1. 有网络接入的人
2. 有实际接触的人
3. 系统问题
4. 其他问题

在威胁树中评估这些类别中的每一个, 如图所示，本例为具有网络访问权限的人类. 网络访问可以来自内部，也可以来自外部，可以是偶然的，也可以是故意的. 所有这些都有可能导致披露、修改、损失/破坏和中断的最终结果.

利用CRM管理风险

1. 风险清单:CRM的总体目标是开发一个风险清单. 该清单是作为信息系统安全计划的核心提出的.
2. CRM流程图描述了风险管理的周期. 以这种方式, 计划或项目团队可以通过关注最主要的风险来完成各种周期, 而不会因信息安全领域的大量风险而不堪重负.

1. 识别—在使用OCTAVE方法进行小型风险评估时，在风险成为问题之前搜索并定位风险.
2. 分析-将风险数据转换为可用的信息，以确定优先级和做出决策. 这里完成了风险清单的生成，并处理了前20%或前5个风险.
3. 计划——将风险信息转化为规划决策和缓解战略(包括现在和未来), 并针对前5大风险(至少)实施这些措施. 这些都在信息系统安全计划中提出，并由系统所有者批准.
4. 跟踪-监测风险指标和缓解工作
5. 控制——纠正风险缓解计划的偏差，并决定未来的行动
6. 沟通和记录——就风险活动向项目提供信息和反馈, 未来的风险, 以及新兴风险

进行系统风险评估

风险评估工作旨在收集系统的所有相关风险, 在评估的时候. 参与者包括系统开发人员、系统所有者、用户代表和系统管理员. 评估可能包括也可能不包括确定风险等级或缓解活动. 信息安全办公室为这些评估提供便利, 根据他们对校园计算环境的了解，使用已知的威胁条件, 以及过去和现在的威胁信息.

1. 预评估计划. 除了管理和技术团队之外，收集系统使用和数据流(实际的或建议的). 现有或类似系统的信息风险, 或者从之前的评估中, 应该带去评估吗.
2. 范围:开发一个上下文模型来映射信息流和存储. 使用上下文模型来识别系统的关键资产. 确定来源信息资产，并对其进行分类, 内部使用, 按大学标准限制.
3. 为系统的关键资产评估OCTAVE威胁树, 使用四种主要的OCTAVE威胁类别. 请注意, 用于较小的项目或处于开发早期阶段的系统, 风险也可以使用信息安全办公室安全设计审查问卷进行评估, 团队头脑风暴会议, 或者个人努力, 由项目经理决定. 要求[U]Tech正式项目管理级别的系统应执行某种形式的OCTAVE威胁评估.
4. 将条件/结果语句生成到风险索引中，并添加到安全计划中.
5. 计划并安排分析会话.

风险属性

风险有发生的概率. 是否发生了不良事件, 概率为1，风险不再是风险，而是成为了一个问题, 问题管理开始接管. 因此, 风险描述的背景用于清楚地定义风险条件和可能的不良事件. 在CRM方法中，每个风险陈述由两部分组成:

1. 条件:基于OCTAVE威胁概要，描述单个当前值得关注的原因. 条件语句包含常见的威胁和漏洞信息, 哪些构成了发生可能性的输入.
2. 后果:对引起关注的原因的感知影响的初步描述. 其后果还应考虑到中期和长期影响. 可以添加额外的任务成功标准，以阐明影响的严重程度.

作为客户关系管理风险分析阶段的结果, 每种风险都定义了三个定性属性:

1. 概率
   1. 低-被认为不可能，小于20%的概率发生
   2. 中期可能
   3. 高——非常有可能, 在其他类似的业务/研究领域有经验, 超过70%的几率发生
2. 影响(可基于性能、安全性、成本、进度等
   1. 事件发生时的低边际影响(e.g. 公开或内部资料的披露)
   2. 中等危险(e.g. 披露受限制资料)
   3. 高灾难性(e.g. 数据资产全部损失或丧失完成任务的能力，没有替代方案)
3. 时间框架(当意识到风险时的反应)
   1. 从长期来看，需要在12个月之后采取行动
   2. 中期行动需要在2到12个月之间进行
   3. 近期-需要在未来2个月内采取行动

风险声明示例

“鉴于这种情况，有可能会发生后果."

策划阶段风险行动标准

风险计划的目的是细化已识别风险的知识, 首先解决最重要的风险. 效率对于最小化信息系统和项目的成本和进度影响是必要的. 因为客户关系管理是一个周期性的过程, 较低优先级的风险将“上升到顶部”，因为最重要的风险在早期周期中得到解决. 一旦确定了风险的优先级，就会制定行动计划来解决前20%或前5个风险. 风险行动分为四类:

1. 观察-监测概率和影响条件的变化, 但行动(以及任何可能的成本支出)被推迟了. 这通常在怀疑低影响或概率将增加时执行.
2. 接受——项目和管理层已经接受该风险对于系统的任务是可以容忍的. 对于被接受的概率和影响在中等以上的风险，必须有应对影响的应急计划.
3. 研究-在分析时存在不充分的信息, 因此，项目团队需要更多地了解风险. 研究中分类的风险需要在研究完成时定义时间表.
4. 缓和-通过分配资源来实施控制或过程变更. 缓解计划中定义了离散行动，其目标如下:
   1. 较低的发生概率
   2. 降低或软化冲击
   3. 延长反应时间

风险指数, 定义了风险行动, 作为信息系统安全计划的一部分交付. 项目评估团队还必须继续理解，承担可计算的风险是允许创新的原因, 记住，风险管理活动的目的是制定计划来管理组织的不可接受风险.

跟踪阶段标准

风险跟踪是信息系统管理功能的一部分, 就像这样, 这最好通过定期更新信息系统安全计划来实现. 系统所有者负责确保风险操作已经发生, 确定缓解活动的有效性, 并确保在业务实践或系统实施发生重大变化时进行新的风险评估周期. 风险状态应在每月的项目状态会议或[U]Tech项目报告中报告.

控制阶段标准

项目经理应在项目状态会议上作出关闭风险的决定, 继续研究, 减轻或监视风险, 重新计划或重新关注行动或活动, 或者调用应急计划. 具有企业影响的前5个(或前20%)风险元素只有在系统所有者同意的情况下才能关闭. 这也是项目经理对风险进行授权和分配资源的时候.

通信和文档阶段标准

风险指数报告作为信息系统安全计划的一部分. 项目状态会议应该使用标准的风险指数表. 适用于FISMA的系统, 长期风险缓解活动(那些需要比初始系统开发周期更长的实施时间框架的活动)将有一个公布的行动计划和里程碑(POA)&M)仅适用于最高风险.

风险接受和系统授权阶段标准

具有承担系统风险责任的适当权限级别的个人(通常是系统所有者)通过批准信息系统安全计划表示他们接受风险行动计划.

责任

首席信息安全官(CISO):确保建立和维护风险管理流程. 通过ITSPAC治理过程定义企业可接受的风险阈值. 管理企业(系统)安全风险.

信息安全人员:持续监控安全风险，并根据不断变化的安全威胁场景定期更新程序控制. 为高级管理人员定义可接受的风险阈值建议.

系统所有者:确保风险管理活动在系统开发生命周期中进行, 本地系统风险决策不会对大学安全风险承受能力产生负面影响. 通过建立信息系统保安计划，确保符合规定.

定义

Risk: The combination of the probability that an undesired event will occur which will prevent the organization from achieving a mission or business function (such as a compromise of security) and the consequences or impact of the; risk generally accompanies opportunity.
风险声明:描述风险的条件(威胁源和漏洞)和后果(影响)的组合.
联邦信息安全管理法案(FISMA) 2003-选择研究系统是主题, 通过合同义务, 遵守该法案的规定. FISMA下风险管理的安全要求由赞助机构安全政策文件描述, 和NIST特别出版物800系列文件.
可接受的风险:系统所有者理解并同意的风险, 程序, 或项目, 首席信息安全官/ITSPAC治理委员会.

系统所有者:由信息系统支持的业务流程的大学权威, 通常是系统的主要内部客户. 例如, the Chief Financial Officer is the system owner of the financial system; the Registrar is the owner of the student information system.

行动计划和里程碑(POA&M)

参考文献

持续风险管理指南，软件工程研究所，匹兹堡，宾夕法尼亚州 http://www.sei.cmu.edu/risk/

OCTAVESM威胁建模

OCTAVE方法管理信息安全风险, 克里斯托弗·阿尔伯特和奥黛丽·多罗菲, addison - wesley, 2003, 培生教育, 公司.

完整系统分析, 该工作簿, 教科书, 答案, 詹姆斯·罗伯逊和苏珊娜·罗伯逊, 1998, 多塞特出版社.

2003年联邦信息安全管理法案(FISMA).

NIST特别出版物800-39，管理信息安全风险

标准检讨周期

本程序将每三年在政策生效日的周年日进行审查, 至少. 该标准可以根据需要进行评审和更改，以适应法规遵从性和业务需求.