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

מדוע NIST SP 800-61 הוא בעל בריתך הטוב ביותר (וכיצד להתאימו לצוות של 3 אנשים)

ה-NIST Special Publication 800-61 Revision 2 מגדיר ארבעה שלבים בתגובה לאירועים: הכנה, זיהוי/ניתוח, בלימה/הכחדה/התאוששות, ופעילויות לאחר האירוע. עבור צוות IT קטן, האתגר אינו בהבנת המסגרת, אלא ביישומה עם משאבים מוגבלים. הספרות הקיימת מצביעה על כך ש-68% מהעסקים הקטנים והבינוניים חסרים תוכנית תגובה פורמלית (ENISA, 2022), אך מה שבאמת נכשל הוא ההתאמה לקנה מידה.

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

פרט קריטי: NIST 800-61 מניח שיש לכם SIEM. בעסק קטן ובינוני זה בלתי אפשרי. האלטרנטיבה היא לרכז יומנים עם Elasticsearch (קוד פתוח) ולהגדיר התראות בסיסיות. לדוגמה, אם משתמש מנסה לגשת לקובץ עם \\company\finanzas\ מכתובת IP מחוץ למשרד, ייווצר התראה. זה לא מושלם, אבל עדיף מכלום.

זיהוי: כיצד להבחין בין התראה שגויה למתקפה אמיתית (מבלי להיות אנליסט SOC)

90% מההתראות הן רעש (Gartner, 2023), אך בעסק קטן ובינוני, כל התראה גוזלת זמן יקר. הכלל שאנו מיישמים ב-CyberShield הוא: אם להתראה אין הקשר, התעלמו ממנה עד שיהיה לה. לדוגמה:

מקרה קונקרטי: בעסק קטן ובינוני בתחום הקמעונאות במקסיקו, צוות ה-IT קיבל התראה על "תעבורה חשודה" בשעה 2 לפנות בוקר. חומת האש דיווחה על חיבורים לשרת ברוסיה. האינסטינקט הראשוני היה לבודד את המחשב, אך בבדיקת היומנים, הם הבינו שמדובר בתוכנת ניהול מלאי (לגיטימית) המסנכרנת נתונים עם ספק. הלקח: לפני שפועלים, ודאו את התהליך שיוצר את התעבורה. כלי מפתח: Process Activity View עבור Windows.

בלימה: כיצד לבודד מחשב מבלי לפגוע בפרודוקטיביות (ומבלי שיפטרו אתכם)

שלב הבלימה הוא המקום שבו רוב הצוותים הקטנים טועים. או שהם מבודדים יותר מדי (ומשתקים את העסק) או שהם מבודדים מעט מדי (והמתקפה מתפשטת). המדריך של ENISA (Good Practice Guide for Incident Management) ממליץ על אסטרטגיית "בלימה הדרגתית":

  1. בלימה מיידית: נתקו את המחשב מהרשת (כבל ו-WiFi). אם מדובר בשרת קריטי, השתמשו בחומת האש כדי לחסום את כל התעבורה למעט זו החיונית (לדוגמה: אפשרו חיבורים רק מכתובות IP של המשרד).
  2. בלימה לטווח בינוני: אם המתקפה היא כופר, זיהו את וקטור הכניסה (דיוג, RDP חשוף, פגיעות בשירות). אם מדובר בדיוג, שנו את הסיסמאות של כל המשתמשים שקיבלו את המייל. אם מדובר ב-RDP, השביתו אותו והשתמשו ב-VPN עם MFA.
  3. בלימה לטווח ארוך: אם המתקפה ניצלה פגיעות ידועה (לדוגמה: CVE-2023-23397 ב-Exchange), החליפו את התיקון וודאו שאין מחשבים נוספים מושפעים. כלי שימושי: Trivy לסריקת פגיעויות במערכות ובמכולות.

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

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

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

באמריקה הלטינית, חוקי הגנת המידע משתנים ממדינה למדינה, אך ישנם עקרונות משותפים. לדוגמה, במקסיקו (LFPDPPP), קולומביה (חוק 1581) וארגנטינה (חוק 25.326), עליכם להודיע לנפגעים אם קיים סיכון משמעותי לנתוניהם. אך מהו "סיכון משמעותי"? הספרות מציעה שאם המתקפה חשפה נתונים רגישים (לדוגמה: מספרי כרטיסי אשראי, היסטוריות רפואיות), ההודעה היא חובה. אם נחשפו רק שמות וכתובות דוא"ל, לא.

תבנית להודעה ללקוחות (ניתנת להתאמה לכל מדינה):

"לכבוד/ה [לקוח/ה],

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

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

