事件会发生。漏洞会发生。您的响应质量可以决定这是一件倒霉事还是一场灾难。响应之后发生的事情可以决定是无休止的疲于奔命，还是在每次战斗中变得更强大。高质量的事后分析是免费的弹药。每次事件都是某人或某些事件在展示系统的弱点在哪里，只要有人愿意倾听。

这就是一位优秀的信息安全官，或是一位真正的信息安全布道者工程师，可以发挥作用的方式

1. 有些事情发生了。这可能是一次演习，也可能是一次真实事件。

2. 您现在有了可以依据的真实信息。您所处的位置与您从理论出发工作时截然不同。

3. 如果 您知道如何理解这些信息，以及您需要哪些信息，您可能会对项目或组织的安全需求有新的理解。即使这只是对您之前已知内容的确认，它也很重要，因为...

4. 这些信息和分析，如果能有效地沟通，尤其是在事件发生之后，可以成为解决问题的强大工具。

5. 下一次，组织将更加得心应手，另一组弱点可以得到加强。每次迭代都使组织变得更强大。

事后分析的错误可能会产生长期的影响，但它们也可能需要很长时间才能被识别出来。对于不知道区别的人来说，糟糕的事后分析感觉和好的事后分析一样令人满意。不幸的是，它使团队——或整个组织——充满了错误的信念、错失的机会和错误的数据，削弱了其成熟安全能力。这些侵蚀是微小的个体，但就像海水拍打海滩一样，它们最终会聚集起来。了解这些反模式，并务必识别它们。

玩指责游戏。

是的，有些事件显然是一个人的错。但在大多数情况下，有很多责任可以分摊。指责是一种借口，它使人们太容易忽视系统性问题，而寻找惩罚对象会让有价值的信息来源保持沉默。除了实际的恶意内部人员攻击事件外，人员问题应与事件事后分析分开处理。

止步于漏洞。

一旦找到要修补的东西或要更改的配置就停止，这可能是最常见的错误。在最好的情况下，更深入地研究可以确认哪些有效，哪些无效。在大多数情况下，存在不止一个原因。一旦找到某些东西就不要停止寻找；首先探查所有角落。

止步于取证。

另一个常见的错误是寻找技术漏洞或妥协的迹象，例如不正确的防火墙配置、软件错误、rootkit 等，而没有从更大的角度看待可能导致这些事情发生的原因。糟糕的软件工程实践或工程师工具不足会增加错误的发生率。过度劳累和士气低落也会如此。同样，系统缺乏配置管理可能会导致错误，因为这迫使管理员多次重复执行流程。

将失败视为信息。

每一次失败，包括没有足够的信息来做适当的事后分析，本身就是信息。不要忽视这一点。如果您发现自己在事后分析中不知所措，请开始查看您本应需要哪些东西才能完成您没有的事后分析。那是您的第一个经验教训。

将“根本原因”视为形容词。

永远不会只有一个根本原因，因为如果只有一个根本原因，那么另一个根本原因是“我们未能通过实施深度防御来实践容错”。根本原因分析是寻找根本原因的行为（复数），而不是寻找单一根本原因。

回到第一性原理。

在我在印第安纳大学 应用网络安全研究中心 的日常工作中，我们一直在研究一套 七项原则，网络安全总体上可以从中推导出来。第一性原理也反向起作用：它们不仅是执行信息安全的工具，也是弄清楚信息安全如何失败的工具。

• 全面性。 是否有一个无人知晓的系统？是否有风险被忽视？全面性失败往往是范围上的失败。

• 机会。 是否有东西因为负担落在资源不足的内部员工身上而不是使用维护良好的常用工具而未得到维护？员工是否培训不足，以至于他们没有认出他们应该认出的东西？是否没有人掌握当前的威胁？

• 严谨性。 组织是否被未经验证的假设所困扰？监控是否失败？是否有东西没有明确规定，以确保每个人都在同一页上？是否没有部署自动化来确保重复性任务在时间和空间上精确且一致地完成？

• 最小化。 是否有东西比它需要的更大目标？是否有比需要的更多的入口点或更多的移动部件？是否可以通过消除或缩小其某些部分来使某些东西更容易保护？

• 分隔。 是否有人或物拥有它绝对不需要的访问权限？隔离是否失败？密码学是否未得到适当的实施？是否在可以使用分段系统和流程时使用了单片系统和流程？系统或系统组件之间的接口是否不清晰或过于复杂？

• 容错。 是否存在单点故障？是否有凭据不够廉价且易于撤销，以至于在应该更换时没有更换？是否有东西在构建或配置时假设坏事不会发生在它身上？

