iThome制表
今年7月，一场大规模的IT故障事故影响全球，起因竟是资安业者CrowdStrike的EDR产品更新，导致全球850万台Windows电脑死当。
这起事件发生在台湾时间在7月19日（周五）的中午过后，虽然CrowdStrike事后号称他们在1小时后就修复问题，并在两个多小时后发布缓解方法，但这场电脑与伺服器大当机的风暴，在短短几个钟头之内，就已经蔓延全球。
究竟这次大当机事故是如何造成？有哪些重要议题需要探讨？例如，资安业者部署验证测试发生的问题，管理方便可能导致的风险集中，以及过度依赖单一平台与供应商的可能风险，还有数位韧性落差等，都成为大家关注的焦点。
由于整起事件在这段期间发生的状况太多，使得相关检讨的资讯与重要议题容易被忽略，不少新闻报导仅将焦点放在局部事件，为此我们归纳出5大议题，帮助大家快速检视需检讨的重要面向。
问题1：业者更新前为何未做好部署验证测试？
所有人质疑的第一个问题在于，资安业者为何在更新前没有做好部署验证测试？酿成这次大规模事故。
事隔6天之后（7月24日），对于更新出包致Windows电脑死当，CrowdStrike公布初步事后检讨（PIR）报告。
他们表示，这次事件的发生时间，是在世界协调时间（UTC）7月19日上午4点09分，也就是台湾时间同一天中午12点09分。
关于问题的发生原因，简单来说，主要出在派送「Rapid Response Content」的环节，加上这个缺陷在验证检查期间未被检测到，使得Falcon感应器在载入这些内容后，导致越界记忆体读取，进而引发Windows电脑当机。
相隔1小时18分后，虽然CrowdStrike撤回有问题的更新，促使后续才连线的系统可以不受影响。但是，先前更新的系统已经受到影响，灾情已经扩散。
具体而言，为了收集新型威胁技术的telemetry资料，CrowdStrike经常针对Windows感测器发布内容配置的更新。主要更新方式有两种，一种是随感测器同时发布，一种是名为「快速回应内容」（Rapid Response Content）发布，而这次问题是发生在后者。
CrowdStrike解释，一般而言，感测器更新都会先进行内部测试，再释放给早期使用者，最后才广泛提供给客户。
而快速回应内容的更新，是为了快速应对威胁而设计，其更新内容为IPC范本实例，用来告诉感测器要侦测哪些行为或攻击。它的更新内容派送流程，将会验证、确认更新内容无误，再透过Channel Files部署到端点，也就是会透过内容验证器检查IPC以确保其正确性。
CrowdStrike接著说明详细状况：他们今年2月引入新感测器功能，以监控可能滥用Windows机制的攻击技术。而这些IPC范本实例，后续已在测试环境中通过压力测试，并在测试的Production环境中表现正常，经历3次额外的Rapid Response Content更新部署。
只是，7月19日当天部署两个IPC范本实例后，有个IPC范本实例存在未被侦测到的错误，加上内容验证器有Bug，使得有问题的更新内容却通过验证。
综观上述事发说明，我们最好奇之处在于，为何Rapid Response Content的更新，只有进行压力测试？却不像Falcon感测器的更新，都会经过较严谨的部署更新测试？可惜，我们在CrowdStrike这份报告中，并未看到对应的解释，无法得知这么做的原因与考量。
是否因为公司要在产品安全功能上求快，导致没有在安全与快速之间拿捏好平衡，也成为大家质疑之处。或许，在骇客零时差漏洞利用入侵越来越泛滥的今日，迫使资安业者更想要早一步侦测入侵迹象，但这次事件显示轻忽最根本的安全考量，成为警惕。
因此，CrowdStrike于7月24日PIR报告中，提出4大改进面向，以防范事件再次发生。这应该就是他们对于这次事件所得到的教训。具体而言，包括：
（一）加强软体测试程序：当中提及将为内容验证器增加额外的验证检查，以及将改善快速回应内容的测试流程。
（二）提升系统韧性与恢复能力：将强化Falcon感测器中的错误处理机制。
（三）优化部署策略：将采分批部署策略，先进行小范围系统进行测试部署，再逐步扩大范围；并针对分批部署期间，强化感测器和系统性能的监控，也将提供更新通知，以及更大控制权，包含允许选择更新的部署时间与位置。
（四）实施第三方验证：将采取多次独立的第三方安全程式码审查；对于从开发到部署流程进行独立审查。
另一方面，在0719事故后，我们还注意到，有其他资安业者公布自家软体与内容更新的发布流程，以及整体发布策略。例如，7月23日有Fortinet，7月19日有Bitdefender。显然这次事件的发生，不仅是CrowdStrike被迫详细解释其更新流程、事前测试，协助企业用户可以了解状况，也促使资安业界可借此机会重新评估与改进，并促使一些业者对其用户公开自家作法，希望获取用户信任。
不过，若是换个角度思考，这些资安业者目前提出的作法够周延了吗？只有自家的监督与稽核，却没有外部验证，是否足以避免问题再次发生？以及企业分散风险的必要性，仍值得继续深思，这也将是我们接下来继续探讨的议题。
问题2：微软为何要开放作业系统核心模式驱动程式使用
这次Windows大当机是因为资安业者而起，加上有国外媒体报导微软提到2009年的欧盟协议，指出微软有义务将自家资安产品使用的API，开放给外部软体开发商。
这也让有些人将此事件的焦点，放在微软的开放生态体系，因为他们为何允许资安业者使用核心模式驱动程式（Kernel-Mode Driver）？以及微软对第三方解决方案是否有相应的安全措施？
对于这方面的问题，在7月27日，微软企业与作业系统安全副总David Weston在官方网站发表文章，针对这方面与Windows安全最佳实践提出说明。
David Weston谈到资安解决方案使用Windows核心模式驱动程式的好处，包括：可以获得系统层级的监控能力，侦测Bootkits与Rootkits，也可加快资料收集与分析，并提供防篡改能力。
以防篡改而言，资安产品的驱动程式为了能够尽早载入，以便在最早的时间点可以观察到系统事件，为此，Windows也提供ELAM驱动程式，这是个早期启动防恶意程式的机制，而CrowdStrike也有签署CSboot驱动程式来作为ELAM，能在系统启动过程载入。
接下来，David Weston也解释了核心模式驱动程式架构（KMDF），并指出所有在核心层级执行的程式码，都需要广泛的验证，因为不像一般用户端应用程式，故障后重新启动就能恢复。
至于要如何避免这样的问题？David Weston提到，资安产品可以在核心使用最小化情形下，减少可用性问题的风险，并维持充分的安全性与侦测能力，例如，尽量减少对于核心模式的依赖，像是微软已经致力于将复杂的Windows核心服务，从核心模式移到使用者模式，好处是，如果有问题发生，系统也容易恢复。
另外，他也指出多种Windows在使用者模式下，可防止窜改的方法。例如，微软近期发表名为Virtualization-based security（VBS）的记忆体保护区，就可以不用透过核心模式驱动程式来防篡改；还有去年底微软推出的Event Tracing for Windows（ETW）新功能，都是可以平衡系统的安全性与稳定性的方法。
另外，David Weston还解释微软如何测试、签署驱动程式，以及第三方厂商如何透过Windows Update等方式，将驱动程式发布给用户。
整体来看，微软传达的重点在于，他们已发展一些作法，可限缩这次更新出包的问题面，并持续发展中，也将与第三方厂商加强相关合作。不过，该公司没有很确切说明哪些策略会强制执行。
至于有人论及封闭生态系统、开放生态系统、开源生态系统，在当前环境的发展态势，这是多年来都在持续讨论的大议题。事实上，每一个生态都有对应之道，并且持续随著整体环境而演变。
尽管外界有一些人士认为，微软可能转向苹果的封闭生态路线，但Windows多年来都是朝向开放的路线，因此这只能等待时间去印证这个预测。
问题3：IT系统风险过于集中？
这次事件之所以带来大规模影响，与CrowdStrike、Windows用户数量有关。
基本上，微软Windows作业系统在全球个人电脑与伺服器的用户数，是数以亿计，而这次事故中的关键业者CrowdStrike，虽然仅有企业用户安装其EDR产品，但根据该公司最新财报显示，全球有多达24,000家企业是他们的客户，并且约有6成都是《财富》全球500强的企业。
这也不难看出，由于许多大型企业都采用CrowdStrike，使得这次事件影响规模如此显著。
对于企业组织而言，采用单一厂商的解决方案带来集中管理的好处，虽然不像采用多个厂商的解决方案，可能使攻击表面增加，但仰赖单一厂商，往往也导致风险集中，是否要将鸡蛋放在同个篮子的老问题，是此事件后的反思焦点；对于整体国家而言，也有人忧心一家业者市占太大而有风险集中问题，不过，有这方面考量的探讨似乎并不多，或是相关议题需要更广泛看待，也许之后还会有进一步讨论，尤其是监管单位是否会介入，他们的态度动见观瞻。
以企业组织而言，在我们后续追踪采访中，就有一家医疗单位的主管就指出，这次事件只影响到院内部分主机，因为这些主机是使用CrowdStrike的EDR产品，其余主机使用另一家厂商产品。但他们仍然学到一些经验，就是在双主机备援机制方面，也打算要采用不同厂商的防护服务。
问题4：企业应变能力低于预期，对于责任归属出现互踢皮球的状况
在0719事故发生后的复原上，有些企业很快完成，但有些企业受影响装置数量庞大，因此需要一定的时间。但更受全球关切的是，有些企业复原天数超乎预期，达美航空就是一例，这也成为企业引以为鉴的状况。
基本上，这次许多受影响的企业组织，大多数都在周五至周日恢复。以台湾为例，有医院受到的影响只有半小时至1小时，桃园机场在当日下午5点多宣布受影响的7家航空公司，之后陆续恢复报到画位服务；也有一些影响状况较严重，像是有资服业者花上3天时间复原。
国际间的状况也多是如此，例如，纽西兰KiwiBank在当地周五早上11点多，宣布服务受影响，周六早上8点已让网路银行、App与ATM的恢复正常运作；另一家ASB银行周六上午表示复原部分，周日上午全数服务恢复。
不过，这些状况的发生，也让灾难复原、营运持续计划（BCP），以及数位韧性等议题，受到更多企业组织的关注。毕竟，不论软硬体或服务，都存在系统故障停摆的可能性，平时是否有这方面的计划，甚至是营运持续的演练，都是企业缩短事故影响的重要环节。
而在众多受到CrowdStrike影响IT运作的企业中，达美航空面临的状况最受外界关注，他们的处理过程遇到许多挑战，也形同帮大家上了一课。因为该公司比其他公司更晚了几天回复上线，导致其航班取消数量、影响客户程度，也是最大。虽然达美航空执行长Ed Bastian在7月31日接受CNBC采访时指出，该公司有4万台Windows伺服器需要手动重启，数量相当庞大，但复原速度相对较慢也是不争的事实。
在灾情与复原状况之外，这场事故也带来一些争议，像是后续衍生不少提告与求偿的消息。例如，灾情发生隔几天，就有马来西亚数位部长向微软、CrowdStrike索赔的消息传出。
达美航空更是以航班取消及公司形象受创为由，表示将提告并向CrowdStrike求偿5亿美元，之后CrowdStrike反指达美试图推卸全部罪过，微软也指出达美航空拒绝协助及基础架构太过老旧，这些提告与求偿的争议，到现在（9月初）还没有初步认定的共识，是要确认谁该为这起事件带来的损失负责？还是就像天灾发生那样自行吸收损失？
不过，美国运输部也介入此事，调查达美航空处置是否得当。换言之，企业的应变与复原能力仍是此事件的关键。
当然，CrowdStrike自身的应变能力也是焦点，像是CrowdStrike对外坦承事故的时间点太晚，在当时饱受各界批评。
例如，CrowdStrike在19日下午1点43分对其用户发出资安公告，但该公告须以用户身分登入才能浏览，外界只能经由用户转贴，才能得知厂商坦承此事；还有我们在当日下午近3点询问该公司台湾总经理陈琤琤，她表示未被授权发言而无法说明。
这些状况，也使得一开始只有IT、资安圈相对了解状况，他们比较清楚是CrowdStrike引发事故，但许多大众媒体报导全球当机事件，都将矛头指向微软。
不过，对于这起事件带来的全球冲击，后续CrowdStrike也持续试图弥补，包括数小时后该公司执行长George Kurtz上电视道歉，持续发布事件最新因应、状态与调查报告。
这段期间CrowdStrike提供补偿方案的10美元礼物卡，也被外界放大检视；今年8月11日DEF CON的Pwnie Awards颁奖，也将今年将「史诗级失败」奖项颁给了CrowdStrike事件。
不过，CrowdStrike总裁Michael Sentonas亲自出席领取的勇气，获得现场相当多研究人员的回响。Michael Sentonas除了再次公开道歉，也表示接受此奖不值得骄傲，但他希望将这个奖项放在公司显眼处来提醒员工们。「知耻近乎勇」这样的态度值得肯定。
到了8月28日，CrowdStrike召开季度会议，说明这几周正赢得许多客户的持续信任，且第二季表现仍超出分析师的预期。但是，这一季的成绩不足以说明这次事件对该公司业绩的影响，接下来两季，才是考验客户是否依旧信任他们，有待后续经营表现才能有所证明。
问题5：开发者写出越界记忆体读取的Bug再起争议
在先前谈及部署验证测试问题之外，为何开发者写出会造成越界（out-of-bounds）记忆体读取的问题，也成为本次事件衍生议题。
事实上，0719事故发生的隔日（周六），我们就看到有国外研究人员在社群平台X声称，在他剖析CrowdStrike EDR系统的当机资料后，发现有段C++程式错误存取了「空指标」（Null Pointer），进而引发系统崩溃。
而在前述CrowdStrike于7月24日的PIR报告，也提到发生越界记忆体读取的问题，7月25日官方部落格的技术文章中，同样指出其频道档案可能包含NULL bytes。因此，证实了这项传言。
对此，微软在7月27日说明Windows安全最佳实践的文章中，也提到其分析结果。微软使用WinDBG侦错工具与一些扩充程式来分析，他们从Windows崩溃报告发现，在读取R8暂存器（Register）特定位址之前有一个检查为NULL的情形，也就是调用一个位址时，但该位址为Null而造成了错误。这也印证CrowdStrike的分析结果。
到了8月6日，事发大约半个月后，CrowdStrike发布了根因分析（RCA）报告，又再有了更具体的说明。
CrowdStrike指出，在7月19日的更新，是基于今年2月首次引入的新感测器功能，这项功能预定义了一组栏位，用于快速回应内容功能的资料搜集。
然而，原本感测器预期是收到20个输入栏位，但当天的更新实际提供了21个栏位，这个栏位不符的情形，导致了越界记忆体读取，进而引发系统崩溃。
由于越界记忆体读取的Bug与漏洞问题，已经探讨多年，因此在这次事件下，也衍生出这方面的讨论。
例如，前几年微软与Google就指出，有70%重大漏洞的根因都出自记忆体问题，到了2022年，包含开源社群、科技大厂与美政府商讨提升开源软体安全对策中，就有一项是针对记忆体安全方面，透过替换「不具记忆体安全（non-memory-safe）」的程式语言，来消除许多漏洞问题的根源。
因此，虽然这次Falcon感测器错误的本质，的确涉及记忆体安全的Bug，值得探讨。不过，可能造成同样故障情形的错误还有很多种。
未来可留意事故责任与监管机关态度的讨论
整体而言，这次事件促使著多个重要议题受到讨论，不仅是资安业者的检讨，企业对于事件的多种反思，都成为大家在看待这次事故时的主要焦点。
例如，CrowdStrike更新前未做好部署验证测试的问题，以及快速因应资安威胁与系统安全的平衡。在我们后续调查国内灾情时，也有医院单位表示将以此事件作为警惕，提醒自己日后在上架IT系统或更新版本时，更需按照标准程序进行，避免为自己带来大麻烦。
另一方面，企业面临这次灾情，对于分散风险这件事也更有感受，甚至考量到双主机备援机制下，也要采不同厂商的防护服务。
至于未来，其实还有一些动向可以留意，例如，这次错误问题是否会被攻击者利用？CrowdStrike表示不会被攻击者利用，而他们也与第三方审查确认。其他像是关于提告的后续消息，监管机关的要求等，可能也是这次事件下的讨论焦点，都值得继续追踪。
CrowdStrike当机事后的5个关键公告
7月20日
官方部落格文章：CrowdStrike发表关于Falcon感测器内容更新的技术细节文章
内容：说明这次更新事故发生在19日的4时09分（世界协调时间），并指出受影响的频道档案为291。
7月20日
官方部落格文章：微软揭露影响电脑数量，并说明将帮助客户度过这次事故
内容：微软指出预估有850万台Windows装置受影响，并表示这虽然不是微软的事件，但考虑到影响整个生态系统，将与相关公司共同协助修补。
7月24日
PDF报告：CrowdStrike公布事件后初步检讨报告
内容：说明发生越界记忆体读取引发作业系统崩溃，有问题的更新涉及「Rapid Response Content」环节，同时负责验证的内容验证器有Bug导致未检测出错误。
7月27日
官方部落格文章：微软发布阐述Windows安全最佳实践的相关文章
内容：解释当今资安产品使用核心模式驱动程式的原因，并传达出Windows已发展一些作法，可帮助限缩这些问题面，并在持续发展中，也将与第三方厂商加强相关合作。
8月6日
PDF报告：CrowdStrike公布根因分析报告
内容：针对越界记忆体读取问题说明，指出原本感测器预期是收到20个输入栏位，但当天的更新实际提供了21个栏位。同时指出事故10日后的7月29日，约有99%的Windows感测器已恢复上线。
0719大当机事故衍生3种乱象
关于CrowdStrike更新引发Windows死当事件，在我们统整出5大焦点议题之外，还有一些围绕在事件周边的消息，也成为整起事故下引发的插曲。
● 出现讯息混淆的状况。在CrowdStrike引发当机事故前几个小时，由于微软发生美国中部Azure资料中心中断事件，加上CrowdStrike在事故发生1个半小时说明引发当机的公告，只有其用户身分登入才能浏览，没有对外公布，导致只有IT、资安圈知道情形，但大众媒体一开始报导全球当机灾情，均将矛头指向微软。
● 错假讯息的分享。例如在事件发生当下转贴拉斯维加斯Sphere球体萤幕出现蓝色当机画面。
● 骇客利用事件名义来发动攻击。CrowdStrike与多家资安业者持续警告，监控到有骇客假借这次IT大当机事故进行恶意活动。