數據泄露程序

1）目的和應用範圍

目的：在確認或可能泄露個人/付款/運營數據時,盡量減少損害,滿足法律要求並迅速恢復正常運行。
覆蓋範圍：玩家/員工的PII，支付文物，訪問標記/代幣，KYC/AML文件，會員/合作夥伴數據，產品和基礎設施的機密文物。

2）「泄漏」的定義和標準"

數據泄漏（data breach）-由於安全事件或過程錯誤,侵犯個人數據（或其他受保護信息）的隱私、完整性或可用性。
確認的vs嫌疑人：任何指標（SIEM異常，供應商/用戶的消息，Paste站點）都會觸發該程序，然後再進行反駁。

3）嚴重性分類（示例）

4）SLA和「事件橋」

啟動：在Medium+中創建一個戰爭室（聊天/呼叫）,分配給事件指揮官（IC）。
SLA： Low-24小時·中學-4小時·高-1小時·Critical-15分鐘。
加登斯：每30-60分鐘（內部），每2-4小時（外部利益相關者）。

5）RACI（簡稱）

6）應對程序（逐步）

1.識別和初級驗證

SIEM/EDR/antifrod/vendor/用戶的信號 →寫入事件註冊表。
收集最低限度的事實：什麼/何時/何地/多少，受影響的數據類型和管轄權。

2.集中（遏制）

禁用易受攻擊的殘局/殘局，地理段，時間限制，凍結發布。
按鍵/令牌輪換,取消訪問,阻止受損帳戶。

3.解散（消除）

補丁/偽造,清除惡意工件,重新組合映像,檢查子處理器。

4.恢復（恢復）

加那利交通輸入，回歸監控，完整性支票通過。

5.Forenzics和影響評估

計算受試者的數量，敏感性，地理位置，風險；確認受影響的記錄。

6.通知和通訊

DPO/Legal確定通知的義務和期限；編寫案文；發送給收件人。

7.後太平間和CAPA

原因分析（5 Whys），有業主和時間表的糾正/預防措施計劃。

7）72小時窗口和法律收件人（地標）

數據監督（DPA）-在發現重大泄漏後不遲於72小時通知,除非排除對實體權利/自由的風險。
用戶-在高風險下「沒有不合理的延遲」（帶有清晰的建議）。
賭博監管機構-影響玩家/可持續性/報告。
銀行/PSP-存在付款/代幣損害/可疑交易的風險。
合作夥伴/供應商-如果共享流/數據受到影響或需要操作。

8）Forenzik和「證據存儲鏈」

卷/邏輯快照，散列工件導出（SHA-256）。
僅使用副本/快照；源系統只讀。
操作協議：誰/時間/做了什麼,使用的命令/工具。
存儲在WORM/對象存儲中；有限的訪問，審核。

9）通訊（內部/外部）

原則：事實→措施→建議→下一次補充。
不可能：發布PII，構建未經檢驗的假設，承諾沒有控制的時間表。

• 檢測到什麼?·規模/類別·當前措施·風險·下一步步驟·HH： MM的下一個升級。

10）與供應商/子處理器的交互

檢查他們的事件註冊表、訪問日誌、通知SLA、子處理器列表。
請求報告（pentest/Forenzica）,提交數據刪除/退回確認。
如果不一致，DPA-升級和臨時隔離/暫停集成。

11）通知模板（片段）

11.1監督機構（DPA）

簡要說明發現事件和時間、類別/大致數據量、主題組、地理、影響和風險、采取/計劃措施、DPO聯系人、應用程序（時間線、哈希摘要）。

11.2個用戶

發生了什麼？哪些數據可能受到影響；我們做了什麼；您可以做什麼（更改密碼、事務控制、網絡釣魚提示）；如何聯系；鏈接到常見問題/支持中心。

11.3 合作夥伴/PSP/監管機構

事實和受影響的接口；合作夥伴的預期行動；截止日期；聯系人。

12）事件登記冊（最低字段）

ID·發現時間/確認時間·嚴重性·來源·系統/數據·範圍/類別·地理·涉及的供應商·采取的措施（時間）·通知（人員/時間）·負責任（RACI）·參考文物·SARA/時限·狀態。

13）度量指標和目標基準

MTTD/MTTC/MTTR（檢測/遏制/恢復）。
72小時通知的百分比為100%。
確定根本原因的事件比例≥ 90％。
CAPA按時關閉≥ 95%。
由於一個原因而重復發生的事件≤ 5％。
SLA （Medium/High/Critical）中關閉的事件比例為90/95/99%。

14）支票單

14.1開始（前60分鐘）

• 指定IC並打開戰爭室
• 穩定措施（斷開/限制/鑰匙旋轉）
• 收集最低限度的事實和截圖/標誌
• 已通知DPO/Legal，確定了前期類別
• 凍結發布和登錄清除協議

14.2至24小時

• Forenzika：範圍/類別/地理（草稿）
• 關於通知、起草案文的決定
• 反應/完整性檢查計劃
• WORM中的證據包，事件的時間線

14.3到72小時

• 向DPA/監管機構/PSP發送通知（如果需要）
• 用戶配合（高風險）
• 更新CAPA計劃、所有者和時間表

15）示範情景和措施

A）將劄幌聊天基地出口到開放式存儲區

措施：關閉訪問，清點下載，通知受影響者，加強S3/ACL政策，DLP出口規則。

B）破壞API訪問令牌

措施：立即輪換，refresh代幣召回，呼叫日誌驗證，網絡手冊重新簽名，流量分割。

C） KYC掃描通過供應商泄漏

措施：集成隔離，刪除確認，手動重新驗證高風險客戶，DPA/保留修訂。

D）在公眾中發布轉儲內容

措施：固定文物（哈希），合法刪除鏈接（接管），通知，監控進一步出版物。

16）與合規性和隱私集成

與GDPR過程的結合：DSAR，RoPA，DPIA/DTIA；在供應商/目標更改時更新策略和cookie/CMR。
將事件納入風險矩陣並修改閾值/控制。

17）CAPA和後太平間（穩定後≤ 72小時）

報告結構：事實/時間線·影響·根本原因·CAPA列表（所有者、期限、成功標準）·有效性檢查日期（30-60天後）。

18）流程成熟度路線圖

月1：更新劇本、聯系人、模板、WORM存檔、通知測試。
第二個月：tabletop演習（泄漏PII/供應商/代幣），SOAR花花公子。
第3個月以上：季度回顧、供應商審核、反親屬/檢測模型生物測試、定期閾值修訂。

TL;DR

泄漏：快速穩定（封裝）,準確確認（forenzika）,及時通知（DPA/用戶/合作夥伴）,透明記錄（註冊表、時間線、證據）和修復根本原因（CAPA）。結果-減少損害，合規性以及恢復玩家和合作夥伴的信心。