這篇整理一個 B2B 平台（電商後台、會員系統這類替商家保管終端使用者資料的 SaaS）在可能的資料外洩發生時，對它的客戶，也就是商家，發出的通知（breach notification）：歸屬還沒確定時的風險預警、確認外洩之後的確認通知與範圍縮小通知、判定改為已排除時的結案通知、事後的調查報告。範圍從平台收到第一個異常訊號開始，到調查報告公布為止。事故怎麼分級、資安事故怎麼分流，在 8.1 事故分級與啟動條件 與 8.17 Security Incident vs Operational Incident 分流；事中更新的格式與節奏在 8.4 事故通訊與狀態更新。

這些通知的讀者是商家。商家通常是會員資料的控制者（data controller，決定處理個人資料的目的與方式的一方），平台是處理者（data processor，替控制者處理資料的一方）；一個平台在具體契約下各是什麼角色，由法務依契約與適用法規確認；兩個角色的分工與通知方向見 Data Controller and Data Processor（控制者與處理者）。在這個分工下，平台通知商家的時間決定了商家能多早保護自己的會員、能多早履行商家自己對主管機關與會員的通報義務。下文的通知延遲指平台收到第一個異常訊號到商家收到第一則通知之間的時間；事故結束之後，主管機關、商家與受害會員檢驗的就是這段時間，以及這段時間裡每一個判斷的依據。

外洩來源的歸屬判定

外洩事故的第一個訊號常常來自下游回報，平台自己的監控多半沒有對應的告警：商家轉述會員接到詐騙電話，詐騙者說得出訂單編號與購買品項。這種訊號本身分不出外洩來源是誰。平台收到這類訊號後要先做的判斷稱為歸屬判定：以手上的證據判斷平台這一側能否排除在外洩來源之外，結果記為已排除、未排除或指向平台（未排除在調查結束時另有一個終止狀態，見下文〈已排除、未排除與指向平台各自需要的證據〉）。它判定的是資料從哪一側流出，與資安領域判定攻擊者是誰的歸因（threat attribution）是兩件事。

資料流出的三類路徑

同一位會員的資料可能經由三類路徑流出，判定要把它們分開看：

  • 平台這一側：平台自己的元件與員工，以及平台與之簽約、由平台把資料傳過去的子處理者（sub-processor，也就是平台再委託的供應商，例如平台串接的物流與金流整合，見 Sub-processor（子處理者））。來源落在子處理者時，對商家來說仍是平台這一側的外洩：平台作為處理者，要為自己委託的子處理者對商家負責（GDPR 第 28 條第 4 項），所以照下文〈確認通知與結案通知〉一節發出確認通知。
  • 商家持有的平台存取權：商家登入平台管理介面的帳號、商家的 API 金鑰、商家從平台匯出的檔案。資料是從平台上被讀走的，而平台這一側沒有被入侵；2024 年多家企業經由各自的 Snowflake 帳號外洩屬於這一類，攻擊者用的是從客戶那一端外洩、沒有啟用多因素驗證的帳號密碼（見 Snowflake 2024 客戶帳號濫用）。
  • 平台以外的系統：商家自己的系統（自建的訂單系統、ERP），以及商家直接簽約的物流、金流與簡訊業者（供應商，vendor）。

歸屬判定只對平台這一側下結論。商家持有的存取權被查到異常使用時，平台這一側照下面的證據標準判，同時把那個身分的登入與讀取紀錄交給那家商家，讓它以控制者的身分處理。

訊號的來源與合併

觸發歸屬判定的訊號有四種來源：商家或會員的詐騙回報、平台自己發現的元件缺陷或異常存取、子處理者自己的入侵通報，以及外部研究者、執法單位的通知或在外洩資料流通的管道看到自己的資料。會員直接打給平台客服時，平台照 8.24 客服回報的處理 立即呼叫值班、建立事故候選，同時把回報轉給該會員所屬的商家；轉交不必等歸屬判定的結果，對會員的回覆內容由商家決定。

四種訊號進的是同一個判定，結果按商家記。同一段期間有幾個訊號都涵蓋同一家商家時，那一家的結果取優先序最高的一個：指向平台優先於未排除，未排除優先於已排除（不論哪個訊號先進來），發給它的通知逐一列出每個訊號各自的結果與依據。

一份紀錄能證明的範圍與可疑期間

