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大當機事故進行惡意活動。