יומן אבטחה

ידיעה קצרה ב-CheckPoint User Group מספרת סיפור שלם. שני האקרים חביבים (באמת חביבים), רוני בכר וניר גולדשלאגר הצליחו לעקוף את מנגנון האבטחה ב-Connectra. זה המנגנון שבודק כי תחנה המתחברת לרשת הארגון אכן מאובטחת. ה-Connectra הוא חלק ממשפחת מוצרי אבטחה המכונים End-Point Security (אבטחת התקני קצה). זהו אחד התחומים החמים כיום באבטחת מידע.. המטרה של אבטחת התקני קצה היא לשלוט ברמת האבטחה של כל רכיב ברשת הארגונית. זה יכול להיות חיבור מרחוק (מחוץ לרשת הארגון, דרך VPN או דרך האינטרנט) או סתם חיבור של תחנות מתוך הארגון. זה יכול להיות תחנות Stand Alone. המטרה המרכזית היא להרחיב את האבטחה עד לקצה גבול התשתית הטכנולוגית הארגונית.

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

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

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

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

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