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

תגובה לאירוע סייבר: מה עושים בדקות הראשונות אחרי מתקפה (ולמה זה מרגיש כמו אזעקת שווא – עד שזה לא)

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

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

אם עושים נכון – אפשר להפוך כאוס ל״סיפור שנגמר טוב״.

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

0-10 דקות: ״זה באמת קורה או שמישהו סתם לחץ על משהו?״

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

לא מחפשים את האשם.

לא כותבים פוסט בלינקדאין.

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

דבר ראשון – להכריז ״אירוע״ (כן, גם אם אתם עוד לא בטוחים)

יש הבדל ענק בין ״משהו מוזר״ לבין אירוע שמטופל עם פוקוס.

ברגע שקוראים לזה אירוע, קורה קסם קטן: יש בעלות, יש סדר, ויש תיעוד.

גם אם יתברר שזה false positive – הרווחתם תרגול.

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

שאלת הבונוס ששווה זהב: מה בדיוק ראיתם?

״הכול איטי״ זה תיאור רגשי. הוא לא לוג.

נסו לאסוף עובדות קטנות ומהירות:

מי זיהה ראשון, באיזה ערוץ, ובאיזו שעה?
איזה סימן היה – התראה, קובץ כופר, התחברות חשודה, פעילות לא רגילה?
מה השתנה מאז אתמול – דיפלוי, הרשאות, ספק חדש, עדכון?

10-30 דקות: לעצור התפשטות בלי ״לשרוף את המקום״

בשלב הזה אתם רוצים לצמצם נזק.

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

זה לפעמים מציל.

ולפעמים זה משמיד ראיות, מפיל שירותים קריטיים, ומקשה להבין מה קרה.

3 פעולות שמצטלמות טוב – אבל צריך לעשות אותן חכם

הנה הדברים שכמעט תמיד רלוונטיים, רק עם שיקול דעת:

בידוד תחנות או שרתים חשודים – עדיף דרך רשת, EDR, או VLAN, ולא כיבוי קשוח אם לא חייב.
עצירת חשבונות בסיכון – משתמשים עם התחברות חריגה, חשבונות אדמין, מפתחות API שנראים דלופים.
חסימת תקשורת החוצה – דומיינים חשודים, IPs בעייתיים, תעבורה חריגה. נקודתי ולא ״לנתק אינטרנט לכל המדינה״.

תיעוד מהיר לפני שמשנים משהו

כל שינוי מפריע לחקירה.

אבל לא תמיד יש זמן.

אז עושים את המינימום שייתן מקסימום:

צילום מסך של הודעת כופר או חלון חריג.
שמירת לוגים זמינים: EDR, VPN, IAM, firewall, proxy, cloud audit.
רשימת מכונות/חשבונות שהושפעו – אפילו חלקית.

30-60 דקות: להבין מה סוג האירוע – ואז לבחור אסטרטגיה

תגובה טובה לאירוע לא מתחילה עם פתרון.

היא מתחילה עם סיווג.

כי תגובה לאירוע כופר שונה מתגובה לדליפת נתונים, ושונה ממתקפת BEC במייל.

אם תטפלו במשהו אחד כאילו הוא משהו אחר – תבזבזו זמן יקר.

5 סוגי מתקפות שכדאי לזהות מהר (עם סימנים פשוטים)

כופרה – קבצים מוצפנים, סיומות מוזרות, פתק כופר, תהליכים לא מוכרים שרצים.
גניבת זהויות והרשאות – התחברויות ממדינות לא צפויות, refresh tokens, יצירת MFA מחדש, שינויים ב-SSO.
דליפת מידע – תעבורה חריגה החוצה, העלאות גדולות, גישה לא שגרתית לדאטה רגיש.
מתקפת מייל (BEC) – שינוי פרטי תשלום, בקשות דחופות, כל מיני ״רק תעביר עכשיו״.
פגיעה בשרתים ציבוריים – webshell, תעבורה מוזרה ל-API, spikes בלוגי nginx/ALB.

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

האם אתם במצב של הכלה או השבתה?

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

השבתה: עוצרים פעילות כדי למנוע נזק גדול יותר.

אין תשובה אחת נכונה.

יש תשובה שמתאימה לסיכון ולמצב.

60-120 דקות: תקשורת חכמה – כי ״שקט״ זו גם החלטה

הטעות הנפוצה: או שמספרים לכולם הכול (כולל שמועות), או שלא מספרים כלום ואז כולם ממציאים.

