读红蓝攻防：技能与策略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中都思量到了基于云的变乱，那么当这些变乱发生时，你应该可以或许更好地做好预备
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。