אם חשבתם ו\או רציתם להטמיע את התקן ISO 27001 בארגון, אז הנה לכם מדריך קצר להטמעת
דרישות התקן ISO 27001 בארגון.
למי שאינו מכיר את התקן, וגם לאלו שכן מכירים, הטמעתו בארגון יכול להפוך לתהליך ארוך
ומסורבל, אם לא מתכננים אותו כראוי.
אז להלן 20 שלבים שיוכלו לסייע לכם בהטמעת התקן ISO 27001 בארגון, בין אם זה בעזרת יועץ
חיצוני, ובין אם החלטתם לקחת את המשימה הזאת על עצמכם.
1. הצטיידו בעותק של התקן ISO 27001
ראשית, עליכם להצטייד בתקן עצמו. ניתן לרכוש את המסמכים ישירות ממכון התקנים. גם לארגונים שהחליטו להיעזר בחברת ייעוץ, מומלץ עדיין להצטיין בתקן עצמו, לקרוא, ולהכיר את הדרישות.
יתרה מכך, אם לקחתם חברת ייעוץ לסייע לכם בהטמעת דרישות התקן, תוכלו להיעזר בהם ולשאול שאלות, על מנת להכיר היטב את דרישות התקן.
2. תלמדו בקצרה את מהות התקן
הסיבה לכך מאוד פשוטה. אם החלטתם לבצע את הפרויקט בעצמכם, אז חשוב מאוד שתדעו מול מה אתם מתמודדים, ומה עליכם לבצע בתהליך הטמעת התקן בארגון. אם החלטתם להקל על עצמכם, ולהיעזר בחברות ייעוץ חיצונית, אז עדיין חשוב שתדעו על מה הם מדברים, שתוכלו לדבר איתם באותה השפה, ולמנוע מצבים בהם מחייבים אתכם לא מעט כסף על פעילויות ודרישות שאינן נחוצות להטמעת התקן. אני תמיד בעד ללמוד ולהעשיר את הידע והכשירות המקצועית, וזאת גם דרישה מהותית של התקן. על כל העוסקים בתחום אבטחת המידע (בייחוד מנהל אבטחת המידע וצוות ה-GRC שלו, להכיר את דרישות התקן). ולא צריך להסתכל על זה באור שלילי, אלא להיפך, במסגרת למידת והבנת דרישות התקן, גם תזכו ללמוד לא מעט דברים חיוניים לשיפור לחוסן הארגון מבחינת היבטי הגנת הסייבר בכל הרבדים השונים (אבטחה פיזית, היבטי אבטחת מידע בשכבת האפליקציה, בשכבת הרשת, בהיבטים של ניהול ותגובה לאירועי אבטחת מידע, בהיבטים של ניהול המשכיות עסקית, בהבטים של זיהוי, ניהול והערכת סיכונים, בהבטים של שרשרת האספקה,עמידה בדרישות תקינה ורגולציה, ועוד.
התקן מהווה ומספק מסגרת נאותה לניהול כל תחום אבטחת המידע בארגון, עם מקבת רחב של המלצות למימוש (Best Practices) שנכתבו ע"י מומחים רבים בעולם. למרות שממליצים לאמץ את כל דרישות התקן, לא חייבים לאמץ את כל הדרישות, אלא רק מה שישים מבחינת הפעילות העסקית של הארגון, ומתאר איומי הייחוס שחלים על המגזר אליו משתייך הארגון.
3. תקבלו את ברכת הדרך של הנהלת הארגון
מלבד העובדה שזה גם נדרש בתקן, חשוב מאוד להתחיל לשווק את היתרונות של התקן בארגון, ולקבל תמיכה מלאה מהנהלת הארגון כבר בשלב הייזום וההטמעת של התקן. ורצוי לקבל את ברכת הדרך ותמיכת ההנהלה הבכירה ולא רק של המנהל הישיר שלכם. לרוב, מתייחסים לנקודה זו כמובנת מאליו, אבל במרבית המקרים זוהי גם נקודת הכשל של רוב הפרויקטים הקשורים בהטמעת התקן ISO 27001 בארגון, בעיקר בארגונים גלובאליים. בגלל היעדר תמיכת הנהלה (ולא רק מבחינת הקצאת משאבים, אלא גם ברמה הפוליטית), פרויקטים מסוג זה נכשלים או נמשכים זמן רב.
אחד הגורמים המהותיים לבעיה זו, היא שבמרבית הארגונים בארץ, מנהל אבטחת המידע כפוף ישירות למנהל מערכות המידע (מנמ"ר), שזה מהווה ניגוד עניינים מובהק, ומקשה על תפקידו של מנהל אבטחת המידע. בעולם המודרני, כבר מזמן הבינו זאת, וניתן לראות במרבית הארגונים בעולם שמנהל אבטחת המידע כפוף ומדווח ישירות למנכ"ל החברה, או לפחות לחברי הנהלה שונים מהסמנכ"ל טכנולוגיות המידע (CIO). וזאת כדי למנוע מצב של ניגוד עניינים.
על מנת לקבל את ברכת הדרך ואת תמיכתם של הנהלת הארגון, מנהל אבטחת המידע צריך למצוא את הדרך לשווק בצורה נכונה את תרומתו של אימוץ דרישת התקן. וניתן לעשות זאת באמצעות הפיכת המונחים הטכנולוגיים להיבטים עסקיים, ולדבר עם הנהלת הארגון בשפה עסקית ולא טכנולוגית. גם בעידן שבו מרבית הארגונים מבינים ומכירים את איומי הסייבר השונים, עדיין יהיה קל יותר לשכנע את חברי ההנהלה שעמידה בדרישות התקן מווה יתרון עסקי ולא רק מבחינת היבטי אבטחת מידע. למשל, ניתן להצדיק זאת באמצעות הלימה לדרישות תקינה, רגולציה ולקוחות. תכינו מצגת קצרה וקולעת, שמציגה בפשטות ובשפה העסקית את תרומתו של התקן לארגון, בהיבטים העסקיים.
4. התייחסו לזה כאל פרויקט
עוד נקודה שכביכול מובנת מאליה, אבל רבים נכשלים להסתכל עליה בצורה נכונה, ומוביל את הפרויקט הזה לכישלון. כמו שציינתי בתחילת המאמר, הטמעת התקן ISO 27001 יכול להיות תהליך ארוך ומסורבל (תלוי בגודל הארגון ובעיקר בתחולת הפרויקט), ולכן רצוי מאוד להתייחס אליו כאל פרויקט על כל המשתמע מכך. תהליך הטמעת התקן יצרוך לא מעט משאבים בארגון, ומבלי לנהל את זה בצורה מתודולוגית ומסודרת, אנו עלולים למצוא את עצמנו בבלגן גדול יותר מאשר מהמצב שהיינו בו עוד טרם ניסיון הטמעת התקן. בארגונים קטנים/בינוניים, פרויקט כזה יכול להימשך בין 2-3 חודשים, בעוד שבארגונים גדולים, הפרויקט יכול להימשך מעל חצי שנה. אם לא מגדירים גאנט מסודר לפרויקט (מטרות ויעדים, לו"ז, צוות עבודה, מנהל פרויקט, משאבים, ניהול סיכונים, וכדומה), אנחנו עלולים למצוא את עצמנו רצים מסביב לזנב. אגב, לא חייבים לסיים הכל בשנה הראשונה, אפשר להגדיר תוכנית עבודה רב שנתית, ולהחליט באיזה אזורים להתמקד בשנה הראשונה (בד"כ זה באזורים בהם הסיכונים גבוהיים יותר), ומה משאירים לשנים הבאות. תוכנית מסודרת גם תעזור לנו למדוד את עצמנו ואת האפקטיביות של הטמעת התקן וניהול הפרויקט.
5. תקבעו מנהל פרויקט
עוד נקודה בסיסית אך לצערנו הרבה ארגונים לא מקפידים לעשות זאת. במרבית הארגונים, המשימה נופלת על מנהל אבטחת המידע, שהוא גם ככה עמוס, ובקושי מוצא זמן לנשום. מלבד העובדה שמנהל אבטחת המידע מהווה צוואר בקבוק בתהליך הזה, זה יכול גם לגרום לניגוד עניינים ובעיות פוליטיות בארגון. רצוי לבחור מנהל פרויקט, שהוא לאו דווקא מנהל אבטחת המידע בארגון. כפי שראיתם, התקן פולש על מגוון רחב של תחומים בארגון (כגון משאבי אנוש, פיתוח, IT, רכש, ניהול אירועי סייבר, אבטחה פיזית ועוד), ולכן מלבד העובדה שמנהל אבטחת המידע בארגון כבר סוחב על עצמו עומס רב, זה יכול גם לגרום ללא מעט בעיות פוליטיות (בייחוד לארגונים גלובאליים).
דבר נוסף חשוב לא פחות, הוא שמנהל הפרויקט חייב להיות דמות סמכותית ואסרטיבית, כדי לגרום לפרויקט להתנהל כמתוכנן, בלי עיכובים, ובלי מכשולים. וגם אם יהיו, שהוא ידע לפתור אותם, מבלי לפגוע בלו"ז של הפרויקט.
6. הגדירו היטב את התחולה של הפרויקט לתקן ISO 27001
בין אם הארגון שלכם גדול (Enterprise), או קטן/בינוני (SMB), אני ממליץ לכם להבין את הדרישות העסקיות, רגולטוריות, וחוזיות, ולתחום את גבולות הגזרה של הפרויקט להטמעת התקן ISO 27001 בארגון. בעת קביעת תיחום הארגון, חשוב להתייחס למרכיבים הבאים: דרישות בעלי עניין רלוונטיים (לקוחות, שותפים עסקיים, רגולטורים, הנהלת הארגון), וגם למתאר איומי הייחוס שרלוונטיים לפעילות העסקית שלכם. אם מגדירים היטב את התיחום וגבולות הגזרה, יהיה גם קל בהמשך לקבוע תוכנית עבודה, מטרות ויעדים, ולמדוד את האפקטיביות של הפרויקט. אם לא מגדירים את התיחום היטב, אתם עלולים למצוא את עצמכם מסובכים, ורצים להטמיע בקרות שלאו דווקא רלוונטיות לפעילות העסקית שלכם, או למתאר איומי הייחוס בהתאם למגזר אליו אתם משתייכים. להמלצות וטיפים כיצד להגדיר בצורה נכונה את התיחום לפרויקט, ניתן להיעזר בחברת ייעוץ. יועצינו בחברת טייטנס סקיוריטי, בעלי ניסיון של אלפי פרויקטים ברחבי הארץ ובעולם, וישמחו לסייע גם לכם בהטמעת דרישות התקן, ולחסוך לכם משאבים יקרים.
7. מדיניות אבטחת מידע של המנא"מ
הגדירו ותכתבו את מדיניות אבטחת המידע של המנא"מ (ISMS). מסמך מדיניות זה מציג את עקרונות והצהרות הנהלת הארגון בנוגע לניהול המנא"מ. זהו לא מסמך אופרטיבי שתפקידו לקבוע ולפרט בפרטי פרוטות מה צריך לעשות, אלא יותר הגדרות ברמת המאקרו. אם כך, אז מהי מטרת המסמך הזה? ובכן, המטרה היא להגדיר את מטרות אבטחת המידע, את מחוייבות ההנהלה לתהליך של שיפור מתמיד של המנא"מ, ואת בעלי התפקידים, אחריות וסמכויות של בעלי העניין הרלוונטיים בתחום אבטחת מידע. זהו גם המסמך היחידי שחובה שמנכ"ל או נציג הנהלה בכירה של הארגון יחתום עליו, היות וזה חלק ממחוייבות ההנהלה.
8. מתודולוגיה להערכת וניהול סיכונים
אחד מעמודי התווך של תקן אבטחת מידע ISO 27001, הוא תהליך של הערכת וניהול סיכונים. התוצר של זיהוי, הערכת, ניתוח וניהול הסיכונים, עומד בבסיס ההצלחה להטמעה נכונה של המנא"מ בארגון. מעבר לכך, התיחום של התקן, נקבע גם באופן חלקי, בהתאם למתאר איומי הייחוס והסיכונים שרלוונטיים לפעילותו בארגון.
מטרת המתודולוגיה היא לקבוע מהם הפרמטרים שנדרשים לצורך זיהוי והערכת סיכונים (זיהוי נכסי המידע של הארגון, זיהוי פגיעויות, זיהוי איומים, קביעת מידת הנזק הפוטנציאלית למימוש האיום, קביעת רמת הסבירות למימוש האיום, קביעת הסיכון, קביעת רמת הסיכון ואת דרכי הטיפול בסיכון, וכדומה), ומהן השיטות לניהול הסיכונים (מהו תאבן הסיכון? מתי מקבלים סיכון? מתי אי אפשר לקבל את הסיכון וצריכים למזער אותו או להעביר אותו לצד ג', וכדומה).
ללא מתודולוגיה מוסדרת, הארגון עלול למצוא את עצמו במערבולת של ניהול סיכונים שאינם משקפים את המציאות, או אינם בהלימה עם דרישות עסקיות או רגוליטוריות לניהול סיכונים.
9. הערכת וניהול סיכונים
לאחר קביעת המתודולוגיה, מגיע שלב הביצוע. בשלב הביצוע, ראשית עלינו לבצע תהליך של זיהוי והערכת סיכונים (ע"י חברה צד ג' כדי לשמור על האובייקטיביות), ולאחר מכן, בהתאם לממצאים, לקבוע תוכנית להפחתת הסיכונים (בהתאם לרמות תיאבון הסיכון והמתודולוגיה לניהול סיכונים (מתי אפשר לקבל סיכון, מתי נדרש לנהל אותו או להעביר אותו לצד ג').
בעוד שהרבה לא יודעים (כי לא מכירים היטב את התקן), נדרש לשלב בין תהליך הערכת הסיכונים, לתהליך של ניתוח השלכות עסקיות (BIA). ואם תחשבו על זה, תראו שזה גם הגיוני. הרי אבטחת מידע אינו תהליך עסקי, אלא תומך בפעילות העסקית, ולכן על כל סיכון, הנהלת הארגון רוצה להבין מהי מידת ההשפעה על הפעילות העסקית, ואת זה לא ניתן לגלות רק באמצעות הסקר סיכונים. שילוב נכון בין תהליך זיהוי והערכת סיכונים, לבין ה-BIA, יכול להניב תוצאות טובות יותר לסקר, ולשפר את החוסן של הארגון מבחינת עמידה באיומי סייבר פוטנציאליים, וגם אירועי קיצון.
דרישה נוספת שלרוב מתפספסת, היא התייחסות לתהליכים ומידע. לרוב, סקרי הסיכונים מתבצעים על המערכות הטכנולוגיות, ולא נעשה תהליך מוסדר של הערכת סיכונים לתהליכים העסקיים הקריטיים בארגון, ולכלל המידע שמעובד במערכות המידע בארגון, או מחוצה לו.
מבחינת התהליך, צריכים ראשית למפות את כל התהליכים העסקיים הקריטיים, להבין איזה מידע מעורב בתהליך הזה, ולאחר מכן לסווג את רמת הקריטיות של התהליך, בהתאם לרמת הקריטיות של המידע (בהיבטים של זמינות המידע ללקוחות או לעובדים), ורגישות המידע (בהיבטים של סודיות, שלמות או אמינות הנתונים).
המטרה של תוכניות ההפחתה, היא לטפל בכל הסיכונים שהארגון לא יכול לקבל אותם, ולכן צריכים להוריד את הסיכון לסיכון שיורי, שהארגון יכול לקבל אותו (בהתאם לתיאבון הסיכון שהוגדר במדיניות ניהול הסיכונים).
תוכניות ההפחתה וטיפול בסיכונים, יכולות להסתמך על הבקרות שנמצאות בנספח א' (Annex A) בתקן אבטחת מידע (ISO 27001), אבל הארגון יכול גם להוסיף בקרות נוספות שאינן נמצאות בתקן, בהתאם לממצאים שעלו בתהליך הערכת הסיכונים.
התקן גם דורש שתהליך הערכת הסיכונים, ותוכניות ההפחתה יהיו מתועדות, ולכן חשוב לשמור את התיעוד לכך (דוחות הערכת סיכונים, ותוכניות ההפחתה). כמו כן, הממצאים של תהליך הערכת הסיכונים, והתוכניות הפחתה צריכים להיות מוצגים בפני הנהלת הארגון, ולקבל את אישורם להמשך טיפול. ניתן לעשות את זה במהלך סקר הנהלה (תהליך שגם חובה לבצע במסגרת התקן, או בישיבה נפרדת).
במידה וישנם סיכונים שיוריים שחורגים מתהליך ניהול הסיכונים שהוגדר ע"י הארגון במדיניות ניהול הסיכונים, זה צריך להיות מגובה ומאושר ע"י הנהלת הארגון.
10. מסמך הצהרת ישימות (SOA)
לאחר סיום תהליך הערכת הסיכונים, וקביעת תוכניות ההפחתה, על הארגון להגדיר ולכתוב את מסמך הצהרת הישימות שלו או SOA (ר"ת של Statement of Applicability). מטרת מסמך זה, הינו לקבוע ולהצדיק את כל הבקרות שישימות או לא ישימות מהנספח א' (Annex A), ואת הסיבה לכך.
מלבד מסמך מדיניות אבטחת המידע הארגוני, זהו מסמך נוסף שעליו חייב להיות חתום נציג הנהלה בכירה של הארגון.
11. מטרות ויעדים
כחלק מדרישות המהותיות של התקן, על הארגון לקבוע מהן מטרות אבטחת המידע, וכנגזרת, מהם היעדים (רצוי יעדים מדידים) שאותם תרצו להשיג.
כאשר מגדירים את מטרות אבטחת המידע של הארגון, חשוב להתייחס לדרישות של כל בעלי העניין (הן בתוך הארגון והן מחוץ לארגון). כמו כן, כנגזרת מהמטרות, צריכים להגדיר יעדים מדידים לפעילויות המנא"מ.
12. בקרות המנא"מ
מלבד הבקרות שהוזכרו לעיל (מדיניות אבטחת מידע, סקר סיכונים ותוכניות הפחתה, ומטרות ויעדים), ישנן בקרות נוספות ותהליכים שצריכים לקיים כחלק מפעילויות המנא"מ. חשוב לוודא שהארגון נתן מענה הולם לכל דרישות המנא"מ. עקרון חשוב שא כולם יודעים, הדרישות של המנא"מ, מהווה את מהות התקן עצמו, והבקרות מהנספח א' (Annex A), כפי שהשם מרמז, אלו בקרות שנספחות לתת מענה לסיכונים שנקבעו בתהליך הערכת הסיכונים. להבדל משאר הבקרות בסעיפי המנא"מ, לארגון יש חופש פעולה אודות איזה בקרות מתוך הנספח א' עליו להטמיע (בהתאם למידת הישימות), אבל כאשר מדברים על הבקרות ותהליכי העבודה בתוך סעיפי המנא"מ – הכל חובה ליישום.
13. בקרות אבטחת מידע
בהתאם לתוכניות ההפחתה, ותוכנית העבודה בתחום אבטחת מידע, הארגון צריך להטמיע את כלל בקרות אבטחת המידע והגנת הפרטיות כפי שנדרש מהתקן. את הבקרות ניתן לחלק ל-4 סוגים:
בקרות ניהוליות: תחת הבקרות הניהוליות, ניתן לכלול את כל המסמכים הרלוונטיים (כגון מסמכי מדיניות, נהלים, רשומות, הנחיות וכדומה), הדרכות מודעות, תוכנית להמשכיות עסקית, תוכנית להתאוששות מאסון, וכדומה.
בקרות טכניות: תחת הבקרות הטכנולוגיות, ניתן לכלול את כל הבקרות הטכנולוגיות (כגון פירוול, מערכות SIEM, מערכות DLP, מערכות EDR, הצפנות, WAF, וכדומה).
בקרות תפעוליות: תחת הבקרות התפעוליות, ניתן לכלול את כל הבקרות התפעוליות בתחום אבטחת מידע (כגון הקשחת מערכות, הערכת וניהול פגיעויות, התקנת טלאים למערכות, תרגולים של סייבר, תרגולים של המשכיות עסקית, הכשרות והדרכות, ועוד).
בקרות אבטחה פיזית וסביבתית: תחת הבקורת הפיזיות, אפשר לכלול את כל הבקרות כגון גילוי אש (חיישנים לגילוי אש), כיבוי אש (מטפים, ספרינקלרים), מערכות אל-פסק, גנרטורים, מצלמות (CCTV), מנגנוני לבקרת כניסה (RFID, ביומטרי), ועוד.
חשוב לזכור, שעל מנת לאבטח היטב את הארגון, נדרש לאמץ את מודל השכבות (Layered Defense), כך שככל שיש יותר שכבות של הגנה, יהיו יותר קשה ומאתגר בשביל התוקף לגרום נזק לפעילות העסקית של הארגון.
14. תיעוד נדרש
לאחר שהטמענו את הבקרות השונות, ישנם תהליכי עבודה שדורשים עפ"י התקן שיהיו נהלים מתועדים (פורמאליים) על מנת לספק הנחיות ברורות לבעלי התפקידים הרלוונטיים (כגון אנשי ה-IT, פיתוח, משאבי אנוש, משתמשים, וכדומה). בחלק הזה יש גמישות מסויימת מבחינת דרישות התקן, ולא חייבים נוהל לכל דבר ותהליך, אלא אפשר לרכז מספר דרישות אל תוך מסמך אחד.
כך למשל, את הפרק 9 בתקן (בקרת גישה) – ניתן לאגד את כל הדרישות של הפרק הזה אל תוך מסמך אחד של "מדיניות בקרת גישה".
בנוסף, צריכים להגדיר נהלים תפעוליים (כגון נהלי הקשחה, נהלי תפעול מערכות הגנת סייבר, נהלי תחזוקת ציוד, פלייבוקים ועוד).
15. הדרכות
אחת הדרישות החשובות בתקן, הינה ביצוע הדרכות להגברת המודעות בנושא היבטי אבטחת מידע, לכלל העובדים בארגון, ובמידת הישימות, גם לגורמים צד ג' (כגון ספקים, שותפים עסקיים, לקוחות וכדומה). החשיבות של הבקרה הזאת היא עליונה, והיא מופיעה בתקן גם בחלק של המנא"מ (בפרק 7), וגם בבקרות של נספח א' (בפרק 7 – היבטי אבטחת מידע במשאבי אנוש). כאן נדרש לאפיין ולגבש תוכנית שנתית להדרכה לכלל העובדים, שבאמצעותה ניתן להעביר לעובדים את כל ההנחיות שנכתבו בנהלים (בצורה מונגשת ופשוטה), בשילוב הסיבות והצורך בהגנה על נכסי המידע הארגוניים והפרטיות של העובדים. חשוב להסביר לעובדים מהם איומי הייחוס שרלוונטיים לפעילות העסקית של הארגון, ומהם דרכי המניעה, או זיהוי ודיווח למחלקת אבטחת מידע, מייד שמזהים ניסיון זדוני (למשל, פישינג).
והכי חשוב, נדרש לבצע תהליך של הערכת אפקטיביות של ההדרכה – וניתן לעשות את זה באמצעות תרגולים (כגון פישינע), ביקורות פתע של אבטחת מידע (כגון ביקורת מדיניות שולחן נקי) וכדומה.
16. כשירות מקצועית
בקרה נוספת שלעתים קרובות מזניחים אותה, היא שמירה ושיפור הכשירות המקצועית של כל בעלי העניין שרלוונטיים לפעילות המנא"מ. בשפה פושטה, על הארגון לאפיין ולגבש תוכנית הכשרה מקצועית בהתאם לקהל היעד (מתכנתים – הנחיות לפיתוח מאובטח, אנשי IT – דרישות הקשחה, הערכת פגיעויות, טיוב מערך הגנת הסייבר, אנשי ה-SOC – זיהוי ותגובה לאירועי סייבר, תחקור דיגיטלי, אנשי ניהול סיכונים – שיטות לזיהוי, הערכת וניהול סיכונים, לאנשים שעוסקים בהמשכיות עסקית – כיצד לבצע תהליך של BIA, כיצד לזהות ולעשות הערכת מצב אל מול איומי הייחוס, וכדומה).
נדרש לשמור תיעוד לכל פעילויות ההכשרה (למשל – תעודת סיום עבור קורסים מקוונים או באתר הלקוח).
17. תכנון ובקרה על תפעול המנא"מ בארגון
לאחר שאפיינו את הדרישות, ביצענו הערכת סיכונים, קבענו איזה בקרות צריכים לממש, וכתבנו תיעוד קיים, הגיעה הזמן של להטמיע את כל הדרישות כפי שמופיעות בתוכנית העבודה. זהו בעצם שלב בשלב הביצוע, הארגון מטמיע את כל הבקרות שזוהו (ניהוליות, טכניות, תפעוליות ופיזיות). חשוב לעבוד אל מול רשימת תיוג מסודרת, על מנת לא לפספס שום בקרה, ולהשאיר את הארגון חשוף למתקפות סייבר.
18. קביעה, ניטור, הערכה ומדידת האפקטיביות של המנא"מ
משימה מאתגרת, שלא מעט מנהלי אבטחת מידע מתקשים או מסתבכים איתה, זה תהליך קביעה, ניטור, הערכה ומדידת האפקטיביות של המנא"מ. בשלב הזה, על הארגון להגדיר מדדים (KPI’s) לבקרות הרלוונטיות (כולל תהליכי המנא"מ), לנטר אותם באופן תקופתי, לבחון את התוצאות, ולמדוד את האפקטיביות של הבקרות. היתרון בשלב הזה, הוא שניתן לבחון את האפקטיביות של הבקרות השונות, ולהפיק לקחים לשיפור. בכלל, המטרה הראשית של התקן (או של כל תקן עם מערכות ניהול), היא שיפור מתמיד. והדבר בא גם לטובתו של מנהל אבטחת המידע בארגון. על סמך התוצאות, הוא יכול להציג נתונים להנהלת הארגון, ולהצדיק את התקציב של השנה החולפת, ואת דרישותיו לשנה הנוכחית.
למשל, אם לא עמדנו ביעדים ובמדדים מסויימים, וסיבת השורש היא היעדר כח אדם, אז ניתן יהיה להצדיק גידול במצבת כח האדם (או לפחות בהצדקת הגשת הבקשה לגיוס עובדים).
19. מבדק פנימי ופעולות מתקנות
מטרתו של המבדק הפנימי, היא לעבור על כל הבקרות של התקן (המנא"מ והבקרות בנספח א'), ולוודא שכל הבקרות במנא"מ הוטמעו כהלכה, וכל הבקרות הישימות בנספח א' (לפי מסמך הצהרת הישימות), גם הוטמעו כהלכה.
בארגונים גדולים, ניתן לחלק את הארגון לאזורים גיוגרפיים שונים (אתרים פיזיים ו/או מחלקות), ולעשות את זה במהלך כל השנה (למשל, בכל רבעון אפשר לעשות חלק מסויים). המטרה היא להקל על ביצוע תהליך של מבדק פנימי (בייחוד אם מדובר בארגונים גדולים, או שיש מחסור כח אדם בארגון). לחילופין, אפשר וגם רצוי להיעזר בחברה חיצונית לביצוע המבדק הפנימי (היות ובמרבית הפעמים, היועצים מכירים היטב את דרישות התקן, מה שיאפשר לכם לוודא שלא פספסתם שום דרישה מנדטורית של התקן, וכל הבקרות הוטמעו כהלכה.
לכל הממצאים שיעלו במסגרת המבדק הפנימי, צריכים למלא טופס של פעולה מתקנת. הפעולות המתקנות נועדו לוודא שכל הממצאים שעלו במבדק הפנימי, מטופלים ומנוהלים היטב. במסגרת הפעולות המתקנות, על מנהל אבטחת המידע (או שאר הגורמים הרלוונטיים בארגון) לקבוע את סיבת השורש לאי-התאמה שנמצאה במסגרת המבדק הפנימי.
הסיבה שחיברתי בין שני הדברים, היא בגלל שעל על האי-התאמות (ממצאים שעלו במהלך המבדק הפנימי), צריכים לאפיין ולהגדיר טופס פעולה מתקנת, להציג את זה בפני הנהלת הארגון במסגרת סקר ההנהלה, ולאחר אישור ההנהלה, להוציא את זה לפועל.
20. סקר הנהלה ושיפור מתמיד
כחלק מחויבות ההנהלה, נציגי הנהלה בכירה צריכים להשתתף בפגישות תקופתיות (לפחות אחת לשנה), עם מנהל אבטחת המידע. פגישות אלו נקראות בשפה של התקן "סקר הנהלה", מטרתם היא להציג בפני נציגי הנהלת הארגון את כלל הממצאים של המנא"מ, כגון:
סטטוס של יעדים ומדדים
אירועי סייבר מהותיים ומה נעשה על מנת לטפל בהם
תוצאות של סקרי סיכונים ותוכניות ההפחתה
תוצאות של המבדקים הפנימיים והפעולות המתקנות שהוגדרו
את מסמך הצהרת הישימות
תוכנית עבודה להטמעה, תחזוקה ושיפור פעילויות המנא"מ
מחויבות ההנהלה ניכרת בכך שנציגי ההנהלה מעורבים בתהליכי המנא"מ, לרבות אישור והקצאת משאבים נאותים (תקציב לרכישת בקרות חדשות, תקציב לטיוב תהליכים ובקרות קיימות, תקציב לגיוס כח אדם חדש, תקציב להכשרת כח אדם קיים, ועוד).
אני מזכיר שוב, שהמטרה העיקרית של התקן, הינה שיפור מתמיד, וע"י הטמעה נכונה של המנא"מ, ותחזוקה שוטפת, ניתן להציג גם שיפור מתמיד.
לרוב, ארגונים בוחרים במודל ה-PDCA (ר"ת של Plan-Do-Check-Act) שמטרתו לשפר תהליכים בתוך הארגון. נדון על המודל הזה בהרחבה בקטנה אחרת.
בכל מקרה, לכל שאלות הבהרה, תוכלו לפנות אלי בכתובת: danny@titans2.com
הכותב הינו סוקר מוסמך בינלאומי (ISO 27001 Lead Auditor), ומרצה מוסמך לקורס זה, וביצע אלפי פרויקטים של הכנת ארגונים גדולים בארץ ובחו"ל לעמידה בדרישות התקן.
כמו כן, הכותב מוסמך גם כסוקר מוביל לתקן לניהול המשכיות עסקית (ISO 22301 Lead Auditor), מוסמך כסוקר מוביל לתקן לניהול תחום הגנת הפרטיות (ISO 27701 Lead Auditor), ובעל הסמכות מקצועיות נוספות כגון CISSP, CISM, CISA, CRISC, CGEIT, CDPSE, ועוד.
בנוסף, הכותב מכהן גם כנשיא של הציאפטר הישראלי – באיגוד העולמי לאבטחת מידע (ISSA).