למידע נוסף, ניתן לפנות אלינו בכתובת [דוא"ל/טלפון]. אנו מודים על אמונכם ומתנצלים על כל אי-נוחות.

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

מה לא לכלול בהודעה:

מקרה ציבורי: ב-2022, עסק קטן ובינוני בתחום המסחר האלקטרוני בברזיל הודיע ללקוחותיו על מתקפה, אך כלל פרטים טכניים שהתוקפים השתמשו בהם כדי לסחוט אותם לאחר מכן. הלקח: ההודעה צריכה להיות שקופה אך מינימליסטית. אם אתם זקוקים לעזרה בכתיבתה, ה-CSIRT של מדינתכם יכול לבדוק אותה. לדוגמה, במקסיקו יש את CSIRT-MX, בקולומביה את ColCERT, ובארגנטינה את CERT.ar.

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

התחקיר בדיעבד הוא השלב המוזנח ביותר בעסקים קטנים ובינוניים. צוות ה-IT מותש, ההנהלה רוצה "לחזור לשגרה", ואיש אינו מעוניין לתעד. אך זהו השלב שבו נמנעים אירועים עתידיים. NIST 800-61 ממליץ על דוח המכיל:

תבנית לתחקיר בדיעבד (קוד פתוח, ניתנת להתאמה): Netflix Security Monkey Incident Response Template. פרט קריטי: התחקיר בדיעבד חייב להיות ללא שמות. המטרה אינה להצביע על עובד, אלא לשפר את התהליך.

ב-CyberShield אימתנו כי עסקים קטנים ובינוניים המבצעים תחקירים בדיעבד מפחיתים ב-40% את האירועים החוזרים. אך יש טריק: התחקיר בדיעבד חייב להיות קצר. אם הדוח ארוך מ-5 עמודים, איש לא יקרא אותו. התמקדו בעיקר: מה קרה, מדוע קרה, ומה נעשה כדי למנוע הישנות.

כלים בקוד פתוח המחליפים SOC (ומתאימים לתקציב של עסק קטן ובינוני)

מרכז פעולות אבטחה (SOC) עולה בין 5,000 ל-50,000 דולר לחודש. עבור עסק קטן ובינוני, זה בלתי אפשרי. אך ישנן חלופות בקוד פתוח המכסות 80% מהצרכים:

כלי שימוש חלופה מסחרית
Elasticsearch + Kibana ריכוז יומנים ויצירת התראות Splunk, IBM QRadar
TheHive ניהול אירועים (כרטיסים, ציר זמן) ServiceNow, Jira
Sigma כללי זיהוי (לדוגמה: "זיהוי brute force ב-RDP") MITRE ATT&CK Navigator
Velociraptor חקירה משפטית במחשבים (לדוגמה: "אילו תהליכים רצו במחשב X בשעה 3 לפנות בוקר?") CrowdStrike, SentinelOne
Gophish סימולציה של דיוג להכשרת משתמשים KnowBe4, Proofpoint

דוגמה קונקרטית: בעסק קטן ובינוני בתחום הבריאות בפרו, הטמענו Elasticsearch + Sigma לזיהוי מתקפות. הגדרנו כלל שמתריע אם יש יותר מ-5 ניסיונות כניסה כושלים במחשב תוך 10 דקות. כאשר תוקף ניסה brute force בשרת RDP, צוות ה-IT קיבל התראה ב-Slack ובידד את המחשב תוך 15 דקות. עלות כוללת: 0 דולר (רק זמן תצורה).

אזהרה: כלים אלה דורשים ידע טכני. אם לצוות ה-IT שלכם אין ניסיון באבטחת סייבר, שכרו יועץ להגדרתם. ב-CyberShield אנו מספקים שירותי אבטחת סייבר 24/7 לעסקים קטנים ובינוניים באמריקה הלטינית עם מערכת משלנו: סוכן endpoint רב-מערכתי, ניטור CVE בזמן אמת ותגובה 24/7. התוכנית הבסיסית עולה 10 דולר לחודש עבור 2 מחשבים, אך אם אתם מעדיפים לעשות זאת בעצמכם, הכלים בקוד פתוח הם נקודת התחלה טובה.

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

מקורות

  1. NIST Special Publication 800-61 Revision 2 (2012). Computer Security Incident Handling Guide. https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final
  2. ENISA (2022). Good Practice Guide for Incident Management. https://www.enisa.europa.eu/publications/good-practice-guide-for-incident-management
  3. Gartner (2023). Market Guide for Security Orchestration, Automation and Response Solutions. ID G00765420.
  4. CSIRT-MX (2023). Guía de Notificación de Incidentes de Seguridad. https://www.gob.mx/csirtmx/documentos/guia-de-notificacion-de-incidentes-de-seguridad
  5. ColCERT (2023). Protocolo de Respuesta a Incidentes de Seguridad. https://www.colcert.gov.co/protocolos
  6. CERT.ar (2023). Recomendaciones para la Gestión de Incidentes de Seguridad. https://www.argentina.gob.ar/aaip/cert/recomendaciones
  7. Netflix (2020). Security Monkey Incident Response Template. https://github.com/netflix/security-monkey/blob/master/docs/incident-response-template.md
  8. MITRE (2023). ATT&CK Framework. https://attack.mitre.org/
  9. מקרה ציבורי: עסק קטן ובינוני בתחום המסחר האלקטרוני בברזיל (2022). הודעת אירוע מנוהלת בצורה לקויה. מקור: TecMundo.
  10. ENISA (2022). Threat Landscape for Supply Chain Attacks. https://www.enisa.europa.eu/publications/threat-landscape-for-supply-chain-attacks