歸屬判定的每一個結果都建立在某一份紀錄上，而一份紀錄只證明得了它記得到的事。內部查證找不到入侵痕跡，只證明在查過、而且有開啟的紀錄裡沒有找到。資料庫的查詢紀錄與雲端的資料存取稽核紀錄常常沒有開啟；開了的話，攻擊者用合法存取憑證發出的查詢也和正常存取長得一樣；網頁伺服器的存取紀錄通常不記請求的內容，放在請求內容裡的漏洞利用不會出現在紀錄上；而被入侵主機上的紀錄可能已被改過（見 8.25 建置主機被入侵後的根除與重建〈清查範圍〉）。所以每一次據紀錄排除或縮小範圍，都寫明那份紀錄涵蓋的期間、記得到什麼、記不到什麼，記不到的部分不算排除；業者與子處理者交來的證據套用同一條標準。把「未排除」記成「已排除」，平台就不會發出任何通知。

紀錄要涵蓋的期間稱為可疑期間。預設的起點是被引用資料裡最早建立的那一筆（詐騙者可能分批從不同來源拿到資料，以最晚那一筆起算會漏掉較早流出的部分），平台自己發現缺陷時是暴露期間的起點，子處理者通報時是平台開始把資料傳給它、或它持有的平台存取憑證簽發的那一天；終點至少到第一個訊號進來那天，存取可能仍在持續時延到當下。期間定得越短，排除越容易成立，所以要比預設的起點往後縮，必須附依據並寫進決策紀錄。

已排除、未排除與指向平台各自需要的證據

判定的預設值是未排除：證據指不出來源，也證明不了平台這一側沒有參與時，結果就是未排除。另外兩種結果各自要有證據才成立。

指向平台要有指向平台這一側的正向證據，有三種：

  • 對不上觸發的讀取：平台自己的紀錄找到平台這一側在可疑期間對相關資料的讀取，而這些讀取對不上任何業務上的觸發。業務上的觸發包括一張工單、一位員工在工具上的一次操作、一個排程工作，以及商家或會員在平台上操作時發出的請求；經由商家持有的身分發出的讀取不算平台這一側的讀取，另照商家持有存取權那一類路徑檢查那個身分有沒有異常使用。
  • 外部附證據確認：子處理者、外部鑑識（Digital Forensics（數位鑑識））或執法單位附證據確認平台這一側的系統，或平台傳給子處理者的資料被存取了；外洩資料樣本裡出現只存在平台這一側的識別碼（平台內部的編號，商家的系統與商家簽約的業者都不保存）時也算這一種，前提是對應商家持有的存取權查過沒有異常使用。
  • 多商家交集：多個彼此無關的商家都有回報，這些商家共用的服務扣掉附證據排除的之後只剩平台這一側，而且各回報商家持有的平台存取權都查過，沒有同一形態的異常使用。這一種是推論而不是直接證據，通知裡要寫明，新的證據可以推翻依它成立的判定。只被其中一兩家商家共用、只解釋得了那幾家回報的商家直簽業者不擋這個判定，照它解釋得了的那幾家另外追。

已排除要平台這一側每一條可能的路徑都被紀錄排除。從回報出發時，是涵蓋可疑期間的讀取紀錄顯示平台這一側對被引用資料的每一次讀取都對得上業務上的觸發；從平台自己發現的缺陷出發時，是紀錄證明缺陷沒有被利用，或者缺陷利用排除不了、而資料讀取的紀錄排除得了（兩層證據見下文）；從子處理者的通報出發時，是子處理者附證據排除，而它持有的平台憑證在平台這一側的 API 紀錄裡也沒有對不上觸發的讀取。找到另一個解釋得了回報的來源（商家自己的系統、商家被盜用的帳號），是讓平台知道該通知誰、協助誰查的線索，但不代替平台這一側的排除：詐騙者可能合併了幾個來源的資料。

兩種結果都可能被推翻。已排除在結案之後，別的商家又有同一形態的回報（先查那一家商家持有的存取權，查明經由它發生的不算）、外部通知指向平台，或平台自己發現一個在可疑期間碰得到那家商家資料的缺陷時重開；指向平台在它的依據被推翻時改判，例如靠多商家交集成立而查出回報其實經由商家持有的存取權發生、靠識別碼成立而查出商家的系統也保存那個識別碼，或子處理者、鑑識單位撤回結論。推翻之後的通知見〈每一家商家的通知狀態〉。

紀錄已經不存在、外部鑑識也沒有結論，而新的訊號停止了一段期間（長度由資安負責人與法務在事前與預警的觸發條件一起定下並簽核）時，事故指揮可以結束調查，結果記為停止調查時仍未排除。它是未排除的終止狀態：合併多個訊號時與未排除同一個優先序，對預警的觸發條件也算未排除。它與已排除的差別在於平台沒有證明自己清白，只是手上已經沒有可以查的東西；對商家的最後一則通知寫明這一點、紀錄記不到什麼，以及哪些訊號會讓調查重開。指向平台而入侵路徑始終找不到時也有對應的終點：外部鑑識沒有結論、新的訊號同樣停止那一段期間後，事故指揮結束調查，受影響範圍維持依權限推得的上限，最後一則通知與調查報告寫明入侵路徑未確認、範圍為什麼縮不下來。

