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



27
יונ
12

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

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

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

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

 

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

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

 

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

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

מודעות פרסומת
06
מרץ
12

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

21
פבר
12

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

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

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

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

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

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

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

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

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

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

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

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

19
דצמ
11

תרשים סיכונים מערכות/מנגנוני הגנה ומניעה

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

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

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

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

הערות כלליות:

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

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

  • DB FW: ניתן להגדיר הרשאות גישה עפ"י יוזר מערכת הפעלה, יוזר בסיס נתונים, כתובת IP, שם מחשב ועוד. יכול לאפשר מניעת גישה לשדות רגישים או ניטורם. מאפשר לנטר ולחסום נסיונות Brute Force.
  • DLP: יכול לחסום התקני זכרון נתיקים, למנוע או לנטר שליחה/שמירה של מידע רגיש על סמך ביטויים/תכנים או ספריות ברשת.
  • הצפנת כונן קשיח משלב ה – Boot: מונעת אפשרות לאתחל את המחשב באמצעים עוקפי מערכת הפעלה של הכונן.
  • AFW: מגן בפני התקפות בקלטים באפליקציה, בפלטים ובניצול חולשות על השרת, מניעת התקפות DoS.
  • XML FW: מגן בפניות ל – Web Services כנגד התקפות XML המובילות ל – DoS, מניעת זליגה דרך SQL Injection.
27
יונ
11

האפקטיביות של בקרות מפצות

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

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

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

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

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

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

27
מרץ
11

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

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

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

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

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

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

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

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

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

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.




יוני 2019
א ב ג ד ה ו ש
« ספט    
 1
2345678
9101112131415
16171819202122
23242526272829
30  
מודעות פרסומת