יום שני, 27 במאי 2013

אבטחת טכנולוגיית מידע (אט"מ)/הגנת סייבר(ה"ס): אחריות, בסיס ידע, מדיניות, נהלים והוראות עבודה - פרשנות רחבה


הפוסט הזה (הוא ארוך מאד, אבל החלטתי להעלותו כיחידה אחת) מסכם ניסיון שנצבר על ידי במעל 30 שנות עיסוקי בנושא.
1.    הגדרות + פרשנות
1.1.       אבטחת טכנולוגיית המידע (אט"מ)/הגנת סייבר (ה"ס) (להלן: אט"מ/ה"ס)
1.1.1.         מכלול האמצעים המתוכננים ומופעלים במישורים הפיזיים, מיחשוביים (לעתים מכונים "לוגיים", בניגוד ל"פיזיים"), תהליכיים ואנושיים, על מנת להשיג ולשמר סודיות, שלמות ואמינות, זמינות ושרידות למידע, מערכות טכנולוגיית המידע ומערכות טכנולוגיות אחרות.
1.2.       בסיס ידע (תורת האבטחה)
1.2.1.         אוסף של מסמכים.
1.2.2.         כולל את כל הידע הנדרש על מנת לבצע את כל פעילויות אט"מ/ה"ס. ניתן לכנות את בסיס הידע "תורת האבטחה או "התנ"ך של האבטחה. ראה הרחבה בפרק 3 של מאמר זה.
 
