Incident Response האם הארגון שלכם באמת מוכן לאירוע סייבר?

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

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

אירוע סייבר משמעותי כמעט אף פעם אינו נשאר רק במחלקת ה־IT.

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

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

הגישה הזו כבר אינה מספיקה.

NIST חיזק בדיוק את הנקודה הזאת בעדכון המשמעותי של SP 800-61 Revision 3, שפורסם באפריל 2025. במקום להתייחס לתגובה לאירועים כאל תהליך מבודד של צוות אבטחת המידע, NIST משלב Incident Response בתוך מערך ניהול סיכוני הסייבר הכולל של הארגון ובהתאם לשש הפונקציות של Cybersecurity Framework 2.0.

במילים פשוטות:

Incident Response טוב לא מתחיל בזמן האירוע. הוא מתחיל הרבה לפניו.

Incident Response הוא תהליך ארגוני, לא רק טכנולוגי

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

לדוגמה:

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

אלה אינן שאלות של SOC בלבד.

הן מערבות CISO, CIO, הנהלה, Legal, Privacy, HR, תפעול, כספים, תקשורת, ספקים ולעיתים גם דירקטוריון.

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

השעות הראשונות קובעות

בשלבים הראשונים של אירוע קיימת בדרך כלל אי־ודאות רבה.

התראה אחת יכולה להתברר כניסיון שנחסם או כסימן ראשון לכך שתוקף נמצא בסביבה הארגונית כבר זמן רב.

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

תהליך Incident Response אפקטיבי צריך לאפשר לארגון לעבור במהירות בין שש פעילויות:

1. Detection & Triage: להבין האם מדובר באירוע ומה רמת החומרה.
2. Investigation & Scoping: לזהות אילו משתמשים, מערכות, זהויות ומידע מעורבים.
3. Containment: לצמצם את יכולת התוקף להמשיך לפעול בלי לגרום נזק עסקי לא מידתי.
4. Eradication: להסיר את הגורם והגישה שאפשרו את האירוע.
5. Recovery: להחזיר את הפעילות בצורה מבוקרת.
6. Post-Incident Review: להבין מה קרה, מדוע, ומה צריך להשתנות.

מאמר בנושא Incident Response ו-Threat Hunting לאחר Phishing מרחיב בצד החקירתי של התהליך ומדגיש כי עצירת הסימפטום אינה מספיקה, צריך להבין את ה-Scope האמיתי של האירוע.

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

זו אחת הנקודות החשובות ביותר.

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

לדוגמה:

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

כאן Incident Response נפגש עם Crisis Management ו-Business Continuity.

הארגון נדרש לנהל במקביל שני מסלולים:

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

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

Incident Response ו-BCP: שתי תוכניות שחייבות לדבר זו עם זו

תוכנית Incident Response ותוכנית Business Continuity Plan – BCP, אינן אותו דבר.

• Incident Response מתמקדת בניהול אירוע הסייבר.
• BCP מתמקדת בשאלה כיצד הארגון ממשיך לבצע את הפעילויות העסקיות הקריטיות כאשר מערכות, אתרים, אנשים או ספקים אינם זמינים.

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

נניח שמערכת ERP נפגעה.

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

לכן כבר בשגרה קריטי לדעת:

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

Incident Response ללא BCP עלול להצליח מבחינה טכנית ולגרום בכל זאת לנזק עסקי משמעותי.

BCP ללא Incident Response, מנגד, עלול להחזיר ארגון מהר מדי לסביבה שעדיין אינה בטוחה.

ומה לגבי Disaster Recovery?

גם כאן חשוב להבחין.

• BCP עוסק בהמשך הפעילות העסקית.
• Disaster Recovery – DR עוסק בתוכנית החזרת מערכות, תשתיות ומידע לפעילות.

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

צריך לדעת:

• האם הגיבויים זמינים?
• האם הם נקיים?
• האם הם נבדקו לאחרונה?
• באיזה סדר משחזרים מערכות?
• האם קיימות תלויות בין מערכות?
• כמה זמן באמת ייקח תהליך השחזור?

NIST ממשיך להדגיש במסגרת משאבי Ransomware Risk Management את הצורך בחיבור בין מניעה, Response ו-Recovery; ביוני 2026 אף פרסם עדכון ל-Ransomware Risk Management Profile המותאם ל-CSF 2.0.

מידע נוסף במאמר סיכוני כופרה והיערכות ארגונית

תרגיל שולחן – Tabletop Exercise: הדרך לגלות אם הנוהל באמת עובד

אפשר לכתוב תוכנית Incident Response מצוינת על הנייר.

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

