7月19日那场震惊全球的「史上最大规模IT故障」，影响还在继续……
25日，情况最为严重、持续时间也最长的航司——达美航空，终于完成了系统修复，恢复正常运营。期间，共有2500多个航班被迫取消。
27日，美国奥兰多警察局发布寻人启事称，一名83岁男子在因CrowdStrike宕机导致回家航班被取消后，已经失踪一周了。
根据分析和保险服务商Parametrix的计算，这次宕机事件给财富500强企业带来了高达54亿美元的损失。
而这种搞崩全球设备的操作，可以算是CrowdStrike家的传统艺能了。
首席执行官George Kurtz早在2010年的Windows XP时代，就曾在McAfee用一个更新搞崩了全球设备；跟CEO的作风类似的，CrowdStrike在过去的四个月里，差不多每30天就要搞垮一个操作系统！
终于，在7月27日，微软针对这次CrowdStrike导致的全球蓝屏事件，给出了一份官方的分析。
「Windows安全工具的集成与管理最佳实践」
而看完报告之后，网友纷纷开启了嘲讽模式：
「难道CrowdStrike的高层领导都睡着了？为什么连续几个月来每30天都会发生这么多事件？」
「微软已经在言辞上尽可能地保持委婉了，但这绝对是对CrowdStrike的一记耳光！」
CrowdStrike不知道如何展开工作，并且需要基本的质量保证（QA）实践指导，我们很乐意教他们……
接着，便列出了一堆在用户模式下运行的功能，告诉他们如何避免需要在内核模式下运行太多东西。
有人表示，自己在微软工作的朋友对此深表不满，每次有类似的宕机事件，微软都得背黑锅。
「接口之所以这样设计，是因为不在内核模式下进行，就很难在实时文件系统过滤中获得足够的性能。这是困扰很多操作系统的难题。」
实际上，微软允许第三方代码加载到自己的内核，跟其他的主要操作系统内核（Linux或Apple XNU之类）并没什么不同。
这次的问题主要是，CrowdStrike在内核模式下做了很多本可以在用户模式下完成的事情。
接下来，就让我们看看，微软官方对于宕机事件的详细分析。
CrowdStrike事件分析
在博客中，微软解释了为什么现在的安全产品，必须使用内核模式驱动程序。
为此，Windows也为第三方解决方案提供了安全措施。
报告中，CrowdStrike将原因归根为内存安全问题，特别是CSagent驱动程序中的越界读取访问违规
对于CrowdStrike给出的解释，微软利用Microsoft WinDBG内核调试器和任何人都可免费谁用的几个扩展，来执行了如下分析。
基于Microsoft对与该事件相关的Windows错误报告（WER）内核崩溃转储的分析，可以观察到反映这一点的全球崩溃模式：
如果深入分析这个崩溃转储，就可以恢复访问违规时的堆栈帧，从而了解更多起因了。
然而不幸的是，由于使用WER数据时，微软只能接收到压缩状态，因此就无法反向反汇编，查看崩溃前的更多指令了。
不过，在反汇编中可以看到，在读取R8寄存器中指定的地址之前，有一个NULL检查：
观察以上结果，就可以证实CrowdStrike的分析是正确的——
在CrowdStrike开发的CSagent.sys驱动程序中，存在越界读取内存安全错误。
另外，微软还发现，csagent.sys模块被注册为文件系统过滤驱动程序——通常被反恶意软件用来接收与文件操作有关的通知。
安全软件会用它来扫描保存到磁盘的任何新文件，比如通过浏览器下载的文件。
而且，文件系统过滤器还可以作为监控系统行为的安全解决方案的信号。
正如CrowdStrike在博客中指出，他们内容更新的一部分，就是更改传感器逻辑，以处理与命名管道创建相关的数据。
而文件系统过滤驱动程序API，允许驱动程序在系统上发生命名管道活动时接收调用，从而能够检测恶意行为。
这种驱动程序的一般功能，是与CrowdStrike分享的信息相关联的。
可以看到，在CrowdStrike分析中指定的控制通道文件版本291也出现在了崩溃中，这表明文件已被读取。
如何确定文件本身与崩溃转储中观察到的访问违规相关联呢？这就需要使用这些工具对驱动程序进行额外的调试了。（这次咱不讨论）
我们可以做的，是通过崩溃转储，来确定在崩溃发生时，运行的系统上是否存在其他由CrowdStrike提供的驱动程序。
从上述分析中可见，CrowdStrike加载了四个驱动程序模块。
其中一个模块根据CrowdStrike的初步事件后审查时间线，会频繁接收动态控制和内容更新。
利用此次崩溃的独特堆栈和属性，便可以识别出由CrowdStrike特定编程错误导致的Windows崩溃报告。
图1 CrowdStrike驱动程序相关的崩溃转储报告随时间的变化（仅包括选择上传的用户）
总之，这次全球宕机事件告诉我们：任何无效内存访问之类的可靠性问题，如果没有结合安全部署实践，都会导致严重的后果。
所以，为什么安全解决方案必须在Windows上使用内核驱动程序呢？
对此，微软给出了以下解释。
为什么安全解决方案，必须依赖内核驱动程序
首先最重要的一点原因，就是内核驱动程序允许系统范围的可见性。
而且，它能在早起启动时运行，这样就能检测出像启动工具包和根工具包这样的威胁（要知道，后者可是在用户模式应用程序加载前，就可以运行的）。
微软为内核驱动程序提供了一套丰富的功能，包括用于进程和线程创建的系统事件回调，以及可以监控文件创建、删除或修改的过滤驱动程序。
而且，内核活动还可以触发回调，让驱动程序决定何时阻止文件或创建进程。
因此，许多供应商都是用NDIS驱动，在内核中使用驱动程序来收集各种网络信息。
性能
内核驱动程序，还会带来潜在的性能优势。
比如，它可以帮助进行高吞吐量的网络活动分析或数据收集。
当然，有许多场景可以在非内核模式下优化数据收集和分析操作，微软也会继续与生态系统合作。
防篡改能力
加载到内核模式的另一个好处，就是防篡改能力。
即使攻击者具有管理员权限，安全产品也不希望软件被恶意软件、针对性攻击或恶意的内部人员击溃。
另一个要求，就是让驱动程序尽早加载，以便尽早观察到系统事件。
为此，微软提供了一种机制，可以在启动过程的早期，启动标记为早期启动反恶意软件（ELAM）的驱动程序。
内核驱动程序提供了以上好处，但是是以弹性为代价的。
因此，安全供应商在使用内核驱动程序时，就必须仔细权衡利弊，平衡可见性和防篡改需求，与在内核模式下操作的风险。
微软表示，如今安全工具已经可以在安全性和可靠性之间实现平衡。
例如，安全供应商可以使用在内核模式下运行的最小传感器进行数据收集和执行，以限制暴露于可用性问题的风险。
其余的关键产品功能则在用户模式下隔离进行，然后再恢复。
图2 平衡安全性和可靠性的示例安全产品架构
而对于用户模型保护方法，Windows也同样提供了几种防篡改的方法，比如基于虚拟化的安全（VBS）隔离区和受保护进程，以及ETW事件和用户模式接口，如反恶意软件扫描接口。
如何在更高安全模式下进行部署
微软表示，Windows本质上是一个开放、多功能的操作系统，可以通过集成工具轻松锁定，以提高安全性。
此外，Windows也在不断增加安全默认值，包括在Windows 11中默认启用的数十个新的安全功能。
在Windows的自我防御方面，默认启用的关键反恶意软件功能包括：
安全启动（Secure Boot）：通过在系统启动过程中强制执行签名一致性，防止早期启动恶意软件和rootkit
测量启动（Measured Boot）：通过集成的证明服务（如设备健康证明）提供基于TPM的硬件加密测量，以检测启动时的属性。
内存完整性（Memory integrity，也称HVCI）：防止在内核中运行时生成动态代码，确保控制流完整性
易受攻击驱动程序阻止列表：集成在操作系统中并由微软管理，与恶意驱动程序黑名单相辅相成
受保护的本地安全机构（Protected Local Security Authority）：负责保护一系列凭据，企业版默认开启基于硬件的凭据保护
Microsoft Defender Antivirus：在整个操作系统中提供反恶意软件保护
利用Windows集成的安全功能来防止攻击，可以提高安全性，同时减少成本和复杂性。可参考的最佳实践如下：
通过App Control for Business来编写一个安全策略，只允许受信任和/或业务关键的应用程序
结合内存完整性（Memory integrity）与特定的允许列表策略，利用基于虚拟化的安全性（VBS）进一步保护Windows内核
以标准用户身份运行，并仅在必要时提升权限
使用设备健康证明（Device Health Attestation, DHA）监控设备的正确安全策略，包括硬件基础的机器安全姿态测量
为反恶意软件生态提供最佳实践
最后，微软计划利用新推出的数十种安全功能和架构改进，来帮助反恶意软件完成方法的现代化，从而提升安全性和可靠性：
提供安全部署指南、最佳实践和技术，使执行安全产品更新更安全
减少内核驱动程序访问重要安全数据的需求
提供增强的隔离和防篡改能力，如VBS enclaves技术
启用零信任方法，如高完整性证明
微软表示，Windows今后将继续创新并提供新的方法，使安全工具能够安全地检测和响应新兴威胁。
还没有评论，来说两句吧...