לפני קצת יותר משנה, כאשר עברתי על לוגים של מערכת IPS שממוקמת ברשת ייעודית (לא מול האינטרנט או גורמי החוץ), ראיתי פעילות DHCP.
מאחר ומדובר בסביבת שרתים, שמן הסתם אמורים להיות עם כתובות IP קבועות, הרי שפעילות DHCP לא הייתה אמורה להתרחש ועל כן יכולה להעיד על גורם בלתי-מורשה שמתחבר לרשת, ולכן נכנסתי לפרטי האירועים.
אז כן, היו אלו אירועי DHCP Discovery, אולם הפרטים שלהם כללו שלושה מאפיינים מטרידים:
1. כתובות ה-MAC היו מזויפות בעליל ולא שייכות לשום יצרן תקשורת. למשל, 4d:c8:43:bb:8b:a6 או 45:3b:13:0d:89:0a שלא העלו שום שם יצרן באתר חיפוש התאמות MAC ליצרן.
2. הכתובות הנ"ל התחלפו בתוך 3 שניות…
3. שם ה-Domain היה DETECTIVE… (שכמובן לא היה קיים ברשת המדוברת)
אופס, חשבתי לעצמי, יש כאן מישהו או משהו רע…
מייד פניתי לאינטרנט, וראיתי שאני לא לבד ולא הראשון שנתקל בתופעה הזו ותוהה על פשרה.
באתר של מיקרוסופט, הן הרגיל והן של התמיכה, לא מצאתי דבר, לא על פי כתובות ה-MAC ולא על פי המילה DETECTIVE.
פניתי לעובד שאחראי על ה-VLAN בו התרחשה הפעילות והוא אמר שבתאריך ובשעה המדוברים הוא עבד על שרת מסוים, מבוסס "חלונות 2003". בדקתי את כתובות ה-MAC של השרת ולא מצאתי את הכתובות שהופיעו ב-IPS, ניסיתי למצוא תהליכים רצים לא מוכרים או משהו שעולה באתחול - ולא מצאתי שום דבר חריג.
בשל חוסר יכולת להמשיך הלאה בחקירה, תייקתי את המקרה כוודו ממוחשב והמשכתי הלאה.
אבל לאחר כחודש בערך, התופעה חזרה במדויק. שוב אותו עובד, שוב שרת 2003 אבל שרת אחר.
הפעם, אמרתי לעצמי, הולכים עד הסוף.
תחקרתי לעומק את העובד, שמוכר לי כמבין עניין ואחראי, והוא אמר לי שהוא חושב שבשני המקרים הוא הפעיל את ה-Configure Your Server Wizard של 2003.
אם כך, אמרתי לעצמי, נעלה בשרשרת המזון.
פניתי לחברת האינטגרציה שנותנת לנו שירותי תמיכה, עם כל הקישורים הרלוונטיים שמצאתי באינטרנט, אך איש משם לא הכיר את הנושא, אז ביקשתי לבצע אסקלציה של המקרה אל תמיכת הפרמייר לארגונים של מיקרוסופט בישראל, וכך היה.
אלא מה? התומך "הבכיר" שם לא ממש ידע מה לעשות, ולמרות כל ההפניות למקרים דומים באינטרנט וההכוונה ליישום הכנראה-בעייתי - הוא הכחיש בעיה ב"חלונות 2003" וטען שבוודאות יש לנו ברשת קוד זדוני או פורץ מתוחכם. הוא כנראה לא ניסה לשחזר את הסיטואציה במעבדה עם סניפר.
דרשתי לבצע אסקלציה של המקרה לרמת התמיכה שמעליו, בחו"ל, אך הוא סירב, ואפילו סירב להעביר את התשובה שלו בכתב.
הוא לא ידע עם מי הוא מסתבך. מאחר ואני ידוע כנודניק שלא נח עד שהוא מגיע לשורש העניין, פניתי ל"מיקרוסופט ישראל" ודרשתי שיעלו את המקרה לתמיכת חו"ל, כי יש כאן משהו.
לקח להם קצת זמן וקצת "צעקות" בדוא"ל, אבל בסוף הם התרצו.
ואז, סוף סוף, הארה! פול מתמיכת הפרמייר באנגליה, שיש לו, למזלי, גישה לקוד המקור של המוצרים, אישר, כבר במייל הראשון שלו, כי המילה Detective נמצאת רק פעם אחת ורק בקוד של "חלונות 2003" ובדיוק ביישום Configure Your Server Wizard…
בקיצור, הוא אישר את הממצאים שלי ושל אלו שנמצאו ברשת, ואמר שזו דרכו של ה-Wizard לאתר שרתי DHCP פעילים ברשת, להתחזות ללקוח "לא קיים" רק לצורך הבדיקה.
הסברתי לו שהשיטה הזו יכולה לגרום לכמה אנשי אבטחת מידע או מנהלי רשתות התקף לב, לראות MACים מזויפים ברצף מהיר בתוספת דומיין בשם DETECTIVE… ולכן כדאי שמיקרוסופט תפרסם מאמר KB על הנושא, בכדי שלקוחות יקבלו "צפירת ארגעה" מהיצרן עצמו. הוא הסכים איתי, ואמר שהוא ידאג לכך.
תענוג. זו תמיכה.
ניסיתי לבקש שיתנו לי קרדיט ב-KB, כמו בפעמים הקודמות, אבל כנראה שלא עברתי הפעם את הסף המתאים להצדקת קרדיט.
אז לקח להם מספר חודשים טובים, והגרסה הראשונה הייתה טכנית ומבולבלת, אבל בסוף הם התאזנו עם גרסה סבירה אם כי לא מאוד ידידותית או תואמת לבעיה, ב-KB מספר 945948, שגם מופיע כאפשרות הראשונה אם מחפשים ע"י גוגל את המילה DETECTIVE באתר התמיכה של מיקרוסופט, כך שהסיכון להתקפי לב ירד, וכל המציל נפש Security Admin אחד…
אני את שלי עשיתי.
קישור קבוע
תגובות
אני שונא ספאם. לא לקבל. גם זה בעצם, אבל זה לא כזה נורא. קצת מציק, אבל לא נורא.
לנהל, לתחזק. כחלק מהעבודה.
מערכות ה-Mail Gateway, שהתחילו רק מסינון קוד זדוני, לרוב אחראיות כיום גם על מניעת ספאם.
וזו בעצם 99% אחוז מהעבודה שמערכות אלו עושות. מניסיון מספרי בדוק.
כמות הקוד הזדוני שמטופל היא אפסית ביחס לספאם.
ואני אומר, סליחה?! במה בדיוק ספאם קשור לאבטחת מידע? למה אנחנו צריכים להתעסק עם זה?
נכון, בהמשך הספאם הגיע הפישינג, והוא אכן רלוונטי לאבטחת מידע, אבל לא ספאם.
תחשבו על זה אחרת, מהצד של העולם הפיזי: נגיד שקיימת וילה פרטית שבעל הבית מאבטח באמצעות עם מספר מאבטחים מקצועיים, ביניהם יש מאבטח שאחראי על הכניסה הראשית, ולידה יש את תיבת הדואר, והוא פותח את המעטפות ומוודא שאין מעטפת נפץ/רעל וכדומה.
אז עכשיו בעל הבית אומר לו שתפקידו מהיום כולל גם לוודא שלא ייכנסו עלוני פרסום, כי זה מציק לבעל הבית המאוד-עסוק וכי ממילא הוא בודק את הדואר. אבל אם המאבטח טועה וזורק דואר שהוא חשב שהוא עלון פרסומי אבל הוא בעצם דואר שבעל הבית היה צריך - אוי, כמה בעל הבית יכעס שהדואר הזה חסר לו.
כן, רוצים שהמאבטחים יהיו טופ-אוף-דה-שנוץ (סתם ביטוי שהמצאתי), שיהיו מוכנים לטפל בכל הסכנות הגרועות ביותר.
כן, אבל אם הם כבר שם, שיעיפו את המטרדים הקטנטנים. נו, במילא משלמים להם, אז שינקו גם את הדסקטופ.
הבעיה היא שהמפלצת הזו של הספאם הופכת להיות מטרד גם בגלל הגישה של הארגון. מדי פעם אני מקבל מה-Help Desk דרישות חד-משמעיות ובלתי-מתפשרות, המגיעות מעובדים, שהם מקבלים יותר מדי ספאם אל תיבת הדוא"ל הפנימית שלהם.
כאשר אני מתעניין כמה זה "יותר מדי", מתברר שהם מקבלים 6 (שש!) הודעות ספאם בשבוע.
כאשר אני מוכיח להם שבסה"כ השבועי נשלחו אליהם משהו כמו 6,000 הודעות דוא"ל, מהן בערך 240 עברו פנימה והשאר ספאם, זה משתיק אותם למשך חודש, ואז הם שוב חוזרים. וכל זאת כאשר המערכת מוקשחת ברגישות הספאם שלה למקסימום. אני מנסה להסביר להם שאין לי ממש מה לעשות יותר בעניין, אבל הם מתעקשים ואז אני מעביר אותם לבוס שלי, רגע לפני שאני מגיע אליהם. אישית.
לפעמים אני חושב שיש בארגונים גדולים לא מעט אנשים משועממים שכנראה אין להם יותר מדי עבודה ומחפשים להתלונן על כל שטות שנותרה לאחר שנעשה המקסימום בכדי למנוע אותה והם באמת יכולים לחיות איתה.
וכמובן, יש במקביל גם את העובדים ההופכיים. אלו שבגלל שרגישות סינון הספאם נמצאת במקסימום, מתלוננים שנחסמות להם הודעות דוא"ל לגיטימיות… והם, מן הסתם בעל הצדקה יותר גבוהה לכעוס לעומת קודמיהם.
ואני באמצע!!!
אולי אני אפגיש בין שתי קהילות עובדים אלו, שהם יחליטו, יחדיו, על רמת רגישות הסינון של הספאם…
אז כמו שאמרתי, אני שונא לנהל ספאם. זה לא ממש התפקיד שלי, זה ממש לא אבטחת מידע, ועובדים יקרים - תשלימו עם הצרות הקטנות של החיים.
תאמינו לי, יש צרות יותר גדולות (ואתם תכירו אותן אם תמשיכו להתלונן שנכנס לכם ספאם… (-: ).
.
מצד שני יש אנשים שנענו לספאם והרוויחו בגדול…
קישור קבוע
תגובה אחת
"Open Web Application Security Project" הוא ארגון של קהילת אנשי אבטחת מידע, ללא מטרות רווח, אשר מקדם את נושאים אבטחת המידע ביישומי WEB, וכעת מצאתי שיש לו צ'אפטר (מילה מגניבה באנגלית ל"סניף" שלא במובן הפיזי) ישראלי, שמסתבר שפעיל כבר מספר שנים (טוב, זה לא ממש התחום הספציפי שלי…).
- יש רשימת דיוור.
- החל מיולי 2008 יתחילו מפגשים חודשיים סדירים במשרדי Breach Security בהרצליה. כל אחד מוזמן להציע עצמו להעברת הרצאה/מצגת.
היה מפגש דומה בספטמבר 2007, ויש משם את המצגות.
- בספטמבר 2008 מתוכנן כנס שנתי. שוב, אתם מוזמנים להרצות ו/או לתת חסות.
הכנס הראשון התקיים בדצמבר 2007, ויש סיכום שלו כולל המצגות וגם תמונות, אולי תמצאו מישהו מוכר…
קדם לו כנס ראשוני, במאי 2007, שוב, קבלו את המצגות. ויש עוד כנסי משנה כאלו ואחרים והמצגות שלהם נמצאות בדף הראשי (הקישור הראשון למעלה).
אז אם זו ההתמחות שלכם אז אתם מוזמנים להשתתף ולתרום, ואם אתם מכירים חברים/קולגות שבתחום - תיידעו אותם.
קישור קבוע
תגובות
אל הדף הזה הגעתי דרך פוסט של מוטי בבלוג "סדקים".
הדף מרכז קישורים לסרטוני הוידיאו של 122 הרצאות ופאנלים שהתקיימו בכנס Defcon מספר 15, באוגוסט 2007 (כלומר, הכנס האחרון).
הדף הראשון מכיל רק חלק מהסרטונים, ובסופו יש עוד קישורים לחלקים השני , השלישי והרביעי, שבהם שאר הסרטונים.
איכות הסרטונים כמובן מזעזעת, אז תתייחסו לזה כמו Podcast ובעיקר תקשיבו, ממילא יש סיכוי שואף לאפס שיהיו שם בנות יפות.
בזמנכם החופשי.
קישור קבוע
תגובות
הפוסט הזה הוא בעיקר קישור, אבל מאוד משעשע.
כדאי לצעירים מתלהבים בתחום לקרוא.
קישור קבוע
תגובות
אני רוצה להציע מחשבה קצת אחרת על מושג הפגיעוּת (vulnerability).
פגיעות, בהקשר של אבטחת מידע, תתייחס לחולשות או סיכוי לפגיעה במידע או מערכות מידע.
פגיעות, כמושג, הרי מגיעה מחיי אנוש, חולשה של אדם המסכנת את גופו ו/או נפשו ומגבירה את הסיכון לפגיעה באותו אדם.
פגיעות היא משהו פסיבי, מעין תכונה קיימת, שרצוי לחזק/לתקן אותה בהקדם האפשרי, בכדי להקטין את האפשרות לפגיעה.
אם באג פוגע בחישובי המערכת, ביציבותה ובביצועיה - הרי שבאג לרוב יתממש באופן לא מכוון, בעת התרחשות של מקרים מסוימים, חלקם מקורם בבני אנוש וחלקם בתהליכים אוטומטיים.
פגיעות, לדעתי, היא למעשה לא יותר ממקרה פרטי של באג, אבל מקרה פרטי חשוב - פגיעות לא תהיה באג ולא תתממש, בדומה למקרים רבים בחיי אנוש, ללא כוונת זדון של בן אנוש (למעט אולי, מקרי DoS, שיכולים, בדוחק רב, להיחשב כחוסר יכולת לעמוד בעמוס גבוה של פעילות תפעולית לגיטימית).
פגיעות היא באג המונע ומתממש מתוך כוונת זדון אנושית בלבד.
הן בני אנוש והן מערכות תקשוב יכולים להתקיים זמן רב ללא נזקים אם הן חיות בסביבה שאינה עוינת או זדונית.
ללא היוזמה לניצול הפגיעות - הרי שניתן לומר כאילו שהפגיעות כלל אינה קיימת, כי לא בוצע פעולה כלשהי שחשפה או ניצלה את הפגיעות.
הרבה פעמים, באבטחת מידע, אנו נוטים להתרכז בצד הטכנולוגי של העבודה (ובשל כך גם מחפשים פתרונות טכנולוגים בלבד), ומתעלמים/מזניחים את הטיפול ביסוד האנושי המהותי הטבוע במקצוע אבטחת המידע (ובמקצועות הביטחון והאבטחה בכלל), שאיתו יותר קשה לנו להתמודד, הן אישית והן כארגון - כוונת הזדון.
קישור קבוע
תגובות
אתר נחמד, שיכול להיות יעיל גם לבדיקות חוסן מסוג Black Box וגם להכנת תכנית הקשחה, הוא myIPneighbors אשר מאפשר לכם לדעת אילו אתרים נוספים מתארחים באותו השרת (שם דומיין) או כתובת ה-IP שתזינו לטופס באתר.
(עדכון, 16/5/08 - האתר לא היה פעיל, אז חיפשתי חלופות דומות. קבלו בנוסף את http://www.find-ip-address.org/reverse_lookup/ )
השירות הזה רלוונטי כמובן רק לאתרים המתארחים על שרתים משותפים או לאיתור שמות sub-domain נוספים המתארחים תחת אותה כתובת IP.
תוצאות החיפוש מראות מצד שמאל את רשימת האתרים, ובצד ימין יש חלון המראה את תוכנו של דף השער של כל אתר שתקליקו על שמו.
אתר מסוג זה יכול לחשוף את מגוון התדמיות/פעילויות שארגון/אדם רוצים להציג לעולם, כי הרי, מן הסתם, הם לא ינהלו מספר אתרים על פני מספר ספקים/שרתים שונים, אלא יסתפקו באותו שרת, עם אותה כתובת IP ורק ישנו את שם הדומיין.
בצד המעשי, האתר יכול לחשוף דפי כניסה לניהול האתר, אתרי משנה הנמצאים בהקמה ועל כן פחות מוגנים, אתרי משנה (פעילים או עזובים) שהם פחות מוגנים ודרכם ניתן לחדור לאתר הראשי או אפילו את דפי
ה-Remote Access של הארגון (כגון אלו המבוססים SSL VPN).
לפעמים, עצם הידיעה שאתר של חברה מסוימת נמצא על אותו שרת עם אתרים של חברות/אנשים אחרים יכולה להעיד עדות ראשונית שהחברה בחרה שלא להגן על האתר שלה בעצמה באופן מלא, אלא הפקידה את הגנת האתר בידי ספק האירוח, דבר שמן הסתם לא יקרה ברמה מספקת.
מצד האספקט האישי, יש משהו מאוד משעשע, מאוד דמוקרטי, מקרי, בלהכיר מי השכנים שלך, כאשר הדברים היחידים המשותפים ביניכם הם אותו ספק אירוח, אותו שרת ואותה כתובת IP.
אני למדתי למשל, שנכון להיום, מתארחים לצידי אתרים של מאנגה בסינית או יפנית, יצרן מכונות מטאיוון, ציירת, דירוג בלוגים, חברת השקעות המשקיעה עבור משקיעים מוסלמים בהשקעות התואמות לרוח השריעה, צלם אופנה, לימוד פורטוגזית, סופר שכותב על דיג, להקת רוק צרפתית, בלוגר אמריקאי, רפובליקנים ממדינת וויומינג, עצות כיצד להתעשר ברשת, זמר, אתר אישי של דף אחד, תכנית רדיו באלסקה לתיקון בעיות מחשב בשידור חי…, וויקי של צמחים ולבסוף, חנות מצתים למעשנים.
( כשיגיע אתר פורנו אשקול ביקור נימוסין… (-; )
כמו בחיים האמיתיים, אין לך ממש אפשרות לבחור את השכנים שלך, אם כי ברשת לפחות אתה לא חייב לסבול מהם. אבל גם לא ליהנות מחברתם. דו-קיום אמיתי. כל אתר לנפשו.
קישור קבוע
תגובות
לאחרונה עסקתי בהקמה של מערכת סינון דואל מול האינטרנט, ותוך כדי לימוד התעבורה ושיפצור חוקי הסינון, למדתי משהו מעניין שמאוד עוזר למניעת זליגת מידע.
לא משהו קרדינלי, לא מתחרה בתוכנות הייעודיות לנושא - אבל משהו קטן וטוב.
תפיסה
אם יש לכם בארגון שרת דואל פנים-ארגוני של מיקרוסופט, Exchange, עם לקוח Outlook, ואני מהמר שמרבית הארגונים הבינוניים והגדולים בישראל עובדים בתצורה זו, אז הנה דרך שתגלה לכם מי מבצע קידום
(Forward) אוטומטי של דואל אל מחוץ לארגון.
בכל פעם שמתרחש אירוע שנובע מחוק שמבצע קידום (ולא חשוב על פי אילו תנאים), שרת ה-Exchange מוסיף לחלק ה-body של הדואל שורת טקסט עצמאית שכוללת את הטקסט הבא באנגלית או בעברית:
auto forwarded by a rule
מועבר אוטומטית לנמענים על פי כלל
רק אחד מהביטויים האלו מוכנס לדואל, כנראה על פי הגדרות השפה בשרת ה-Exchange.
עצם העובדה שהביטויים האלו מתווספים רק ברמת ה-Exchange מונעת מהמשתמשים לבטל את הוספתה.
אם רוצים להגדיר את הביטויים הנ"ל כביטוי שלם ואחיד (Exact Phrase) במסגרת Regular Expression הרי שהמשפטים צריכים להיראות כך:
\bauto forwarded by a rule\b
b\מועבר אוטומטית לנמענים על פי כלל\b
כך שאם אתם יכולים במערכת סינון הדואל להקים חוק שתופס כל דואל יוצא שמכיל לפחות את אחד מהביטויים האלו (חוק ANY או OR) - אתם יכולים לדעת מי הקים חוק קידום אוטומטי.
גם אם לא תמצאו זליגת מידע זדונית, אתם עדיין תתפלאו (או לא) למצוא מספר נאה של עובדים שהחליטו לפתוח תיבת ראי לתיבת הדואל הארגונית שלהם, והם מקדמים כל דואל נכנס אל התיבה האישית שלהם באינטרנט.
חשוב לדעת כי לשיטה זו יש גם חריג שמאפשר במידה מסוימת לעקוף אותה:
כאשר העובד לא מגדיר חוק Outlook רגיל, אלא מפעיל את רכיב Out of office, הוא גם יכול להפעיל ברכיב זה חוקים שונים, ביניהם חוק קידום:
להגדרת חוק ה-Forward יש גם שדה של Method (שיטה):
ולשדה זה שלוש אפשרויות (המידע בקישור אמנם מתייחס ל-Exchange 5.0, אבל המידע נכון גם לגרסה 2003):
1. Standard - מדמה ביצוע קידום ידני על ידי המשתמש, כך ששדה ה-From נשאר עם כתובת הדואל של המשתמש עצמו, והמידע של הדואל המקורי נשאר בתוך הדואל כטקסט רגיל + הודעת הקידום הנזכרת לעיל. בשיטה זו החוק שתקימו יעבוד באופן תקין.
2. Leave message intact - במצב זה Exchange מתנהג כמעין "נתב דואל" ולא מבצע שום שינוי בדואל עצמו ורק מנתב אותו ליעד הנבחר בחוק.
זו הבחירה העוקפת את חוק הזיהוי הנזכר לעיל, מאחר ואין היא מכילה את הודעת הקידום המעידה על קידום אוטומטי. ניתן לתפוס הודעה מסוג זה בתנאי ומערכת הדואל שלכם מאפשרת לכם ליצור חוק Anti spoofing, שיתפוס כל דואל שהוא בכיוון יוצא (Outbound) אך עם כתובת דואל של :From שאינה משתמשת בשם הדומיין שלכם.
כך למשל, אם המשתמש הוא למשל בארגון microsoft.com והוא מקבל כעת דואל מ-yahoo.com, הדואל ייצא מהארגון עם שדה :From של yahoo.com .
3. As an attachment - בשיטה זו המצב דומה לשיטה הראשונה לעיל, למעט זה שהדואל המקורי מוכנס להודעה חדשה כאובייקט מצורף וגם אין את תוספת הודעת הקידום המעידה על קידום הדואל. אין לי ניסיון בתפיסת שיטה זו, אולם אם מערכת הסינון שלכם יודעת לשייך את אובייקט הדואל המקורי ולסרוק אותו מתוך הנחה שהוא בתוך הודעת דואל יוצאת - אזי יש סיכוי שההודעה הכוללת תיתפס במסגרת חוק Anti Spoofing.
מניעה
בצד המניעה "מיקרוסופט" מאפשר לנו למנוע קידום אוטומטי של דואל אל האינטרנט, באופן גלובלי בלבד (יש אפשרות עקיפה מסוימת. ראו בהמשך).
השדה הנוגע למקרה שלנו, ולו נרצה לבצע Disable, הוא כנראה Allow automatic forward בלבד, כי עדיין נרצה לאפשר למשתמשים לבצע reply של טקסט, כמו במקרה של Out of office.
You cannot restrict certain automatic responses to the Internet based on administrative groups in Exchange 2000 Server or in Exchange Server 2003, Article ID: 840158
Automatic replies, automatic forwards and Out of Office to Internet recipients are disabled in Exchange 2000 Server and in Exchange Server 2003, Article ID: 266166
פירוט תיבת הדיאלוג המדוברת לגבי Exchange 2003, ולגבי 2007 (הסברים טובים יותר).
כיצד בכל אופן לאפשר למשתמשים מסוימים לבצע קידום אוטומטי, למרות שקיימת הגבלה ארגונית:
How to Override Blocked Auto-Forwarding for Select Users, Article ID: 317652
קישור קבוע
2 תגובות
אתר בנק ישראל באנגלית נפרץ ופירצפו לו את הצורה. קאקר מוסלמי. האתר לא זמין כרגע. כנראה בשלב הדבקת הפלסטרים. יופי.
אתר בנק ישראל הוא לא רק אתר תדמיתי (ואנחנו יודעים עד כמה בנק ישראל צריך לעבוד על התדמית), אלא גם מכיל נתונים פיננסיים תפעוליים (כמו שערים יציגים, ריבית פריים ונתונים היסטוריים), רבים מהם כקובצי אקסל.
בוא ונניח שלמשל מערכת אבט"מ כלשהי עושה לכם צרות בהורדת קבצים מאתר כמו בנק ישראל, לא משהו אבטחתי, סתם שיבוש הפונטים בקבצים למשל, ויש לעובדים בחברה שלכם צורך קבוע להוריד מדי פעם קבצים אלו - לא תכניסו את אתר בנק ישראל ל"רשימה הלבנה"? הרי זה בנק ישראל, אם לא נסמוך עליהם, אז על מי נסמוך?!
בתור איש אבטחת מידע, יש תמיד את הספק במי לבטוח. הרי העסק עובד כך:
אם אתה סומך על א' וא' סומך על ב' - אז למעשה אתה סומך על ב'. ואתה בכלל לא מכיר את ב'.
ואתה בכלל לא באמת סומך על א' לאור עובדות שיש לך, לא ערכת לו ביקורת אבט"מ וגם אם ערכת - אתה יודע שהיא נכונה לרגע הבדיקה ולא דקה אחרי.
הרי אם הקאקר היה פושע בעל כוונות ריגול עסקי או גניבה - הוא היה יכול להשאיר את האתר כמו שהוא ורק להוסיף לו קוד זדוני במיקום פופולרי… ומשם הדרך כבר מוכרת.
הפריצה הזו היא בדיוק מסוג האירועים שצריכים ללמד אותנו לא לסמוך על אף אחד חוץ מעל עצמנו. לא שאנחנו מחוסנים ומאובטחים ב-100%, אבל בטח שאין טעם להרחיב את מעגל הסיכונים אליהם אנו נחשפים.
לא מזמן בנק ישראל השיק מערכת סליקה בזמן אמת. איך לקוחות המערכת (מוסדות פיננסיים) והלקוחות של אלו (אנחנו) אמורים לבטוח בבנק ישראל שיצליח לאבטח באופן סביר מערכת כה מורכבת, כאשר רכיב פשוט יחסית כמו אתר אינטרנט סטטי (כלומר, בלי פעולות) הוא לא מצליח לאבטח מפני ההתקפה הנפוצה ביותר ברשת?
איך המוסדות הפיננסיים בישראל אמורים להתייחס כעת לבנק ישראל, שכולל גם יחידת פיקוח על הבנקים, שפרסמה הוראות אבטחת מידע לבנקים ולחברות הביטוח (טעות שלי, את הוראות האבט"מ לחברות הביטוח פרסם המפקח על הביטוח במשרד האוצר, שאינו קשור, כמובן, למקרה זה)? מי ישמור על השומרים? מי יסמוך על השומרים?
קישור קבוע
4 תגובות
אם יש נושא שלאבטחת מידע יש בו חסר מתמיד הוא, באופן טבעי, תיעוד היסטורי מסודר או אפילו מולטימדיה שאינה חינוכית (אפשר עם מירכאות כפולות). רוב מה שיש הוא או כתבות טלוויזיה וראיונות או סרטים בידוריים לקהל הרחב.
אשתדל להביא בעתיד דברים שמצאתי בעבר, אבל מה שמצאתי כרגע זה ריכוז של סרטים על Phreaking, פריצות למערכות טלפוניה, דור המייסדים של הקראקרים. קווין מיטניק התחיל (ודי נעצר. תרתי משמע…) שם.
כדאי לכם לשמור אצלכם עותק, כי מי יודע כמה זה יישאר זמין ברשת.
קישור קבוע
תגובות
« לפוסטים הקודמים
