读红蓝攻防：技术与策略28事件调查与灾难恢复

1. 确定问题范围

1.1. 两种场景

• 1.1.1. 在组织内部
  
• 1.1.2. 在混合环境中
  

1.2. 并非每个事件都是与安全相关的事件

• 1.2.1. 有些症状可能会导致你最初认为正在处理与安全相关的问题，但随着更多问题的提出及更多数据的收集，你可能会逐渐意识到该问题并非与安全真正相关
  

1.3. 在开始调查之前确定问题的范围至关重要

• 1.3.1. 案例的初步分类对调查能否成功起着重要作用
  
• 1.3.2. 在初始分类期间，确定问题的频率也很重要
  

1.4. IT、运营和安全必须完全协调一致，以避免派发误报任务，从而导致利用安全资源执行基于支持的任务
1.5. 如果问题当前没有发生，你可能需要配置环境以便在用户能够重现问题时收集数据
1.6. 确保记录所有步骤，并为最终用户提供准确的行动计划
1.7. 关键工件

• 1.7.1. 更多的数据并不一定意味着更好的调查，主要是因为你仍然需要在某些情况下执行数据关联，同时过多的数据可能会导致调查偏离问题的根本原因
  
• 1.7.2. 当为设备分布在世界各地的全球性组织处理调查任务时，确保了解要调查系统的所在时区非常重要
  
  
  
  • 1.7.2.1. 对于员工在办公室外工作时使用的设备（如笔记本电脑和平板电脑）来说，这一点更为重要
    
  
  
• 1.7.3. 当恶意程序出现在其中时，它还会创建服务
  
  
  
  • 1.7.3.1. 查看注册表项HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services也很重要
    
  • 1.7.3.2. 运行msinfo32实用程序
    
  
  

1.8. 在处理实时调查时，还要确保使用Wireshark收集网络痕迹，如有必要，请使用Sysinterals中的ProcDump工具创建受害进程的转储
1.9. 调查受损系统的过程可能因系统运行位置的不同而有所不同
2. 调查内部失陷系统

2.1. 使用VirusTotal在线验证
2.2. Mimikatz

• 2.2.1. 被广泛用于凭据盗窃攻击
  

2.3. 使用PsExec工具来启动具有提升（系统）权限的命令提示符(cmd.exe)
2.4. ProcDump工具通常被攻击者用来转储lsass.exe进程中的凭据
3. 调查混合云中的失陷系统

3.1. PowerShell base64编码的字符串

• 3.1.1. MITRE ATT&CK T1059.001记录的技术
  

3.2. 在默认路径之外执行了SVCHOST的新实例

• 3.2.1. 威胁行为者使用这种技术来逃避检测
  
• 3.2.2. 威胁者已经对计算机进行了一些本地侦察，禁用了Windows防火墙，并创建了一个新的进程
  

3.3. 使用Windows中的注册表命令以建立持久性
3.4. 可以利用Windows中的reg工具来修改注册表，查询注册表，并在注册表中搜索不安全的凭据
3.5. 集成Microsoft Defender for Cloud与SIEM以进行调查

• 3.5.1. Microsoft Defender for Cloud提供的数据非常丰富，但它没有考虑其他数据源，例如防火墙等内部设备
  
  
  
  • 3.5.1.1. 这是需要将威胁检测云解决方案集成到内部SIEM的关键原因之一
    
  
  

3.6. 如果正在使用Splunk作为SIEM，并且想要开始从Microsoft Defender for Cloud获取数据，为Splunk提供的Microsoft Graph Security API附加组件
4. 主动调查（威胁猎杀）

4.1. 许多组织已经在通过威胁猎杀进行主动威胁检测
4.2. 主要目标是（甚至在系统触发潜在告警之前）识别攻击指示器(Indications of Attack，IoA)和攻陷指示器(Indications of Compromise，IoC)

• 4.2.1. 使组织能够积极主动地走在前面
  
• 4.2.2. 威胁猎人(threat hunter)通常会利用SIEM平台中的数据来查询失陷的证据
  

4.3. 每个查询都是为一组特定的数据源定制的，并映射到MITRE ATT&CK框架
5. 经验教训

5.1. 每次事件接近尾声时，你不仅应该记录在调查期间完成的每个步骤，还应该确保确定了需要检查的调查的关键方面，如果它们工作得不是很好，则需要改进或修复
5.2. 吸取的经验教训对于流程的持续改进和避免再次犯同样的错误至关重要
5.3. 针对用户凭据的攻击是一个日益严重的威胁，并且解决方案不是基于银弹产品

• 5.3.1. 它是任务的聚合
  
• 5.3.2. 减少管理级别账户的数量并取消本地计算机中的管理账户
  
  
  
  • 5.3.2.1. 普通用户不应该作为自己工作站的管理员
    
  
  
