文档结构  
翻译进度:已翻译     翻译赏金:0 元 (?)    ¥ 我要打赏

今年(2016年),我接到了很多很多事件响应工作。我作为顾问或志愿者,花了大概300小时回应今年发生的安全事件和数据泄露。

这其中包括接手一个正在进行中的数据泄露事件,或与受害的工程团队和事件响应者协调一个对于事件的答复。

这些教训来自于我对这些事件的集中笔记。我主要(但不仅限于)与科技公司合作,因而你会在这些教训中看到一些偏颇。

集中式日志记录使一切变得更好。

这篇文章的一个主题是:“如何区分标准事件与恐怖的噩梦?“

第 1 段(可获 1.28 积分)

一个围绕日志的好的或坏的故事,将决定事件的其余部分。我多次发现,审计日志是所有良好的安全政策和有效的事件响应的核心。

我在任何事件中所做的第一件事,就是了解我能在多大程度上依赖受害者的日志基础设施。我得到的答案将极大地改变我的经历和公司的成功。 目前有一个在CI/CD/DevOps 文化中的良好趋势,集中记录和警报正在成为一个标准的实践。在过去的三年中,我几乎形成了在任何公司都预期丰富的数据的头衔。

第 2 段(可获 1.38 积分)

我建议任何推迟全面日志记录的安全团队或基础设施团队,放弃几乎其他所有事情,来对日志系统进行投资。这意味着将从所有的主机和应用程序、所有的团队中获取到的日志,集中到尽可能少的日志记录点。

建议你拥有围绕主机、应用、认证和基础设施日志的强大故事,这将在未来指导你预防性的工作。另外,这能够帮助其他追求可用性目标的团队。

结论:配置良好的、方便、集中、可以报警的日志,优先级高于大多数其他安全项目。如果做法正确,一个警报的响应应该很容易在10分钟左右部署进生产环境中。

第 3 段(可获 1.31 积分)

你可能找不到一个漏洞的根本原因。

今年我处理的多个事件最终得到了解决,却没有找到根本原因。

对于那些要与领导和管理人员开会,描述他们缓解事件的努力,而不以数据为导向的受害者来说,这是一个噩梦般的经历。如何遏制事件的恶化,成为一个不完整的和“尽力而为”的问题。

如果你发现了 根本原因,一个缓解方案大概是这个样子:

“我们擦除了这个笔记本电脑的程序,更换了那个服务器,调整了一个凭据。”

如果你发现 根本原因,一个缓解方案更像这个样子:

“我们擦除了所有笔记本电脑的程序,更换了所有服务器,调整了全部的凭据。”

第 4 段(可获 1.33 积分)

根本原因的发现是一个重要的里程碑,它描述了一个事件可能发生的脆弱环境,以及这个环境是否变得不健康。

一片乌云将盘旋在一个团队上空,直到他们发现了指导性的根本原因。这会让人们互相诘难。我努力避免这种团队的毒素。当大量的指责、恐慌和辞职构成了一个强硬的谈话时,我会记得挂断电话。

无论你的角色是大还是小——时常预演一个危机十分重要。

结论:定期进行普通的桌面练习和 团队红色预警演习。将随机的bug赏金或漏洞披露作为全面爆发的练习事件。在你无法控制、有些情况不了解、正确的日志不存在以及大家无法理解一个事件的场景下演习。每时每刻与你的团队一起从头开始奋斗。

第 5 段(可获 1.94 积分)

持续的攻击者将针对家庭。

“带上你自己的设备” 通常用于明确描述员工为组织带来的风险。这没有很好地描述针对组织内部个体发生的直接攻击。

在今年涉及APT集团的事件中,攻击直接集中在员工的个人电子邮件和终端。如果他们在个人帐户和设备中共享凭据或访问令牌,或者从家里访问企业帐户,他们是否带着他们的个人设备出现在办公室将无关紧要。

第 6 段(可获 1.09 积分)

理解从员工家中到公司的横向运动非常困难。在许多场合,对员工进行人工跟进是调查摩擦的主要领域。一个共同的趋势是针对个人账户和设备的攻击获取到共享密码,这些设备未在企业中使用过的,但储存了相关凭据。

