我的上一篇博客文章的开头是“无论可能的残余风险......”。我今天想重点关注的正是这

suchonakaniz4

我的上一篇博客文章的开头是“无论可能的残余风险......”。我今天想重点关注的正是这些残余风险。为此，我将首先定义何时可以谈论残余风险，然后更详细地研究它们。

残余风险 - 简短定义
用经济学术语来说，剩余风险可以定义为我作为公司或个人能够承受的风险。这意味着“我的”风险暴露是我可以接受的，这种风险的发生虽然令人痛苦，但不会对我的公司或我个人产生严重影响。这本质上是风险管理流程的目标。当然，灾难性事件发生概率非常非常低的情况很有趣，比如陨石掉到我头上的概率。但下次再详细讨论。

我不想进一步讨论这个经济方面——即使严格来说，它与我的  白俄罗斯 whatsapp 数据​ 进一步评论相关。因为当然软件的开发和运营也是经济风险管理的一部分。

我对最大的视角更感兴趣：如果我不断用尽所有技术和组织选项，还会剩下什么风险？我知道我可能超出了必要的限度。

下一步，我想简要讨论一下实际需要做什么，以便我能够谈论技术和组织上不可避免的风险。

实现最低风险的先决条件
实现这一点的先决条件是实施尽可能安全的安全软件开发流程和操作（通常称为 DevSecOps）。其中包括（无需详细说明）以下几个方面：

完全了解安全要求并实施适当的措施。
进行设计分析或威胁模型（最好多次）。
进行工具支持的静态代码分析，并有选择地通过手动代码审查和修复可能的漏洞来补充它们。
如果可能的话，持续依赖管理（有时也称为软件组成分析）可在 24 小时内修补已使用的存在漏洞的第三方库。
强化的操作和网络环境。
经过安全测试的配置。
安全处理密钥和凭证。
定义、实施和测试恢复时间（例如 RPO、RTO 或 WRT）。
充分的授权概念。
全面的安全测试概念 - 包括可能的动态分析和渗透测试。
不要忘记评估安全机制、漏洞和可能的解决方案的专业知识。
防范 DDoS 和 DoS 攻击的措施。
演示文稿当然有点简短，但其目的是表明所有已知的措施都是通过专业知识实施的。

是否还存在任何剩余风险？
简单的答案是“是”。再次，但并非详尽无遗，还有一些剩余的风险：

零日漏洞（如我上一篇博客文章中所述），即主要存在于第三方库中的漏洞，这些漏洞在没有直接可用的补丁的情况下就已为人所知。
间接使用的库中存在严重漏洞。
漏报 - 例如，测试和检查未检测到的代码漏洞、病毒等。
错误的决定、错误的判断——例如，真正的积极结果被误解。
滥用权利，即员工利用其权利试图进行欺诈或更严重的串谋欺诈。
人为错误——员工由于粗心或匆忙而犯下严重错误。
非常大量的 DDoS/DoS 攻击。
当然，理想情况下，针对大多数残余风险已经采取了补偿措施。例如，您可以作为一个团队来分类漏洞或监控关键流程，以在事后检测欺诈企图。在我看来，它们的共同点就是无法完全消除。

这就是经济考虑发挥作用的地方。在大多数情况下，残余风险应在可接受的范围内。

现实是什么样的？
我的爱好是创建风险模型和风险分析，因此随着时间的推移，我能够支持许多项目。在我从事这项工作的近 15 年里，发生了很多事情，但也必须说，绝大多数项目尚未达到上述水平。

一如既往，也有非常积极的例子。具体来说，在过去的几个月里，我有两个客户，我实际上认为他们非常接近这个“最佳值”。但是，当你已经处于非常有利的位置时，你会做什么呢？

首先，当然，安全是一个过程，这意味着一定不能放松关心和努力。为了降低过于常规地处理安全问题的风险，我通常建议采取以下措施：

1）深度培训，即除了较一般的认知措施外，实际对团队进行新内容的培训。例如，您还可以为开发人员推荐黑客培训，而不是重复经典的 OWASP 十大安全编码培训。