Complexity == Security?

Complexity == Security?

Print Friendly, PDF & Email

מורה אי שם בהודו: כל העולם שאתם רואים נתמך על ידי צב ענק.

התלמיד: ומה מחזיק את הצב הענק למטה?

המורה: צב ענק אחר כמובן.

התלמיד: ומה מחזיק את הצב הזה?

המורה: אל תדאג – יש צבים עד למטה!

 

 

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

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

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

אנסה לתת מספר דוגמאות:

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

עם זאת, בארגונים רבים, קיימות מספר רשתות DMZ ולפעמים גם מספר רשתות ארגוניות רבות. זאת, לעיתים משום שכפי שהיטיב להגדיר זאת ברוס שנייר (Bruce Schneier) במאמרו המעולה The feeling and reality of security (שמופיע גם כהרצאה ב-TED כאן), אנו, כבני אדם (או כמנהלי רשתות), מגיבים פעמים רבות לתחושת הביטחון במקום לביטחון עצמו. התוצאה של מציאות כזו עשויה להיות עלייה תלולה במורכבות הרשת ועקב כך גם במורכבות הטיפול והתחזוקה שלה. במובנים רבים פעולה שכזו עשויה לדרוש יותר תשומת לב לפרטים ממנהל/י הרשת ובמקרה בו ישנם מספר מנהלי רשת – גם לתיאום מורכב בהרבה ביניהם.

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

 

דוגמה נוספת: אחת הטכניקות שלעיתים מומלצות למנהלי רשת היא להציב בארגון שני ציודי Firewall של שני יצרנים שונים בתצורת Back-to-Back בכדי שאם אצל יצרן אחד תתגלה חולשה כלשהי, הסיכויים יהיו גבוהים שאצל היצרן השני החולשה הזו לא תהיה קיימת. עם זאת, תחזוקתם של שני ציודי Firewall של שני יצרנים שונים תצריך לא מעט משאבים ובנוסף, על מנת לנצל את היתרונות שבתצורה הזו יהיה צורך להחיל את אותה מדיניות בשני הציודים, היות ומדובר בשני ציודים משני יצרנים שונים, מתודולוגית עדכון הציודים משתנה והופכת מורכבת ביותר עם הזמן. שוב – אם נשאל את עצמנו (או את גוגל…) מהן החולשות המנוצלות ביותר שלנו, אחת מהבולטות ברשימה תהיה מן הסתם – עקביות. כל מי שיש לו לפחות שלושה ילדים יכול לראות את זה: בילד הראשון כל עקרונות החינוך שקיבלתם בילדותכם ומה שקראתם באינטרנט מיושם כמעט אחד לאחד, בשני פתאום יש התרופפות משמעת לפעמים ובשלישי – לפעמים מצליחים להקפיד חלק מהזמן על כלל אחד או שניים והילד הגדול עומד נדהם איך הדברים השתנו. גם במקרה הזה, פעמים רבות כאשר שואלים את מנהל הרשת הוא מסביר שבוודאי שהוא עובד בתצורת Back-to-Back אבל כאשר בודקים לעומק איתו, מגלים שיש ברשותו שני ציודי Firewall מיצרנים שונים אבל כל אחד אחראי על משימות שונות: לדוגמא, אחד אחראי על טיפול ב-IPSEC VPN ושירותים שזמינים לאינטרנט והשני אחראי להפריד בין הרשת לחלק משרתי ה-DMZ וכך למעשה במקרים מסויימים עוברים סינון של ה-Firewall הראשון ולפעמים של השני אבל ברוב המקרים לא סינון של שניהם.

 

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

 