• 5.3.3. 尽可能多地使用多因素身份验证
  
• 5.3.4. 调整安全策略以限制登录权限
  
• 5.3.5. 计划定期重置Kerberos TGT(KRBTGT)账户
  
  
  
  • 5.3.5.1. 此账户用于执行黄金票据攻击
    
  
  

5.4. 蓝队应该创建一份全面的报告，记录所学到的经验教训以及如何利用这些经验教训来改进防御控制
6. 恢复过程

6.1. 一个组织不能完全依赖于它可以保护自己免受其面临的每一次攻击和所有风险的假设

• 6.1.1. 组织面临着广泛的潜在灾难，因此不可能针对所有灾难都采取完善的保护措施
  
• 6.1.2. IT基础设施灾难的成因可以是自然的，也可以是人为的
  

6.2. 自然灾害是由环境危害或自然行为引起的灾害，包括暴风雪、火灾、飓风、火山喷发、地震、洪水、雷击，甚至还有从天而降的小行星撞击地面
6.3. 人为灾难是指由人类用户或外部人类行为者的行为引起的灾难，包括火灾、网络战、核爆炸、黑客攻击、电涌和事故等
6.4. 当一个组织遭受这些打击时，其应对灾难的准备程度将决定该组织的生存能力和恢复速度
7. 灾难恢复计划

7.1. 灾难恢复计划(Disaster Recovery Plan，DRP)是一套记录在案的流程和程序，用于在灾难事件发生时恢复IT基础设施
7.2. 由于对IT的依赖，组织必须拥有全面且良好制定的灾难恢复计划

• 7.2.1. 组织不可能避免所有的灾难，因此所能做的最好的事情就是提前计划当灾难不可避免地发生时将如何恢复
  

7.3. 目标是在IT运营部分或全部停止时，对威胁到业务运营连续性的即时或特定紧急情况做出反应
7.4. 好处

• 7.4.1. 组织有安全感
  
  
  
  • 7.4.1.1. 恢复计划确保了它在灾难面前继续发挥作用的能力
    
  
  
• 7.4.2. 组织减少了恢复过程中的延迟
  
  
  
  • 7.4.2.1. 如果没有完善的计划，灾难恢复过程很难以协调一致的方式完成，从而导致不必要的延迟
    
  
  
• 7.4.3. 备用系统的可靠性得以保证
  
  
  
  • 7.4.3.1. 灾难恢复计划的一部分是使用备用系统恢复业务运营
    
  • 7.4.3.2. 计划确保这些系统始终做好准备，随时准备在灾难期间接手
    
  
  
• 7.4.4. 为所有业务运营提供标准测试计划
  
• 7.4.5. 最大限度地减少灾难期间做出决定所需的时间
  
• 7.4.6. 减轻组织在灾难期间可能产生的法律责任
  

8. 灾难恢复计划流程

8.1. 强调了在确定面临的风险、要恢复的关键资源的优先顺序以及最合适的恢复策略方面需要做的工作，还讨论了系统保持在线时的现场恢复
8.2. 组建灾难恢复小组

• 8.2.1. 灾难恢复小组是受命协助组织执行所有灾难恢复操作的团队，该小组应该包罗万象，包括来自所有部门的成员和一些最高管理层的代表
  
• 8.2.2. 团队将是确定恢复计划范围的关键，这些恢复计划涉及他们在各自部门执行的业务
  
• 8.2.3. 小组还将监督计划的成功制定和实施
  
• 8.2.4. 激活是指灾难恢复计划中包含的操作被启动和执行
  
  
  
  • 8.2.4.1. 拥有一个明确的激活过程将使灾难恢复计划更具主动性
    
  • 8.2.4.2. 激活所有者可以是CISO、CIO或任何在灾难恢复计划中定义的角色
    
  
  

8.3. 执行风险评估

• 8.3.1. 灾难恢复小组应进行风险评估，并确定可能影响组织运营的自然和人为风险，尤其是与IT基础设施相关的风险
  
• 8.3.2. 所选的部门工作人员应分析其职能领域的所有潜在风险，并确定与这些风险相关的潜在后果
  
• 8.3.3. 灾难恢复小组还应通过列出敏感文件和服务器面临的威胁以及这些威胁可能产生的影响来评估它们的安全性
  

8.4. 确定流程和操作优先顺序

• 8.4.1. 灾难恢复计划中每个部门的代表确定其在发生灾难时必须优先考虑的关键需求
  
• 8.4.2. 大多数组织不会拥有足够的资源来应对灾害期间出现的所有需求
  
• 8.4.3. 在制定灾难恢复计划时，需要确定优先级的关键领域包括功能操作、信息流、使用的计算机系统的可访问性和可用性、敏感数据以及现有策略
  
