Archive for the 'מניעת זליגת מידע' Category



31
מאי
13

למה צריך NAC?

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

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

למרות שפתרון (Network Access Control  (NAC נחשב פחות חזק מפתרון EAP, הוא מספק, כאמור, פתרון להתקנים שונים (כגון מדפסות, בקרי כניסה) שפתרון EAP לא תומך בהם. מוצרי NAC מתקדמים מספקים כיום הגנה בפני מספר סיכונים:

  • התחברות לא מורשית של אורח לרשת החברה
  • חיבור מחשב ארגוני (או מחשב אורח מורשה לחיבור) לרשת כאשר המחשב אינו עומד במדיניות האבטחה ומסכן את הרשת (כגון אנטי וירוס לא מותקן)
  • חיבור מחשב מורשה כאשר התקנים מסוימים פתוחים (כגון USB או WiFi)
  • שליחת התראות (ל – SIEM או במייל) כאשר מחשב שאינו מורשה מחובר לרשת

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

15
מרץ
13

למה לא BYOD

האם ארגונים מאפשרים כיום לעובדים לחבר במשרד מחשבים ניידים פרטיים שלהם לרשת? הרוב המוחלט לא. זה עדיין טאבו שארגונים לא מוכנים לשמוע עליו. לא בטוח שזה יישאר כך לעד.
האם עד לפני שלוש-ארבע שנים ארגונים אפשרו לעובדים לסנכרן טלפונים פרטיים שלהם לתיבת המייל? היום תופעת ה – Bring Your Own Device (או BYOD) נפוצה והרבה ארגונים מאפשרים זאת לעובדים במטרה לחסוך עלויות רכש. הרבה ארגונים מאפשרים לעובדים שלהם לסנכרן את המכשירים החכמים הפרטיים (טלפון או טאבלט) למייל.

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

  1. כאשר עובד עוזב את הארגון, הוא לוקח עימו את המכשיר שלו. נכון שהארגון אמור לבטל את סנכרון המיילים למכשיר. אך מה עם כל המיילים שכבר שמורים על המכשיר? ויותר מזה, מה עם מסמכים רגישים שהיו מצורפים למיילים שהעובד צפה ושמר על כרטיס הזכרון? הם נותרים שמורים על המכשיר גם לאחר ביטול הסנכרון. תחשבו שמנהל מכירות שומר את קובץ הלקוחות או קובץ ZIP עם הסכמים עם ספקים ועמלות, ועובר לארגון מתחרה.
  2. כאשר המכשיר הינו פרטי, עולות בעיות משפטיות בחדירה לפרטיות. המכשיר הפרטי מכיל תכנים פרטיים רבים לצד תכנים עסקיים. עד להיכן יכול הארגון לנהל ולבקר את תכני המכשיר? עם הזמן, אני בטוח שיהיו מקרים שעובדים שעזבו יתבעו את המעסיק הקודם על חדירה לפרטיות.
  3. כאשר המכשיר הוא פרטי, לארגון אין רצון ויכולת למחוק את המכשיר של העובד שעזב. במכשיר ארגוני, המחיקה לא מצריכה את אישור העובד שעזב.
  4. אי אפשר לדרוש מהעובד שלא להתקין תוכנות מסוכנות על מכשירו הפרטי. נכון שגם במכשיר ארגוני קשה לכפות מניעה כזו, אך ניתן להגביל בנוהל התקנת תוכנות שכאלה ובמידת הצורך אפשר ליישם נוהל מחיקת מכשיר ארגוני ללא צורך בהסכמת העובד מעבר להסכמתו הראשונית בעת הנפקת המכשיר.
  5. לבסוף, החסכון מאי רכישת טלפון חברה עבור עובד אינו כה מוחשי כפי שנדמה בהתחלה. עדיין ישנן עלויות תפעול (OPEX) רבות. העובדים פונים לתמיכה גם בתקלות שאינן קשורות למיילים והטכנאים מוצאים את עצמם מקדישים זמן רב על תקלות אלה.

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

07
דצמ
12

גלישה מאובטחת והפרדה מהאינטרנט

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

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

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

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

תיאור קצר של הארכיטקטורה של פתרון הניתוק הלוגי (הגישה השניה) ולאחר מכן שרטוט סכמתי:

רשת טרמינלים

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

חסימת תקשורת

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

מיילים

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

חוויית משתמש

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

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

 ארכיטקטורת גלישה מאובטחת

01
ספט
12

מתי לא לסמוך על דוחות אבטחה של המערכת עצמה?

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

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

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

כיצד מתמודדים עם הבעיה? כיום ישנם כלי Compliance המאפשרים סריקת המחשבים ברשת בלי להסתמך על סוכנים. כלים כאלה סורקים לרוב ע"י WMI ופרוטוקול SSH. בעזרת כלים כאלה ניתן ליצור דוח המציג את כל התחנות ללא סוכן של מערכת הטלאת Patches, סוכן AV או של DLP. סריקה שבועית של כל הרשת תאפשר להציף תחנות לא מאובטחות שיועברו לטיפול מנהל הרשת. ברשתות מתקדמות, ניתן לחבר כלים אלה למערכות SIEM, למשל ע"י Syslog, וליצור חוקי התרעה על תחנות שאינן עומדות בדרישות.

01
מאי
12

10 חוקים לניטור וחסימה במערכת DLP

אחת התופעות הידועות והמרגיזות אצל חברות אינטגרציה, בכל הקשור בהטמעת מערכות, היא שהן מתקינות מוצר עם סט בסיסי ומובנה של חוקים ועוזבות. מבחינת חברות אלה, הן סיימו את העבודה והצדיקו את הכסף. מבחינת הארגון, אין לו שימוש אמיתי בחוקים אלה. כבר ציינתי את זה כאן בעבר. זה בערך כמו התחנה המרכזית החדשה בתל אביב שעמדה במשך שנים רבות ללא שימוש (אבל היא הייתה בנויה/מותקנת).
ביקשו ממני לציין חוקי תוכן שכדאי ליישם במערכת DLP – חוקים שיתנו ערך מוסף אמיתי לארגון. אומנם לא כל מערכות DLP מגיעות עם אותן יכולות, אך אני מניח שניתן להגדיר את סט החוקים הבא במערכות המובילות היודעות לנטר תכנים (בניגוד למערכות שיודעות רק לחסום התקני זכרון).
חשוב להכיר את יכולות המערכת מעבר להגדרות חוקים בסיסיות. לרוב, ניתן להגדיר סף (Threshold) שקופץ רק כשעוברים אותו (למשל מעל 5 חזרות של תוכן מסוים באותו מייל). ניתן גם להחריג יחידות ארגוניות או משתמשים בודדים מחוקים מסוימים.
בדוגמאות הבאות ניתן להגדיר לא רק את ערוץ המייל, אלא גם ערוצים נוספים כגון FTP, Web Post, התקני זכרון ניידים ועוד. המערכות יודעות לתמוך במגוון ערוצי תקשורת.

אז הנה מספר חוקים:

  1. שליחה של מספרי כרטיסי אשראי. חשוב להפעיל, במידה וניתן, בדיקת תקינות למספרים (בדומה לתעודות זהות, גם למספרי כרטיסי אשראי יש חוקיות) כדי למנוע התראה על מספרים שאינם תקינים (שאינם בהכרח כרטיסי אשראי). חוק חשוב לתקן PCI.
  2. שליחה של מספרי תעודות זהות. גם כאן להפעיל בדיקת תקינות ולוודא שמדובר בתעודות זהות.
  3. שליחה של תנאי העסקה – שכר, משכורת.
  4. שליחה של מידע רפואי (צריך ליצור במערכת מילון של מושגים רפואיים רגישים).
  5. שליחת קבצים מספריות ברשת שסומנו כרגישות. למשל, משאבי אנוש, ספריות של אפליקציות עסקיות, הנהלה ודירקטוריון, שיווק.
  6. שליחה אל נמענים מהעיתונות כדי לאתר הדלפות.
  7. שליחה אל נמענים מחברות מתחרות. האם זה תקין שעובד בחברת סלולר אחת ישלח מייל לחברת סלולר מתחרה?
  8. שליחה של סיסמאות. נזהה את זה בין השאר ע"י הביטויים: סיסמא, סיסמה, סיסמאות, admin ועוד.
  9. שליחה של נתוני עמלות. סוכן מכירות של החברה ינסה להשיג ממקור פנים נתוני עמלות של סוכנים מתחרים.
  10. שליחה של שאילות לבסיסי נתונים. נזהה ע"י הימצאות כל הביטויים הבאים: select, from, where
12
דצמ
11

אבטחת מכשירים סלולריים/חכמים II

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

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

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

אבטחת אפליקציות ארגוניות. את תכונה זו גם נחלק לשניים. אפליקציות מבוססות Web (כגון פורטל SharePoint) ואפליקציות עסקיות כגון BI/DWH. אנחנו נראה בעתיד הלא רחוק מנהלים המעוניינים לקבל נתוני מכירות או מדדי שירות לאפליקציית ה – BI שעל המכשיר. ונראה עובדים שרוצים להשתמש במידע ארגוני מהפורטל בלי לפתוח את המחשב הנייד שלהם.

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

03
ספט
11

פרטיות ציבורית

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

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

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

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

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

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

אז מה פרטי היום ומה ציבורי? והאם לפרט אין יותר אחריות על המידע?




פברואר 2020
א ב ג ד ה ו ש
« ספט    
 1
2345678
9101112131415
16171819202122
23242526272829

הרשומות הנצפות ביותר