微软安全运营架构解读

微软安全安全架构解读-安全运营篇

微软在其网络安全架构中对安全运营部分基于自身实践提出了安全运营架构，微软认为安全运营的主要挑战是安全运营工具的竖井，需要通过工具和数据进行集成，并提出了微软的安全运营架构和安全运行模型。

竖井是安全运营的挑战

安全运营在尝试跨系统跟踪攻击者时，经常面临内部的诸多障碍，由于企业IT产业复杂和资源类型繁多，安全工具的孤岛化，放大了这种复杂性。因为攻击者通常遵循生产用户在企业中访问资源的路径来完成攻击任务，攻击者则不会受到这种复杂性的影响，而防御者通常受限于孤立的工具，且缺乏对企业整个环境的可视性，很难迅速跟踪这些攻击者。

虽然安全运营使用不同工具执行分析工作，来加强团队之间的协作，但因为工具在设计时并没有考虑作为单个系统运行，通常整合这些孤岛难度很大，主要的挑战包括不同工具以不同类型的竖井和对象（如端点、电子邮件）为中心，不同对象使用的格式和标识符也不同，同的工具有通常有不同的偏差，使得它们之间的数据难以集成。

工具和数据的集成

微软做了大量的安全运营的集成工作，将自身的工具集本地化集成到产品工程中来优化分析师使用体验。

• 从功能较强的云扩展检测工具开始，提供 API 接口供集成的工具之间互相通信，确保数据集成符合安全和隐私法规以及客户合同。

• 统一实体的信誉数据，为端点、IP 地址、电子邮件等物品及其各种属性启用统一的语言定义，统一每个工具的信誉数据

• 统一语义和意义，确保各种术语的使用保持一致

• 自动化保护和补救行动 ，确保自动化运行于所有的系统

• 单一门户体验，整合成单一的Microsoft 365 Defender门户

微软安全运营参考架构

安全运营以人为中心

微软认为安全运营是技术性的领域，首先是以人为中心，需要技术进行赋能，这些现代安全运营技术能帮助扩展人类的技能和经验，尤其在多云及混合的环境下面对高级的安全攻击。

微软提供了三类顾问或外包专家协助：

• 微软威胁专家，内置于 Microsoft 365 Defender 中的托管威狩猎服务，为安全操作中心 （SOC） 提供专家级别的监控和分析，帮助确保您特环境中的关键威胁不会错过。
• 微软事件响应和恢复服务，微软的检测和响应团队 （DART）和客户支持为事件响应、恢复和搜索（现场和远程）提供帮助。
• 合作伙伴 / 托管检测和响应，Microsoft 与业内顶级专家合作，建立这些 Microsoft 安全运营能力的专业知识，以便合作伙伴能够为客户提供建议并直接支持客户。

XDR作为基础的安全运营工具

• XDR工具能极大提高安全运营效率
  微软认为XDR扩展检测和响应工具的引入，能给安全运营工作的效率和效果带来了极大的提升，XDR工具一方面提供了针对特定资产类型的深度可视化，也提供了增强的检测、响应和恢复能力，能为SIEM提供高质量的警报，降低误报率。使安全分析师可以关注真实的风险调查中，减少检查误报和维护查询的时间。

• 安全自动化（SOAR）和集成
  加强安全运营能力的另一个关键要素是采用安全编排、自动化和修复（SOAR）技术将工具集成在一起。以减少分析师的人工活动和不必要的控制台切换，使用机器响应提高响应时间和速度；可扩展安全运营的规模，以适应不断增长的攻击量和企业多云/混合环境的复杂性。微软提供了以下工具集成实现安全自动化：

• Azure Sentinel和SIEM的现代化

  Azure Sentinel是一种基于云的SIEM，通过横跨XDR工具和任意的日志/数据源获得完整的可视性。除了传统的静态分析功能，还集成了 SOAR、ML、UEBA、威胁情报和安全数据湖的方法，以改进威胁检测、调查和威胁狩猎流程。Azure Sentinel还利用 Azure 数据资源管理器以更低的成本存档大量数据。

安全运营重要指标

