读红蓝攻防：技术与策略04事件处置和事后活动

1. 事件处置

1.1. 在IR生命周期上下文中，事件处置包括检测和遏制阶段
1.2. 为了检测到威胁，你的检测系统必须了解攻击介质，而且由于威胁环境变化如此之快，检测系统必须能够动态了解更多有关新威胁和新行为的信息，并在遇到可疑活动时触发告警
1.3. 一旦发现可疑活动，终端用户在识别和报告问题方面将扮演重要角色

• 1.3.1. 终端用户还应该了解不同类型的攻击，并学习如何手动创建事件通知单来处理此类行为，这应该是安全意识培训的一部分
  

1.4. 即使用户通过勤奋工作密切监视可疑活动，并且配置了传感器，以便在检测到破坏企图时发送告警，IR过程中最具挑战性的部分仍然是准确地检测出真正的安全事件

• 1.4.1. 需要从不同来源手动地收集信息，以查看收到的告警是否真的反映了有人试图利用系统中的漏洞进行攻击
  
• 1.4.2. 数据收集必须符合公司的策略
  
• 1.4.3. 当需要将数据带到法庭时，你需要保证数据的完整性
  

1.5. 用于识别威胁参与者的攻击/操作的日志

• 1.5.1. 网络钓鱼电子邮件
  
  
  
  • 1.5.1.1. 端点保护和操作系统日志有助于确定IoC
    
  
  
• 1.5.2. 横向移动之后是提升权限
  
  
  
  • 1.5.2.1. 端点保护和操作系统日志有助于确定IoC
    
  
  
• 1.5.3. 未经授权的或恶意的进程可能会读取或修改数据
  
  
  
  • 1.5.3.1. 服务器日志和网络捕获有助于确定IoC
    
  
  
• 1.5.4. 数据外泄并提交给指挥控制(C2)
  
  
  
  • 1.5.4.1. 假设云和内部资源之间有防火墙，防火墙日志和网络捕获有助于确定 IoC
    
  
  

1.6. 检测正在成为公司最重要的安全控制之一，位于整个网络（内部和云端）的传感器在识别可疑活动和发出告警方面发挥重要作用
1.7. 网络安全的一个日益增长的趋势是利用安全情报和高级分析来更快地检测威胁并减少误报

• 1.7.1. 可以节省时间，提高整体精度
  

1.8. 理想情况下，监控系统将与传感器集成，使你可以在单个面板上可视化显示所有事件

• 1.8.1. 如果你使用的是不允许彼此交互的不同平台，情况可能并非如此
  

1.9. 一旦检测到事件并确认为真，你就需要收集更多数据或分析已有的数据

• 1.9.1. 如果这是一个持续存在的问题，此时攻击正在发生，你需要从攻击中获取实时数据，并迅速提供补救措施来阻止攻击
  
• 1.9.2. 检测和分析有时几乎是并行进行的，以节省时间，然后利用这段时间快速响应
  

1.10. 当你没有足够的证据证明发生了安全事件时，最大的问题就出现了，你需要不断捕获数据以验证其准确性
1.11. 如果不知道什么是正常的，你就无法确定什么是不正常的

• 1.11.1. 如果用户启动一个新事件，说服务器性能很慢，你必须知道所有变量，然后才能得出结论
  
• 1.11.2. 要知道服务器是否很慢，你必须首先知道什么是正常速度
  
• 1.11.3. 这也适用于网络、电器和其他设备
  
• 1.11.4. 系统配置文件
  
• 1.11.5. 网络配置文件/基线
  
• 1.11.6. 日志留存策略
  
• 1.11.7. 所有系统的时钟同步
  

2. 事件处置清单

2.1. 让每个人有一个简单的清单来保持一致
2.2. 建立自己的清单的建议

• 2.2.1. 确定事件是否实际发生，并开始调查
  
  
  
  • 2.2.1.1. 分析数据和潜在指示器（IoA和IoC）​
    
  • 2.2.1.2. 审查与其他数据源的潜在相关性
    
  • 2.2.1.3. 一旦你确定事件已经发生，请记录调查结果，并根据事件的严重程度确定事件处理的优先顺序
    
  • 2.2.1.4. 考虑影响和可恢复性工作
    
  • 2.2.1.5. 向适当的渠道报告事件
    
  
  
• 2.2.2. 确保你已经收集并保存证据
  
• 2.2.3. 执行事件遏制
  
  
  
  • 2.2.3.1. 隔离受感染的资源
    
  • 2.2.3.2. 重置受损凭据的密码
    
  
  
• 2.2.4. 消除事件
  
  
  
  • 2.2.4.1. 确保所有被利用的漏洞都得到缓解
    
  • 2.2.4.2. 从备份还原文件从受损系统中删除任何恶意软件，并评估该系统的可信度
    

    2.2.4.2.1. 在某些情况下，有必要完全重新格式化系统，因为你可能无法再信任该系统
    

    
    
  
  
