提高安全投资回报:威胁建模和OPEN FAIR™风险分析

2024-03-17 11:36

本文主要是介绍提高安全投资回报:威胁建模和OPEN FAIR™风险分析,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

对大多数人和企业来说,安全意味着一种成本。但重要的是如何获得适合的量,而不是越多越好。然而,你如何决定什么时候可以有足够的安全性,以及你如何获得它?则完全是另一回事。

该篇文章是由The Open Group安全论坛主办,微软和Kyndryl等企业的安全专家以及其他安全论坛成员领导完成,将描述威胁建模(Threat Modeling)与Open FAIR™风险分析的相关性。该系列文章共有4篇,主要围绕如何通过威胁建模和Open FAIR™风险分析提高安全投资回报。

我们生活在一个复杂、相互关联的世界里。它不断为我们提供新的机会,以及随之而来的新挑战。我们都熟悉“互联网”“社交媒体”和“物联网”等术语,我们正在用“生成人工智能(AIGC)”“量子”和“元宇宙”来扩展我们的词汇量。除了这些术语外,我们继续更加熟悉“安全”和“隐私”等不太令人愉快的话题。

安全被视为“做生意的成本”。如果你不这样做,你将受到损害,你将面临重大的经济损失,以及对声誉的损害。因此,您必须做任何需要做的事情来确保您的解决方案。然而,这不太可能是一种具有成本效益的方法。

所以,问题是:到底需要多少安全性就足够了?

安全控制不是免费的。他们每个人都有实施和运营成本。当你实施它们时,你会得到递减的回报,因为你实施的每个控制都会降低残余风险。在某一点上,您将获得低于下一次控制成本的剩余风险。这是你应该停止添加更多控件的时候,因为成本将超过你将获得的收益。

这些考虑因素有可能彻底改变我们未来保护资产的方式。它们暗示安全可能成为企业可用于控制其解决方案经济的另一种工具。我们可以从当前的现实,即组织盲目地将资源投入到建议和合规法规中,而不评估预期收益,转向新的现实,即他们批判性地思考组织需要什么,以便以正确的成本获得足够的安全性。在这个新的现实中,组织不再通过实施所有可用的安全工具来分散和浪费他们的时间、注意力和金钱。相反,他们将实施和操作安全控制的成本与恶意行为者在受到攻击时造成的估计损失进行比较。

为了实现这一目标,我们确定了两种不同的工具:威胁建模和OPEN FAIR™风险分析

威胁建模是一个过程,可以帮助您了解特定系统的安全威胁,确定这些威胁的潜在损失,并建立适当的缓解措施。威胁建模宣言提出了一个令人信服的理由:

当您执行威胁建模时,您开始识别系统中可能出现的问题。它还允许您确定需要缓解的设计和实施问题,无论是在系统的早期还是整个生命周期中。威胁模型的输出被称为威胁,它为您在后续设计、开发、测试和部署后阶段可能做出的决策提供信息。

换句话说,威胁建模允许您了解恶意行为者如何选择攻击您的系统,并确定您可以实施哪些控件来防止、检测和响应这些攻击。

威胁建模最终会产生一个控件列表,并解释了为什么您应该采用它们。然而,它并不能帮助您了解在更大的业务环境中应该采取什么行动(如果有的话)。您的解决方案可能已经足够强大,以至于攻击的潜在损失无法证明进一步投资实施增量安全控制是合理的。但你怎么确定呢?这就是Open FAIR风险分析的拯救之地。

Open FAIR™知识体系提供了一致的、经过行业测试的分类法和方法来量化因网络安全事件而造成的潜在损失。Open FAIR™风险分析侧重于识别和描述损失情景——从不良行为者(威胁代理)联系资产、努力妥协资产并导致组织因妥协(主要损失)而遭受可观察到的、可量化的损失,以及可能因“辐射”(二次损失)而导致额外损失的一系列事件。

根据威胁建模的建议,通过利用Open FAIR流程来分析不同控制组合的影响,组织可以有效地确定哪组控制对降低系统的风险最有效。更重要的是,组织可以通过考虑风险的总体降低以及实施这些控制的成本来决定给定系统的最佳控制集。这意味着组织现在可以根据与业务相关的客观数据做出业务决策。

呼吁

这篇博客文章是四个系列文章中的第一篇,将描述第一个将威胁建模与Open FAIR风险分析联系起来的项目。第二篇文章将向您展示如何将威胁建模与Open FAIR风险分析相结合,以评估系统的当前状态。在第三篇文章中,我们将讨论如何考虑控件来估计其效果并进行一些成本优化。这不仅有助于解决“多少安全就足够了?”的问题,还有助于解决更重要的问题——“我们应该怎么做?”第四篇文章将介绍使用这些概念来定义KPI的注意事项,以评估您的开发团队如何确保他们正在构建的解决方案。

  • 帖子2:评估当前风险

  • 帖子3:估计缓解的影响

  • 帖子4:威胁建模和开放公平风险分析作为敏捷项目的KPI

