NIST SP 800-61 – Incident Response – היערכות, זיהוי, תגובה והתאוששות מאירועי סייבר.

באפריל 2025 פרסם NIST את SP 800-61 Revision 3, המחליף את Revision 2 משנת 2012. השינוי המשמעותי אינו רק עדכון של שלבי הטיפול באירוע, אלא מעבר מתפיסה של Incident Handling לתפיסה רחבה יותר של Incident Response כחלק מניהול סיכוני הסייבר הארגוני.

עבור ארגונים, זהו שינוי שצריך להשפיע לא רק על נוהל ה-IR, אלא גם על הדרך שבה הנהלה, CISO, IT, פרטיות, BCP וספקים נערכים לאירוע.

מה בעצם השתנה ב-SP 800-61 Rev. 3?

SP 800-61 Rev. 2 נשא את השם Computer Security Incident Handling Guide והתמקד במידה רבה בניהול ובטיפול באירוע לאחר שהתרחש.

Revision 3 נושא שם שונה ומכוון יותר:
Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile.

השם עצמו כבר מספר את הסיפור.

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

במילים אחרות:

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

מידע נוסף על NIST Ransomware Risk Management: כך נערכים לכופרה

כל שש פונקציות NIST CSF 2.0 נכנסות לתמונה

אחד השינויים החשובים ב-Revision 3 הוא החיבור הישיר ל-NIST Cybersecurity Framework 2.0.

CSF 2.0 בנוי סביב שש פונקציות:

Govern, Identify, Protect, Detect, Respond ו-Recover.

NIST מדגיש שכל שש הפונקציות ממלאות תפקיד ב-Incident Response, ולא רק Detect ו-Respond. פעילויות Govern, Identify ו-Protect עוזרות לארגון למנוע אירועים ולהיערך אליהם, בעוד Detect, Respond ו-Recover מסייעות לגלות, לנהל ולהתאושש מהם.

זו נקודה משמעותית במיוחד עבור הנהלות.

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

Governance לפני Response

התוספת של פונקציית Govern ב-CSF 2.0 היא אחת ההתפתחויות המשמעותיות ביותר במסגרת החדשה.

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

מבחינת Incident Response, המשמעות פרקטית מאוד.

עוד לפני האירוע צריך לדעת:

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

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

מידע נוסף על שירות CISO as a Service – מנהל אבטחת מידע כשירות מקצועי של אינפוגארד וסקרי סיכוני אבטחת מידע.

Incident Response ו-BCP חייבים להתחבר

Revision 3 גם מחזק תפיסה חשובה נוספת: Response ו-Recovery הם חלק מאותו מחזור ניהול סיכון.

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

כאן נוצר החיבור בין:

• Incident Response: ניהול ותגובה לאירוע סייבר ואבטחת מידע והשלכותיו
• Business Continuity – BCP: תוכנית המשכיות עסקית
• Disaster Recovery – DR: שחזור מערכות, מידע ותשתיות.

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

לכן תהליך טוב דורש מראש הבנה של סדרי עדיפויות, RTO/RPO, תלויות בין מערכות ודרכי עבודה חלופיות.

קישור פנימי מומלץ: המאמר המרכזי בנושא Incident Response, תרגילי הנהלה, BCP ו-DR.

גם ספקים הם חלק מה-Incident Response

ספקי ענן, SOC, שירותי IT, Forensics, ייעוץ משפטי וחברות Incident Response יכולים להפוך לחלק קריטי מהאירוע בתוך דקות.

CSF 2.0 מדגיש במיוחד את ניהול סיכוני שרשרת האספקה כחלק מה-Governance, ו-SP 800-61 Rev. 3 משלב את התגובה לאירועים בתוך אותה תפיסת ניהול סיכונים כוללת.

לכן תוכנית IR צריכה לכלול גם:

• אנשי קשר של ספקים קריטיים.
• SLA והליכי הסלמה.
• הרשאות וגישה למערכות.
• תהליך אישור לפעולות רגישות.
• ערוצי תקשורת חלופיים.
• ותהליך Due Diligence לגורמים חיצוניים.

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

הפקת לקחים אינה שלב אופציונלי

אחד המסרים החשובים בגישה החדשה של NIST הוא שאירוע אינו מסתיים כאשר המערכות חזרו לעבוד.

הלקחים צריכים לחזור אל תוך תהליך ניהול הסיכונים.

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

לכן Post-Incident Review צריך להוביל לעדכון של:

• סקר הסיכונים.
• בקרות.
• נהלים.
• ארכיטקטורה.
• הדרכות.
• תוכנית BCP/DR.
• חוזים עם ספקים.
• ותוכנית העבודה של הנהלת הסייבר.

