ארכיון עבור מרץ, 2011

27
מרץ
11

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

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

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

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

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

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

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

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

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

04
מרץ
11

טיוב חוקי ANY ב – Firewall

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

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

כיצד ניתן לטייב פורטים ולצמצם את החוק? ישנן מספר דרכים:

  1. לברר עם מפתחי האפליקציות באיזה פורטים המערכת עובדת. הבעיה כאן היא שבד"כ המפתחים לא מבינים בתקשורת ולא יודעים את התשובה. סביר להניח גם שהמפתחים המקוריים כבר לא עובדים בארגון.
  2. לנתח לוגים ב – FW (בתנאי שהפעילו לוגים על אותו חוק). הבעיה כאן היא שהלוג עשוי להכיל מיליוני שורות ויהיה כמעט בלתי אפשרי לעשות זאת אפילו באקסל.
  3. לעשות שימוש ב – Firewall Analyzer. למוצר כזה צריכה להיות יכולת לנתח תעבורה בפועל על חוקים ולפרט באילו פורטים עברה תקשורת בתקופה האחרונה. כעת ניתן לשנות את הגדרת ה- ANY לאותם פורטים אשר היו בשימוש האפליקציה. צריך להזהר לא להשבית את המשתמשים בגלל שפורט מסוים לא הוגדר בחוק עקב שימוש נמוך בפונקציה מסוימת באפליקציה.
02
מרץ
11

אי הגדרת Group Policy

אני מניח שכולם מכירים את היכולות של Active Directory.
AD לא רק מהווה מאגר זהויות/משתמשים ארגוני ומספק שירותי הזדהות מאובטחים לרשת, אלא גם מאפשר להחיל הגדרות אבטחה על משתמשים בניהול מרכזי. Group Policy מכיל אוסף חוקים והגדרות אבטחה על משתמשים ב – AD. אפשר להחיל GP על כל המשתמשים (דומיין) ב – AD או על קבוצה היררכית (Organizational Unit) של משתמשים. בארגון טיפוסי תמצאו עשרות ואפילו מאות OU. מי שלא מכיר את המושגים האלה, גם לא יצליח להבין אותם מההסבר העקום שלי. ומי שמכיר, כנראה דילג על הפסקה הזו. עברית קשה שפה. אז למה בכל זאת?

מקום מאוד מעניין לבחון ב – AD הוא OU שלא מוגדר עליו GP. מה זה אומר? אם מוגדרים משתמשים ב – OU הזה, יתכן והם לא כפופים למדיניות אבטחה של הזדהות לרשת. הם לא נדרשים להחליף סיסמאות כל X ימים, הסיסמא שלהם בכלל לא עומדת במדיניות החברה ועוד.

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

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

אז קדימה, צאו ואתרו את אותם OU ללא GP.




מרץ 2011
א ב ג ד ה ו ש
 12345
6789101112
13141516171819
20212223242526
2728293031