קמפיין לקוחות בשירות חיצוני

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

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

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

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

מה עושים? כנראה שאין הרבה מה לעשות. אפשר לנסות את ההצעות הבאות:

1. להגדיר חוקים במערכת DLP לזיהוי זליגת נתונים רגישים (שיוצאים בתור דוגמא למשרד הפרסום).
2. לנסות לזהות ולחסום גישה לקמפיינים כאלה ע"י מערכת Web Filtering – מאוד קשה לעלות על זה.
3. לחנך את השיווק (לא ממש יעזור).
4. לבנות עם מערכות מידע תשתית מוכנה מראש לקמפיינים – אחלה הצעה אבל בד"כ לא ממוממשת עקב חוסר משאבים.
5. להעביר החלטה בהנהלה/דירקטוריון נגד הפקרות בנתוני לקוחות – מאוד יעיל אבל קשה למימוש.

 

סיווג ותיוג מידע

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

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

לאחרונה נתקלתי בפרוטוקול שנקרא TLP שפורסם ע"י ה – CERT האמריקאי (חלק מארגון ה – DHS, ארגון בטחון הפנים שלהם). הפרוטוקול, שהינו ראשי תיבות של Traffic Light Protocol, מציע דרך הרבה יותר ידידותית למשתמש לסיווג מידע. צבע הסיווג מגדיר את רמת רגישות המסמך.

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

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

 

המקור לדלף מידע בארגונים

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

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

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

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

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

התממשות האיום, שבו גורם יוציא מידע מסווג מהארגון ללא אישור, תלויה רבות בערוצי הוצאת המידע מהארגון ובנגישות שלהם למקור האיום לדלף מידע (העובדים). כגון: שליחת מיילים חיצוניים מתוך המייל הארגוני, שליחת מסרים אוטומטיים ממערכות הארגון באמצעות מערכת הפצה (מייל, פקס ו- SMS), הצגה וקבלת מידע באתרי הארגון, הדפסת מסמכים, גישה למייל הארגוני מהאינטרנט (OWA), מכשירי מובייל המחוברים למייל הארגוני (Active Sync), ממשקים פנימיים וחיצוניים, דיסקים/DOK כוננים וכד'.

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

כיצד ניתן להוריד את רמת הסיכון לדלף מידע בארגון שלך:

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

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

טכנולוגיה
רכישת כלים חזקים לשליטה בכל פעילות הארגון. פתרונות DLP – Data Leakage Prevention system מאפשרים לנו להגביל הוצאה של נתונים בנקודות הקצה בארגון ואף לשלוט בהפעלה של יישומים – על פי רשימה שחורה (לא מורשים) או לבנה (מורשים). מערכות ה – UTM (Unified Threat Management) למשל, שנחשבות כדור הבא של חומות האש (Firewalls), כבר הטמיעו את התכונות וכוללות יכולות סינון דואר אלקטרוני, סינון תכנים ושליטה ביישומים.

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

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

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

המידע הארגוני חָשּוב לך: חְשֹוב איך להגן עליו.

על כותב המאמר:
ליאור מזור, מהנדס תוכנה. בעל תואר ראשון .B.Sc. למדעי המחשב ומתמטיקה, ניסיון של למעלה מ- 10 שנים באבטחת מידע ביישום והטמעה של מערכות אבטחת מידע בחברות מובילות וניסיון בניהול פרויקטים בארץ ובחו"ל. מוסמך מת"י כ Leading Auditor לתקן ISO 27001 , מוסמך CISSP. וכן בעל ניסיון מקצועי בפיתוח, ביצוע מבדקי חדירה אפליקטיביים, בדיקות קוד, תקיפות והגנת סייבר.

 

פגיעה במידע בשירות מיקור חוץ

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

הוצאת שירותים עסקיים מצריכה לאפשר אחת מהשתיים:

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

 

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

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

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

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

1. הסכם משפטי מחמיר הכולל נספח אבטחת מידע מפורט הכולל דרישות אבטחה רבות ונוקשות
2. ביצוע ביקורות פתע (יש לעגן בהסכם המשפטי)
3. סגירת שטח אצל הספק והקמת רשת תקשורת מבודדת במתחם הסגור
4. בדיקות מהימנות לעובדי הספק והדרכות אבטחה תקופתיות

 

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

 

סיפורי סיסמאות

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

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

האתגרים בהטמעת מערכת NAC

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

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

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

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

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

רוצים לשתף בקשיים? אתם יותר ממוזמנים לרשום בתגובות.

שיטות אימות ב – NAC

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

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

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

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

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

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

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

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

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

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

למה צריך NAC?

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

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

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

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

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

למה לא BYOD

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

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

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

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

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

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

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

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

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

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

רשת טרמינלים

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

חסימת תקשורת

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

מיילים

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

חוויית משתמש

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

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