准备应对不舒适情况的组织有更好的机会处理关键事件。
尽管不可能为可能扰乱您组织的每种情况制定计划，但作为综合灾难规划策略的第一步，正如第十六章中所讨论的那样，是务实和可行的。这些步骤包括建立一个事件响应团队，在事件发生之前为系统和人员进行预置，并测试系统和响应计划——这些准备步骤也将有助于为危机管理做好准备，这是第十七章的主题。在处理安全危机时，具有各种技能和角色的人员需要能够有效地合作和沟通，以保持系统运行。
在遭受攻击后，您的组织将需要控制恢复并处理后果，正如第十八章中所讨论的那样。在这些阶段进行一些前期规划也将有助于您进行彻底的响应，并从中吸取教训，以防止再次发生。
为了更全面地了解情况，我们还包括了一些特定章节的背景示例：
由MichaelRobinson和SeanNoonan
与AlexBramley和KavitaGuliani一起
与仅仅希望系统能够在灾难或攻击中幸存下来，或者您的员工能够做出合理的响应不同，灾难规划确保您不断努力提高从灾难中恢复的能力。好消息是，制定全面战略的第一步是务实和可行的。
很少有人在灾难全面爆发时才意识到灾难。与其偶然发现一栋被大火吞没的建筑物，您更有可能首先看到或闻到烟雾——一些看似微小的迹象，并不一定看起来像灾难。火灾逐渐蔓延，直到您深陷其中，您才意识到情况的极端性。同样，有时候一个小事件——比如第二章中提到的会计错误——可能会引发全面的事件响应。
灾难有各种形式：
在本章和下一章中，我们将灾难和危机这两个术语互换使用，意思是任何可能需要宣布事件并采取响应的情况。
潜在灾难的范围很广，但设计灵活的灾难响应计划将使您能够适应迅速变化的情况。提前考虑可能遇到的情景，已经是为其做准备的第一步。与任何技能一样，您可以通过规划、实践和程序的迭代来磨练灾难响应技能，直到它们变得自然而然。
短期恢复阶段应包括为事件制定退出标准，即宣布事件响应完成的标准。成功的恢复可能意味着将服务恢复到完全运行状态，但基础解决方案可能具有提供相同服务水平的新设计。标准还可能要求完全消除风险分析中确定的安全威胁。
在制定应对即时响应、短期和长期恢复以及恢复运营的策略时，您的组织可以通过以下方式做好准备：
进行灾难风险分析是确定组织最关键运营的第一步，这些运营的缺失将导致完全中断。关键运营功能不仅包括重要的核心系统，还包括它们的基础依赖，如网络和应用层组件。灾难风险分析应该确定以下内容：
尽管您可能能够直观地对运营进行评估，但更正式的风险评估方法可以避免群体思维，并突出那些并不明显的风险。为了进行彻底的分析，我们建议使用标准矩阵对组织面临的风险进行排名，该矩阵考虑了每种风险发生的概率以及对组织的影响。附录A提供了一个样本风险评估矩阵，大型和小型组织都可以根据其系统的具体情况进行调整。
您的风险评估可能会因组织资产的位置而有所不同。例如，日本或台湾的站点应考虑台风，而美国东南部的站点应考虑飓风。随着组织成熟并将容错系统（如冗余互联网电路和备用电源）纳入其系统中，风险评级也可能会发生变化。大型组织应在全球和每个站点级别上进行风险评估，并随着运营环境的变化定期审查和更新这些评估。通过风险评估确定需要保护的系统，您可以准备好创建一个配备工具、程序和培训的响应团队。
有各种方法可以配置应急响应（IR）团队的人员。组织通常以以下几种方式配置这些团队：
无论您实现哪种人员配置模型，都可以使用以下技术来创建成功的团队。
在准备响应计划时，您需要确定将响应事件的核心团队，并明确确定他们的角色。虽然小型组织可能会有来自各个团队的个人贡献者，甚至是一个单一团队来应对每一个事件，但资源更丰富的组织可能会选择为每个功能领域设立一个专门的团队，例如，一个安全响应团队，一个隐私团队，以及一个专注于公共面向站点可靠性的运营团队。
您可能需要以下一些或全部角色来进行事件响应：
事件指挥官
领导对个别事件的响应的个人。
可以重新配置受影响的系统或实现代码以修复错误的人。
公共关系
客户支持
可以回应客户查询或主动联系受影响的客户的人。
法律
可以就法律事务提供咨询的律师，例如适用的法律、法规或合同。
隐私工程师
可以解决技术隐私问题的影响的人。
取证专家
可以进行事件重建和归因以确定发生了什么以及如何发生的人。
安全工程师
可以审查事件的安全影响并与SRE或隐私工程师合作保护系统的人。
IR团队的宪章应从团队的使命开始，即一句话描述他们将处理的事件类型。使命让读者能够快速了解团队的工作内容。
为了确保IR团队专注于合格事件，组织领导和IR冠军就范围达成一致意见非常重要。例如，虽然IR团队当然可以回应关于系统防火墙配置和日志启用/验证的个别客户查询，但这些任务可能更适合客户支持团队。
最后，定义团队的成功看起来是非常重要的。换句话说，当IR团队的工作完成或可以宣布完成时，您如何知道呢？
优先级模型定义了人员需要多快回应事件。这个模型建立在您对事件严重性的理解之上，也可以使用五点（0-4）评分，其中0表示高优先级，4表示低优先级。优先级决定了所需工作的节奏：评级为0的事件需要立即响应，团队成员在处理其他工作之前要先回应这个事件。评级为4的事件可以与日常运营工作一起处理。达成一致的优先级模型还有助于保持各个团队和运营负责人的同步。想象一下，一个团队将事件视为优先级0，而对总体情况了解有限的第二个团队将其视为优先级2。这两个团队可能会以不同的节奏运作，延迟了适当的事件响应。
通常情况下，一旦了解了事件的严重性，它在事件生命周期内将保持不变。另一方面，优先级可能在事件过程中发生变化。在对事件进行分类和实现关键修复的早期阶段，优先级可能是0。在关键修复完成后，您可以将优先级降低到1或2，因为工程团队进行清理工作。
在建立了严重性和优先级模型之后，您可以定义操作参数，描述事件响应团队的日常运作。当团队除了事件响应工作外还执行定期运营工作，或者需要与虚拟团队或外包团队进行沟通时，这变得越来越重要。操作参数确保严重性0和优先级0的事件得到及时响应。
操作参数可能包括以下内容：
有许多方法可以组织值班轮换，以确保事件响应工作在团队中得到适当的负载平衡，或者根据定期安排的持续工作进行平衡。有关详细讨论，请参阅SRE书的第十一章和第十四章，SRE工作手册的第8章和第9章，以及Limoncelli、Chalup和Hogan（2014）的第十四章。1
在严重事件期间做出决策可能具有挑战性，因为响应者试图在有限的信息下迅速工作。精心制定的响应计划可以指导响应者，减少浪费的步骤，并为如何应对不同类别的事件提供一个总体方法。虽然一个组织可能有一项全公司范围的事件响应政策，但IR团队需要制定一套涵盖以下主题的响应计划：
事件报告
如何向IR团队报告事件。
分类
将响应初始报告并开始分类事件的IR团队成员名单。
服务水平目标
关于响应者将采取行动的速度目标的参考。
角色和责任
明确定义IR团队参与者的角色和责任。
外联
如何联系可能需要协助事件响应的工程团队和参与者。
沟通
在事件期间进行有效的沟通不是没有提前规划的。您需要建立如何执行以下每一项任务：
playbook是响应计划的补充，列出了响应者应如何从头到尾执行特定任务的具体指令。例如，playbook可能描述如何向响应者授予对某些系统的紧急临时管理访问权限，如何输出和解析特定日志进行分析，或者如何故障转移系统以及何时实现优雅降级。playbook具有程序性质，应经常修订和更新。它们通常是团队特定的，这意味着对任何灾难的响应可能涉及多个团队通过其自己的特定程序playbook进行工作。
您的团队应该定义一个存储文档的地方，以便在灾难期间可以使用材料。灾难可能会影响对文档的访问，例如，如果公司服务器离线，所以确保您在紧急情况下可以访问的位置上有副本，并且这些副本保持最新。
系统会进行补丁、更新和重新配置，威胁态势也会发生变化。您可能会发现新的漏洞，并且新的利用程序会出现。定期审查和更新您的响应计划，以确保它们准确并反映任何最近的配置或操作变化。
良好的事件管理需要频繁和健壮的信息管理。团队应该确定一个适合跟踪事件信息和保留事件数据的系统。处理安全和隐私事件的团队可能希望建立一个严格控制访问的系统，而处理服务或产品中断的响应团队可能希望创建一个在公司范围内广泛可访问的系统。
为了促进对事件的快速响应，IR团队应预先确定事件响应的适当访问级别，并提前建立升级程序，以便获取紧急访问的过程不会缓慢和复杂。IR团队应具有日志分析和事件重建的读取访问权限，以及用于分析数据、发送报告和进行法证检查的工具访问权限。
培训您的员工识别、报告和升级事件。工程师、客户/用户、自动警报或管理员可能会发现事件。每个报告事件的一方应有单独明确的渠道，公司员工应接受如何何时将事件升级给IR团队的培训。这种培训应支持组织的IR政策。
您应该在紧急情况发生之前建立决策标准，以确保响应者选择最合乎逻辑的行动方案，而不是在临时决定时做出直觉决定。第一响应者经常面临需要立即决定是否将受损系统脱机或使用何种封锁方法的情况。有关此主题的更多讨论，请参见第十七章。
一旦您已经创建了组织为应对事件所需的所有材料，如前文所述，评估这些材料的有效性并改进您发现的任何不足是至关重要的。我们建议从多个角度进行测试：
您应该定期进行这些测试，至少每年一次，以确保您的系统、程序和响应在实际紧急情况下是可靠和适用的。
每个组件在将受灾系统恢复到运行状态中发挥着至关重要的作用。即使您的IR团队技能非常高，如果没有程序或自动化系统，其应对灾难的能力将是不一致的。如果您的技术程序已记录但不可访问或不可用，它们可能永远不会被实现。测试灾难响应计划的每一层的弹性可以降低这些风险。
对于许多系统，您需要记录减轻威胁的技术程序，定期审计控制（例如，每季度或每年一次）以确保它们仍在实现，并向工程师提供修复列表，以纠正您发现的任何弱点。刚开始进行IR规划的组织可能希望调查有关灾难恢复和业务连续性规划的认证，以获得灵感。
您应该审计所有关键系统和依赖系统，包括备份系统、日志系统、软件更新程序、警报生成器和通信系统，以确保它们正常运行。完整的审计应确保以下内容：
备份系统正常运行。
事件日志（在上一章中讨论）被正确存储。
关键漏洞应及时修补。
审核自动和手动的补丁流程，以减少人为干预的需求和人为错误的可能性。
警报正确生成。
系统生成警报-电子邮件警报，仪表板更新，短信等-当满足特定标准时。验证每个警报规则，以确保它正确触发。还要确保考虑依赖关系。例如，如果在网络中断期间SMTP服务器离线，您的警报会受到什么影响？
运作良好的通信渠道对于响应团队至关重要。您还应该审核这些工具的故障转移能力，并确保它们保留您需要编写事后分析的消息。
桌面练习是测试记录程序和评估响应团队表现的非常有价值的工具。这些练习可以作为评估端到端事件响应的起点，并且在实际测试不可行时也很有用-例如，引发实际地震。模拟可以从小到大，范围广泛，并且通常是非侵入式的：因为它们不会使系统脱机，所以不会干扰生产环境。
在实现桌面练习时，以下是一些要考虑的关键特点：
可信度
桌面场景应该是可信的-一个引人入胜的情景可以激励参与者跟随而不需要悬置怀疑。例如，一个练习可能假设用户受到网络钓鱼攻击，使对手能够利用用户工作站上的漏洞。您可以基于现实攻击和已知的漏洞和弱点来确定攻击者在网络中移动的关键点。
细节
制定桌面情景的人应该提前研究该情景，引导者应该熟悉事件的细节和对情景的典型响应。为了增加可信度，桌面的创建者可以创建参与者在真实事件中会遇到的文物，如日志文件、客户或用户的报告和警报。
决策点
就像“选择你自己的冒险”故事一样，桌面练习应该有决策点，帮助情节展开。典型的60分钟桌面练习包含大约10-20个情节决策点，让参与者参与决策，影响练习的结果。例如，如果桌面练习的参与者决定将受损的电子邮件服务器下线，那么在剩下的情景中参与者就不能发送电子邮件通知。
参与者和引导者
尽量使桌面练习尽可能互动。随着练习的展开，引导者可能需要对响应者执行的行动和命令做出回应。与其仅仅讨论他们如何应对事件，参与者应该展示他们将如何应对。例如，如果IR手册要求事件响应者将勒索软件攻击升级到取证团队的成员进行调查，同时也要升级到网络安全团队的成员来阻止对敌对网站的流量，那么响应者应该在桌面练习中执行这些程序。“执行响应”有助于事件响应者建立肌肉记忆。引导者应提前熟悉情景，以便在需要时即兴并引导响应者朝正确的方向发展。再次强调，这里的目标是让参与者积极参与情景。
结果
一个成功的桌面练习不应该让参与者感到挫败，而应该以对工作得好和工作不太好的可行反馈结束。参与者和引导者应该能够就事件响应团队的改进领域提出具体建议。在适当的情况下，参与者应该建议对系统和政策进行改变，以解决他们发现的固有弱点。为了确保参与者解决这些建议，创建具体负责人的行动项。
与其测试整个系统的端到端，你可以将大型系统分解为单独的软件和/或硬件组件进行测试。测试可以采用各种形式，可以涉及单个本地组件或具有组织范围的单个组件。例如，当一个恶意内部人连接USB存储设备到工作站并尝试下载敏感内容时会发生什么？本地日志是否跟踪本地USB端口活动？日志是否足够聚合并及时升级，使安全团队能够快速响应？
虽然许多测试涉及系统的技术方面，但测试也应考虑人员故障。当特定人员不可用或未能行动时会发生什么？通常，事故响应团队依赖于对组织具有强大机构知识的个人，而不是遵循既定流程。如果关键决策者或经理在响应期间不可用，那么IR团队的其他成员将如何继续？
除了测试单个组件和依赖项外，还要考虑整个系统失败时会发生什么。例如，许多组织运行主要和次要（或灾难恢复）数据中心。在切换到从次要位置运行之前，您无法确信故障切换策略是否会保护您的业务和安全姿态。谷歌定期对整个数据中心建筑进行电源循环，以测试故障是否会导致用户可见的影响。这种练习确保服务保持在没有特定数据中心位置的情况下运行的能力，并且执行此工作的技术人员在管理断电/通电程序方面经验丰富。
对于在另一个提供商的云基础设施上运行的服务，考虑如果整个可用区域或区域发生故障，您的服务会发生什么情况。
除了宣布的测试，谷歌还进行灾难准备演习，称为红队演习：由其信息安全保障组织进行的进攻性测试。类似于DiRT演习（参见“DiRT演习测试紧急访问”），这些演习模拟真实攻击，以测试和改进检测和响应能力，并展示安全问题的业务影响。
在应对实际事件和测试场景时，创建有效的反馈循环非常重要，这样您就不会反复遭受相同的情况。实际事件应该需要具体的事后分析和行动项目；您也可以为测试创建事后分析和相应的行动项目。虽然测试既可以是一种有趣的练习，也可以是一种极好的学习经验，但这种实践需要一些严谨性——跟踪测试的执行情况，并对其影响以及您组织中的人员如何应对测试进行批判性评估是非常重要的。进行一项练习而不实现所学到的教训只是娱乐。
在评估组织对事件和测试的响应时，考虑以下最佳实践：
为了使本章描述的概念和最佳实践更具体，这里有一些真实世界的例子。
2019年，谷歌对旧金山湾区发生大地震的响应进行了测试。该场景包括模拟对物理设施、交通基础设施、网络组件、公用事业和电力、通信、业务运营和高管决策的影响。我们的目标是测试谷歌对大规模中断的响应以及对全球运营的影响。具体来说，我们测试了以下内容：
有时我们可以同时测试可靠性和安全运营的稳健性。在我们的年度灾难恢复培训（DiRT）演习中，SRE测试了紧急访问凭证的程序和功能：当标准ACL服务中断时，他们能否获得对公司和生产网络的紧急访问？为了增加安全测试层，DiRT团队还纳入了信号检测团队。当SRE启动紧急访问程序时，检测团队能够确认正确的警报触发，并且访问请求是合法的。
灾难规划和准备使我们能够在两个方面减轻风险：技术方面和事件管理方面。在事件管理方面，潜在的灾难如此重大，以至于谷歌指派了一组事件经理全职处理问题。团队需要确定受影响的系统，包括供应商固件图像，并执行一项全面的计划来减轻风险。
在技术方面，SRE已经为Linux内核实现了深度防御措施。一个运行时补丁，或者ksplice，使用函数重定向表来使重新启动新内核变得不必要，可以解决许多安全问题。Google还保持内核推出纪律：我们定期向整个机器群推送新内核，目标是少于30天，并且我们有明确定义的机制，以增加这一标准操作程序的推出速度，如果有必要的话。
如果我们无法使用ksplice修复漏洞，我们可以以较快的速度进行紧急推出。然而，在这种情况下，我们可以使用内核splice来解决受影响的两个函数——tcp_collapse_ofo_queue和tcp_prune_ofo_queue。SRE能够在生产系统中应用ksplice，而不会对生产环境产生不利影响。由于推出程序已经经过测试和批准，SRE很快获得了副总裁的批准，在代码冻结期间应用补丁。
当考虑如何从零开始启动灾难恢复测试和计划时，可能会感到可能的方法的数量令人不知所措。然而，即使在小规模上，您也可以应用本章的概念和最佳实践。
从这一重要的第一步开始，您可以逐步扩大覆盖范围，形成一个强大的灾难准备战略。从最初的确定和预防引发火灾的火花，您可以逐步应对不可避免的大火。
1Limoncelli,ThomasA.,StrataR.Chalup,andChristinaJ.Hogan.2014.云系统管理实践：设计和操作大型分布式系统。波士顿，马萨诸塞州：Addison-Wesley。
第九章讨论了准备组织快速应对事故的其他设计方法。
作者：MattLinton
与NickSoda和GaryO'Connor一起
安全事件是不可避免的。行业中有一句常见的格言是“只有两种公司：知道自己受到了侵害的和不知道自己受到了侵害的。”安全事件的结果取决于你的组织做好了多少准备，以及你的响应有多好。为了实现成熟的安全姿态，你的组织需要建立和实践事件响应（IR）能力，正如前一章所讨论的那样。
事件通知已成为安全领域的核心特性，与云计算的易用性和普及性、工作场所“自带设备”（BYOD）政策的广泛采用以及物联网（IoT）等技术进步并驾齐驱。这些进步为IT和安全人员带来了新的挑战，例如对组织所有资产的控制和可见性的限制。
并非每个事件都是危机。事实上，如果你的组织状况良好，相对较少的事件应该会演变成危机。一旦发生升级，响应者评估升级的第一步是分诊——利用他们掌握的知识和信息对事件的严重性和潜在后果进行合理和明智的假设。
分诊是急诊医疗界的一项成熟技能。一名急救医生（EMT）到达车祸现场时，首先要确保现场没有进一步伤害的立即风险，然后进行分诊。例如，如果一辆公共汽车与一辆小汽车相撞，已经可以逻辑推断出一些信息。小汽车上的人可能受了重伤，因为与重型公共汽车的碰撞可能会造成很大的伤害。公共汽车可以载有许多乘客，所以乘客可能会受伤。通常情况下，两辆车都不会携带危险化学品。在到达的第一分钟内，急救医生知道他们需要叫更多的救护车，可能要警报重症监护单位，并叫消防部门来解救小车上被困的人。他们可能不需要危险物质清理队。
你的安全响应团队应该使用相同的评估方法来对待不断发生的事件。作为第一步，他们必须估计攻击的潜在严重程度。
在分诊时，负责调查的工程师必须收集基本事实，以帮助决定升级是否属于以下情况之一：
他们应该能够使用预定的流程对可预测的问题、错误和其他简单问题进行分诊。更大更复杂的问题，比如有针对性的攻击，可能需要组织和管理的响应。
每个团队都应该有预先计划的标准，以帮助确定什么构成了一起事件。理想情况下，他们应该在事件发生之前确定在他们的环境中哪些风险是严重的，哪些是可以接受的。对事件的响应将取决于事件发生的环境类型，组织预防控制的状态以及其响应程序的复杂性。考虑三个组织如何应对相同的威胁——勒索软件攻击：
您的团队可以进行一些基本评估，以确定升级是否需要标准的流程驱动方法或危机管理方法。问问自己以下问题：
长期以来，IR团队一直负责应对疑似入侵和妥协事件。但是对于软件和硬件漏洞，也就是安全漏洞呢？你会把系统中新发现的安全漏洞视为尚未被发现的妥协吗？
软件漏洞是不可避免的，你可以为它们制定计划（如第八章中所述）。良好的防御实践在漏洞开始之前消除或限制潜在的负面后果。2如果你计划良好并实现了深度防御和额外的安全层，你就不需要像处理事件那样处理漏洞修复。也就是说，可能需要使用事件响应流程来管理复杂或影响较大的漏洞，这可以帮助你组织并快速响应。
在谷歌，我们通常将具有极端风险的漏洞视为事件。即使漏洞没有被积极利用，尤其严重的漏洞仍然可能引入极端风险。如果你在漏洞被公开披露之前参与修复（这些努力通常被称为协调漏洞披露或CVDs），操作安全和保密问题可能需要加强响应。另外，如果你在公开披露后匆忙修补系统，保护具有复杂相互依赖关系的系统可能需要紧急努力，部署修复可能会困难且耗时。
一些特别危险的漏洞示例包括Spectre和Meltdown（CVE-2017-5715和5753）、glibc（CVE-2015-0235）、Stagefright（CVE-2015-1538）、Shellshock（CVE-2014-6271）和Heartbleed（CVE-2014-0160）。
现在我们已经讨论了分类和风险评估的过程，接下来的三节假设“大事”已经发生：你已经确定或怀疑受到了有针对性的妥协，需要进行全面的事件响应。
许多应对者将严重事件升级与不断上升的恐慌感和肾上腺素飙升联系在一起。消防、救援和医疗领域的紧急应对人员在基础培训中被告知不要在紧急情况下奔跑。奔跑不仅会增加现场事故的可能性，使问题变得更糟，还会给应对者和公众灌输恐慌感。类似地，在安全事件中，匆忙行动所获得的额外几秒钟很快就会被计划失败的后果所掩盖。
尽管谷歌的SRE和安全团队执行事件管理的方式类似，但在开始安全事件的危机管理响应和可靠性事件（如故障）之间存在差异。当发生故障时，值班的SRE准备采取行动。他们的目标是快速找到错误并修复它们，以恢复系统到良好状态。最重要的是，系统并不知道自己的行为，并且不会抵制被修复。
作为安全事件响应者，您的第一个任务是控制自己的情绪。在升级的前五分钟内，深呼吸，让任何恐慌的感觉过去，提醒自己需要一个计划，并开始考虑下一步。虽然立即做出反应的愿望很强烈，但实际上，事后分析很少报告说，如果员工早五分钟做出反应，安全响应就会更有效。更有可能的是，提前进行一些额外的规划将增加更大的价值。
在响应者接管并成为IC之后，他们的工作是保持对事件的控制。IC指挥响应，并确保人们始终朝着特定目标前进，以便危机中的混乱和不确定性不会使团队偏离轨道。为了保持控制，IC和他们的领导必须与所有参与者保持卓越的通信。
谷歌使用IMAG作为各种事件的通用响应框架。所有值班工程师（理想情况下）都接受相同基本知识的培训，并学习如何使用它们来扩展和专业地管理响应。虽然SRE和安全团队的重点可能不同，但最终，拥有相同的响应框架使这两个团队能够在压力下无缝合作，当与陌生团队合作可能最困难时。
根据IMAG模型，一旦宣布发生事故，宣布事故的人要么成为事故指挥官，要么从其他可用的工作人员中选择一个IC。无论选择哪种路线，都要明确指定这项任务，以避免响应者之间的误解。被指定为IC的人也必须明确承认他们接受了这项任务。
接下来，IC将评估需要立即采取的行动，以及谁可以担任这些角色。您可能需要一些熟练的工程师来启动调查。大型组织可能会有一个专门的安全团队；非常大型的组织甚至可能会有一个专门的事件响应团队。小型组织可能会有一个专门的安全人员，或者有人在其他运营责任之外兼职处理安全事务。
无论组织的规模或构成如何，IC都应该找到熟悉潜在受影响系统的员工，并将这些人员委派为事件响应团队。如果事件规模扩大并需要更多人员，最好指定一些领导人负责调查的某些方面。几乎每个事件都需要一个运营负责人（OL）：战术上的对应和IC的合作伙伴。虽然IC专注于制定实现事件响应进展所需的战略目标，OL专注于实现这些目标并确定如何实现。大多数执行调查、修复和打补丁系统等技术人员应该向OL汇报。
您可能需要填补的其他主要角色包括以下内容：
管理联络人
您可能需要有人立即做出艰难的决定。您的组织中谁可以决定必要时关闭一个产生收入的服务？谁可以决定让员工回家或撤销其他工程师的凭证？
法律负责人
您的事件可能会引发您需要帮助回答的法律问题。您的员工是否有增强的隐私期望？例如，如果您认为有人通过其网络浏览器下载了恶意软件，您是否需要额外的权限来检查他们的浏览器历史记录？如果您认为他们通过个人浏览器配置文件下载了恶意软件怎么办？
沟通负责人
根据事件的性质，您可能需要与客户、监管机构等进行沟通。擅长沟通的专业人员可能是您响应团队的重要补充。
IC最终负责确保保密规则得到制定、传达和遵守。要求参与调查的每个团队成员都应该接受简要介绍。您可能有特定的数据处理规则，或者对使用哪些通信渠道有期望。例如，如果您怀疑您的电子邮件服务器在违规范围内，您可能会禁止员工之间就违规进行电子邮件交流，以防攻击者能够看到这些对话。
向攻击者透露您已发现他们的攻击的后果可能很严重。一个决心要在您的调查之外持续存在的攻击者可能会保持安静。这会使您失去对他们妥协程度的宝贵洞察，并可能导致您错过他们的一个（或多个）立足点。而已经完成目标并且不想保持安静的攻击者可能会在发现您的行动后尽可能地摧毁您的组织！
以下是一些常见的操作安全性错误：
在您的操作安全性响应中考虑以下良好的做法：
在保持您的事件响应保密的一般建议中有一个明显的例外：如果您面临即将到来且明确可识别的风险。如果您怀疑对一个如此关键以至于重要数据、系统甚至生命可能处于危险之中的系统进行了妥协，可能会有正当理由采取极端措施。在处理作为事件的漏洞或错误的情况下，有时该漏洞可能如此容易被利用并且如此广为人知（例如，Shellshock^(3）），以至于关闭或完全禁用系统可能是保护它的最佳方式。这样做当然会让您的攻击者和其他人明显地意识到出现了问题。
这些重大决定和组织权衡不太可能仅由事件指挥官做出，除非在极端危险的情况下（例如，关闭电网控制系统以防止灾难）。通常，组织内的高管做出这样的决定。然而，当这些决定被辩论时，事件指挥官是房间里的专家，他们的建议和安全专业知识至关重要。在一天结束时，组织在危机中的许多决策并不是关于做出正确的决定；而是在一系列次优选择中做出最佳可能的选择。
调查安全妥协涉及尝试通过攻击的每个阶段来追溯攻击者的步骤。理想情况下，您的IR团队（由分配到该工作的任何工程师组成）将尝试在多个任务之间保持紧密的努力循环。这一努力侧重于确定组织的所有受影响部分，并尽可能多地了解发生了什么事情。
数字取证是指确定攻击者可能在设备上采取的所有行动的过程。取证分析师（进行取证的工程师，最好是经过专门培训和经验的人）分析系统的所有部分，包括可用的日志，以确定发生了什么事情。分析师可能会执行以下一些或所有的调查步骤：
取证成像
制作与受损系统连接的任何数据存储设备的安全只读副本（和校验和）。这样可以在副本被拍摄时将数据保留在已知状态，而不会意外覆盖或损坏原始磁盘。法庭诉讼通常需要原始磁盘的取证图像作为证据。
内存成像
制作系统内存的副本（或在某些情况下，运行二进制文件的内存）。内存可能包含许多数字证据，这些证据在调查过程中可能会有用，例如进程树、正在运行的可执行文件，甚至攻击者可能已加密的文件密码。
文件刻录
提取磁盘内容，以查看是否可以恢复某些文件类型，特别是可能已被删除的文件，例如攻击者试图删除的日志。一些操作系统在删除文件时不会将文件内容清零。相反，它们只会取消文件名的链接，并将磁盘区域标记为以后重用。因此，您可能能够恢复攻击者试图删除的数据。
日志分析
恶意软件分析
对攻击者使用的工具进行分析，以确定这些工具的功能、工作原理以及这些工具可能与哪些系统进行通信。此分析的数据通常反馈给进行取证和检测工作的团队，以提供有关系统可能已被入侵的潜在迹象的更好见解。
在数字取证中，事件之间的关系与事件本身一样重要。
如果你有足够的人员来同时支持多个努力（参见“并行化事件”），考虑将你的努力分成三个轨道，每个轨道负责一个重要的调查部分。例如，你的OL可能会将他们的临时团队分成三个小组：
图17-1显示了各组之间的关系。OL负责保持这些团队之间的紧密反馈循环。
最终，你发现新线索的速度会放缓。在这一点上，IC决定是时候转向补救了。你是否已经学到了所有需要学到的东西？可能没有。但你可能已经学到了所有需要知道的东西，以成功地清除攻击者并保护他们追求的数据。确定在哪里划线可能很困难，因为涉及到所有未知因素。做出这个决定很像知道何时停止加热一袋爆米花：当爆裂之间的间隔明显增加时，你应该在整袋爆米花烧焦之前离开。在进行补救之前，需要进行大量的规划和协调。第十八章会更详细地介绍这一点。
在进行取证调查的早期阶段开始准备清理环境可能看起来有些违反直觉，但如果你有可用的工作人员，那么现在是分配这项任务的好时机。IMAG允许您随时创建自定义角色，因此您可以在事件的任何时候分配修复主管（RL）角色。RL可以在运营团队发现受损区域时开始研究这些区域。凭借这些信息，RL可以制定清理和修复这些受损区域的计划。当运营团队完成他们的调查时，IC将已经制定了清理计划。在这一点上，他们可以启动下一阶段的工作，而不是当场决定下一步该怎么做。同样，如果您有可用的工作人员，现在就指定某人开始事后分析也不为时过早。
借用编程构造，大型事件中的IC角色看起来像是通过while循环的一组步骤：
对抗大型森林火灾是在体力和情感上都非常具有挑战性的，可能需要数天、数周甚至数月。为了对抗这样的火灾，加利福尼亚州林业和消防局将其分为“区域”，并为每个区域指定一个事件指挥官。每个区域的IC都会为其区域制定长期目标和实现目标的短期目标。他们将可用资源分配到不同的班次中，这样当一组团队工作时，另一组团队就休息，并准备在第一组团队疲惫时接替他们的工作。
你应该向接替团队传达的信息取决于事件。在谷歌，我们发现离任团队的IC问自己“如果我不是要把这个调查交给你，我接下来会花12小时做什么？”这个问题的答案应该在交接会议结束之前由接替团队的IC给出。
例如，交接会议的议程可能如下所示：
在任何重大事件中，指挥官需要保持团队士气。这个责任经常被忽视，但是至关重要。事件可能会带来压力，每个工程师对这些高压情况的反应都会不同。有些人会迎接挑战并积极参与，而其他人会发现高强度的努力和模糊不清的情况让他们深感沮丧，他们最想做的就是离开事件现场回家。
作为IC，不要忘记激励、鼓励和跟踪团队的整体情绪状态是实现积极事件结果的关键因素。以下是在危机中保持士气的一些建议：
吃饭
睡觉
减压
观察倦怠
以身作则
领导者公开表达的现实但积极的展望对于设定团队对成功的期望是非常有帮助的。这种展望鼓励团队，并让他们觉得他们可以实现目标。此外，响应团队的成员可能怀疑是否真的鼓励自我关怀（例如，充分进食和睡眠），直到他们看到IC或OL公开这样做作为最佳实践。
在事件响应中涉及的所有技术问题中，沟通仍然是最具挑战性的。即使在最好的情况下，与同事和团队之外的其他人进行有效的沟通也可能很困难。在受到压力、紧迫的截止日期和安全事件的高风险的情况下，这些困难可能会加剧，并迅速导致延迟或错过响应。以下是您可能遇到的一些主要沟通挑战，以及管理它们的建议。
响应者之间的误解很可能构成您沟通问题的主要部分。习惯一起工作的人可能会对未说出的事情做出假设。不习惯一起工作的人可能会使用陌生的行话、不同团队之间意义不同的首字母缩略词，或者假设一个实际上并不普遍的共同参照系。
例如，拿短语“当攻击得到缓解时，我们可以重新启动服务。”来说。对产品团队来说，这可能意味着一旦攻击者的工具被删除，系统就可以安全使用。对安全团队来说，这可能意味着在进行完整调查并得出结论表明攻击者不再能存在于环境中，或者返回环境之前，系统才能安全使用。
当您发现自己在处理事件时，作为一个经验法则，始终明确和过度沟通是有帮助的。解释当您要求某事或设定期望时，即使您认为对方应该知道您的意思。在前面段落的例子中，即使您认为对方应该知道您的意思，也不妨说一下，“当我们确信所有回路都已修复，并且攻击者不再能够访问我们的系统时，我们可以重新启动服务。”请记住，沟通的责任通常属于沟通者——只有他们才能确保他们正在与之沟通的人收到预期的信息。
避免在紧张局势下表达确定性的另一个常见沟通错误是使用避免性语言。当人们在紧张的情况下被期望给出建议，但又没有信心时，他们往往倾向于在陈述中加入限定词。在不确定的情况下避免表达确定性，比如说“我们相当确定找到了所有的恶意软件”，可能会让人感到更安全，但避免性语言往往会使情况变得模糊，并导致决策者的不确定性。再次强调，明确和过度沟通是最好的解决办法。如果您的IC问您是否已经确定了所有攻击者的工具，“我们相当确定”是一个含糊的回答。最好的回答是，“我们对我们的服务器、NAS、电子邮件和文件共享感到肯定，但对我们的托管系统不太有信心，因为我们在那里的日志可见性较低。”
要在事件中取得进展，您需要让人们一起协调他们的努力。与事件响应中的关键参与者进行定期、快速的同步会议是一种特别有效的方式，可以保持对正在发生的一切的控制和可见性。IC、OL、公司律师和一些关键高管可能每两到四个小时开一次会，以确保团队能够迅速适应任何新的发展。
我们建议严格限制这些会议的与会者。如果您的会议室或视频会议室里挤满了人，而只有少数人在发言，其他人在听或查看电子邮件，那么您的邀请名单就太长了。理想情况下，事件负责人应该参加这些会议，而其他人则应该完成需要完成的任务。会议结束后，负责人可以更新各自的团队。
虽然会议通常是共同工作的必要部分，但管理不当的会议会危及您的进展。我们强烈建议IC在每次会议开始时都提前制定一个议程。这可能看起来是一个显而易见的步骤，但在持续事件的肾上腺素飙升和压力下很容易忘记。以下是谷歌在安全事件启动会议上使用的一个示例议程：
以下是进行中的同步会议：
在两个示例议程中，IC指定了一名记录员。通过经验，我们已经了解到，记录员对于保持调查的顺利进行至关重要。负责人忙于处理会议中出现的所有问题，没有精力来做好记录。在事件发生时，你经常会忘记你认为自己会记住的事项。这些记录在撰写事后总结时也变得非常宝贵。请记住，如果事件涉及任何法律后果，您将希望就最佳管理此信息的方式与您的法律团队进行咨询。
长期进行的调查可能需要向以下人员提供不同细节水平的频繁更新：
高管和高级领导
他们应该收到关于进展、障碍和潜在后果的简短、简洁的更新。
IR团队
这个团队需要关于调查的最新信息。
未参与事件的组织人员
您的组织可能需要决定告知人员的内容。如果您告知所有员工有关事件，您可能能够请求他们的帮助。另一方面，这些人可能会传播您意料之外的信息。如果您不告知组织人员有关事件，但他们无论如何发现了，您可能需要处理谣言。
客户
法律/司法系统参与者
本节通过演示一个任何规模的组织可能遇到的妥协情况，将本章内容联系在一起。考虑这样一个情景，一个工程师发现一个他不认识的服务账户被添加到一个他以前没有见过的云项目中。中午，他将自己的担忧上升到了安全团队。经过初步调查，安全团队确定一个工程师的账户很可能已经被入侵。使用之前提出的建议和最佳实践，让我们从头到尾走一遍你可能如何应对这样的妥协。
你响应的第一步是分类。从最坏的情况假设开始：安全团队的怀疑是正确的，工程师的账户被入侵了。使用特权访问查看敏感的内部信息和/或用户数据的攻击者将是一个严重的安全漏洞，因此你宣布了一起事件。
作为事件指挥官，你通知安全团队其他成员：
既然你已经宣布了事件，组织中的其他人——高管、法律部门等——需要知道事件正在进行中。如果攻击者入侵了你组织的基础设施，给这些人发邮件或聊天可能是有风险的。遵循运营安全的最佳实践。假设你的应急计划要求使用组织信用卡在与你组织无关的云环境中注册一个商业账户，并为每个参与事件的人创建账户。为了创建和连接到这个环境，你使用了与你组织的管理基础设施没有连接的全新重建的笔记本电脑。
在晚上9点的团队同步会议上，OL透露他们的团队已经找到了攻击者的初始入口点：一封非常精心制作的钓鱼邮件发送给工程师，工程师被骗以运行一个命令，下载了攻击者的后门并建立了持久的远程连接。
在这样做之后，他们没有对工作站采取进一步行动。相反，云服务日志显示，攻击者直接与服务API进行了交互。他们上传了一个新的机器镜像，并在新的云项目中启动了数十个该虚拟机的副本。伦敦团队尚未分析任何正在运行的镜像，但他们审计了所有现有项目中的凭据，并确认他们所知道的恶意服务账户和API令牌是唯一无法验证为合法的凭据。
得到伦敦团队的更新后，你确认了新的信息，并确认自己将接任IC的职责。接下来，你提炼新的信息，并向高管和法律部门提供简明扼要的更新。你还向团队介绍了新的发现。
尽管你知道攻击者对生产服务拥有管理访问权限，但你还不知道用户数据是否存在风险或受到影响。你给你的取证团队一个新的高优先级任务：查看攻击者可能对现有生产机器采取的所有其他行动。
随着调查的进行，你决定是时候将事件响应的一些组件并行化。如果攻击者可能访问了你组织的用户数据，你可能需要通知用户。你还需要减轻攻击。你选择了一位技术写作能力强的同事担任沟通负责人（CL）。你要求一位不参与取证工作的系统管理员成为整改负责人（RL）。
与此同时，RL制定了组织已知受攻击者影响的每一项资源清单，以及清理每个资源的方案。即使你知道工程师的密码并没有在最初的钓鱼邮件中泄露，你也需要更改他们的账户凭据。为了安全起见，你决定防范尚未发现但可能随后出现的后门。你复制了工程师的重要数据，然后擦除了他们的主目录，在新安装的工作站上创建了一个新的主目录。
随着你的应对工作的进行，你的团队得知攻击者并没有访问任何生产数据，这让大家都松了一口气！攻击者启动的额外虚拟机似乎是一群挖矿服务器，用于挖掘数字货币并将资金转入攻击者的虚拟钱包。你的RL指出，你可以删除这些机器，或者如果你希望以后向执法部门报告事件，也可以对这些机器进行快照和归档。你还可以删除创建这些机器的项目。
到了下午中期，你的团队已经没有了线索。他们搜索了可能受到恶意API密钥影响的每一个资源，制定了减轻方案，并确认攻击者没有触及任何敏感数据。幸运的是，这只是一次机会主义的挖矿行为，攻击者并不关心你的任何数据，只是想在别人的账单上使用大量计算能力。你的团队决定是时候执行你的整改计划了。在与法律和领导层核实关闭事件决定得到他们的批准后，你向团队发出了行动的信号。
由AlexPerry，GaryO’Connor和HeatherAdkins
与NickSoda
正如我们在第八章和第九章中讨论的，根据良好设计原则构建的系统可以抵御攻击并且易于恢复。无论系统是单个计算实例、分布式系统还是复杂的多层应用程序，都是如此。为了促进恢复，良好构建的系统还必须与危机管理策略相结合。如前一章所述，有效的危机管理需要在继续威慑攻击者的同时恢复任何受损资产到已知（可能改进的）良好状态之间取得微妙的平衡。本章描述了良好的恢复检查表所包含的微妙考虑，以实现这些目标。
根据我们的经验，恢复工程师通常是每天设计、实现和维护这些系统的人。在攻击期间，您可能需要召集安全专家担任特定角色，例如执行取证活动、对安全漏洞进行分类或做出微妙的决定，但将系统恢复到已知良好状态需要来自每天与系统一起工作的专业知识。事件协调和恢复工作之间的合作允许安全专家和恢复工程师双向共享信息以恢复系统。
从安全攻击中恢复往往涉及比预先计划的playbooks能够适应的更模糊的环境。攻击者可以在攻击过程中改变他们的行为，恢复工程师可能会犯错或发现关于他们的系统的意外特征或细节。本章介绍了一种动态的恢复方法，旨在匹配您的攻击者的灵活性。
恢复行为也可以成为推动改进安全姿态的强大工具。恢复采取短期战术缓解和长期战略改进的形式。我们在本章中介绍了一些思考安全事件、恢复和下一个事件之间的静默期之间的连续性的方式。
如前一章所讨论的，良好管理的事件受益于并行化响应。并行化在恢复过程中尤其有益。参与恢复工作的人员应与调查事件的人员不同，原因有几个：
在准备恢复并考虑您的选择时，您应该建立一个正式的团队结构。根据事件的范围，这个团队可以小到一个人，也可以大到整个组织。对于更复杂的事件，我们建议创建协调机制，如正式团队、频繁会议、共享文档存储库和同行评审。许多组织通过使用冲刺、Scrum团队和紧密的反馈循环，将恢复团队的运作模式建模在其现有的敏捷开发流程上。
从复杂事件中组织良好的恢复可能看起来像精心编排的芭蕾舞表演，不同个体在恢复过程中的行动相互影响。重要的是，恢复芭蕾中的舞者们要避免踩到彼此的脚。因此，您应该明确定义准备、审查和执行恢复的角色，确保每个人都了解操作风险，并且参与者经常进行面对面的沟通。
信息管理和沟通在恢复过程中是成功响应的重要组成部分。原始事件轨迹、草稿笔记、恢复检查表、新的操作文档以及有关攻击本身的信息将是重要的文档。确保这些文档对恢复团队可用，但对攻击者不可用；使用类似空气隔离的计算机进行存储。例如，您可以使用诸如bug跟踪系统、基于云的协作工具、白板，甚至贴在墙上的便签卡等信息管理工具的组合。确保这些工具不在攻击者可能威胁到您系统的最广泛范围之内。考虑从便签卡开始，并在确保没有恢复团队成员的机器受到威胁后添加独立的服务提供商。
良好的信息管理是确保顺利恢复的另一个关键方面。使用每个人都可以访问并实时更新的资源，以便在问题出现或检查表项完成时进行更新。如果您的恢复计划只能由您的纠正负责人访问，这将成为快速执行的障碍。
在恢复系统的同时，保持关于恢复过程中发生的事情的可靠记录也很重要。如果您在途中犯了错误，您的审计轨迹将帮助您解决任何问题。指定专门的记录员或文档专家可能是一个好主意。在谷歌，我们利用技术撰稿人来优化我们的恢复工作中的信息管理。我们建议阅读第二十一章，其中讨论了更多的组织方面。
对事件的足够了解和了解恢复范围将决定采取哪种路线。通常，在启动恢复操作时，调查团队已经开始了事后分析文档（可能是初步原始笔记的形式），恢复团队在进行过程中更新。该文档中的信息将指导恢复团队的规划阶段（参见“规划恢复”），这应该在启动恢复之前完成（参见“启动恢复”）。
您的恢复工作的目标是减轻攻击并使系统恢复到正常运行状态，并在此过程中应用任何必要的改进。复杂的安全事件通常需要并行化事件管理，并设置结构化团队来执行事件的不同部分。
恢复规划过程将依赖调查团队发现的信息，重要的是在采取行动之前仔细规划恢复。在这些情况下，一旦您对攻击者所做的事情有足够的基线信息，您应该立即开始规划恢复。以下各节描述了一些准备最佳实践和常见陷阱。
您如何定义事件的恢复将取决于您遇到的攻击类型。例如，从单个机器上的勒索软件等较小问题中恢复可能相对简单：您只需重新安装系统。然而，要从在整个网络上存在的国家行为者以及窃取敏感数据的攻击者那里恢复，您将需要来自组织各个部门的多种恢复策略和技能。请记住，恢复所需的工作量可能与攻击的严重程度或复杂性不成比例。一家对简单勒索软件攻击毫无准备的组织可能最终会有许多受损的机器，并需要进行资源密集型的恢复工作。
正如在第十七章中提到的，理想情况下，指挥官会指派某人在调查早期为缓解文档维护行动项目（在“事后检讨”中讨论）。缓解文档和随后的事后检讨将确定解决妥协根本原因的步骤。您需要足够的信息来优先处理行动项目，并将其分类为短期缓解措施（如修补已知漏洞）或战略性的长期变更（如更改构建流程以防止使用易受攻击的库）。
汇总受损资产和短期缓解措施的清单需要进行紧密的沟通和反馈循环，涉及您的事后笔记、调查团队和事件指挥官。您的恢复团队需要尽快了解新的调查发现。如果调查和恢复团队之间的信息交换不高效，攻击者可以绕过缓解措施。您的恢复计划还应该考虑到您的攻击者可能仍然存在并观察您的行动。
您的缓解和恢复清单（参见“恢复清单”和“示例”）将包括切断攻击者与您资源的任何连接，并确保他们无法返回。实现这一步骤需要进行微妙的平衡，需要对攻击有近乎完美的了解，并制定一个执行驱逐的坚实计划。一个错误可能导致攻击者采取您未能预料或看到的额外行动。
考虑这个例子：在事件中，您的调查团队发现攻击者已经妥协了六个系统，但团队无法确定最初的攻击是如何开始的。甚至不清楚您的攻击者是如何首次访问您的系统的。您的恢复团队制定并执行了一个重建这六个受损系统的计划。在这种情况下，恢复团队在没有完全了解攻击是如何开始、攻击者将如何回应，或者攻击者是否仍在其他系统上活动的情况下行动。仍在活动中的攻击者将能够从其在另一个受损系统中的位置看到您已经将这六个系统下线，并可能继续破坏其余可访问的基础设施。
除了损害您的系统外，攻击者还可以窃听电子邮件、错误跟踪系统、代码更改、日历和其他资源，这些资源您可能希望用来协调您的恢复。根据事件的严重程度和您正在恢复的妥协类型，您可能希望使用对攻击者不可见的系统进行调查和恢复。
这些例子可能看起来很极端，但它们阐明了一个非常简单的观点：在攻击的另一侧有一个人在对您的事件响应做出反应。您的恢复计划应考虑在了解攻击者的访问权限并采取行动以最小化进一步危害的风险。
今天，安全事件响应者普遍认为，在驱逐攻击者之前，您应该等到对攻击有全面的了解。这可以防止攻击者观察您的缓解措施，并帮助您进行防御性响应。
尽管这是一个好建议，但要谨慎应用。如果您的攻击者已经在做一些危险的事情（例如获取敏感数据或破坏系统），您可能会选择在完全了解他们的行动之前采取行动。如果您选择在完全了解攻击者的意图和攻击范围之前驱逐攻击者，那么您就进入了一场国际象棋游戏。做好准备，并知道您需要采取的步骤以达到将军！
如果您正在处理复杂的事件，或者有活跃的攻击者正在与您的系统交互，您的恢复计划应包括与调查团队的紧密整合，以确保攻击者无法重新访问您的系统或绕过您的缓解措施。确保告知调查团队您的恢复计划-他们应该确信您的计划将阻止攻击。
在恢复计划的早期阶段，确定您需要进行响应的基础设施和工具，并询问调查团队他们是否认为这些恢复系统已被妥协。他们的答案将决定您是否可以进行安全的恢复，以及您可能需要为更完整的响应做准备的额外补救步骤。
例如，假设攻击者已经入侵了您网络上的几台笔记本电脑和管理它们设置的配置服务器。在这种情况下，您需要在重建任何受损的笔记本电脑之前为配置服务器制定一个补救计划。同样，如果攻击者已经在您的自定义备份恢复工具中引入了恶意代码，您需要找到他们的更改并将代码恢复到正常状态，然后再恢复任何数据。
更重要的是，您必须考虑如何恢复资产——无论是位于目前受攻击者控制的基础设施上的系统、应用程序、网络还是数据。在攻击者控制基础设施的情况下恢复资产可能会导致同一攻击者再次威胁。在这种情况下的常见恢复模式是建立一个“干净”或“安全”的资产版本，例如一个与任何受损版本隔离的干净网络或系统。这可能意味着完全复制整个基础设施，或者至少是其中的关键部分。
回到我们的一个受损配置服务器的例子，您可以选择创建一个隔离网络，并使用全新的操作系统安装重建这个系统。然后您可以手动配置系统，以便您可以从中引导新的机器，而不会引入任何受攻击者控制的配置。
假设您的调查团队报告说，攻击者利用了缓冲区溢出漏洞来攻击您的网络服务基础设施。虽然攻击者只能访问一个系统，但您知道其他20台服务器也在运行相同有缺陷的软件。在规划恢复过程时，您应该处理已知受损的系统，但还要考虑另外两个因素：其他20台服务器是否也受到攻击，以及您将如何在将来减轻所有这些机器的漏洞影响。
如果您使用的是开源或商业软件，并且测试变体超出了您的控制范围，希望维护软件的人已经考虑了可能的攻击变体并实现了必要的保护措施。值得检查软件堆栈其他部分的可用补丁，并将广泛的升级作为恢复的一部分。
许多恢复方法旨在将受影响的资源恢复到已知的良好状态。这一努力可能依赖于系统镜像、存储在代码库中的源代码或配置。您恢复的一个关键考虑因素应该是您的恢复操作是否会重新引入使系统容易受攻击的攻击向量，或者是否会使您已经取得的耐久性或安全性进展倒退。考虑一个包含有漏洞软件的系统镜像，允许攻击者威胁系统。如果您在恢复过程中重用这个系统镜像，您将重新引入有漏洞的软件。
这种漏洞重新引入是许多环境中的常见陷阱，包括依赖于通常由整个系统快照组成的“黄金镜像”的现代云计算和内部环境。在系统重新上线之前，重要的是更新这些黄金镜像并删除受损的快照，无论是在源头还是安装后立即进行。
在从传统备份（如磁带备份）中恢复系统或数据时，您应该考虑您的系统是否也备份了攻击者的修改。您应该销毁或隔离包含攻击者证据的任何备份或数据快照，以供以后分析。
在系统中遵循弹性设计的良好实践（参见第九章）可以帮助您快速从安全事件中恢复。如果您的服务是分布式系统（而不是单片二进制），您可以相对快速、容易地对各个模块应用安全修复：您可以对有缺陷的模块执行“就地”更新，而不会对周围的模块引入重大风险。同样，在云计算环境中，您可以建立机制来关闭受损的容器或虚拟机，并迅速用已知良好的版本替换它们。
然而，根据攻击者已经妥协的资产（如机器、打印机、摄像头、数据和账户），您可能会发现自己只剩下一些不太理想的缓解选择。您可能需要决定哪个选项是最不好的，并为短期内永久驱逐攻击者离开系统而承担不同程度的技术债务。例如，为了阻止攻击者的访问，您可能选择手动向路由器的实时配置添加拒绝规则。为了防止攻击者看到您所做的更改，您可能会绕过正常的程序，不经同行审查和跟踪版本控制系统就进行此类更改。在这种情况下，您应该在将新的防火墙规则添加到配置的规范版本之前禁用自动规则推送。您还应该设置一个提醒，在未来的某个时候重新启用这些自动规则推送。
在决定是否在短期缓解措施中接受技术债务以驱逐攻击者时，问问自己以下问题：
如图18-1中的模板恢复检查表所示，检查表上的每一项都对应一个单独的任务，以及完成该任务所需的相应技能。恢复团队的成员可以根据自己的技能来领取任务。然后，事件指挥官可以确信所有已完成的恢复步骤都已经被勾选。
在发生安全事件后，系统的安全可靠恢复在很大程度上依赖于有效的流程，比如精心构建的检查表。根据您正在处理的事件类型，您需要考虑有效的技术选项。您的缓解和恢复工作的目标是将攻击者从您的环境中驱逐出去，确保他们无法返回，并使您的系统更加安全。第九章涵盖了提前将恢复选项设计到系统中的原则。本节涵盖了在考虑这些原则的情况下执行恢复的实际现实，以及做出某些决定的利弊。
隔离（也称为*隔离）是减轻攻击影响的一种非常常见的技术。一个经典的例子是将恶意二进制文件移动到隔离文件夹的防病毒软件，文件权限会阻止系统上的其他任何东西读取或执行该二进制文件。隔离也常用于隔离单个受损的主机。您可以在网络层面（例如，通过禁用交换机端口）或主机本身（例如，通过禁用网络）对主机进行隔离。甚至可以使用网络分割来隔离整个受损机器的网络——许多DoS响应策略会将服务从受影响的网络中移开。
考虑一些标记这些资产受损的方法，比如在设备上使用高度可见的贴纸，或者保持一个最新的隔离系统的MAC地址列表，并监控这些地址是否出现在你的网络上。贴纸可以主动避免重复使用，而地址列表可以快速地进行反应性移除。确保你的恢复清单和事后总结覆盖了任何隔离资产是否安全和永久地得到了补救。
考虑以下难题：你在三个系统上发现了攻击者的恶意软件，并且正在进入事件的恢复阶段。为了驱逐攻击者，你是删除恶意软件并让系统继续运行，还是重新安装系统？根据你的系统的复杂性和关键性，你可能需要考虑这些选项之间的权衡。一方面，如果受影响的系统是使命关键的，并且难以重建，你可能会倾向于删除攻击者的恶意软件并继续前进。另一方面，如果攻击者安装了多种类型的恶意软件，而你并不知道所有的恶意软件，你可能会错过全面清理的机会。通常，从头开始重新安装系统并使用已知的良好镜像和软件是最佳解决方案。
如果你使用可靠和安全的设计原则来操作你的环境，重建系统或升级软件应该相对简单。第九章提供了一些关于了解系统状态的提示，包括主机管理和固件。
您还应该检查攻击者是否篡改了任何应用程序级别的数据，例如数据库中的记录。如第九章所述，确保备份的强大加密完整性会增加您对这些备份的信心，并使您能够确保您需要与潜在受损的实时数据进行比较的任何比较都是准确的。调和攻击者所做的更改可能也会非常复杂，并且可能需要您构建特殊的工具。例如，为了利用部分恢复，您可能需要定制工具将从备份中获取的文件或记录拼接到您的生产系统中，同时进行同时的完整性检查。理想情况下，在制定可靠性策略时，您应该构建和测试这些工具。
您可能已经有监控措施来检测由软件错误导致的重大数据丢失。也有可能您的攻击者避免触发这些警报。即便如此，审查这些日志总是值得的：数据可能会确定攻击开始的拐点。如果指标显示了这样的拐点，那么您现在有了一个独立的下限，可以确定要跳过多少个备份。
恢复的备份可能包含被意外修改的数据和被损坏的数据。这种损坏可能是由恶意更改（攻击者）或随机事件（例如磁带损坏或硬盘故障）引起的。重建数据的工具往往专注于从随机损坏或恶意损坏中恢复，但不是两者兼顾。了解您的恢复和重建工具提供的功能，以及方法的局限性非常重要。否则，数据恢复的结果可能不符合您的期望。使用常规的完整性程序，例如根据已知的良好加密签名验证恢复的数据，将有所帮助。最终，冗余和测试是应对随机事件的最佳防御措施。
加密密钥通常也用于应用级通信。如果攻击者可以访问存储这些应用级密钥的系统，你需要对密钥进行轮换。仔细考虑存储API密钥的位置，比如你用于云服务的密钥。将服务密钥存储在源代码或本地配置文件中是一个常见的漏洞：如果攻击者可以访问这些文件，他们以后可以访问其他环境。作为恢复的一部分，你应该确定攻击者是否可以访问这些文件（尽管可能无法证明他们被访问），并保守而经常地轮换这些服务密钥。
根据情况，凭证轮换可能需要谨慎执行。对于单个被钓鱼的账户，要求用户更改密码可能是一个简单的任务。然而，如果攻击者可以访问各种账户，包括管理员账户，或者你不确定他们可能已经compromise了哪些账户，你可能需要轮换所有用户的凭证。在创建恢复清单时，确保列出重置账户的顺序，优先考虑管理员凭证、已知被compromise的账户以及授予对敏感资源访问权限的账户。如果你有大量的系统用户，你可能需要通过一次性事件中断所有用户。
如果你可以接触到安全专家，最好在制定恢复计划时咨询他们。这些专家可以进行威胁建模，并提供如何改进你的凭证处理实践的建议。他们可能会建议通过采用双因素认证来消除复杂的密码方案的需要。
一旦你驱逐了攻击者并完成了恢复，下一步是过渡出事故并考虑发生的长期影响。如果你经历了像单个员工账户或单个系统被compromise这样的小事件，恢复阶段和事后可能相对简单。如果你经历了一个更严重的事件，影响更大，恢复和事后阶段可能会更加广泛。
长期的举措可能会融入到你的组织安全姿态改进的整体计划策略中。这些行动项目通常更基本地影响你的系统和流程的运作方式，例如成立专门的安全团队、部署骨干加密或改变操作系统选择。
以下的工作示例展示了事后分析、恢复清单的建立以及恢复执行的关系，以及长期缓解措施如何融入更大的安全计划。这些示例并未涵盖所有的事件响应考虑，而是侧重于如何在驱逐攻击者、减轻他们的即时行动和进行长期变更之间进行权衡。
场景：贵组织使用的基于网络的软件包在云提供商的基础设施中用于为用户流量提供服务的虚拟机（VM）存在常见的软件漏洞。一名机会主义的攻击者使用漏洞扫描工具发现了您的易受攻击的网络服务器并利用了它们。一旦攻击者接管了虚拟机，他们就会利用它们发起新的攻击。
恢复完成后，由所有参与事件的人共同开发的事故事后分析确定了需要一个正式的漏洞管理计划，以便及时主动地发现和修补已知问题。这一建议被纳入了改善组织安全姿态的长期战略中。
场景：在七天内，攻击者对贵组织发起了密码钓鱼攻击，而贵组织并未使用双因素认证。70%的员工上当受骗。攻击者使用这些密码读取了贵组织的电子邮件，并向媒体泄露了敏感信息。
作为这种情况下的IC，您面临着许多复杂性：
与修复负责人合作，您必须权衡快速驱逐攻击者（通过取消他们对电子邮件的访问权限）和确保攻击者在此期间无法访问任何其他系统之间的权衡。这项恢复工作需要精确的执行，图18-3提供了一个假设的清单。同样，出于简洁起见，我们省略了确切的命令和程序，但您的真实清单应包括这些细节。
恢复完成后，您的正式事后分析强调了以下需求：
贵组织还注意到需要一名IT安全专家为您提供建议标准最佳实践。这一建议被纳入了改善贵组织安全姿态的长期战略中。
情景：你并不知情，攻击者已经能够访问你的系统一个多月了。他们窃取了用于保护与客户在网上通信的SSL密钥，向你的源代码中插入了后门，以每笔交易中盗取0.02美元，并监视你组织中高管的电子邮件。
作为IC，你面临着许多复杂性：
我们不会为这种相当复杂的攻击提供详细的恢复检查表，而是会专注于事件的一个非常重要的方面：需要并行恢复。与RL合作，你需要为这些问题中的每一个创建一个恢复检查表，以便更好地协调恢复步骤。在此期间，你还需要与正在了解攻击者过去和当前行动的调查团队保持联系。
例如，你的努力可能需要一些或所有以下恢复团队（你可能还可以想到其他的）：
电子邮件团队
这个团队将切断攻击者对电子邮件系统的访问，并确保他们无法重新进入。团队可能需要重置密码，引入双因素认证等。
源代码团队
这个团队将确定如何切断对源代码的访问，清理受影响的源代码文件，并重新部署经过清理的代码到生产系统。为了完成这项工作，团队需要知道攻击者何时在生产环境中更改了源代码，以及是否存在安全版本。这个团队还需要确保攻击者没有对持久版本控制历史进行更改，并且不能进行额外的源代码更改。
SSL密钥团队
客户数据团队
调和团队
在这种复杂的事件中，通常需要在恢复过程中做出不太理想的选择。例如，考虑需要切断公司电子邮件访问权限的团队。他们可能有一些选择，比如关闭电子邮件系统，锁定所有账户，或者并行启动一个新的电子邮件系统。这些选项都会对组织造成一定影响，可能会提醒攻击者，并且可能并不一定解决攻击者最初获取访问权限的问题。恢复和调查团队需要密切合作，找到适合情况的前进路径。
本书中强调的工程实践将帮助您的组织构建安全可靠的系统，只有在整个组织投入安全可靠文化的情况下，您的努力才会有效。文化是每个组织的强大而独特的定义性组成部分，您不应低估其在推动变革中的作用。
作者：ParisaTabriz
与SusanneLanders和PaulBlankinship
在过去的十年中，Chrome的安全组织经历了四个大致的演变阶段：
团队v0.1
团队v1.0
公开测试版发布一年后，随着浏览器的实际使用开始增长，一个专门的Chrome安全团队应运而生。这个最初的安全团队由来自Google中央安全团队和新员工的工程师组成，利用了Google建立的最佳实践和规范，并从组织外部带来了新的观点和经验。
团队v2.0
这些早期决定最终对团队未来的文化产生了重大影响。它将安全团队建立为不是孤立的顾问或分析师，而是作为安全专家的混合工程团队。这种混合方法最大的优势之一在于它提供了关于如何将安全开发纳入每个Chrome工程师日常流程的独特和实用的见解。
团队v3.0
安全审查
安全团队定期与其他团队协商，帮助设计和评估新项目的安全性，并审查代码库中的安全敏感变更。安全审查是团队的共同责任，并有助于促进知识传递。团队通过撰写文档、举办安全培训，并担任Chrome代码的安全关键部分的所有者来扩展这项工作。
发现和修复漏洞
拥有数百万行安全关键代码和数百名全球开发人员不断进行更改，团队投资于一系列方法，以帮助每个人尽快找到和修复漏洞。
架构和利用缓解
团队意识到永远无法预防所有安全漏洞，因此他们投资于安全设计和架构项目，以最小化任何单个漏洞的影响。由于Chrome可在流行的桌面和移动操作系统上使用（例如MicrosoftWindows、macOS、Linux、Android和iOS），这些操作系统本身不断发展，这需要持续的针对特定操作系统的投资和策略。
可用安全性
无论团队对Chrome软件和用于构建它的系统有多么自信，它们仍然需要考虑用户（毕竟是可犯错误的）如何以及何时做出关乎安全的决定。鉴于浏览器用户的数字素养范围广泛，团队投资于帮助用户在浏览网页时做出安全决策，使安全更易用。
Web平台安全
除了Chrome之外，团队还致力于提升为构建Web应用程序的开发人员的安全性，以便任何人都能更轻松地在Web上构建安全体验。
为每个重点领域确定负责任的领导者，以及后来的专门经理，有助于建立更具可扩展性的团队组织。重点领域的领导者重视灵活性、团队范围的信息共享和项目协作，以确保没有个人或重点领域与其他重点领域隔离。
寻找和留住优秀的人才——那些关心团队使命和核心原则，并且与他人合作良好的人——至关重要。团队中的每个人都参与招聘、面试，并为他们的队友提供持续的成长导向反馈。拥有合适的人才比任何组织细节都更重要。
重要的是，我们追求并考虑了那些对安全感兴趣，但在其他领域具有专业知识或成就的个人。例如，我们雇佣了一名具有丰富SRE背景的工程师，他对保护人们安全的使命非常关心，并且对学习安全感兴趣。这种多样化的经验和观点被广泛认为是团队成功的关键因素之一。
Chrome具有如此强烈的安全重点的一个关键原因是，我们将安全作为核心产品原则，并建立了一个安全被视为团队责任的文化。
尽管Chrome安全团队有幸几乎完全专注于安全，团队成员意识到他们永远无法为Chrome的所有安全负责。相反，他们努力将安全意识和最佳实践融入到每个参与产品开发的人的日常习惯和流程中。系统设计约定旨在使易用、快速和明晰的路径成为安全路径。这通常需要额外的前期工作，但最终导致了更有效的长期合作。
实践中的一个例子是团队处理安全漏洞的方式。所有工程师，包括安全团队成员，都会修复漏洞并编写代码。如果安全团队只是发现并报告漏洞，他们可能会失去对编写无漏洞代码或修复漏洞有多么困难的感触。这也有助于缓解安全工程师不参与传统工程任务时可能出现的“我们”与“他们”的心态。
安全团队成员经常向个人或其经理发送同行奖金或积极反馈，当他们注意到有人在模拟强大的安全实践时。由于安全工作有时会被忽视或对最终用户不可见，因此额外努力直接或与职业目标一致地予以认可有助于为更好的安全性设立积极激励。
独立于策略，如果组织尚未认为安全是核心价值和共同责任，就需要更基本的反思和讨论来证明安全和可靠性对组织的核心目标的重要性。
有效的安全性不应依赖于任何最终用户的专业知识。任何拥有大规模用户群的产品都需要仔细平衡可用性、功能和其他业务约束。在大多数情况下，Chrome的目标是使安全性对用户几乎是不可见的：我们进行透明更新，我们倾向于安全默认设置，并且我们不断努力使安全决策成为易于决策的决策，并帮助用户避免不安全的决策。
在团队v3.0阶段，我们共同承认我们在可用安全方面存在一系列问题，这些问题源于人类与软件的互动。例如，我们知道用户正在成为社会工程和网络钓鱼攻击的受害者，我们对Chrome的安全警告效果表示担忧。我们想解决这些问题，但团队中的人性化软件专业知识有限。我们决定需要有策略地雇佣更多的可用安全专业知识，并与一个对新角色感兴趣的内部候选人偶然取得联系。
当时，这位候选人处于研究科学家的职业阶梯上，Chrome在招聘方面没有先例。尽管最初有所保留，但我们说服了领导层雇佣这位候选人，强调候选人的学术专长和多元化观点实际上是团队的资产，并且对于增强其现有技能组是必要的。与用户体验（UX）团队密切合作，这位新加入我们团队的成员继续建立了Chrome可用安全的重点领域。最终，我们雇佣了更多的UX设计师和研究人员，帮助我们更深入地了解用户的安全和隐私需求。我们了解到，安全专家，由于他们对计算机系统和网络运作方式的高度理解，往往对用户面临的许多挑战视而不见。
用户安全取决于快速检测安全漏洞并在攻击者利用之前向用户提供修复程序。Chrome最重要的安全功能之一是快速自动更新。从早期开始，安全团队与技术项目经理（TPM）密切合作，他们建立了Chrome的发布流程并管理了每个新版本的质量和可靠性。发布TPM测量崩溃率，确保高优先级错误的及时修复，小心谨慎地推进发布，当工程师们进展太快时进行反对，并努力以合理的速度将可靠性或安全性改进的发布推送给用户。
早期，我们利用Pwn2Own和后来的Pwnium黑客大赛作为强制性手段，以查看我们是否能在24小时内发布和部署关键的安全修复。（我们可以。）这需要与发布TPM团队的强大合作伙伴关系和大量的帮助和支持，尽管我们证明了这种能力，但由于Chrome在深度防御方面的投资，我们很少需要使用它。
实践中深度防御的最好例子之一是持续投资于沙盒能力。Chrome最初采用了多进程架构和沙盒化的渲染器进程。这阻止了恶意网站接管用户整个计算机，这对于当时的浏览器架构来说是一个重大进步。在2008年，来自网络的最大威胁是恶意网页利用浏览器妥协在用户的机器上安装恶意软件，而Chrome的架构成功地解决了这个问题。
由于深度防御工作不太可能导致用户可见的变化（如果做得正确），因此领导层更需要积极管理、认可和投资这些项目。
在谷歌内部，我们组织了一年一度的团队外出会议，将Chrome安全团队与中央安全团队和其他嵌入式团队（例如，Android的安全团队）联系起来。我们还鼓励谷歌内的安全爱好者在Chrome上做20%的工作（反之亦然），或者找到与Chromium项目上的学术研究人员合作的机会。
将安全性作为团队责任，拥抱透明度，并与Chrome之外的社区互动有助于创建和推进以安全为中心的文化。追求快速创新导致了一个动态的产品，并有能力灵活应对不断变化的环境。深度防御设计有助于保护用户免受一次性错误和新型攻击。考虑安全的人类因素，从最终用户体验到招聘流程，帮助团队扩大对安全的理解并解决更复杂的挑战。愿意直面挑战并从错误中学习使团队能够努力使默认路径也成为安全路径。
由HeatherAdkins，CyrusVesuna，HunterKing，FelixGrbert和DavidChalloner撰写
与SusanneLanders，StevenRoddis，SergeySimakov，ShylajaNukala，JanetVong，DouglasColish，BetsyBeyer和PaulBlankinship合作
正如本书多次强调的那样，构建系统是一个过程，而改进安全性和可靠性的过程依赖于人。这意味着构建安全可靠的系统涉及解决两个重要问题：
这些问题的答案高度依赖于您组织的目标和文化（下一章的主题）。以下部分概述了如何思考这些问题的一些高层指导，并提供了谷歌多年来如何处理这些问题的见解。
在一个组织中谁负责安全和可靠性？我们认为安全和可靠性应该整合到系统的生命周期中；因此，它们是每个人的责任。我们希望挑战这样一个神话，即组织应该把这些问题的负担完全放在专门的专家身上。
为了进一步扩展这个想法，根据系统的复杂性，组织可能需要具有专业经验的人员来做细微的判断。由于不可能构建一个绝对安全、能够抵御所有攻击的系统，或者一个完全可靠的系统，专家的建议可以帮助引导开发团队。理想情况下，这些指导应该整合到开发生命周期中。这种整合可以采取多种形式，安全和可靠性专家应该直接与开发人员或其他专家合作，以改进系统的每个阶段。1例如，安全咨询可以在多个阶段进行：
任何试图在组织中雇佣安全专业人员的人都知道这项任务可能具有挑战性。如果你自己不是安全专家，那么在雇佣安全专家时应该寻找什么？医学专业人员提供了一个很好的类比：大多数人对人类健康的基本原理有一般了解，但许多人在某个时候会专攻某个领域。在医学领域，家庭医生或全科医生通常负责初级护理，但更严重的疾病可能需要神经学、心脏病学或其他领域的专家。同样，所有安全专业人员通常掌握一般知识，但他们也倾向于在一些特定领域专攻。
在雇佣安全专家之前，了解组织需要的技能类型非常重要。如果你的组织很小，例如，如果你是一家初创公司或一个开源项目，一名综合性专家可能可以满足你的许多需求。随着组织的成长和发展，其安全挑战可能变得更加复杂，需要增加专业化。表20-1介绍了谷歌早期历史上需要相应安全专业知识的一些关键时刻。
表20-1.Google历史上关键时刻需要的安全专业知识
这些标准化的测试机制不一定能证明某人在您组织的安全角色中取得成功的能力，因此我们建议采取一种平衡的方法来评估安全专家，综合考虑他们的所有资格：他们的实际经验、认证和个人兴趣。虽然认证可能表明某人通过考试的能力，但我们见过持有证书的专业人士在应用知识解决问题时遇到困难。与此同时，早期职业候选人或从其他专业角色转入该领域的候选人可能会利用认证快速提升他们的知识。对于对该领域有浓厚兴趣或在开源项目中有实际经验（而不是工作经验）的早期职业候选人来说，他们可能能够迅速增加价值。
由于安全专家的需求越来越大，许多行业和大学一直在开发和完善以安全为重点的学术项目。一些机构提供涵盖多个安全领域的通用安全学位。其他学位项目专注于特定的安全领域（这对博士生来说很常见），还有一些提供了关于网络安全问题和公共政策、法律和隐私等领域重叠课程的混合课程。与认证一样，我们建议在考虑候选人的学术成就时，要考虑他们的实际经验和您组织的需求。
例如，您可能希望首先聘请一名经验丰富的专业人士作为您的第一位安全招聘，并在团队建立并能够提供指导时聘请早期职业人才。另外，如果您的组织正在解决一个小众的技术问题（比如保护自动驾驶汽车），一位在特定研究领域有深入知识但工作经验较少的新博士毕业生可能会很好地适应这个角色。
知道何时开始从事安全工作更多的是一门艺术而不是科学。关于这个话题的意见很多，也各不相同。然而，可以肯定的是，你越早开始考虑安全，你就会越好。更具体地说，多年来我们观察到一些情况很可能会促使组织（包括我们自己）开始建立安全计划：
想象一下，你选择了一个集成在线支付系统不安全的供应商。数据泄露可能会导致法规罚款、客户信任的丧失，以及工程师重新实现系统的生产力损失。许多组织在此类事件后停止存在。
同样，想象一下，你的公司正在与一个有额外数据处理要求的合作伙伴签订新合同。假设，你的法律团队可能会建议你在签署合同之前实现这些要求。如果你延迟了额外的保护措施，并因此遭受了泄露，会发生什么？
首先，为了使安全有效，必须仔细平衡组织的其他要求。为了让这一准则更具体化，我们可以通过关闭数据中心、网络、计算设备等来使谷歌几乎100%免受恶意行为的影响。虽然这样做可以实现高水平的安全性，但谷歌将不再拥有客户，并将消失在失败公司的历史中。可用性是安全的核心原则！为了制定合理的安全策略，你需要了解业务运营所需的内容（对于大多数公司来说，赚取利润所需的内容）。找到业务需求和充分的安全控制之间的平衡。
多年来，我们看到许多公司在组织内部的哪里嵌入安全专家和安全团队进行了实验。这些配置范围从完全嵌入产品团队内的安全专家（参见第十九章）到完全集中的安全团队。谷歌的中央安全团队在组织上配置为这两种选项的混合体。
许多公司在决策方面也有不同的问责安排。我们看到首席信息安全官（CISO）和其他负责安全的领导角色向几乎每个C级高管汇报：CEO、CFO、CIO或COO、公司的总法律顾问、工程副总裁，甚至CSO（首席安全官，通常也负责物理安全）。没有正确或错误的配置，您的组织所做的选择将高度依赖于对您的安全工作最有效的因素。
在谷歌，我们首先建立了一个作为产品工程同行的中央安全组织。该组织的负责人是工程部门的高级领导（副总裁）。这创造了一个报告结构，其中安全被视为工程的盟友，但也允许安全团队有足够的独立性来提出问题并解决冲突，而不会受到其他领导可能存在的利益冲突的影响。这类似于谷歌的SRE组织与产品开发团队保持独立的报告链的方式。通过这种方式，我们建立了一个专注于改进的开放和透明的参与模型。否则，您可能会面临以下特点的团队：
谷歌的中央安全团队依赖于标准流程，如工单系统，与组织的其他部门进行交互，当团队需要请求设计审查、访问控制变更等。要了解这个工作流程的运作方式，请参见“谷歌的智能引入系统”。
随着谷歌的发展，将“安全冠军”嵌入到各个产品工程对等组中也变得很有用。安全冠军成为促进中央安全团队和产品团队合作的门户。在开始时，这个角色非常适合在组织中地位良好并对安全感兴趣或有安全背景的高级工程师。这些工程师还成为产品安全倡议的技术负责人。随着产品团队变得更加复杂，这个角色被分配给高级决策者，如董事或副总裁，这个人可以做出艰难的决定（比如在发布和安全修复之间取得平衡），获取资源并解决冲突。
由于谷歌和Alphabet规模庞大，除了中央安全团队和分布式安全冠军外，我们还为更复杂的产品设立了特殊的分散安全团队。例如，Android安全团队位于Android工程组织内。Chrome也有类似的模式（见第十九章）。这意味着Android和Chrome安全团队负责其各自产品的端到端安全，包括决定产品特定的标准、框架、基础设施和方法。这些专门的安全团队运行产品安全审查流程，并有特殊的程序来加固产品。例如，Android安全团队已经努力加固了媒体堆栈，并从集成的安全和工程方法中受益。
安全团队通常使用颜色来标记他们在保护组织中的角色。所有这些以颜色编码的团队都致力于共同的目标，即改善公司的安全姿态。
蓝队主要负责评估和加固软件和基础设施。他们还负责在成功攻击发生时进行检测、封锁和恢复。蓝队成员可以是组织中任何一个致力于保卫组织的人，包括构建安全可靠系统的人。
红队进行攻击性安全演练：模拟真实对手的端到端攻击。这些演练揭示了组织防御的弱点，并测试其检测和防御攻击的能力。
特定目标
例如，红队可能试图利用客户账户数据（或更具体地说，找到并将客户账户数据外泄到一个安全的目的地）。这些练习与对手的操作方式非常相似。
监视
目的是确定你的检测方法是否能够检测到对手的侦察行为。监视也可以作为未来目标导向参与的地图。
定向攻击
目的是证明那些据称是理论的、极不可能被利用的安全问题的利用是可行的。因此，你可以确定哪些问题值得建立防御。
红队不是漏洞扫描或渗透测试团队。漏洞扫描团队寻找软件和配置中可预测和已知的弱点，可以自动扫描。渗透测试团队更专注于发现大量的漏洞和测试人员试图利用它们。他们的范围更窄，专注于特定产品、基础设施组件或流程。由于这些团队主要测试组织安全防御的预防和一些检测方面，他们的典型参与持续几天。
相比之下，红队的参与是目标导向的，通常持续几周。他们的目标是特定的目标，比如知识产权或客户数据的外泄。他们的范围广泛，使用任何必要手段来实现他们的目标（在安全限制内），穿越产品、基础设施和内部/外部边界。
由于他们并不完全模仿外部攻击者的行为，红队攻击并不是对你的检测和响应能力的完美测试。特别是如果红队由对系统已有知识的内部工程师组成，这一点尤为真实，因为他们试图渗透的系统。
您也不可能频繁地进行红队攻击，以提供对攻击的实时视图或对检测和响应团队的统计显著指标。红队旨在发现正常测试无法发现的罕见边缘情况。尽管存在所有的警告，定期进行红队演习是了解您的安全姿态的一种好方法。
您还可以利用红队来教导设计、实现和维护系统的人员对抗敌对心态。直接将这些人员嵌入攻击团队，例如通过一个小范围的项目，将使他们第一手了解攻击者如何审查系统可能存在的漏洞并绕过防御。他们可以在以后将这些知识注入团队的开发过程中。
与红队合作有助于更好地了解您的组织安全姿态，并制定实现有意义的风险降低项目的路线图。通过了解您当前的风险容忍度的影响，您可以确定是否需要进行调整。
检查和改进您的安全姿态的另一种方法是与发现系统漏洞的外部研究人员和爱好者密切合作。正如我们在第二章中提到的，这是了解您的系统的一种有用方式。
了解如何建立漏洞赏金计划需要一些前期工作。如果选择运行漏洞赏金计划，可以按照以下基本步骤进行：
每个漏洞赏金计划都面临一些可能的挑战，包括以下内容：
需要调整被报告问题的火管
根据您的行业声誉、攻击面、支付金额和发现漏洞的难易程度，您可能会收到大量报告。事先了解您的组织需要做出怎样的响应。
报告质量差
如果大多数工程师都在追踪基本问题或非问题，那么赏金计划可能会变得繁重。我们发现这对于Web服务尤其如此，因为许多用户配置错误的浏览器并且“发现”了实际上并不是bug的bug。安全研究人员不太可能出现在这个范围内，但有时很难事先辨别bug报告者的资格。
语言障碍
漏洞研究人员不一定会用您的母语向您报告bug。语言翻译工具在这里可能会有所帮助，或者您的组织可能有人了解报告者使用的语言。
漏洞披露指南
安全和可靠性是由流程和实践的质量或缺失所创造的。人是这些流程和实践最重要的推动者。有效的员工能够跨角色、部门和文化边界进行协作。我们生活在一个未知未来且对手不可预测的世界。在一天结束时，确保您组织中的每个人都对安全和可靠性负责是最好的防御！
1在SRE工作手册的第十八章中描述的发展轨迹展示了经验丰富的SRE在整个产品生命周期中提供的价值。
22002年的萨班斯-奥克斯法案（公众公司会计改革和投资者保护法）为美国上市公司设定了有关其会计实践的标准，并包括信息安全主题。支付卡行业数据安全标准为保护信用卡信息设定了最低指导方针；任何进行此类支付处理的人都需要遵守合规要求。《通用数据保护条例》是一项关于个人数据处理的欧盟法规。
3一些知名的组织在遭受攻击后破产或申请破产，比如CodeSpaces和美国医疗收费机构。