Archive for the 'מדיניות ונהלים' Category

03
מאי
18

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

שלום לכולם,

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

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

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

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

 

 

מודעות פרסומת
03
יונ
15

סיווג ותיוג מידע

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

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

לאחרונה נתקלתי בפרוטוקול שנקרא TLP שפורסם ע"י ה – CERT האמריקאי (חלק מארגון ה – DHS, ארגון בטחון הפנים שלהם). הפרוטוקול, שהינו ראשי תיבות של Traffic Light Protocol, מציע דרך הרבה יותר ידידותית למשתמש לסיווג מידע. צבע הסיווג מגדיר את רמת רגישות המסמך.

  • סיווג (רמזור) אדום: רגיש מאוד – תפוצה פנימית הקשורה לנושא הנדון בלבד (לא לכל העובדים בחברה)
  • סיווג (רמזור) כתום: רגיש – תפוצת חברה
  • סיווג ירוק: ניתן להפצה בין שותפים חיצוניים הקשורים לנושא (אבל לא בלמ"ס)
  • סיווג לבן: בלמ"ס

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

 

15
מרץ
13

למה לא BYOD

האם ארגונים מאפשרים כיום לעובדים לחבר במשרד מחשבים ניידים פרטיים שלהם לרשת? הרוב המוחלט לא. זה עדיין טאבו שארגונים לא מוכנים לשמוע עליו. לא בטוח שזה יישאר כך לעד.
האם עד לפני שלוש-ארבע שנים ארגונים אפשרו לעובדים לסנכרן טלפונים פרטיים שלהם לתיבת המייל? היום תופעת ה – Bring Your Own Device (או BYOD) נפוצה והרבה ארגונים מאפשרים זאת לעובדים במטרה לחסוך עלויות רכש. הרבה ארגונים מאפשרים לעובדים שלהם לסנכרן את המכשירים החכמים הפרטיים (טלפון או טאבלט) למייל.

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

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

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

01
פבר
13

Endpoint Compliance

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

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

רוב פתרונות האבטחה לתחנות קצה (Endpoint Security) מתבססות על סוכן (Agent, Client) המותקן על מחשב המשתמש. מערכות כגון Anti-Virus, חסימת התקני זכרון ואחרות, מפיצות את הגדרות האבטחה (ה – Policy) לסוכן בתחנה. לסוכנים אלה יש מספר חולשות ידועות. משתמש עלול להפסיק את ריצתן – למשל כדי לשפר ביצועי התחנה או כדי לעקוף הגדרות אבטחה המונעות ממנו לבצע פעולות מסוימות. סוכנים אלה מופצים לרוב ע"י כלי הפצה ארגוניים. במקרים לא מעטים, הפצת הסוכנים לתחנות נכשלת והתחנות אינן מוגנות. במקרים אחרים, הסוכן הופץ לתחנה אך מסיבה כלשהי, אינו מתקשר מול המערכת. לבסוף, גם כאשר הסוכן פעיל על התחנה, קורים מקרים בהם הגדרות האבטחה המופצות מהמערכת, אינן נקלטות בסוכן והוא נשאר לא מעודכן (למשל, חתימות אנטי-וירוס).

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

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

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

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

06
מרץ
12

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

21
פבר
12

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

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

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

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

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

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

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

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

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

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

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

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

27
מרץ
11

דילמות בשימוש בכח ומאזן האימה של אבטחת מידע

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

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

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

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

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

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

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

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




דצמבר 2018
א ב ג ד ה ו ש
« ספט    
 1
2345678
9101112131415
16171819202122
23242526272829
3031  
מודעות פרסומת