Archive for the 'ניהול אבטחת מידע' Category

03
מאי
18

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

שלום לכולם,

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

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

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

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

 

 

מודעות פרסומת
17
פבר
16

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

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

תפקיד מנהל אבטחת מידע (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. וכן בעל ניסיון מקצועי בפיתוח, ביצוע מבדקי חדירה אפליקטיביים, בדיקות קוד, תקיפות והגנת סייבר.

 

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

 

09
ינו
15

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

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

20
דצמ
13

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

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

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

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

#

השיקול 

כפוף לסמנכ"ל IT 

כפוף לסמנכ"ל אחר 

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

למנמ"ר יכולת להשפיע (ולרכך) על המדיניות.

למנמ"ר קשה להשפיע על המדיניות 'ונאלץ' לקיימה באופן מחייב יותר.

יכולת לבקר פעילות IT

בקרה תלויה חלקית.
יכולת של המנמ"ר לרכך ממצאים. הרבה פעמים הממצאים נשארים בתוך ה – IT ללא יכולת להציף כלפי מעלה.

בקרה בלתי תלויה.
אין בעיה להצביע על ליקויים קשים ולא לעגל פינות. יכולת הצפת והצגת ליקויים להנהלה בכירה.

תקציבים

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

קשה להשיג תקציבים ביחידות חיצוניות.
לפעמים יעבירו את  מנהל אבטחת המידע במסע ייסורים להוצאה מסכנה של 30K ₪. לעומת זאת ב – IT, לא מדברים איתך על סכומים מתחת לשש ספרות.

שליטה בלוחות זמנים

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

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

יכולת לבחור פתרונות בהתאם לצרכי אבטחה

יכולות טובה.
תלוי בכח שלו ב – IT, הוא יהיה בין המחליטים, אם לא הקובע הראשי, בבחירת הפתרון.

הרבה פעמים לא סופרים את מנהל אבטחת המידע בבחירת פתרונות כאשר הוא מחוץ ל – IT. הרבה פעמים פתרונות ייבחרו על סמך שיקולים תפעוליים (נוחות ניהול) ולא אבטחתיים.

יכולת להטמיע פתרונות בהתאם לדרישות

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

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

רמת אבטחה טכנולוגית

כנראה טובה יותר.

כנראה פחות טובה.

רמת אבטחה נהלית/תהליכית

קשה לומר.

קשה לומר.

רמת ביצוע בקרה

תלוי בגורמים רבים.

טובה.

הבקרה נראית יותר כמו ביקורת חיצונית.

14
אוק
12

עבודה בשיטת 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 אלא גם להסביר לצד השני למה הכוונה ברשימה לבנה ומה לא לעשות (רשימה שחורה) ובמהלך העבודה לוודא איתם שהם מקודדים או עובדים כפי שדרשתם. אל תמתינו לשלב המסירה שלפעמים מתגלה כמאוחר מידי לתקן.

03
יול
12

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

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

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

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

 

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

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

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

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

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

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

 

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

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

 

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

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




מאי 2018
א ב ג ד ה ו ש
« פבר    
 12345
6789101112
13141516171819
20212223242526
2728293031  
מודעות פרסומת