• 比例性。 安全性或任何系统或软件决策是否是在孤立的情况下做出的，而没有考虑整体环境？这可能是致命的——当安全性妨碍完成工作时，人们会绕过它。当安全性太昂贵时，没有人会实施它。当没有相对于其他风险进行商业案例时，组织将不知道要投资什么安全性，并且可能根本不投资，因为做所有信息安全控制是站不住脚的。

使用这些原则进行分析并学习如何使用它们需要时间，但这样做是值得的。它们对于围绕出现的任何问题灵活运用大脑是无价的，而不是一次学习一种问题类型。每个原则都比这些简短的示例包含更多内容，但此处的示例应为它们如何在事件事后分析中出现提供一个起点。

以下是我通过多年从事事后分析所学到的一些东西。

会有更多的错误。

总是会有更多的错误。有时正确的答案确实是“修补它并继续前进”。但是，不应在不询问是否可以变得更健壮的情况下继续前进。为了防止未来的妥协，修补是否可以更快地发生？是否可以部署辅助控制，以便一个组件中的漏洞不会等同于整个系统中的漏洞？如何提高容错能力？是否有足够的监控来做出适当的响应？如果错误发生在您维护的软件中，那么该错误仅仅是一个错误，还是工程实践阻碍了您的工程师，或者是更深层次的架构问题，应该在重构中清理？

发布补丁很好，但是消除一类问题，而不是引起您注意的一个问题，是系统或组织随着时间的推移以有意义的方式变得更成熟和更安全的方式。

事件是证据，而证据是杠杆。

在任何组织中，都极难提倡将资源投入到安全性中，因为资源总是有限的，预防是不可能量化的。当发生事件时，如果您知道如何有效地使用它，那么您手中就有具体的东西。

不要屈服于将每次事件都变成道德恐慌的诱惑。过分夸大的恐吓战术只会使其他人对安全团队不断发出的灾难呼声充耳不闻。将它留到天塌下来的时候用。相反，看看事件缓解造成的损失或具体阻止了什么。看看揭示了哪些潜在问题，以及如果不解决潜在问题，更多此类事件的总体成本将是多少。谈论风险与回报，并手头准备好美元数字和时间估算，即使它们有点粗略。还要考虑其他组织成本和收益，包括上市时间的变化、人员流动、声誉、责任等等。

不要提供一长串清单。

如果您要求的超过了决策者可以接受的范围，那么您就失去了他们。不要用琐事淹没他们。他们想听取构建系统服务器组件的细节，就像您想听取下次股东大会报告的组成部分一样。也许更少。关于清晰沟通和与管理层合作的书籍有很多，所以我不会尝试在这里重现它们。请去读一两本。

跟踪随时间的变化。

安全专业人员和一般的技术人员往往天生就是问题解决者。我们专注于已损坏的事物。这不仅会使我们在别人看来很消极，而且还会使我们看起来像是在原地踏步，而不是真正取得进展，有时甚至对我们自己也是如此。每次事后分析——无论是演习还是实际的漏洞/事件——都可以用来刺激渐进式改进。充分利用这种聚合需要知道聚合是什么。

具体展示安全性如何逐年提高将提高团队士气，保护安全资源和自主权，帮助领导层将安全性视为具体的、易于处理的问题，而不是无限且模糊的问题，并帮助推动安全界限的人保持理智。此外，如果年度图片不是成熟度的稳步提高，那么最好知道这一点，以便您可以对问题进行分类。无论是缺乏支持、缺乏培训还是其他原因，都要找到一种做得更好的方法。没有什么是完美的安全。努力做得比过去的自己更好。

读者可能会注意到，除了假设可以获得关于事件性质的一些数据外，本文没有谈论取证。事实是，数字取证既昂贵又需要专门的技能。对于不知道如何使用结果信息的组织来说，它也是无用的。掌握基于您可获得的任何信息的事后分析，您很快就会知道何时需要更多信息，以及何时数字取证技术对您的预算和手头的事件有意义。

在您知道更基本的分析是否会让您达到您需要去的地方之前，不要被取证技术的闪亮声音蒙蔽双眼。我的生命攸关的技术项目将在需要时进行数字取证；一个年收入 3 万美元的非营利项目永远不会。我还有一些项目可能没有自己的取证资源，但可能会与 CERT 或 ISAC 合作，以帮助了解与多个组织相关的威胁。

请记住，事后分析的目标是改进您的防御，而不是回答所有问题。现实生活不是夏洛克·福尔摩斯小说。您并不总是得到一个整洁的结局，所有悬而未决的问题都得到妥善解决。事实上，这种情况几乎从未发生过。