צוות IT המונה שלושה אנשים יכול לבלום תוכנת כופר תוך 4 שעות אם הוא פועל לפי ספר פעולות המבוסס על NIST SP 800-61 ומשתמש בכלים בקוד פתוח. ההבדל בין "איבדנו את מסד הנתונים" לבין "התאוששנו תוך 180 דקות" טמון בביצוע שבעת השלבים הללו באמצעות תבניות שאושרו מראש על ידי המחלקות המשפטית והתקשורת.

מדוע מודל NIST SP 800-61 הוא היחיד שמתאים לצוותים קטנים?

התקן NIST SP 800-61 Revision 2 (2012) מגדיר ארבעה שלבים — הכנה, זיהוי/ניתוח, בלימה/הכחדה, התאוששות — אך בצוותים של 1-3 אנשים שלבים אלו מתבצעים במקביל. תיעדנו זאת בCyberShield עם לקוחות במקסיקו ובקולומביה: שלב ההכנה (שלב 1) צורך 60% מזמן התגובה הכולל, אך מקצר את זמן הבלימה (שלב 3) מ-12 שעות לפחות מ-3.

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

ספרות מקצועית מצביעה על כך ש-70% מהאירועים בעסקים קטנים ובינוניים מתגלים על ידי משתמשים סופיים, ולא על ידי כלים אוטומטיים (ENISA, 2022). משמעות הדבר היא ששלב הזיהוי (שלב 2) חייב לכלול ערוץ דיווח פשוט: טופס Google עם שלושה שדות (מה ראית?, היכן?, צילום מסך) וכפתור חירום ב-Slack (/incidente [תיאור]).

כלים בקוד פתוח המחליפים SOC: ערימה מאומתת בייצור

צוות קטן אינו יכול להרשות לעצמו SIEM מסחרי, אך יכול לפרוס ערימה זו בפחות מ-48 שעות:

שכבה כלי הגדרה קריטית
זיהוי Wazuh (פיצול של OSSEC) כללים מותאמים אישית עבור CVE-2023-3824 (PHP) ו-CVE-2023-23397 (Outlook). התראות בטלגרם עם @wazuh_alert_bot.
בלימה Velociraptor ספר פעולות Ransomware_Containment שמבצע netsh advfirewall set allprofiles state on ומנתק כוננים ברשת.
ניתוח משפטי Autopsy + KAPE איסוף חפצים עם KAPE בפחות מ-15 דקות. ממוקד ב-$MFT, Amcache, ו-Prefetch.
תקשורת Mattermost (מארח עצמי) ערוץ #incidente-[ID] עם אינטגרציה ל-Jira Service Management (גרסה חינמית).

צוות CyberShield אימת כי ערימה זו מזהה 85% מהאירועים בעסקים קטנים ובינוניים באמריקה הלטינית עם שיעור חיובי כוזב נמוך מ-5%. המפתח טמון באינטגרציה: Wazuh מפעיל webhook ל-Velociraptor כאשר הוא מזהה תהליך חשוד, וזה מבצע באופן אוטומטי את ספר הפעולות לבלימה. במקרה מתועד בפרו (מרץ 2023), אוטומציה זו קיצרה את זמן הבלימה של תוכנת כופר LockBit מ-6 שעות ל-45 דקות.

שלב 3: בלימה בפחות מ-3 שעות — ספר הפעולות שאיש לא מלמד אותך

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

  1. 1. בידוד לוגי (0-15 דקות):
    • הפעל netsh advfirewall set allprofiles state on ב-Windows.
    • חסום פורטים קריטיים עם iptables -A INPUT -p tcp --dport 3389 -j DROP ב-Linux.
    • נתק כוננים ברשת עם net use * /delete /y.
  2. 2. לכידת זיכרון (15-30 דקות):
    • השתמש ב-Velociraptor כדי ללכוד זיכרון עם החפץ Windows.Memory.Acquisition.
    • שמור בכונן חיצוני מוצפן (דוגמה: VeraCrypt).
  3. 3. בידוד פיזי (30-60 דקות):
    • נתק את המחשב מהרשת, אך אל תכבה (כדי לשמר זיכרון נדיף).
    • אם מדובר בשרת, העבר שירותים קריטיים לגיבוי קר (דוגמה: rsync ל-VPS אצל ספק אחר).
  4. 4. הכחדה (60-180 דקות):
    • השתמש ב-Autopsy כדי לזהות את וקטור הכניסה (דוגמה: phishing.xls בתיקיית Downloads).
    • הסר את התוכנה הזדונית עם Malwarebytes (גרסה חינמית) או ClamAV.
    • שנה את כל הסיסמאות של החשבונות שנפגעו (השתמש ב-Bitwarden כדי ליצור סיסמאות באורך 24 תווים).

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

אירוע #: [מזהה]
תאריך/שעה: [YYYY-MM-DD HH:MM]
ציוד מושפע: [שם מארח/IP]
פעולות שננקטו:
- [ ] בידוד לוגי (פקודה: _______)
- [ ] לכידת זיכרון (hash SHA256: _______)
- [ ] בידוד פיזי (שעה: _______)
- [ ] הכחדה (כלי: _______)
אחראי: [שם]

