关于风险评估的思路

资产中存在潜在脆弱性,威胁源利用这些脆弱性,通过威胁路径入侵,从而导致威胁事件发生。这些威胁事件发生的可能性,以及由此产生的后果和影响就是风险。

为什么要进行风险评估?为了找出系统风险并制定风险规避措施或者缓解措施。这些风险是什么?这些风险是一个个场景。场景是什么?场景是一个个威胁事件,以及这些威胁事件产生的影响与系统的运营目标相比较产生的后果。

1、确定所评估系统的业务和运营目标。这个过程需要对评估目标明确定义,按照生产损失,营收损失,人身健康,安全,环境造成的影响记录,站在更高的战略层面展开。

需要问几个问题:

* 企业如何盈利?

* 哪些系统对于盈利至关重要?

* 企业生产的是什么?

* 控制运行和实现自动化的过程有哪些?

* 在过程和自动化中部署了哪些系统来支持这一过程?

* 通过上述问题,识别关键系统,关键系统停止运行导致的部分后果?

2、系统评定与分类。运营目标确定后,根据目标找出可能发生的与系统相关的安全事件以及这些事件可能导致的后果。

将运营目标与这些可能导致的后果联系起来,如果产生这些后果,如果系统的资产损坏、离线或者滥用会产生什么样的影响?这些对于构建风险场景,以及后续制定风险缓解措施非常重要。

需要考虑的后果包括但不限于以下这些,风险场景的建立基于这些影响,风险缓解措施也是基于这些影响制定,这些影响还不够全面,后面的过程会不断增加和优化。构建风险场景是基于现有情况和评估者所了解的攻击技术预设出来的可能性。

* 阻断或延迟信息流可能导致操作的中断

* 指令、命令报警阈值的未授权改动,可能损坏、禁用、关闭设备,造成环境影响以及人身伤亡

* 发出不准确信息,掩盖未授权改动,意图不当操作的负面影响

* 系统软件或组态改动,感染病毒的负面影响

* 干扰设备保护系统的运行,对设备的影响

* 干扰功能保护系统的运行,可能造成的人身伤亡

* 资产的关键性评级或安全保障级别

3、资产识别。就是与系统相关的所有资产,软件,硬件,文档,资料等,其中客户提供的清单不一定准确,实际中可能会进行资产发现,以免与实际不符;这个资产按照设备物理数量来计算,比如一台服务器上安装有操作系统,数据库,同时也是一台硬件,它就是具有这几种属性的一个资产。

关于文档,可以根据搜集到的文档内容将文档分类:安全管理策略,安全管理培训,操作实施手册,安全管理实施,安全管理措施,应急预案,配置管理策略,访问控制策略,身份认证策略,事件检测与应急响应等。对每一项文档具体内容进行描述,在依据等保2.0访谈检查的过程中,管理类不符合要求的条目,多可以具体匹配到上述某一项。

比如,

脆弱性:安全策略制定不完善。

脆弱性描述是:由于策略制定不完善或者缺乏针对系统安全的具体策略,通常会导致系统存在脆弱性,每项对抗措施都应该在策略中有迹可循,从而确保一致性和可问责性。安全策略必须将在公共系统环境中使用的便携式设备与移动设备包括在内。

资产:安全管理策略文档;

在等保2.0访谈检查与此脆弱性描述相关的不符合项都归到这条脆弱性下。这里是针对资产举例子,具体脆弱性的工作在脆弱性识别阶段做。

4、网络拓扑与数据流查询。这步主要是根据用户提供的拓扑图,或者自己根据资产发现获取的信息绘制的拓扑图,以及抓包获得的信息进一步识别资产,通信接口从而识别攻击路径,攻击路径就是攻击者攻击的途径,比如通过wifi的攻击,来自互联网的攻击或者来自vpn的攻击。

5、风险预筛,就是根据资产可靠性,完整性,保密性评出等级,高等级的必须要进行风险评估,低等级的根据实际情况可以推迟或者取消评估。因为低等级的资产对系统运营目标可以忽略不记,这个步骤的目的是将精力集中的重要的资产的评估上,从而节省大量时间,确保评估更有效。

6、脆弱性识别,识别系统脆弱性,主要通过几个途径:

等保2.0规范检测合规性,包括管理和技术,主要关注不符合项目和部分符合项目,符合项目不需评估;

表格中有测评项和检查内容,评估结果,建议将测评项和评估结果拿出来但列一表,根据不符合的测评项把脆弱性归结为以下条目之一。以下条目可能不完整,可以根据实际情况补充,最终的目的是把脆弱性确定为具有概括性的确定的若干条。

* 安全策略制订不完善

* 没有正规的安全培训和认知计划