回報、元件缺陷、子處理者通報與外部通知的取證路徑

從回報出發時，方法借自信用卡盜刷調查的共同洩漏點分析（common point of compromise analysis，也常稱 common point of purchase）：靠多張被盜刷卡片的交集認出它們共同經過的商店或服務，不需要先證明每一個沒有共用的地點都清白。事故處理團隊比對詐騙者引用的欄位組合存在哪三類路徑的哪些系統裡、回報分布在哪些商家與這些商家用了哪些服務、被引用的資料落在什麼時間範圍，並查回報商家持有的平台存取權在可疑期間有沒有異常使用（新的來源位置、沒有多因素驗證的登入、讀取量突增、匯出了平常不匯出的範圍）；商家日常的讀取本來就涵蓋全部訂單，看的是異常使用而不是讀過與否。幾家商家的帳號同時被盜用時，事故處理團隊還要查這些帳號的憑證有沒有共同經過平台這一側（平台保存的 API 金鑰、session、客服工單裡的附件）：憑證是從平台這一側流出的，就是平台這一側的外洩，這一步排除之前平台這一側不能判已排除。查到一家商家的帳號被盜用時，接著查同一段時間內其他商家的帳號：有同一形態（同一批來源位置、同一種逐一嘗試外洩帳號密碼的方式）的成功登入的商家，平台同樣交付那段期間的登入與讀取紀錄；只有失敗嘗試的商家，收到帳號防護通知（檢查登入紀錄、啟用多因素驗證、更換 API 金鑰）。商家直接簽約的業者與平台之間沒有契約，比對結果經由商家交給業者，業者不回應時，那家業者仍算候選來源。同一家業者同時是平台的子處理者、又是某些商家直接簽約的業者時，依外洩的那一份資料是從哪一條路徑流進那家業者來判（見 Sub-processor 卡）；分不出是哪一份時，平台這一側判為未排除。

從回報出發時，下文的嫌疑元件是平台這一側保存或碰得到被引用欄位組合、而且碰得到其中至少一家回報商家資料的元件，每一個都標明它解釋得了哪幾家的回報。一個元件碰得到的資料，指它手上的存取憑證（credential，例如資料庫帳號密碼、API 金鑰、存取權杖）能到達的資料，加上它在網路上連得到、而不需要認證或認證可以被繞過的系統（例如同一個網段裡沒有設密碼的快取或搜尋服務），也就是以那個元件為起點的 blast radius。在可疑期間有變更或異常存取的元件排在調查的最前面，但不因此把其他元件移出嫌疑元件：用合法憑證讀走資料的攻擊在紀錄上沒有異常。入侵路徑確認之後，受影響範圍改用入口元件碰得到的資料，加上清查確認攻擊者到過的其他系統各自碰得到的資料計算，取代先前依嫌疑元件推得的範圍。

從平台自己發現的缺陷出發時，下文的暴露指一個元件處在未授權者到得了的狀態、而有可利用的缺陷（漏洞或設定錯誤），可達不等於已被利用；暴露期間從那個狀態開始的那一天算起，不從漏洞公布那天算。嫌疑元件就是有缺陷的那一個，證據分兩層：缺陷有沒有被利用，證據在那個元件自己的存取紀錄與網頁伺服器紀錄裡（利用這個缺陷的請求、已知的 Indicator of Compromise（入侵指標）），紀錄要涵蓋整段暴露期間、而且記得到這個缺陷的利用請求才排除得了；排除不了或已找到利用時，往下查元件碰得到的資料有沒有對不上業務觸發的讀取，找到就是指向平台。各類共用元件碰得到的範圍，以及內部工具平台依攻擊者拿到的權限層級分開計算的範圍，見 7.44 多租戶平台的隔離層級〈存取層的隔離〉。元件經由營運後台的 API 存取資料時，營運後台的稽核紀錄就是這一層的讀取紀錄，它要記得到發起操作的員工，才分得出攻擊者拿著元件憑證發出的讀取。利用紀錄與讀取紀錄都不存在或不完整時，內部已經沒有可查的紀錄，當下委託外部鑑識。