תבנית זו, בשילוב עם צילומי מסך מ-Wazuh ו-Velociraptor, מספיקה לדיווח ל-CSIRT הלאומי (דוגמה: CERT.br בברזיל) ולעמידה בתקנות כמו חוק הגנת הפרטיות של מקסיקו (LFPDPPP).

תקשורת עם ה-CSIRT הלאומי: מה לשלוח ומה לעולם לא לחשוף

ה-CSIRT הלאומיים (דוגמה: CSIRT צ'ילה, CERT UNAM) דורשים דיווחים בפורמטים ספציפיים, אך צוותים קטנים רבים אינם יודעים מה לכלול. על פי המדריך של ENISA (2022), זה המינימום הנדרש:

תבנית דיווח ל-CSIRT (דוגמה למקסיקו):

נושא: דיווח אירוע - [סוג] - [שם החברה] - [תאריך]
גוף:
1. פרטי התקשרות:
   - שם החברה: _______
   - איש קשר: _______
   - טלפון: _______
   - דוא"ל: _______

2. פרטי האירוע:
   - תאריך/שעה (UTC): _______
   - סוג (ENISA): [malware/phishing/DDoS/וכו']
   - כתובות IP מושפעות: _______
   - Hashes SHA256: _______
   - וקטור כניסה: _______
   - השפעה: [דוגמה: "שרת אחד נפגע, 500 גיגה-בייט של נתונים מוצפנים"]

3. פעולות שננקטו:
   - [ ] בלימה
   - [ ] הכחדה
   - [ ] התאוששות
   - [ ] הודעה ללקוחות (צרף תבנית בשימוש)

נספחים:
- צילומי מסך מכלי זיהוי (Wazuh, Velociraptor).
- יומנים רלוונטיים (מסוננים כדי לא לחשוף נתונים רגישים).
- Hashes של קבצים זדוניים.

ה-CSIRT עשוי לבקש מידע נוסף, אך דיווח ראשוני זה מספיק כדי להפעיל את תמיכתו. במקרה בארגנטינה (יוני 2023), ה-CSIRT המקומי סיפק אינדיקטורים לפגיעה (IOCs) נוספים שעזרו לזהות וקטור כניסה שני שלא זוהה בתחילה.

הודעה ללקוחות: תבניות העומדות בדרישות הרגולציה מבלי ליצור פאניקה

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

1. אירוע ללא דליפת נתונים (דוגמה: תוכנת כופר ללא הוצאת נתונים)

נושא: הודעה חשובה בנוגע לאירוע אבטחה

לכבוד [שם הלקוח],

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

1. אין ראיות לכך שהנתונים האישיים שלך ניגשו או נפגעו.
2. בלמנו את האירוע ואנו עובדים עם מומחי אבטחת סייבר כדי לשחזר את השירותים שלנו.
3. דיווחנו לרשויות המוסמכות, כולל [ה-CSIRT הלאומי], ואנו פועלים לפי המלצותיהם.

מה אתה יכול לעשות?
- אין צורך לנקוט בפעולה כלשהי בשלב זה.
- אם יש לך שאלות, אתה יכול להשיב לדוא"ל זה או ליצור איתנו קשר בטלפון [מספר טלפון].

אנו מודים על אמונך ונשמור אותך מעודכן בכל התפתחות רלוונטית.

בכבוד רב,
[שם המנכ"ל]
[שם החברה]

2. אירוע עם דליפת נתונים אפשרית (דוגמה: פגיעה במסד נתונים)

נושא: הודעת אירוע אבטחה - [שם החברה]

לכבוד [שם הלקוח],

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

1. האירוע נבלם ואנו עובדים עם מומחי אבטחת סייבר כדי לחקור.
2. דיווחנו לרשויות המוסמכות, כולל [ה-CSIRT הלאומי] ו[רשות הגנת הפרטיות המקומית, דוגמה: INAI במקסיקו].
3. אין ראיות לכך שהמידע נעשה בו שימוש בהונאה.

מה אתה יכול לעשות?
- אנו ממליצים לבדוק את חשבונות הבנק וכרטיסי האשראי שלך לגבי כל פעילות חשודה.
- אם אתה משתמש באותה סיסמה בשירותים אחרים, אנו ממליצים לשנותה.
- אתה יכול ליצור איתנו קשר בטלפון [מספר טלפון] או בדוא"ל [כתובת דוא"ל] אם יש לך שאלות.

מצורף רשימת שאלות נפוצות לעיונך. אנו מודים על הבנתך ונשמור אותך מעודכן בכל התפתחות.

בכבוד רב,
[שם המנכ"ל]
[שם החברה]

---
שאלות נפוצות:
1. איזה מידע נחשף?
   [תשובה ספציפית, דוגמה: "שמך, כתובת דוא"ל ומספר טלפון. סיסמאות ומידע פיננסי לא נחשפו."]

2. מדוע לא הודעתם לי מוקדם יותר?
   [תשובה: "אנו פועלים לפי הנחיות [רגולציה מקומית] המתירה הודעה תוך פרק זמן סביר כדי לא להפריע לחקירה."]

3. מה אתם עושים כדי למנוע אירועים עתידיים?
   [תשובה: "יישמנו [אמצעים ספציפיים, דוגמה: "אימות רב-גורמי בכל המערכות" ו"ניטור 24/7 של הרשתות שלנו"].]

תבניות אלו עומדות בדרישות ההודעה של החוק הפדרלי להגנת נתונים אישיים בידי גורמים פרטיים (LFPDPPP) של מקסיקו, הצו 1377 משנת 2013 של קולומביה, והחוק מספר 29733 של פרו. הנקודה הקריטית היא:

במקרה מתועד ב-CyberShield עם לקוח בצ'ילה (אפריל 2023), השימוש בתבניות אלו הפחית את פניות הלקוחות ב-60% והימנע מתביעה בגין אי-עמידה בחוק מספר 19.628 על הגנת הפרטיות.

תחקיר בדיעבד: כיצד להפוך את האירוע לתוכנית שיפור (בלי להוציא כסף על יועצים)

התחקיר בדיעבד הוא המקום בו רוב הצוותים הקטנים מפספסים את ההזדמנות לשפר. הם עוקבים אחרי מודל "לקחים שנלמדו" כללי ולא מייצרים פעולות קונקרטיות. זו התבנית בה אנו משתמשים ב-CyberShield, המבוססת על NIST SP 800-61 ומותאמת לצוותים קטנים:

תחקיר בדיעבד של אירוע
אירוע #: [מזהה]
תאריך: [YYYY-MM-DD]
צוות: [שמות]

1. כרונולוגיה:
   - [תאריך/שעה] [אירוע] [אחראי]
   - דוגמה: "2023-10-15 09:30 - משתמש מדווח על דוא"ל חשוד עם קובץ מצורף .xls - מריה לופז"
   - דוגמה: "2023-10-15 09:45 - Wazuh מייצר התראה על תהליך חשוד (PID 1234) - חואן פרס"

2. ניתוח סיבת שורש (RCA):
   - וקטור כניסה: [דוגמה: "דוא"ל פישינג עם קובץ מצורף .xls שניצל את CVE-2023-3824"]
   - סיבת שורש: [דוגמה: "חוסר עדכון של PHP בשרת האינטרנט"]
   - בקרות שנכשלו: [דוגמה: "לא היה כלל ב-Wazuh לזיהוי CVE-2023-3824"]

3. מדדי תגובה:
   - זמן זיהוי: [דוגמה: "15 דקות מהשליחה של הדוא"ל"]
   - זמן בלימה: [דוגמה: "45 דקות מההתראה של Wazuh"]
   - זמן התאוששות: [דוגמה: "3 שעות לשחזור מגיבוי"]

4. פעולות מתקנות (עם אחראים ומועדים):
   | פעולה                          | אחראי      | מועד        | סטטוס      |
   |---------------------------------|-------------|-------------|------------|
   | עדכון PHP לגרסה 8.2.11         | חואן פרס    | 2023-10-20  | ממתין      |
   | יצירת כלל ב-Wazuh עבור CVE-2023-3824 | מריה לופז | 2023-10-16  | הושלם      |
   | הדרכת פישינג לעובדים           | משאבי אנוש | 2023-10-25  | ממתין      |

5. המלצות לבדיקה הבאה:
   - [ ] לכלול סימולציית פישינג חודשית.
   - [ ] לבדוק את ספר הפעולות של תוכנת כופר כדי לכלול את CVE-2023-3824.
   - [ ] להעריך הטמעת אימות רב-גורמי בשרת האינטרנט.

התחקיר בדיעבד חייב להיות מסמך חי. ב-CyberShield, אנו בודקים אותו כל 30 יום עם צוות ה-IT ומציגים אותו לוועדת ההנהלה בפורמט מנהלים (עמוד אחד לכל היותר). המפתח טמון ב:

אצל לקוח בפרו (יולי 2023), יישום תבנית זו קיצר את זמן התגובה ב-40% באירוע הבא (מ-5 שעות ל-3 שעות) ואפשר להצדיק בפני ההנהלה העסקת אנליסט אבטחה נוסף.

תגובה לאירועים בצוותים קטנים אינה בעיה של כלים, אלא של תהליך. ספר פעולות המבוסס על NIST SP 800-61, בשילוב עם כלים בקוד פתוח ותבניות שאושרו מראש, יכול לצמצם את השפעת האירוע מ"אסון" ל"תקלה ניתנת לניהול". ההכנה אינה דורשת תקציב עתק, אלא משמעת: עדכון המלאי מדי שבוע, בדיקת ספרי הפעולות מדי חודש, ובדיקת התחקיר בדיעבד כל 30 יום. ב-CyberShield, אנו מספקים שירותי אבטחת סייבר 24