לפני מספר חודשים בעת ביקור בבית הורי, ישבתי עם אחותי הקטנה מול המחשב והראתי לה מספר משחקי מחשב שהייתי משחק בהם כשהייתי בערך בגילה, משחקים כדוגמת סדרת המשחקים Commander Keen, או Supaplex האגדי כשאת רב הילדות שלי העברתי מול כל אחד מ-111 השלבים שלו. הראתי לה את אותם המשחקים גם מפני שאני חושב שלמרות כל המשחקים החדשים שיש היום אותם משחקים ישנים עדיין מעולים, וגם כנראה מהרצון לתת לה פרספקטיבה על אילו דברים היו נחשבים מגניבים ומעניינים פעם - עוד בתקופה שמערכת ההפעלה הנפוצה ביותר הייתה DOS וסייר הקבצים שהיה נחשב המילה האחרונה היה "Norton Comander"… חלק מהמשחקים הורדתי מכל מיני איזורים נידחים ברשת והרצתי על גבי DOSBox, ולחלק אף מצאתי גרסאות On-Line (אני לא מדבר על משהו בסיגנון של jDosBox, אלא ממש מריצים את המשחק על השרת עצמו). 

 

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

 

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

 

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

 

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

 

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

 

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

 

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