• 2.2.5. 从事件中恢复
  
  
  
  • 2.2.5.1. 从备份中还原文件
    
  • 2.2.5.2. 确保所有受影响的系统再次完全正常运行
    
  
  
• 2.2.6. 进行事后分析
  
  
  
  • 2.2.6.1. 创建一份包含所有经验教训的跟进报告
    
  • 2.2.6.2. 确保你正在采取基于这些经验教训的行动来增强你的安全态势
    
  
  
• 2.2.7. 该列表已为你自己的事件响应需求提供了坚实的基础
  

3. 事后活动

3.1. 事件优先级可能决定了遏制策略
3.2. 记录所吸取的教训

• 3.2.1. 在事后活动阶段拥有的最有价值的信息之一是所学到的经验教训，这将帮助你通过发现流程中的差距和需要改进的领域来不断完善流程
  
• 3.2.2. 记录文档必须非常详细地说明事件的完整时间表、为解决问题采取的步骤、每个步骤中发生了什么，以及问题的最终解决方式
  
  
  
  • 3.2.2.1. 谁发现了安全问题，用户还是检测系统？
    
  • 3.2.2.2. 事件是否以正确的优先顺序开始？
    
  • 3.2.2.3. 安全运营小组是否正确执行了初步评估？
    
  • 3.2.2.4. 数据分析是否正确？
    
  • 3.2.2.5. 遏制措施做得对吗？
    
  • 3.2.2.6. 解决这一事件花了多长时间？
    
  
  
• 3.2.3. 创建一个可用于未来事件的知识库
  

3.3. 证据留存

• 3.3.1. 在事件期间捕获的所有证据都应该根据公司的保留策略进行存储，除非有关于证据留存的具体指南
  
• 3.3.2. 如果需要起诉攻击者，证据必须完好无损，直到法律诉讼彻底解决为止
  

3.4. 只是简单的点击操作就可能导致危害，社会工程学手段仍然是主要因素之一，因为它利用人类因素来诱使用户做一些事情

• 3.4.1. 提高所有用户的安全意识培训，以覆盖此类场景
  
• 3.4.2. 降低用户在自己工作站上的权限级别
  
• 3.4.3. 实施AppLocker来阻止不需要的应用程序
  
• 3.4.4. 在所有端点实施EDR，以确保在初始阶段捕获这类攻击
  
• 3.4.5. 实施基于主机的防火墙来阻止对可疑外部地址的访问
  

3.5. 永远不要错过学习和改进IR计划的机会
4. 云中IR的注意事项

4.1. 当我们谈论云计算时，指的是云提供商和承包服务的公司之间的共同责任

• 4.1.1. 责任等级将根据服务模型的不同而有所不同
  

4.2. 对于软件即服务(Software as a Service，SaaS)，大部分责任在云提供商身上，事实上，客户的责任基本上是保护其内部的基础设施（包括访问云资源的终端）​

• 4.2.1. 对于SaaS模型，与事件响应相关的绝大多数信息都掌握在云提供商手中
  
• 4.2.2. 如果在SaaS服务中发现可疑活动，你应该直接联系云提供商，或通过门户启动事件
  

4.3. 对于基础架构即服务(Infrastructure as a Service，IaaS)，大部分责任在于客户，包括漏洞和补丁管理

• 4.3.1. 在IaaS环境中，你可以完全控制虚拟机，并且可以完全访问操作系统提供的所有日志
  
• 4.3.2. 此模型中唯一缺少的信息是底层网络基础设施和虚拟机管理程序日志
  

4.4. 理想情况下，你应该有一个涵盖主要场景（内部部署和云环境）的单一事件响应流程

• 4.4.1. 意味着你需要更新当前流程，以包括涉及云的所有相关信息
  
• 4.4.2. 检测：根据正在使用的云模型，你希望包括云提供商检测解决方案，以便在调查过程中为你提供帮助
  
• 4.4.3. 遏制：重新审视云提供商的能力，以便在事件发生时将其隔离，这也会因你使用的云模型而有所不同
  

4.5. 云上IR的另一个重要方面是拥有适当的工具集

• 4.5.1. 对于云计算，过去使用的许多与安全相关的工具在收集数据和检测威胁方面效率不高
  
• 4.5.2. 在规划IR时，你必须修订当前的工具集，并确定对于云工作负载的潜在差距
  

4.6. 云解决方案提供商(Cloud Solution Provider，CSP)和客户之间的交接必须非常同步，这应该在云采用的规划阶段解决

• 4.6.1. 如果这种交接与CSP协调得很好，并且确保在你自己的IR和CSP的IR中都考虑到了基于云的事件，那么当这些事件发生时，你应该能够更好地做好准备
  

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