המטרה: תקשורת קצרה, מדויקת, מרגיעה, עם מה שיודעים ומה שעושים עכשיו.

מי צריך לדעת – ובאיזה פורמט?

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

תבנית הודעה פנימית שעובדת (ומפחיתה לחץ)

מה קרה: זוהתה פעילות חשודה במערכת X.

מה עושים עכשיו: בידוד רכיבים רלוונטיים ואיסוף נתונים.

מה ההשפעה: ייתכנו שיבושים נקודתיים בשירות Y.

מה לא עושים: לא מבצעים שינויים במערכות Z בלי אישור צוות האירוע.

עדכון הבא: בעוד 30-60 דקות.

החלק שאנשים שוכחים: ראיות, שרשרת אחזקה, והיכולת לשחזר את הסיפור

גם אם אתם לא בעולם משפטי, ראיות זה נכס.

הן עוזרות להבין מה קרה.

הן עוזרות למנוע פעם הבאה.

והן עוזרות לדבר בביטחון מול גורמים פנימיים וחיצוניים.

מה לשמור כבר עכשיו (במינימום מאמץ)

רשימת חשבונות שנגעו בהם, ושינויים בהרשאות.
דגימות: קבצים חשודים, hash, שמות תהליכים.
תיעוד זמני: timestamps של התראות ושל פעולות שביצעתם.
תצורת רשת רלוונטית: חוקים, exceptions, NAT, VPN.

מה לא לעשות אם אתם רוצים לישון בשקט

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

שאלות ותשובות קצרות (כי ברור שיש)

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

תשובה: לפעמים, אבל זה פטיש של 5 קילו. עדיף להתחיל בחסימות ובידודים נקודתיים, ורק אם רואים התפשטות מהירה – לשקול ניתוק רחב.

שאלה: לכבות שרת שנראה נגוע?

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

שאלה: מה ההבדל בין ״הכלה״ ל״מיגור״?

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

שאלה: מתי מודיעים ללקוחות?

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

שאלה: האם ״גיבויים יש״ אומר שאנחנו רגועים?

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

שאלה: מי אמור להחליט על צעדים קיצוניים?

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

הדקות שאחרי: לבנות תוכנית פעולה ל-24 השעות הקרובות

אחרי שייצבתם, צריך לעבור מ״כיבוי שריפות״ ל״עבודה מסודרת״.

זה השלב שבו מגדירים יעדים קצרי טווח ומודדים התקדמות.

רשימת משימות שעושה סדר בראש (ובמערכות)

מיפוי היקף – אילו מערכות, אילו משתמשים, אילו נתיבים.
ציד אינדיקטורים – IOCs, דפוסי התחברות, תעבורה חריגה, persistence.
איפוס סודות – סיסמאות אדמין, מפתחות API, סשנים, טוקנים, SSH keys.
קשיחות מיידית – MFA חזק, חסימת פרוטוקולים מיותרים, סגירת גישות חיצוניות.
שחזור בשלבים – קודם שירותים קריטיים, אחר כך שאר המערכת, עם ניטור צמוד.
בדיקות – אימות שהמערכת נקייה, לא רק ״עובדת״.

טריק קטן שמונע חזרה לאותו בור

כל רכיב שחזר – חוזר עם ניטור חזק יותר ממה שהיה לפני.

אחרת אתם מחזירים את הבית למקום, ומשאירים את החלון פתוח.

איך הופכים אירוע ליתרון קטן (כן, זה אפשרי)

אירוע סייבר הוא לא חגיגה.

אבל הוא גם לא סוף העולם.

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

3 שדרוגים שמומלץ לעשות מיד אחרי שהאבק שוקע

Runbooks אמיתיים – לא מסמך ״ליום אחד״, אלא צעדים שעובדים בזמן אמת.
תרגול חודשי קצר – 30 דקות. תרחיש קטן. שריר נשאר חם.
הפרדת הרשאות – פחות אדמינים, יותר עקרון least privilege, והרבה פחות ״לכולם הכול״.

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

בסוף, תגובה טובה לאירוע סייבר נראית מבחוץ כמו קסם.

בפנים זה פשוט משמעת: לזהות, לייצב, להכיל, לתעד, ולשחזר בלי להילחץ.

הדקות הראשונות הן הכי רועשות, אבל גם הכי משמעותיות.

ואם תיקחו מהמאמר הזה דבר אחד – שיהיה זה: עדיף החלטה סבירה עכשיו, מאשר החלטה מושלמת בעוד שעתיים.