הפרצה קרתה אצל הספק — ואתם חייבים לדווח: 72 השעות הראשונות

באמצע אוגוסט 2026 דיווחה ביטס אוף גולד, חברת הקריפטו המפוקחת הגדולה בישראל, על אירוע אבטחת מידע שבו נחשפו פרטיהם של כ-200 אלף לקוחות — שם מלא, מספר תעודת זהות, כתובת דוא״ל, טלפון, כתובת IP ופרטי חשבון בנק. הפרט המעניין באירוע הזה איננו היקף הדליפה. הוא מיקומה: הפורץ לא נכנס למערכות של ביטס אוף גולד. הוא נכנס למערכת ניתוח נתונים של ספק — כלי BI בשם Metabase, בהתקנה עצמאית — וניצל חולשה קריטית שזכתה למזהה CVE-2026-72898.

זהו התרחיש שרוב הארגונים הישראליים אינם מתורגלים בו. יש נהלים לאירוע שקורה אצלנו. אין נהלים לאירוע שקורה אצל מישהו אחר, עם המידע שלנו. והפער הזה יקר, כי החוק אינו מכיר בו: מבחינת תיקון 13 לחוק הגנת הפרטיות, החובה נשארת אצלכם.

למה דווקא כלי ה-BI

המקרה של Metabase ממחיש דפוס חוזר. מדובר בחולשת SQL Injection שאינה דורשת הזדהות כלל, דרך נקודת הקצה של איפוס סיסמה, והיא מדורגת בחומרה 10.0 — הציון הגבוה ביותר בסולם CVSS. סריקות רשת מצאו אלפי התקנות עצמאיות חשופות, ורובן המכריע לא עודכן בזמן. הניצול בשטח הקדים את הפרסום הפומבי של החולשה.

כלי BI הוא יעד אידיאלי בדיוק משום שהוא עושה את עבודתו היטב: הוא מחובר בהרשאות קריאה רחבות למסדי הנתונים היצרניים, הוא מרכז מידע ממערכות שונות במקום אחד, ולעיתים קרובות הוא הותקן פעם אחת על ידי מפתח שכבר עזב. בפועל זו מערכת שמחזיקה את המידע הרגיש ביותר בארגון ואינה מופיעה באף מסמך הגדרות מאגר.

השורה האחרונה אינה תיאורטית: באותו גל אירועים נחשפו גם לקוחות של יצרני ארנקי קריפטו בעקבות פריצה לספק שינוע שלהם. הספק שנראה הכי פחות ״טכנולוגי״ הוא לעיתים זה שמחזיק את הרשימה השלמה.

השעון מתחיל כשנודע לכם — לא כשהספק מסיים לחקור

זו הנקודה שבה ארגונים נכשלים, והיא כבר תומחרה בפועל. בעיצום הכספי המשמעותי הראשון שהוטל מאז כניסת תיקון 13 לתוקף, הרשות להגנת הפרטיות קנסה גוף בריאות גדול בסכום של מאות אלפי שקלים — לא בשל התקלה עצמה, אלא בשל העיכוב בדיווח. הארגון ידע על החשד, פתח בירור פנימי, והמתין לתוצאותיו לפני שדיווח. הרשות ראתה בכך הפרה.

חובת הדיווח מתגבשת ברגע שמתעורר חשש סביר לגישה בלתי מורשית למידע — לא בסיום התחקיר ולא לאחר שהתקבלה תשובה סופית מהספק.

כשהאירוע הוא אצל הספק, המתח הזה מחריף. הספק מנהל את החקירה שלו, בקצב שלו, ומול עשרות לקוחות במקביל. הוא ישלח לכם עדכון ראשוני מעורפל ויבקש להמתין. ההמתנה הזו היא הסיכון הרגולטורי שלכם, לא שלו. אתם נדרשים לדווח על בסיס מה שידוע לכם באותו רגע, ולעדכן בהמשך.

72 השעות הראשונות: תוכנית פעולה

שעות 0–4 — לקבע עובדות

