מדוע מוכנות ה-MSP לאירועים שבורה בשנת 2025
מנהלי שירותים רבים עדיין מתייחסים לתגובה לאירועים כאלתור ולא ליכולת מתועדת וניתנת לחזרה, שהם יכולים להוכיח תחת פיקוח רציני. כאשר היסטוריית האירועים שלכם מוצגת בצילומי מסך, בשרשורי צ'אט ובפניות חצי-גמורות, אינכם יכולים להראות שאתם מתכננים, שולטים ובודקים אירועים באופן עקבי. פער זה הופך לגלוי לעין כאשר לקוח, חברת ביטוח או רואה חשבון מבקשים ציר זמן ברור, החלטות בעלות שם וראיות לכך שעמדתם בציפיות החוזיות והרגולטוריות.
אירועים כמעט ולא נכשלים בגלל טכנולוגיה; הם נכשלים משום שההכנה והאחריות מעולם לא הובהרו.
בסקר ISMS.online שלנו לשנת 2025 על מצב אבטחת המידע, רק כאחד מכל חמישה ארגונים אמר שלא חווה אובדן נתונים בשנה הקודמת.
כאוס תפעולי בטיפול יומיומי באירועים
כאוס תפעולי נוצר כאשר זרימת העבודה של האירועים מתפתחת סביב אנשים וכלים, ולא סביב עיצוב מכוון ומתועד שכולם מבינים. אירועי אבטחה רגילים יכולים להיראות ניתנים לניהול, אך אירוע אבטחה בעל השפעה גבוהה חושף פערים בבעלות, בסדרי עדיפויות ובתקשורת שתמיד היו שם אך מעולם לא נבדקו תחת לחץ אמיתי.
בעיות אירועי MSP נופלות לעיתים קרובות לדפוס מוכר:
- בעלות מקוטעת: – ניטור, בלימה ועדכוני לקוחות נמצאים בצוותים שונים, ללא בעלים אחראי אחד.
- כאוס כרטיסים: – אירועי אבטחה חולקים תורים עם תקלות שגרתיות, תוך שימוש בקטגוריות מאולתרות וסדרי עדיפויות לא עקביים.
- סחף חוזה: – הסכמי רמת שירות ולוחות זמנים של אבטחה מבטיחים דפוסי תגובה שהפרקטיקה היומיומית שלכם כבר לא משקפים.
- בלבול בין דיירים מרובים: – פלטפורמות משותפות מייצרות בעיות שמשפיעות על מספר לקוחות, אך אתם מתייחסים אליהן כאל אירועים בודדים.
- למידה חלשה: – לקחים מאירועים גדולים כמעט ולא חוזרים לספרי תכנון, לכלי עבודה או לחוזים.
דפוס זה מקשה על הוכחת מה באמת קרה, מי החליט מה והאם עמדת בהתחייבויות החוזיות שלך. משמעות הדבר היא גם שכל אירוע משמעותי מרגיש חדש, גם כאשר שורש הבעיה מוכר וניתן היה לטפל בו בצורה חלקה יותר עם הכנה טובה יותר ותכנון ברור יותר.
לקוחות, חברות ביטוח ורגולטורים מניחים כיום שניהול האירועים שלכם מוגדר, מתורגל ומוכח, ולא מאולתר במשבר. הנחיות רגולטוריות בנושא אבטחה ונתונים אישיים מדגישות יותר ויותר תהליכים מתועדים ונבדקים ורישומים ברורים המראים כיצד טופלו האירועים, ולא רק שהם הוכרו. הם מצפים לראות כיצד אתם מתאמים עבודה טכנית, קבלת החלטות ותקשורת בין צוותים ושוכרים מבלי להסתמך על מעשי גבורה או ניחושים כאשר משהו רציני משתבש.
לקוחות ארגוניים, חברות ביטוח סייבר ורגולטורים מניחים יותר ויותר שניהול אירועים מוגדר, מתורגל ומוכח, ולא מאולתר ביום האירוע. דוחות על פרצות ואיומים בתעשייה מדגישים באופן קבוע פערים בהכנה ובתקשורת, אשר בתורם דוחפים את בעלי העניין לדרוש טיפול מוכח טוב יותר באירועים מספקיהם. הם מצפים שתראו שאתם יכולים לתאם עבודה טכנית, קבלת החלטות ותקשורת בין צוותים ושוכרים מבלי להסתמך על מעשי גבורה של יחידים. תקן הבקרה ISO/IEC 27001:2022 A.5.24 נותן לציפיות הללו צורה קונקרטית ושפה בה משתמשים סוקרים חיצוניים כאשר הם בוחנים את יכולתכם. טקסט הבקרה מתמקד בתכנון, הכנה והקצאת אחריות ברורה לאירועי אבטחת מידע, ומעניק למבקרים ולמעריכים נקודת התייחסות משותפת כאשר הם בוחנים ספקי שירותי ניהול מידע (MSP).
בפועל, משמעות הדבר היא שמישהו יבקש מכם בסופו של דבר להוכיח שיש לכם מדיניות ונהלים מתועדים בנוגע לאירועים, שהצוות מכיר את תפקידיו ועוקב אחר נתיבים עקביים בטיפול באירועים, ושאתם יכולים לייצר תיעוד קוהרנטי של פעולות, אישורים ותקשורת. אם אינכם יכולים לעשות זאת כיום ללא מאמץ, הפער אינו רק בעיית תאימות; הוא יכול בקלות להפוך לבעיית אמון רחבה יותר שתערער חידושים, הפניות ויכולת הביטוח.
כיצד A.5.24 חושף את הפער במוכנות ל-MSP
A.5.24 חושף האם יכולת האירועים שלכם תוכננה באמת וניתנת לחזרה, או סתם אוסף רופף של כרטיסים וכוונות טובות בקרב לקוחות רבים. עבור ספקי שירותי ניהול שירותים (MSPs), הבקרה בודקת האם הפעילות החיה שלכם תואמת את מה שהמדיניות שלכם טוענת והאם אתם יכולים להסביר את הגישה שלכם בצורה ברורה לגורמים חיצוניים שאינם מכירים את הסביבה שלכם.
סעיף A.5.24 דורש ממך להגדיר, לבסס ולתקשר תהליכים, תפקידים ואחריות לניהול אירועים מראש, ולאחר מכן להראות שאתה משתמש בהם. תיאורי הבקרה מדגישים באופן עקבי קיום תהליכים מתועדים, בעלות ברורה והוכחות לכך שתהליכים אלה מיושמים בפועל, במקום להסתמך על הרגלים לא פורמליים. עבור מנהלי ניהול תקריות (MSPs) זה אינו תרגיל ניירת; זהו מבחן האם נוהג האירועים שלך בעולם האמיתי עומד בבדיקה של לקוחות רבים בו זמנית וניתן להסבירו בבירור לגורמים חיצוניים.
דרך פשוטה לבחון את מצבך הנוכחי היא לשאול שלוש שאלות:
- האם תוכל להראות למבקר היכן תפקידים, תהליכים ואחריות באירוע מתועדים ומאושרים?
- האם תוכל ללוות לקוח אסטרטגי דרך אירוע שהתרחש לאחרונה, תוך שימוש בתיעוד יחיד וקוהרנטי כמקור האמת שלך?
- האם תוכל להראות שהלקחים מהאירוע הגדול האחרון שינו את כללי המשחק, הכלים או החוזים?
אם תשובה כלשהי אינה באמת, יש לכם עבודה לעשות. היתרון הוא שאותן קרנות שסוגרות את פער A.5.24 גם מפחיתות כאוס, משפרות את הרווחיות ומקלות עליכם לבטח ולקנות מהם, במיוחד כשאתם יכולים להסביר את הגישה שלכם במונחים פשוטים וניתנים להגנה.
הזמן הדגמהמה באמת דורש תקן ISO 27001:2022 A.5.24
תקן ISO 27001:2022 A.5.24 מצפה מכם להפעיל מסגרת ניהול אירועים אמיתית, ולא רק להחזיק במסמך שנקרא "תוכנית תגובה לאירועים". עבור MSP, מסגרת זו צריכה לפעול על פני לקוחות ופלטפורמות רבות, תוך שהיא נשארת פשוטה מספיק כדי שהצוות יוכל להבין אותה ולמבקרים יוכלו להעריך אותה. הבקרה בעצם שואלת האם אתם יכולים לתאר מה אתם מתכוונים לעשות, כיצד אתם עושים זאת, מי עושה זאת וכיצד אתם מוכיחים זאת לאחר מכן.
כמעט כל המשיבים בסקר ISMS.online שלנו לשנת 2025 בנושא מצב אבטחת מידע ציינו השגה או שמירה על אישורי אבטחה כגון ISO 27001 או SOC 2 כעדיפות עליונה לארגון.
A.5.24 עושה הרבה יותר מאשר לבקש "תוכנית תגובה לאירועים" כללית; הוא מצפה למסגרת עבודה שניתן להסביר, להפעיל ולהציג תחת לחץ. עבור MSP, מסגרת זו צריכה לעבוד על פני לקוחות רבים, טכנולוגיות שונות ומגוון חוזים מבלי להפוך לבלתי ניתנת לניהול או לסטות מהמציאות. זהו עמוד השדרה של האופן שבו מוכיחים מוכנות, לא מסמך סימון שעומד במבחן ביקורת פעם אחת.
ארבע השכבות המעשיות של A.5.24 עבור ספקי שירותי ניהול רשת (MSPs)
ניתן להבהיר את A.5.24 עבור הצוותים שלכם על ידי מסגורו כארבע שכבות מעשיות: ממשל (ממשל), תהליך (תהליך), יכולת (יכולת) וראיות (ראיות). ממשל (ממשל) מגדיר כוונה וסמכות; תהליך (תהליך) מגדיר את מחזור החיים; יכולת (יכולת) מספקת אנשים וכלים; ראיות מוכיחות שאתם באמת פועלים לפי התכנון. יחד, הן נותנות לכם רשימת תיוג פשוטה המשקפת את האופן שבו מבקרים ולקוחות אסטרטגיים חושבים על מוכנות האירועים שלכם.
קל יותר להבין את A.5.24 אם מחלקים אותו לארבע שכבות: ניהול, תהליך, יכולת וראיות. יחד הם מתארים מה אתם מתכוונים לעשות, איך אתם עושים את זה, מי עושה את זה ואיך אתם מוכיחים את זה מאוחר יותר, וזה בדיוק האופן שבו מבקרים ולקוחות אסטרטגיים יעריכו אתכם.
שלב 1 – קבעו ממשל ואחריות ברורים
הגדירו מדיניות לאירועים, היקף, הגדרות ותפקידים בעלי סמכויות שהוענקו להם, כדי שלא יתקעו החלטות.
שלב 2 - תאר תהליך פשוט וניתן לחזור עליו
הסכימו כיצד אירועים הופכים לתקריות וכיצד הם עוברים דרך שלבי מחזור חיים מוגדרים שהצוות יכול לעקוב אחריהם.
שלב 3 – בנייה והכשרה של יכולת התמיכה
תן לאנשים, לכלים ולמידע את המבנה הדרוש להם כדי לבצע את התהליך בצורה אמינה בקרב הדיירים.
שלב 4 – איסוף ראיות לכך שאירועים מנוהלים
ודאו שאירועים מותירים תיעוד בר-מעקב של לוחות זמנים, החלטות, פעולות ולקחים שתוכלו להראות לאחרים.
מבחינת ניהול, אתם זקוקים למדיניות אירועים מאושרת, הגדרה ברורה של מה נחשב כ"אירוע" ומה הופך ל"תקרית", ותפקידים בעלי שם כגון מנהל אירועים, ראש טכני, ראש תקשורת ואיש קשר עם הלקוח. תפקידים אלה חייבים להיות בעלי סמכות מספקת כדי לפעול במהירות ולהיות מוכרים הן על ידי הצוותים שלכם והן על ידי הלקוחות שלכם.
תהליך פירושו מחזור חיים מתועד שאנשים מזהים ועוקבים אחריו. דפוס נפוץ הוא גילוי ודיווח, הערכה וסיווג, בלימה והשמדה, התאוששות ואימות, ולקחים שנלמדו. התקן פחות מתוויות מדויקות ויותר מתוכן שהתהליך מתועד, מועבר ומיושם באופן עקבי, כך שאף אחד לא מאלתר שלבים תוך כדי תנועה.
יכולת היא עניין של אנשים וכלים. אנליסטים ומהנדסים חייבים להבין את התהליך ואת מקומם בו. מערכות ניטור וטיפול חייבות לתמוך במחזור החיים ולא לפעול נגדו. תקשורת מאושרת מראש, קריטריונים לקבלת החלטות וגישה ליומנים ומקורות ראיות מקשרים זאת יחד בפעילות היומיומית.
ראיות הן החלק שרבים מ-MSPs ממעיטים בערכם. אתם זקוקים לרישומי אירועים עם חותמות זמן, פעולות ואישורים, רישומי תרגילים והדרכות, תוצרים מסקירות לאחר אירועים ודיונים בהנהלה על מגמות אירועים ויעילותם. פלטפורמות כמו ISMS.online מקלות על שמירת מבנה ותיאום של חפצים אלו ברחבי מערכת ניהול אבטחת המידע כולה, כך שתוכלו לייצר אותם במהירות כאשר מתעוררים אתגרים. ההנחיות שלנו בנספח A.5.24 מתמקדות בבניית מדיניות, RACI ורישומי אירועים במערכת ISMS מרכזית כך שמעקב זה יהיה זמין באופן עקבי לסקירה פנימית וחיצונית.
בפועל, תצוגה בת ארבע שכבות זו נותנת לכם רשימת תיוג פשוטה: מדיניות ותפקידים קיימים, תהליך מוגדר, יכולות מופעלות וראיות שנאספו. כאשר אתם יכולים לסמן את כל הארבעה בצורה אמינה, A.5.24 מתחיל להרגיש כמו תיאור של הפעילות הרגילה שלכם ולא כמו דרישה חיצונית.
כיצד A.5.24 מתחבר לשאר מערכת ה-ISMS שלך
A.5.24 מחבר תכנון והכנה לאירועים למערכת ניהול אבטחת המידע הרחבה יותר, כך שלא ניתן להתייחס אליהם כאל משימה עצמאית. מבקרים ולקוחות יבדקו האם מדיניות האירועים, הערכת הסיכונים, ניהול הספקים ותכנון ההמשכיות שלכם מספרים את אותו סיפור על האופן שבו אתם מטפלים באירועי אבטחה והפסקות.
A.5.24 אינו בקרה מבודדת; הוא נוגע כמעט בכל חלק במערכת ניהול אבטחת המידע שלכם. זה חשוב מכיוון שמבקרים ולקוחות יחפשו עקביות, לא רק מסמך מלוטש אחד שנראה טוב בפני עצמו.
כ-41% מהארגונים בסקר ISMS.online לשנת 2025 שלנו על מצב אבטחת המידע אמרו שניהול סיכוני צד שלישי ומעקב אחר תאימות ספקים הם אחד מאתגרי אבטחת המידע הגדולים ביותר שלהם.
זה מקשר לבקרות אחרות הקשורות לאירועים בנושאי הערכה, תגובה ולמידה. בקרות רישום וניטור תומכות בגילוי ובראיות. בקרות המשכיות עסקית ובקרות ספקים משפיעות על האופן שבו אתם מטפלים בהפסקות שירות ובכשלים של צד שלישי. סעיפי ליבה של ISMS בנושא כשירות, מודעות, הערכת ביצועים ושיפור קובעים כיצד אתם מכשירים אנשים, מודדים תוצאות ומשפרים את המערכת לאורך זמן.
עבור ספקי שירותי ניהול מערכות (MSPs), השינוי האמיתי הוא להפסיק לשאול "האם יש לנו מדיניות לאירועים?" ולהתחיל לשאול "האם נוכל להגן על יכולת האירועים שלנו, על הנייר ובמעשה, בפני מבקר, רגולטור ולקוח אסטרטגי?". כשמסתכלים על A.5.24 דרך עדשה זו, הוא הופך לעמוד השדרה של האופן שבו מוכיחים מוכנות ולא לתיבת סימון עצמאית, והוא יוצר את השיחה על מי עושה מה כאשר אירוע כרוך גם בך וגם בלקוחות שלך.
הפיכת A.5.24 למסגרת עבודה בין לקוחות
מסגרת A.5.24 מעשית עבור ספק שירותי ניהול נתונים (MSP) חייבת לספק ליבה משותפת בין דיירים, תוך מתן אפשרות לאחריות ספציפית ללקוח וחובות רגולטוריות. תכנון מודל "ליבה בתוספת וריאציות" פעם אחת, ולאחר מכן יישום מחדש שלו לכל לקוח, מונע ממך להמציא מחדש את ניהול האירועים מאפס עבור כל חוזה ומפחית את הסיכון לסחיפה בלתי ניתנת לניהול.
מכיוון שאתם משרתים ארגונים רבים, אינכם יכולים לעצב מסגרת אירועים שונה מאפס עבור כל דייר ולצפות שהיא תישאר מעודכנת. במקום זאת, אתם מגדירים מודל ליבה שחל על פני תיק ההשקעות שלכם ולאחר מכן משנים תחומי אחריות ספציפיים ונתיבי הסלמה לכל לקוח, תוך שימוש בחוזים שלכם כדי לשקף את ההבדלים הללו.
בפועל, זה נראה כמו סט מדיניות ונהלים סטנדרטיים לאירועים, בתוספת ספרי הכנה וריצות לשימוש חוזר, כולם ממופים ל-A.5.24 ולבקרות קשורות. הוראות לפי לקוח, כגון כללי הודעה או התחייבויות רגולטוריות, מתחברות לאחר מכן לליבה משותפת זו. פלטפורמת ISMS מעניקה לכם בית טבעי למודל זה, וקושרת מדיניות, סיכונים, ספקים, המשכיות ואירועים לסביבה אחת, כך שעדכונים וסקירות יזרמו באופן עקבי בין כל הלקוחות שלכם.
כאשר יש לכם מסגרת משותפת זו במקום, הצעד ההגיוני הבא הוא לדייק באופן שבו חלוקת האחריות בין הצוות שלכם לכל לקוח, וכאן נכנסים לתמונה תפקידים ברורים, אינטרסים ניהוליים וגבולות.
ISO 27001 בקלות
יתרון של 81% מהיום הראשון
עשינו את העבודה הקשה בשבילך, ונתנו לך התחלה של 81% מרגע הכניסה. כל שעליכם לעשות הוא להשלים את החסר.
הגדרת תפקידי MSP לעומת תפקידי לקוח, RACI וגבולות
תפקידים וגבולות ברורים בין ספק שירותי ניהול הרשת (MSP) שלכם לבין כל לקוח חשובים לא פחות מהתהליך הטכני כאשר מתרחשים אירועים חמורים. ללא אחריות מוסכמת, אתם מסתכנים בהחמצת מועדי מעקב רגולטוריים, עיכובים בבלימה ותקשורת סותרת שפוגעת באמון. A.5.24 מצפה שתפתרו את השאלות הללו לפני אירוע, לא בזמן שכולם כבר נמצאים תחת לחץ.
כל אירוע חמור הכרוך בלקוח מעלה את אותן שאלות לגבי מי אחראי על אילו החלטות, מי מדבר כלפי חוץ ומי נושא באחריות רגולטורית, ושאלות אלו קלות הרבה יותר לענות עליהן אם החלטתם עליהן מראש. A.5.24 מצפה מכם ליישב את הנקודות הללו לפני שמשהו משתבש, לא בזמן שאתם מטפלים במתקפה חיה ודנים בבעלות באמצע משבר. תפקידים ברורים הם הבסיס למוכנות אמינה לאירועים עבור MSPs.
למה אתם צריכים תפקידים וגבולות מודעים לשוכרים
תפקידים וגבולות מודעים לשוכרים מבטיחים שהצוות שלכם והלקוח שלכם יקבלו החלטות בזמן הנכון, ברמת הסמכות הנכונה, ועם הבנה משותפת של מי עושה מה. עמימות בגבולות אלה הופכת במהירות בעיה טכנית ניתנת לניהול לבעיית ביטחון שמשפיעה על חידושים והפניות.
עמימות בתפקידים היא אחת הדרכים המהירות ביותר להפוך אירוע בר ניהול למשבר אמון. אם הצוות שלכם מניח שהלקוח יודיע לרגולטורים, בעוד שהלקוח מניח שאתם תגידו להם מתי להודיע, מועדים חשובים יכולים לחלוף ללא פעולה. אם אף אחד לא יודע מי מאשר בלימה משבשת, מהנדסים מהססים, דיונים נתקעים והנזק גובר בזמן שכולם ממתינים להנחיות.
מודל RACI (אחראי, אחראי, מתייעץ, מודע) המודע לדיירים מספק לכם דרך פשוטה וחוזרת על עצמה להקצאת תפקידים. עבור כל שלב במחזור החיים של האירוע, אתם מגדירים מהי הפעילות בהקשר שלכם, איזה צד מעורב וכיצד האחריות מחולקת. מודל זה לאחר מכן מלמד על חוזים, נהלים וספרי פעולות, כך שהמציאות והתיעוד יישארו תואמים ושני הצדדים ידעו למה לצפות זה מהשני.
בניית RACI מעשי בין MSP ללקוח
RACI מעשי בין MSP ללקוח מתחיל במודל כללי המשקף את אופן העבודה שלכם כיום, ולאחר מכן מסתגל לקריטיות ולרגולציה של הלקוח מבלי לשנות את המבנה הבסיסי שלו. זה שומר על דברים פשוטים עבור הצוותים שלכם ועדיין נותן למנהלי תיקי לקוחות את הגמישות לנהל משא ומתן על אחריות ספציפית ללקוח היכן שזה חשוב.
נקודת התחלה שימושית היא RACI גנרי עבור לקוח "טיפוסי", המותאם לפי קריטיות ורגולציה. לאחר מכן ניתן להתאים את המודל כל מקרה לגופו מבלי להמציא אותו מחדש בכל פעם, תוך שמירה על אותו מבנה שהצוותים שלכם מזהים.
דוגמה פשוטה לתיאור סיפורי עשויה להיראות כך:
| שלב האירוע | תפקיד הלקוח (סיכום) | תפקידו של חבר הפרלמנט (סיכום) |
|---|---|---|
| זיהוי ודיווח | מקבל ומעביר דוחות משתמשים | מנטר מערכות והופך התראות לכרטיסים |
| מיון והערכה | מספק הקשר להשפעה עסקית | מסווג וקביעת סדרי עדיפויות לאירועים ותקריות |
| מכולה | מאשר פעולות משבשות | מציע ומיישם בלימה טכנית |
| הודעה | בעלת דיווחים רגולטוריים וציבוריים | מספק פרטים טכניים ומידע על זמנים |
| לקחים שהופק | קובע תיאבון לסיכון ושינויים | מתעד את שורש הבעיה ומציע שיפורים |
המפתח אינו הניסוח המדויק, אלא הסרת האזורים האפורים. שום פעילות לא צריכה להתקיים במרחב שבו כל צד מניח בשקט שהצד השני יפעל. כשכותבים תיאורי שירות, הסכמי רמת שירות, הסכמי רמת תפעול וחומרי קליטה, RACI זה צריך לבוא לידי ביטוי בבירור, כך שהבטחות המכירות, המציאות התפעולית וציפיות הלקוח יתאימו.
טיפול ברגולטורים, ראיות וצדדים שלישיים
טיפול ברגולטורים, ראיות וצדדים שלישיים דורש יותר מניסוח כללי בחוזים שלכם; אתם זקוקים לטריגרים, החלטות ומסירות ספציפיים עבור תרחישים בהם חלים מגבלות זמן ותקנים משפטיים. הקפדה נכונה על אלה ב-RACI שלכם מגינה עליכם ועל לקוחותיכם כאשר אירועים מושכים תשומת לב חיצונית.
רוב הארגונים בדוח מצב אבטחת המידע ISMS.online שלנו לשנת 2025 ציינו כי הושפעו מלפחות אירוע אבטחה אחד הקשור לצד שלישי או לספק בשנה האחרונה.
ישנן תחומי אחריות הדורשים טיפול מיוחד כדי למנוע הפתעות במשבר, משום שמעורבים גורמים חיצוניים ומועדי היעד קבועים.
שעוני רגולציה חשובים. אם ללקוח יש מועדי דיווח מוגדרים כחוק, החוזים והנהלים שלכם חייבים לציין מי מחליט שאירוע מדווח, מי מפעיל את השעון ומי בפועל מגיש הודעות. הנחיות ציבוריות בנוגע לדיווח על אירועים מדגישות לעתים קרובות את הצורך בקריטריונים ברורים לדיווח, אחריות מוגדרת ולוחות זמנים מוסכמים, במיוחד כאשר חלים מועדים סטטוטוריים. תהליך האירועים שלכם צריך לכלול הנחיות להפעלת החלטות אלו בזמן, עם נתיבי הסלמה ברורים כאשר יש חילוקי דעות.
בעלות על ראיות היא תחום רגיש נוסף. אתם זקוקים להסכמות לגבי אופן שיתוף יומני רישום, צילומי מסך וחפצים אחרים, וכיצד תשמרו על שרשרת המשמורת. התייחסות לנתוני לקוחות כאל נוחות פנימית לא תעמוד בבדיקה משפטית או רגולטורית כאשר חוקרים ישאלו כיצד אספתם והגנתם עליהם.
ספקי צד שלישי מסבכים את לוחות הזמנים. אירועים רבים כוללים פלטפורמות ענן, ספקי SaaS או ספקי שירות. ה-RACI שלך צריך להבהיר מי יוצר קשר עם איזה ספק, איזה מידע הוא מעביר וכיצד אינטראקציות אלו נרשמות במערכת האירועים שלך, כך שתוכל להפגין שקידה מאוחר יותר.
תפקידים לא טכניים כמו פרטיות, משפט ומשאבי אנוש חייבים גם הם להיות בעלי מקומות מוגדרים בתהליך. כתיבה עליהם כ"נערב אותם במידת הצורך" אינה מספיקה; הם זקוקים לתנאי טריגר ופעולות צפויות כדי שעבודתם תשתלב בצורה חלקה עם התגובה הטכנית. לאחר שגבולות אלה ברורים, ניתן לעגן אותם במדיניות, בנהלים, בספרי ההפעלה ובספרי הריצה המרכיבים את ספריית האירועים שלכם.
עיצוב מדיניות, נהלים, ספרי הכנה וספרי הפעלה
יכולת האירועים שלכם תתרחב בין לקוחות רק אם תארגנו אותה כספרייה קטנה ורב-שכבתית של מדיניות, נהלים, ספרי הכנה וספרי הפעלה, ולא כתוכנית אחת נפוחה. כל שכבה צריכה לענות על שאלה שונה ולהיכתב עבור קהל יעד שונה, החל ממנהלים המאשרים את המדיניות ועד אנליסטים שעוקבים אחר ספרי ההפעלה תחת לחץ זמן.
יכולת יעילה לאירועים עבור MSP אינה מסמך "תוכנית תגובה לאירועים" יחיד שמנסה לעשות הכל. זוהי ספרייה קטנה וקוהרנטית של מדיניות, נהלים, ספרי הכנה וספרי עבודה שאנשים שונים יכולים להשתמש בהם ברמות פירוט שונות, כולם מקושרים חזרה ל-A.5.24 ול-RACIs של MSP-לקוח. תכנון ספרייה זו באופן מכוון מאפשר לך להרחיב את הגישה שלך ולשמור על אמינותה תחת ביקורת.
בניית ספרייה קטנה ורב-שכבתית במקום תוכנית מפלצתית
ספרייה רב-שכבתית מונעת מתיעוד האירועים שלכם להפוך לבלתי קריא ומיושן, מכיוון שלכל מסמך יש תפקיד וקהל יעד ברורים. מדיניות מגדירה כוונה, נהלים מגדירים את מחזור החיים, ספרי נהלים מגדירים תרחישים וספרי נהלים מגדירים שלבים ברמת הכלי. יחד הם נותנים לצוותים שלכם ולמבקרים שלכם תמונה קוהרנטית של אופן הטיפול באירועים.
אפשר לחשוב על ספרייה כארבע שכבות שעונות על שאלות שונות: למה, מה, איך ובעזרת אילו כלים. שמירה על שכבות ברורות מונעת מסמכים להתנפח ומבטיחה שהצוות ידע היכן לחפש כשהוא תחת לחץ ושיהיו לו שניות, לא דקות, למצוא הדרכה.
שלב 1 – כתיבת מדיניות תמציתית לניהול אירועים
קבעו את היקף, הכוונה ואחריות ברמה גבוהה בהצהרה קצרה ומאושרת שכולם יוכלו להבין.
שלב 2 – הגדרת נוהל כללי לניהול אירועים
תאר שלבי מחזור חיים, נקודות החלטה וכללי הסלמה ברמת התהליך, ללא תלות בכלים ספציפיים.
תעד טריגרים, יעדים, תפקידים, פעולות ותקשורת עבור תרחישים נפוצים איתם מתמודדים הלקוחות שלך בפועל.
שלב 4 – תחזוקת ספרי ריצה טכניים ספציפיים לכלי עבודה
הצג פעולות שלב אחר שלב בפלטפורמות ספציפיות אליהן מתייחסים ספרי ההפעלה, מוכנות לשימוש אנליסטים ומהנדסים.
המדיניות מסבירה מדוע אתם מטפלים באירועים, מה ההיקף ומי אחראי בסופו של דבר. ההליך הופך את הכוונה הזו למחזור חיים עקבי ומסביר מתי לעבור משלב אחד למשנהו. ספרי הדרכה לוקחים את התהליך הגנרי והופכים אותו להנחיות קונקרטיות וספציפיות לתרחיש, שאנליסטים יכולים לעקוב אחריהם. ספרי הדרכה מעגנים את התרחישים הללו בכלים אמיתיים, כך שמהנדסים לא יצטרכו לאלתר שלבים טכניים באותו היום.
בחירת ספרי ההדרכה הראשונים שחשובים
ספרי ההנחיות הראשונים שלכם צריכים לכסות את האירועים הסבירים והמזיקים ביותר עבור בסיס הלקוחות שלכם, ולא כל תרחיש תיאורטי. התמקדות במספר קטן של מקרים בעלי ערך גבוה מקלה על הכשרת הצוות, שיפור ההנחיות באמצעות שימוש אמיתי והדגמת כיסוי מוחשי ללקוחות ולמבקרים.
אינכם זקוקים לעשרות ספרי הדרכה כדי להתחיל; למעשה, ספרייה עמוסה קשה יותר לתחזוקה ופחות סביר שתשתמש בה. יעיל יותר לכתוב קומץ תרחישים בעלי ערך גבוה התואמים את בסיס הלקוחות ומחסנית הטכנולוגיה שלכם, ולאחר מכן לחדד אותם באמצעות שימוש אמיתי ותרגילים מובנים.
מועמדים מוקדמים טובים לספרי משחק של MSP כוללים לעתים קרובות:
- תוכנות זדוניות או תוכנות כופר בנקודת קצה מנוהלת בלקוח טיפוסי.
- פשרה של דוא"ל עסקי בפלטפורמת דוא"ל ענן סטנדרטית.
- פריצה לחשבון בעל זכויות יוצרים בספרייה או בקונסולת ענן.
- פעילות חשודה בפלטפורמת ניהול מרחוק משותפת.
- הידרדרות בשירות מרובה דיירים שעשויה להיות קשורה לאבטחה.
כל ספר פעולות צריך להגדיר כיצד מתחיל האירוע, מהן המטרות המיידיות שלך, אילו תפקידים מעורבים, אילו החלטות מפתח יש לקבל ואילו ראיות יש לאסוף. תבניות קצרות ועקביות מקלות על תחזוקה זו ועל אנליסטים להשתמש בה תחת לחץ, והן גם מקלות על קליטת צוות חדש לשיטת העבודה שלך.
לאחר מכן, Runbooks ממלאים פרטים ספציפיים לכלי, כגון כיצד לבודד מארח בכלי זיהוי נקודות קצה מסוים או כיצד לייצא יומני רישום מפלטפורמת ענן ספציפית. שמירה על הפרדתם ממדיניות ונהלים מונעת עריכות מדיניות מתמידות בעת שינויים בכלים או בעת אימוץ פלטפורמות חדשות עבור מקטעי לקוחות שונים.
שמירה על מסמכים שמישים ומותאמים למציאות
התיעוד שלכם מוכיח את ערכו רק אם הוא משקף את אופן העבודה שלכם בפועל כיום וקל לצוות למצוא אותו כשהוא זקוק לו. בקרת שינויים פשוטה, בעלות ברורה ושילוב בכלים יומיומיים שומרים על הספרייה שלכם בקו אחד עם הפרקטיקה ומדגימים למבקרים שאתם מתחזקים, ולא רק יוצרים, את חומרי האירועים שלכם.
מסמכים שנמצאים בתיקייה מבודדת ולעולם לא משתנים מתרחקים במהירות מהפרקטיקה בפועל, דבר שפוגע הן במוכנות והן באמינות הביקורת. כדי לשמור על הספרייה שלכם חיה, בנו סביבה משמעת שינוי פשוטה וחברו עדכונים ישירות לאירועים ולתרגילים.
לאחר אירועים או תרגילים משמעותיים, יש לבדוק אילו מסמכים היו שימושיים, אילו היו חסרים ואילו לא מדויקים. יש לעדכן את המדיניות, הנוהל, מדריך הפעולות או מדריך הפעולות הרלוונטיים באופן מכוון, באמצעות בקרת גרסאות ואישורים קלים. המטרה היא לשמור על ההתאמה בין ההנחיות הכתובות לפרקטיקה בפועל, מבלי להעמיס על הצוות בירוקרטיה או להאט שינויים חיוניים.
זה גם עוזר להטמיע את המסמכים האלה במקום שבו מתבצעת העבודה. קישור פלייבוקס וריצות ישירות מרישום אירועים או לוחות מחוונים של SOC הופך את השימוש לסביר הרבה יותר מאשר להסתמך על אנשים שיחפשו במאגר נפרד. ISMS.online ופלטפורמות דומות יכולות לשמש כעמוד השדרה, ולחבר את המדיניות והנהלים שלכם לסיכונים, ספקים, תוכניות המשכיות ורישומי אירועים, כך שלצוות תמיד יהיו הנחיות עדכניות בהישג יד. עם הספרייה הקיימת, האתגר הבא הוא לוודא שכלי הרישום, הניטור וה-SOC שלכם אכן משקפים את העיצוב הזה.
שחררו את עצמכם מהר של גיליונות אלקטרוניים
הטמע, הרחב והרחיב את תאימותך, ללא כל בלגן. IO מעניק לך את החוסן והביטחון לצמוח בצורה מאובטחת.
שילוב A.5.24 עם פעולות כרטוס, ניטור ו-SOC
A.5.24 מספק ערך רק כאשר עיצוב האירועים שלכם משתקף בכלים בהם הצוותים שלכם משתמשים מדי יום. עבור רוב ספקי שירותי ה-MSP, דלפק השירות או פלטפורמת ניהול שירותי ה-IT (ITSM) צריכים להיות מערכת הרישומים של אירועים, בעוד ניטור וכלי SOC מזינים אותם בצורה צפויה. כאשר כלים אלה משקפים את התהליך, התפקידים ומודל הראיות שלכם, תוכלו להפגין שליטה במקום להסתמך על נרטיבים וזיכרון.
A.5.24 מספק ערך רק כאשר הוא גלוי בכלים היומיומיים שלכם ובאופן שבו הצוותים שלכם עובדים בפועל. עבור רוב ספקי שירותי ה-MSP, מערכת שירות השירות או מערכת ניהול שירותי ה-ITSM (ITSM) צריכה להיות מערכת הרישומים של אירועים, כאשר כלי ניטור ומרכז תפעול אבטחה (SOC) צריכים להזין אותם בצורה מבוקרת. הנחיות לטיפול באירועים בדרך כלל ממליצות על רשומה מרכזית אחת לכל אירוע, כאשר מערכות גילוי וצוותי תגובה מזינים את הרשומה הזו במקום לתחזק יומנים נפרדים ומקוטעים. כאשר כלים אלה משקפים את התהליך והתפקידים שלכם, מוכנות הופכת למשהו שאתם יכולים להראות, לא רק משהו שאתם טוענים לו.
הפיכת כלי ה-ITSM למערכת רישום האירועים שלך
התייחסות לפלטפורמת ה-ITSM שלכם כמערכת רישום אירועים מבטיחה שכל אירוע משמעותי ישאיר עקבות מובנים שתוכלו לסקור ולשתף. כאשר קטגוריות, זרימות עבודה ושדות תואמים את A.5.24 ואת מחזור החיים של האירוע שלכם, אינכם מסתמכים עוד על מיילים מפוזרים או יומני צ'אט כדי לספר את הסיפור; הפנייה עצמה הופכת לנרטיב עבור מבקרים ולקוחות.
אם אירועי אבטחה ותקריות מפוזרים בשרשורי דוא"ל, ערוצי צ'אט ומסמכים אד-הוק, לא ניתן להוכיח בקלות שליטה או ללמוד מניסיון. כאשר תצורת ה-ITSM שלכם תואמת את תהליך האירועים שלכם, כל אירוע משמעותי משאיר שובל מובנה שתוכלו לסקור ולהציג ללקוחות, למבקרים ולחברות ביטוח ללא טרחה.
שלב 1 – הגדרת כיצד התראות הופכות לאירועים
הסכימו אילו התראות צריכות לפתוח כרטיסים וכיצד אנליסטים מאשרים ומסווגים אירועים לפני הסלמה.
שלב 2 – הגדרת קטגוריות, סדרי עדיפויות ותהליכי עבודה
הגדר קטגוריות אבטחה, דרגות חומרה ומצבי מחזור חיים ייעודיים המשקפים את התהליך המתועד שלך.
שלב 3 – איסוף נתונים מובנים עבור כל אירוע
הוסף שדות ותבניות עבור מקור זיהוי, השפעה, אישורים, תקשורת ולקחים שנלמדו.
התחילו בהחלטה כיצד התראות ניטור נכנסות לכלי ה-ITSM. מערכות ניטור צריכות ליצור כרטיסים באופן אוטומטי או להזין תור מיון שבו אנליסטים מחליטים אם לפתוח או לעדכן אירועים. לאחר אישור אירוע, יש לתייג אותו בבירור כקשור לאבטחה ולהקצות לו חומרה מוסכמת הקשורה להשפעה ולדחיפות, כך שמאמץ התגובה יהיה עקבי.
יש להגדיר קטגוריות ותת-סוגים כך שאירועי אבטחה יהיו נפרדים מבעיות שירות שגרתיות. יש להגדיר מצבי מחזור חיים כגון פתוח, מיון, חקירה, בלימה, התאוששות, סקירה וסגירה, ולוודא שכרטיסים עוברים דרך מצבים אלה בצורה מבוקרת. יש להוסיף שדות ותבניות עבור נקודות נתונים מרכזיות במסגרת A.5.24 כמו מקור זיהוי, נכסים מושפעים, החלטות מרכזיות, אישורים ותקשורת, כך שסוקרים יוכלו לעקוב אחר העלילה במבט חטוף.
כדי להפוך זאת למוחשי, דמיינו התראת כופרה בנקודת קצה מנוהלת. כלי הניטור מעלה אירוע שפותח כרטיס "אירוע אבטחה", המאוכלס מראש במקור, המארח המושפע, כלל הזיהוי וחומרה. לאחר מכן, האנליסטים עוקבים אחר טופס מובנה כדי לתעד החלטות מיון, פעולות בלימה, הודעות לקוח וצעדי שחזור סופיים, הכל בתוך אותה רשומה אחת. הכרטיס המתקבל נראה כמו ציר זמן, לא כמו חידה.
חיבור ניטור, SOC ותקשורת לקוחות
כלי ניטור וניהול תהליכים תקינים (SOC) זקוקים למסלולים ברורים ומתועדים בתהליך האירועים שלכם, כך שהתראות, חקירות ועדכוני לקוחות יישארו תואמים. המטרה שלכם היא זרימה מבוקרת שבה מערכות טכניות יוצרות או מעדכנות כרטיסים, אנליסטים משפרים ומסלמים, וצוותי לקוחות מתקשרים בדרכים שתוכלו לעקוב אחריהן ולהסבירן בהמשך.
בצד הניטור וה-SOC, אתם רוצים זרימות ברורות וניתנות להסבר מהתראות לרשומות. מערכות ניהול מידע ואירועי אבטחה (SIEM), כלי זיהוי ותגובה לנקודות קצה (EDR), פלטפורמות אבטחת ענן ומקורות אחרים צריכים לפתוח או לעדכן כרטיסים בהתאם לכללים שתוכלו לתאר בנוהל ובספרי ההליכים שלכם. כוונון הכללים כדי לצמצם תוצאות חיוביות שגויות וכפילויות הוא גם רווח יעילות וגם סימן לכך שחשבת היטב על הזיהוי.
עבור אירועים חמורים, ניתן לבחור ליצור מנגנון גישור כגון ערוץ צ'אט ייעודי בחדר מלחמה או שיחות ועידה מתוזמנות. יש לסכם את ההשתתפות, ההחלטות וההודעות המשמעותיות מגשר זה בחזרה לתיעוד האירוע, כך שלא תצטרכו לשחזר אותם מאוחר יותר מתמלילים וזיכרונות כאשר מישהו דורש ציר זמן.
התקשורת עם הלקוח צריכה לעקוב אחר אותו מבנה. שינויים בחומרה צריכים להוביל למעברים פנימיים במצב, ובמידת הצורך, עדכונים חיצוניים באמצעות דפי סטטוס, מיילים או שיחות עם מנהלי תיקי לקוחות. שימוש בתבניות הודעות שאושרו מראש ובנתיבי אישור ברורים מפחית את הסיכון להצהרות לא עקביות או מטעות תחת לחץ ומקל על הוכחת שנקטת בצעדים מדודים ובזמן.
למידה מכל אירוע לשיפור המערכת
הכלים ותהליכי העבודה שלכם צריכים להתפתח לאחר כל אירוע משמעותי כך שיהיה קל יותר לטפל באירוע הבא וקל יותר להוכחה. בניית שלבי "סקירה ושיפור" בתהליך שלכם הופכת את A.5.24 למניע של בגרות תפעולית ולא למשימת תאימות סטטית.
מטרת התכנון וההכנה של A.5.24 מתממשת רק כאשר משתמשים באירועים כדי לשפר את המערכת, במקום להתייחס לכל אחד מהם כאל שריפה חד פעמית שיש לכבות. משמעות הדבר היא בניית דפוס חוזר לסקירות אירועים והזנת התוצרים שלהם לשינוי שניתן לעקוב אחריו.
לאחר כל אירוע משמעותי, שאלו האם הכלים והתהליך עזרו לכם או הפריעו לכם. האם היה לכם את כל המידע הדרוש לכם במקום אחד? האם היו שלבים ידניים שיכלו להיות מופעלים על ידי טפסים פשוטים או אוטומציות? האם הפנייה סיפרה סיפור קוהרנטי משלב הגילוי ועד לסגירה שמישהו אחר יכול היה לעקוב אחריו?
הפוך את ההרהורים הללו לפעולות: התאימו קטגוריות, שפרו זרימות עבודה, שנו תבניות, שפרו את ספרי ההליכים או עדכנו חוזים. רשמו פעולות שיפור באופן שתוכלו לעקוב אחריהם עד לסגירה ולהתייחס אליהן בישיבות סקירת הנהלה. עם הזמן, פעולה זו הופכת את A.5.24 מבקרה סטטית למניע של שיפור מתמיד בכל פעולות ה-MSP שלכם, וזה באופן טבעי מוביל לשאלות לגבי האופן שבו אתם מעצבים ומגנים על הראיות עליהן מסתמכות הסקירות הללו.
ראיות, רישום ומוכנות משפטית עבור ספקי שירותי ניהול נתונים מרובי דיירים
סעיף A.5.24 מניח שניתן להראות כיצד טופלו אירועים, ולא רק לטעון שהם נוהלו כראוי. עבור ספקי שירותי ניהול מידע (MSPs) זה קשה משום שעליכם לאזן בין איכות הראיות, הפרדת הדיירים וחובות הפרטיות של לקוחות וספקים רבים, תוך שמירה על עלויות תחת שליטה. מודל ראיות מכוון ומתועד הופך את פעולת האיזון הזו לנוהג חוזר במקום מטלה אד-הוק. פרשנויות על הבקרה מדגישות לעתים קרובות את הצורך ברשומות ובחפצים המדגימים תכנון, קבלת החלטות ומעקב, ולא רק הצהרות ברמה גבוהה על תגובה.
תכנון מודל ראיות שעובד לפי דייר
מודל ראיות לכל דייר עוזר לך להימנע הן מנקודות מתות והן מדליפות נתונים מקריות על ידי הגדרת אילו יומני רישום וארכיטקטים אתה אוסף, היכן הם נמצאים וכיצד הם קשורים לרישומי אירועים. כאשר כולם מבינים את המודל הזה, אתה יכול להגיב לחקירות בביטחון במקום לחפש במאגרים לא מנוהלים.
מודל ראיות פשוט ומתועד עבור כל לקוח עוזר לכם להימנע הן מפערים והן מחשיפה מקרית של נתונים. המודל צריך לענות על אילו יומני רישום וארכיטקטים אתם אוספים, היכן הם מאוחסנים, כיצד שעונים מסונכרנים וכיצד רשומות מתחברות לאירועים בכלי ניהול ה-ITSM או בכלי ניהול התיקים שלכם.
שלב 1 – רשימת מקורות יומן מפתח ואירועים לכל לקוח
זהה אילו מערכות מייצרות רשומות רלוונטיות לאבטחה וכיצד ניתן לגשת אליהן במהירות.
שלב 2 – הגדרת כללי אחסון, סנכרון זמן ושמירה
תעד היכן נמצאים הנתונים, כיצד השעונים נשארים מיושרים וכמה זמן אתה שומר כל סוג של רשומה.
שלב 3 – קישור ראיות לרישומי אירועים
תאר כיצד יומני רישום, חפצים לא רצויים והחלטות קשורים לכרטיסים לצורך סקירה וביקורות מאוחרות יותר.
אינכם זקוקים לתרשים מורכב עבור כל לקוח, אך עליכם להיות מסוגלים להסביר, לדוגמה, שירישום רלוונטיים לאבטחה ממערכות מוגדרות זורמים למאגרים מרכזיים או למאגרי נתונים מוגדרים היטב, ששעונים מסונכרנים כך שצירי זמן הגיוניים בין פלטפורמות שונות ושהגישה למאגרי נתונים אלה נשלטת ונרשמת. הסבר זה צריך להיות עקבי עם המדיניות והחוזים שלכם.
קישור ראיות לאירועים יכול להיות פשוט כמו שיוך קטעי יומן, דוחות או הפניות למאגרים ספציפיים בתוך כרטיסי ה-ITSM שלכם. המפתח הוא שמישהו יוכל מאוחר יותר לשחזר את האירוע מהרשומה ללא חיפוש אוצרות בין מערכות וחשבונות, ושהוא יוכל לראות מדוע החלטות מסוימות התקבלו בזמנים מסוימים.
ביצוע נכון של שימור, גישה והפרדה
שמירה, גישה והפרדה של נתוני אירועים חייבות לאזן בין חובות משפטיות, ציפיות הלקוח וצרכים תפעוליים. כמות גדולה מדי של נתונים השמורים למשך זמן רב מדי מגדילה את הסיכון; מעט מדי נתונים או מחיקה אגרסיבית מדי מותירים אתכם ללא יכולת לתמוך בחקירות או להפגין זהירות ראויה כשאתם נשאלים.
החלטות בנוגע לשמירה ומחיקה נמצאות בצומת שבין אבטחה, פרטיות ועלות. שמירת כל דבר למשך זמן רב מדי מגבירה את הסיכון ועלולה להפר את כללי הפרטיות; מחיקה אגרסיבית מדי אינה מאפשרת לך לענות על שאלות סבירות לאחר תקרית או לתמוך בהליכים משפטיים.
תעדו את הבחירות שלכם עבור סוגים שונים של נתונים כגון יומני גלם, אירועים מצטברים וחפצי חקירה. שימו לב היכן אתם משתמשים בשמירה ארוכה יותר מסיבות רגולטוריות או חוזיות, והגדירו טריגרים המאריכים את השמירה עבור אירועים ספציפיים, כגון החזקות משפטיות או חקירות ביטוח. הסבירו כיצד ומתי נתונים נמחקים בצורה מאובטחת, וודאו שהנוהג תואם את מה שכתוב במדיניות שלכם ואת הסכמי הלקוחות.
בסביבה מרובת שוכרים, הפרדה חשובה לא פחות משימור עובדים. אתם רוצים ביטחון ש:
- אנליסטים החוקרים לקוח אחד אינם יכולים לעיין באופן אגבי בנתונים של לקוח אחר.
- פעולות אדמיניסטרטיביות במאגרי יומנים וראיות נרשמות בעצמן ונבדקות מעת לעת.
- כאשר אתם משתפים חפצים עם לקוחות, אתם עושים זאת באמצעות ערוצים מאושרים ומאובטחים עם בקרות גישה ברורות.
דרישות אלו צריכות להופיע במודל הראיות שלכם ובנהלי התפעול שלכם. אם אתם משתמשים בפלטפורמת ISMS, תוכלו לעתים קרובות לרכז הפניות לראיות תוך שמירה על נתונים בסיסיים במאגרי מידע טכניים מפולחים, כך שתוכלו לשמור על הפרדה מבלי לאבד את הנראות של מה שקיים היכן.
שילוב איסוף ראיות בעבודה היומיומית
איסוף ראיות חייב להיות משולב בפעילויות תגובה יומיומיות לאירועים, ולא להתייחס אליו כאל מחשבה שלאחר מעשה, אם אתם רוצים תיעוד אמין תחת A.5.24. על ידי הפיכת שלבי ראיות מרכזיים לתיבות סימון בתוך ספרי נהלים, ספרי ריצה ותבניות כרטיסים, אתם מקלים על האנליסטים לעשות את הדבר הנכון גם תחת לחץ.
הזמן לחשוב על ראיות הוא לא לאחר סגירת אירוע; אלא בזמן שספרי מעקב ותוכניות הפעלה מבוצעים בזמן אמת. אם איסוף ראיות מרגיש כמו עבודה נוספת, אנשים ידלגו עליו כאשר הלחץ יעלה, ותגלו את הפער רק כאשר מישהו ישאל שאלות קשות.
כדי להימנע מכך, יש לעצב ספרי הכנה (playbooks) וספרי עבודה (runbooks) כך שפעולות מפתח יכללו שלבי ראיה מפורשים. לדוגמה, לפני בידוד מארח, אנליסטים מצלמים צילומי מסך מוסכמים או מייצאים יומני רישום ספציפיים; לאחר איפוס אישורים, הם מתעדים אילו חשבונות שונו ומתי; בעת הודעה ללקוח, הם מצרפים את ההצהרה שאושרה ומציינים מי חתם עליה ובאיזו שעה.
אירועים סגורים הם דוגמאות טובות לביקורת. בחרו מעת לעת כמה אירועי ביקורת ובדקו אותם כאילו הייתם מבקר, רגולטור או לקוח אסטרטגי. שאלו האם אתם יכולים לראות ציר זמן מלא מגילוי ועד סגירה, האם ההיגיון לפעולות מפתח ברור והאם הראיות המצורפות יספקו את דעתו של בודק חיצוני. כאשר התשובה היא לא, שפרו את מודל הראיות שלכם, את התיעוד וההכשרה שלכם כך שהאירוע הדומה הבא ייצור תיעוד וניתוח טובים יותר, ויניחו את היסודות לתרגילים ממוקדים יותר.
ניהול כל דרישות התאימות, הכל במקום אחד
ISMS.online תומך ביותר מ-100 תקנים ותקנות, ומעניק לך פלטפורמה אחת לכל צרכי התאימות שלך.
שילוב הדרכות, תרגילים ו-ISMS במערכות A.5.24–A.5.30
הכשרה ותרגילים הופכים את תכנון A.5.24 שלכם ליכולת חיה שאנשים יכולים להשתמש בה תחת לחץ. עבור MSP, משמעות הדבר היא מיפוי תפקידי אירועים ספציפיים להכשרה מותאמת אישית, תרגול תרחישים מציאותיים בין דיירים והטמעת לקחים במערכת ה-ISMS הרחבה יותר שלכם, כך שהשיפור יהיה גלוי לעין, לא רק משוער.
כשני שלישים מהארגונים בסקר ISMS.online לשנת 2025 על מצב אבטחת המידע אמרו כי המהירות והיקף השינויים הרגולטוריים מקשים על קיום תאימות לתקנות האבטחה והפרטיות.
סעיף A.5.24 מניח שתהליכי האירועים שלכם לא רק כתובים, אלא גם מובנים ומתורגלים על ידי האנשים שחייבים להשתמש בהם. הנחיות מגופי תקינה בנוגע לתכנון תגובה לאירועים מדגישות שוב ושוב הכשרה, חזרה והיכרות של הצוות עם הנהלים כהשלמה חיונית לתיעוד כתוב. עבור מנהלי שירותים, משמעות הדבר היא פיתוח מיומנויות ספציפיות בתפקידים שונים ושימוש בתרגילים כדי לבחון הן את התכנון שלכם והן את המוכנות שלכם בין דיירים ואזורי זמן. הכשרה וחזרה סוגרים את הפער בין מסמכים מסודרים לתגובה מבולגנת בעולם האמיתי.
מיפוי תפקידים להכשרה שהם באמת צריכים
תפקידים שונים זקוקים להכשרה שונה אם הם עומדים לזהות גורמים לאירועים, לפעול לפי נהלים ולקבל החלטות טובות. מיפוי תפקידים אלה לתוצרי למידה קונקרטיים הופך את תוכנית ההכשרה שלך לממוקדת ומדידה, ומספק ראיות חזקות לכך ש-A.5.24 מוטמע ולא תיאורטי.
הכשרה כללית למודעות אבטחה לא תכין את הצוותים שלכם לטיפול באירועים מרובי דיירים שבהם תחומי אחריות חוצים גבולות ארגוניים. עליכם למפות תפקידים לתוצאות למידה קונקרטיות ולאחר מכן להתאמן מול ספרי ההפעלה, ספרי הריצה והכלים האמיתיים שלכם, כך שאנשים יראו את עצמם בתרחישים.
שלב 1 – זיהוי תפקידים הקשורים לאירועים בצוותים השונים
רשימת אנליסטים, מהנדסים, מנהלי לקוחות, גורמי פרטיות, גורמי משפט ומקבלי החלטות בכירים הנוגעים לאירועים.
שלב 2 – הגדירו מה כל תפקיד חייב להכיר ולעשות
ציין טריגרים, פעולות, נתיבי הסלמה וחובות תקשורת לכל תפקיד, כולל מתי למסור את השליטה.
השתמשו בפגישות קצרות שיעברו על אירועים מציאותיים באמצעות הכלים החיים שלכם וזרימת כרטיסים בפועל.
אנליסטים בחזית וצוותי שירות חייבים לזהות גורמים המעוררים אירועים, לפעול לפי ספרי הפעולות ולאסוף ראיות תוך כדי תנועה. מהנדסים צריכים לבצע ספרי פעולות בצורה בטוחה, להבין אפשרויות בלימה ולדעת מתי להעלות את הליכי המעקב לאישורים. מנהלי לקוחות צריכים להבין מתי וכיצד לתקשר עם לקוחות, במיוחד בשלבים מוקדמים מעורפלים. מנהיגים בכירים זקוקים להבהרה לגבי המצבים הדורשים את מעורבותם וההחלטות שעליהם עשויים לקבל במהירות תחת מידע חלקי.
הדרכה עובדת בצורה הטובה ביותר כאשר היא משתמשת בספריית האירועים ובכלים האמיתיים שלכם. מעבר על תרחיש כופרה בסביבת הניטור והכרזות האמיתית שלכם יעיל הרבה יותר מאשר מצגת כללית, מכיוון שהצוות רואה בדיוק באילו מסכים, שדות וזרימות עבודה הם ישתמשו כאשר האירוע הבא יופיע.
עיצוב תוכנית אימונים שמרגישה אמיתית
תוכנית תרגיל צריכה לבחון הן את אנשיכם והן את התכנון שלכם על ידי סימולציה של אירועים מציאותיים ומוגבלי זמן המשקפים את בסיס הלקוחות שלכם. על ידי החלפת תרחישים ופלחי לקוחות, אתם בונים ביטחון שגישת A.5.24 שלכם עומדת בתנאים שונים ואתם מייצרים ראיות לכך ש-MSP שלכם מתייחס ברצינות למוכנות.
גוון שלושה ממדים כדי לשמור על משמעות התרגילים:
- סוג תרחיש: – תוכנת כופר בלקוח מפתח, פגיעה בפלטפורמת ניהול משותפת, חשד לדליפת נתונים או תצורה שגויה בענן.
- פלח לקוחות: – לקוחות מוסדרים לעומת לקוחות שאינם מוסדרים, או חשבונות בעלי קריטיות גבוהה לעומת קריטיות בינונית.
- תדירות: – תרגילים פנימיים רבעוניים ותרגילים משותפים מדי פעם עם לקוחות נבחרים בהם הסיכון הוא הגבוה ביותר.
תרגילים משותפים עם לקוחות בעלי ערך גבוה יכולים להיות בעלי עוצמה רבה במיוחד. הם עוזרים להתאים ציפיות, לבחון RACI ולחשוף הנחות חוזיות שאינן עומדות תחת לחץ. הם גם מייצרים ראיות חזקות עבור רואי חשבון וועדות סיכונים לכך שאתם מתייחסים ברצינות למוכנות בסביבות משותפות. תרגילים שמנוהלים היטב נוטים להשאיר אחריהם יומנים, דוחות ופעולות שיפור שגופי פיקוח יכולים לסקור כהוכחה קונקרטית לאופן שבו אתם מתאמנים ומשפרים את תגובתכם.
לאחר כל תרגיל, התייחסו אליו כאל אירוע קטן. תעדו מה עבד, מה לא עבד ומה צריך להשתנות במסמכים, בכלים או בהסכמים. עקבו אחר פעולות אלו והכניסו סיכום לתוכנית סקירת ההנהלה שלכם כדי שתוכלו להראות שיפור לאורך זמן, לא רק פעילות. דפוס זה מקשר את A.5.24 ישירות לסעיפים רחבים יותר של הערכת ביצועים ושיפור ב-ISMS שלכם.
סגירת המעגל במערכת ה-ISMS שלך
הערך האמיתי של A.5.24 מתגלה כאשר תכנון אירועים, הכשרה ותרגילים משלבים את ניהול הסיכונים, פיקוח על ספקים והמשכיות עסקית, ומחזקים את כל מערכת ה-ISMS שלכם. לולאה זו מאפשרת לכם להראות שמוכנות לאירועים היא חלק מהאופן שבו אתם מנהלים את הארגון, ולא עניין טכני מבודד.
סעיף A.5.24 יושב לצד בקרות אחרות הקשורות לאירועים כגון הערכה, תגובה, למידה והמשכיות עסקית, וכולן מזינות את מערכת הניהול שלך כולה. שימוש בתרגילים והדרכה כדי להזין בקרות אלו הופך את עבודת האירועים שלך למניע של שיפור כלל-מערכתי ולא לתהליך מבודד.
לדוגמה, דפוסים מאירועים ותרגילים צריכים להשפיע על הערכת סיכונים, הערכות ספקים ותוכניות המשכיות. בעיות חוזרות ונשנות עם פלטפורמה מסוימת עלולות לעורר ביקורות ספקים או שינויים טכנולוגיים. פערים בהכשרה או בקבלת החלטות עלולים להוביל לשינויים בתוכניות כשירות ומודעות או להתאמות ב-RACI ובכללי ההסלמה שלכם.
ריכוז רישומי אירועים, דוחות תרגילים ופעולות שיפור בפלטפורמה כמו ISMS.online עוזר לכם להפוך את הקישורים הללו לגלויים. זה גם מקל על ההצגה למבקרים כיצד תכנון והכנת האירועים שלכם משפיעים על שאר מערכת ניהול אבטחת המידע שלכם, ומושפעים ממנה, ומספק גשר טבעי לדיונים על האופן שבו טכנולוגיה יכולה לתמוך בשאיפות שלכם במסגרת A.5.24.
הזמן הדגמה עם ISMS.online עוד היום
ISMS.online עוזר לכם להפוך את תקן ISO 27001 A.5.24 מבקרה סטטית ליכולת אירועים חיה ומוכנה ל-MSP שתוכלו להפעיל ולהוכיח על פני כל הלקוחות שלכם. על ידי חיבור מדיניות, RACIs, ספרי הכנה, רישומי אירועים, ראיות ופעולות שיפור בסביבה אחת, אתם מקבלים בסיס למוכנות לאירועים שמתאים לתיק העבודות שלכם ומקל על ההסבר של הגישה שלכם ללקוחות, למבקרים ולחברות ביטוח. האופן שבו הפלטפורמה מארגנת תכנון אירועים, תחומי אחריות ורישומים סביב נספח A.5.24 תוכנן במיוחד כדי לעזור ל-MSPs להדגים הן תכנון והן ביצוע כאשר הם נשאלים.
מה אתם מרוויחים מלראות את ISMS.online בפעולה
צפייה ב-ISMS.online בפעולה היא הדרך המהירה ביותר לשפוט האם יישום מובנה של A.5.24 מתאים לאופן שבו ה-MSP שלכם עובד. סיור ממוקד יכול לעקוב אחר אירוע אמיתי משלב הגילוי ועד לפידוד הלקחים, להראות היכן נמצאים מדיניות ו-RACIs, כיצד רישומי אירועים תואמים למודל הראיות שלכם וכיצד תצוגות הנהלה מאחדות את הכל לצורך פיקוח ודיווח.
סיור קצר וממוקד מאפשר לכם לבחון כיצד גישת ניהול אירועים מובנית תשנה את האירועים האחרונים שלכם. תוכלו לחקור כיצד מדיניות ונהלי אירועים תואמים את A.5.24, כיצד נרשמים RACIs וספרי הפעלה, כיצד רישומי אירועים מקושרים לראיות ולפעולות שיפור, וכיצד נקודות המבט של ההנהלה מאחדות את כל אלה במקום אחד. ראיית האלמנטים הללו יחד מקלה על שיפוט האם זהו עמוד השדרה הנכון למוכנות ה-MSP שלכם לאירועים.
החלטה האם ISMS.online היא הפתרון המתאים
בחירת הפלטפורמה הנכונה עבור A.5.24 היא למעשה החלטה כיצד אתם רוצים שהצוותים והלקוחות שלכם ירגישו מוכנים לאירועים. אם אתם רוצים ניהול אירועים שניתן לביקורת, ניתן להרחבה בין דיירים ומשולב עם מערכת ה-ISMS הרחבה יותר שלכם במקום להיות מותקן מראש, ISMS.online מציעה בסיס מעשי ומותאם לתקנים.
כדאי לכם לבחור ב-ISMS.online כשאתם רוצים מוכנות לאירועים ניתנת לביקורת, ניתנת להרחבה בין דיירים ומשולבת עם מערכת ניהול אבטחת המידע שלכם. אם אתם מעריכים ביקורות עצמאיות, ראיות מובנות ומקור אמת יחיד שתוכלו להראות ללקוחות, רואי חשבון וחברות ביטוח, אנחנו מוכנים לעזור.
שיחה שתעבור על אירוע אמיתי אחד או שניים, וכיצד הם היו יכולים להיראות בתוך מערכת ניהול מידע (ISMS) משולבת, תראה האם זהו הבסיס הנכון לשלב הצמיחה הבא שלכם. כאשר המצב הנוכחי שלכם תואם את הפערים שתוארו קודם לכן ואתם מוכנים לחזק את A.5.24 על ידי הפיכת כאוס של אירועי תקרית ליכולת מובנית ובעלת ערך מסחרי, ISMS.online מוכנה לתמוך בכם.
הזמן הדגמהשאלות נפוצות
כיצד צריך MSP לפרש את ISO 27001:2022 A.5.24 בפעילות היומיומית?
תקן ISO 27001:2022 A.5.24 מצפה מ-MSP שלך הפעלת יכולת אירוע חוזר, לא רק לאחסן "מדיניות אירועים" במערכת ה-ISMS שלך. בפועל, פירוש הדבר שאתה מתכנן, מספק משאבים, מפעיל ובודק באופן קבוע מחזור חיים של אירוע - ויכול להראות שמקרים אמיתיים פעלו לפי תכנון זה.
מה המשמעות של "מתוכנן ומוכן" עבור מנהל רשתות חברתיות (MSP)?
עבור ספק שירותים מנוהלים, A.5.24 נופל על ארבעה תחומים בולטים מאוד:
- עיצוב: – מדיניות ונהל מתועד התואמים למערכת ניהול אבטחת המידע (ISMS) או למערכת הניהול המשולבת (IMS) של נספח L, עם הגדרות ברורות של מה נחשב כ"אירוע אבטחת מידע" בקרב דיירים ושירותים.
- אנשים: – תפקידים בעלי שם שעובדים על פני אזורי זמן ודיירים מרובים, עם בעלים לגילוי, מיון, בלימה, תקשורת, שחזור וסקירה.
- ביצוע: – מחזור חיים שמהנדסים יכולים לעקוב אחריו תחת לחץ מבלי לחפש דרך SharePoint, בדרך כלל זרימה פשוטה מזיהוי ← מיון ← בלימה ← שחזור ← סקירה.
- עֵדוּת: – מערכת תיעוד שקושרת הכל יחד ומראה כיצד אירועים אמיתיים עברו לאורך מחזור החיים הזה.
אם מבקר או לקוח מרכזי מבקשים מהצוות שלך לעבור על התקרית החמורה האחרונה עבור דייר מפתח, עליך להיות מסוגל:
- פתח רשומת אירוע בודדת בכלי ה-ITSM שלך עבור דייר זה.
- הצג חותמות זמן, שינויי מצב, חומרה ותפקידים שהוקצו.
- הצבע על סעיפי מדיניות, RACIs והתאמה ל-A.5.24.
- הצג מה השתנה לאחר מכן - פעולות מתקנות, עדכוני נהלים, שינויים בהדרכה או בחוזה.
ניהול אירועים שמנוהל היטב מרגיש משעמם מבחוץ - משום שההפתעות כבר תוכננו ממנו.
כאשר אתם מנהלים את מדיניות האירועים, הנהלים, התפקידים ורישומי האירועים שלכם יחד ב-ISMS.online, תוכלו להראות ש-A.5.24 אפוי ב-ISMS או ב-ANNEX L של IMS, במקום להיות מסמך לוואי שאתם מנקים לפני ביקורת חיצונית.
כיצד צריך MSP לבנות את תחומי האחריות של האירוע עם כל לקוח תחת A.5.24?
לפי A.5.24, מצופה ממך להתייחס לאחריות לאירוע כאל מודל משותף מעוצב לכל דייר, לא הנחה מעורפלת קבורה בשרשורי דוא"ל. מבקרים ולקוחות ארגוניים יחפשו סימנים לכך שהחלטתם - ותיעדתם - מי עושה מה בכל שלב של אירוע, וששני הצדדים מכירים בחלוקה הזו.
כיצד ניתן לעצב מודל ברור של אחריות משותפת?
שיטה מעשית שעובדת ברוב סביבות ה-MSP היא:
- התחל עם RACI סטנדרטי: שתואם את זרימת האירועים הרגילה שלך: גילוי, מיון, בלימה, מיגור, התאוששות, הודעה, תקשורת וסקירה.
- קבע ברירות מחדל הגיוניות: עבור השירותים המנוהלים שלך, לדוגמה:
- מנהל ה-MSP שלך: אחראי על גילוי ובלימת איומים בתוך פלטפורמות ושירותים מנוהלים.
- הלקוח: אחראי על הודעות רגולטוריות, תקשורת עם לקוחות והחלטות עסקיות המשפיעות על פעילותו.
- משותף: אספקת ראיות, הסכמה על פעולות משבשות, הגדרת מהו "מהותי" או "בר-דיווח".
- התאם על ידי הדייר: במקום להמציא את הגלגל מחדש:
- מגזרים בעלי סיכון גבוה יותר או מוסדרים (פיננסים, שירותי בריאות, מגזר ציבורי) עשויים להזדקק להתחייבויות הודעה מהירות יותר ויותר החלטות משותפות.
- צוותי אבטחה פנימיים מתוחכמים עשויים לרצות יותר שליטה; לקוחות קטנים יותר עשויים לצפות שתנהגו כמעט בכל דבר.
RACIs אלה צריכים להיות ממוקמים במקום שבו הצוותים ימצאו ויתחזקו אותם בפועל - בדרך כלל בתוך ISMS או IMS שלכם, המקושרים ל-A.5.24, בקרות ספקים כגון A.5.19 ותיאורי השירות הרלוונטיים.
כיצד הופכים אחריות משותפת לגלויה במהלך אירועים אמיתיים?
פיצול מתוכנן עוזר רק אם הוא נראה בכלים ובחפצים שאנשים נוגעים בהם תחת לחץ:
- חוזים והסכמי רמת שירות: התייחסו למודל האירועים המשותף וקבעו ציפיות לזמני זיהוי, התראה ותגובה.
- תבניות כרטיסים: לכלול שדות כגון "בעל אירוע לקוח", "בעל הודעה רגולטורית", "מאשר עסקי לפעולות משבשות" ו"מוביל תקשורת".
- ספרי משחק: לציין מי מפעיל איזו החלטה, מי מדבר עם איזו קבוצת בעלי עניין, ואילו אישורים נדרשים בכל שלב.
כאשר ניתן להראות שאותו עיצוב משותף מופיע באופן עקבי בחוזים, RACI, שדות כרטיסים, ספרי התקנות ורישום אירועים ספציפיים לשוכר עדכני, ניתן לסמוך בקלות על A.5.24 עבור מבקרים וקניינים גדולים - וקל הרבה יותר עבור הצוותים שלכם לעקוב אחריו על פני מאות לקוחות.
אילו מדריכי הפעלה ו-runbooks של אירועים באמת צריך MSP עבור A.5.24?
A.5.24 לא מתגמל ויקי נפוח שאף אחד לא פותח ב-2 לפנות בוקר. הוא מצפה סט רזה של ספרי משחק וספרי ריצה שמכסים את האיומים הסבירים ביותר שלך, בהתאם לשירותים שאתה מפעיל בפועל ולכלים שבהם משתמשים בפועל מערכות ההפעלה (SOC) והמהנדסים שלך.
רוב ספקי שירותי ניהול הרשת (MSP) מקבלים כיסוי חזק עם 4-7 ספרי הכנה מעוצבים היטב המותאמים לסביבות המנוהלות שלהם, לדוגמה:
- תוכנות כופר או תוכנות זדוניות הרסניות: בנקודות קצה או שרתים מנוהלים.
- פגיעה בדוא"ל עסקי: – השתלטות על חשבון, עייפות ממשרד עורכי דין, כללי העברת מידע מסוכנים.
- פגיעה בחשבון מורשה: – מנהלים, חשבונות שירות, זהויות שבירות זכוכית.
- חשד לגניבת נתונים: מענן מנוהל או מסביבה מקומית.
- תקרית בפלטפורמה מרובת דיירים: – כאשר כלי או שירות נפוץ מתנהג בצורה לא תקינה והאבטחה עשויה להיות הגורם השורשי או לא.
- פשרה של SaaS על ידי צד שלישי: שמשפיע על מספר דיירים דרך המחסנית המנוהלת שלך.
כל ספר הדרכה צריך לענות על אותן שאלות יסוד:
- מה בדרך כלל מעורר את התרחיש הזה?
- מי מוביל ומי תומך, בתוך הארגון שלך ובצד הלקוח?
- כיצד מסווגים את חומרת המצב ומתי מחמירים את המצב?
- מתי וכיצד אתם מערבים את הלקוח, את התפקידים המשפטיים ואת תפקידי הפרטיות?
- אילו אישורים נדרשים לפני נקיטת פעולות בעלות השפעה גבוהה, כגון בידוד או מחיקת נתונים?
- איזה מידע יש ללכוד ברישום האירוע בכל שלב כדי לעמוד בדרישות A.5.24 ובבקרות שכנות?
כיצד עליך לבנות ולתחזק runbooks עבור כלים ספציפיים?
ספרי משחק מתארים מי עושה מה ומתי ברמת התרחיש; לכידת ספרי ריצה אֵיך לבצע פעולות ספציפיות בכל פלטפורמה:
- בידוד מכשיר בפתרון EDR או ניהול נקודות הקצה שלך.
- נעילה ואיפוס זהויות בספקי ענן גדולים.
- לכידת תמונות לוגים וטלמטריה מ-SIEM, חומת אש או פרוקסי.
- בדיקה וניקוי של כללי תיבות דואר חשודות ויעדי העברה.
שמירה על מדיניות, ספרי משחק וספרי ריצה נפרד אך מקושר צולב בתוך ISMS.online יש יתרונות ברורים:
- ממשל (ניסוחי מדיניות ובקרה) נשאר יציב בעוד הטכנולוגיה משתנה.
- מהנדסים יודעים בדיוק היכן לחפש "מהו הצעד הבא הנכון?" לעומת "איזה פקודה או כפתור קונסולה עליי להשתמש?".
- ניתן להציג למבקרים שרשרת נקייה מטקסט מדיניות A.5.24 → מדריך ברמת התרחיש → מדריך ספציפי לפלטפורמה → כרטיסי אירוע אמיתיים שבהם נעשה שימוש בארטיפקטים אלה.
אם המאגר הנוכחי שלכם רחב ידיים או מיושן, התחלה עם ספרייה ממוקדת שתואמת את האירועים הנפוצים ביותר שלכם תעזור יותר עבור A.5.24 - ועבור הלקוחות שלכם - מאשר רשימה ארוכה של מסמכים שנוגעים בהם לעתים רחוקות.
כיצד יכול ספק שירותי ניהול רשתות (MSP) להטמיע את A.5.24 בתפעול כרטיסים, ניטור ו-SOC מבלי להאט את המהנדסים?
אתה הופך את A.5.24 לחלק מעבודה רגילה על ידי התייחסות לתיעוד אירועי ה-ITSM שלך כמקור האמת היחיד וחיווט כלי ניטור ושיתוף פעולה סביבו. רישום האירועים מספר את כל הסיפור; קונסולות, לוחות מחוונים וצ'אט לוכדים את העומק הטכני שמאחורי אותו קומה.
מה צריך לכלול רישום אירוע המותאם לתקן A.5.24?
בכלי ה-ITSM או בכלי שירות הלקוחות שלכם, הגדירו סוג ייעודי של "אירוע אבטחת מידע" המשקף את התהליך המתועד שלכם:
- תחומי ליבה: עבור הדייר, הסביבה, השירות המושפע, חומרתו, רגישות הנתונים ורלוונטיות רגולטורית פוטנציאלית.
- זרימת מצב: שמשקף את ההליך שלך (לדוגמה: חדש ← מיון ← חקירה ← בלימה ← התאוששות ← סקירה ← סגור).
- שדות חובה ורשימות תיוג: במעברים מרכזיים:
- האם הושלמה סקירה לפני הסגירה?
- אם האירוע כלל מידע אישי, האם נערך הליך התייעצות עם גורמי הפרטיות?
- האם עמדו בלוחות הזמנים שסוכמו להודעה?
- סיכומים וקישורים: עבור:
- פעולות ואישורים מרכזיים, עם מי אישר מה ומתי.
- תקשורת עם לקוחות, כולל ערוצים וזמנים.
- התראות, מקרים או מקורות יומן בסיסיים המאוחסנים במקום אחר.
קטגוריות ותגיות ספציפיות לאבטחה מאפשרות לכם להפריד בין אירועי אבטחת מידע לבין הפסקות פעילות כלליות. זה מקל מאוד על דיווח על מגמות, הוכחת מוכנות למבקרים וקידום שיפורים במערכת ניהול אבטחת המידע שלכם.
כיצד כלי ניטור ו-SOC משתלבים סביב העיצוב הזה?
ברגע שיש לכם סוג וזרימה ברורים של רשומה, אתם מחליטים אילו התראות צריכות ליצור או להעשיר רישומי אירועים, כגון:
- גילוי בעל השפעה גבוהה או רמת ביטחון גבוהה מכלי SIEM, EDR או אבטחת ענן מעלה באופן אוטומטי כרטיסי אירוע המאוכלסים מראש.
- אותות בדרגת חומרה נמוכה יותר מקובצים לסקירת אנליסטים, עם נתיב קידום קל ל"תקרית" כאשר מתקיימים קריטריונים מסוימים.
- אינטגרציות שמוסיפות הקשר - משתמשים או מכשירים שנפגעו, אירועים מתואמים, חפצי ראיות - בחזרה לרשומה הראשית במקום להשאיר הכל לכוד בצ'אט או בקונסולות בודדות.
אם הצוות שלכם משתמש בצ'אט או בגישורים וירטואליים במהלך טיפול בזמן אמת, יש תמיד לדחוס סיכום קצר של החלטות ואישורים בחזרה לרשומת האירוע, כך שתוכלו להדגים שליטה כאשר מישהו יבחן את המקרה חודשים לאחר מכן.
כאשר אתם מעצבים את הזרימה הזו פעם אחת, מחברים אותה ל-A.5.24 ולבקרות הקשורות אליה ב-ISMS.online, ומאמןים את ה-SOC ואת דלפק השירות שלכם להתייחס לרשומת האירועים כ"מקום בו נמצאת הקומה", אתם עומדים בדרישות הבקרה מבלי להוסיף תקורה בירוקרטית למהנדסים.
אילו ראיות צריך MSP לשמור כדי להדגים בצורה משכנעת את מוכנות האירוע ל-A.5.24?
A.5.24 נבדק בדרך כלל באמצעות אירועים אמיתיים אחרונים, לא רשימות תיוג תיאורטיות. רואי חשבון, חברות ביטוח ולקוחות גדולים בדרך כלל יבחרו מקרה אחד או שניים ויבקשו מכם להראות כיצד הם התפתחו אל מול גישת האירועים המתועדים שלכם.
כיצד נראית מערכת ראיות חזקה עבור כל אירוע?
עבור כל אירוע מהותי – במיוחד כאלו הכרוכים במידע רגיש או שיבוש משמעותי – עליך להיות מסוגל להציג:
- רישום האירוע העיקרי:
- חותמות זמן, שינויי מצב וחומרה.
- הקצאת תפקידים ומסירות בין משמרות או צוותים.
- תיאור קצר של מה שקרה ומדוע התקבלו החלטות מפתח.
- חפצים טכניים מקושרים:
- התראות SIEM או EDR, מזהי מקרים וייצוא סיכום.
- קטעי יומן רלוונטיים או הערות פורנזיות, או הפניות למקום שבו נתונים אלה נשמרים בצורה מאובטחת.
- היסטוריה של פנייה ללקוח:
- מי עודכן, מתי ובאיזה ערוץ.
- כיצד עמדת או חרגת מלוחות הזמנים של ההודעה החוזית.
- כל דוחות מעקב או סיכומי פגישה ששותפו עם הלקוח.
- תוצרי סקירה ושיפור:
- שורש הבעיה הסבירה, גורמים תורמים וסיכון שיורי.
- פעולות תיקון ושיפור ספציפיות, עם בעלים ותאריכי יעד.
- עדכונים שבוצעו בספרי משחק, חוזים, תבניות או RACI כתוצאה מכך.
עבור רוב ספקי שירותי ניהול רשתות (MSPs), האתגר הוא עקביות ולא נפח. כמה קבצים מצורפים וקריאות שנבחרו בקפידה שתומכים בבירור בעלילה שווים הרבה יותר מעשרות קבצי יומן לא מובנים.
כיצד ניתן להימנע מטביעה בראיות על פני דיירים ושירותים רבים?
אתה שומר על ראיות ניתנות לניהול על ידי סטנדרטיזציה של דפוסים לפי פלח לקוחות:
- הגדירו על אילו מקורות יומן ופלט ניטור אתם מסתמכים עבור סוגים שונים של שירותים (נקודת קצה מנוהלת, שכירות ענן, רשת).
- תקניזציה של האופן שבו מתייחסים לחפצים אלה או אופן ההפניה אליהם או אופן ההצמדה אליהם בתוך רישומי האירועים.
- קבע תקופות שמירה ובקרות גישה התואמות את ההתחייבויות החוקיות והחוזיות עבור כל פלח.
סקירות ראיות תקופתיות – שבהן לוקחים אירוע סגור באופן אקראי ושואלים "האם צד חיצוני היה מוצא את זה שלם ואמין?" – חושפות לעתים קרובות שינויים קטנים בעיצוב עם יתרונות גדולים.
כאשר אתם מנהלים את מודל ראיות האירועים שלכם, את המדיניות הרלוונטית ואת מיפויי A.5.24 יחד ב-ISMS.online, תוכלו להראות למבקרים וללקוחות אסטרטגיים שהמוכנות היא עקבית ומודעת לשוכרים, ולא משהו שאתם ממהרים לשחזר כשמגיעים שאלון או תביעה.
כיצד אימון ותרגילים עוזרים ל-MSP לעבור מעמידה בניירות ערך לעוצמה אמיתית תחת A.5.24?
אימונים ותרגילים הם המקום שבו A.5.24 הופך מתיעוד לרפלקסיםהבקרה מדברת על תכנון והכנה; עבור MSP, פירוש הדבר שצוותים בתפקידים שונים תרגלו אירועים מציאותיים תוך שימוש בכלים, רשומות וספרי נהלים בפועל, ולא רק קראו מדיניות פעם בשנה.
אילו גישות אימון עובדות בצורה הטובה ביותר עבור צוותי MSP?
מפגשים קצרים וספציפיים לתפקיד כמעט תמיד עדיפים על מצגות גנריות ארוכות:
- אנליסטים ומהנדסים: להריץ התראות מדומות במחסנית הניטור שלך, להעלות ולעדכן רישומי אירועים, ולפעול לפי ספרי הפעולות שלב אחר שלב עד שהדפוס מרגיש טבעי.
- מנהלי לקוחות ובעלי שירותים: לתרגל עדכוני לקוחות בלחץ זמן במהלך הפסקה או פגיעה ריאליסטית, תוך שימוש במידע שהם היו רואים בכרטיסים ובלוחות מחוונים.
- עמיתים לתחום המשפט, הפרטיות והתאימות: לבצע תרגולים של החלטות הודעה עם מידע חלקי, בהתבסס על מה שנקלט בפועל ברישומי האירועים וביומני האירועים שלכם.
- מנהיגים בכירים: תרגול מתי להצטרף לגשרים, כיצד לאשר בלימה משבשת במהירות וכיצד ליישר קו בין מסרים פנימיים וחיצוניים.
מפגשים אלה בונים ביטחון שכאשר אירוע רציני פוגע באדם מרכזי, אנשים יודעים בדיוק היכן לחפש ומה לעשות, במקום לבזבז זמן בדיונים על צעדים בסיסיים.
כיצד עליכם לתכנן תוכנית אימונים שתעמוד בדרישות A.5.24 מבלי להעמיס על הצוותים שלכם?
אינך זקוק לתוכנית משחקי מלחמה מורכבת; לוח שנה פשוט וגלוי מספיק לעתים קרובות:
- סימולציות פנימיות לפחות פעם בשנה עבור התרחישים בעלי ההשפעה הגבוהה ביותר שלך (לדוגמה, תוכנת כופר, פריצת דוא"ל עסקית, הפסקת חשמל משמעותית בפלטפורמה).
- תרגילים משותפים מזדמנים עם לקוחות בעלי חשיבות אסטרטגית או לקוחות מוסדרים, מה שהופך את RACIs, נתיבי הסלמה ודפוסי תקשורת לממשיים עבור שני הצדדים.
- דוחות קצרים לאחר כל תרגיל שמתעדים:
- מה שעבד טוב ויש לחזק אותו.
- היכן שתפקידים, מידע או כלים היו מבלבלים או איטיים.
- מספר קטן של שיפורים קונקרטיים ב-RACIs, ספרי השמעה, תבניות כרטיסים, רישום או חוזים.
פעולות שיפור אלו צריכות להשתלב במנגנוני ISO 27001 הרגילים שלכם - תוכניות טיפול בסיכונים, יומני פעולות מתקנות, סקירות הנהלה - כך שתוכלו להדגים לולאה מלאה, מהתכנון ועד לבדיקות ועד לשיפור.
כאשר אתם מתכננים, מעבירים ועוקבים אחר הפגישות הללו בתוך ISMS.online לצד מדיניות A.5.24, ספרי ההדרכה ורישומי האירועים שלכם, אתם מציגים קומה ברורה למבקרים, רגולטורים וקניינים ארגוניים: מוכנות לאירועים מתוכננת, מופעלת ומתחזקת כחלק ממערכת ניהול אבטחת המידע שלכם, ולא נותרת ליד המקרה. וזה בדיוק המצב שבו ספק שירותים מנוהלים מודרני רוצה להיות כאשר מגיע אירוע רציני או לקוח תובעני.
