我过去曾为许多组织工作过，这些组织利用了我所说的“通过默默无闻的安全”来证明其合理性的做法，包括以下内容：

• 密码的弱/易受攻击的两种方式散列
• 利用众所周知的各种 API/实用程序来包含严重的漏洞
• 各种形式的数据/代码混淆
• 马虎/没有用户管理
• 继续使用极其不安全的密码
• （名单还在继续……）

通常，对这些问题的修复并不涉及大量投资/更改，我发现很容易获得资源来解决这些问题。我的问题是证明任何潜在的修复是合理的，当这些做法受到挑战时，通常会通过以下评论消除担忧：

• “只有 xyz 组可以访问该网络/产品/机器/登录/任何内容”
• “这不是一个大问题” -未说明的版本：
• “没有人能猜到/知道测试”

即使在非常重视安全性并且审计是一个持续关注的环境中，我总是发现让其他人（尤其是非技术/管理类型）相信设计和维护设计安全的系统的重要性具有挑战性。

我发现，当您使用示例时，人们会在原则上同意您的看法，但这一课真的永远不会深入。当面对对特定系统/子系统为何易受攻击的彻底解释时，管理人员通常会求助于“这不是现在的优先事项”（我不能为它辩护，我不在乎）争论本身就有效，但更多次而不是识别和记录问题，反思经验教训，并制定时间表满足某个预先定义的合规水平，管理层经常会丢弃任何与完全合规相反的证据，确保所有相关方前面提到的系统是“安全的”，并运送产品。

我认为通过默默无闻的安全性不是安全系统的有效部分，并且这种模式所花费的资源是更好地用于应用程序的其他部分的资源。

在我的职业生涯中，我发现实施安全系统最困难的部分不是让其他人相信安全系统的价值或收集必要的资源，而是让其他人相信这一原则。为提高组织的安全性而付出的努力通常会变成一个人的十字军东征，而不是文化和实践的系统性和长期变化。

冒着被广泛或普遍基于意见的风险，向他人传授避免“默默无闻的安全”背后的价值和推理的最佳策略是什么？