תוכנית עבודה לשנה הבאה, מפת איומים – בקשה ממכם

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

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

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

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

אשמח לשמוע מכם.

המדריך השלם לאבטחת סייבר לעסקים קטנים ובינוניים

שלום לכולם,

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

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

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

אז הנה אני מפרגן להם בלינק הבא.

 

 

דרוש תקציב לאבטחת המידע

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

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

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

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

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

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

להלן מספר כלים עבור מנהל אבטחת מידע לקבלת תקציב עבור אבטחת המידע בארגון:
1. מענה לרגולציה: הרגולציה שאליה כפוף הארגון משפיעה רבות על אבטחת המידע. ישנן רגולציות עולמיות ומקומיות שאי עמידה בהן עלולה להעמיד את הארגון בפני קנסות ו/או פקיעת רישיון עסקי. לרוב, ההנהלה מאשרת פרויקטים הקשורים לרגולציה.
2. ניהול סיכונים: אבטחת מידע מבוססת בעיקר על מדע איכותי (בניגוד לכמותי) של סיכונים. הרי לא ניתן להעריך נזק כספי מדויק מפריצה למערכת נתונים וגניבת מידע או מפגיעה במוניטין של הארגון. עם זאת, על סמך שווי נכס איכותי או אירועי אבטחת מידע קודמים ניתן להעריך סיכונים של ליקויים שונים. על בסיס רמת הסיכון, ניתן להצדיק תקציב לאבטחת המידע .
3. החזר השקעה (ROI): למרות שאין תשואה ריאלית על השקעת ביטחון אלה יש רק ניהול סיכונים, ניתן לכמת עלות של נזק צפוי כגון:
עלות הנכס (Asset Value) X אחוז הפגיעה בנכס (Exposure Factor) = עלות בודדת (Single Loss Expectancy).
עלות בודדת (Single Loss Expectancy) X הסבירות השנתית שיקרה הנזק (Annualized Rate of Occurrence) = עלות הנזק השנתית (Annualized Loss Expectancy).
על עלויות לנזק או נזק שכבר קרה, ניתן להצדיק תקציב לאבטחת המידע .
4. תוכנית עבודה לאבטחת מידע: תוכנית אבטחת מידע צריכה להיגזר מהבנת הסביבה העסקית התואמת את האסטרטגיה העסקית של הארגון. חשוב מאוד לתכנן פרויקטים לטווח ארוך, להכניס אותם לתוכנית עבודה ולאשרה בהנהלה. אם משלבים בתוכנית העבודה את שלוש הנקודות הראשונות, הסיכוי שהמשימות השונות והתקציבים הנדרשים, יאושרו.
5. שילוב אבטחת מידע בפרויקטים: תמחור של פרויקטים באגף מערכות מידע חייבים לכלול גם אספקטים של אבטחת מידע (כגון: סקר אבטחת מידע, מערכות אבטחה, וכד'). שילוב ואישור אבטחת מידע בצמתים קריטיים ובקרה של הפרויקטים בוודאות יסייעו בקבלת תקציבים לאבטחת מידע.
6. הצגת אירועי אבטחת מידע: מנהל אבטחת מידע חייב לקחת חלק פעיל בישיבות הנהלה בחברה, ולהציג את תמונת אבטחת המידע בארגון ואירועי אבטחת מידע כחלק מאסטרטגיית סיוע לפיתוח העסקי בארגון הכוללת לו"ז ותקציב.
7. שיווק פעילות אבטחה: הצגת אבטחת מידע כ- Business Enabler Securely (מאפשר את העסקים המאובטחים) החצנת פעולות אבטחת מידע בארגון והאופן שבו רואים בארגון את מנהל אבטחת מידע קובעת את ההתייחסות שהוא יקבל בכול פורום או דרישת תקציב שהוא יעלה.

המידע שלך חָשוּב לך: חְשוֹב איך להגן עליו.

 

על כותב המאמר:

ליאור מזור, מהנדס תוכנה. בעל תואר ראשון B.sc למדעי המחשב ומתמטיקה, ניסיון של למעלה מ- 9 שנים באבטחת מידע ביישום והטמעה של מערכות אבטחת מידע וניסיון בניהול פרויקטים בארץ ובחו"ל. מוסמך מת"י כ Leading Auditor לתקן ISO 270001, מוסמך CISSP. וכן בעל ניסיון מקצועי בפיתוח, ביצוע מבדקי חדירה אפליקטיביים, בדיקות קוד, תקיפות והגנת סייבר.

 

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

 

ניהול סיכונים וכימות הנזק

נוהגים לומר שניהול נכון של אבטחת מידע מחייב ניהול סיכונים אשר מאפשר להעריך האם יישום של בקרה מסוימת מצדיק את העלות אל מול התועלת הצפויה. זה נכון לכל דיסציפלינה ולא רק לאבטחת מידע.
את עלות יישום הבקרה קל יחסית לאמוד. בד"כ ישנה עלות הקשורה ברכש חומרה, תוכנה או רשיונות, וישנה עלות כח אדם ליישום הפתרון (ועוד מרכיבים חשבונאיים כמו פחת, תחזוקה שנתית, שטחי אחסון וכדומה).
לעומת זאת, את מידת הסיכון לארגון קשה מאוד להעריך. את הערכת הסיכון ניתן בגסות לחלק לשני מרכיבים. הנזק לארגון כתוצאה מזליגת מידע, אובדן זמינות או פגיעה באמינות הנתונים (CIA), שאמור להיות מתורגם לנזק כספי זה המרכיב הראשון. המרכיב השני זו ההסתברות שאירוע כזה יתרחש. מדובר בשני רכיבים שאין בשבילם נוסחה מתמטית שתנבא אותם. במקרה הטוב, מנהל כלשהו יעריך בצורה גסה את עוצמת הנזק ובמקרה הרע זה יישאר כהערכה איכותית ולא כמותית. גם את ההסתברות לא ניתן להעריך, ובפרט כאשר ההסתברות עשויה להשתנות כל הזמן כיוון שכלי הפריצה הממוכנים הולכים ומשתכללים כל הזמן.
מה בכל זאת ניתן לעשות כדי לקחת את ההערכות הגסות האלה רמה אחת יותר גבוהה (אבל עדיין לא מספקת)? התשובה היא לא הרבה. אפשרות אחת היא לחפש פרסומים על אירועים דומים המציינים מה היה גובה הנזק לארגון. למשל, כמה עלה לחברה מסוימת גניבת X מספרי כרטיסי אשראי ומכאן לגזור הערכה מעט יותר מושכלת לארגון. דוגמא נוספת, מה היו אובדן ההכנסות לחברה אחרת מכך שאתר האינטרנט שלהם הושחת או לא היה זמין.
אפשרות נוספת היא לחפש מחשבונים. אומנם בד"כ המחשבונים מותאמים יותר לשוק האמריקאי שם, כנראה, ההוצאות המשפטיות גבוהות יותר, אבל זו נקודת התחלה טובה. נתקלתי במחשבון נחמד של חברת Synantec ומכון The Ponemon Institute בלינק הזה. שחקו עם הפרמטרים השונים ונסו להתאים את התוצאות לארגון שלכם ותדביקו אותם לסיכונים השונים שלכם כך שבפעם הבאה תציגו הערכה ראשונית של נזק לכל סיכון. מול הערכות מספריות, יהיה למנהל הכספים או למנהל ה – IT יותר קשה להתווכח על הצורך בהוצאות הקשורות באבטחת מידע.

שיוך ארגוני של מנהל אבטחת מידע

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

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

נשאלתי לא מעט פעמים מהו המיקום הנכון של ה – CISO. האם הוא צריך להיות חלק מגוף IT/מערכות מידע, או שהוא צריך לשבת ביחידה ארגונית אחרת? האם הוא צריך להתוות מדיניות ולספק הנחיות בלבד, או שהוא צריך להיות פעיל ביישום אבטחת מידע? אני חושב שאין תשובה אחת נכונה. במקום לענות מה השיוך הנכון, אפרט כאן יתרונות וחסרונות של כל גישה, בהתייחס לגודל השוק הישראלי ולסיכונים השונים.

#	השיקול	כפוף לסמנכ"ל IT	כפוף לסמנכ"ל אחר
	קביעת מדיניות אבטחת מידע	למנמ"ר יכולת להשפיע (ולרכך) על המדיניות.	למנמ"ר קשה להשפיע על המדיניות 'ונאלץ' לקיימה באופן מחייב יותר.
	יכולת לבקר פעילות IT	בקרה תלויה חלקית. יכולת של המנמ"ר לרכך ממצאים. הרבה פעמים הממצאים נשארים בתוך ה – IT ללא יכולת להציף כלפי מעלה.	בקרה בלתי תלויה. אין בעיה להצביע על ליקויים קשים ולא לעגל פינות. יכולת הצפת והצגת ליקויים להנהלה בכירה.
	תקציבים	אין ספק שהתקציבים הגדולים (לפחות בארץ) שוכבים ב – IT. זה המקום להשיג משאבים לצרכי אבטחת מידע.	קשה להשיג תקציבים ביחידות חיצוניות. לפעמים יעבירו את  מנהל אבטחת המידע במסע ייסורים להוצאה מסכנה של 30K ₪. לעומת זאת ב – IT, לא מדברים איתך על סכומים מתחת לשש ספרות.
	שליטה בלוחות זמנים	מצד אחד, מנהל אבטחת מידע שותף לקביעת הלו"ז וקשה לסבן אותו, מצד שני הרבה פעמים רואים את הלו"זים נדחים.	מצד אחד, יסבנו אותו בלו"ז רחוק (הוא לא חי את הפעילות של מערכות מידע). מצד שני, התחייבות של מערכות מידע ללו"ז, מסנדלת אותם והם לא יכולים להזיז, שכן קשה לשנות התחייבות (תוכניות במסמך רשמי) לגוף חיצוני.
	יכולת לבחור פתרונות בהתאם לצרכי אבטחה	יכולות טובה. תלוי בכח שלו ב – IT, הוא יהיה בין המחליטים, אם לא הקובע הראשי, בבחירת הפתרון.	הרבה פעמים לא סופרים את מנהל אבטחת המידע בבחירת פתרונות כאשר הוא מחוץ ל – IT. הרבה פעמים פתרונות ייבחרו על סמך שיקולים תפעוליים (נוחות ניהול) ולא אבטחתיים.
	יכולת להטמיע פתרונות בהתאם לדרישות	בדומה לסעיף בחירת הפתרון, גם כאן ההטמעה יכולה להיעשות בהתאם לצרכי מנהל אבטחת המידע, ולעיתים אף על-ידו.	בהרבה מקרים 'מדווחים' לו על ההטמעה והוא לא משפיע על איכות ההטמעה. במקרה הטוב, הוא יבצע סקר הטמעה וימתין חודשים לתיקון חלק מהליקויים.
	רמת אבטחה טכנולוגית	כנראה טובה יותר.	כנראה פחות טובה.
	רמת אבטחה נהלית/תהליכית	קשה לומר.	קשה לומר.
	רמת ביצוע בקרה	תלוי בגורמים רבים.	טובה. הבקרה נראית יותר כמו ביקורת חיצונית.

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

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

במקרים רבים, אנו מגדירים סינון תכנים, סריקות, בדיקות ועוד. הגדרות אלה מחולקות לשתי קטגוריות עיקריות: White List, Black List.

מה ההבדל בין רשימה שחורה ללבנה?
ברשימה שחורה מגדירים מה אסור. למשל, בלי כתום, ירוק וכחול. עוד דוגמא מעולם חסימת התקני זכרון: לחסום (כלומר, בלי) Disk-on-Key, CD-ROM, Floppy.
ברשימה לבנה מגדירים מה מותר. למשל, מותר (רק) לבן קרם, או מותר (רק) מדפסות רשת ומקלדת אלחוטית (ואף התקן אחר).

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

ההמלצה היא לעבוד עם רשימות לבנות ולא שחורות.

דוגמא לתכנות על בסיס רשימה לבנה: בדיקת קלטים באתרי Web. לאפשר קליטת תווים מותרים לפי סוג הקלט בלבד – למשל [0-9] עבור שדה תעודת זהות, וכמובן מותר אורך השדה רק בן 9 תווים. אם היינו עובדים כאן לפי רשימת שחורה (למשל ללא אותיות [a-z] [א-ת]) לא היינו מטפלים (חוסמים) תווים מסוכנים להתקפות SQL Injection כגון: ' -.

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

מספר דוגמאות:

• הגדירו ששדה ת.ז. לא יכול להכיל אותיות, אך לא מנעו קליטת תווים מיוחדים (סכנה…).
• חסמו העלאת קבצים דרך האתר מסוג exe, אך לא הגבילו סוגים אחרים הנחשבים מסוכנים, למרות שבמקור הגדרתי שמותר לעלות רק jpg, png, gif. התוכניתן תירץ זאת בכך שהוא חשב שהסכנה היא רק מקבצי exe (למרות שהיה מונח לו על השולחן האפיון הפתוח בעמוד שהגדיר את ה – White List.
• ביקשתי סריקה ברשת של כל המחשבים מבוססי Windows לגילוי מחשבים ללא AV. קיבלתי רשימה של תחנות עבודה בלבד ללא שרתים. 

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

לכן, המלצתי היא לא רק להגדיר דרישות כתובות ל – White List אלא גם להסביר לצד השני למה הכוונה ברשימה לבנה ומה לא לעשות (רשימה שחורה) ובמהלך העבודה לוודא איתם שהם מקודדים או עובדים כפי שדרשתם. אל תמתינו לשלב המסירה שלפעמים מתגלה כמאוחר מידי לתקן.

כיצד לבצע סקירת הרשאות?

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

פירוט הקשיים בסקירת הרשאות:

1. גזירת הרשאות מהמערכות. כדי שמנהלים יוכלו להורות על הסרת הרשאות, הם צריכים קבצים המרכזים את ההרשאות במערכת עליהם הם אחראיים. או לחלופין, גישה למסך המציג להם את ההרשאות. רגע, כיצד שולפים את ההרשאות? איזה מידע מהטבלאות מרכיב בכלל את ההרשאות?
2. מאשרי הרשאות. או במילים אחרות: פוליטיקה. המנהלים העסקיים ינסו להתנער מהחובה הזו. לא ישתפו פעולה. לא יסקרו את הרשימות בצורה מעמיקה. לא יספקו בזמן את התוצרים. יחזירו לכם שאלות קנטרניות. או בכלל יטענו שהם לא מבינים והם לא הכתובת הנכונה (וזה לאחר שאתם ממתינים חודשיים לתשובות מהם).
3. מעקב ובקרה. כיצד מנהלים את כל התהליך הזה? למי כבר העברנו את הרשימות, מי נתן תשובה מלאה ומי רק חלקית? למי צריך להפיק רשימה טובה יותר? באיזה מערכת כבר הסירו הרשאות?
4. הסרת יתר של הרשאות. המנהל משה דווקא שיתף פעולה באופן מפתיע. מתוך 400 רשומות, הוא הורה על הסרת 50 הרשאות. ביצעתם. טלפונים זועמים ממשתמשים: "למה הורידו לנו הרשאות? אנחנו צריכים לבצע תשלומים וזה היום האחרון בחודש. דחוף!" לאחר בדיקה, גיליתם שמשה הורה על הסרת 10 הרשאות (מתוך ה – 50) שלא היו צריכים להיות מוסרות. משה התלהב יותר מידי.

 

מספר המלצות לייעול התהליך:

1. תיעוד של התהליך: החל מהפעם הראשונה, תתעדו כל פעולה, כל מידע על גזירת הרשאות במערכת מסוימת. תפיקו לקחים בתוך הפרויקט ובטח לאחריו. אל תסמכו על כך שבפעם הבאה זה ילך יותר טוב. בלי תיעוד, לא יהיה שיפור. מניסיון.
2. תתחילו בקטנה. תבחרו שתי מערכות מייצגות ותבצעו רק עליהן את התהליך עד סופו. לאחר מכן, תתפרסו על שאר המערכות.
3. ישיבות סטטוס: תירתמו הנהלה בכירה לתהליך טרם תחילתו, ודווחו להם סטטוס התקדמות פעם במספר שבועות. בקשו את עזרתם מול מנהלים סוררים שאינם משתפים פעולה.
4. מידע HR: אל תצאו לדרך בלי לגזור מידע HR המפרט שיוך ארגוני לכל עובד. לכל רשימת הרשאות תצמידו (בגוף הרשימה) את השיוך הארגוני של כל עובד. המנהל סוקר הרשאות בעיקר על סמך שיוך ארגוני ולא על סמך שם או ת.ז.
5. טבלאות ניתנות לפילטור: ספקו יכולות פילטור נוחות לרשימות. זה יקל על הסוקרים ויקצר את התהליך. זה גם יאפשר לכם לטייב את המידע לפני שאתם מעבירים אותו לסקירה.
6. מערכות הרשאות: ישנן מספר מערכות בשוק המספקות יכולות ניהול קמפיין סקירת הרשאות. ההטמעה שלהם לא זולה, אבל בטווח הארוך הם מקצרים זמנים בכל סקירה, מביאים לשיתוף פעולה טוב של כולם. קחו בחשבון שפרויקט הטמעה של מערכת כזו יקח לפחות שנה. לא פרויקט של שבועיים.
7. תתעדו (כבר אמרתי).

סקירת והסרת הרשאות

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

מספר סיבות מדוע סקירת הרשאות חשובה:

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

 

כיצד מנהלים סקירת הרשאות:

1. מגדירים אחראי לכל מערכת – מישהו שמכיר את משמעות ההרשאות במערכת.
2. שולפים את ההרשאות במערכות ומעבירים אותן לאשרור האחראי.
3. האחראי מסמן למי יש הרשאות עודפות (למשל, על סמך שיוך ארגוני או תפקיד) ואת ההרשאות החורגות.
4. מסירים את ההרשאות בהתאם להנחיית האחראי.
5. מדווחים למנהל אבטחת המידע ושומרים תיעוד.

 

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

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

כיצד מנהל אבטחת מידע חדש צריך להיערך – חלק ב'?

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

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

 

מיפוי נכסים והערכת סיכונים:

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

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

 הגדרת נהלי אבטחת מידע ראשונים:

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

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

 סקר סיכונים (רוחבי):

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

בארגון הנמצא בתחילת דרכו ביישום אבטחת מידע, אני מציע להתחיל בסקר סיכונים רוחבי. תקבעו אתם את תכולתו. הסקר יכול לשלב קצת אבטחה פיזית (כניסות לאזורים שונים כולל חדר מחשב, אבטחת סביבת העבודה), קצת נהלים (מדיניות סיסמאות ברשת ובמספר מערכות עיקריות), קצת הקשחה של שרתים (למשל Active Directory), בחינה כללית של ארכיטקטורת רשת וחוקים ב – Firewall, וכדומה.

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

 התקנת מנגנוני אבטחה סטנדרטיים:

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

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

כנ"ל לגבי Firewall בכניסה לרשת והגדרת חוקים נכונה.

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

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

כיצד מנהל אבטחת מידע חדש צריך להיערך – חלק א'?

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

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

תחומי סמכות, אחריות וטיפול:

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

שיוך ארגוני וכפיפות מתאימים:

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

הגדרת מסגרת העבודה:

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

מדיניות אבטחת מידע:

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

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