引用AviD的话：

以牺牲可用性为代价的安全是以牺牲安全为代价的

如果你让实现安全策略变得太难，人们要么会忽略它，要么会寻找漏洞和变通方法来实现它的字面意思，而不是精神上的。因此，您将达到与预期相反的结果并削弱安全性。

为此的安全策略应该：

• 目标是让人们对问题敏感，而不是强制执行解决方案。
• 鼓励人们承担维护良好安全的责任，而不是盲目地遵循指示。
• 主要是应该政策而不是必须政策，所以人们在有充分理由时可以分歧。
• 在安全性和可用性之间找到合理的折衷方案。

轶事：我的一个朋友在一个维护系统的团队中工作，该系统具有非常严格的密码策略。它不仅要求定期更改密码、最小长度和数字、小写、大写和特殊字符的使用，它还有一长串规则，旨在防止密码与以前的密码过于相似密码。结果是，您通常可以在垃圾箱中找到文件，或者在办公室周围乱扔文件，人们试图在其中构建密码以适应这些严格的政策。多亏了密码政策，通过垃圾箱潜水获得密码会非常容易。

写过许多政策的人的一些建议：

规则1。

这是最重要的规则。事实上，它需要启动任何其他进程。如果您的管理团队不打算支持这些政策，那么您的时间、公司的时间都不值得，更不用说用户制定任何事情的时间了。我说的是你的 C 级，如果他们不在船上，现在就停下来。拯救你的精神痛苦。

政策、标准、程序、指南

它们之间存在巨大差异，您应该阅读它，但简而言之：

• 政策——我们为什么需要这个？
• 标准 - 这需要什么？
• 程序 - 我们如何执行此操作？
• 指南 - 最佳实践、重要脚注等。

政策就是目标

政策是您在公司中为之奋斗的目标。但是，您无法始终满足您的政策目标的情况会出现。我们称之为例外，通常会有团队分析不满足要求的风险。一些企业可以例外地采用毫无意义的安全政策（非常糟糕），而其他公司则受到如此严格的监管（想想银行业），如果不遵守政策可能会对公司的运营产生重大影响。

用户很重要............ ish

组织越大，用户越多，意见越多，改变就越难。在一定程度上，变革是由管理层在员工的帮助下制定的。较小的组织，可以由员工在管理层批准下制定。这听起来很相似，但对于交互来说可能会有很大的不同。

信息安全在政策方面遇到了相当艰难的时期，因为我们通常会强迫其他团体遵守我们的任务这一简单事实。在大公司中，强制执行诸如密码要求之类的策略并不是 IS 负责实施的事情。它通常是 OPS 团队或应用程序所有者。

不是每个人都需要政策，但它会影响他们

会计部门的 Jenny 并不关心信息安全部门的 Paul 要求 IT 部门的 Frank 确保服务器正在运行 TLS 或在会计应用程序上实施最低密码。如果您没有保单，Jenny 会在意，神奇的是，有一天 Jenny 的密码 1234 必须是 8 个字母数字字符。这不是政策，这是影响，您可能参与也可能不参与处理。简单的说明，HR是你的朋友。

您在这里基本上有两个选择：1）您考虑能力并制定例外流程，或 2）您拒绝与无法实施您的政策的任何人合作。

如果您不做 1) 并且不能做 2)，则意味着您的保单仅存在于纸面上。如果你没有能力让 2) 发生，那么你就只能考虑能力了。不过，我想说的是，你需要有一些严格的能力。如果供应商不能做到最少 12 个字符，您可能可以接受给定的其他缓解策略，但您不希望适应真正令人震惊的问题，例如硬编码的管理员密码。

根据您所采用的策略，您可以做的一件事是使您的策略相互补充，如果您还实施另一策略，则其中一个策略的实施会变得更容易和/或更安全。

例如：您给出密码要求的示例策略。如果您在该政策的同时还制定了一项政策，要求您的用户使用密码管理器，该管理器可以以安全的方式处理和存储正确的密码，您的用户将不太倾向于玩弄系统，因为不会玩弄系统更容易。

另一个例子：如果你要求你的用户在他们的前端服务器上使用 TLS，他们中的一些人可能会用过期或不安全的证书做一个伪劣的实现。一个补充策略是使用 Let's Encrypt 来简化证书处理。

您可以同时使用的东西是通过货币激励来鼓励人们正确实施政策。我不是在谈论向那些表现不佳的人发放费用或罚款，而是更多关于基于某些可量化和公平目标的许可或支持费用等方面给予小幅折扣（如 1% 或其他东西）。例如：如果运行您的需要 TLS 的产品的网站在 Qualys 上获得 A（这很容易检查），他们在下一次许可证续订时获得 1% 的折扣（除非您是维护该网站的人，当然）。

因此，您以这样一种方式编写您的政策，即各个细分市场相互加强，并奖励那些超越职责范围的人。