1.3.       מדיניות
1.3.1.         מסמך כתוב.
1.3.2.         חתום ע"י הנהלת/דירקטוריון הארגון.
1.3.3.         מפרט ומבהיר את עמדתם לגבי נושא מוגדר.
1.3.4.         מכיל את העקרונות המנחים בנושא המדובר עבור הארגון ובה בעת מבטא את מחויבותם הם (של הגוף החתום על המסמך) למימוש המדיניות.
1.3.5.         התוכן מותנה במספר משתנים. אלו יוסברו בפירוט בהמשך המסמך.
1.3.6.         אחריות לכתיבת המסמך:
1.3.6.1.        מנהל אט"מ/ה"ס בארגון.
1.3.6.2.        באם אין בעל תפקיד כזה בארגון (וסביר שברוב רובם של הארגונים אין תפקיד כזה, לפחות לא בשלב זה), אזי המסמך ייכתב ע"י מנהל אבטחת המידע (CISO). תפקידו בהיבט זה כפול:
א.        כתיבת פרקי המסמך:
1.        כתיבה בפועל של החלק שבתחום אחריותו. מהו? יש לבחון את הגדרת תפקידו ומשם לגזור את התכנים. במדינת ישראל במגזרים רבים, לדוגמה במגזר הפיננסי, תחום האחריות שלו מוגבל בעיקר להגנה ושימור מרכיב הסודיות (C), של המשולש (סודיות, שלמות ואמינות, זמינות ושרידות C-I-A).
2.        ומה עם השאר, מה שאיננו בתחום אחריותו עפ"י הגדרת תפקידו? ה-CISO נדרש לוודא שכל מנהל בארגון שלו אחריות לכתיבת חלק/חלקים
ב-אט"מ/ה"ס יכתוב את חלקו.
ב.        לשלב את כל התכנים לכדי מסמך אינטגרטיבי אחד הנושא את הכותרת : מדיניות אט"מ/ה"ס של הארגון.
מדוע זה תפקידו? משום שהוא מזכיר ועדת ההיגוי
ל-אט"מ/ה"ס. ומדוע הוא מזכיר הועדה? בגלל העובדה שיותר מחצי המשימות מתרכזות סביבו או מונחות על ידו באופן ישיר/עקיף.
אם צריך להצביע על בעל תפקיד אחד בארגון, הוא בעל התפקיד לבצע משימה זו.
1.4.       נוהל
1.4.1.         מסמך כתוב.
1.4.2.         כולל הנחיות ברורות כיצד יש לבצע משימה מוגדרת המוזכרת במדיניות.
1.4.3.         מופנה לעבר קבוצת אוכלוסייה מוגדרת. על מנת להבהיר כוונתי באופן חד משמעי, נוהל איננו תיאור מלא של משימה ארגונית המבוצעת ע"י יחידות ארגוניות שונות, (זה נקרא בז'רגון המקצועי: מסמך מהלך עבודה -   Workflow Document) ולא נוהל.
1.4.4.         אחריות לכתיבת המסמך:
1.4.4.1.        היחידה הארגונית שהינה בעלת התהליך.
1.4.4.2.        ישנם ארגונים שבהם קיימת יחידה ארגונית ייעודית שתפקידה כתיבת נהלים, אזי היחידה הארגונית שהינה הבעלים של התהליך אחראית להעברת התכנים של הנוהל ליחידה שאחראית על כתיבתם. היחידה שאחראית לכתיבתם מבצעת את הפעילות הטכנית של הכתיבה, אך משמרת את עובדת היות היחידה הארגונית שהעבירה לה את התכנים, בעלת התהליך. 
1.5.       הוראת עבודה
1.5.1.         מסמך כתוב.
1.5.2.         כולל הוראות מפורטות (טכניות או מנהליות. לעתים ברמת צעד-אחר-צעד) כיצד לבצע משימה מוגדרת.
1.5.3.         אחריות לכתיבת המסמך:
1.5.3.1.        היחידה הארגונית שהינה בעלת התהליך.  
1.6.       וועדת היגוי ל-אט"מ/ה"ס
1.6.1.         קבוצה של מנהלים בכירים שמנכ"ל או אחד הסמנכ"לים ממנה על מנת לנווט/לפקח/לבקר את מכלול פעילויות אט"מ/ה"ס בארגון.
1.6.2.         בדרך כלל, החברים בוועדת ההיגוי מייצגים את המחלקות הארגוניות שלהן אחריות לחלקים שונים של אט"מ/ה"ס, לדוגמה: אגף טכנולוגיית המידע, אבטחה פיזית, רכש, משאבי אנוש, לשכה משפטית, מחלקות עסקיות ועוד. 
1.6.3.         יו"ר הוועדה יהיה המנכ"ל או אחד מסגניו.
1.6.4.         מזכיר הוועדה אמור להיות המנהל המופקד על פעילויות אט"מ/ה"ס בארגון. בהיעדר בעל תפקיד כזה בארגון, (זה בדרך כלל המצב), מנהל אבטחת המידע (CISO) יתמנה לתפקיד זה.
1.6.5.         הוועדה תתכנס בתדירות של 2-4 פגישות מתוכננות בשנה. אופציונאלית תכונס לפגישות שלא מן המניין (בסמכות יו"ר הוועדה).
1.6.6.         בסמכות הוועדה (בין יתר סמכויותיה) להזמין לדיוניה נציגים מהארגון ומחוצה לו בהתאם לעניין.  
2.    אחריות ל-אט"מ/ה"ס
2.1.       לאור ההגדרות הנ"ל, נראה שאין מנהל אחד בארגון שהנו בעל יכולת לפעול כבעל האחריות היחיד שאין לו שותף מלבדו לכל הפעילויות המרכיבות את אט"מ/ה"ס בארגון.
2.2.       מספר דוגמאות על מנת להמחיש אמירה מפתיעה זו:
2.2.1.         משאבי אנוש אחראי בארגון לניהול מחזור חיי העובדים בארגון. אחד הנושאים באחריותו עשוי להיות בצוע סינון המועמדים לקבלה לעבודה. אחד הפרמטרים בתהליך הסינון חייב להיות אמינות/מהימנות המועמד. על כן, ייתכן  שאגף משאבי אנוש אמור לקבל קלט ממנהל אבטחת המידע או מקצין הביטחון או משניהם גם יחד מה נדרש לבצע בנושא מבדקי אמינות/מהימנות. דוגמה: כאשר המועמד לקבלה לעבודה אמור לעסוק בתפקיד מנהלן מערכות המידע (System Administrator) ובשליטתו יהיו כל מערכות המידע של הארגון. הרי לא יעלה על הדעת לשכור את שרותיו של אדם ללא מבדקי רקע ובחינה של מהימנותו במגוון מבדקים שונים. כנ"ל כאשר אנו מדברים על תפקידים רגישים במחלקות ארגוניות שונות. דוגמה לכך תהיה תפקיד הגזבר או מנהל הרכש וכן הלאה. ומה לגבי הקפאה זמנית של הרשאות גישה לעובדים היוצאים לחופשה ארוכה (חופשה ללא תשלום/חופשת לידה) וביטול הרשאות הגישה לעובדים המסיימים את עבודתם בארגון? כל הפעילויות הללו מקורן באגף משאבי אנוש, בהיותה היחידה הארגונית שבאחריותה מחזור חיי העובד בארגון. בנוסף, הם האחראים להגדיר (בסיוע היחידות העסקיות בארגון), מהם התפקידים הקיימים בארגון. תפקידים אלו מהווים את המסד שעליו נבנה מערך ההרשאות. ומה לגבי ענישה משמעתית שיש לתכנן, לפרסם לעובדים ולהפעילה במידה ועובד מפר את מדיניות אט"מ/ס"ס או פועל שלא עפ"י נוהל/הוראת עבודה בנושא אט"מ/ה"ס? כל הנושאים שהוזכרו לעיל מצויים תחת אחריות אגף משאבי אנוש בארגון.
2.2.2.         הרכש מטפל בכל הרכש המתבצע בארגון. חלקו עשוי לכלול רכיבי טכנולוגיית מידע, או כל תהליך של רכש שאחת מתוצאותיו האפשריות הנה שינוי ברמת אט"מ/ה"ס הנוכחית שבה שרוי הארגון. לדוגמה, רכש של סמארטפונים חדשים אשר יכללו מידע ארגוני מסוג כלשהו.
2.2.3.         אבטחה פיזית אחראית להגנה על בני אדם, רכוש ומידע באמצעות מתן התייחסות להיבטים הפיזיים של תהליכי האבטחה. אחת הדוגמאות עשויה להיות האמצעים שי לנקוט על מנת להגן על מחשבים ניידים כאשר הם מנוידים מהארגון אל מחוץ לארגון. אבטחה פיזית בדוגמה זו תנחה כיצד לשאת את המחשב הנייד, כיצד להגן עליו במכונית הפרטית, בתחבורה ציבורית, בנמל תעופה, בעת הטיסה במטוס, וכן הלאה. על מנת להשלים את התמונה בדוגמה זו, אבטחת המידע בהיבטים המיחשוביים תידרש לספק הנחיות כיצד להגן על הנתונים במחשב הנייד מפני זליגה לגורם בלתי מורשה (באמצעות הצפנה לדוגמה) או כיצד להגן על המחשב הנייד מפני חדירת תוכנות זדוניות (באמצעות כלי אנטי וירוס לדוגמה).
2.2.4.         יחידות עסקיות/ארגוניות הנן הסיבה מדוע הארגון בכלל קיים. יחידה ארגונית אחראית לאחד או יותר תהליכים עסקיים שהארגון מעוניין לבצע. המשמעות של אחריות לתהליך עסקי הינה שהאחריות אמורה לכלול את כל ההיבטים של התהליך. אחד מהנושאים הנו ניהול כל הסיכונים הנלווים לתהליך. חלקם עשויים לכלול, זליגת מידע סודי (אם קיים כזה בתהליך), נתונים לא אמינים או לא שלמים המהווים חלק מהתהליך ועל כן נדרש לבצעו מחדש לאחר טיוב הנתונים (אם בכלל התהליך הנו כזה שניתן לחזור עליו), אי יכולת לבצע את התהליך עפ"י הסכם רמת השירות (Service Level Agreement) שעליו התחייבה היחידה הארגונית לגבי התהליך וכיו"ב. כיוון שארגונים משתייכים למגזרים (חינוך, בריאות, פיננסים ועוד), ועל כן נבדלים ביחידותיהם הארגוניות, אשתדל לתת דוגמה אשר ניתן להכילה כמעט בכל ארגון. הדוגמה תהיה אגף השיווק.
אגף השיווק, אחראי על תהליך השיווק. כיום, אתר אינטרנט של ארגון הנו כלי שיווקי מקובל ונפוץ. ומה באשר לסיכונים? זה מידע שיווקי פתוח לכל, אין מידע סודי מסווג, אז למי אכפת? אין מידע מסווג שיכול לזלוג... אמת הדבר. א-ב-ל... מה לגבי אמינות/שלמות המידע המוצג לציבור הרחב הגולש לאתר? אה כן, זה כבר חשוב. ומה לגבי זמינות אתר האינטרנט? אה, כן, גם זה חשוב. מישהו שמע על השחתת אתר (Defacement)? התקפה מבוזרת למניעת שירות (DDOS)? OPISRAEL ואחרות? אינני חושב שקיים מנהל שיווק אחד שישמח לקבל טלפון מהמנכ"ל שלו שיבשר לו שאתר האינטרנט של הארגון הושחת ע"י פצחנים (האקרים) ויש להפסיק את פעולתו.
תכנון ויישום של האמצעים הנכונים כנגד האיומים/סיכונים הרלוונטיים לתהליך שבעל התהליך אחראי עליו, הנו תוצאה של בצוע ניהול סיכונים. ניהול סיכונים לתהליך הנו באחריותו של בעל התהליך.
מאחר ויותר ויותר תהליכים ארגוניים הופכים תלויי טכנולוגיה, על הבעלים לסגל לעצמם יכולות לקבל אחריות על ניהול האיומים/הסיכונים הכולל את ההיבטים הטכנולוגיים הנלווים לתהליך.
2.3.       כפי שהוזכר לעיל, הדוגמאות הנ"ל מספקות לנו הצצה למשימה הארגונית המורכבת של השגה ושימור של אט"מ/ה"ס. אני מקווה שבנקודה זו כבר ברור שמדובר במשימה ארגונית אשר עליה מפקחת ואותה מנווטת ומבקרת וועדת ההיגוי ל-אט"מ/ה"ס, כאשר יותר מיחידה ארגונית אחת מחויבת/אחראית לבצע משימות שונות להשגת המטרה. המשימות והאחריות מותאמות לתפקידים ולתחומי האחריות המקוריים של אותן היחידות הארגוניות.  
2.4.       בואו נניח, שהמצב התואר בסעיף 2.3 לעיל הינו המציאות. כעת עולה השאלה מהן אבני הבניין? כיצד כל יחידה ארגונית תדע מה עליה לבצע? המענה טמון במתודולוגיה של כתיבה ופרסום  של מסמכים ארגוניים פורמליים: מדיניות, נהלים והוראות עבודה. בזה יעסוק הפרק הבא של מסמך זה.
3.    פיזור הידע של אט"מ/ה"ס בארגון
3.1.       הסבר לשם הפרק
3.1.1.         ראשית, מדוע שמו של הפרק הנו פיזור הידע ולא כתיבת המסמכים?
3.1.2.         המענה הנו שלפני כתיבה כיצד על הארגון לפעול בתחום ה-אט"מ/ה"ס, על הארגון לאמץ את בסיס הידע של אט"מ/ה"ס ("תורת האבטחה").
3.1.3.         בסיס הידע יכול להיבנות מאחד מהבאים:
3.1.3.1.        בסיס ידע שהוכן ע"י רשות מוסמכת לעניין זה ועבור ארגון זה/המגזר שאליו משויך הארגון. בדרך כלל, הארגון חייב לאמץ את בסיס הידע כיוון שמדובר בתהליך המגובה בחוק מדינה. במצב זה עולה שאלה אחרת: כמה שלם בסיס הידע שנכפה על הארגון אל מול המשימה הארגונית הכוללת בהיבטי אט"מ/ה"ס? מניסיוני, בדרך כלל מדובר בבסיס ידע שאיננו שלם. אם כך, על הארגון להרחיב/להשלים את בסיס הידע לפחות לרמה סבירה עבור הארגון.  
3.1.3.2.        בסיס ידע מקובל שהשימוש בו נפוץ. דוגמה יכולה להיות תקן בינלאומי או קבוצת תקנים בינלאומיים שהוכן/הוכנו ע"י ארגון תקינה בינלאומי או ארגוני תקינה בינלאומיים. דוגמה לכך הנו תקן ISO 27002 עבור ארגונים שבהם מערך טכנולוגיית מידע רגיל/שגרתי (מערכות מחשב לשימוש כללי). דוגמה נוספת הינה שילוב של תקן ISO 27002 ותקן ייעודי מגזרי:
1.      למגזר הבריאות: שילוב של תקן ISO 27002 עם תקן ISO 27799 ובנוסף בסיס ידע להגנה על מכשור רפואי.
2.       למגזר הטלקום: שילוב של תקן ISO 27002 עם תקן ISO 27011.
3.      למגזר הפיננסי: שילוב של תקן ISO 27002 עם תקן ISO 27015.  
3.1.3.3.        בסיס ידע שהארגון מכין/רוכש ואיננו נכלל באמור לעיל. בסיס ידע שמוכן ע"י גורמי פנים או גורמי חוץ מקצועיים עבור הארגון בהזמנה מיוחדת ("Tailor made".)
3.1.3.4.        בסיס ידע המהווה שילוב כלשהו של האמור לעיל.
3.1.4.         בכל מקרה, וללא קשר איזה סוג של בסיס ידע הארגון יבחר לאמץ, נקודת הפתיחה הנה בסיס ידע, ולא כתיבת מדיניות.
3.2.       להלן, פירוט לגבי סוגי המסמכים שהוזכרו. אנסה שלא לחזור על דברים שנכתבו בפרק הראשון (הגדות + פרשנות).
3.3.       מדיניות אט"מ/ה"ס
3.3.1.         כוללת ב"משפטי מדיניות" את כל האספקטים של אט"מ/ה"ס שהארגון חושב שעליו לכלול. יש לזכור, שמבחינה פורמלית, השמטה של משהו ממסמך המדיניות, מונעת כתיבת נוהל עבורו. באם אין נוהל אין פעולה. חסרונו של נוהל עלול לגרום שמשהו שאמור היה להתבצע לא יבוצע.
3.3.2.         מסמך בעל תפקיד כפול:
3.3.2.1.        לשימוש פנים ארגוני: משמש כבסיס לכל פעילויות אט"מ/ה"ס בארגון.
3.3.2.2.        לשימוש חיצוני: משמש בסיס לביקורת חיצונית, האם הארגון יכול להשיג את יעדי אט"מ/ה"ס שעליו להשיג?.
3.3.3.         בכתיבת המדיניות, יש לתת את הדעת לארבעה מרכיבים:
3.3.3.1.        בסיס הידע ל-אט"מ/ה"ס שאומץ ע"י הארגון..
3.3.3.2.        עצמאות הארגון. האם קיימות/אינן קיימות מגבלות חוקיות/רגולטוריות אחרות, בנוסף לבסיס הידע שאומץ.
3.3.3.3.        מה ייחשב חיוני שייכלל?
3.3.3.4.        מהן הדרישות הייחודיות ("טביעת האצבעות" של ארגון זה) שיש לכלול. במילים אחרות, מהם השינויים האמיתיים בין מסמך מדיניות זה ממסמכי מדיניות אחרים של ארגונים דומים באותו המגזר.
3.3.4.         מסמך מדיניות אט"מ/ה"ס טיפוסי יכלול את הפרקים הבאים::
3.3.4.1.        פרק מס' 1: הגדרות
3.3.4.2.        פרק מס' 2: תיאור כללי של {שם הארגון}: עיקרי פעילותו ומרכיבי טכנולוגיית המידע/סייבר (להלן: מט"מ/ס) שבו נעשה שימוש.
3.3.4.3.        פרק מס' 3: מטרות מסמך המדיניות (שונה ממטרות יישום המדיניות בארגון).
3.3.4.4.         פרק מס' 4: איומים וסיכונים עיקריים ל-מט"מ/ס וטכנולוגיות אחרות בארגון (מה הצורך ב-אט"מ/ה"ס)
3.3.4.5.        פרק מס' 5: ניהול סיכוני השימוש במידע, מט"מ/ס וטכנולוגיות אחרות בארגון. מעשית מדובר בהבהקים מתודולוגיים של אט"מ/ה"ס בקצרה. (מה זה אט"מ/ה"ס בלשון מנהלים).
3.3.4.6.        פרק מס' 6: המטרות של יישום מסמך המדיניות.
3.3.4.7.        פרק מס' 7: תחולת המדיניות. על מי המדיניות חלה.
3.3.4.8.        פרק מס' 8: אחריות וסמכות בארגון –  יכלול לדוגמה את: יחידת אבטחת מידע ומנהלה, וועדת היגוי, מחלקות שונות בארגון שלהם תפקיד בהשגת יעדי אט"מ/ה"ס וכיו"ב).
3.3.4.9.        פרק מס' 9: הבהקים ייחודיים לארגון –  עקרונות יישום אט"מ/ה"ס בארגון. לדוגמה:
1.        אחריות וחבות אישית בנושא אט"מ/ה"ס,
2.        סיווג מידע,
3.        טיפול במשאב האנושי (פנימי וחיצוני),
4.        הזדהות ווידוא הזדהות ל-מט"מ/ס, טכנולוגיות אחרות,
5.        הפרדת תפקידים וסמכויות,
6.        גישה מרחוק למידע, מט"מ/ס וטכנולוגיות אחרות שבבעלות/בתפעול הארגון,
7.        דרישות אבטחה (פיזיות, מיחשוביות, תהליכיות ואנושיות) המוטלות על גופים חיצוניים (מיקור חוץ, ספקים, לקוחות וכיו"ב).
8.        שילוב דרישות אבטחה בתהליכי רכש, פיתוח, שינוי ושדרוג של מערכות,
9.        בקרה וביקורת,
10.   בקרות טכנולוגיות,
11.   בקרות פיזיות (אט"מ/ה"ס מתחילה בטיפול בנושא הפיזי),
12.   אמצעי בטיחות במערך המאחסן מערכים טכנולוגיים מרכזיים,
13.   תכנון המשכיות עסקית.
3.3.4.10.   פרק מס' 10: חריגה מהמדיניות.
3.3.4.11.   פרק מס' 11: עדכון המדיניות.

3.4.       נהלים
3.4.1.         הסבר לשם הפרק
3.4.1.1.        ראשית, מדוע שם הפרק הנו "נהלים" ולא נהלי אט"מ/ה"ס?
3.4.1.2.        המענה הנו בליבת העניין שאני מבקש להבהיר. כפי שהוגדר בפרק הראשון (הגדרות + פרשנות), נוהל נכתב ע"י הבעלים של התהליך. כפי שהוסבר במהלך מסמך זה, רק חלק מפעילויות אט"מ/ה"ס בארגון ניתן להכתירן בכותרת: "פעילות אט"מ/ה"ס". דוגמאות לפעילויות שכן ניתן לסווגן כפעילויות אט"מ/ה"ס יכללו את "תכנון וניהול סקר אבטחת המידע ומבדקי חדירה מבוקרים" שלהן אחראי מנהל אבטחת המידע, או "תכנון ומעקב בצוע של תוכנית שנתית לאבטחת מידע", גם זו פעילות שבאחריות מנהל אבטחת המידע. פעילויות רבות אחרות התורמות להשגת יעדי אט"מ/ה"ס מבוצעות או נכון יותר יהיה לומר נדרש שישולבו בתהליכים המבוצעים ע"י מגוון יחידות ארגוניות. נהלים המתארים את האופן שבו יחידות ארגוניות מבצעות את פעילותן ובהן משולבות דרישות אט"מ/ה"ס, אינם נהלי אט"מ/ה"ס. נהלים אלו נכתבים ע"י יחידות ארגוניות והפעילויות המתוארות בהם מבוצעות ע"י יחידות ארגוניות, בהתאם לתפקידיהן בארגון. ומה באשר
ל-אט"מ/ה"ס? זה יוסבר בהמשך המסמך.
3.4.1.3.        מנקודה זו ואילך, אין במסמך הפרדה בין נוהל והוראת  עבודה. אני משאיר זאת להחלטתו של קורא המסמך או למי שאמור ליישמו לייצר עבור תהליך שני מסמכים (מסמך "נוהל" ומסמך "הוראת עבודה" שניהם בעלי אותו השם) או מתי אחד מהם יספיק.
3.4.1.4.        ייכתב פרק נפרד כאשר ארגון שלם או אגף ארגוני (במיוחד אם מדובר באגף מערכות המידע עצמו) מוסמך לתקן האיכות ISO 9001 (תקן ניהול האיכות).
3.4.2.         נהלי אט"מ/ה"ס
3.4.2.1.        אתר את פעילויות אט"מ/ה"ס האמתיות, אלה שאין ספק שניתן לסווגן כ"תהליכי אט"מ/ה"ס. הצבעתי על שתי דוגמאות בסעיף 3.4.1.2.
3.4.2.2.        לכל אחת מפעילויות אלו, יש לכתוב נוהל.
3.4.2.3.        מי כותב אותו? כפי שכבר הזכרתי, בדרך כלל יהיה זה
ה-
CISO. הוא בעל התפקיד האחד בארגון שכל הגדרת התפקיד שלו סובבת רק ואך ורק סביב אט"מ/ה"ס. אבל הוא איננו בעל התפקיד היחיד בארגון שיש לו משימות בתחום ה-אט"מ/ה"ס. מה אם כך עם האחרים?
ה-CISO הנו דמות מפתח ביכולתם של האחרים בארגון לדעת מה עליהם לבצע במסגרת אט"מ/ה"ס בארגון, אבל הוא איננו בעלים של תהליכי עבודה אחרים בארגון. על כן:
1.        ה-CISO איננו כותב את הנהלים של יחידות אחרות בארגון.
2.        ה-CISO. איננו כותב נהלים עבור יחידות אחרות בארגון.
3.        ה-CISO איננו כותב נהלים במקום שיחידות ארגוניות אחרות יכתבו כל אחת את נהליה היא.
4.        ה-CISO מנחה יחידות ארגוניות אחרות, על פי בסיס הידע שאומץ על ידי הארגון. בהמשך יוסבר נושא הנחיית אט"מ/ה"ס.
3.4.2.4.        כיצד כותבים נוהל? לאו דווקא נוהל אט"מ/ה"ס. להלן הנחיות לכתיבת נהלים מכל מין וסוג:
1.      כתוב את הנהלים בארגון תוך שימוש בתבנית אחת. התכנים יהיו כמובן שונים, אבל המבנה (שמות הפרקים) מומלץ שיהיו זהים לכל נהלי הארגון. זו השיטה הטובה ביותר להבטיח פשטות בכתיבה, בקריאה, בהבנה ובהטמעה. (הרעיון: Keep It Simple).
2.      דוגמה אפשרית המיישמת עבור נהלים את האמור בסעיף 1 לעיל:
א.        פרק מס' 1: כללי – מבהיר את הסיבה/בות מדוע קיים צורך לכתוב נוהל.
ב.        פרק מס' 2: מטרה/מטרות – מהי המטרה/מהן המטרות שנדרש להשיג בפעילות או בפעילויות המתוארות בנוהל.
ג.         פרק מס' 3: הגדרות – הגדרת מונחים הנדרשים להבנת הנוהל. (אופציונאלי, במובן שפרק מס' 3 תמיד יופיע כ-"הגדרות". אם אין מונחים שנדרש להגדירם, תירשם מול הכותרת המילה "אין").
ד.         פרק מס' 4: אחריות – מי אחראי לכתיבת/עדכון הנוהל.
ה.       פרק מס' 5: חלות – על מי בארגון הנוהל חל.
ו.          פרק מס' 6: השיטה – הגוף העיקרי של הנוהל. הפרק מתאר באופן הבהיר והמובן ביותר האפשרי הפעילות/הפעילויות שנדרש שיבוצעו ע"י אלו המוגדרים בפרק 5 של הנוהל (ראה לעיל)
ז.         פרק מס' 7: נספח/ים – טפסים, ומסמכים אחרים שלדעת כותב הנוהל הינם רלוונטיים ליישום הנוהל.
3.4.3.         הנחיות/דרישות אט"מ/ה"ס
3.4.3.1.        הנחת עבודה: ה-CISO הנו דמות המפתח בפעילויות אט"מ/ה"ס בארגון. מהי המשמעות?
המשמעות המעשית הנה שעליו להוציא הנחיות כתובות למחלקות בארגון. אני משתמש במונח "הנחיות" כיוון שאני מעריך שמבחינה טכנית זו המילה הנכונה להשתמש בה. אלא שהנחיות אלה הנן למעשה "דרישות אט"מ/ה"ס".
מהו התוכן של הנחיות/דרישות אלו? מהי מטרת ההנחיה?
3.4.3.2.        הנחיות/דרישות אט"מ/ה"ס - תוכן
1.        מיצוי תוכן מבסיס הידע.
2.        לכל יחידה ארגונית, ימוצה התוכן הרלוונטי עבורה.
3.4.3.3.        הנחיות/דרישות אט"מ/ה"ס - מטרה
1.        כל יחידה ארגונית בהתאם לתפקידה/תפקידיה הטבעיים בארגון המקבלת הנחיות/דרישות אט"מ/ה"ס תשלב אותן בנהליה.
3.4.3.4.        הנחיות/דרישות אט"מ/ה"ס – תוצאות כלל ארגוניות
1.        נהלים/הוראות עבודה בכל היחידות בארגון כוללים/כוללות את הנחיות/דרישות אט"מ/ה"ס שמוצו מבסיס הידע שאומץ ע"י הארגון.
2.        פעילויות אט"מ/ה"ס משולבות בתהליכי העבודה של כל היחידות בארגון.
3.4.3.5.        נותרו מספר הנחיות/דרישות אט"מ/ה"ס מיוחדות. ייחודן בכך שהן מופנות לכל הארגון. ככל שניתן הדבר המלצתי הנה לשלב הנחיות אלו בהנחיות יחידות ארגוניות אחרות ולא להשאירן כהנחיות אט"מ/ה"ס ייחודיות. הדוגמה הטובה ביותר הנה הנחיות אט"מ/ה"ס למשתמשי מט"מ/ס. הנחיות אט"מ/ה"ס למשתמשי קצה יש לשלב במכלול ההנחיות לעובדים. הנחיות אלו מתפרסמות באחריות אגף משאבי אנוש. זוהי ה"דרך הראשית" שבה בוחר הארגון להעביר לעובדיו את חובותיהם (דרישות הארגון) וזכויותיהם. מדוע לא להשתמש בה על מנת להעביר את דרישות אט"מ/ה"ס שהארגון דורש מעובדיו? האם דרישות אלו שונות מהותית מדרישות אחרות שהארגון דורש מעובדיו? ובכן לא. הנה המסר שלי: דרישות אט"מ/ה"ס מהעובדים/משתמשים הן חלק מהמשמעות של להיות מועסק ע"י הארגון, לא יותר ולא פחות. אין בהם ייחוד.
3.4.3.6.        אכיפת  יישום הנחיות/דרישות אט"מ/ה"ס ביחידות הארגוניות
1.      מדוע שיחידה ארגונית תשלב בתהליכי עבודתה דרישות אלו? מיהו בכלל ה-CISO להנחות את הארגון? מהיכן שואב ה-CISO את סמכותו להנחות את כל היחידות הארגוניות?
2.      שתי תשובות:
א.        ממסמך מדיניות אט"מ/ה"ס. על מסמך המדיניות לכלול את סמכותו של ה-CISO להנחות את הארגון.
ב.        וועדת ההיגוי ל-אט"מ/ה"ס.
3.      מומלץ שתוכנית העבודה השנתית של מבקר הפנים של הארגון, תכלול באופן קבוע ביקורת של שילוב והטמעה של הנחיות אט"מ/ה"ס במדגם של יחידות ארגוניות. 
4.      אם יחידה ארגונית כלשהי מוסמכת לתקן ניהול האיכות: ISO 9001, אזי אכיפת תהליכי אט"מ/ה"ס נעשים מובנים יותר. זאת מכיוון שאמורים לפעול תהליכים כגון: מבדק איכות פנימי, סקר הנהלה לאיכות, פעילות מתקנת ואחרים. בפעילויות מובנות אלו המושרשות בתהליכי העבודה של אותן יחידות ארגוניות ניתן בקלות רבה יותר לשלב את אכיפת ההנחיות/הדרישות של אט"מ/ה"ס.
לנושא ניהול האיכות ו-אט"מ/ה"ס נדרש טיפול מעמיק יותר מאשר התייחסות שולית כפי שנתנה לעיל.
4.    שתי דוגמאות
4.1.       הנושא: הקשחת רכיבי טכנולוגיית המידע/סייבר
4.1.1.         בסיס המידע:
4.1.1.1.        מסמכי הקשחה.
4.1.2.         מדיניות:
4.1.2.1.        במסמך מדיניות אט"מ/ה"ס מופיע משפט בסגנון:
"... מרכיבי טכנולוגיית המידע/סייבר (כגון: מערכות הפעלה, מסדי נתונים, רכיבי תקשורת ותשתיות תוכנה) המספקים שירותים לסביבת הייצור של הארגון, יוקשחו בהתאם למסמכי הקשחה שיסופקו ויאושרו ע"י ה-CISO"
4.1.3.         נהלים/הנחיות עבודה:
4.1.3.1.        עבור ה-CISO, הנוהל/הוראת העבודה תכלול את הצעדים הבאים:
1.        אתר באלו מרכיבי טכנולוגיית מידע/סייבר נעשה שימוש בארגון, וקבע תהליך ליידע את ה-CISO לפני ששינוי עומד להתרחש.
2.        הכן את מסמכי ההקשחה המתאימים.
3.        קבע תהליך עבודה עם מנהל טכנולוגיית המידע/סייבר האחראי לפעילות ההקשחה במחלקת טכנולוגיית המידע/סייבר.
4.        העבר את מסמכי ההקשחה עפ"י תהליך העבודה שסוכם.
5.        קבל משוב שמסמכי ההקשחה התקבלו ביעדם וכי נקבע לו"ז לתחילת/סיום תהליך ההקשחה.
6.        קבל הודעה שתהליך ההקשחה הסתיים.
7.        בדוק את המרכיבים שהוקשחו. האם תוצאת הבדיקה תואמת את דרישות ההקשחה? פעל בהתאם תוצאות הבדיקה.
4.1.3.2.        עבור מנהל טכנולוגיית המידע/סייבר האחראי על בצוע פעילות ההקשחה:
1.      עליו לכתוב נוהל/הוראת עבודה מקבילה הכוללת את "שרשרת הפעולות" שלו, כאשר הוא מקבל מסמך הקשחה פעם ראשונה עבור רכיב חדש, או מסמך הקשחה המעדכן מסמך הקשחה קודם.
4.2.       הנושא: דרישות לפיתוח מאובטח
4.2.1.         בסיס המידע:
4.2.1.1.        מסמך פיתוח מאובטח המאושר ע"י ה-CISO.
4.2.2.         מדיניות:
4.2.2.1.        במסמך מדיניות אט"מ/ה"ס מופיע משפט בסגנון:
"... בכל חוזה עם ספק או מכרז של מט"מ/ס ייכלל פרק בנושא אט"מ/ה"ס. יישום דרישות אט"מ/ה"ס הנו תנאי לכל התקשרות"
4.2.3.         נהלים/הנחיות עבודה:
4.2.3.1.        עבור ה-CISO, הנוהל/הוראת העבודה תכלול (בין היתר) את הצעדים הבאים:
1.      כאשר כתיבת קוד הנה חלק מתהליך הרכש/המכרז, אזי אחת מהדרישות תהיה: "שימוש בפרקטיקה של פיתוח מאובטח, מאושרת ע"י ה-CISO..."
או
"אלו הלוקחים חלק בתכנון וכתיבה של קוד עברו הכשרה פורמלית בפרקטיקה של פיתוח מאובטח שאושרה ע"י
ה-
CISO".
4.2.3.2.        עבור מנהל הרכש, האחראי על תהליך הרכש:
1.   בנוהל הרכש/הוראת העבודה לרכש שלו, נדרש לשלב את הנחיות/דרישות ה-CISO.
2.   החוזה שנחתם עם הספק יכלול את סעיפי השמירה על הסודיות ו-אט"מ/ה"ס המאושרים של הארגון. 
 

יום חמישי, 16 במאי 2013

פוסט מסכם – ניהול אבטחת מידע – מילות סיכום ומבט לעתיד

פוסט זה מסכם את סדרת הפוסטים בנושא ניהול אבטחת מידע ומתייחס גם לאופנה הנפוצה כיום של איחוד נושאי ניהול סיכונים תחת "מטריה אחת" – ניהול סיכונים ארגוני.
ראשית, מבט קצר על פרקי הסדרה
תחילת הסדרה עסקה בשאלה: את מה מנהל מנהל אבטחת המידע?
המתודולוגיה מכתיבה שאבטחת מידע הינה טיפול בשלושה מרכיבים: סודיות, שלמות ואמינות, זמינות ושרידות.
במדינת ישראל, אם בארגון מונה מנהל אבטחת מידע אזי בפועל הוא אחראי בעיקר על מרכיב הסודיות. אין לזלזל במרכיב זה, מבין השלושה, דווקא המענה לסודיות דורש את ההתייחסות הרחבה ביותר כאשר אנו עוסקים בטכנולוגיית מידע. המענה לנושא האיומים על הסודיות מתפרס על פני התחומים הבאים: ארכיטקטורת פריסת מערכות טכנולוגיית המידע, הגדרת מדיניות להפעלת מערכות טכנולוגיית המידע רכיב אחרי רכיב (רכיבי התקשורת, מערכות ההפעלה, מסדי הנתונים, יישומים) ולבסוף מגוון תהליכי העבודה שנקבעו עבור המשתמשים לסוגיהם השונים. האחריות לנושא שלמות ואמינות המידע תמצא בדרך כלל בידי מנהלי הפיתוח/מנהל מערכות המידע (מנמ"ר) עצמם, כך גם נושא הזמינות. שונה לגמרי נושא השרידות, שכן שרידות הנה פתרון לתרחיש/ים של פגיעה בזמינות. בדרך כלל האחריות לשרידות ניתנת למנהל בכיר בארגון שכן מדובר בתקציבים ומשאבים גדולים ליישום מענה.   
ניהול אבטחת מידע וחקיקה/רגולציה בישראל
מספר חוקים רגולציות עוסקות בנושא זה ומחייבות חברות וסקטורים שונים:
1.        חוק ותקנות להגנת הפרטיות,
2.         חוק להסדרת הביטחון בגופים ציבוריים,
3.        הוראת ניהול בנקאי תקין מס' 357 לתאגידים בנקאיים מטעם המפקח על הבנקים,
4.        ניהול סיכוני אבטחת מידע לגופים מוסדיים מטעם המפקח על הביטוח.
שני מרכיבים לניהול אבטחת מידע: מיצוב ארגוני ותחומי אחריות:
 
א.   מיצוב ארגוני. שלושה מהארבעה (חוק להסדרת הביטחון, והוראות המפקח על הבנקים והמפקח על הביטוח) שמים דגש ומציבים עמדה ברורה בעניין זה (מנהל אבטחת המידע הנו נושא משרה בכיר). חוק הגנת הפרטיות איננו מתייחס לסוגיה זו כלל וכלל. גם הסמנטיקה של "ממונה אבטחת מידע" בלשון חוק הגנת הפרטיות ממעיטה מחשיבות/בכירות המשרה, בבחינת מיהו ממונה? מי שמונה וזה יכול להיות כל עובד בארגון, לעומת מנהל שזו הגדרה ברורה לנושא משרה ניהולית, ומבדלת את נושא המשרה מעובד שאיננו מנהל.
ב.   תחומי אחריות. במישור CIA (סודיות, שלמות ואמינות, זמינות ושרידות) ובמישור אבטחה פיזית למול אבטחת המחשבים:
1.     חוק הגנת הפרטיות מתייחס לכל ה-CIA וכולל התייחסות לדרישות לאבטחה פיזית ומיחשובית,
2.     חוק להסדרת הביטחון נחזה להתייחס ל-C בלבד וקיימת הפרדה בין פעילות אבטחה פיזית ופעילות אבטחת מידע,
3.     הוראת המפקח על הבנקים ל-C ול-I בלבד ומחייבת אספקת מענה פיזי ומיחשובי,
4.     הוראת המפקח על הביטוח לכל ה-CIA. גם הוראה זו מתייחסת לפן הפיזי והמחשובי.
נראה שבמבחן ההתאמה למציאות, המחוקקים והרגולטורים במדינת ישראל אינם קוהרנטיים בינם לבין עצמם, דבר העלול להקשות על ארגונים הנדרשים לעמוד במספר חוקים/דרישות רגולטוריות לקבל החלטות בעניין תחומי האחריות של מנהל אבטחת המידע.
מנהל אבטחת מידע: טכנולוג או מנהל
אבטחת מידע בארגון הנו תהליך החוצה את כל היחידות הארגוניות. מדובר במגוון פעילויות הדורשות הכרת תהליכי יצירת, שינוע ואגירת מידע בכל תהליכי העבודה בכל אחת מהיחידות הארגוניות. ככזה מחייב מוטת שליטה רחבת היקף. מזה זמן כבר לא מדובר על משימה טכנולוגית בלבד. זו משימה המחייבת כישורים ניהוליים. כישורים ניהוליים נדרשים כוללים את:
1.        היכולת להבין מתוך הגדרת התפקיד כפי שהוטל, כיצד לפרק אותו לנושאים הספציפיים.
2.        לסמן בכל נושא מי אמור לבצע אותו, מתי אמור להתחיל ולהסתיים, ומה המשאבים הנדרשים על מנת לבצע אותו.
3.        להוציא לפועל את הפעילויות הנ"ל.
4.        להוביל בארגון את ניתוח האיומים, הסיכונים והמענים להם למידע ולטכנולוגיית המידע בתחום הסודיות, ובמידה מסוימת גם בנושאי שלמות, אמינות וזמינות.
5.        להגדיר פרמטרים למדידת רמת אבטחת המידע של הארגון בתחומי אחריותו.
6.        להציג בפני הנהלת הארגון מעת לעת ועפ"י בקשה את מצב אבטחת המידע עפ"י פרמטרי המדידה.
מערך הנושאים המתואר לעיל הינו במובהק בתחום הניהול. על כן, מנהל אבטחת המידע, בין שהינו בעל רקע טכנולוגי רחב או צר, חייב להיות בעל יכולות ניהול לפחות ברמה של כל מנהל אחר בארגון. באם יהיה רק בעל יכולת טכנולוגית, יבצר ממנו להפוך את תחום אבטחת המידע (ואפילו זה "רק" מרכיב הסודיות), לנושא המוטמע בתהליכי העבודה הארגוניים, כדוגמת: תהליכי רכש, שיווק, פעילויות ליבה עסקיות (בהתאם למגזר שאליו משתייך הארגון) וכד'. אבטחת מידע בארגון משמעותה הינה אחת, אבטחת מידע המוטמעת כדבר שבשגרת העבודה בתהליכי העבודה הארגוניים. כבר מזה זמן לא מדובר בתהליך טכנולוגי צר.
אבטחת מידע: הנחיה, ביצוע ובקרה – הפרדת תפקידים וסמכויות
שלושה תהליכי עבודה מרכיבים את מקצוע אבטחת המידע: הנחייה – הצבת דרישות, ביצוע ההנחיה, וביצוע בקרה כיצד ההנחיה מבוצעת בפועל.
בדרך כלל נעדיף שמנהל אבטחת המידע יעסוק בהנחיה ובבקרה יישום הנחיותיו. ביצוע ההנחיות יימסר בידי גוף תפעולי בתחום טכנולוגיית המידע אשר חייב להכשיר עצמו לביצוע המשימה. זאת למעט מספר נושאים מצומצם שגם ביצועם יישאר בידי מנהל אבטחת המידע (נושאי הניהול עצמם). רזולוציית ההנחיה הינה עניין לשיקול דעת מקצועי והתאמה ארגונית. בקרה על ביצוע ניהול אבטחת המידע עצמה תימסר לידי יחידת ביקורת הפנים בארגון אשר נדרשת לידע מקצועי בנושא זה.
מיקום ארגוני של מנהל אבטחת המידע ותפקוד אבטחת מידע
שתי אסכולות קיימות:
1.        מנהל אבטחת המידע אסור שיהיה חלק ממערך מערכות המידע בארגון.
2.        מנהל אבטחת המידע יכול להיות חלק ממערך טכנולוגיית המידע בארגון.
לטעמי השאלה שיש לספק עליה מענה הנה שונה:
בהינתן כל מה שידוע לנו עד לנקודה זו, מהם התנאים הנדרשים על מנת שמנהל אבטחת המידע יוכל לבצע את תפקידו כהלכה. התשובה מורכבת משתי אבני בניין.
הראשונה, היררכיה ארגונית סמכות ואחריות:
1.      על מנהל אבטחת המידע להיות חבר בהנהלת הארגון, או כפוף למנהל שהוא חבר הנהלת הארגון. אותו חבר הנהלה יכול להיות מנהל מערכות המידע, או כל מנהל אחר שהנו חבר הנהלה.
2.      נדרשת וועדת היגוי לאבטחת מידע. מנהל אבטחת המידע משמש מזכיר הוועדה. יו"ר הוועדה הנו מנהל בכיר מבין חברי הנהלת הארגון. וועדת ההיגוי תשקף פריסת סמכויות ואחריות הנהלת הארגון בתחום אבטחת מידע.
השנייה, ההיבטים הפורמליים של תיעוד תהליכי עבודה:
1.        מדיניות אבטחת מידע שבה נכללת מחויבות ההנהלה לאבטחת מידע ולתקצובה הנאות.
2.        תהליך מובנה, סדור, מנוהל ומבוקר של כתיבת מסמכים המתארים תהליכי עבודה (נהלים, הוראות עבודה, הוראות תפעוליות וכיו"ב) לאבטחת מידע ולשילוב אבטחת מידע בכל תהליכי העבודה הארגוניים הרלוונטיים.
אבטחת מידע ואבטחה פיזית
אבטחה פיזית מספקת מעטפת אבטחה המהווה תשתית להגנה על אנשים, נכסים ומידע. על כן קיימת חשיבות רבה לשיתוף פעולה בין שתי הפונקציות.
יחד עם זאת, אין הכרח שיהיו תחת אותה קורת גג ניהולית, אם כי, כאשר האבטחה הפיזית ואבטחת המידע מצויות תחת קורת גג ניהולית משותפת קיים פוטנציאל גבוה יותר לשילוב מנצח של הגנה על המידע ונכסי המידע.
אבטחת מידע וניהול כולל של סיכונים
בעשור הקודם החלו לנשב רוחות חדשות. תחילה רגולציה כלל עולמית בשם בזל II שחלה על מערכת הבנקאות ברחבי העולם. זו מביאה לעולם מונח חדש: "סיכונים תפעוליים". ומהו סיכון תפעולי אליבא דבאזל II?
"הסיכון שבהפסד הנובע מכישלון או אי התאמה של תהליכים פנימיים, אנשים או מערכות, או מאירועים חיצוניים". מערכות טכנולוגיית המידע מתאימות "בול" להגדרה זו.
אז מה קיבלנו? שסיכוני טכנולוגיית המידע הם בסה"כ מקרה פרטי של עולם הסיכונים התפעוליים.
התוצאה: לא עוברות אלא שנתיים שלוש מאז שמומצא המונח הזה, וכבר יש לנו תוכנות שמסייעות לתאגידים הבנקאיים הגדולים בעולם לנהל את הסיכונים התפעוליים. והיכן היא טכנולוגיית המידע/אבטחת מידע? פשוט נעלמת... מדהים, אבל בכלי התוכנה הללו טכנולוגיית המידע איך אמרנו בילדותנו "לא פונקציה"? אז זהו, לא סופרים את טכנולוגיית המידע. מדוע ולמה? כי הרי הכל תהליכים עסקיים. טכנולוגיית המידע היא רק "ספק שירותים" של התהליכים העסקיים.
עוברות עוד שנתיים שלוש ונדמה ש"קם הגולם על יוצרו" בואו נעשה את מגדל בבל של ניהול הסיכונים. נקים פונקציה שתקרא: "משרד ניהול הסיכונים הארגוני" נעשה "פריש מיש" ונקבל על סרגל אחד את כל הסיכונים של הארגון מהנמוך ביותר ועד הגבוה ביותר. הרי זה משובח. עכשיו סוףסוף תוכל הנהלת הארגון פעם ראשונה בתולדותיה לראות מהם הסיכונים שאתם הארגון צריך להתמודד ולתעדף.
ועכשיו אנה נעלם מנהל אבטחת המידע? נחזור לתחילת הדיון. הוא מנהל בעיקר את הסיכון לסודיות של המידע במערכות המידע. איזו חשיבות כבר יכולה להיות לסודיות המידע? כיצד יישום מדיניות שימוש נכון בתשתיות טכנולוגיית המידע (מה שקרוי בז'רגון המקצועי: "הקשחה") מתמודדת עם סיכון של אובדן שוק עקב תחרות? כיצד הטלאת כשלי אבטחה (מה שקרוי בז'רגון המקצועי (Security patches policy משפר את התחרותיות? הרי לכם המענה: אי אפשר לדעת. רק בעקיפין נוכל לומר שבהעדר יישום מדיניות הקשחה נכונה, או בהעדר מדיניות הטלאה של פגיעויות בתוכנות גובר הסיכוי לריגול תעשייתי. מישהו מקשיב בהנהלה? מסופקתני.
אז מה עושים? מחכים שהאופנה הזו תעבור, כפי שכל אופנה עוברת חולפת לה. בינתיים עושים ככל הניתן לשמר ולשפר את המענים לאיומים ולסיכונים למידע ולטכנולוגיית המידע שכן אלו לא מתייחסים לאופנה כזו או אחרת ומשתדלים ככל הניתן להיות מקצוענים. שם המשחק הוא מקצוענות.האויב הנו מקצוען גם מנהל אבטחת המידע וכל מי שעיסוקו ניהול סיכוני המידע וטכנולוגיית המידע חייב להתמקצע.
      
                                                                                 

יום רביעי, 13 בפברואר 2013

אבטחה פיזית ואבטחת מידע

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

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

בהיבט זה, מתקן עשוי להיות מתקן המחשב (בשמו אז, "מרכז החישובים המרכזי", או בשמו היום: "חוות שרתים ארגונית"), ציוד עשוי להיות מחשב (נייד או נייח), ונכס בעל ערך עשויה להיות מדיה מגנטית נתיקה (דיסק שליף, Disk On Key, CD ודומיהם) או דוח שהודפס על נייר. דוגמאות אלה ממחישות (כך אני מקווה) באופן ישיר ומידי את העובדה שהביטחון הפיזי קשור קשר ישיר להגנה על נכסי המידע של הארגון. אין זה הקשר היחיד. בשנים האחרונות, ומגמה זו רק הולכת וגוברת, חלק הולך וגדל מאמצעי ההגנה שבהם משתמש הביטחון הפיזי כדוגמת אמצעים לבקרת כניסה פיזית למתקן, לחדר או לאזור כלשהו, מצלמות וציוד התראה ומעקב הפכו להיות אמצעים דיגיטליים, משמע, ממוחשבים. המשמעות הינה שאותם האמצעים המשמשים כאמצעי הגנה פיזית, חשופים כעת לאותם האיומים והסיכונים שאליהם נחשפים אמצעי המחשוב הארגוניים. ניקח לדוגמה את מצלמות האבטחה. מדובר במצלמות דיגיטליות אשר מחוברות לרשת תקשורת, מעבירות למרכז בקרה מרוחק את התמונה וניתנות לשליטה מרחוק למטרת שינויי התמקדות בשטח המצולם, זום וכד'. במה שונה המצלמה מכל רכיב מחשובי אחר המחובר לרשת וקיימת אליו גישה מרחוק? אז זהו, המצלמה איננה שונה, היא פשוט עוד רכיב ברשת התקשורת. על כן גם היא חשופה לאותם המפגעים שאליהם חשופים רכיבי מחשוב דיגיטליים. בין יתר האיומים ניתן למנות את מתקפות הפצחנים (האקרים בלעז) העלולים לשבש את עבודתה. דוגמאות יהיו: הסטת המצלמה באופן זדוני, "שתילת" תמונה כוזבת במסך הבקרה, או "סתם" הפסקת פעולתה. המשמעות הינה שבחלק הולך וגדל מאמצעי האבטחה הפיזיים נדרש לממש אבטחת מידע מיחשובית.

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

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

מנהל ביטחון פיזי ומנהל אבטחת המידע

אם שני הנושאים קשורים זה בזה מה זה אומר מבחינת ניהול הנושאים הללו בארגון?

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

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

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

האם "לעבוד ביחד" מחייב ניהול שתי הדיסציפלינות תחת מנהל אחד?

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

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

(1) מי מנהל את מי? מנהל הביטחון הפיזי את מנהל אבטחת המידע או מנהל אבטחת המידע את מנהל הביטחון הפיזי?

(2) אם שתי הפונקציות אינן מנהלות זה את זה, מיהו זה המנהל אותן, והיכן מיקומו הארגוני?

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

השאלה השנייה מתורגמת למעשה לשאלה הבאה: מהו מיקומו הארגוני של מנהל האבטחה בארגון?

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

קיימות למעשה שתי אפשרויות לניהול משולב של אבטחה פיזית ואבטחת מידע:

1. מנהל האבטחה הינו חבר הנהלת הארגון. תחתיו קיימות שתי פונקציות ניהוליות (לפחות): מנהל הביטחון הפיזי ומנהל אבטחת המידע.

2. מנהל האבטחה כפוף לחבר הנהלה. גם במקרה זה מתחתיו שתי פונקציות ניהוליות (לפחות): מנהל הביטחון הפיזי ומנהל אבטחת המידע.

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

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

לסיכום ניהול האבטחה בארגון:

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