ארכיון עבור פברואר, 2012

21
פבר
12

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

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

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

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

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

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

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

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

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

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

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

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

מודעות פרסומת
05
פבר
12

חוזק סיסמא

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

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

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

כדי לבחור סיסמא שאינה קלה לניחוש אבל קל לזכור אותה, מומלץ לחבר שתי מילים קצרות (אפשר שני שמות) ולרפד את הסיסמא בתוכן קבוע. הריפוד (Padding) מאפשר להאריך את הסיסמא ולשנות אותה כך שתאפשר שינוי סיסמא כל פרק זמן הנדרש ממדיניות הסיסמאות.
למשל, לחבר שמות של ילדים/הורים/אחים: טלי, גיל (Tali, Gil) ולרפד בהתחלה עם ספרות:21. הסיסמא תהיה: 21TalGil. בהחלפת הסיסמא הבאה, הסיסמא תהיה: 22TaliGil ולאחר מכן 23TaliGil. כך, השגנו סיסמא מאוד חזקה – תשעה תווים – אך מאוד קשה לניחוש או פיצוח של כלי פריצה.

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

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




פברואר 2012
א ב ג ד ה ו ש
« ינו   מרץ »
 1234
567891011
12131415161718
19202122232425
26272829  
מודעות פרסומת