此外 (这属于 “无法发现根本原因”类型)一个特殊的事件高度指明了,一个工程师可能在其个人云基础设施存储了敏感凭据,来远程调试生产基础设施的情况。

第 7 段(可获 1.11 积分)

当我们需要日志指导我们的时候,日志反倒无法获得。我们听说过在攻击发生之前几个月,发生了针对高级开发者的攻击,但在没有某种线索开始调查的情况下,针对雇员系统的调查工作会找不到方向而且成本颇高。

结论:找到办法提高你的雇员在家中的安全实践。为他们提供补贴,来使用密码管理器、MFA硬件或任何其他你能找到的安全工具。即使他们有个人安全问题或在不上班时有恶劣的行为,也要努力让他们参与到你的安全措施中来。

第 8 段(可获 1.45 积分)

有人以比特币为目标,即使你没有存储任何比特币。

假设一个平台公司与一个比特币公司有联系,或者是与一个比特币公司整合在一起,这个公司经常会被连累和弱化。请参考Blockchain Graveyard 来获取这个趋势的更多信息,或者从SendGrid的博客 得到这个公共案例。

结论:如果你深深依赖合伙人的技术,找到一种方法来管理风险。如果你是比特币公司,请采取极其强大的措施限制你的合作伙伴的访问。

复杂性在羞辱之后。

第 9 段(可获 1.11 积分)

作为事件的描述,很多漏洞报告指出他们遇到了一个“复杂的攻击者”。当最初始的易受攻击的原因被揭露时,这些报告经常会被批评。

大多数攻击行为开始于网络钓鱼、价值利用、密钥泄露、或其他一些明显的或可预防的细节。

然而,这从不是值得谈论的攻击“复杂的”方面。我们很容易指出这些简单的、令人觉得尴尬问题向量,然后忽略攻击的其余部分。

因此,不要根据其选择的向量来评判一个攻击者。一个对手可能在过了他的滩头阵地(一个简单的漏洞)之后,才告诉你什么才是“复杂”。

第 10 段(可获 1.31 积分)

比如说,尽管一个初始的向量可能不是值得关注的或者有趣的,一个攻击者从另一个平台漏洞获得的访问密码或凭据,可能显示了他们多大的动机和能力来针对你进行攻击。

举一个公共案例:Lockheed公司会将他们2011年受到的攻击描述为复杂吗?即使他们的攻击者已经准备好预先偷取的RSA SecureID数据。。。如果攻击始于一个网络钓鱼,这能代表在某种程度上攻击者不再具有威胁吗?

结论: “复杂的” 攻击者不会在他们最开始的入侵努力中展示他们的肌肉。不要将针对你的最开始蹩脚的攻击低估为不复杂的,一个攻击者在这一阶段总会投入最小的努力。那个普通的网络钓鱼之后,可能是一个新的“零日漏洞攻击”。(即安全补丁与瑕疵曝光的同一日内,相关的恶意程序就出现,并对漏洞进行攻击。)

第 11 段(可获 1.56 积分)

管理你的密钥。

在受害者公司中,对密钥的管理会带来很大不同。

今年,我没有遇到任何一个攻击发生在拥有角色驱动的环境,且密钥完全由一个密钥商店管理的公司中。

这可能代表以下情况中的一种:这种环境根本不存在;这种环境很少;或者他们没有看到能保证安全引入像我这样的IR同事的事件。

保存在源代码中的,泄露到云日志平台上的,在雇员的终端或个人设备中不安全地保存的,或者被复制粘贴到Gist或者Pastebin网站上的密钥,这些在今年是一个一致的主题。密钥的不安全性既是明显的根本原因,也会在被攻击者获得的时候,加剧这次攻击。

第 12 段(可获 1.63 积分)

结论:调查一下AWS云平台的角色,避免将密钥放在源代码中,让真实的密钥远离开发者,以及保障自己能快速和频繁地修改密钥。

凭据盗窃仍然是在最低处悬挂的果实。

尽管拥有避免密码重用的健康的信息传递机制,尤其是拥有资深的执行领导,一些组织仍然遇到了一些安全事件。这种安全意识如果没有传达到雇员,考虑到个人账户问题,这种意识终究没有用处。