* 实施指南缺失或不完善

* 安全策略实施管理机制缺失

* 安全控制措施有效性审查不完善

* 没有应急预案

* 缺乏配置管理策略

* 缺乏适当的访问控制策略

* 缺乏适当的身份认证策略

* 事件监测与响应计划和程序不完善

* 关键部件缺乏冗余

脆弱性的其余部分来源于以下方式:

* 漏洞映射,根据应用程序、操作系统版本查询漏洞数据库(这个咱们没那么细,以后做的时候可以收集操作系统版本号,查询公共数据看这些版本是否存在漏洞。)

* 配置核查,手动或者自动核查。(咱们主要是人工核查)

* 漏洞扫描。

* 实时网络流量分析。

* 控制分析,技术方面安全策略审查。

最终也对应到具有概括性的确定的若干条,技术类,如下所示:

架构与设计

* 在架构搭建与设计过程中,未考虑安全因素

* 不断进化的不安全架构,

* 未定义安全边界,

* 在控制网络中传输非控制流量。

* 在控制网络中使用原先未在控制网络中的服务

* 事件的历史数据收集不完善,

网络安全维护

* 硬件固件和软件缺乏配置管理,

* 直到发现漏洞,操作系统和软件厂商也未开发出安全补丁

* 未对操作系统和应用程序安全补丁进行维护管理,或者厂商拒绝提供补丁修复漏洞

* 针对安全变更的测试不完善,

* 远程访问控制机制薄弱,

* 配置方式不完善,

* 未对关键配置信息进行存储或备份,

* 未对便携设备中的数据予以保护。

* 口令的生成使用与保护同安全策略不一致,

* 访问控制不完善,

* 不当的数据连接

* 未安装恶意代码防护程序或未对恶意代码防护程序进行更新。

* 未对恶意代码防护程序进行充分测试,

* 拒绝服务攻击,

* 未安装入侵检测或入侵防御软件

* 日志维护缺失,

物理环境

* 未授权人员对设备物理访问

* 射频,电磁脉冲,静电放电电压不足和电压尖峰

* 备用电源缺失,

* 环境失控

* 不安全的物理接口

软件开发

* 数据验证不当,

* 默认情况下未启用已安装的安全功能

* 软件中的身份认证,权限分配和访问控制不完善,

通信与网络配置

* 未采用数据流控制

* 未部署防火墙或防火墙配置不当

* 防火墙及路由日志信息记录不完善,

* 使用标准的,具有详细说明文档的通信协议,并且通信采用明文传输

* 对用户数据或设备的认证过程不符合标准,或者未采用身份认证措施,

* 使用了行业中不安全的公共系统协议

* 通信内容的完整性检查机制缺失

* 无线客户端与接入点之间的认证机制不完善,

* 无线客户端与接入点之间的数据保护措施不完善。

上面的每一个脆弱性都要有一个描述说明,比如,未定义网络边界的描述是如果系统没有对安全边界做出明确定义,则无法确保对必要的安全控制进行了正确的部署和配置,这可能导致对系统与数据的未授权访问以及其他很多问题。

这样做的目的是将等保2.0检查表中的条目归结为确定的若干条脆弱性。

通过这一步,我们可以生成资产,脆弱性的对应表。

7、威胁评估

我们现在有了脆弱性和脆弱性对应的资产,接下来要根据威胁情报,把威胁源,攻击路径,脆弱性,资产归结为威胁事件。脆弱性和资产已经有了,攻击者是谁?这是威胁源,攻击者利用脆弱性的攻击入口是什么?这是攻击路径。这四个要素共同构成的是威胁事件。威胁事件必然有后果,这个后果与运营目标的差距就是这个威胁事件的影响。

威胁事件还与威胁事件发生的可能性有关,威胁事件的可能性是多大,这就是威胁评估需要得出的结果。

8、风险计算

威胁事件再加上攻击类型和攻击者目的就是风险场景。

我们一共得出了以下要素:威胁源,攻击类型,攻击路径,脆弱性,资产,攻击者目的,潜在的后果,这些要素共同构成风险场景。

其中攻击源,攻击类型,攻击路径,攻击者目的都需要根据威胁情报去归纳的条目,这些条目要有固定的列表,比如威胁源是内部员工,前员工,有组织的犯罪集团,黑客,病毒等,从中选取可能的即可。

将这些条目根据系统的实际情况(资产、脆弱性)进行组合,构造风险场景,得出潜在的后果。

我们可以对资产、脆弱性、威胁可能性打分,通过这些可以计算出风险值。潜在的后果可以作为风险值计算中的一个要素,也可以作为后续缓解措施解决问题的重要方向。

你可能感兴趣的:(关于风险评估的思路)