חדש: צור קשר

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

השתלטות מרחוק דרך מייל

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

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

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

מדובר בתוכנות המבססות את האישור על כתובת מייל. כמה מוזר שזה נשמע – כתובת מייל. התוכנות האלה מאפשרות גישה מרחוק למייל הארגוני ולשרת הקבצים! אני חוזר שנית – לשרת הקבצים (File Server)! צירפתי לינקים לשתי תוכנות כאלה. תבינו, זה עובד בפרוטוקולים POP3/IMAP/SMTP.

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

אז מה אפשר לעשות? קשה להתמודד עם הסיכון הזה.

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

תרבות או חוצפה ישראלית

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

• לכל כלל יש יוצא מהכלל
• מי שכתב את החוקים האלה לא מבין מהחיים
• אפשר לחשוב על איזה חוק עברתי

 

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

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

 

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

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

 

echo request

שלום לכולם,

שולח ping ראשון בבלוג זה.

אנא החזירו reply (תגובה) כדי שאדע שהגעתם לפה ושניתן להגיב.

תודה

CISO

על אנונימיות ואבטחת מידע בעידן Web 2.0

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

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

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

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

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

 

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

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

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

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

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

לוח זמנים ליישום תקן PCI-DSS

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

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

• עבור חברות שהן Level 1 אין כרגע לו"ז.

• עבור חברות שהן Level 2, המועד כנראה הוא סוף 2010 (לחברות שסולקות מול ויזה כדאי לוודא שזה המועד, מול מאסטרקארד זה בטוח המועד).

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

פריצת מיילים ב – 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 … {ההמשך נחתך עקב רגישות התוכן}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

דליפת מאגר נתונים – אגרון

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

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

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