זו הדרך להפוך Incident Response מתהליך תגובתי למנגנון שמחזק את רמת ההגנה לאורך זמן.

איך תרגילי Tabletop מתחברים ל-SP 800-61 Rev. 3?

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

אם Incident Response תלוי ב-Governance, תפקידים, Recovery ופעילות רוחבית. אי אפשר לבדוק אותו רק באמצעות סימולציה טכנית של SOC.

צריך לתרגל גם את ההנהלה.

תרגיל Tabletop טוב יכול לבדוק:

1. מי מקבל החלטה?
2. האם מפעילים BCP?
3. מה עושים כאשר המידע חלקי?
4. מתי מעדכנים לקוחות?
5. מי מדבר עם הרגולטור?
6. מה קורה אם ספק מרכזי אינו זמין?
7. וכיצד מקבלים החלטה כאשר הצוות הטכני והצוות העסקי ממליצים על פעולות שונות?

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

מידע נוסף על Tabletop Exercise ותרגילי מוכנות לאירוע סייבר.

מה ארגונים צריכים לעשות בעקבות Revision 3?

אין צורך להחליף מיד את כל מערך ה-Incident Response, אבל בהחלט כדאי לבצע Gap Analysis.

הבדיקה צריכה לשאול:

1. האם תוכנית ה-IR מחוברת לתהליך ניהול הסיכונים הארגוני?
2. האם קיימת בעלות ניהולית ברורה על התהליך?
3. האם BCP ו-DR מחוברים ל-Incident Response?
4. האם תפקידי Legal, Privacy, HR והנהלה מוגדרים?
5. האם ספקים וצדדים שלישיים נכללים בתוכנית?
6. האם הארגון מבצע תרגילי Tabletop?
7. האם Lessons Learned מאירועים ותרגילים באמת מתורגמים לתוכנית עבודה?

אם התשובה לכמה מהשאלות האלה היא "לא", אז Revision 3 מספק סיבה טובה לפתוח מחדש את תוכנית ה-Incident Response.

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

המשמעות המרכזית של SP 800-61 Rev. 3 היא לא שינוי של מונח כזה או אחר.

השינוי הוא בתפיסה.

NIST עובר מ-Incident Handling כתהליך שמופעל לאחר שהתקיפה כבר התרחשה, אל Incident Response כחלק בלתי נפרד מ-Cybersecurity Risk Management.

עבור ארגונים, זה אומר שמוכנות לאירוע נמדדת פחות בשאלה "האם יש לנו נוהל?" ויותר בשאלות:

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

איפה אנחנו באינפוגארד יכולים לסייע?

אינפוגארד מסייעת לארגונים לבחון את רמת המוכנות שלהם לאירועי סייבר באמצעות סקרי סיכונים, Gap Analysis, סקירת נהלי Incident Response, בחינת BCP ו-DRP, הגדרת תפקידים וסמכויות ותרגילי הנהלה ו-Tabletop Exercise.

הבחינה יכולה להתבצע גם מול העקרונות המעודכנים של NIST SP 800-61 Rev. 3 ו-CSF 2.0, במטרה לזהות פערים בין המסמכים הקיימים לבין היכולת הארגונית בפועל.

המטרה אינה רק לעמוד במסגרת מקצועית.

המטרה היא שהארגון יהיה מסוגל לנהל את האירוע הבא כאשר הוא באמת יתרחש.

Incident Response הוא אירוע אסטרטגי להנהלת הארגון

NIST SP 800-61 Rev. 3 משנה את Incident Response מתהליך טכני מבודד לחלק אינטגרלי מניהול סיכוני הסייבר הארגוני.
Governance, המשכיות עסקית, התאוששות, ספקים והפקת לקחים הם חלק בלתי נפרד מהמוכנות.
עבור ארגונים, זו הזדמנות לבחון מחדש את תוכנית ה-IR, לחבר אותה ל-BCP ול-DR ולתרגל את ההנהלה באמצעות Tabletop Exercise.
בסופו של דבר, השאלה אינה רק האם הארגון יודע להגיב לתקיפה, אלא האם הוא מסוגל להמשיך לקבל החלטות ולתפקד בזמן שהיא מתרחשת.

מאחלים לכם שלא תצטרכו להתמודד עם Incident Response
ואם אתם רוצים להיות מוכנים, דברו עם המומחים שלנו לייעוץ ראשוני

מקורות

• NIST, SP 800-61 Rev. 3 – Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile, אפריל 2025.
• NIST, NIST Revises SP 800-61: Incident Response Recommendations and Considerations for Cybersecurity Risk Management, 3.4.2025.
• NIST, The NIST Cybersecurity Framework (CSF) 2.0, פברואר 2024.
• NIST, Cybersecurity Framework 2.0 – Resource & Overview Guide.

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

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

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