1. לתעד את רגע הגילוי. תאריך, שעה, מי קיבל את ההודעה ובאיזה ערוץ. זהו המסמך הראשון שהרשות תבקש, והוא זה שקובע אם עמדתם בלוח הזמנים.
2. לדרוש מהספק הצהרה בכתב ובה שלוש שאלות בלבד: אילו מערכות נגישות נפרצו, אילו שדות מידע שלנו נכללו, ומהו חלון הזמן של החשיפה. שיחת טלפון אינה ראיה.
3. להקפיא מחיקות ולוגים. מדיניות שמירה אוטומטית שמוחקת לוגים אחרי 30 יום עלולה למחוק בדיוק את הראיה שתידרש בהמשך.
4. לפתוח יומן אירוע מרוכז בניהול בעל תפקיד אחד. שתי מחלקות שמדווחות במקביל גרסאות סותרות הן הכשל הנפוץ ביותר בתיקים האלה.

שעות 4–24 — להעריך היקף בלי גישה לראיות

כאן נמצא הקושי המבני: אין לכם גישה למערכות של הספק, ולכן אינכם יכולים לבצע פורנזיקה עצמאית. מה שכן ניתן לעשות — ויש לעשות — הוא לשחזר את החשיפה מהצד שלכם:

• לשלוף מהחוזה ומה-DPA אילו שדות מידע הועברו לספק בפועל, ולהצליב מול מה שהספק מודה בו.
• לבדוק את לוגי ההעברה שלכם — אילו רשומות נשלחו, מתי, ובאיזה נפח. גם אם הספק אינו יודע, אתם יודעים מה מסרתם.
• לסווג את רגישות המידע. מספרי תעודת זהות, פרטי חשבון בנק ומידע רפואי מעלים את חומרת האירוע ואת רמת האבטחה הנדרשת — והם משנים את אופי הדיווח.
• לזהות אם מדובר באירוע אבטחה חמור לפי ההגדרה בתקנות, שכן זו הקטגוריה שמפעילה את חובת הדיווח המיידית לרשות.

שעות 24–72 — דיווח, יידוע והחלטות עסקיות

1. להגיש את הדיווח לרשות להגנת הפרטיות בטופס הייעודי, בצירוף מה שידוע נכון לאותה שעה.
2. להחליט על יידוע נושאי המידע. כשנחשפו מזהים ישירים כמו ת״ז ופרטי בנק, יידוע הוא לרוב המהלך הנכון גם כשאינו נדרש במפורש — הוא מקטין נזק תדמיתי ומצמצם חשיפה לתביעות.
3. להזהיר מפני הונאות המשך. דליפה של ת״ז וטלפון מתורגמת תוך ימים לשיחות התחזות בשם הארגון. הודעה יזומה ללקוחות שמבהירה ״לעולם לא נבקש מכם סיסמה בטלפון״ שווה יותר מכל התנצלות.
4. להיערך לתגובת שרשרת עסקית. באירוע ביטס אוף גולד, שותפה עסקית הקפיאה שירות שהסתמך על החברה. הפרצה של הספק שלכם הופכת במהירות להחלטה עסקית של הלקוח שלכם.

מה למנוע לפני האירוע הבא

אחרי שהאבק שוקע, שלוש פעולות מונעות את החזרה על אותו תרחיש. אף אחת מהן אינה פרויקט של שנה:

• רשימת מעבדי מידע חיה — טבלה אחת ובה כל ספק, אילו שדות מידע הוא מקבל, היכן הוא מאחסן אותם ומי מנהל את הקשר מולו. זהו גם המסמך הראשון בכל ביקורת ספקים וגם הראשון שמבקשים בשאלון פיקוח.
• סעיף דיווח עם לוח זמנים מספרי בחוזה — ״ללא שיהוי״ אינו אכיף. ״הודעה בכתב תוך 24 שעות מרגע גילוי חשד״ כן. יש להוסיף זאת בכל חידוש חוזה.
• מיפוי מערכות צל — סבב שאלה אחת מול כל מנהל מחלקה: אילו כלים מחוברים למסד הנתונים שלנו. כלי ה-BI, סביבת ה-Staging וכלי הדיוור יעלו כמעט תמיד, ולרוב אינם מופיעים באף מסמך קיים.

מי שרוצה לוודא שהתרחיש הזה מכוסה מקצה לקצה — מהמיפוי ועד נוהל הדיווח — יכול להתחיל בסקר סיכונים ובדיקת פערים, או להיעזר בממונה הגנת פרטיות חיצוני שמנהל את מערכת היחסים מול הספקים באופן שוטף. כשהאירוע כבר קרה, תגובה לאירועי סייבר היא הדרך לוודא שלוח הזמנים הרגולטורי נשמר גם כשהראיות נמצאות אצל מישהו אחר.