在2016年，我尽可能的参与到了事件响应的工作中，并且我还花费了超过300小时的时间去作为今年很多安全事件或者数据泄露事件的顾问。这些工作中包括我目前正在进行的工作，协调事件受害者与事件响应人员的关系。而本文中我所列举的这些内容，多数都来自与我的工作内容的总结经验，另外要说明的一点是我主要和科技公司进行合作，所以在这些总结中可能会偏重科技类企业一点。

1、对日志进行统一集中的管理可能会更好

事实上，我认为我这篇文章最重要的一点就是去教会大家如何去区分什么是标准的安全事件，什么是灾难性的事件。而根据日志记录的好坏，将可能成为其中非常重要，甚至可以说是决定性的部分。

我发现，反复的对日志进行审计，能够使你在应对事件时更好的去提供安全策略并且有效的应对事件。因此，我建议任何安全部门或者相关团队都应该去推出一个全面的解决方案，并且尽可能的去投资它，因为这可能意味着需要你们将所有的日志从所有主机、应用程序并且跨团队的去进行归纳整理，尽可能的去减少日志的不同类别。我相信通过这一做法将能在未来为你们团队去进行安全防护提供可靠的信息，并且还可以满足其他团队的可用性需求目标。

A gotcha – 注意用户在您记录的日志中的隐私，以及相关信息的长期存储是否会出现违规。其实缩短保留期以保护用户隐私是非常常见的做法，当然这还将取决于您构建的产品是否有更大的需求。

结论：在大多数安全项目中，优先考虑进行良好，可访问，集中和可报警的日志记录整理。如果这一条做的好，那么很有可能在10分钟内你就会发现一个可能出现的安全警报。

2、当无法找到事件的根本原因时

在这即将过去的一年里，我不止一次的碰到过事件及时已经被解决了，但是仍然无法找到根本原因的情况。这对于很多应急响应人员来说无疑是一场噩梦，因为这意味着面对领导层或者管理层描述自己的解决方案时只能做到暂时的缓解，却无法进行一些明确的针对，不得不使这个情况成为一个看起来心有余而力不足的问题。

事实上，如果能够找到根本原因，那么解决方案更像是：

我们擦拭了这台笔记本电脑，更换了这台服务器，翻阅了这个证书。

而如果无法找到根本原因，解决方案更像是：“我们擦拭了所有的笔记本电脑，更换了所有的服务器，翻阅了所有的证书。”

发现事件的根本原因就像是一个非常重要的里程碑，它决定了事件将要发生的所有可能环境和情绪，以及它是否会走向不好的方向。如果无法发现根本原因，那么对于整个团队来说都可能是有一片乌云徘徊在头顶，使所有人都显得慌张不安，进而感到工作十分困难。因此，不管你的团队是大还是小 – 重要的是经常进行危机演练。

结论：进行常规情况和红蓝对抗练习。这时你们需要将随机错误提供赏金或漏洞披露视为非常有风险的做法。并且在练习场景中，你不能进行控制，你不是无所不知，正确的日志不存在，你并不能理解很多问题，从现在开始与你的团队战斗。

3、攻击者将可能针对家庭进行持续很长时间的攻击。

“带自己的设备”通常用于明确描述员工对组织带来的风险，但这其实并不能很好地描述针对组织内的个人的直接攻击。

今年涉及APT团体的事件很多都是将攻击直接集中在员工的个人电子邮件和终端上。这就使得不管他们是在个人帐户和设备上共享凭据或访问令牌，还是从家里访问公司帐户，或者他们在办公室出现他们的个人设备这都显得无关紧要。

但往往了解从员工家到企业资产的横向移动是非常困难的，手动的去跟进员工是调查的主要方式。目前一个常见的趋势是从对个人帐户和未在公司网络上使用的设备的攻击获取共享密码，但其相关的凭证是进行托管的。

此外（这归因于“零根本原因”）工程师可能将敏感的凭证存储在他们自己的个人云基础设施中以远程调试生产基础设施中，而这很可能是具有高风险性的。

结论：这需要寻找改善员工在家中进行安全防护的方法，对他们进行补贴要求他们使用密码管理器，MFA硬件或任何其他你可以获得的。推动他们和你的安全团队进行多沟通，如果他们有个人安全问题或在下班时看到不良行为，对他们进行教导并使他们能够保护自己的家人免受威胁。

4、比特币成为了重要目标，即使你可能并不拥有它

比特币平台越来越多的受到攻击，而很多黑客们很可能去访问或者参与到比特币公司中去，因此这需要你非常的注意。有关这种趋势的更多信息，或者SendGrid博客上的公共示例，请参考Blockchain Graveyard。

结论：如果你深深的依赖着合作伙伴的技术，那么你首先要做的是去管理这种风险。而如果你是一个比特币公司，那么你可能需要尽可能的去限制除了您的合作伙伴的访问。

5、复杂性往往意味着你的“轻视”

今年的许多事件公告都将“复杂的攻击者”作为他们的问题的叙述。而这样做往往会导致外界大量的批评，这看起来就像是他们表现出的妥协已经暴露了。

其实大多数漏洞都开始于鱼叉式网络钓鱼，商品漏洞，泄漏密钥或其他一些明显或的可预防的细节。

