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



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 מיליון איש יהיו זמינים לכולם?

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

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

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

26
אפר
11

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

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

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

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

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

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

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

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

27
דצמ
10

המלך הוא עירום

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

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

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

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

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

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

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

15
אוק
10

אבטחת טלפונים חכמים

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

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

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

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

הבייסיקס:

  • נעילת המכשיר עם PIN (או לפחות את הסביבה במכשיר השומרת את המידע הארגוני). זה מעצבן הרבה מנהלים, אבל תשאלו אותם האם הם מוכנים לכרטיס כספומט ללא PIN.
  • מחיקת תוכן המכשיר אוטומטית (Automatic Wipe) לאחר שטועים X פעמים בהקשת ה – PIN.
  • אפשרות למחוק מרחוק (Remote Wipe) את המכשיר במקרה של דיווח על אובדן/גניבה.
  • תווך תקשורת מוצפן בין המכשיר לשרת (SSL).
  • אימות המכשיר ע"י תעודה דיגיטלית המותקנת עליו.

 למתקדמים:

  • הצפנת תוכני המכשיר. כך שגם אם מוצא/גונב המכשיר מוציא את ה – SIM מהמכשיר, ותוכן המכשיר לא יימחק, התכנים עצמם יישארו מוצפנים.
  • אפשרות סינון מה יסונכרן למכשיר: האם לאפשר צרופות, איזה סוג צרופות (למשל תמונות כן, אבל מסמכים לא), מיילים רק של זימונים לפגישות אבל לא מיילים רגילים. לדעתי, במקרים בודדים אנשים פותחים צרופות של מיילים, בעיקר מסמכים ארוכים. לרוב הם משאירים מיילים כאלה לקריאה במשרד.
  • סינון תכנים – חסימה של סנכרון מיילים המכילים תכנים מסוימים (כרטיסי אשראי, נתוני רווח והפסד, מלאי ציוד).
  • אימות מכשיר עפ"י מזהה המכשיר עצמו (IEMI).
  • מניעת גיבוי תכני המכשיר (לפחות הרלוונטיים לארגון) בענן (למשל ע"י iTunes). ברגע שהמידע בענן, אין לארגון שליטה עליו.
  • אפשרות לחסום שימוש ב – WiFi. לזה כל משתמש ממש יתנגד. אבל בארגון עם מידע קריטי, כנראה שלא תהיה ברירה.
07
ספט
10

סיכונים לא קלאסיים בפיתוח Services

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

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

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

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

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

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

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

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

12
יול
10

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

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

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

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

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

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

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

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

מניעת זליגת מסמכים – ענת קם

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

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

מערכת DLP מספקת מספר יכולות:

  1. היכולת הראשונה מאפשרת לחסום או לאפשר שימוש במדיה נתיקה (כגון DOK או צורב DVD). המערכות כיום מאוד גרנולריות וניתן להגדיר איזה משתמשים ו/או באיזה מחשבים ניתן יהיה לחבר מדיה נתיקה. יותר מזה, ישנן מערכות שמאפשרות לקרוא מהמדיה אך לא לשמור עליה קבצים.
  2. היכולת השניה מאפשרת חסימת שמירת קבצים רגישים על מדיה נתיקה (או במקרה של ארגונים אזרחיים, למנוע שליחת קבצים רגישים במייל אל מחוץ לארגון). ניתן לחסום עפ"י מיקום ברשת (ספריות רגישות), ביטויים רגישים (למשל מסמכים המכילים "סיווג: סודי ביותר"), או מאפליקציות רגישות (למשל פורטלים ארגוניים/צהליים).

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

לאלה ששוקלים DLP, הקישור הזה מומלץ.

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

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

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




ספטמבר 2020
א ב ג ד ה ו ש
 12345
6789101112
13141516171819
20212223242526
27282930