ארכיון עבור אוגוסט, 2007

30
אוג
07

AFW ו – DB FW

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

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

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

CISO

26
אוג
07

בשביל מה סיסמא?

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

ניחוש? זה היה פעם שרת פיתוח או בדיקות ועבר כך לייצור.

עוד ניחוש? ה – Administrator ממש חסר אחריות.

CISO

25
אוג
07

ההבדל בין זיהוי ואימות

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

CISO

23
אוג
07

הגנה בשכבות

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

התפיסה הקיימת, לרוב בארגונים קטנים, כאילו Firewall (להלן FW) מספק פתרון אבטחת מידע מלא לרשת, עלולה להיות מוטעית. נבחן את הדוגמא בשרטוט 1. נאמר שמבנה הרשת מחולק לפי השרטוט ושה – FW מוגדר לאפשר תעבורה בפורטים 80, 25 בלבד לסגמנט המסומן: 1. לכאורה, הרשת מאובטחת בצורה אידיאלית. אז היכן הבעיה?

שרטוט 1: רשת ארגונית

זוכרים את השומר שסינן באופן דומה את הנכנסים לבניין (גם נותני השירות הם פורט 80)? ה – FW אומנם מאפשר תעבורת Web (פורט 80), אך אין לו מושג מה מכילה תעבורה זו. אם ניקח התקפה ידועה בשם SQL Injection, אשר מזריקה קוד SQL לשדה קלט במסך, הקוד יעבור באופן 'חוקי' לסגמנט המסומן: 2, לכיוון שרת האפליקציה (APP Srv) ומשם לבסיס הנתונים (DB). ברגע זה, הפורץ השיג את יעדו וגנב מידע מה – DB. אז מה הפתרון? הטמעת שכבות הגנה. לצורך הדוגמא, נעשה זום לכמה רכיבים מהשרטוט ונתעלם מהשאר (שרטוט 2).

שרטוט 2: שכבות הגנה

לאחר שהגענו למסקנה ש – FW לא מספיק. נוכל להוסיף שרת  Firewall לשכבת האפליקציה (AFW) שיגן על שרת ה- Web מפני סוג התקפות כאלה ואחרות. נוכל להוסיף (במקום AFW או בנוסף) שרת Firewall לשכבת בסיסי הנתונים (DB FW). רכיבים נוספים אלה (השכבות הנוספות) אמורים למנוע התקפות בשכבת האפליקציה (Layer 7).

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

CISO

 

13
אוג
07

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

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

  1. ישמש כמקור להתייחסות לפוסט אחר בנושא הגנה בשכבות.

  2. יציג את חשיבות הבטחון לאבטחת המידע.

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

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

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

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

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

CISO

12
אוג
07

אבטחת מידע במערכות ERP

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

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

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

CISO

08
אוג
07

אמצעי/רכיבי זיהוי חזקים

בפוסט קודם, דנתי על הצורך בזיהוי חזק לאתרים (וגם למערכות ארגוניות). כעת אדון בקצרה על מספר אמצעי זיהוי חזק מקטגוריית רכיב פיזי – Something you have. רכיב פיזי זה הינו רכיב שני בסכימת Two-Factor Authentication.

ניתן לחלק רכיבים מקטגוריה זו לפי המאפיינים הבאים:

  1. רכיב מבוסס PKI (תעודות דיגיטליות)
  2. מחולל סיסמאות חד-פעמי (OTP)

1. רכיב מבוסס PKI שומר בתוכו תעודה דיגיטלית לפי תקן X.509. תעודה זו הינה ייחודית לבעליה ומזהה אותו בעת תהליך האימות לאתר. התעודה נשמרת באמצעי אחסון מאובטח (Secure Store) המונע אפשרות העתקתה. אמצעי האחסון הנפוצים כוללים תעודה חכמה (Smart Card) וטוקן (פתרון נפוץ בשוק הנו eToken של חברת אלאדין הישראלית).
2. מחולל סיסמאות חד-פעמי הינו רכיב המספק סיסמא (בד"כ מחרוזת בת 6 או 8 ספרות) התקפה לפרק זמן קצר (בד"כ 60 שניות) לצורך אימות מול האתר. השם מחולל סיסמאות מעט מטעה שכן הסיסמא לא מחוללת בעת לחיצה על כפתור אלא מתחלפת (ומוצגת) לפי האלגוריתם המסוים כל 60 שניות. האלגוריתם צריך להיות מסונכרן מול השרת הארגוני בכדי שבשני הצדדים 'תחולל' סיסמא זהה. רק מי שמחזיק את הרכיב הפיזי הזה, יראה את הסיסמא הזו. שני פתרונות נפוצים בשוק הנם SecureID ו – Vasco.
פתרונות OTP נוספים ניתן לממש על טלפונים סלולריים (שרק בעליו נגיש אליו – נחשו כמה זמן ייקח לאדם שטלפון שלו נגנב/אבד לבטל אותו בחברת הסלולר). אופן המימוש משתנה; ישנם פתרונות בשוק השולחים את הסיסמא ב – SMS לטלפון בעוד שאחרים מתקינים על הטלפון תוכנת Java המחוללת סיסמאות משתנות כל 60 שניות.

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

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

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

בפוסט נפרד ארחיב בעתיד על PKI.

CISO

07
אוג
07

חוזק זיהוי

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

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

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

להלן מספר פרמטרים שיש לשקול בבחירת חוזק זיהוי:

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

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

CISO

07
אוג
07

בחירת סיסמאות אישיות

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

מדוע שימוש בסיסמא אחת אינו נבון?

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

טיפ:

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

CISO

06
אוג
07

מדיניות סיסמאות

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

  • מספר תווים מינימלי
  • חיוב לשלב ספרות, אותיות קטנות (Lower Case), אותיות גדולות (Upper Case), סימנים מיוחדים
  • שמירת היסטוריה
  • מספר ימים מינימלי להחלפת סיסמא
  • ועוד…

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

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

בהמשך אמליץ על מדיניות סיסמאות לסביבות שונות.

CISO




אוגוסט 2007
א ב ג ד ה ו ש
 1234
567891011
12131415161718
19202122232425
262728293031