מציאות הכופר החדשה עבור ספקי שירותי ניהול שירותים (MSPs)
תוכנות כופר מתייחסות יותר ויותר ל-MSP שלכם כאל הנתיב המהיר ביותר לעשרות סביבות לקוח בו זמנית. תוקפים מכוונים לגישה מרחוק, פלטפורמות ניהול וחשבונות מנהל משותפים שלכם, כך שפגיעה אחת יכולה להתפשט על פני דיירים רבים. משמעות הדבר היא שהגנה מפני תוכנות זדוניות "טובה מספיק" כבר אינה רק בחירה של מוצר קצה; זוהי היכולת שלכם להכיל אירוע לפני שהוא הופך למשבר מרובה דיירים ולהראות ללקוחות ולמבקרים שאתם יכולים לעשות זאת באופן עקבי.
שינוי זה חשוב משום שהוא משנה את מה שנראה כ"מספיק טוב". כלי נקודות קצה כשלעצמם הם רק מרכיב אחד בבקרה רחבה יותר: כיצד מגדירים אותם, כיצד מנטרים אותם, כיצד מגיבים וכיצד מדגימים את כל זה לאחרים. במקביל, לקוחות, חברות ביטוח ומבקרים שואלים שאלות קשות יותר לגבי האופן שבו מאבטחים נקודות קצה בפועל, לא רק איזה לוגו של מוצר מופיע במצגת. הערכות איומים של אכיפת החוק, כמו הערכת איומי הפשע החמור והמאורגן של יורופול, מדגישות שקבוצות כופר מאורגנות מכוונות יותר ויותר לספקי שירותים ולמתווכים כדי למקסם את ההשפעה על הקורבנות, וזה בדיוק התפקיד שתופסים מנהלי שירותי כופר.
כמעט כל המשיבים בדוח מצב אבטחת המידע לשנת 2025 מפרטים השגה או שמירה על אישורי אבטחה כגון ISO 27001 או SOC 2 כעדיפות עליונה.
אבטחה חזקה תלויה לעתים קרובות פחות ברכישות חדשות ויותר בשמירה על עקביות בכלים הקיימים שלך.
מדוע מנהלי שירותי רשת (MSPs) הם מטרות עיקריות
תוקפים מתמקדים בספקי שירותי ניהול שירותים (MSP) משום שפגיעה בגישה ובאוטומציה שלכם מעניקה להם טווח הגעה שקשה להשיג קורבן אחד בכל פעם. פלטפורמת הניטור והניהול מרחוק שלכם, חשבונות השירות המועדפים ומנגנוני העדכון אטרקטיביים משום שהם מאפשרים לתוקף לעבור ממארח פרוץ אחד לאזורי לקוחות רבים במהירות מדאיגה. דוחות מגמות של תוכנות כופר בתעשייה מתארים שוב ושוב קמפיינים שבהם גורמי איום מנצלים לרעה גישת MSP או RMM כדי לספק מטענים ללקוחות רבים בפעולה אחת, במקום לתקוף כל ארגון בנפרד.
רוב הארגונים בסקר מצב אבטחת המידע לשנת 2025 אומרים שכבר הושפעו מלפחות אירוע אבטחה אחד של צד שלישי או ספק בשנה האחרונה.
קמפיין מודרני לעיתים קרובות מקשר מספר שלבים. זה יכול להתחיל עם גניבת פרטי טכנאי או פישינג, לאחר מכן לנצל לרעה את ניהול מרחוק, להשבית סוכני נקודות קצה ולבסוף לדחוף מטענים זדוניים דרך ערוצי העדכון או הסקריפטים שלך. ברגע שתדמיין את הרצף הזה, כדאי לשאול שאלה ישירה: אם נקודת קצה אחת בעלת זכויות יוצרים בסביבה שלך נפגעת, עד כמה יכול תוקף להגיע באופן סביר באמצעות הגישה והאוטומציה שאתה מסתמך עליהן מדי יום?
ניסוי המחשבה הזה לא נועד להבהיל אתכם; הוא נועד להדגיש היכן באמת נמצאות ההגנות הנוכחיות שלכם. אם התשובה הכנה היא "מעבר לגבולות שהיינו רוצים", נספח A.8.7 הוא אחד המנופים בהם תוכלו להשתמש כדי להדק את הקומה הזו בצורה מובנית וניתנת לביקורת.
מהתקנת AV להפעלת בקרה
A.8.7 דוחף אותך מלהיתקנת אנטי-וירוס בכל מקום להפעלת בקרת תוכנות זדוניות חוזרת ונשנית שאנו יכולים להסביר ולהוכיח. משמעות הדבר היא להגדיר מה כל נקודת קצה מנוהלת חייבת לפעול, כיצד היא צריכה להתנהג וכיצד לאשר את ההתנהגות הזו בין דיירים, במקום להסתמך על העדפות של מהנדסים בודדים או על בחירות מוצר היסטוריות.
עבור ספקי שירותים רבים (MSP), אבטחת נקודות הקצה צמחה באופן אורגני. מהנדסים שונים העדיפו ספקים שונים, חלק מהלקוחות התעקשו לשמור על מוצר אנטי-וירוס ישן, והגדרות הבסיס התבססו על ידע שבטי ולא על תקן כתוב. ההנחה הלא מדוברת הייתה שאנטי-וירוס בכל מקום שווה ערך לתאימות ולטיפול סביר.
נספח A.8.7 שובר את האשליה הזו. הבקרה מצפה שהגנה מפני תוכנות זדוניות תוכנן, תיושם ונתמך על ידי מודעות המשתמש באופן שניתן להדגים. סיכומים של עדכון ISO 27001:2022 מציינים כי בקרות נספח A המעודכנות, כולל A.8.7, שמות דגש רב יותר על אמצעים טכניים מיושמים ומוכחים לצד מודעות המשתמש, במקום פשוט לתת שם למוצר. בפועל, משמעות הדבר היא שאתם:
- הגדר מה כל נקודת קצה מנוהלת חייבת להפעיל.
- קבעו כללים ברורים לעדכונים, סריקות ותגובות.
- אסוף ראיות לכך שהדברים האלה באמת קורים.
ברגע שאתם מקבלים את השינוי הזה, השיחה מפסיקה לעסוק בשאלה איזה ספק הוא הטוב ביותר ומתחילה לעסוק באופן שבו אתם ממקמים סטנדרטיזציה של התנהגות בכל המכשירים והדיירים שאתם מטפלים בהם.
הזמן הדגמהמה ISO 27001:2022 A.8.7 דורש בפועל משירותי MSP
עבור MSP, A.8.7 מצפה ממך להפעיל הגנה מפני תוכנות זדוניות כבקרה מתועדת ומנוטרת המשלבת טכנולוגיה, תצורה, תהליך ומודעות למשתמש, ושתוכל להדגים אותה למבקרים וללקוחות במקום רק לציין שאתה "משתמש בכלי EDR". פרשנות על עדכון 2022 של ISO 27001 מדגישה כי נספח A.8.7 נועד להניע בקרות תוכנות זדוניות מתועדות ומנוטרות הנתמכות על ידי מודעות המשתמש, ולא סימון פשוט המציין שקיימת צורה כלשהי של אנטי-תוכנה זדונית. למרות שנספח A.8.7 קצר בתקן, כוונתו ברורה: ליישם הגנה מפני תוכנות זדוניות, לגבות אותה במודעות מתאימה למשתמש כך שמידע ונכסים קשורים אחרים יהיו מוגנים, ולהיות מסוגל להסביר ולהראות את השילוב הזה בפעולה. אם אתה מארח, מפעיל או מנהל אבטחת נקודות קצה עבור לקוחות, השירותים שלך הם חלק עיקרי באופן שבו הם עומדים ב-A.8.7, והשאלה האמיתית היא לא רק האם אתה משתמש בכלים מודרניים, אלא האם הכלים, ההגדרות והתהליכים שלך יחד מספקים את מה שהבקרה מצפה.
דו"ח מצב אבטחת המידע לשנת 2025 מציין כי לקוחות מצפים יותר ויותר מספקים להתאים את עצמם למסגרות פורמליות כגון ISO 27001, ISO 27701, GDPR, Cyber Essentials ו-SOC 2, לצד סטנדרטים מתפתחים של בינה מלאכותית.
השליטה בשפה פשוטה
בהסרה של הניסוח הפורמלי, A.8.7 מצפה ממך לפרוס הגנה מתאימה מפני תוכנות זדוניות, לשמור על יעילותה, לנטר את מה שהיא מוצאת ולתמוך במשתמשים כך שסיכוני תוכנות זדוניות יישארו בגבולות מקובלים. היא מתעניינת באופן שבו אנשים מתנהגים וכיצד אתה מגיב בדיוק כמו שהיא מתעניינת בסוכן המותקן במכשיר. במונחים מעשיים, הבקרה מבקשת ממך:
- התקינו הגנה מתאימה מפני תוכנות זדוניות או הגנה מפני נקודות קצה במערכות הרלוונטיות.
- שמרו על הגנות אלו מעודכנות ותצורתן מאובטחת.
- לנטר גילויים ואירועים ולהגיב בזמן.
- לעזור למשתמשים לזהות ולדווח על פעילות חשודה.
מבחינתך, זה מעלה מיד שאלות מעשיות. היכן הציפיות הללו מלוטשות במדיניות ובתקנים שלך? האם תיאורי השירות וספרי הניהול שלך תואמים אותן? כאשר לקוח שואל כיצד אתה תומך בתאימות שלו, האם תוכל להצביע על מסמכים ולוחות מחוונים ספציפיים המציגים את A.8.7 בפעולה, במקום רק לצטט שמות כלים?
כיצד רואי חשבון מפרשים את A.8.7 עבור מנהלי רשתות חברתיות (MSPs)
מבקרים בדרך כלל מחפשים כמה נושאים עקביים בעת הערכת A.8.7 בסביבות MSP. הם רוצים לראות שאתם והלקוחות שלכם הגדרתם כיצד הגנה מפני תוכנות זדוניות צריכה לפעול, יישמתם אותה באופן עקבי, תמכו בה במודעות המשתמשים ובדקתם באופן קבוע שהיא עדיין פועלת כמתוכנן. עבודת פיקוח רחבה יותר על ביקורות ואחריות מדגישה לעתים קרובות את אותה תבנית: מדיניות ותקנים ברורים, קווי בסיס מוגדרים וראיות לכך שהבקרות פועלות כמתואר, ומבקרים רבים במגזר הפרטי מיישמים ציפיות דומות כאשר הם בוחנים בקרות אבטחה.
בהקשר של MSP, משמעות הדבר היא לעיתים קרובות בחינת מדיניות אבטחת תוכנות זדוניות או נקודות קצה, תצורות הבסיס עבור סוגי מכשירים שונים, דגימת נקודות קצה כדי לאשר שהסוכנים והמדיניות מיושמים, וסקירת רישומי אירועים, יומני הדרכה וקמפיינים להגברת המודעות. כאשר השירותים שלכם הם חלק ממערכת ניהול המידע (ISMS) של הלקוח, מבקרים יבדקו כיצד חלוקת האחריות: אילו נקודות קצה אתם מאבטחים, אילו מהן הלקוח מנהל, וכיצד אתם מתאמים אירועים, הדרכות וחריגים.
אם התשובות שלכם מפוזרות על פני קטלוגי שירותים, מיילים וזיכרונות של מהנדסים, תמצאו את השאלות האלה מלחיצות. אם במקום זאת תתייחסו ל-A.8.7 כבעיית תכנון שירות, תוכלו להכין קוהרנטיות הרבה לפני שמופיע תאריך הביקורת. פלטפורמת ISMS כמו ISMS.online יכולה לעזור לכם לתעד את הציפיות הללו, לקשר אותן לנספח A.8.7 ולשמור על ראיות תואמות לבקרה כך שיהיה לכם נרטיב עקבי מוכן כשמישהו שואל "הראה לי".
סקירה כללית זו היא מידע כללי אודות A.8.7, ואינה מספקת ייעוץ משפטי או ייעוץ בנוגע להסמכה. לקבלת החלטות מחייבות, עליך תמיד להתייעץ עם התקן הרשמי, ובמידת הצורך, עם יועצים מוסמכים.
ISO 27001 בקלות
יתרון של 81% מהיום הראשון
עשינו את העבודה הקשה בשבילך, ונתנו לך התחלה של 81% מרגע הכניסה. כל שעליכם לעשות הוא להשלים את החסר.
וקטורי איום A.8.7 מצפים שתכסה את כל הדיירים
A.8.7 מצפה שתבין את הנתיבים העיקריים שבהם תוכנות זדוניות יכולות להיכנס ולנוע בתוך הסביבה שלך ושל הלקוחות שלך, ולהציב בקרות הגיוניות ומפוקחות סביב נתיבים אלה. עבור ספק שירותי ניהול (MSP), פירוש הדבר הוא להסתכל מעבר ל"קבצים זדוניים" ולשקול דוא"ל, אינטרנט, כלים מרוחקים, מדיה נשלפת וניצול לרעה של תכונות ניהול לגיטימיות על פני מספר דיירים.
תוכנות זדוניות מגיעות לנכסים המנוהלים שלך דרך מספר קטן של נתיבים חוזרים שבהם משתמשים תוקפים שוב ושוב. הן מגיעות דרך דוא"ל, דפדפנים, מסמכים, מדיה נשלפת, ניהול מרחוק ואפילו כלים לגיטימיים שנעשה בהם שימוש לרעה בידיים הלא נכונות. הנחיות של אנשי מקצוע בנוגע לבניית תוכניות הגנה מפני תוכנות זדוניות מגלות באופן עקבי שרוב האירועים בעולם האמיתי נובעים מקבוצה קטנה יחסית של וקטורי הדבקה חוזרים, מה שמחזק את הערך של התמקדות בנתיבים אלה תחילה במקום לנסות לכסות כל תרחיש היפותטי בבת אחת. סעיף A.8.7 מצפה ממך לשקול את כל הווקטורים הרלוונטיים בסביבה שלך ולבחור אמצעים שמפחיתים את הסיכון לרמה מקובלת, בהתבסס על ניסיון מהעולם האמיתי ולא על תיאוריה בלבד.
עבור ספק שירותי ניהול מערכות (MSP), וקטורים אלה משתרעים הן על התשתית שלך והן על נכסי הלקוחות שלך. לכן, סטנדרטיזציה של הגנה מתחילה במתן שמות לדרכים שבהן תוכנות זדוניות יכולות להגיע ולנוע באופן מציאותי בין המערכות שאתה מנהל, ובבדיקת האופן שבו הבקרות הנוכחיות שלך עומדות בסטנדרטים אלה.
נתיבי תוכנות זדוניות מרכזיים בעיזבונות MSP
בסביבות MSP רבות, מספר מסלולים מובילים לרוב האירועים בעולם האמיתי: הודעות דוא"ל וקבצים מצורפים של פישינג, הורדות אינטרנט מאתרים פרוצים או מזויפים, שימוש לרעה בכלי גישה מרחוק ובסוכני ניטור וניהול מרחוק, מדיה נשלפת נגועה או לא מהימנה, ושימוש לרעה בכלי ניהול קיימים. הבנת האופן שבו כל אחד מהם מופיע בסביבה שלך מעניקה לך נקודת התחלה מעשית להגדרת קווי הבסיס שלך ב-A.8.7. חומרי הגנה קהילתיים מפני תוכנות זדוניות מדגישים שוב ושוב את אותם וקטורים כמקורות הדבקה דומיננטיים, מה שאמור לתת לך ביטחון שההתמקדות בהם תחילה תואמת את החוויה בעולם האמיתי.
אינכם צריכים להמציא מחדש את מודיעין האיומים כדי להתחיל. צעד מעשי הוא לנקוט בדרכים אלו ולשאול, עבור כל אחת מהן:
- מה אנו מצפים שיקרה היום אם נעשה שימוש בווקטור הזה?
- כיצד אנו יודעים שהציפייה מתממשת בסביבות חיות?
- מי אחראי לתקן פערים כשאנחנו מוצאים אותם?
אם התשובה עבור מדיה נשלפת היא "תלוי מי התקין את המכונה", או עבור גישה מרחוק היא "אנחנו סומכים על הטכנאים שלנו שלא יעשו טעויות", זהו סימן לכך שהטמעת A.8.7 שלכם ממוקדת בכלים ולא בשליטה.
טבלה פשוטה יכולה לעזור לך לבנות את החשיבה הזו:
| וקטור | איך זה נראה בשבילך | בקרות בסיס אופייניות |
|---|---|---|
| פישינג / קבצים מצורפים | משתמשים בפלטפורמות דואר מנוהלות ופרודוקטיביות | סינון דוא"ל, סריקת קבצים מצורפים, הדרכת משתמשים |
| הורדות מהאינטרנט | גלישה ממחשבים ניידים ונייחים מנוהלים | סינון אתרים, סינון DNS, הקשחת דפדפנים |
| גישה מרחוק / RMM | טכנאים המשתמשים בכלים מרוחקים במערכות לקוח | אימות חזק, אישורים וניטור פעילות |
| מדיה נשלפת | התקני USB המחוברים לנקודות קצה | בקרת פורטים, הפעלה אוטומטית מושבתת, סריקה בעת הכנסה |
| שימוש לרעה בכלי ניהול | קונסולות סקריפט וניהול המשמשות לשינויים בכמות גדולה | בקרת יישומים, רישום, גישה עם הרשאות מוגבלות |
המטרה אינה שלמות ביום הראשון; היא להפוך את הנסתר למפורש, כך שתוכלו לראות היכן קווי הבסיס הנוכחיים שלכם תואמים והיכן אינם תואמים את הסיכון שלכם.
כיצד וקטורים אלה מתואמים ל-A.8.7
תחת A.8.7 עליך להגדיר כיצד אתה מגן מפני נתיבי תוכנות זדוניות חשובים בסביבתך ולהראות שהגנות אלו מיושמות בפועל. משמעות הדבר היא שחשבת על הווקטורים העיקריים, בחרת הגנות מתאימות ויכולת להדגים שהן קיימות ועובדות. מחקר על ניהול אבטחת סייבר מבוסס סיכונים תומך בהתאמת עומק ותמהיל הבקרות לפרופיל הסיכון של הנכס והארגון, במקום לנסות לאכוף בקרות "מקסימליות" זהות בכל מקום ללא קשר להקשר.
עבור ספקי שירותי ניהול שירותים (MSPs), משמעות הדבר היא בדרך כלל ציפיות מתועדות בנוגע לסינון דוא"ל ואינטרנט, סוכני נקודות קצה, שימוש בטוח במדיה נשלפת, ניהול מרחוק מאובטח, ונהלי ניטור, תגובה ומודעות משתמשים כאשר מתגלות התקפות. אינכם זקוקים לאמצעים זהים עבור כל לקוח. עסק מקומי קטן עם חשיפה חיצונית מוגבלת עשוי באופן סביר להפעיל מערכת פשוטה יותר מאשר מוסד פיננסי מוסדר.
מה שחשוב הוא שתוכלו להסביר, על סמך סיכונים, מדוע לדייר נתון יש שילוב מסוים של בקרות, ושתוכלו להדגים שבקרות אלו קיימות ועובדות. אם תצליחו לעשות זאת, אתם בדרך הנכונה לעמידה בדרישות A.8.7 באופן שירגיש אמין הן בביקורות והן בשיחות עם לקוחות.
מסגור מחדש של A.8.7 כבעיית עיצוב וממשל שירות MSP
אתם מקבלים את הערך הרב ביותר מ-A.8.7 כאשר אתם מתייחסים להגנה מפני תוכנות זדוניות כשירות מתוכנן ומוסדר שאתם מספקים ללקוחות, ולא כתיבת סימון בביקורת של מישהו אחר. ברגע שתראו את זה ככה, תוכלו לתקנן רכיבים, להבהיר תחומי אחריות ולשפר את הרווחיות במקום להילחם באותן שריפות בדרכים מעט שונות עבור כל דייר.
ספקי שירותים רבים פוגשים לראשונה את A.8.7 דרך שאלת ביקורת של לקוח או גיליון אלקטרוני של RFP. השאלון מופיע כשורה ששואלת האם אתם "מגנים מפני תוכנות זדוניות" ובאילו כלים אתם משתמשים. אם תתייחסו אליו רק כתיבת סימון, תפספסו את ההזדמנות להפוך אותו לשירות סטנדרטי ומבדיל שמפחית סיכונים ומשפר את הרווחיות.
במקום זאת, כדאי לחשוב על A.8.7 כמתאר שירות שאתם מספקים: שירות הגנה מפני תוכנות זדוניות עם רכיבים, אחריות וראיות מוגדרים, המסופק באופן עקבי על פני כל הדיירים.
תחשבו על שירותים, לא על כלים
חשיבה בשירותים מאלצת אותך להגדיר כיצד כל החלקים הנעים משתלבים יחד, לא רק אילו מותגים אתה מתקין. כלים הם חלק מהתשובה, אבל הם לא השירות שאתה מוכר או מציג כנגד A.8.7.
שירות הגנה חזק מפני תוכנות זדוניות כולל בדרך כלל:
- מדיניות ותקנים מתועדים בבירור להגנה מפני תוכנות זדוניות.
- קווי בסיס של נקודות קצה מוגדרים עבור כל סוג מכשיר ורמת סיכון.
- תהליכים לפריסה, עדכונים ובדיקת תקינות.
- נהלי ניטור וטיפול בהתראות.
- מודעות משתמשים, הדרכה וסימולציות פישינג.
- מערכות לניהול חריגים ושיפור מתמיד.
כלים כגון פלטפורמות EDR, מערכות ניטור מרחוק ושערי דוא"ל מאובטחים תומכים באלמנטים אלה אך אינם מחליפים אותם. אם תשרטו את הרכיבים הללו, תוכלו לשאול "היכן כל אחד מהם מתועד כיום?" ייתכן שתגלו שבסיסי נתונים נמצאים במסמכי פרויקט נפרדים, כללי ניטור במסוף ה-EDR שלכם ופעילויות מודעות נמצאות במיילים מזדמנים. איחודם תחת הגדרת שירות אחת מקל על ניהול, הסבר ותמחור של מה שאתם עושים בפועל עבור לקוחות.
ממשל, תפקידים ואחריות משותפת
תכנון ללא ממשל יסחף. סעיף A.8.7 נמצא בתוך מערכת ניהול אבטחת מידע רחבה יותר, המצפה להבהרה לגבי מי יכול לבצע שינויים, לקבל סיכונים ולאשר חריגים. ללא בהירות זו, אפילו בקרות טכניות טובות הופכות לבלתי עקביות עם הזמן וסכסוכי בעלות מופיעים ברגע הגרוע ביותר.
כשני שלישים מהארגונים שהשתתפו בסקר ISMS.online לשנת 2025 אומרים כי המהירות והיקף השינויים הרגולטוריים מקשים על קיום תאימות.
ניהול הגנה מפני תוכנות זדוניות פירושו להחליט מי הבעלים של התקן, מי יכול לאשר סטיות ממנו, מי אחראי על ניטור הביצוע וכיצד החלטות מתועדות ונבדקות. עבור ספק שירותי ניהול שירותים (MSP), זה עשוי לכלול מנהל אבטחה או תאימות, מנהלי תפעול, בעלי חשבונות ואנשי קשר עם לקוחות, כולם עם תפקידים מוגדרים היטב הגלויים ולא מוסתרים בהסכמים לא פורמליים.
מכיוון שאתם מספקים שירותים למערכת ה-ISMS של ארגון אחר, חשוב גם להיות מפורשים לגבי תחומי אחריות משותפים. אילו נקודות קצה, עומסי עבודה וערוצים אתם חוזים להגן עליהם? אילו נופלים מחוץ לתחום הפעולה שלכם? כיצד מתואמים אירועים הכוללים את שני הצדדים? יש לתעד חריגים וקבלת סיכונים עבור בקרות תוכנות זדוניות במערכת ה-ISMS שלכם, ובמידת הצורך, יש לשקף אותם בהצהרת הישימות של הלקוח, כך שלא תהיה אי ודאות בהמשך.
עבור בעלי MSP שאינם בעלי תחומי אבטחה, מבנה זה הוא יותר מתאימות. תפקידים ברורים, קווי בסיס וראיות מפחיתים את כיבוי האש, יוצרים עבודה חוזרת ונשנית ומקלים על הרחבה רווחית. פלטפורמת ISMS כמו ISMS.online יכולה לעזור לכם לאחסן את התפקידים, המסמכים וההחלטות הללו במקום אחד, כך שהממשל יהיה גלוי וקל יותר לניטור ככל שהעסק גדל.
שחררו את עצמכם מהר של גיליונות אלקטרוניים
הטמע, הרחב והרחיב את תאימותך, ללא כל בלגן. IO מעניק לך את החוסן והביטחון לצמוח בצורה מאובטחת.
תכנון בסיס EDR סטנדרטי, מדורגי סיכון
בסיס EDR והגנה מפני תוכנות זדוניות לפי רמות סיכון מאפשרים לך להחליט, פעם אחת, כמה הגנה יש לקבל על דיירים ונכסים שונים, ולאחר מכן ליישם החלטה זו באופן עקבי. במקום הגדרות מותאמות אישית בכל מקום, יש לך קבוצה קטנה של רמות סטנדרטיות המותאמות לסיכון ולהקשר העסקי שתוכל להסביר ללקוחות, לצוות ולמבקרים.
לאחר שתבחנו את A.8.7 דרך עדשת עיצוב השירות, תוכלו לעבור לאחד המנופים החזקים ביותר שיש לכם: בסיס סטנדרטי, מדורגי סיכון, לגילוי ותגובה לנקודות קצה ולמניעת תוכנות זדוניות. בסיס משותף מאפשר לכם לענות על שאלות כגון "מה מקבלת כל תחנת עבודה מנוהלת, כמינימום?" או "כיצד אנו מתייחסים לנקודות קצה בסיכון גבוה בצורה שונה?" מבלי להמציא את הגלגל מחדש עבור כל לקוח.
הגדרת רמות הסיכון שלך
לא כל לקוח או מכשיר זקוק לאותה רמת הגנה, אך כל בחירה צריכה להיות מכוונת. דרך פשוטה להתחיל היא ליצור שתיים או שלוש רמות סיכון המשקפות רגישות נתונים, לחץ רגולטורי, חשיפה חיצונית וסבילות לזמן השבתה.
מודל מעשי של חלוקת סיכונים מקבץ לקוחות ומערכות לרמות כגון רמה סטנדרטית, סיכון משופר וסיכון גבוה. לאחר מכן, כל רמה ממופה לבקרות ספציפיות של נקודות קצה, תוך ניטור עומק וציפיות תגובה. החלטות לגבי אילו שוכרים וסוגי נכסים נמצאים בכל רמה צריכות להתבסס על הערכת סיכונים והקשר עסקי, ולא רק על תקציב או נוחות.
כאשר אתם מגדירים את הרמות הללו, רשמו את הקריטריונים. לדוגמה, כל דייר שמעבד נתונים פיננסיים או בריאותיים מוסדרים עשוי להיות "משופר" כברירת מחדל, בעוד שתחנות עבודה פנימיות של ניהול עם גישה רחבה לדיירים רבים עשויות ליפול אוטומטית לדרגת "סיכון גבוה". כתיבת כללים אלה מקלה על ההגנה עליהם במהלך ביקורות ועל הסברתם ללקוחות ולחברות הביטוח.
בניית קו בסיס EDR לפי רמה
עם רמות בהישג יד, ניתן להגדיר קו בסיס לכל אחת מהן, כך שתוכל לעבור מ"אנו משתמשים ב-EDR" ל"אלה היכולות וההגדרות המינימליות שאנו מצפים להן עבור רמת סיכון זו". בהירות זו עוזרת למהנדסים, מנהלי לקוחות ומבקרים לשאוב את אותו כיוון.
קו בסיס EDR מתוכנן היטב מתאר יכולות מינימליות כגון זיהוי בזמן אמת וזיהוי התנהגותי, בקרת מדיניות מרכזית, עדכונים אוטומטיים, אפשרויות בידוד ושמירת רישום וטלמטריה. הוא גם לוכד פריטי תצורה כגון אילו התנהגויות חסומות לעומת אילו התנהגויות מקבלות התראות, כמה זמן נשמרים יומני רישום ומה נחשב כטריגר לבדיקה אנושית או בידוד אוטומטי עבור כל רמת סיכון.
בנוסף לכך, הבסיס צריך לציין כיצד EDR משתלב עם חלקים אחרים במערך שלך: סינון דוא"ל ואינטרנט בקצה הקדמי, ניהול זהויות וגישה לחשבונות פריבילגיים, ומערכות ניהול כרטיסים ואירועים לצורך מעקב. התראה שלעולם לא מגיעה לאדם או לתהליך אינה חלק שימושי מקומת A.8.7 שלך, לא משנה כמה מוכשרת הטכנולוגיה שמאחוריה עשויה להיות.
חשוב לאזן את כל זה מול המציאות התפעולית. דיירים בסיכון גבוה עשויים לסבול חסימה אגרסיבית יותר ונפחי התראות גבוהים יותר; סביבות בסיכון נמוך עשויות להעדיף מגע קל יותר. המפתח הוא להגדיר את ההבדלים הללו באופן מכוון, למדוד את השפעתם ולתעד את הרציונל כדי שתוכלו לבחון ולהתאים את עצמם ככל שהאיומים והצרכים העסקיים מתפתחים.
קווי בסיס של אנטי-תוכנות זדוניות ו-EDR לפי סוג מכשיר וסביבה
A.8.7 מצפה גם ממך להחיל הגנה מפני תוכנות זדוניות בצורה מתאימה לסוגי מכשירים וסביבות שונים, ולא להניח שתצורה אחת מתאימה להכל: תחנות עבודה, שרתים, נקודות קצה של ניהול, משתמשים מרוחקים, שולחנות עבודה וירטואליים, עומסי עבודה בענן וטכנולוגיה תפעולית - כולם נושאים סיכונים ואילוצים שונים, ולכן קווי הבסיס שלך צריכים לשקף את ההבדלים הללו. רמות הסיכון עונות על "כמה" הגנה; סוגי מכשירים וסביבות עונים על "היכן וכיצד" היא מיושמת, ויישום יעיל של A.8.7 צריך להכיר במציאות זו. גישת A.8.7 אמינה עבור MSP קובעת לכן קווי בסיס מעשיים לכל קטגוריה, יחד עם טיפול ברור בחריגים כאשר אינך יכול להחיל את הבקרות המועדפות עליך.
בסביבות MSP רבות, מספר קטן של קטגוריות נקודות קצה שולטות: תחנות עבודה ומחשבים ניידים של משתמשים, שרתים ונקודות קצה של מנהלים בעלי זכויות יוצרים המשמשות לניהול סביבות רבות. לכל קטגוריה תפקיד ופרופיל סיכון שונים, כך שלכל אחת מהן מגיע קו בסיס מותאם אישית אך סטנדרטי.
לכל קטגוריית נקודת קצה צריכה להיות נקודת בסיס מתועדת המתארת:
- איזה סוכן אנטי-וירוס או EDR חייב להיות קיים.
- אילו תכונות הגנה ליבה חייבות להיות מופעלות.
- באיזו תדירות עדכון של חתימות ומנועי נתונים.
- באיזו תדירות סריקות מבוצעות ומה הן מכסות.
- אילו התנהגויות חסומות או רק מתראות.
- כיצד נאספים ונשמרים יומני רישום.
- אילו בקרות נוספות חלות על קטגוריה זו.
עבור תחנות עבודה, זה עשוי לכלול סינון אינטרנט ובקרות קבצים מצורפים. עבור שרתים, זה עשוי לכלול בקרת שינויים הדוקה יותר ותגובות אוטומטיות שמרניות יותר. עבור נקודות קצה של מנהלי מערכת, ייתכן שתחייבו הקשחה חזקה יותר, רישום היתרים של יישומים ורישום משופר כדי שתוכלו לשחזר פעילות אם משהו משתבש.
עובדים מרוחקים והיברידיים ראויים לתשומת לב מיוחדת. מכשירים המבלים תקופות ארוכות מחוץ לרשת הארגונית או מחוץ להישג ידכם הרגיל של הניהול מרחוק עלולים בקלות לא לעמוד בדרישות. מחקרים על תצורה שגויה של נקודות קצה וסטיית תצורה מציינים כי מכשירים מחוץ לרשת או שאינם מנוהלים נוטים במיוחד להחמיץ עדכונים או לסטות מקווי הבסיס הצפויים, ולכן הם ראויים לתשומת לב מפורשת בתקנים שלכם.
טיפול במגבלות מרחוק, ענן, OT ומדורים מדור קודם
לא כל סביבה מאפשרת לך להפעיל את אותו סוכן או תצורה. יישומי קו עסקי עלולים להתנגש עם סריקות מסוימות, ייתכן שחלק ממערכות ההפעלה לא יתמכו על ידי הכלים שבחרת, ולעתים קרובות לטכנולוגיה תפעולית יש אילוצים מחמירים של ביצועים וניהול שינויים המגבילים את מה שאתה יכול להתקין.
מציאויות אלה אינן מאפשרות לכם להתעלם מ-A.8.7; הן פשוט מעבירות אתכם לעולם של בקרות פיצוי וחריגים מתועדים. במקומות בהם אינכם יכולים להפעיל סוכן מלא, ייתכן שתאכפו במקום זאת בידוד רשת, בקרת גישה מחמירה יותר, ניטור נוסף בגבולות הרשת, או בדיקות גיבוי ושחזור תכופות יותר. במקומות בהם עליכם להוציא ספריות או תהליכים מסריקה, עליכם להתייחס לאי הכללות אלו כאל החלטות סיכון: מאושרות על ידי מישהו בעל סמכות, מוצדקות, מתועדות ונבדקות באופן קבוע.
בכל המקרים הללו, שקיפות היא קריטית. עליכם לדעת אילו מערכות חורגות מקו הבסיס הסטנדרטי שלכם, מדוע, אילו הגנות חלופיות חלות ומתי תבדקו האם חריגים אלה עדיין נחוצים. רישום זה, הנשמר ב-ISMS שלכם ומשתקף בהצהרות הישימות של הלקוחות שלכם במידת הצורך, הופך לחלק מכריע באופן שבו אתם מראים שהיישום שלכם ב-A.8.7 מבוסס על סיכונים ומכוון ולא באופן רגוע או מקרי.
ניהול כל דרישות התאימות, הכל במקום אחד
ISMS.online תומך ביותר מ-100 תקנים ותקנות, ומעניק לך פלטפורמה אחת לכל צרכי התאימות שלך.
תיעוד, ניטור והוכחת A.8.7 עבור ביקורות ולקוחות
כדי לעמוד בדרישות A.8.7, עליכם להיות מסוגלים להראות מה אתם מצפים שיקרה, שזה אכן קורה ושאתם משכללים זאת לאורך זמן. תיעוד, ניטור וראיות הופכים כוונות טובות לעמדה שתוכלו לעמוד מאחוריהם מול מבקרים, לקוחות ומנהיגים שאינם בתחום הביטחוני שצריכים לראות שהסיכון העסקי שלהם נמצא תחת שליטה.
אפילו בסיס מתוכנן היטב אינו עומד בדרישות A.8.7 בפני עצמו. הבקרה מצפה שההגנה תיושם, תנוטר ותשתפר לאורך זמן. לקוחות ומבקרים רוצים לראות את הקומה הזו בצורה שהם יכולים לעקוב אחריה, ובעלי MSP רוצים לראות שהיא מפחיתה את כיבוי האש במקום להוסיף לה.
אם תתייחסו לראיות כאל מחשבה שנייה, תמצאו את עצמכם מתלבטים בכל פעם שמופיעים שאלון או ביקורת. אם תשלבו אותם בתהליכי העבודה שלכם, תוכלו לענות על רוב השאלות בעזרת דוחות שכבר משתמשים בהם כדי לנהל את העסק ולהראות התקדמות לאורך זמן.
שרשרת הראיות שלך ב-A.8.7
שרשרת ראיות חזקה להגנה מפני תוכנות זדוניות מחברת את המדיניות, קווי הבסיס, רישומי הפריסה, הזיהויים ופעילות הבדיקה שלכם לתמונה אחת וקוהרנטית. המטרה היא להקל על המעקב בין ציפייה כתובה לביצוע בעולם האמיתי וחזרה.
בפועל, זה בדרך כלל אומר שיש:
- מדיניות ותקנים מתועדים להגנה מפני תוכנות זדוניות.
- תצורות בסיסיות לפי שכבה, מכשיר וסוג סביבה.
- רישומי פריסה, תקינות הסוכנים וכיסוי.
- יומני גילויים, תגובות וקרוטי אירועים.
- הערות או פרוטוקולים מסקירות ופעולות שיפור.
במונחים מעשיים, ייתכן שתאחסנו את מדיניות התוכנות הזדוניות שלכם ואת תקני נקודות הקצה במערכת ה-ISMS שלכם, ייצאו דוחות כיסוי ותאימות קבועים מכלי ה-EDR וניטור מרחוק שלכם, קישור כרטיסי אירוע חזרה לבקרות אליהן הם מתייחסים, ולתעד קומץ החלטות מפתח מכל פגישת סקירה. כאשר מבקר שואל "הראו לי כיצד אתם מגינים מפני תוכנות זדוניות", תוכלו לייצר חבילה קוהרנטית במקום תיקייה מלאה בצילומי מסך לא קשורים. פלטפורמת ISMS כמו ISMS.online יכולה לעזור לכם לאחסן את הראיות הללו יחד כך ששרשרת הראיות תהיה גלויה וקלה לתחזוקה.
מדדי ביצועים (KPI), סקירות ודיווחי לקוחות
מדדים ודיווח הם המקום שבו A.8.7 פוגש שיפור מתמיד. הם מקדמים אותך מעבר לעמידה בדרישות נקודתית אל תוך שיחה כנה יותר על מידת התפקוד של הבקרות שלך, היכן הן דורשות תשומת לב וכיצד איכות השירות שלך משפיעה על תוצאות עסקיות. ניתוחים מומחים על שימוש במדדים לניהול סיכוני סייבר ממליצים לעתים קרובות על מדדי כיסוי ובריאות בקרה כמדדים מרכזיים לביצועי אבטחה תפעולית, דבר התואם באופן טבעי את A.8.7.
בסקר מצב אבטחת המידע של ISMS.online לשנת 2025, כ-41% מהארגונים ציינו ניהול סיכוני צד שלישי ומעקב אחר תאימות ספקים כאתגר מרכזי.
אינדיקטורים שימושיים כוללים:
- אחוז נקודות הקצה הנכללות בהיקף עם חומר פעיל ובריא.
- הזמן שלוקח לעדכן מנועים וחתימות בכל דגמי סטיישן.
- שיעור גילוי תוכנות זדוניות לכל דייר או פלח.
- זמן מהתראה ועד בלימה או תיקון.
- מספר וגיל החריגים התלויים ועומדים.
- מספר אירועים או כמעט-התקלות הקשורים לתוכנות זדוניות.
סקירה קבועה של המספרים הללו עם האנשים הנכונים עוזרת לכם לזהות היכן הבסיס שלכם זקוק לחידוד. עבור לקוחות, דיווח קל לעיכול בונה אמון. רבים לא ירצו סקירה טכנית מעמיקה, אך הם יעריכו הצהרות ברורות כגון "לכל נקודות הקצה במסגרת הבדיקה הייתה הגנה פעילה בבדיקה האחרונה", "שלושה אירועי תוכנה זדונית זוהו ונכלאו בזמנים שסוכמו", ו"החרגה אחת ארוכת שנים של סריקה הוסרה לאחר עדכוני יישומים".
כאשר סיכומים אלה מגובים בראיות מפורטות יותר הזמינות לפי בקשה, שני הצדדים יכולים להרגיש בטוחים יותר לגבי הסיכון המשותף שלהם. אתם גם מקלים הרבה יותר על מענה עקבי כאשר מגיעות שאלונים, חידושים ובקשות לבדיקת נאותות, ואתם יכולים להראות למנהלי MSP שניהול ממושמע של A.8.7 מפחית עבודה לא מתוכננת במקום רק להוסיף תקורה.
הזמן הדגמה עם ISMS.online עוד היום
ISMS.online עוזר לך להפוך את התחייבויותיך במסגרת A.8.7 לקומה קוהרנטית אחת שתוכל לשתף עם מבקרים, לקוחות ובעלי עניין פנימיים. על ידי חיבור סיכונים, מדיניות, קווי בסיס, חריגים וראיות במקום אחד, קל יותר להדגים את שליטתך בסיכוני תוכנות זדוניות ולהראות כיצד ספק שירותי ניהול אבטחת המידע שלך תומך במערכת ניהול אבטחת המידע הרחבה יותר של כל לקוח.
ראה את קומת A.8.7 שלך במקום אחד
בעזרת פלטפורמת ISMS כגון ISMS.online, תוכלו למדל את מדיניות ותקני ההגנה מפני תוכנות זדוניות, לקשר אותן ישירות לנספח A.8.7, לתעד את תצורות הבסיס שלכם עבור שכבות וסוגי מכשירים שונים, ולקשר ראיות רלוונטיות כגון דוחות, כרטיסים והערות סקירה. זה מקל בהרבה על הצגת האופן שבו השירותים המנוהלים שלכם תומכים בהסמכות של לקוחות ובצורכי האבטחה הפנימיים שלכם מבלי לאסוף חומר מאפס לפני כל ביקורת.
עבור מנהיגי MSP, מבט מרכזי זה חושף גם כפילויות ופערים. ניתן לראות היכן לקוחות שונים עדיין משתמשים בגישות מדור קודם, היכן מצטברים החרגות, והיכן קווי הבסיס שלכם עובדים היטב. תובנה זו תומכת בהחלטות לגבי היכן להשקיע מאמץ בהמשך, כיצד לשפר את הרווחיות על ידי סטנדרטיזציה של שירותים וכיצד להציג את בגרות האבטחה שלכם בהצעות מחיר ובחידושים.
הוכחת ערך במהירות בעזרת פיילוט ממוקד
מעבר לגישה מובנית יותר לא חייב להיות פרויקט גדול ומשבש. דרך פרגמטית להתחיל היא לבחור לקוח מייצג אחד או שניים ולהשתמש בפלטפורמה כמו ISMS.online כדי למדל את יישום A.8.7 שלהם מקצה לקצה, החל מסיכונים ומדיניות ועד לקווי בסיס וראיות.
לאחר מכן תוכלו להשוות את המאמץ הכרוכה בהכנה לביקורת או מענה לשאלון לקוח באמצעות השיטה הנוכחית שלכם, אד-הוק, לעומת איסוף אותן תשובות מסביבה מאורגנת אחת. לראות עד כמה הכנת הביקורת הופכת למהירה וברורה יותר בפיילוט, ייתן לכם טיעון מוחשי להרחבת גישה זו על פני בסיס הלקוחות הרחב יותר שלכם ומערך הבקרה.
בסופו של דבר, A.8.7 הוא יותר מסתם סימון סעיף בתקן. מדובר בהוכחה שניתן למנוע, לזהות ולבלום תוכנות זדוניות באופן שמגן על הלקוחות שלכם ועל המוניטין של ספקי שירותי ה-MSP שלכם. בסיס EDR ואנטי-תוכנות זדוניות מעוצב היטב, המגובה בתיעוד ברור ובפלטפורמת ISMS משולבת כמו ISMS.online, נותן לכם דרך להוכיח את הסטורה הזו בכל יום, לא רק כאשר מבקר מתקשר. אם אתם רוצים לראות איך זה יכול להיראות בסביבה שלכם, הצוות שלנו יכול להדריך אתכם בהדגמה קצרה ולעזור לכם להחליט האם ISMS.online מתאים לאופן העבודה שלכם.
הזמן הדגמהשאלות נפוצות
כיצד תקן ISO 27001:2022 A.8.7 מעלה את הרף להגנה מפני תוכנות זדוניות ב-MSP?
ISO 27001:2022 A.8.7 מעלה את הרף מ"יש לנו AV בכל מקום" ל- בקרת תוכנות זדוניות מעוצבת וניתנת לחזרה שתוכלו להוכיח שעובדת בכל הסביבות המנוהלות. עבור ספק שירותי ניהול שירותים (MSP), משמעות הדבר היא שתוכל להראות כיצד אתה מזהה סיכון לתוכנות זדוניות, קובע סטנדרטים, מפעיל את השירות ומשפר אותו לאורך זמן עבור כל לקוח מייצג.
איך נראה "מספיק טוב" תחת A.8.7 עבור MSP?
תחת A.8.7, "מספיק טוב" פירושו שניתן להוביל מבקר ספקן או מנהל מערכות מידע ארגוניות דרך קומה משולבת והגיונית:
- אתה מבין את הסיכון:
חשבתם כיצד תוכנות זדוניות יכולות לפגוע באופן מציאותי בלקוחות שלכם ובפעילות שלכם - החל מתוכנות כופר במחשבים ניידים מרוחקים ועד לתולעת בשרתים משותפים - ואתם מתעדים את הסיכונים הללו במערכת ה-ISMS שלכם.
- הפכת את הסיכון הזה למדיניות והיקף:
אתם מקפידים על מדיניות אבטחה קצרה ומאושרת של תוכנות זדוניות/נקודתי קצה אשר:
- מסביר את מטרת הבקרה בשפה עסקית.
- מגדיר אילו דיירים, מיקומים, מערכות וסוגי מכשירים נכללים בהיקף.
- הפניות לנספח A.8.7 כך שהמיפוי מפורש.
- מצביע על בקרות תמיכה כמו A.8.8 (ניהול פגיעויות) ו-A.5.24–A.5.28 (טיפול באירועים).
- יש לך קו בסיס סטנדרטי, לא "מה שהמהנדס הגדיר":
ניתן להציג קווי בסיס כתובים, מבוקרי גרסה (סטנדרטי / משופר / סיכון גבוה) עבור מחלקות מכשירים שונות המגדירות:
- יכולות מינימליות (EDR/AV, הגנה בזמן אמת, ניטור התנהגות, עדכונים).
- לוחות זמנים של סריקה, שמירת יומנים וספי התראות.
- הגדרות מחמירות יותר עבור נקודות קצה של מנהל מערכת, מכונות משותפות ומערכות חשופות.
- אתה מפעיל את השירות כמו שירות:
מאחורי הסוכן שאתה מפעיל:
- ספרי ריצה למיון, בידוד, ניקיון וחזרה לשירות.
- בעלות ברורה על כוונון מדיניות וניהול החרגות.
- שבילי דוחות ומדדים שמראים מה קורה בפועל כאשר התראות מופעלות.
- סקירות ניהוליות שוטפות שבוחנות כיסוי, אירועים, חריגים וסחיפות.
- אתה מאמן את האנשים שיכולים לעשות או לשבור את השליטה:
הצוות שלכם מבין ניהול בטוח, גישה מרחוק ושימוש בכלים פריבילגיים. במקומות שבהם החוזים שלכם קובעים שתשפיעו על משתמשי הקצה, אתם מספקים הנחיות ברורות ופשוטות לגבי קבצים מצורפים לדוא"ל, פקודות מאקרו ומדיה נשלפת במקום לקבור אותם בקבצי PDF של מדיניות.
אם תצליחו לחבר את כל הגורמים יחד במהירות – עם מדיניות, סטנדרטים, החלטות בנוגע לסיכונים וראיות החיים במערכת ניהול אבטחת מידע אחת – A.8.7 הופך פחות לשאלה מלכודת ויותר להזדמנות להציג עד כמה האבטחה המנוהלת שלכם באמת בוגרת. ISMS.online נועד לספק לכם את המקום היחיד שבו תוכלו לשמור על העניינים ולשמור עליהם מוכנים לביקורת.
כיצד יכול MSP להפוך את A.8.7 לשירות EDR / אנטי-תוכנות זדוניות סטנדרטי שניתן להרחיב בין דיירים?
אתה הופך את A.8.7 להרחבה על ידי התייחסות להגנה מפני תוכנות זדוניות כאל מוצר חוזר עם בסיס מתועד, לא עיצוב חדש לכל לוגו חדש. קו הבסיס מגדיר איך נראה "טוב" פעם אחת; רמות סיכון וחריגים מאפשרים לך להגמיש אותו בצורה הגיונית מלקוח ללקוח.
מה שייך לבסיס תוכנות זדוניות רב פעמיות עבור ספקי שירותי ניהול שירותים (MSPs)?
בסיס מוצק מכיל בדרך כלל ארבעה אבני בניין שניתן להשתמש בהן שוב ושוב בכל מקום ולהצדיק אותן במהירות.
1. מינימום ברור לכל סוג של מכשיר
אתה מגדיר מה חייב להיות לכל הפחות בכל מכשיר הנכלל בתוכנית:
- נקודות קצה של המשתמש (מחשבים ניידים, מחשבים שולחניים, טאבלטים במידת התמיכה):
- EDR או סוכן אנטי-תוכנות זדוניות מנוהל באופן מרכזי.
- הגנה בזמן אמת וניתוח התנהגותי.
- עדכוני חתימה/מנוע אוטומטיים, עם גיבוי הגיוני.
- סינון אתרים/כתובות URL עבור נתיבי אספקה נפוצים.
- יכולת בידוד מקומית במקרה של חשד לפגיעה.
- שרתים ומערכות קריטיות:
- הגנה דומה, מכווננת למניעת שיבושים עסקיים.
- רישום והתראות נוספות על פעילות חריגה.
- שליטה הדוקה יותר על שינויים במדיניות.
- מנהלים ומארחי קפיצה:
- פרופילים מחמירים יותר עם רשימת היתרים, רישום משופר וסבילות נמוכה יותר לחריגים.
- אימות רב-גורמי ושימוש מוגבל.
היכולת להראות "זה המינימום שכל מכשיר מקבל לפי סוג" נותנת ללקוחות ולמבקרים ביטחון מיידי שאתם לא מאלתרים לפי מהנדס.
2. פרופילים סטנדרטיים במקום פולקלור של קונסולות
אתם מתעדים פעם אחת, בכתב, כיצד הפרופילים שלכם מתנהגים:
- מה שאתה חוסם באופן מיידי לעומת מה שאתה מעלה כהתראה.
- מתי סריקות מלאות ומהירות מבוצעות ומי בודק כשלים.
- כמה זמן נשמרים יומני רישום והיכן הם נמצאים.
- אילו אירועים חייבים תמיד לפתוח כרטיס (לדוגמה, התנהגות בסגנון כופרה, סקריפטים חסומים חוזרים ונשנים).
- אילו קבוצות של נקודות קצה נמצאות בפרופילים מחמירים יותר, ומדוע.
פרופילים אלה צריכים להיות מבוקרי גרסאות בתוך מערכת ה-ISMS שלכם, עם היסטוריית שינויים ואישורים, כך שביקורות עתידיות מתמקדות בהצגת הסטנדרט של היום, ולא בשחזור הניחושים הטובים ביותר של השנה שעברה.
3. רמות מבוססות סיכון ולא טיפול מבוסס מותג
במקום לקבוע את קפדנות הפעולה על סמך לוגו או ערך חוזה, אתם ממפים דיירים ומכשירים למודל פשוט של רמת סיכון:
| נִדבָּך | מה מניע את זה | דוגמאות אופייניות |
|---|---|---|
| תֶקֶן | השפעה עסקית נמוכה/רגילה | משתמשי משרד פנימיים בארגונים שאינם מפוקחים |
| משופר | השפעה פיננסית או תפעולית גבוהה יותר | צוותי כספים, עמדות משותפות, מחשבי הנדסה באתר |
| סיכון גבוה | עומסי עבודה רגולטוריים, בעלי הרשאות זכויות או חשופים לאינטרנט | דיירים בתחום הבריאות או הפיננסי, נקודות קצה של מנהלים |
המיפוי קיים ברישומי הנכסים והסיכונים שלכם, כך שכאשר מישהו שואל "למה הסביבה הזו נעולה יותר מזו?", אתם יכולים להצביע על קריטריונים ברורים, לא על אישיות או היסטוריית משא ומתן.
4. תהליך חריגים מבוקר וגלוי
החיים האמיתיים תמיד מזמנים אתגרים - יישומים מדור קודם, בעיות ביצועים, מוזרויות באינטגרציה. A.8.7 אינו אוסר חריגים; הוא מצפה לנהל אותם:
- כל סטייה מקו הבסיס נרשמת במאגר חריגים.
- כל רשומה מציגה את הסיבה, הסיכון, בקרות הפיצוי והאישור.
- לחריגים יש בעלים ותאריך סקירה.
- ניתן להראות כמה נסגרו או הודקו בתקופה האחרונה.
כאשר קו הבסיס, הרמות והחריגים שלך נמצאים כולם ב-ISMS.online עם בעלות ברורה, שלושה דברים טובים קורים בו זמנית:
- מהנדסים כבר לא צריכים לזכור "הגדרות שבטיות" לכל דייר.
- צוותים מסחריים יכולים לתאר את השירות באופן עקבי בהצעות ובחידושים.
- A.8.7 שיחות עם מבקרים או לקוחות מצטמצמות לסקירה של קו הבסיס, מודל השכבות וכמה דוגמאות לחריגים.
אם אתם רוצים שקו הבסיס הזה ירגיש כמו חלק ממערכת ISMS מחוברת ולא קבצים מפוזרים, בנייתה ותחזוקה שלה ב-ISMS.online נותנים לכם מבנה ויכולת שימוש חוזר מהיום הראשון.
אילו בקרות טכניות ותפעוליות באמת צריך/ה של ספק שירותי ניהול רשת (MSP) כדי להרגיש בטוח/ה לאשר את A.8.7?
אתם רוצים להיות מסוגלים להסתכל בקטלוג השירותים שלכם ולומר, בפנים ישרות, ש כל מכשיר הנכלל בתוכנית מוגן באופן משמעותי וכי התראות הופכות לפעולה באופן אמיןביטחון זה תלוי הן בטכנולוגיה שאתם פורסים והן באופן שבו הצוות שלכם מפעיל אותה.
אילו בקרות טכניות צריכות להיות בלתי ניתנות למשא ומתן?
שירות נקודת קצה ריאליסטי המותאם ל-A.8.7 כולל לרוב:
- כיסוי ופריסה:
- אכיפה שכל נקודות הקצה הנכללות במסגרת - כולל עובדים מרוחקים ומכשירים חדשים - יקבלו את הסוכן באופן אוטומטי.
- בדיקות תקינות לאיתור סוכנים חסרים או לא תקינים, עם התראות ברמת השוכר וברמת תיק ההשקעות.
- שילוב עם כלי ה-RMM או כלי ההקצאה שלכם כדי למזער פערים בקליטת המערכת.
- טווח הגנה וגילוי:
- סריקה מתמדת של קבצים, תהליכים וסקריפטים.
- זיהוי התנהגותי של תוכנות כופר, שימוש לרעה בסקריפטים ותהליכים יוצאי דופן של ילדים.
- עדכונים אוטומטיים עם מעקות בטיחות בעת עקיפות ידניות.
- תמיכה בבידוד או ב-Kill-switch כך שמהנדסים יוכלו להכיל אירוע תוך דקות, לא שעות.
- בקרות תומכות במעלה ובמורד הזרם:
- סינון דוא"ל ואינטרנט לחסימת תוכנות זדוניות נפוצות
- ניהול תיקונים ותצורה להפחתת חשיפה.
- גיבוי ושחזור נבדקו כך שתוכלו להתאושש בביטחון אם פגיעה עוברת את הגנות נקודות הקצה.
מסגור הבקרה שלך כמכלול השליטה הזה - לא רק הסוכן - מקל על ההסבר ללקוחות כיצד אתה מנהל את הסיכון לתוכנות זדוניות לאורך מספר נתיבים, לא רק בקפיצה האחרונה.
אילו ראיות תפעוליות מרגיעות את רואי החשבון ואת הקונים של ארגונים?
רוב הסוקרים פחות מתעניינים בלוגו שעל הסוכן ויותר בשאלה האם הפעילות שלכם מתנהגת באופן עקבי כשזה חשוב:
- ספרי משחק מתועדים:
- שלבים ברורים לסיווג התראות לפי חומרה והקשר.
- פעולות מוגדרות לחשד לפריצה: בידוד, חקירה, ניקוי, אימות.
- קריטריונים למתי וכיצד לבצע שימור פורנזי.
- נקודות בהן אתם מודיעים או מעבירים את הנושא לאנשי קשר של לקוחות.
- רמות שירות ואחריות:
- זמני תגובה יעד עבור התראות בעדיפות גבוהה.
- בעלים בעלי שם לכוונון בסיס, רשימות אי הכללה ומדדי כיסוי.
- סידורי כוננות לאירועים מחוץ לשעות הפעילות, אם החוזים דורשים זאת.
- ראיות לכך שהתהליך מתנהל כמתוכנן:
- מעקב אחר כרטיסים משלב הגילוי ועד לשלב הפתרון, עם חותמות זמן ותוצאות.
- סיכומים קבועים המציגים את הזמן הממוצע לסקירה, בלימה וסגירה של אירועים.
- הערות מסקירות שבהן דפוסים בגילויים או תוצאות חיוביות שגויות הובילו לשינויים.
אם הפריטים, המדדים וההחלטות הללו מקושרים למדיניות A.8.7 ולקווים הבסיסיים שלכם בתוך ISMS.online, תוכלו לעבור מ"תאמין לנו, אנחנו שולטים בזה" למדריך פשוט כיצד הבקרה באמת עובדת. שינוי זה נוטה להתקבל לטובה הן בקרב מבקרים והן בקרב לקוחות גדולים יותר שממפים את הבקרות שלכם בחזרה לתקן ISO 27001 ולמסגרות קשורות כגון NIST CSF או SOC 2.
כיצד יכול MSP לתעד, לנטר ולדווח על A.8.7 כך שביקורות ירגישו כמו חודש רגיל, לא כמו פרויקט מיוחד?
ביקורות A.8.7 מרגישות שגרתיות כאשר התיעוד, לוחות המחוונים והרשומות שלך לשקף את האופן שבו אתה מפעיל את השירות כבר עכשיו, במקום לאלץ אותך להיכנס ליקום מקביל. המטרה היא קבוצה קטנה ומסודרת של חפצים שמתאימים לפרקטיקה היומיומית.
אילו מסמכים כדאי לשמור בצורה תקינה?
אינכם זקוקים לעשרות פוליסות; אתם זקוקים לכמה שהן עדכניות, מקושרות וקלות למציאה:
- מדיניות אבטחה של תוכנות זדוניות / נקודות קצה:
- מטרת המדינות, היקף, אחריות וקישורים לנספח A.8.7 (ולבקרות קשורות).
- מתייחס לשיטת הערכת הסיכונים שלך ולסטנדרטים הבסיסיים.
- נמצא במערכת ה-ISMS שלך עם ניהול גרסאות ואישורים ברורים.
- סטנדרטים בסיסיים ופרופיליים:
- תאר את רמות הסיכון, סוגי המכשירים והתצורות הסטנדרטיות שלך.
- שימו לב לכל תוספות ספציפיות למגזר (לדוגמה, שירותי בריאות, פיננסים).
- מתעדכנים במכוון, לא על ידי שינויים שקטים בקונסולה.
- תהליכים תפעוליים:
- קליטה: כיצד שוכרים ונכסים חדשים מוכנסים לשירות.
- ניטור: כיצד בודקים קונסולות ופידים, ועל ידי מי.
- תגובה לאירוע: המסלול מהתראה לבלימה, התאוששות וסגירה.
- ניהול חריגים: כיצד מוצעות, מאושרות, נרשמות ונבדקות חריגות.
- אוגרי חריגים וסטייה:
- עקבו אחר היכן המציאות שונה מהקו הבסיסי שלכם ומדוע.
- הצג בעלים, בקרות פיצוי ותאריכים לסקירה.
איחוד האלמנטים הללו ב-ISMS.online מאפשר לכם ליצור חבילת ביקורת במהירות והצוותים הפנימיים שלכם תמיד עובדים מאותו סט ייחוס.
מה כדאי לנטר, ואיך מציגים זאת מבלי להטביע אנשים בנתונים?
בדרך כלל ניתן לענות על רוב שאלות A.8.7 בעזרת מספר מדדים קבועים:
- מדדי כיסוי ובריאות:
- % מהמכשירים הנכללים בתוכנית עם סוכן תקין ועדכני ומדיניות נכונה לכל דייר.
- מספר מכשירים חסרים בכיסוי, עם סיבות (חדשים, יוצאים משימוש, יוצאי דופן).
- קווי מגמה לאורך זמן, המראים האם הכיסוי יציב, משתפר או יורד.
- אינדיקטורים לגילוי ותגובה:
- מספר וחומרת גילוי תוכנות זדוניות לכל דייר ולכל שכבה.
- זמן ממוצע וזמן הגרוע ביותר לסקירה ובלימת אירועים קריטיים.
- מקרים בהם בלימה הסתמכה על גיבוי/שחזור, והתוצאות.
- אינדיקטורים לחריגות וסחיפות:
- מספר כולל של אי הכללות פעילות וגילם הממוצע.
- ספירת חריגים שנוספו והוסרו בכל תקופה.
- סטייה נצפתה בין תצורות מיועדות לתצורות בפועל על פני דיירים מייצגים.
ניתן לסכם את אלה עבור ביקורות וסקירות לקוחות בצורה קצרה וקריאה, לדוגמה:
ברבעון האחרון, שמרנו על הגנה אקטיבית על 98.7% מנקודות הקצה במסגרת הפרויקט שלכם. חקרנו 11 התראות הקשורות לתוכנות זדוניות, שלוש תקריות מאושרות נמצאו בתוך זמני התגובה שסוכמו עליכם, וסגרנו חמש החרגות מיושנות שלא היו נחוצות עוד לאחר שינויים באפליקציה.
כאשר מערכת ה-ISMS שלכם, כלי נקודות הקצה שלכם והדיווח שלכם מסתדרים כך – משהו ש-ISMS.online בנוי לתמוך בו – ביקורות מתחילות להיראות כמו סיור מובנה בטלמטריה הרגילה שלכם ולא כמו חיפוש אחר צילומי מסך.
אילו חולשות בדרך כלל מוצאים מבקרים ולקוחות בספקי שירותי ניהול שירותים (MSPs) סביב A.8.7 – וכיצד אתם נשארים צעד אחד קדימה?
הממצאים הלא נוחים ביותר מקובצים במקום שבו הבטחת השיווק, היסטוריית הכרטיסים והסטנדרטים הפורמליים אינם תואמיםזיהוי מצבי הכשל הנפוצים מאפשר לך לתכנן את בקרת A.8.7 שלך כך שבדיקות חיצוניות יאשרו את מה שאתה כבר יודע, במקום לחשוף פערים.
היכן MSPs נתקלים הכי הרבה ב-A.8.7?
דפוסים אופייניים כוללים:
- כיסוי לא עקבי או לא שלם:
- מכשירים מרוחקים ומכשירים של BYOD שמעולם לא מקבלים את הסוכן.
- דיירים חדשים נוספו מבלי שיופו לרמת סיכון או לפרופיל בסיס.
- מערכות קריטיות נותרו על הגדרות ברירת מחדל או מדור קודם למשך זמן רב מדי.
- קווי בסיס לא כתובים וכוונונים אד-הוק:
- מהנדסים "יודעים בערך" מה להגדיר, אבל אין סטנדרט כתוב ומוסכם.
- ההגדרות משתנות באופן משמעותי בין דיירים בעלי פרופילי סיכון דומים.
- אין תיעוד מדוע נבחרו הגדרות מחמירות או רפויות יותר.
- חריגים לא מנוהלים והפרות מדיניות שקטות:
- החרגות גדולות נוספו במהלך פתרון בעיות ולא נבדקו שוב.
- הסריקה מושבתת לתיקון בעיות ביצועים ללא בקרות פיצוי.
- ויכוחים על מי הבעלים של הסיכון כאשר אלה מתגלים.
- ראיות דקות ומפוזרות:
- יומני רישום וכרטיסים המאוחסנים במספר מערכות שאינן מחוברות.
- קושי להוכיח מה קרה במהלך אירוע מעבר למספר הודעות צ'אט.
- אין דרך קלה להראות שיפור לאורך זמן.
אלו בדיוק החולשות שמלחיצות קונים גדולים יותר, במיוחד כשהם משווים אתכם מול נספח A לתקן ISO 27001 או למדיניות הפנימית שלהם.
כיצד גישה ממושמעת יותר המתמקדת ב-ISMS משנה את התמונה?
אינכם צריכים להפוך לארגון ענק כדי להימנע ממלכודות אלו. כמה הרגלים ממושמעים, מעוגנים במערכת ניהול מערכות מידע (ISMS), יעזרו לכם רבות:
- החל את בסיס שכבתי כברירת מחדל לכל דייר ונכס חדשים, באמצעות תבניות הקליטה שלכם.
- הפעל a זרימת עבודה פשוטה ויחידה לחריגים כאשר כל הסטיות נרשמות, נבדקות לפי לוח זמנים ומקושרות להחלטות סיכון.
- לעשות דוחות כיסוי וחריגים חלק קבוע מסקירות שירות פנימיות ושיחות עם לקוחות, לא רק בעונת הביקורת.
- רשום לקחים שנלמדו מאירועים ותוצאות חיוביות שגויות כעדכונים לתוכניות בסיס, ספרי ריצה וחומרי הדרכה.
כאשר אתם מנהלים את כל זה דרך ISMS.online – שם מדיניות, סיכונים, בקרות, חריגים וראיות מחוברים – תוכלו לענות על שאלות A.8.7 ברוגע:
- הנה איך אנחנו מעוצב השליטה.
- הנה איך אנחנו לפעול ולמדוד זה.
- הנה איך אנחנו לשפר את זה לאורך זמן.
בהירות זו נוטה להסיט את הדיון מ"מדוע זה השתבש?" לכיוון "כיצד נרחיב את החוזק הזה לתחומים אחרים בשירות שלכם?"
כיצד יכול MSP לבחור ולהגן על כלי EDR / אנטי-תוכנות זדוניות עבור A.8.7 מבלי להיתקע בטיעוני ספק?
לנספח A.8.7 לא אכפת באיזה ספק אתה משתמש; אכפת לו שההגנה שלך מפני תוכנות זדוניות תהיה מתאים לסיכון, מיושם באופן עקבי והוכח כיעילתפקידך הוא להראות שבחירות הכלים שלך תומכות בתכנון הבקרה אליו התחייבת - ולא להיפך.
אילו קריטריונים צריכים להנחות את בחירת הכלים עבור A.8.7?
דרך מעשית להחליט היא להתחיל מהבסיס ומהאילוצים התפעוליים שלך, ואז לשאול כל מוצר:
- האם זה תומך בקו הבסיס שלך, או כופה פשרות?
- האם תוכלו להגדיר את יכולות הזמן-אמת, ההתנהגות והבידוד הנדרשות לרמות שלכם?
- האם ניתן ליישם פרופילים מחמירים יותר עבור מכשירים בסיכון גבוה ללא פתרונות מורכבים לעקיפת הבעיה?
- האם זה מספק את הרישום הדרוש לך כדי להוכיח גילוי, בלימה ושחזור?
- האם זה באמת ידידותי למספר דיירים?
- האם ניתן לנהל שוכרים רבים ממקום אחד ללא כפילויות בלתי פוסקות של פוליסות?
- האם ניתן לאכוף סטנדרטים גלובליים ועדיין לאפשר שונות מבוקרת בין דיירים?
- האם ישנן בקרות גישה ברורות מבוססות תפקידים כך שהצוות רואה רק את מה שהוא צריך?
- האם זה מתאים למחסנית השירותים הקיימת שלך?
- האם זה משתלב עם שירותי הכרטוס, ה-SIEM וה-RMM שלכם, כך שהתראות יהפכו באופן טבעי לפעולות?
- האם תוכלו להתאים את כלי הזהות, הדוא"ל וכלי הגיבוי לתגובת נקודת הקצה?
- האם זה תומך ברמת האוטומציה שהצוות שלך יכול לנהל באופן ריאלי?
- האם העומס התפעולי נסבל?
- כמה כוונון נדרש כדי להגיע ליחס אות-רעש מקובל?
- באיזו קלות המהנדסים שלכם יכולים לרכוש ולשמר יכולת?
- מה קורה כאשר יש שדרוג משמעותי או שינוי במודל המדיניות?
ניסוח הבחירה במונחים אלה עוזר לך לשמור על שיחות עם לקוחות ומבקרים ממוקדות בהתאמה וביעילות, ולא בטענות שיווקיות של ספקים.
לאחר שתתקינו סטנדרטיזציה על פלטפורמה אחת או שתיים, תוכלו לענות על שלוש שאלות פשוטות עם ראיות:
- נֵאוֹתוּת
- נימוק קצר במערכת ה-ISMS שלכם המסביר מדוע הכלי מתאים לבסיס הלקוחות ולפרופיל הסיכון שלכם.
- מיפוי המציג כיצד תכונות מפתח תומכות במדיניות התוכנות הזדוניות שלך ובקו הבסיס של A.8.7.
- פריסה והתנהגות
- לוחות מחוונים של כיסוי ובריאות ברמת השוכר והתיק.
- רישומי סקירות תצורה ואישורי שינויים.
- רישומי אירועים לדוגמה המציגים גילוי, בלימה וניקוי שבוצעו באמצעות הכלי.
- יכולת הסתגלות לאורך זמן
- תהליך קליל להערכה מחודשת של מערך הכלים כאשר צצים איומים, תקנות או דרישות לקוחות חדשות.
- דוגמאות לשינויים שכבר ביצעתם, כגון הידוק הבקרות לאחר קמפיין כופר במגזר שלכם.
על ידי ניהול הנרטיב הזה דרך ISMS.online – קישור סיכונים, בקרות, בחירות כלים, אירועים וסקירות – תוכלו להעביר את שיחות A.8.7 הרחק מ"איזה מוצר אתם משתמשים?" ל"כך אנו שומרים על הסיכון לתוכנות זדוניות תחת שליטה עבור ארגונים כמו שלכם". זוהי סוג התשובה שמבטיחה לצוותי תאימות, מנהיגי אבטחה ודירקטוריונים שה-MSP שלכם לא רק מתקין תוכנה, אלא מפעיל בקרה מחושבת ומגובה בראיות.
