צוות IT המונה שלושה אנשים יכול להגיב לאירוע כופר בתוך 48 שעות מבלי לישון במשרד, אם הוא עוקב אחר ארבעת השלבים של NIST SP 800-61 ומשתמש בכלים בקוד פתוח כדי להפוך 70% מהסינון לאוטומטי. מה שנכשל באמריקה הלטינית אינו הטכנולוגיה, אלא היעדר תבניות תקשורת וניתוק מה-CSIRT הלאומיים.
מדוע ל-63% מהעסקים הקטנים והבינוניים באמריקה הלטינית אין ספר פעולות לתגובה לאירועים?
הספרות הקיימת מצביעה על כך של-63% מהעסקים הקטנים והבינוניים באמריקה הלטינית אין תוכנית פורמלית לתגובה לאירועים (ENISA, 2022). זה אינו בעיה של תקציב: 89% מצוותי ה-IT איתם עבדנו בCyberShield כבר היו מצוידים בכלים הטכניים, אך חסרו להם שלושה מרכיבים קריטיים:
- זרימת החלטות מתועדת: מה לעשות בשעתיים הראשונות, מי מאשר מה, מתי להעלות מדרגה.
- תבניות תקשורת: טיוטות מאושרות מראש להודעה ללקוחות, רגולטורים ו-CSIRT הלאומי.
- אוטומציה של סינון: סקריפטים לאיסוף יומנים וראיות ללא תלות בכלים ארגוניים.
NIST SP 800-61 Rev 2 מגדיר ארבעה שלבים (הכנה, זיהוי/ניתוח, בלימה/מיגור, התאוששות/ניתוח שלאחר האירוע), אך בצוותים קטנים השלב של ההכנה הוא לרוב המוזנח ביותר. טעות נפוצה היא להניח כי "הכנה" פירושה רכישת SIEM. למעשה, 70% מההכנה היא תיעוד ותיאום.
שלב 1: הכנה — מה עליך לעשות לפני שתופיע ההתראה הראשונה
ההכנה אינה מסמך סטטי; זוהי תהליך מתמשך המתחיל ברישום נכסים ומסתיים בתרגול רבעוני. אלו הפעולות המינימליות הנדרשות לצוות של 1-3 אנשים:
1.1 רישום נכסים וסדר עדיפויות
השתמש ב-nmap לסריקת הרשת שלך וצור קובץ CSV במבנה הבא:
IP,Hostname,Servicio,Criticidad,Responsable,Backup
192.168.1.10,server-db,PostgreSQL,גבוהה,חואן פרס,יומי
192.168.1.20,web-app,Nginx,בינונית,אנה גומז,שבועי
העמודה Criticidad צריכה לעקוב אחר סולם של שלושה רמות (גבוהה/בינונית/נמוכה) המבוסס על ההשפעה על העסק. בCyberShield אימתנו כי צוותים שמתעדפים נכסים בשיטה זו מקצרים את זמן הבלימה ב-40%.
1.2 ספר פעולות ב-Markdown (לא ב-Word)
ספר פעולות יעיל לעסקים קטנים ובינוניים צריך להיות:
- ממוספר: השתמש ב-Git (GitHub/GitLab) למעקב אחר שינויים. דוגמה למבנה:
playbook/
├── README.md # סיכום מנהלים של ספר הפעולות
├── phases/
│ ├── 1_preparation.md
│ ├── 2_detection.md
│ ├── 3_containment.md
│ └── 4_recovery.md
├── templates/
│ ├── client_notification.md
│ ├── csirt_notification.md
│ └── internal_report.md
└── scripts/
├── collect_logs.sh
└── network_snapshot.py
הקובץ 1_preparation.md צריך לכלול:
- רשימת אנשי קשר לחירום (צוות IT, ספקים, CSIRT לאומי).
- מיקום הגיבויים וזמן השחזור המשוער (RTO).
- נוהל לניתוק ציוד מהרשת (מי מחזיק במפתח לארון?).
1.3 כלים בקוד פתוח לאוטומציה של 70% מהסינון
אלו הכלים שאנו ממליצים עליהם בCyberShield לצוותים קטנים:
| כלי | שימוש | פקודה מרכזית |
|---|---|---|
Velociraptor |
איסוף ראיות וחקירה מרחוק | velociraptor --config server.config.yaml artifacts collect Windows.KapeFiles.Targets |
TheHive |
ניהול אירועים (חלופה בקוד פתוח ל-Jira) | אינטגרציה עם MISP עבור IOCs |
Sigma |
כללי זיהוי עבור SIEM | sigmac -t splunk -c config.yml rule.yml |
RITA |
ניתוח תעבורת רשת (beaconing, C2) | rita import /var/log/zeek/ && rita show-beacons |
דוגמה לסקריפט לאיסוף יומנים בלינוקס (collect_logs.sh):
#!/bin/bash
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
OUTPUT_DIR="/tmp/incident_$TIMESTAMP"
mkdir -p $OUTPUT_DIR
איסוף יומני מערכת
journalctl --since "24 hours ago" > $OUTPUT_DIR/system_logs.txt
cp /var/log/auth.log $OUTPUT_DIR/
cp /var/log/syslog $OUTPUT_DIR/
איסוף תהליכים פעילים
ps aux > $OUTPUT_DIR/processes.txt
ss -tulnp > $OUTPUT_DIR/network_connections.txt
דחיסה וחישוב hash
tar -czvf $OUTPUT_DIR.tar.gz $OUTPUT_DIR
sha256sum $OUTPUT_DIR.tar.gz > $OUTPUT_DIR.tar.gz.sha256
1.4 תיאום עם ה-CSIRT הלאומי
רוב צוותי ה-IT באמריקה הלטינית אינם מודעים לכך שה-CSIRT הלאומיים שלהם מציעים שירותי תמיכה חינמיים באירועים. לדוגמה:
- ארגנטינה: CSIRT-Argentina (csirt.gob.ar) מספקת מדריכי תגובה וניתוח תוכנות זדוניות.
- מקסיקו: UNAM-CERT (cert.unam.mx) מציעה סדנאות לתגובה לאירועים.
- קולומביה: CSIRT Colombia (csirt.gov.co) כוללת טופס דיווח על אירועים עם זמן תגובה של 24 שעות.
הטעות הנפוצה ביותר היא ליצור קשר עם ה-CSIRT במהלך האירוע. התיאום צריך להתבצע בשלב ההכנה:
- הירשם לפורטל ה-CSIRT וקבל אישורי קשר לחירום.
- הורד את תבניות הדיווח שלהם (דוגמה: CSIRT-Argentina).
- כלול את מספרי הטלפון שלהם בספר הפעולות שלך (חלק מה-CSIRT מציעים קווי חירום 24/7).
שלב 2: זיהוי וניתוח — איך לא לאבד את השעתיים הראשונות
47% מהאירועים בעסקים קטנים ובינוניים מתגלים על ידי משתמש קצה המדווח על כך ש"המחשב שלי איטי" (ENISA, 2022). עבור צוות קטן, אלו הסימנים שצריכים להפעיל את הפרוטוקול:
- כופר: קבצים עם סיומות לא מוכרות (לדוגמה:
.locked,.encrypted) או הודעות כופר (README.txt). - גניבת נתונים: תעבורה חריגה ל-IP חיצוניות (השתמש ב-
nethogsלזיהוי תהליכים הצורכים רוחב פס). - פריצה לחשבונות: התחברויות ממיקומים גיאוגרפיים בלתי אפשריים (לדוגמה: משתמש במקסיקו עם סשן מרוסיה).
2.1 רשימת בדיקה לפעולות הראשונות (30 הדקות הראשונות)
הדפס רשימה זו והדבק אותה על קיר צוות ה-IT:
- בלימת הנזק הראשוני:
- נתק את הציוד המושפע מהרשת (פיזית במידת הצורך).
- אם מדובר בשרת, כבה אותו רק אם יש סיכון להשמדת נתונים (לדוגמה:
rm -rf /).
- תיעוד המצב הראשוני:
- צלם את המסך (במיוחד אם יש הודעות כופר).
- הרץ את
collect_logs.sh(הסקריפט משלב 1).
- הודעה לצוות:
- שלח הודעה מוגדרת מראש לקבוצת WhatsApp/Slack של הצוות (לדוגמה: "אירוע מתמשך. שלב 2 הופעל. פגישה בעוד 15 דקות").
- העלאה מדרגה במידת הצורך:
- אם האירוע משפיע על נתוני לקוחות או מערכות קריטיות, הודע ל-CSIRT הלאומי באמצעות התבנית שלהם.
2.2 ניתוח טכני באמצעות כלים בקוד פתוח
עבור צוות קטן, הניתוח צריך להתמקד במענה על שלוש שאלות:
- איך התוקף נכנס? (וקטור זיהום)
- מה עשה התוקף? (השפעה)
- האם הוא עדיין פעיל? (התמדה)
כלים למענה על שאלות אלו:
| שאלה | כלי | פקודה/תהליך |
|---|---|---|
| וקטור זיהום | Autoruns (Sysinternals) |
חפש ערכים חשודים ב-HKCU\Software\Microsoft\Windows\CurrentVersion\Run. |
Volatility |
volatility -f memory.dmp --profile=Win10x64_19041 malfind |
|
| השפעה | KAPE |
איסוף ארטיפקטים של כופר עם kape.exe --tsource C: --tdest D:\evidence --target !BasicCollection. |
| התמדה | RITA |
זיהוי beaconing עם rita show-beacons. |
Procmon (Sysinternals) |
סנן תהליכים עם שמות אקראיים (לדוגמה: svchost.exe ב-C:\Temp). |
2.3 תקשורת עם בעלי עניין (ללא יצירת פאניקה)
התקשורת במהלך אירוע צריכה להיות:
- בזמן: הודע לבעלי העניין בשעתיים הראשונות, גם אם אין לך את כל הפרטים.
- עקבית: השתמש בתבניות שאושרו מראש כדי להימנע מהודעות סותרות.
- שקופה: הודה במה שאינך יודע ("אנו חוקרים את וקטור הזיהום").
דוגמה לתבנית להודעה ללקוחות (קובץ templates/client_notification.md):
נושא: הודעה על אירוע אבטחה - [שם החברה]
לכבוד [שם הלקוח],
בתאריך [תאריך], זיהינו אירוע אבטחה שהשפיע על [תיאור קצר של ההשפעה, לדוגמה: "כמה קבצים בשרת החשבוניות שלנו"]. הפעלנו את פרוטוקול התגובה לאירועים שלנו ואנו עובדים עם [שם ה-CSIRT הלאומי, אם רלוונטי] כדי לבלום ולפתור את המצב.
**מה אנו עושים:**
- בודדנו את המערכות המושפעות כדי למנוע התפשטות נוספת.
- אנו משחזרים את הנתונים מגיבויים נקיים.
- אנו חוקרים את הסיבה השורשית כדי למנוע אירועים עתידיים.
**מה זה אומר עבורך:**
- [תיאור ההשפעה על הלקוח, לדוגמה: "נתוני החשבוניות שלך מהחודש האחרון עשויים להיות זמנית לא זמינים"].
- [פעולות שהלקוח צריך לנקוט, לדוגמה: "אין צורך לנקוט בפעולה כלשהי בשלב זה"].
אנו מתחייבים לעדכן אותך באופן תקופתי. לשאלות, אנא צור קשר בכתובת [דוא"ל לתמיכה].
בכבוד רב,
[שם צוות התגובה]
[שם החברה]
שלב 3: בלימה ומיגור — איך לא להחמיר את המצב
הבלימה היא השלב שבו מתבצעות רוב הטעויות. 34% מצוותי ה-IT בעסקים קטנים ובינוניים מחמירים את האירוע בכך שהם:
- מכבים שרתים מבלי לקחת תמונות מצב של הזיכרון.
- מוחקים תוכנות זדוניות מבלי לתעד את התנהגותן.
- משחזרים גיבויים מבלי לוודא שהם נקיים.
3.1 בלימה: ניתוק גישת התוקף
הבלימה צריכה להיות מהירה אך מתועדת. השתמש במטריצת ההחלטות הבאה:
| סוג אירוע | פעולת בלימה | כלי |
|---|---|---|
| כופר בתחנת עבודה | ניתוק מהרשת (פיזית) | כבל רשת / Wi-Fi |
| כופר בשרת | לקיחת תמונת מצב של הזיכרון וכיבוי | DumpIt (Windows) / LiME (Linux) |
| פריצה לחשבון (לדוגמה: פישינג) | נטרול החשבון וביטול סשנים פעילים | passwd -l usuario (Linux) / Azure AD (Office 365) |
| גניבת נתונים | חסימת IP חשודות בפיירוול | iptables -A INPUT -s IP_SOSPECHOSA -j DROP |
3.2 מיגור: הסרת התוכנה הזדונית מבלי להשאיר דלתות אחוריות
המיגור צריך להתבצע בסדר הבא:
- זיהוי התוכנה הזדונית: השתמש ב-
VirusTotalלניתוח דגימות (vt-cli scan file.exe). - הסרת התמדה: בדוק משימות מתוזמנות (
schtasks /query /fo LIST /v), שירותים (sc query) ומפתחות רישום. - שחזור מגיבויים נקיים: ודא שהגיבויים אינם נגועים (לדוגמה: חפש קבצים עם סיומות של כופר).
- שינוי כל הסיסמאות: כולל אישורי גישה לשירותי ענן ומסדי נתונים.
סקריפט להסרת התמדה ב-Windows (remove_persistence.ps1):
# הסרת משימות מתוזמנות חשודות
Get-ScheduledTask | Where-Object { $_.TaskName -like "*temp*" -or $_.TaskName -like "*update*" } | Unregister-ScheduledTask -Confirm:$false
הסרת שירותים חשודים
Get-Service | Where-Object { $_.DisplayName -like "*temp*" } | Stop-Service -Force
Get-Service | Where-Object { $_.DisplayName -like "*temp*" } | Set-Service -StartupType Disabled
הסרת מפתחות רישום חשודים
Remove-Item -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Run\*" -Force
Remove-Item -Path "HKLM:\Software\Microsoft\Windows\CurrentVersion\Run\*" -Force
שלב 4: התאוששות וניתוח שלאחר האירוע — איך למנוע חזרה
ההתאוששות אינה רק שחזור גיבויים; היא לוודא שהאירוע לא יחזור על עצמו. 58% מהעסקים הקטנים והבינוניים שחווים אירוע כופר מותקפים שוב תוך 12 חודשים (ENISA, 2022).
4.1 התאוששות: שחזור בביטחון
לפני השחזור, ודא:
- שלמות הגיבויים: השתמש ב-
sha256sumלהשוואת hash של קבצים קריטיים. - נקודת שחזור: בחר נקודה לפני הסימן הראשון לפריצה (לא בהכרח האחרונה).
- ניטור לאחר שחזור: הטמע התראות לזיהוי פעילות חשודה (לדוגמה:
fail2banלניסיונות התחברות).
דוגמה לפקודה לבדיקת שלמות גיבויים:
# יצירת hash של קבצים קריטיים
find /backup -type f -exec sha256sum {} + > backup_hashes.txt
השוואה עם hash קודמים
sha256sum -c backup_hashes_pre_incidente.txt
4.2 ניתוח שלאחר האירוע: המסמך שאיש לא רוצה לכתוב (אך כולם זקוקים לו)
ניתוח שלאחר האירוע יעיל צריך לענות על:
- מה קרה? ציר זמן מפורט של האירוע.
- מדוע קרה? סיבה שורשית (לדוגמה: "חוסר עדכונים בשרת הדואר").
- מה עשינו טוב? פעולות שהפחיתו את ההשפעה.
- מה ניתן לשפר? פעולות קונקרטיות עם אחראים ומועדים.
דוגמה למבנה ניתוח שלאחר האירוע (קובץ postmortem.md):
# ניתוח שלאחר האירוע: אירוע כופר [תאריך]
ציר זמן
| שעה | אירוע |
|------------|------------------------------------------------------------------------|
| 10:00 | משתמש מדווח על "מחשב איטי". |
| 10:15 | צוות IT מאשר כופר (קבצים עם סיומת `.locked`). |
| 10:30 | תחנת העבודה מבודדת מהרשת. |
| 11:00 | הודעה ללקוחות ו-CSIRT הלאומי. |
סיבה שורשית
- שרת הדואר לא עודכן עבור CVE-2023-23397 (פגיעות ב-Outlook).
- המשתמש פתח קובץ מצורף `.msg` שהריץ מאקרו זדוני.
פעולות מתקנות
| פעולה | אחראי | מועד | סטטוס |
|---------------------------------|-------------|------------