尽管这种意识能够很好地推迟不可避免的事件发生,更有效的办法是使用一个身份提供商来管理密钥,以及将单点登录系统(SSO)集成到他们的云产品中。我还没有遇到任何一个在企业身份解决方案中MFA被攻破的安全事件。

第 13 段(可获 1.45 积分)

当无法进行单点登录系统的集成时,在每个产品中找到MFA选项并执行它,也是一个主要的缓解攻击的步骤。采用GitHub是有必要的,因为团队经常将密钥存储在由全组范围的MFA保护的源代码中,直到一个更好地密钥存储选项被团队公认采用。

内部威胁有一定的模式。

今年我遇到的最少数的问题涉及内部威胁。每个内部问题都是在一个已知的动机范围内,我看到好几年都是这样,2016年也不例外。

第 14 段(可获 1.25 积分)

第一种模式包括这样的人:他们极为认同硅谷的创业文化,并且在接近媒体来为他们当前或未来的公司吸引注意力方面非常激进。

特别地,你可以使用这样的内部威胁模型:

如果我向科技媒体泄露一些信息,也许他们之后会写一些有关于我的科技创业想法的文章。

尽管这是一个非常具体的模式,在高科技公司的员工 真的 喜欢为了各种出路泄漏IP和产品信息。

这种情况是常见的,足以让我们考虑内部威胁的趋势类型。这种威胁很难防御,因为这些通常是由不需要太多的信任就能够泄露信息的员工造成的。我很难对此给出有用的建议,同时我不建议像Apple公司那样的封闭模式。大多数CEO希望对员工透明,并接受这种风险。

第 15 段(可获 1.88 积分)

我见到的第二种模式是关于内部的客户支持工具的。一旦你允许一些员工访问管理工具,一个离群的雇员可能会进行欺诈,或者与其他人同谋一起做这个事情。

衡量和消除你的债务。

今年我协助的几乎所有组织都有一个惊人的技术债务。

这使我相信,考虑“债务”作为工程过程的一部分的公司,通常是具有高度纪律、较低风险的组织。

原因如下:一个创业公司可能快速前进,他们能够切掉不重要的边角工作。他们能够激进地竞争,并承担风险。

第 16 段(可获 1.3 积分)

在开发以及成功启动的过程中,各个公司的不同点在于,他们能否很好地记录他们抄过的“捷径”,并“反思”他们的技术债务积累了多少。

然后他们偿还他们的债务。

我很少看到一个团队消除 所有 债务,但组织 至少 使得他们的债务不累积太多,导致他们无法缓解一个攻击。

债务有多种形式:规模、发展速度、网站可靠性、客户流失、自动化前的手工工作和安全。

问题是,安全的债务是静默的。所有其他形式的债务导致错误、客户投诉、费用和工程师的愤怒。 安全债务只导致漏洞攻击,而且几乎无法量化。需要手工努力或技术治理来偿还安全债务。

第 17 段(可获 1.73 积分)

作为一个公司或者一个易于保证安全的组织,一个掌握其债务的工程组织是罕见的。这是一个症结所在。

我很少在实践中看到这一点,但在一家公司,这种开明工程的愿望是一个极好的迹象。Google将其“错误债”围绕其发布行为构建,并针对它采取了一些策略,这是我见过的让“债务”成为一个能够衡量和解决的客观问题的最好案例之一Ollie Whitehouse @ NCC Group 也曾 介绍过这个话题

第 18 段(可获 1.25 积分)

大多数工程组织不知道他们的一些基础流程(反思、事后分析)能帮助他们避免大量的债务区域。

结论:确保在开始下一个大的计划前,你最大的技术债务已经偿还了。

总结

我们最能从我们的安全事件中吸取教训。重要的是找到方法讨论他们并从中学习。如果你参与事件响应,我希望你也可以!

@magoo

我是一个安全工程师,曾在Facebook、Coinbase工作,现在担任为数不多的初创公司的导师和顾问。事件响应和安全团队建设通常是我的事情,但我基本上涉及安全相关的各个方面。

第 19 段(可获 1.41 积分)

文章评论