供应商生态系统仍将是运营中断的主要影响因素，例如CrowdStrike导致的“全球蓝屏”不得不让首席信息安全官们警醒。但你准备好迎接下一个不可避免的事件了吗？这里有五个步骤的行动计划，可以帮助你的组织在下一次重大的IT“地震”中幸存下来，无论是由于另一个早已锈迹斑斑的安全更新还是来自于第三方漏洞。
1. 建立一个“作战室”
在CrowdStrike事件发生后，最能有效地恢复运营的是那些能够迅速将关键决策者聚集在“作战室”的组织。作战室是一个集中的指挥中心，专家们聚集在这里实时管理发生的危机。许多组织错误地认为，精心制定的事件或应急响应计划足以降低运营中断风险。但是正如CrowdStrike事件如此微妙地指出的那样，你无法为每一种可能的IT中断做好准备。
作战室是一项关键的安全措施，可以弥合你的应对计划和计划外IT危机之间的差距。为了有能力解决最广泛的潜在中断，你需要用主要风险类别的代表来填补你的作战空缺。对于大中型企业，专业人员名单至少应包括你的：
首席信息安全官 – 代表IT/网络风险敞口
首席财务官 – 代表财务风险敞口
首席风险官 – 代表运营风险敞口
除了C-Suite成员外，在作战室的其他人员可以还有：
合规主管 – 代表合规风险敞口
IT经理 – 代表IT和数据安全风险敞口
网络安全经理 – 代表安全和第三方风险敞口
法务 – 代表法律风险敞口
无论特定事件引发的具体风险暴露如何，你的所有作战室成员都应该聚集在一起。如果中断严重到足以触发作战室会议，它可能会在多个风险类别中产生涟漪效应，需要跨多个业务职能部门进行协作响应。
无论会议是亲自进行还是远程进行，作战室设置都应启用以下功能：
- 快速信息共享：通过影响分析报告或供应商风险摘要报告，有效分解有关活动事件的所有关键信息。
- 决策敏捷性：能够做出迅速、明智的决定，以减轻中断的影响并加快恢复工作。
- 实时影响和补救监控：所有成员都应该能够访问所有受影响系统的实时监控源。如果已经部署了补救措施，成员应该可以查看每个任务的状态。
- 开发和维护事件时间表：在高危的处境下，很难跟踪近实时发生的事件并寻找它们之间的因果关系。详细的时间表对于管理未来的审计和合规流程也至关重要。
2. 不要过于依赖自动化
在一个我们被过程自动化宠坏的世界里，我们很容易变得自满，允许所有关于手动方法的知识萎缩。然而，CrowdStrike事件颠倒了多年来的IT进步，突然普及了老派的事件响应方法。
由于错误的CrowdStrike更新影响了受影响系统的核心功能，大多数自动补救任务都是无效的，需要一种耗时、手动的方法来清除数百万台有问题的更新设备。
为了确保你的IT人员保持敏捷的手动解决问题的本能，是时候考虑重新引入黑客演习。为了增强对类似于CrowdStrike事件的供应商生态系统中断的复原能力，请选择提升第三方风险管理计划影响的项目。以下是一些例子。
- 事件响应模拟
开发和实施全面的事件响应手册，集成自动响应脚本和实时系统遥测仪表板，以应对大规模IT中断。
- 自动补救工具
创建复杂的自动化脚本或软件代理，可以使用机器学习模型来检测、隔离和补救错误更新引起的问题，以预测和防止类似事件。
- 增强监控和警报系统
使用人工智能驱动的异常检测算法、实时警报机制设计和部署高级监控解决方案，并将其集成到SIEM（安全信息和事件管理）系统中。
- 风险评估和管理框架
构建强大的风险评估工具，利用大数据分析和持续监控能力，动态评估和可视化第三方供应商风险。
- 灾难恢复计划制定
开发详细的灾难恢复框架，包括自动故障转移系统、连续数据复制技术和无缝恢复流程的编排工具。
- 安全测试自动化
创建和集成CI/CD管道安全测试工具，在部署更新之前自动执行静态和动态代码分析、漏洞扫描和渗透测试。
- 多云弹性策略
使用Kubernetes和多云管理工具等容器编排平台，在多个云提供商之间开发和实施工作负载分配和故障转移策略。
- 实时事件通信平台
构建和部署具有事件跟踪、自动通知系统和集成协作工具的实时通信平台，以进行高效的事件管理和协调。
3. 完成关键系统的端到端依赖链映射
CrowdStrike事件最重要的教训之一是要去了解关键系统的端到端依赖链的重要性。这种意识将有助于风险管理团队预测外部中断的可能影响以及恢复正常运营所需的努力。
你的依赖映射应该能够识别你的关键系统所依赖的所有相互连接的组件和服务，以正常运行。这项工作涉及几个步骤：
- 第1步 – 对你的IT资产进行库存化：对关键系统受到损害的所有硬件、软件和网络组件进行编目。
- 第2步 – 识别相互依赖性：了解所有关键系统组件如何相互作用。这项工作应该沿着依赖链延续到你的供应商生态系统，并注意到对第三方服务和托管服务提供商的外部依赖。
- 第3步 – 文档流程和工作流程：生成依赖这些系统的所有流程和工作流程的详细文档。这项工作将更容易地在依赖链的任何时候，做到失败影响的可视化。
- 第4步 – 评估关键性：评估每个组件和依赖性的临界性。确定哪些元素对运营至关重要，哪些具有冗余或故障转移选项。
4. 实施软件变更管理流程
CrowdStrike事件再次强调了有效的软件更改管理策略的重要性。以下是一些确保未来有故障的安全更新不会损害系统稳定性的关键要素：
- 全面测试：始终在受控环境中对新更新进行彻底测试。这项工作应该包括单元和集成测试。一旦确认不会发生中断，请向IT环境逐步扩展推出更新，始终在每次推出扩展时监控中断。考虑在预先确定不需要立即更新安装的IT系统上开始推出。
- 审批工作流程：建立准确的变更审批流程。让多个利益相关者参与进来，如IT、网络安全和业务部门。
- 文档：记录与新版本相关的所有新更新和IT生态系统变化。这将为恢复工作留下有用的审计线索。
- 备份和回滚计划：在应用更新之前，始终有一个回滚计划，以便在发生事件时立即激活。
- 更改窗口期：在预定义的更改窗口期间安排更新，以尽量减少对操作的影响。更新应在高峰营业时间之外进行，以尽量减少潜在中断的影响。任何可能产生重大影响的即将更新都应提前通知利益相关者。
5. 考虑多云策略
多云策略可以显著降低依赖单一云服务提供商（CSP）的风险集中度。这种方法涉及在多个CSP之间战略性地分配工作量，从而减少因单个CSP失败而导致重大运营中断的可能性。多云策略的一些例子包括：
- 工作负载分配：关键系统工作负载在多个CSP之间分配，从而将更重要的应用程序的权重分配给CSP，故障的可能性最小。
- 冗余和多样化：这是一种更通用的工作量分配方法，重点是多样化，从而大大降低因单个故障CSP而导致总系统中断的可能性。
- 故障转移机制：当CPS失败时，故障转移机制会自动将流量重新路由到备用CSP。这种方法的有效性取决于无缝操作的分流，而不会对服务可用性产生任何明显的影响。Kubernetes或多云管理平台等工具可以监控不同CSP的服务运行状况，并在无需手动干预的情况下启动故障转移。
- 性能优化：持续监控不同CSP应用程序的性能，利用负载平衡来确保最佳资源管理。
- 成本管理：实施FinOps实践，以管理和优化与多云部署相关的成本。使用成本管理工具来监控不同CSP的支出，并就资源分配效率做出明智的决定。
本文作者：爱德华·科斯特
原创译介：Alan Huang
在此声明以上观点和内容，仅代表原作者和出处，与数治网DTZed 无关，如有出错或侵害到相关合法权益，请通过电邮与我们联系：cs@dtzed.com。
在文末扫码关注官方微信公众号“idtzed”，发送“入”直通相关数治x行业共建群、AIGC+X 成长营，@老邪 每周免费领取法规、标准、图谱等工具包。
欢迎先注册，登录后即可下载检索公共数据等相关标准、白皮书及报告。更多高质量纯净资料下载，在文末扫码关注官方微信公众号“idtzed”，进入公众号菜单“治库”。