• 8.4.4. 要确定最重要的优先级，小组需要确定每个部门在没有关键系统的情况下可以运行的最长时间
  
• 8.4.5. 关键系统被定义为支持组织中发生的不同操作所需的系统
  
• 8.4.6. 业务影响分析(Business Impact Analysis，BIA)
  
  
  
  • 8.4.6.1. 用于确定最大可容忍停机时间(Maximum Tolerable Downtime，MTD)，MTD用于计算恢复点目标(Recovery Point Objective，RPO)或RPO（最后一个可恢复的备份）和恢复时间目标（Recovery Time Objective，RTO，即灾难事件和恢复之间的时间）​
    
  
  
• 8.4.7. 确定优先顺序的常用方法是列出每个部门的关键需求，确定为满足这些需求需要进行的关键流程，然后确定基本流程和操作并对其进行排序
  
• 8.4.8. 优先级：必要、重要和非必要
  

8.5. 确定恢复策略

• 8.5.1. 需要制定恢复战略，以涵盖组织的所有方面，包括硬件、软件、数据库、通信通道、客户服务和最终用户系统
  
• 8.5.2. 可能会与第三方（如供应商）达成书面协议，以便在发生灾难时提供恢复替代方案，包括将本地存储和备份与云存储相结合，以减轻硬盘驱动器故障的影响
  
• 8.5.3. 组织应审查此类协议、其覆盖期限以及条款和条件
  

8.6. 收集数据

• 8.6.1. 为便于灾难恢复小组完成完整的灾难恢复流程，应收集并记录有关组织的信息
  
• 8.6.2. 在适用的情况下，企业还应该考虑可能伴随着这些数据的合规性要求
  

8.7. 创建灾难恢复计划

• 8.7.1. 如果执行正确，前面的步骤将为灾难恢复小组提供足够的信息，以制定全面而实用的完善灾难恢复计划
  
• 8.7.2. 响应程序应以通俗易懂的方式进行全面解释，它应该有一个循序渐进的布局，并涵盖响应小组和其他用户在灾难来袭时需要做的所有事情
  
• 8.7.3. 计划还应规定自己的审查和更新程序
  

8.8. 测试计划

• 8.8.1. 计划的适用性和可靠性永远不应听天由命，因为它可能决定一个组织在重大灾难发生后的连续性
  
• 8.8.2. 应该对其进行彻底测试，以确定其可能包含的任何挑战或错误
  
• 8.8.3. 测试将为灾难恢复小组和用户提供执行必要检查并充分了解响应计划的平台
  
  
  
  • 8.8.3.1. 可以进行的一些测试包括模拟、检查表测试、完全中断测试和并行测试
    
  
  
• 8.8.4. 必须证明整个组织所依赖的灾难恢复计划对最终用户和灾难恢复小组都是实用且有效的
  
• 8.8.5. 不仅测试是重要的，而且根据所处理的数据，它也可能是一个监管要求
  

8.9. 获得批准

• 8.9.1. 计划经测试确定可靠、实用、全面以后，报最高管理层批准
  
• 8.9.2. 最高管理层必须批准恢复计划
  
  
  
  • 8.9.2.1. 保证计划与组织的政策、程序和其他应急计划一致
    

    8.9.2.1.1. 一个组织可能有多个业务应急计划，这些计划都应该精简
    

    
    
  • 8.9.2.2. 计划可以安排在年度审查的时间段内
    

    8.9.2.2.1. 最高管理层将对计划进行自己的评估以确定其充分性
    

    8.9.2.2.2. 整个组织都有足够的恢复计划
    

    8.9.2.2.3. 最高管理层还必须评估计划与组织目标的兼容性
    

    
    
  
  

8.10. 维护计划

• 8.10.1. IT威胁环境可能会在很短的时间内发生很大变化
  
• 8.10.2. 一个好的灾难恢复计划必须经常更新
  
• 8.10.3. 灾难恢复计划应该根据需要而不是严格的时间表进行更新
  
• 8.10.4. 灾难恢复过程的最后一步应该是建立更新时间表，该时间表还应规定在需要时进行更新
  

9. 挑战

9.1. 缺乏最高管理层的批准

• 9.1.1. 灾难恢复计划被认为仅仅是对可能永远不会发生的假事件的演练
  
• 9.1.2. 最高管理层可能不会优先制定这样的计划，也可能不会批准似乎有点昂贵的雄心勃勃的计划
  

9.2. 灾难恢复小组提出的恢复时间目标(Recovery Time Objective，RTO)不完整

• 9.2.1. RTO是组织可接受的最长停机时间的关键决定因素，最大可容忍的停机时间(Maximum Tolerable Downtime，MTD)用于确定RTO
  

9.3. IT基础设施在尝试应对其面临的威胁时会动态变化

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！