בארגונים רבים מוצבים ציודי תקשורת יתירים ומסלולי תקשורת מקבילים. זאת בכדי לצמצם את הסיכון לנפילת תקשורת כתוצאה מנפילה של ה-Backbone Switch (למשל). כדאי להבין, שבעוד שארכיטקטורה כזו אכן תצמצם משמעותית  את הסיכון לאובדן תקשורת כתוצאה מנפילת ציודי תקשורת ואם היא מוגדרת בתצורת Active-Active היא גם עשויה לצמצם את הסיכון לנפילה בעקבות מתקפת DoS מסוגים שונים, הרי שבד בבד, היא מייצרת סיכונים חדשים: סיכונים לתקיפה או תקלה במנגנונים למניעת לולאות (Spanning Tree למשל), מספר ערוצים שצריך כעת לאבטח למניעת ציתות לרשת ועוד ובנוסף על כל אלו – לעיתים קרובות, תקלה בציוד בתצורה כזו תהיה קשה יותר לאיתור וכמו כן, ציודי ניטור מבוססי Packets יתקשו במקרים רבים לאסוף באופן אפקטיבי את המידע הנחוץ להם. חשוב להבין – אני לא מנסה לומר ששימוש בציוד תקשורת יתיר על מנת לצמצם סיכונים לנפילת תקשורת או למתקפות מבוססות גודל, הוא רעיון גרוע – להיפך. אני פשוט מנסה לשים על השולחן את כל השיקולים להחלטה כזו. אני בהחלט חושב שהיום ציודי תקשורת הם די אמינים ולכן ארגונים צריכים להבין שציוד תקשורת יתיר (Redundant) הוא לא פתרון קסם ללא Downsides ושיש לבחון את נחיצותו אל מול האתגרים והקשיים שהוא מציב.

 

הבטחתי שבסוף הפוסט אני אציג דווקא דוגמא למצב שבו משתמשים במכוון במורכבות כדי ליצור אבטחת מידע טובה יותר. אחת הדוגמאות למצב כזה, לדעתי, היא Obfuscation. כדי להבין במה מדובר טוב יותר, צריך לזכור שקוד מקור שעובר הידור (קומפילציה) לשפת מכונה אמיתית כמו בשפות C או ++C או GO הופך למשהו שקשה מאד להפוך אותו חזרה לטקסט קריא ובפרויקט גדול מדובר במשימה כמעט בלתי אפשרית. ולכן תוכנות קוד סגור רבות כתובות בשפות אלו על מנת להקשות על גנבים פוטנציאליים להשיג את קוד המקור. עם זאת, במקרים רבים, מסיבות טכנולוגיות שונות, גם תוכנות קוד סגור רבות נאלצות להכיל חלקים בשפות שאינן עוברות הידור או כאלו שעוברות הידור חלקי (כגון #C ו-JAVA) ולכן, נוצר צורך להגן באופן כלשהו על קוד המקור גם כאשר לא ניתן להדר את התוכנית. הפתרון שנמצא היה תהליך ה-Obfuscation אשר מבצע המרה של הקוד לקוד שיהיה קשה לקריאה, על ידי בין השאר:
– העברת כל הקוד לשורה אחת שמכילה את כל ה-Class-ים והמתודות השונות
– החלפת שמות המשתנים, המחלקות והפונקציות לטקסטים אקראיים
– הוספת קוד דמי שלא עושה כלום
– פירוק פונקציות לפונקציות משנה
ועוד ועוד…

 

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

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

 

2 תגובות

  1. הי. ראשית – המון תודות על תגובתך. לשאלתך מה אני ממליץ, אני מניח שאת מדברת על הנושא של חסימת תכנים לילדים ובכן… אני ממליץ – לחשוב ורצוי עם הילדים. כלומר, בתחום אבטחת המידע בדרך כלל זו לא שאלה של מאובטח או לא מאובטח אלא יותר שאלה של האם זה שווה את ה-Trade off, זה נכון עובדתית שהתקנה של פתרונות סינון רבים (במיוחד ברמת ספקית האינטרנט) מהווים סכנה ממשית וחמורה לפרטיותו של הגולש ולכן לא הייתי ממליץ לבחור בהם. עם זאת, במידה והילד עצמו מבקש סיוע בסינון תכנים אפשר לחשוב על שימוש בפתרונות כדוגמת Google Family Link אשר מאפשרים הגדרה של "רשימה לבנה" של אתרים שהגישה אליהם תתאפשר או "רשימה שחורה" של אתרים שהגישה אליהם תיחסם. זה לא שאי אפשר לעקוף את החסימה, אפשר ובקלות רבה, אבל אם הילד עצמו מעוניין בחסימה זה יהיה פתרון סביר. אגב, אצלי בבית האינטרנט לא מסונן כלל.

    admin

השאר תגובה