如何定义安全要求以确保开发人员......不会通过默默无闻来提供安全性?

信息安全 朦胧 用户教育 要求
2021-08-22 01:46:03

我试图解释不应该使用默默无闻的安全性,但假设我受到了挑战!

我收到的答案是通过我知道的默默无闻列出已知的安全性,这是一种不好的做法,不应该遵循。事实上,通过默默无闻来定义安全性是相当困难的,但我不相信列出不好的做法也不是正确的方法。

因此我的问题:

  • 有没有人有我可以列出的默默无闻解决方案的安全列表?
  • 定义通过模糊来阻止安全性的要求不是更好吗?但是如何定义这些要求?我想知道是否有人知道设置的正确要求是什么才能通过默默无闻来禁止安全性
4个回答

一个例子是内容加扰系统,以防止 DVD 被复制。虽然加扰系统未知,但这是有效的。然后一个叫Jon Lech Johansen的少年想通了,写了 DeCSS 并且它坏了。

正如@GrahamLee 指出的那样,即使被坏人知道,需要依赖的安全机制也必须仍然有效。

如今,密码学为许多应用程序提供了安全性,因此正确实施它至关重要。因为数学超出了大多数人的范畴,所以有一种思想流派主张发表算法,让全世界的人们尝试寻找缺陷。好处 - 许多眼睛。缺点 - 如果算法已经实现,攻击者可能会发现漏洞并能够使用它,因此在实现之前执行此操作非常有用。

另一种观点是隐藏算法以防止攻击者知道它是如何工作的 - 默默无闻的问题是,已经一次又一次地证明,依靠默默无闻的安全性是失败的,因为在某些时候坏人会发现秘密。

值得一读Bruce Schneier 的这篇文章——他是众所周知的通过默默无闻的安全反对者,以及已经过社区测试的各种加密算法的作者——作为一个例子,说明了默默无闻在哪里起作用,但这只是因为犯罪分子没有了解计划。

我不知道是否有可能在没有更多上下文的情况下真正回答您问题的最后一部分。例如,如果这是由第 3 方开发的代码,您可以要求进行代码审查,但您真正需要的是第 3 方将他们的算法/代码等作为开源发布。

隐匿性安全的典型反例是基尔希科夫原则:密码设计者应该假设密码系统将被敌人捕获,因此如果除了密钥之外的所有内容都已知,它应该仍然是安全的。

请注意,这并不是说默默无闻是不好的,不应该依赖它:它说默默无闻不是唯一的防御措施。那是因为它很脆弱。但默默无闻仍然可以减缓或阻止不熟练的攻击者。

晦涩是无法量化的。

适当的安全性伴随着成本估算。我们说 128 位加密密钥是安全的,因为我们可以估计通过详尽搜索(尝试所有可能的 128 位密钥)找到密钥的成本(专用处理器和电力,最终以美元计)。当成本远高于攻击者愿意花费的成本时,特别是当成本远高于任何使用地球技术的攻击者可能花费的成本时,我们就实现了安全性。

当这样的估计是不可能的,那么它就是默默无闻的安全。例如,假设您在某个软件上安装了某种加密系统,并且您对其保密。那个软件有多少秘密?它写在一些硬盘上。它已经在某个地方开发,它的源代码存在,存储在某个地方。攻击者恢复算法有多难?存储的文件在许多地方泄漏,例如废弃的旧电脑、被盗的笔记本电脑、分包商的轻率行为(软件源代码在文件中,但也在一些程序员的大脑中)......如果攻击者能够掌握二进制文件,他可以拆卸它,这个过程不是立即的,而是仅受攻击者的机智限制。

所有这一切的重点是,虽然让一些代码保密肯定会使攻击者的任务变得更难,但当你想用美元表示时,很难说它有多难。

所以这是我对你的问题的回答:为了防止实施者默默无闻地使用安全性,要求他们应该为攻击提供详细的合理成本估算。

如果您正在尝试为内部开发人员构建安全编码指南,那么该轮子已经被发明出来了。 例如, OWASP有一个广泛的概述,其中包括禁止通过默默无闻依赖安全性的禁令;CERT有非常详细的 C和C++ 标准。