כאן נכנס Tabletop Exercise – TTX.

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

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

CISA מפעילה גישה דומה במסגרת Cybersecurity Tabletop Exercise Packages, עם תרחישים בתחומים כגון Ransomware, Phishing, Insider Threat ופגיעה במערכות ICS.

מה צריך להיכנס לתרגיל Tabletop איכותי?

תרגיל טוב לא בודק אם ההנהלה זוכרת את הנהלים בעל־פה.

הוא יוצר מצבים שבהם אין תשובה מושלמת.

למשל:

09:05 – SOC מזהה פעילות חריגה במספר שרתים.

09:30 – מתברר שמערכת עסקית קריטית אינה זמינה.

10:15 – מתקבל מידע שמרמז על גניבת נתונים.

11:00 – לקוח גדול מתקשר ודורש לדעת אם המידע שלו נחשף.

11:30 – ספק מרכזי מדווח שגם הוא חווה אירוע.

12:00 – מתפרסמת ברשת טענה שהארגון נפרץ.

בכל שלב מתעוררות שאלות אחרות.

• מי מנהל את האירוע?
• מי מחליט על השבתה?
• מתי מעדכנים מנכ"ל?
• מתי מערבים Legal ו־Privacy?
• מי מתקשר ללקוחות?
• האם מפעילים BCP?
• מתי מתחילים שחזור?
• מי מאשר הודעה חיצונית?

הערך המרכזי של התרגיל אינו הציון.

הערך הוא הפערים שהוא חושף והיכולת ללמוד וליישם

תרגיל הנהלה אינו תרגיל SOC

אחת הטעויות הנפוצות היא להפוך Tabletop של הנהלה לתרגיל טכני.

• מנכ"ל לא צריך להסביר כיצד מבצעים Isolation ל-Endpoint
• CFO לא צריך לזהות Indicators of Compromise

הנהלה צריכה לתרגל קבלת החלטות.

לדוגמה:

האם ממשיכים להפעיל שירות שקיים לגביו ספק?
מה רמת הסיכון שהארגון מוכן לקבל?
מי מוסמך להשבית פעילות עסקית?
כמה מידע מפרסמים כאשר התמונה עדיין חלקית?
כיצד מתמודדים עם לחץ של לקוחות?
מה עושים אם המשבר נמשך 24, 48 או 72 שעות?

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

תרחישי Tabletop שכדאי לארגונים לתרגל

אין צורך לתרגל רק "פריצה".

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

כופרה

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

דליפת מידע

מידע אישי או עסקי מופיע מחוץ לארגון, אך היקף האירוע אינו ברור.

Phishing וגניבת זהות

Account Takeover שמתפתח לתנועה רוחבית ולגישה לשירותי Cloud.

ספק או שרשרת אספקה

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

Cloud Outage או Compromise

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

אירוע Cyber + Influence

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

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

מי צריך להשתתף בתרגיל?

התשובה תלויה בארגון ובתרחיש, אבל תרגיל הנהלה טיפוסי עשוי לכלול:

• מנכ"ל או נציג הנהלה בכירה.
• CIO / CTO.
• CISO או מנהל אבטחת מידע.
• IT ותשתיות.
• SOC / Incident Response.
• Legal.
• DPO / Privacy.
• HR.
• תפעול.
• Finance.
• דוברות / Marketing / Communications.
• BCP / Business Continuity.
• ולעיתים ספקים מרכזיים.

בחלק מהתרגילים כדאי לשלב גם את חברת ה-Incident Response החיצונית או ספק ה־SOC כדי לבחון כיצד עובד ממשק ההסלמה בפועל.

אל תשכחו את הספקים

אירוע אמיתי אינו מכבד גבולות ארגוניים.

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

לכן Incident Response Plan צריך לכלול מראש:

• רשימת אנשי קשר מעודכנת
• SLA והתחייבויות
• מנגנון הסלמה
• סמכויות וגישה למערכות
• ערוצי תקשורת חלופיים
• תהליך לאישור פעולות רגישות

המאמר שלנו על כלכלת הכופרה אף ממחיש מדוע Due Diligence על גורמי Incident Response ומו"מ חשוב במיוחד: אירועי אכיפה בארה"ב ב־2026 חשפו מקרים חריגים שבהם אנשי מקצוע מתוך התעשייה ניצלו את האמון והגישה שניתנו להם ופעלו לצד תוקפים.

מתי Incident Response הופך לאירוע Privacy ורגולציה?

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

צריך להבין:

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

הזמן שבו צריך לברר מי ה־DPO או היועץ המשפטי אינו במהלך האירוע.

