深入MSRC:SSIRP事件响应全解析

本文详细介绍了微软安全响应中心(MSRC)的软件与服务事件响应计划(SSIRP)流程,涵盖从监控、分类、评估到工程开发和事后审查的五个关键阶段,包括实际案例分析和跨团队协作机制。

深入MSRC:SSIRP事件响应全解析

这是系列博客的第二篇,分享微软安全响应中心(MSRC)如何通过软件与服务事件响应计划(SSIRP)应对客户面临的高级别威胁。

上一篇博客中,我们回顾了MSRC和SSIRP的历史,以及微软如何以整体视角帮助保护和防御客户。下面,我们将分享SSIRP团队如何协调跨公司响应潜在安全威胁,以确保客户受到保护。

SSIRP是我们响应客户重大威胁的事件响应流程,包括野外利用攻击客户的漏洞(“零日”)、威胁微软服务(如Azure和O365)安全的威胁,以及可能用于攻击客户的未修补漏洞的公开披露。在此响应过程中,公司许多团队被动员起来,包括网络防御运营中心(CDOC)响应团队、企业安全响应、产品和服务安全团队,以及关键安全技术团队如Windows Defender。这些安全专家每天作为快速响应者处理对我们产品、服务以及内部网络的各种威胁。虽然每个团队都是其产品或服务的专家,但通过SSIRP流程和CDOC,他们加入跨公司协调努力,以保护客户免受严重安全威胁。

SSIRP事件剖析

几乎每个产品或服务SSIRP事件都有五个阶段,如下所示。

监控

微软持续监控新兴事件,内部和外部合作伙伴是关键参与者,对微软生态系统的各个部分有具体见解。与MSRC一起,“监控合作伙伴” vigilantly 监视其责任区域的新兴威胁迹象。

分类

当发现问题时,我们的团队会对其进行分类,如果对客户有高风险,则宣布SSIRP。这集中额外资源以确保及时的变体分析、缓解、服务更新和向客户发布更新。每个SSIRP被分配一个严重性级别,衡量对客户的潜在风险。严重性旨在作为一个动态评级,随着情况发展而变化,并驱动响应级别。

例如,今年早些时候,我们被告知一个名为runc的开源软件(OSS)容器运行时中的漏洞,影响了所有使用此组件的Linux系统。该漏洞是一个权限提升(EoP),可能允许攻击者在容器中已有恶意代码执行的情况下获得根级代码执行。虽然底层漏洞不在我们的产品或服务中,但我们认为它对客户构成重大威胁,并宣布了“严重性级别2”SSIRP,以动员资源进行跨公司响应。

评估

宣布事件后,团队努力评估问题的范围,并确认记录计划以尽快保护客户。这项工作包括工程、通信、客户服务和支持以及其他防御者的代表。除了确定问题范围外,团队还努力确保客户在更新发布前了解任何缓解措施。在评估阶段,通过我们的MAPP程序与行业进行协调和合作,以及在Spectre和Meltdown类漏洞的情况下与其他主要技术公司合作。评估是一个时间关键的功能,几乎没有犯错的空间。我们的座右铭是“知道 – 不要猜测”。

工程/开发

建立记录计划后,重点转向工程,并确保有足够的资源动员以尽快保护客户。在某些情况下,工程将发布工程变通办法或向Microsoft Defender添加保护,以及通信如安全公告、博客文章和向Microsoft Active Protections Program(MAPP)合作伙伴的提醒,同时开发完整修复。

微软对影响计算机芯片的_Meltdown_和Spectre漏洞的响应在内部被称为SSIRP Poncherello,以电视节目“CHiPS”的主角命名。

同时,团队致力于最终目标:广泛分发任何安全更新、修复任何受影响的服务,以及当客户需要采取特定行动保护自己时的客户指导(安全更新指南公告、博客、现场警报)。服务更新在测试后立即推送到生产环境。产品安全更新通常作为我们常规更新星期二(Update Tuesday)计划的一部分发布,同时披露已修复的漏洞,为行业提供见解和学习。每月更新星期二的可预测性允许客户及时安排系统更新,同时减少任何停机的经济成本。在极少数高风险情况下,我们可能确定需要立即、“带外”更新,例如我们在WannaCry爆发期间发布的更新。

在_runc_漏洞SSIRP期间,团队调查了所有微软服务以确定哪些(如果有)受到影响。在此调查中,Azure Moby和Azure Kubernetes服务被识别为使用runc,但由于它们使用了该组件的静态链接版本(不易受攻击),因此未受影响。即便如此,两项服务都更新了代码以包含代码维护者提供的补丁,并将更改推送到生产环境。当代码维护者公开漏洞时,它被赋予“高”严重性评级(CVSS 3.0分数:8.6),并被分配唯一标识符CVE-2019-5736。

事后审查

在事后审查阶段 – 更新发布和服务更新后 – 危机负责人与监控合作伙伴确认事件已全面解决。危机响应团队解散,并举行事后审查以正式捕获任何经验教训并推动全公司改进。这对任何响应模型都至关重要,因为安全形势总是在变化 – 昨天有效的,可能不是明天事件的最佳选择。在runc_SSIRP的情况下,没有额外的经验教训可收集 – 该案例对于开源软件(OSS)事件是典型的,团队使用了一些最佳实践,我们将在下一篇博客中分享。我们还将提供一些建议,用于构建您自己的事件响应流程,借鉴超过二十年的安全事件响应经验。

Simon Pope,事件响应总监,微软安全响应中心(MSRC)

comments powered by Disqus
使用 Hugo 构建
主题 StackJimmy 设计