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

28
מרץ
10

כמה מאובטח SSO?

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

הפתרון היה Buzz Word די חדש בשוק. פתרון Single Sign On (או SSO). כל אחד בשוק דיבר על נפלאות SSO וכמה שהפתרון ישפר את רמת אבטחת המידע בצורה דרמטית.

לפני מספר חודשים עברתי ביקורת חיצונית ע"י משרד רואי חשבון. את דעתי על הביקורות האלה כבר הבעתי. המבקר טען שאחת המערכות הינה מערכת מאוד רגישה ולכן לדעתו אסור שהיא תעבוד SSO. לשאלתי, הוא אמר שאם העובד עוזב את העמדה ולא נועל את המסך, מישהו אחר עשוי לראות נתונים מאוד רגישים ולבצע פעולות רגישות באותה מערכת.התגובה הראשונה שלי היתה חיוך. מיד היה לי פלאש-באק לאותה מערכת בנקאית שאותה ציינתי למעלה. לא קיבלתי את דעתו של המבקר. אמרתי לו שהיום, כל מחשב בארגון ננעל לאחר 15 דקות של אי-פעילות. אנחנו לא חיים בעידן של Windows 95/98 שמשתמש יכול לבטל נעילת מסך.

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

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

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

המסקנה שלי היא ש – SSO עדיין עדיפה מכמה סיבות:

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

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

מודעות פרסומת
10
מרץ
10

פריצת מיילים ב – mailinator

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

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

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

רק שהיום גיליתי במקרה כיצד 'לפרוץ' למיילים זמניים של אחרים. בעבר, כתובת זמנית כזו חיה 5-10 דקות ולאחר מכן המייל שנשלח לאותה כתובת היה נמחק. כנראה ששינו שם את המדיניות. היום המשתמש צריך למחוק את המייל באופן ידני ע"י כתיבת תוכן Captcha שמוצג לו.

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

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

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

 GOODDAY,I AM MR ANTHONY, A SENIOR STAFF WITH THE XXX BANK OF XXX.I AND THE CHIEF SECURITY OFFICER (CSO) OF OUR BANK HAVE ARRANGED WITH AN
OFFICER IN THE COMPUTER SECTION OF THIS BANK, ENGINEER XXXX TO BRING
OUT PART OF YOUR TOTAL CONTRACT SUM AMOUNTING TO TWO MILLION USD.
AS I HAVE FOUND OUT THAT YOU HAVE ALMOST MET ALL THE STATUTORY REQUIREMENTS OF THE XXX IN RESPECT OF YOUR CONTRACT PAYMENT, YOUR PROBLEM IS THAT OF INTEREST GROUPS.ALSO WE FOUND OUT THAT SOME OF THE OFFICIALS OF VARIOUS … {ההמשך נחתך עקב רגישות התוכן}

08
מרץ
10

מה לנטר בבסיסי נתונים

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

  • מספר כשלונות בהתחברות לבסיס נתונים (בעיקר בסביבת ייצור)

  • התחברות ליוזרים המגיעים עם התקנת המערכת (Default Users)

  • התחברות דרך כלי SQL (למשל sqlplus) לבסיס נתונים בייצור

  • התחברות לבסיס נתונים בשעות לא סבירות

  • התחברות מכתובות IP לא מקובלות

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

  • ביצוע עדכון טבלאות ע"י משתמש שאינו אפליקטיבי 

(אם יש לכם עוד רעיונות לניטור אירועים, אתם מוזמנים לכתוב בתגובות.) 

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

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

05
מרץ
10

אימות זהות משתמשים ולקוחות

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

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

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

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

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

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

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

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

להלן ציטוט אחד מטיוטת התקנה: "…יש לבצע את אימות זהות נושא המידע תוך שימוש בלפחות נתון אחד אשר אמור להיות ידוע אך ורק לנושא המידע." בהמשך הם אפילו ממליצים על שימוש ברכיב זיהוי פיזי (something the user has).

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




מרץ 2010
א ב ג ד ה ו ש
« ינו   אפר »
 123456
78910111213
14151617181920
21222324252627
28293031  
מודעות פרסומת