נוהל זה מגדיר את אופן ההתנהלות במקרה של חשד או אירוע אבטחת מידע המשפיע על מערכות JTOOLS או על נתוני לקוחות. הוא חל על כלל הסביבות והשירותים, ומיושם בתיאום עם הלקוח (בעל המאגר) ובכפוף לדין החל.
1. מטרות ותחולה
- להבטיח תגובה מהירה, מתואמת ומתועדת לכל חשד/אירוע.
- לצמצם פגיעה בנתונים, בשירות ובלקוחות.
- לעמוד בדרישות דין ודיווח, ככל שנדרש.
הנוהל חל על כל משתמשי המערכת, עובדי החברה וספקי משנה רלוונטיים.
2. תפקידים ואחריות (RACI)
מנהל אבטחה (Incident Manager) אחראי
- הכרזה על אירוע, סיווג חומרה וניהול תהליך מקצה לקצה.
- תיאום בין צוותים, קבלת החלטות בלימה ושיחזור.
צוות טכני (Dev/Infra/Sec) מבצע
- בלימה טכנית, איסוף ראיות, חקירה ותיקון.
- שחזור ושיפורים טכניים לאחר האירוע.
נציג לקוח (Controller) מיודע/מאשר
- קבלת עדכונים והחלטות הנוגעות למידע שבבעלותו.
- טיפול בבקשות נושאי מידע ודיווח לגורמי צד ג׳ לפי הצורך.
יועץ משפטי מייעץ
- בחינת חובות דיווח ותוכן הודעות ללקוחות/רשויות.
3. סיווג חומרה (Severity)
- S0 – קריטי: דליפה/שינוי נתונים רחב, זמינות ירודה משמעותית, פגיעה נרחבת בלקוחות.
- S1 – גבוה: חשיפה ממוקדת/מוגבלת בזמן לנתוני לקוח, דרוש דיווח מיידי ללקוח.
- S2 – בינוני: חשד לאימות גישה חריגה או תקלה עם פוטנציאל פגיעה מוגבל.
- S3 – נמוך: אירוע לוגים/זיהוי תבנית חשודה ללא פגיעה מהותית.
4. תרשים החלטה – האם זה אירוע?
- האם קיימת גישה בלתי מורשית/דליפת נתונים/השבתה? אם כן → אירוע.
- אם חשד בלבד → פותחים חקירה מקדמית ושומרים לוגים.
- אם לא התקבלו ממצאים תוך זמן קצר → סוגרים כהתראה/False Positive ומתעדים.
5. שלבי טיפול
5.1 זיהוי
- איסוף אינדיקציות (התראות ניטור, דיווח לקוח/עובד, לוגים).
- פתיחת כרטיס אירוע והקצאת מנהל אירוע.
5.2 בלימה (Containment)
- חסימת גישה חשודה, סיבוב מפתחות/API, ניתוק שירות מושפע לפי צורך.
- שמירת עותקי לוג/קונפיגורציה לצורכי חקירה.
5.3 חקירה
- ניתוח לוגים, טיימליין, זיהוי היקף הפגיעה ונקודת הכניסה.
- הערכת חומרה (S0–S3) והשלכות על נושאי מידע/לקוחות.
5.4 תיקון ושחזור
- טלאים/קונפיגורציה/הרשאות; שחזור מגיבוי במידת הצורך.
- בדיקות תקינות (QA) לפני חזרה מלאה לשגרה.
5.5 דיווח
- עדכון הלקוח (Controller) ללא דיחוי בלתי סביר.
- דיווח לרשות/צדדים שלישיים — ככל שנדרש לפי דין.
5.6 שיפור (Lessons Learned)
- פגישת סיכום, ניתוח שורש (RCA) ותוכנית הקשחה/מענה.
- עדכון נהלים/בקרות/הדרכות בהתאם.
6. תקשורת והודעות
- ערוץ תיאום עם הלקוח (מייל/טלפון) + ריכוז פניות לנקודת קשר אחת.
- הודעות חיצוניות יועברו רק לאחר אישור מנהל האירוע והיועץ המשפטי.
- תיאום תוכן ההודעה עם הלקוח במקרים בהם נפגע מידע שבבעלותו.
7. איסוף ראיות ושימור לוגים
- ייצוא ואימות לוגים רלוונטיים (זמן, מקור, משתמש, פעולה, IP).
- שימור עותק “קריאה בלבד” של קבצים/תצורה/DB שנפגעו.
- תיעוד שרשרת שמירה (Chain of Custody) במקרה של ראיות קריטיות.
8. זמני תגובה מומלצים
- S0/S1: בלימה ראשונית מיידית; עדכון לקוח בהקדם האפשרי לאחר אימות ראשוני.
- S2: הערכה ראשונית בתוך שעות ספורות; עידכון לקוח אם יש השפעה בפועל.
- S3: תיעוד ומעקב; אין הודעה חיצונית אם אין השפעה.
הזמנים בפועל יושפעו מנסיבות המקרה, זמינות ראיות וחובות דין.
9. תבניות
9.1 יומן אירוע (Incident Log)
- זמן גילוי/דיווח: ________
- סוג האירוע והמערכת המושפעת: ________
- חומרה (S0–S3): ________
- פעולות בלימה שבוצעו: ________
- ממצאי חקירה: ________
- תיקון/שחזור: ________
- הודעות ללקוח/רשות: ________
- לקחים ושיפורים: ________
9.2 הודעה ללקוח (דוגמה קצרה)
- נושא: עדכון בנוגע לאירוע אבטחת מידע
- תאריך/שעה: ________
- תיאור קצר: ________
- השפעה משוערת: ________
- צעדים שננקטו: ________
- מה נדרש מהלקוח (אם רלוונטי): ________
- נקודת קשר: mdg1306@gmail.com | 053-7788121
הנוסח בפועל יותאם לנסיבות האירוע ולדרישות הדין.
10. מסמכים קשורים
11. יצירת קשר
- דוא״ל: mdg1306@gmail.com
- טלפון: 053-7788121
- אתר: https://jtools.co.il