從子處理者的通報出發時，平台拿不到它的紀錄，取證依兩者之間的資料處理協議，要求它提供存取紀錄的查核結果或鑑識結論。嫌疑範圍取兩部分的聯集：平台傳給它的資料（哪些商家的哪些欄位、它保存多久），以及它持有的平台憑證（例如向平台拉訂單用的 API 金鑰）讀得到的資料；平台同時撤換那些憑證。子處理者附證據確認聯集裡的某些資料被存取時，確認通知照整個聯集發、標明是上限，被確認存取的資料另外標出；聯集裡其餘的資料照證據標準被排除之後，範圍才縮小。確認通知能宣告到什麼程度，依子處理者提供的根除進度，由平台的事故指揮據此決定。調查報告的根因另外寫一項：平台傳給它哪些欄位，其中哪些超過它的職責所需。

從外部通知或流通的資料樣本出發時，樣本裡的欄位就等於詐騙者引用的欄位，照從回報出發的方式比對；樣本裡出現只在平台這一側產生的識別碼時，照上面指向平台的正向證據裡「外部附證據確認」那一種判。

confidence 欄位與判定的紀錄

歸屬判定記在 8.18 Incident Intake & Evidence Triage 的 intake 紀錄（事故進入分級前的登記項）上，與 confidence 並列成兩欄：confidence 記錄外洩事件本身的證據來自哪裡、可信到什麼程度，歸屬判定記錄平台這一側能否排除在外洩來源之外。兩欄各自變化：多個商家的回報讓歸屬判定指向平台時，confidence 仍是 external-only，確認通知不等它變成 confirmed。每一次判定的依據、重新判定的時間與會讓判定改變或重開的訊號，寫進 8.19 Incident Decision Log，項目見下文〈事中決策紀錄〉一節。重新判定的間隔依傷害的進展決定：回報仍在增加時以天為單位，回報停止時可以拉長；沒有回報可以觀察時，依外部鑑識的進度與存取憑證撤換的完成時間決定。

判定是「未排除」、而手上已經沒有還沒查過的內部紀錄時，事故處理團隊委託外部鑑識：一開始就沒有紀錄可查的，當下委託；還有紀錄可查的，查完之後判定仍是未排除，就委託。能改變判定的證據常常不在平台自己的紀錄裡（攻擊工具的特徵、外洩資料流通的情報），外部鑑識團隊手上有這些材料。

風險預警：歸屬未定時的通知

風險預警是平台在歸屬判定還是「未排除」時發給商家的通知，收件人是商家，與監控系統發給值班人員的告警是兩回事。它交付三件事：平台收到了什麼訊號、平台正在查什麼、商家現在可以做什麼；它不宣告外洩。

是否發出風險預警，先由法務查兩件事：平台與商家之間的資料處理協議對疑似外洩訂了什麼通知義務與時限，以及手上的證據是否已達到適用法規所說的「知悉」（以 GDPR 為例，處理者在知悉外洩後要無不當延遲地通知控制者；依 EDPB 採納的指引，知悉指對已發生個資外洩有合理程度的確定，不必等鑑識完成；這段指引是就控制者寫的，套用到處理者、以及「未排除」是否已經到達這個程度，由法務判斷）。契約或法規已經要求通知時，平台照它通知，不必再看下文的觸發條件；發送範圍由法務依各商家的契約決定，契約沒有規定時照下文的發送範圍。兩者都沒有要求時，平台在剩下的裁量範圍裡比較兩種代價，下文的觸發條件是這個比較事前寫下的結果。台灣個人資料保護法等其他法規對受託者的義務，同樣由法務依契約與適用法規確認。等待的代價落在會員與商家身上：外洩確實發生時，詐騙在等待期間持續發生，每一天都有新的受害者。誤報的代價落在平台與商家身上：商家為一個最後被排除的訊號提醒會員、加開客服，平台的商譽也因此受損。