然而，这些往往都不是大家去认为感到“复杂”的方面。实际上这些一开始看起来令人有些犯“尴尬癌”的攻击方式，往往在其最终的攻击出现后尽皆消散。

因此，不要通过他们选择的最初攻击向量来判断对手，他们很可能在最终告诉你真正“复杂”的那一面。

例如，虽然初始向量可能不是显着的或有趣的，但攻击者从单独的平台进行入侵访问或获取凭证就可以发现一些让他们为之心动的内容。

结论：“复杂的”攻击者往往不会在最初的入侵上努力，展现他们的肌肉，因此不要低估那些初期看起来并不成熟的攻击，对手总是会尽最大的努力。这个目前正在运行的钓鱼攻击很可能会跟着一个你不知道的新的0Day。

6、管理好你的隐私和密钥

隐私管理的好坏是公司是否遭受安全事件的一个重要分水岭。在过去的一年里我并没有接触到任何一家进行了严格的隐私管理的公司出现过安全事故，而这可能意味着安全事件在这种情况下发生的并不多，或者说不足以需要我这样的人来进行咨询。

事实上，存储在源代码中的密钥、泄露的云平台记录、没有采取任何安全措施的员工端或个人设备，甚至是复制粘贴到gist和pastebin中的对我来说都是意味着一件事，隐私以及密钥的管理存在着严重的疏漏，而这将可能导致攻击者进一步的扩大破坏程度。

结论：认真的去了解你所使用的云平台，避免将秘密、隐私放在源代码中，尽量让真正的隐私远离开发人员，并能够快速而频繁地去进行更换密钥。

7、窃取证书仍然是最容易的做法

在正常的进行信息传递时，组织内应该要尽可能去避免密码的重复使用，尤其是高层领导间，但在过去的一年里，仍然发生了几起。并且最为重要的是，这种意识的不到位造成的结果就是相关登陆凭证的丢失。

而很多身份管理商正是在这方面进行了拓展，将管理凭据与登录过程在云产品上进行了集成，我没有对任何在企业对身份解决方案中破坏MFA的事件进行回应，当单点登录集成不是一个选项时，在每个产品中查找MFA选项并执行它们也是一个主要的缓解步骤。 特别强调一下GitHub是非常必要的，因为很多团队经常将秘密存储在源代码中，这时就可以通过强制的MFA对团队进行保护，直到更好的秘密存储选项由团队同意了进行。

8、内部威胁其实是有一些模式可循的

我在今年的工作遇到的最小的问题是涉及到内部威胁的情况。其实每个内部人员出现问题时都在一个已知的动机范围内，这一点我已经在好几年都见过了了，2016年也不例外。

比如那些非常关注硅谷创业文化的人，他们在与媒体接触然后引起媒体关注到一些创业公司方面的做法其实非常具有典型性。

具体来说，这其实就是使用了一个内部威胁模型：

如果我现在给科技新闻进行曝光，也许他们就会把这个写成是我的科技创业想法。

虽然这是一个相当具体的模型，但是技术公司的员工真的很喜欢泄漏IP和产品信息来获得这种结果。

这其实是非常常见的情况，完全可以考虑将其作为一种内部威胁的发展趋势类型。并且这是很难防御的，因为这些通常是雇员们不需要太多的信任就可以发生泄漏的现象，很并且难给予广泛适用的预防建议，所以大多数CEO都会选择对员工透明，并接受这种风险。

我看到的第二个模式是内部的客户支持工具。一旦你选择了一定数量的员工可以访问管理工具，其中很可能就有一个员工是内鬼，与他人串通。

9、努力去衡量和消除你的债务

我今年协助的所有组织都有一个不正常的情况就是存在技术债务。这使我不得不相信，将“债务”问题作为工程过程的一部分进行考虑的公司通常是拥有严格纪律的组织，也就会使得其具有较低的风险。而这也就是为什么，他们可以积极竞争、冒险甚至是灵活的进行业务转换。

实际上，从开发到产品成功发布期间，公司之间主要的差异就在于他们如何记录债务，并对他们的债务水平进行一个“回顾”，然后偿还债务。

我很少看到一个团队能够完全消除所有的债务，但至少不尊重债务的组织从来没有走远的，因为这会使得他们不能再在违约中得到帮助。债务其实有多种形式：规模，开发速度，现场可靠性，客户流失，自动化之前的手动工作量和安全性。

问题是安全债务沉默。每一种其他形式的债务导致错误，客户投诉，费用和工程师出现状况。安全债务只会导致违约，几乎不可能量化，因此它需要手动工作量或技术线索来表现安全债务。

一个完全掌握债务的工程组织如果在一个公司出现是非常罕见的，但这其实是一个很好的状况，表明这是一个安全性高的组织。

我很少在实践中看到这一点，但这种水平的工程的出现毫无疑问是一个公司可能成为伟大的迹象。Google就是这样的一家公司，围绕其发布实践构建了“错误债务”，并围绕它制定了政策，这是我发现的使“债务”成为要衡量和解决的客观问题的最好的例子之一。

实际上大多数工程组织不知道他们的一些基本流程（回顾，验尸）帮助他们避免大量债务。