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

19
ספט
16

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

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

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

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

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

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

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

 

מודעות פרסומת
03
יונ
15

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

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

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

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

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

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

 

22
מרץ
15

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

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

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

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

רבות מהפרצות הגדולות ביותר של השנים האחרונות מתבססות על גניבת מידע המצוי במערכות הארגון. לפי חברת האנטי וירוס "סימנטק" העלות הממוצעת לחברה עבור רשומת מידע שנגנבה הינה בממוצע כ- $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. וכן בעל ניסיון מקצועי בפיתוח, ביצוע מבדקי חדירה אפליקטיביים, בדיקות קוד, תקיפות והגנת סייבר.

 

07
מרץ
15

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

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

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

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

 

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

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

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

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

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

 

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

 

23
אוק
13

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

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

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

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

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

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

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

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

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

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

03
יול
13

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

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

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

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

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

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

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

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

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

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

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




מאי 2018
א ב ג ד ה ו ש
« פבר    
 12345
6789101112
13141516171819
20212223242526
2728293031  
מודעות פרסומת