הם צריכים להיות חלק מתהליך ההסלמה כבר מראש.

התקשורת בזמן משבר היא חלק מ-Incident Response

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

ארגון צריך לדעת מראש:

מי מוסמך לדבר בשם החברה?
כיצד מעדכנים עובדים?
איך מתקשרים אם מערכות הדואר אינן זמינות?
מי מאשר הודעה ללקוחות?
כיצד מונעים מצב שבו מחלקות שונות מוסרות מידע סותר?

תרגיל Tabletop הוא הזדמנות לבדוק גם את התרחיש הזה.

לא רק "מה נעשה למערכת", אלא מה נאמר לאנשים.

אחרי האירוע: השלב שהכי קל לדלג עליו

כאשר המערכות חוזרות לפעילות, הלחץ יורד והארגון רוצה לחזור לשגרה.

דווקא אז צריך לבצע Post-Incident Review.

לא כדי לחפש אשמים.

אלא כדי להבין:

• מה עבד?
• מה לא עבד?
• אילו החלטות התעכבו?
• אילו הרשאות היו חסרות?
• איזה ספק לא הגיב בזמן?
• איזה מידע לא היה זמין להנהלה?
• האם ה־BCP באמת עבד?
• כמה זמן לקח השחזור לעומת היעד?
• מה צריך להשתנות?

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

איך יודעים אם הארגון באמת מוכן?

אפשר להתחיל מכמה שאלות פשוטות:

1. האם קיימת תוכנית Incident Response עדכנית?
2. האם בעלי התפקידים יודעים שהם חלק ממנה?
3. האם מוגדר מי מוסמך להכריז על אירוע משמעותי?
4. האם קיימים אנשי קשר זמינים 24/7 לספקים קריטיים?
5. האם תוכנית ה־IR מחוברת ל־BCP ול־DR?
6. האם ההנהלה תרגלה אירוע בשנה האחרונה?
7. האם נבדקו תרחישים של ספקים, כופרה ודלף מידע?
8. האם קיימים ערוצי תקשורת חלופיים?
9. והאם בעקבות התרגיל הקודם בוצעו בפועל פעולות תיקון?

אם התשובה לחלק מהשאלות היא "לא יודעים", זה בפני עצמו ממצא חשוב.

ממסמך Incident Response ליכולת ארגונית

אי אפשר למנוע כל אירוע סייבר.

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

ארגון שמכיר את הנכסים הקריטיים שלו, מגדיר מראש סמכויות, מחבר בין Incident Response, BCP ו־DR ומתרגל את ההנהלה נמצא בעמדה שונה לחלוטין מארגון שמתחיל לבנות את תהליך קבלת ההחלטות בזמן שהמערכות כבר מושבתות.

וזה ההבדל בין נוהל Incident Response לבין Cyber Resilience אמיתי.

Incident Response אפקטיבי אינו מסתכם בזיהוי התקיפה ובהחזרת השרתים לפעולה.

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

מקורות

• NIST, SP 800-61 Rev. 3 – Incident Response Recommendations and Considerations for Cybersecurity Risk Management, אפריל 2025.
• NIST, הודעת פרסום SP 800-61r3 והטמעת Incident Response בכלל פעילויות ניהול סיכוני הסייבר, 3.4.2025.
• NIST, Ransomware Risk Management: A Cybersecurity Framework 2.0 Community Profile, עדכון יוני 2026.
• CISA, Cybersecurity Tabletop Exercise Packages – Cybersecurity Scenarios, הכוללים תרחישי Ransomware, Phishing, Insider Threat ו־ICS.
• CISA, #StopRansomware Guide – המלצה על תרגילי סייבר כחלק מהערכת ופיתוח תוכנית Incident Response.
• מערך הסייבר הלאומי, מדריך לתרגול בסייבר – הגדרת תרגיל שולחני (TTX) ומתודולוגיית תרגול.
• רשות החירום הלאומית, הנחיות להיערכות וניהול משבר סייבר בארגון, לרבות הקמת צוות הנהלה, הפעלת תוכנית ותיעוד.
• בנק ישראל – הפיקוח על הבנקים, תרגיל סייבר מערכתי במתכונת TTX לבחינת היערכות טכנולוגית, ארגונית ותהליכית, 13.11.2025.

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

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

המאמר נכתב בשיתוף מומחי אבטחת המידע והסייבר של Infoguard מקבוצת IDOR, ונערך על ידי ROY KISCH, חובב פרטיות,אבטחת מידע, סייבר ומנהל שיווק בקבוצת חברות עידור (Messagenet, Infoguard, Idornext).