zoukankan      html  css  js  c++  java
  • 安全与风险管理之IT风险评估

    一、风险评估的几个定义
    在谈风险评估时一般会围绕脆弱性/薄弱性、威胁、威胁主体、风险、资产、控制措施/防护措施、暴露、安全策略等几个概念展开,因此本文在论述风险评估之前有必要先了解下其定义和之间的关系,有利于我们理解和实际应用。
    以下内容描述过程中,未特指均指的是IT领域的风险评估,但过程和相关定义在公共领域也同样适用,但范围会有所不同。
    以下所有内容的理解大部分都是参考中文文献,英文能力太差,但大家有时间还是推荐看看英文原版。
    1.脆弱性/薄弱性
    GB/T 20984-2007 中的定义:可能被威胁所利用的资产或若干资产的薄弱环节
    在NIST SP 800-30中的的定义:能够被威胁利用而导致安全破坏或违背安全方针的缺陷或薄弱点
    CISSP认证考试指南中的定义:脆弱性是缺少防护措施或防护措施存在能够被利用的缺陷。
    关键词:缺陷、弱点。
    例如:计算机漏洞就是缺陷,明文传输就是弱点。
    2.威胁源和威胁
    CISSP认证考试指南中的定义:威胁是某人或某物有意或无意的利用某些脆弱性并导致资产损失的可能性
    GB/T 20984-2007 中的定义:威胁是可能导致对系统或组织维护的不希望事故潜在的起因。
    在NIST SP 800-30中的的定义:是特定威胁源成功利用特定薄弱点的潜在可能。
    威胁源:是指任何能给对系统造成潜在影响的环境或者事件。通常可以将威胁源分类为自然的、人为的、环境的。
    举个例子:
     
    总结起来,其实威胁是一个动作,就是你做什么,影响了什么,这就是威胁。而谁来发起威胁呢?就是威胁源,也就是发起者。向谁发起呢?就是脆弱点。
    举个例子:
    图中,由于离职员工账号没有被及时清除(弱点),离职员工(威胁源)访问公司私有数据(威胁),导致公司商业秘密泄露(风险)。
    3.风险
    CISSP认证考试指南中的定义:风险是威胁主体利用脆弱性对资产造成伤害的可能性以及导致的业务影响。
    在NIST SP 800-30中的的定义:风险是指已被识别的威胁源利用特定的潜在弱点/缺陷导致不利事件的概率及其影响的函数。
    其实从字面上大家都能力理解,概念比较晦涩,笔者理解为风险由概率和影响两个维度组成例如离职员工利用原单位未及时删除账号的弱点,盗取原有公司的商业信息导致公司损失这是不利事件,而到底能不能发生,这就是可能性/概率。若企业网络网络不在互联网上运行,离职员工必须突破企业的物理安全防线后才能进入,这个风险就可以忽略。而这个事件一旦发生会带来什么后果呢?这就是影响。
    注意一般风险分已知和未知风险,所以在800-30里面加”特定“
    4.风险评估
    风险评估是对信息系统及其由处理、传输和存储的信息的保密性/机密性、完整性、可用性等安全属性进行评价的过程,它要评价资产面临的威胁以及威胁利用脆弱性导致安全事件的可能性,并结合安全事件所设计的资产价值来判断安全事件一旦发生对组织造成的影响。
    残余风险是采取安全控制措施后,信息系统仍然可能存在的风险。
    安全事件是系统、服务或网络的一种可识别状态的发生,它可能是对信息安全策略违反或防护措施的失效,或未预知的不安全状况。
    安全措施保护资产、抵御威胁、减少脆弱性、降低安全事件的影响,以及打击信息犯罪实施的各种实践、规程和机制。
    5.一张图总结上面几者之间的关系
     
    威胁主体利用脆弱性发起威胁,威胁带来风险,风险产生带来对资产的破坏,引起了影响(暴露),通过防护措施降低/规避风险。
    来自GB/T 20984-2007 的风险评估要素关系图

     
    二、国内外风险评估框架参考
    1.关注IT领域
    1) NISTSP 800-30
    NIST SP 800-30 IT系统风险管理指南
    NIST SP 800-26 IT系统安全自评估指南
    NIST SP 800-53 联邦IT系统推荐的安全控制
    几个标准的关系:26是其企业自评估指南,是实施指南,30偏框架类,53是技术控制,推荐的应该怎么做。实际上三者相互关联,26作为30的输入,30作为53的输入。
    这里延伸一些知识概念,在CISSP中提到企业应该有各种委员会,包括:安全策略委员会,对应53,风险评估委员会对应30 ,审计委员会对应26 。
    由于审计委员会暴露出风险,而审计报告的质量由安全督导委员会审查。评审的内容提交给风险评估委员会,风险评估委员会评估后提交安全策略委员会。这过程中都由安全监督委员会跟进。
    2)ISO/IEC 27001:2013
    先说下ISO/IEC 27001:2013,就是我们常说的27000认证,标准的前身为BS 7799,设计出来主要用于企业认证,帮助企业建立和维护ISMS。
    该标准要求组织通过业务风险评估的方法来建立、实施、运行、监视、评审、保持和改进其ISMS,确保其资产的保密性、可用性和完整性。
    其中27001是信息安全管理体系要求,27005是信息安全风险管理。
    • ISO/IEC 27000 概述和词汇
    • ISO/IEC 27001 ISMS 要求
    • ISO/IEC 27002 信息安全管理实践代码
    • ISO/IEC 27003 信息安全管理体系实施指南
    • ISO/IEC 27004 信息安全管理衡量指南与指标框架
    • ISO/IEC 27005 信息安全风险管理指南
    • ISO/IEC 27006 认证机构要求
    • ISO/IEC 27007 ISMS 审计
    • ISO/IEC 27008 审计师指南
    • ISO/IEC 27011 通信组织信息安全管理指南
    • ISO/IEC 27014 信息安全治理指南
    • ISO/IEC 27015 金融行业信息安全管理指南
    • ISO/IEC 27031 业务连续性
    • ISO/IEC 27032 网络空间安全指南
    • ISO/IEC 27033 网络安全指南
    • ISO/IEC 27034 应用安全指南
    • ISO/IEC 27035 安全事件管理指南
    • ISO/IEC 27037 数字证据收集和保存指南
    • ISO/IEC 27799 医疗机构信息安全管理指南
    • ISO/IEC 13335 信息安全风险管理指南
    3)国内标准
    GB/T 20984-2007 信息安全技术 信息安全风险评估指南
    GB/T 31509-2015 信息安全技术 信息安全风险评估实施指南
     
    三、风险评估过程

    风险评估目标:评估的过程是识别脆弱性和威胁、计算风险值,评估可能造成的损失,达成的目标是确保安全防护措施是划算的、相关的、及时的并能响应特定的威胁。

    评估要先收集数据,然后再对收集的数据进行研究,确定应该采取什么行动。


    1.制定方案
    此阶段也称为准备阶段主要包括:
    • 确定风险评估的目标、范围;
    • 组建合适的团队;
    • 确定评估的依据和方法;
    • 制定方案;
    • 获得最高管理者对工作的支持。
     
    2.风险识别
    在大部分标准和文献中将资产识别/系统调研放在了第一部分。作为风险识别的开始,作为后续其他“识别”的基础,笔者更倾向于放在此部分。
    在风险识别部分,更多的是识别各种信息,为后续分析做准备,所谓知己知彼百战百胜。
    1)资产识别/系统调研
    • 业务战略及管理制度;
    • 主要的业务功能和要求;
    • 网络结构与网络环境,包括内部连接和外部连接;
    • 系统边界;
    • 主要软硬件;
    • 数据和信息;
    • 系统和数据的敏感性;
    • 支持和使用系统的人员。
     
    系统调研:调查表、现场调查、文件评审、使用工具进行扫描
    建立资产清单,根据业务流程来识别信息资产
    信息资产存在的形式
    • 电子数据:数据库和数据文件、用户手册等
    • 书面合同:合同,策略方针,归档文件,重要商业结果
    • 软件资产:应用软件、系统软件、开发工具、软件程序
    • 实物资产:磁介质、电源和空调、网络基础设施、服务器等
    • 人员:承担特定只能和责任的人员或角色
    • 服务:计算和通信服务、外包服务,其他技术性服务
    • 组织形象与声誉:无形资产
     
     
    2)脆弱性识别
    脆弱性是资产本身存在的,如果没有被利用,单纯的脆弱性不会对资产造成损害。
    在这里识别脆弱性,是针对所确定的范围、环境和识别的资产进行脆弱性识别。这个在制定方案阶段确定。
    此步骤最终形成脆弱性清单。
    应该记录可能存在的弱点以及判断弱点的方法。
    弱点分析的来源有哪些呢?
    • 以往的风险分析报告
    • IT的审计报告
    • 供应商信息(发布的漏洞、补丁程序、服务公告、产品信息等)
    • 互联网及其他机构的服务信息
    • 系统软件的安全分析
     
    怎么确定弱点呢?
    • 自动的脆弱性扫描;
    • 安全测试与评估;
    • 渗透测试。
     
    总结:
    识别出每个资产可能被利用的弱点:技术性弱点、操作弱点、管理型弱点
    识别途径:审计报告、实践报告、安全检查报告、系统测试和评估报告。自动化漏洞扫描工具和渗透测试
     
    3)威胁和威胁源识别
    一项资产可能面临多个威胁,一个威胁也可能对多个资产造成影响。
    威胁是特定威胁源成功利用特定薄弱点的潜在可能。
    威胁源是指任何能够对系统造成影响的环境或事件。
    威胁三要素:存在的漏洞、可行的攻击、有能力的威胁
    威胁源种类
    • 人员威胁;
    • 系统威胁;
    • 环境威胁;
    • 自然威胁。
     
     
     
    威胁源一定会有动机,才会生产威胁活动。
    评估威胁可能性是要考虑威胁源的动机和能力因素。
     
    威胁源的确定需要和企业自身及其所处的环境而确定。
    威胁示例:
     
     
    4)已有的安全措施
    在进行以上信息识别的同时,也需要对已采取的措施进行识别,采取了哪些措施,措施是否生效。
    从针对性和实施方式来看:
    • 管理性安全策略、风险管理程序
    • 技术性包括操作性和技术性措施;逻辑访问控制、日志审计、加密、身份识别、物理和环境安全策略等
    • 物理:基础环境控制,视频监控、CCTV等
    从作用上看
    • 威慑性(Deterrent):防止威胁的发生
    • 预防性(preventive):保护系统
    • 检测性(Detective):发现安全事件
    • 纠正性(corrective):减小造成的影响
    至此,风险识别的过程算完成了。
    3.风险分析
    此阶段的方法包括定性和定量分析,一般两者结合使用。

     
    1)定性分析
    定性分析主要来源于主观判断、最佳实践、直觉和经验
    收集数据的技术:Delphi、集体讨论、情节串联、焦点群体、调查、问卷、检查表、单独访谈、采访
    a)资产赋值
    评价信息资产
    • 受损后造成的直接损失;
    • 资产恢复需要的代价,包括检测、控制、修复的人力和物理;
    • 组织公众形象和名誉损失,竞争优势损失;
    • 其他损失,如保险费用的增加。

    根据重要性(影响或后果)来划分资产等级,同时考虑保密性、完整性和可用性的受损可能引发的后果

    参考GB/T 20984-2007,对资产进行保密性、完整性和可用性三个方面进行赋值了

    机密性/保密性

    完整性
    可用性
     
    对于资产重要等级确定,GB/T 20984-2007是这么说的:评定方法可根据企业自身的特点,选择资产机密性、完整性和可用性最为重要的一个赋值等级作为资产的的最终赋值结果;也可以根据资产的机密性、完整性、可用性的不同等级及其赋值进行加权赋值(每个值设置比重)到资产的最终赋值结果。加权方法可根据企业的特点确定。

    b)脆弱性赋值
    参考GB/T 20984-2007中的定义,可根据资产的损害程度(若弱点行为直接导致企业无法生产,例如工控安全事件)、技术实现难易程度(攻击者也是先易后难)、弱点的流行程度(越流行越容易被攻击)等,对弱点的严重程度赋值。具体脆弱性的描述等等详见上一章节。

    c)威胁赋值
    参考GB/T 20984-2007中的定义,威胁出现的频率是威胁赋值的重要内容,需要参考以往事件的概率、可发现的概率、国内外的统计情况等。
    2)风险值计算
    参考GB/T 20984-2007中的定义:
    在完成了资产识别、威胁识别、脆弱性识别,以及对已有安全措施确认后,将采用适当的方法与工具确定威胁利用脆弱性导致安全事件发生的可能性。综合安全事件所作用的资产价值及脆弱性的严重程度,判断安全事件造成的损失对组织的影响,即安全风险。以下面的范式形式化加以说明:
    风险值=R(A, T, V) = R(L(T, V), F(Ia, Va ))
    其中, R 表示安全风险计算函数; A 表示资产; T 表示威胁; V 表示脆弱性; Ia 表示安全事件所作用的资产价值; Va 表示脆弱性严重程度; L 表示威胁利用资产的脆弱性导致安全事件发生的可能性; F表示安全事件发生后产生的损失。 
    在解释各值的定义前,再把前面的内容用一张图来进行下总结:
    a) 计算安全事件发生的可能性
    根据威胁出现频率及弱点的状况,计算威胁利用脆弱性导致安全事件发生的可能性,即:安全事件发生的可能性=L(威胁出现频率,脆弱性)= L(T, V )
    在具体评估中,应综合攻击者技术能力(专业技术程度、攻击设备等)、脆弱性被利用的难易程度(可访问时间、 设计和操作知识公开程度等)、资产吸引力等因素来判断安全事件发生的可能性。
    b) 计算安全事件发生后的损失
    根据资产价值及脆弱性严重程度,计算安全事件一旦发生后的损失,即:安全事件的损失=F(资产价值,脆弱性严重程度)= F(Ia, Va )
    部分安全事件的发生造成的损失不仅仅是针对该资产本身,还可能影响业务的连续性;不同安全事件的发生对组织造成的影响也是不一样的。在计算某个安全事件的损失时,应将对组织的影响也考虑在内。
    部分安全事件损失的判断还应参照安全事件发生可能性的结果,对发生可能性极小的安全事件( 如处于非地震带的地震威胁、在采取完备供电措施状况下的电力故障威胁等) 可以不计算其损失。
    c) 计算风险值
    根据计算出的安全事件发生的可能性以及安全事件的损失,计算风险值,即:风险值=R(安全事件发生的可能性,安全事件造成的损失)= R(L(T, V), F(Ia, Va ))
    评估者可根据自身情况选择相应的风险计算方法计算风险值,如矩阵法或相乘法。矩阵法通过构造一个二维矩阵,形成安全事件发生的可能性与安全事件的损失之间的二维关系;相乘法通过构造经验函数,将安全事件发生的可能性与安全事件的损失进行运算得到风险值。
    具体风险值的赋值方法在GB/T 20984-2007给出了详细方法在此就不做过多介绍。
    总之,计算的风险值,根据风险计算的方法会给出个区间,每个区间会给出是否处于哪个等级。
    3)定量风险分析
    细心的人会发现,为什么这里才说定量分析分析呢?
    在项目管理中,定量风险分析是对已经识别的风险在定性风险分析后被确定为对项目的竞争性存在潜在重大影响的风险进行的分析。实施定量风险分析过程就是分析这些风险对项目目标的影响,主要用来评估所有风险对项目的总体影响。在进行定量分析时,也可以对单个风险分配优先级数值。
    本过程的主要作用是为决策者提供更加直观的决策依据,关系到资金的投入,投入的防护手段所需要花费的资金是否小于产生风险对资产带来的损失等。
    提供成本/收益比,帮助企业将安全计划目标整合到企业的业务目标和需求中。
    评估用来收集数据,分析对收集的数据进行研究,确定应该采取什么行动

    笔者的理解,其实我们大部分单位做完定性风险分析后就已经形成风险分析报告,而具体针对风险的问题也给出解决方案,但这些问题要不要解决,是否有价值,产出比是否合理,一般都是在安全委员会上提交而定的,也姑且可以认为实际我们在在做完分析后,提交领导决策,这个过程潜移默化的就会涉及到定量的数据。领导最关心的是这事不做会带来多大损失,做要花多大代价,然后做出判断。

    因此定性和定量是相辅相成。先定性,然后根据定性的结果,将分析结果再缩小,比如定性确定了高、中、低风险,接下来针对高风险,再做定量分析。

    定量风险分析涉及的几个定义:
    暴露因子:某种特殊资产被已发生的风险损坏所造成损失的百分比。
    SLE:单一损失预期,为某个事件赋予的货币价值。
    SLE=资产价值*暴露因子
    ARO(年发生比率):一年时间内发生特定威胁的预计频率
    ALE:年度损失预期:SLE*年发生比率=ALE
    ARO:年发生比率..一年时间内发生特定威胁的预计频率
    使用场景:计算结果是一个货币数值。如果每年投入的高于损失所产生的货币值就没有价值了,可用于有形资产
    为什么不能实现真正的定量风险分析:定量的措施必须施加定性要素
    4)分析结果
    赋予资产的货币价值
    所有可能威胁和重要威胁的综合列表
    每种威胁的发生概率
    12个月时间内公司在每种威胁下能够承受的潜在损失
    建议的防护措施、对策和行动
    意义:帮助将安全计划目标整合到公司的业务目标和需求中。为安全计划及构成安全技术的组件制订合理的预算
     
    在这个阶段风险识别及其赋值与IT系统生命周期所处的阶段有关。
    笔者在这个过程中遇到好多企业新建系统不知道怎么做风险识别,当然目前我也是处于懂和不懂的过度期(汗颜),以下来自GB/T 20984-2007中,一起共勉
    对于处于规划阶段:主要关注组织的安全方针和策略。在此阶段资产、脆弱性不需要识别,威胁根据未来系统的应用对象、应用环境、业务状况、操作要求等方面进行分析。
    对于处于设计阶段:需要根据规划阶段的运行环境、资产的重要,提出安全功能需求。风险分析结果应对方案中所提供的安全功能符合性进行判断。也就是说主要对方案的可行性进行风险分析。
    对于处于实施阶段:根据系统的安全需求和运行环境对系统开发、实施过程进行风险分析,并对建成后的系统进行安全功能验证
    对于运维阶段:了解和控制运行过程中的安全风险,一般我们大部分都是针对运行阶段的风险评估。
    对于废止阶段:对处置及影响进行评估。
    4.风险应对
    对不可接受的风险应根据导致该风险的脆弱性制定风险处理计划。风险处理计划中明确应采取的弥补弱点的安全措施、预期效果、实施条件、进度安排、责任部门等。安全措施的选择应从管理与技术两个方面考虑。安全措施的选择与实施应参照信息安全的相关标准进行。
    1)风险处置方法
    • 缓解/减低/削弱风险(Mitigate/Reduce Risk)
             例子:
                    减少威胁:实施恶意代码控制措施
                    减少弱点:通过安全意识培训,强化安全操作能力
                    降低影响:灾难恢复计划和业务连续性计划,做好备份
    • 规避风险(Avoid/Reject Risk)
    • 转移风险(Transfer Risk):(外包/买保险)
    • 接受风险(Accept Risk)

    2)风险控制措施选择对策

    基本原则:实施安全措施的代价不应该大于所要保护资产的价值

    对策成本:购买费用,对业务效率的影响,额外人力物力,培训费用,维护成本费用等

    控制价值=实施控制之前的ALE-实施控制后的ALE-控制的年成本

    约束条件:时间约束,技术约束,环境约束,法律约束,社会约束

    3)评价残留风险

    实施安全控制后残留或残存的风险

    残留风险Rr=原有风险R0-控制效力R

    残留风险<=可接受的风险Rt

    5.风险监控

    风险监控实际是作为风险管理的一个过程,不作为风险评估的一个过程。风险监控一方面监控已有的风险是否被规避或者升级,另一方面要监控系统否有新的风险产生。以上问题都会再次生产风险的再评估。
    因此风险管理是动态的、周期性的。
    6.其他
    在CISSP中提到了几个风险评估的方法,没有去看,以下先进行如下罗列吧
    OCTAVE :是团队型的、通过研讨会而管理风险的方法,通常用于商业部门
    FRAP :便利的风险分析过程,只对最需要的风险进行评估,过程中不计算风险被利用的概率和年度预期损失
    FMEA 失效模式和影响分析 :用于产品开发和运营环境中,标识出最容易出现故障的环节。一种确定功能、标识功能失效以及通过结构化过程评估失效原因和失效影响的方法

    四、几个相关知识
    风险管理是作为ISMS(信息系统管理)的输入,需要高级管理层的承诺和一个文档化的过程

    风险管理框架(RMF)
        ISO 31000:2009
        ISACA IT风险
        COSO 企业风险管理:自上而下的方式
        NIST RMF SP 800-37 r1

    安全控制的选择:可能引发风险再评估(安全控制系统/设备本身带来风险)

     
    特别声明:
    1.以上所有描述内容部分参考链接/文献未逐一列出,若有侵权,请及时告知,有则改之无则加勉。
    2.以上仅是学习过程的总结,相信有很多理解偏差的地方,特别希望指出,给予帮助,更新知识体系,共同进步。
     
    参考文献:
     

    https://wenku.baidu.com/view/b957a4dc5dbfc77da26925c52cc58bd631869384.html?from=search

    https://www.docin.com/p-734773530.html

    https://blog.csdn.net/sunmoon1210/article/details/82955955

    https://www.nist.gov/news-events/news/2012/09/new-nist-publication-provides-guidance-computer-security-risk-assessments

     

    GB/T 20984-2007 信息安全技术 信息安全风险评估指南

    CISSP 认证考试指南(第7版)

     
     

    <wiz_tmp_tag id="wiz-table-range-border" contenteditable="false" style="display: none;">





  • 相关阅读:
    修改spring boot 的banner
    创建oracle 数据库的时候 提示 “使用database control配置数据库时,要求在当前oracle主目录中配置监听程序”
    Spring Boot 中文乱码解决
    SharePoint 2013 安装图解
    Hadoop 数据安全方案 Apache Eagle
    通用财经数据传输与监控平台1.0(泛型,接口与基类,Sql,Ibatis,Awt,Swing)
    应用Druid监控SQL语句的执行情况
    监控和剖析数据库操作 -- P6Spy、SQL Profiler、IronTrack SQL 使用简介
    Jboss7集群配置说明
    JavaMelody监控SQL
  • 原文地址:https://www.cnblogs.com/worter991/p/12498578.html
Copyright © 2011-2022 走看看