資安負責人與法務在事故發生之前寫下並簽核風險預警的觸發條件，事中由事故指揮判斷每一個條件是否成立。理由與 7.37 密碼外洩之後〈通知門檻〉 要求產品層門檻事前定下的理由相同：事件當下做決定的人偏向不通知。契約與法規都沒有要求通知時，下列條件同時成立，平台就發出風險預警：

  • 傷害正在發生，或資料可能已經流出（下列情形有一種成立，這一條就成立）：已經有會員因為疑似外洩的資料受害（詐騙電話、盜用帳號）；平台自己確認了一個碰得到商家資料的元件曾經暴露、排除不了缺陷被利用，而讀取紀錄不足以排除資料被讀走；子處理者通報它保存平台資料的系統疑似被入侵；或平台的資料樣本出現在外洩資料流通的管道。
  • 商家或會員做得了事：收到預警之後，商家能做出降低傷害的動作，例如提醒會員平台不會來電要求轉帳、暫停會被詐騙者冒用的退款流程、加強客服的身分核對；會員收到商家轉達的提醒後，能做的是不回撥來電者留下的號碼、改用官方管道查訂單。還沒有任何會員受害時（平台自己發現的暴露），商家能做的是事先提醒會員注意冒名來電、檢查自己串接平台用的 API 金鑰。商家與會員什麼都做不了時，預警只會增加慌亂。
  • 歸屬判定是「未排除」：已經「指向平台」時發的是確認通知；已經「已排除」時不發預警。
  • 證據強到足以讓平台這一側成為可信的候選：回報來自兩家以上彼此無關的商家、被引用的欄位組合只存在平台這一側而回報商家持有的平台存取權查過沒有異常使用，或者「傷害正在發生，或資料可能已經流出」那一條裡回報以外的情形（元件缺陷、子處理者通報、流通的資料樣本）成立。上面舉的是證據的種類，實際門檻（幾家商家、哪些欄位組合）由資安負責人與法務事前定下；這一項存在的理由是誤報的代價，沒有這一項，每一則詐騙回報都會變成一次對全平台的預警。證據強度這一項不成立時（例如只有一則回報、而商家自己的系統也保存同一組欄位），平台對回報的那一家商家發協查請求，附比對用的欄位與時間範圍，請它同時查自己的系統；協查請求只發給那一家，不宣告任何判定，不是風險預警。

預警的發送範圍由嫌疑元件碰得到哪些商家的資料決定（不論那些資料是否已確認被讀取；來源可能是子處理者時，照〈回報、元件缺陷、子處理者通報與外部通知的取證路徑〉裡子處理者通報的聯集計算），而不是由回報來自哪些商家決定。嫌疑元件只碰得到少數商家的資料（例如只在某一個 cell 內；cell 是把租戶分組、每組各有自己的資料庫分區的做法，見 7.44 多租戶平台的隔離層級）時，預警發給那些商家；嫌疑元件是全平台共用的（共用的訂單資料庫、共用的應用伺服器、內部工具平台本身被入侵）時，預警發給它碰得到的全部商家，即使其中多數還沒有回報。只通知回報者而其他商家的暴露程度相同時，之後確認外洩，這個選擇會被讀成選擇性揭露。

風險預警的內容依讀者能用它做什麼決定：

  • 平台收到了什麼訊號：哪一類回報、從什麼時候開始、回報的形態（詐騙者引用了哪幾類欄位）。商家拿它比對自己的客服紀錄。
  • 平台正在查什麼：歸屬判定目前的結果是「未排除」、已經排除了哪些可能、下一次更新的時間。這一項要寫得精確：寫「目前尚未發現平台系統遭入侵」時，商家會讀成「已排除」；寫「目前證據無法確認外洩來源，平台系統仍在調查範圍內」時，讀者拿到的是正確的判定結果。
  • 商家現在可以做什麼：給會員的提醒文字範本、可以暫時關閉的高風險流程、遇到同類回報時要轉給平台的資訊。比對結果顯示商家自己的系統也是候選時，附上比對用的欄位組合與時間範圍，請商家同時查自己的系統。

預警只送給發送範圍內的商家，走點對點的管道（商家的帳號聯絡人、平台提供給商家的管理介面裡的通知），不貼上公開的狀態頁：在 8.4 事故通訊與狀態更新〈通訊拓樸〉 裡，公開狀態頁發布的是已確認的事實，而預警不宣告外洩，發送範圍也只到嫌疑元件碰得到的商家。預警沿用 8.4〈更新欄位與節奏〉的欄位格式與更新節奏，其中歸屬判定的現況放在 Known limitation、不放 Known facts，因為它不是已確認的事實；商家可以做的事在 8.4 沒有對應欄位，另立一欄。對商家與其他利害關係人的分層照 8.10 Stakeholder 通訊與外部狀態頁。

確認通知與結案通知：外洩確認或排除之後交付的事實

確認通知是歸屬判定變成「指向平台」之後發給商家的通知；它確認的是外洩來源指向平台這一側，不表示平台自己的紀錄已經找到外洩的讀取。它的依據是歸屬判定，不等 intake 紀錄上的 confidence 變成 confirmed（見〈confidence 欄位與判定的紀錄〉）：多個商家的回報讓判定指向平台時就發，通知裡寫明目前的證據來自外部回報、平台自己的紀錄還沒找到對應的存取。它與風險預警的差別在於宣告了外洩，所以每一句都是事後會被檢驗的事實宣稱。確認通知能宣告到什麼程度，由事故指揮依根除進度決定，宣告的等級不高於已成立的那一級：宣告依序升級、前一級成立之後才能宣告下一級：止血完成時只能宣告「已切斷已知的入侵路徑」，清查清單完成後才能宣告「已確認受影響範圍」，之後依序是「已移除攻擊者的立足點」、「事故已解除」，各級的成立條件見 8.25 建置主機被入侵後的根除與重建〈對外宣告已掌握狀況的條件〉。

