整体 SDL。

根据定义，您无法防御事先不知道的特定攻击。
但是，如果您在所有阶段（包括适当的威胁建模）实施了完整的安全开发生命周期，并且您减轻了威胁（而不是攻击） - 那么您应该相对没问题。

缓解零日攻击的最佳方法是防止零日攻击编写者编写零日攻击。

防止零日攻击编写者编写零日攻击的最佳方法是鼓励他们寻找其他赚钱或成名的方式，这将需要降低数据泄露的难度和利润，以及使身份盗窃和概念“黑客”的乐趣更少。

为了使数据泄露和识别盗窃变得不那么容易/有利可图，我们必须以某种方式改变游戏规则，即摆脱支付卡数据和政府颁发的身份证明，如社会安全号码。我们可能不得不改变我们使用名称和数字的方式，尤其是一起使用。

为了让黑客变得不那么有趣，我们需要让它变得无聊和无用，可能是通过让更新颖的活动比黑客更令人兴奋，并且以某种方式让黑客比水下编织篮子或水下会计更不令人兴奋。

如果上述方法失败，那么最好通过刑事改造、监禁、罚款和其他形式的惩罚来阻止对零日漏洞的犯罪使用。但是，为了准确惩罚，首先我们必须使用零日漏洞来抓捕罪犯。零日漏洞利用的一些伪犯罪使用是“高于法律”的，就像间谍活动在民族国家层面上一样（例如，虚构角色詹姆斯邦德拥有“杀人许可”，可能有些黑客拥有“杀人许可”使用零日漏洞”）。

假设这也失败了，那么我们必须让零日作家编写零日漏洞的成本太高。我相信这是微软针对他们的一些产品所采取的策略。这存在于 SDL 之外，通常涉及利用反措施，例如 DEP、ASLR，以及使用EMET等工具中的技术。

一些 Linux 贡献者通过发明 ASLR 并在他们的grsecurity内核补丁中实现其他概念来采取这种方式。但是，无论是微软还是 grsecurity 开发人员都无法预见非传统的漏洞利用，例如基于 Web 应用程序的漏洞利用、内核漏洞利用、竞争条件以及其他深奥或基于设计的缺陷。

在技​​术方面，解决零日漏洞利用问题要困难得多。这就是为什么我主要提供了一份针对零日漏洞利用问题的人工解决方案清单，我相信这会产生更大的影响。我不是解决这些人类社会问题的专家——如果我是，我会使用这些神奇的力量来对抗饥饿、疾病或其他比零日攻击更深刻的问题。

也许最好让零日漏洞发生。你不能阻止他们被释放。您可以做的一件事肯定会帮助您的组织减少零日漏洞攻击的目标，那就是在从未（或很少）成为零日漏洞攻击目标的基础架构上运行，但这可能会导致安全性模糊。作为这种失败策略的一个例子，AOL 使用了 Stratus 容错设备，但这并不能阻止它们被黑客入侵。

迄今为止最著名的方法之一是利用蜜罐、文件/内核/内存/进程完整性监控（例如带有 TPM 的 BitLocker、Tripwire 等）和诡计来提供防御级别，然后迅速而无情地跟进进攻，很像现代战争。同样，这主要涉及在人员层面工作，而无需大量繁重的技术提升。其中一些方法可以使用商业智能技术进行组合，这也是一些 SIEM 产品（以及 OSSIM 开源 SIEM 工具）尝试做的事情，但这些仍处于成熟和进步的早期阶段，因此不应该自己依赖，但是更大的方法和反零日漏洞利用管理计划的一部分。

如果您谈论针对网络中任何应用程序的零日攻击。我会建议：

在网络防火墙上使用入口过滤并使用出口过滤来限制哪些流量可以从您的系统传出，这意味着如果一台机器受到零日漏洞利用的影响，它可能无法进行出站通信。

使用 IDS / IPS 检测异常流量模式也可能被证明是有效的。

Avi 或 Mark 没有完全提到的一点是“纵深防御”的古老口头禅。这可能是一个非常陈词滥调的短语，但由于多层安全性，攻击者需要使用多个零日来获取访问权限，并且每一层都可以提供更多机会来发现攻击（通过 IDS 等）或做出响应。

一定要开发 SDL，并使用 IDS、IPS 和其他工具，但构建一个安全的架构，它将显着提高您的安全性。