通常严重的网络攻击与攻击人员的攻击接近实时发生，所以，安全运营的成功指标应重点关注攻击者在环境中的驻留时间上，主要从3个指标衡量：

• 衡量响应效率的平均响应时间-MTTA，度量人员在接收到告警后，花费多久响应并开始检测。

• 衡量效果的平均修复时间MTTR，度量一个安全事件从分析到移除花费了多久。

• 告警的质量，度量警报的质量能确保分析师不浪费在误报的警报上，因此组织还应进行积极的威胁狩猎，用高级分析师搜索低质量的警报，以主动搜寻未被检测到的攻击威胁。

安全运营模型

微软也提出了安全运营分层处理的模型，阐述不同层级组织、工具、工作内容的主要差异，据此可构建合理的安全运营流程。

微软认为有效的安全运营专注于管理环境中主动攻击者的风险，运营活动主要分为三类：反应式的事件活动（称为"热门"路径） 、主动狩猎和告警调整活动（称为"冷"路径）、关键的支持功能。每个安全运营活动由多个不同的职能组成，每个职能/团队都有一个主要的重点领域，并且还必须与其他功能和外部团队密切合作才能有效。上图的模型描绘了配备人员齐全的团队的完整模型，但在较小的组织中，这些功能通常被合并为单个角色或团队，或由 IT 运营（用于技术角色）执行。

• 自动化处理

  从处理反应性警报开始 ，通过自动化对已知攻击事件类型进行近实时解决，这些攻击是组织多次看到的明确定义的攻击。

• 分类筛选（第1层）

  该团队属于一线分析人员，专注于快速修补大量已知事件类型，这些事件类型仍然需要分析人员进行快速的人工判断。通常的任务是审批批准自动修复工作流程，并识别需要升级或需要调查团队（2层）检查的异常情况。

• 调查和事件管理（第2层）

  该团队为分类筛选（第1层）问题的升级点，主要监控任务包括：触发更复杂的攻击者行为的警报、与关键业务资产相关的特殊案例警报，以及持续攻击活动的监控。

  该团队对更复杂、较低数量的攻击（通常是由人类攻击者进行的多阶段攻击）进行更深入的调查。该团队将新的/不熟悉的警报类型用于记录分类团队和自动化流程，通常包括 Azure Defender 在云托管应用程序、VM、容器和 Kubernetes、SQL 数据库等上生成的警报。该层事件管理团队负责管理安全事件的技术方面，包括与其他团队（如沟通、法律、领导和其他业务利益相关者）的协调。

• 狩猎和事件管理（第3层）

  这是一个多学科的团队，专注于识别可能在被动的检测中未发现的攻击者。狩猎团队主动寻找未发现的威胁，协助升级和高级取证进行反应性调查，并改进警报和自动化。这些团队的运行方式更多的是假设驱动的模型，而不是被动警报的模型。该层的事件管理团队主要处理影响业务的重大事件。

不同层级团队分工协同

• 分类筛选团队分析师（第1层）得到的如恶意软件警报等大多数案例都提供了快速修复的方法，但通过分析师具体分析后，可能需要高级的修复方式，升级到调查分析员（第2层），后者可能会利用Azure Sentinel或其他SIEM获得更广泛的深入调查，着手进行补救和结案。最后，狩猎分析师（第3层）可能会在审查已关闭的事件中注意到该案例，再进一步挖掘出共性或异常的情况，比如：检测可能适合于自动修复的、多个相似的事件可能有通常的根本原因、其他潜在的流程/工具和告警的改善等。

总结

结合以上安全运营的架构的分析，微软认为安全运营需要重要解决的是主动攻击者的风险，而目前的安全运营主要依靠采集数据到进行SIEM的分析是不够的，因为采集的数据缺少检测、缺少一致性的语言定义，也缺少在安全运营各资产相关安全保护的工具之间统一的术语，这就造成了安全工具的竖井，竖井的产生也造成了跨工具追踪攻击者的困难。XDR也正是为了解决这一问题而产生，微软统一了基本覆盖企业所有各类资产的XDR控制台，实现了数据的共享和集成，在通过安全自动化平台，以减轻安全运营的人工工作量，提高安全运营的效率和效果。

微软安全架构参考材料：aka.ms/MCRA