平台是處理者時，依 GDPR 的分工，平台在知悉外洩後要無不當延遲地通知商家（第 33 條第 2 項），並依它掌握的資訊協助商家履行通報義務（第 28 條第 3 項 (f) 款）。商家要判斷兩件事：是否通報主管機關（第 33 條第 1 項以通報為預設，除非外洩不太可能對當事人的權利與自由造成風險，時限是無不當延遲、可行時不晚於知悉後 72 小時），以及是否通知會員（第 34 條的門檻是高風險）。所以確認通知要交付商家判斷是否通報主管機關、是否通知會員所需的事實，大致對應第 33 條第 3 項列出的通報內容（資料類別與約略的人數、筆數，可能的後果，已採取的措施，聯絡窗口）；同條第 4 項允許這些事實分階段提供，對應下面的下一次更新時間：

  • 這個商家受影響的資料與可能的後果：哪些資料類別、約略多少位會員與多少筆訂單、時間範圍，以及這些資料外洩後會員可能遭遇什麼（詐騙者引用訂單資訊來電、冒用退款流程）。全平台受影響的會員總數與訂單總數讓商家填不出自己通報裡的人數與筆數，也不知道要通知哪些會員，商家需要的是自己的那一份。讀取紀錄不足以算出實際被讀走的資料時，以被入侵的存取憑證能到達的範圍作為受影響範圍的上限，資料類別、會員數與訂單筆數都照這個範圍計算，寫明這是依權限推得的上限而不是實際讀取量；之後鑑識縮小範圍時，在下一次更新寫明縮小的依據；範圍擴大與縮小時的更新見下文〈每一家商家的通知狀態〉。
  • 外洩如何發生、平台做了什麼：入侵路徑（被利用的漏洞或被盜的憑證）、入口元件（攻擊者最先入侵、再由此往內擴散的元件）與已完成的處置，寫到商家能判斷風險是否已經止住的程度。歸屬判定只靠多個商家的回報指向平台、入侵路徑還沒找到時，上面的宣告等級沒有任何一級成立，這一項寫明「外洩來源指向平台，入侵路徑仍在調查」與已採取的防範措施，不寫成風險已止住。受影響範圍在入侵路徑確認之後怎麼計算，見〈回報、元件缺陷、子處理者通報與外部通知的取證路徑〉。入口元件的權限範圍與哪些隔離擋住了擴散，見 7.44 多租戶平台的隔離層級〈事故報告應交代的隔離資訊〉。
  • 商家要做的事與平台提供的協助：給會員的通知範本、客服話術、平台協助處理的窗口，以及賠償的處理程序。賠償先承諾處理程序（認定受影響的標準、受害者要提出的證據、由誰判定與給付時程）；承諾「所有損失由平台負責」這類結果，會讓每一個個案事後都要爭執因果，見 8.25 建置主機被入侵後的根除與重建〈對外承諾賠償的時機〉。
  • 下一次更新的時間：確認通知之後，受影響範圍通常還會更新。

確認通知發給受影響範圍內的商家，不是發給全部收過預警的商家。受影響範圍還沒確認時，照嫌疑元件碰得到的範圍發，範圍標明是依權限推得的上限。對先前收過風險預警的商家發確認通知時，要明寫與預警之間改變了什麼：歸屬判定從「未排除」變成「指向平台」、依據是什麼。兩則之間的變化交代清楚，商家才分得出平台是在更新判斷，而不是前後說法不一。

每一家商家的通知狀態