这篇关于提高安全投资回报:威胁建模和OPEN FAIR™风险分析的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/818822

相关文章

Nginx分布式部署流程分析

《Nginx分布式部署流程分析》文章介绍Nginx在分布式部署中的反向代理和负载均衡作用,用于分发请求、减轻服务器压力及解决session共享问题,涵盖配置方法、策略及Java项目应用,并提及分布式事... 目录分布式部署NginxJava中的代理代理分为正向代理和反向代理正向代理反向代理Nginx应用场景

Redis中的有序集合zset从使用到原理分析

《Redis中的有序集合zset从使用到原理分析》Redis有序集合(zset)是字符串与分值的有序映射,通过跳跃表和哈希表结合实现高效有序性管理,适用于排行榜、延迟队列等场景,其时间复杂度低,内存占... 目录开篇:排行榜背后的秘密一、zset的基本使用1.1 常用命令1.2 Java客户端示例二、zse

Redis中的AOF原理及分析

《Redis中的AOF原理及分析》Redis的AOF通过记录所有写操作命令实现持久化,支持always/everysec/no三种同步策略,重写机制优化文件体积,与RDB结合可平衡数据安全与恢复效率... 目录开篇:从日记本到AOF一、AOF的基本执行流程1. 命令执行与记录2. AOF重写机制二、AOF的

MyBatis Plus大数据量查询慢原因分析及解决

《MyBatisPlus大数据量查询慢原因分析及解决》大数据量查询慢常因全表扫描、分页不当、索引缺失、内存占用高及ORM开销,优化措施包括分页查询、流式读取、SQL优化、批处理、多数据源、结果集二次... 目录大数据量查询慢的常见原因优化方案高级方案配置调优监控与诊断总结大数据量查询慢的常见原因MyBAT

分析 Java Stream 的 peek使用实践与副作用处理方案

《分析JavaStream的peek使用实践与副作用处理方案》StreamAPI的peek操作是中间操作,用于观察元素但不终止流,其副作用风险包括线程安全、顺序混乱及性能问题,合理使用场景有限... 目录一、peek 操作的本质:有状态的中间操作二、副作用的定义与风险场景1. 并行流下的线程安全问题2. 顺

Java JUC并发集合详解之线程安全容器完全攻略

《JavaJUC并发集合详解之线程安全容器完全攻略》Java通过java.util.concurrent(JUC)包提供了一整套线程安全的并发容器,它们不仅是简单的同步包装,更是基于精妙并发算法构建... 目录一、为什么需要JUC并发集合?二、核心并发集合分类与详解三、选型指南:如何选择合适的并发容器?在多

MyBatis/MyBatis-Plus同事务循环调用存储过程获取主键重复问题分析及解决

《MyBatis/MyBatis-Plus同事务循环调用存储过程获取主键重复问题分析及解决》MyBatis默认开启一级缓存,同一事务中循环调用查询方法时会重复使用缓存数据,导致获取的序列主键值均为1,... 目录问题原因解决办法如果是存储过程总结问题myBATis有如下代码获取序列作为主键IdMappe

Java中最全最基础的IO流概述和简介案例分析

《Java中最全最基础的IO流概述和简介案例分析》JavaIO流用于程序与外部设备的数据交互,分为字节流(InputStream/OutputStream)和字符流(Reader/Writer),处理... 目录IO流简介IO是什么应用场景IO流的分类流的超类类型字节文件流应用简介核心API文件输出流应用文

Android 缓存日志Logcat导出与分析最佳实践

《Android缓存日志Logcat导出与分析最佳实践》本文全面介绍AndroidLogcat缓存日志的导出与分析方法,涵盖按进程、缓冲区类型及日志级别过滤,自动化工具使用,常见问题解决方案和最佳实... 目录android 缓存日志(Logcat)导出与分析全攻略为什么要导出缓存日志?按需过滤导出1. 按

Linux中的HTTPS协议原理分析

《Linux中的HTTPS协议原理分析》文章解释了HTTPS的必要性:HTTP明文传输易被篡改和劫持,HTTPS通过非对称加密协商对称密钥、CA证书认证和混合加密机制,有效防范中间人攻击,保障通信安全... 目录一、什么是加密和解密?二、为什么需要加密?三、常见的加密方式3.1 对称加密3.2非对称加密四、