收過任何一則通知的商家（包括只收過協查請求、帳號防護通知或登入與讀取紀錄的商家），在事故結束前都記著三個欄位：這一家的判定（未排除、指向平台、已排除、停止調查時仍未排除，或不在任何訊號涵蓋的範圍內，例如只收過帳號防護通知的商家）、它相對於範圍的位置（在嫌疑範圍內，也就是嫌疑元件碰得到它的資料；在受影響範圍內，包括依權限推得的上限；確認在範圍之外，這個值以「已確認受影響範圍」那一級成立為前提；還不能判定），以及它已經收過哪些通知。三個欄位裡任何一項改變，或對它已宣告的根除等級改變時，平台就對那一家發一則更新，寫明改變了什麼、依據的紀錄記不到什麼、什麼訊號會讓它再改變。常見的更新有幾種：

  • 仍在調查：嫌疑範圍縮小，而落在新範圍之外的商家還不能宣告不受影響（「已確認受影響範圍」那一級還沒成立）時，照預警承諾的更新時間收到這一則，寫明嫌疑範圍改變了什麼、為什麼還不能宣告。
  • 範圍縮小通知：「已確認受影響範圍」那一級成立後，收過預警或範圍上限確認通知、而落在受影響範圍之外的商家收到這一則，寫明確認的範圍與這一家在範圍之外的依據。在那一級成立之前，平台不對任何商家宣告「你不受影響」。
  • 範圍擴大與宣告退回：新找到一條入侵路徑、或清查發現攻擊者到過先前沒算進去的系統時，已在範圍內的商家在下一次更新裡看到新的依據與先前的數字為什麼偏低，先前收到範圍縮小通知、現在被重新納入的商家收到確認通知。新的入侵路徑也讓已宣告的等級退回（「已切斷已知的入侵路徑」不再成立，以它為前提的「已確認受影響範圍」跟著失效），已發出的宣告要更正；收過範圍縮小通知、這次沒有被重新納入的商家也收到更正，範圍位置退回還不能判定。
  • 確認通知的更正：靠推論成立的指向平台被推翻時（例如查出回報其實經由商家持有的存取權發生），收過確認通知的商家收到更正，寫明哪一項依據被推翻、新的判定是什麼，讓已經向主管機關通報的商家拿得到補報需要的事實。
  • 結案通知：判定轉為已排除時，狀態表上判定改變的每一家（收過預警、確認通知或協查請求的商家）收到結案通知，內容見下一段。
  • 重開通知：已排除或停止調查之後判定重開時，收過結案通知或停止調查通知的商家收到這一則，寫明重開的依據、判定的新值，以及已撤回的會員提醒在什麼情形下恢復。
  • 停止調查的通知：判定記為停止調查時仍未排除時，狀態表上判定改變的每一家收到最後一則通知，寫明平台沒有證明自己清白、紀錄記不到什麼，以及哪些訊號會讓調查重開。

結案通知的內容依收件的是來源所在的商家、還是其他收過預警的商家而不同。來源所在的商家（比對顯示外洩經由它自己的系統或它持有的平台存取權發生）收到比對用的欄位、紀錄與時間範圍，供它查自己的系統、履行它作為控制者的通報；它的會員仍在詐騙風險裡，對會員的提醒繼續維持。其他收過預警的商家收到平台這一側已排除的依據（比對了哪些欄位與紀錄、那些紀錄記不到什麼、什麼訊號會讓判定重開），據此撤回對會員的提醒、結束加開的客服；結案通知說的是平台這一側已排除，不是對商家宣告「你的會員資料沒有外洩」。帳號被盜用的形態也出現在這些商家的帳號上時，它們依〈回報、元件缺陷、子處理者通報與外部通知的取證路徑〉裡的分法，收到的是登入與讀取紀錄或帳號防護通知，不是撤回提醒。結案通知寫出來源商家的名稱，牽涉那一家的資訊與契約，由法務決定，預設不寫。以已排除結案時，平台這一側沒有入侵、也就沒有根除可以報告，結案通知取代調查報告；少了結案通知，誤報的代價會一直留在商家那一側。

調查報告：時間軸與根因要交代的內容

調查報告是歸屬判定指向平台、根除完成之後公布的完整說明。它的讀者除了商家，還有正在評估是否繼續用這個平台的潛在客戶，他們拿報告判斷兩件事：平台這次的歸屬判定與通知決定依據是否充分、同樣的外洩以後是否還會發生。所以報告的兩個主體是時間軸與根因。

時間軸（incident timeline）在調查報告裡記錄的是每一個判斷與它當時的依據，而不只是事件發生的順序：第一個訊號什麼時候進來、當時的歸屬判定是什麼、依據哪些紀錄；什麼時候判定改變、是哪一個新訊號讓它改變；什麼時候委託外部鑑識、什麼時候確認入口、確認的外洩起始時間是哪一天。當時判斷錯了的位置也寫進去，例如「第一次判定為來源不在平台系統，依據是當時的存取紀錄沒有異常；外部鑑識後確認攻擊者讀取資料的查詢沒有被那份紀錄收錄」。時間軸的材料是事中寫下的決策紀錄（見〈事中決策紀錄：通知延遲在事後被檢驗時的材料〉）。有委託外部鑑識時寫明外部結論與內部是否一致；沒有時寫明結論僅來自內部調查。

根因要寫到每一道沒擋住的控制，而不是只寫入侵路徑：

  • 入侵路徑與入口元件：攻擊者經由什麼進來（一個沒更新的第三方元件的已知漏洞、被盜的憑證），最先入侵的是哪一個元件。
  • 為什麼入口元件碰得到那份資料：被入侵的元件手上有什麼存取憑證、那些憑證能到達哪些系統。權限配置這一道控制通常才是外洩規模的成因，入侵路徑換一個，同樣的權限配置會造成同樣的結果；報告怎麼寫入口元件的權限範圍與哪些隔離擋住了擴散，見 7.44 多租戶平台的隔離層級〈事故報告應交代的隔離資訊〉。
  • 為什麼沒有更早發現：哪些訊號當時存在而沒有觸發告警，或者根本沒有被收集。
  • 每一道控制的改善與狀態：已完成的、進行中的與預計完成時間。

只寫入侵路徑的報告，讀者拿到的結論是「那個元件更新了就沒事」，而讓入口元件碰得到資料的權限配置與偵測上的缺口留在原地。根因要挖到系統性的那一道、改善項目要有負責人與完成標準，見 8.5 復盤與改進追蹤；把每一道的改善寫回權限配置與偵測規則，見 7.24 資安事故如何回寫產品與架構；第三方元件的修補流程見 7.B11 Vulnerability Response State Machine。

事中決策紀錄：通知延遲在事後被檢驗時的材料

外洩事故結束後，主管機關、商家與受害會員檢驗通知延遲時，查的是平台在每一個時間點知道什麼、依據什麼做了判斷。最直接的材料是事中留下的決策紀錄，所以事故指揮（或指派的紀錄者）要在每一次判定與每一則通知的決定做出時，當下寫進決策紀錄：

  • 每一次歸屬判定的結果、依據的紀錄（以及那些紀錄涵蓋的可疑期間與記不到什麼）、比對的欄位；結果是未排除時，下一次重新判定的時間與會讓判定改變的訊號；結果是已排除或停止調查時，會讓判定重開的訊號。重新判定的時間記在 8.19 的 Follow-up，會讓判定改變或重開的訊號記在 Rollback condition。
  • 決定發或不發風險預警時，法務對契約與法規的判斷、事前寫下的四個觸發條件（傷害正在發生或資料可能已經流出、商家或會員做得了事、歸屬判定是未排除、證據強到足以讓平台這一側成為可信的候選）各自是否成立與依據，以及發送範圍怎麼決定。
  • 委託外部鑑識的時間與理由，以及縮短可疑期間的依據。
  • 每一則發給商家的通知（〈每一家商家的通知狀態〉列出的每一種，以及風險預警、協查請求、帳號防護通知與交付的紀錄）發給誰、依據哪些紀錄。

有這些紀錄時，誤判與隱瞞在事後分得開：誤判的紀錄顯示當時的證據確實指不出來源，隱瞞的紀錄顯示證據已經在手上、而通知沒有跟著發出。沒有這些紀錄時，平台只能拿工單、通訊與稽核紀錄的時間戳拼回當時知道什麼；拼不出來的部分，檢驗的人只聽得到平台事後的說明。

常見風險邊界：把資料在平台上當成平台被入侵、把未排除當成已排除、模糊的預警文字、只發給回報者的預警、總數取代各商家的資料、只寫入侵路徑的根因、事後補寫的時間軸

  • 被引用的資料存在平台上，就判定指向平台：資料也可能經由商家持有的平台帳號或 API 金鑰被讀走，平台接著發出的確認通知事後會被推翻。
  • 內部查不到入侵痕跡就記成「已排除」：查不到只代表查過、而且有開啟的紀錄裡沒有，平台因此不會發出任何通知。
  • 預警寫「目前尚未發現平台系統遭入侵」：商家讀成已排除，之後確認外洩時，這一句成為平台隱瞞的證據。
  • 嫌疑元件是全平台共用的，預警卻只發給已經回報的商家：之後確認外洩時被讀成選擇性揭露。
  • 確認通知只給全平台受影響的總數：商家填不出自己通報裡的人數與筆數，也不知道要通知哪些會員。
  • 調查報告只寫入侵路徑：讀者以為修補那個元件就足夠，而讓入口元件碰得到資料的權限配置沒有被檢討。
  • 時間軸在事後才補寫：當時的判斷依據沒有留下，誤判與隱瞞在檢驗的人眼中分不開。

延伸閱讀：事故入口判讀、事中更新、對外宣告、決策紀錄與事前隔離