כשמדובר בבעיות בטיחות במוצרים חדשים ומורכבים, התגובה של החברה היא בדרך כלל עקבית: ראשית, האשימו את המשתמש. רק מאוחר יותר עליך לחייב את היצרן באחריות לפגמי עיצוב מובנים במוצרים שלהם. ראינו את זה עם מכוניות ואחר כך עם מחשבים. אבל בדיוק כשהמכונית השתנתה, גם הגישות בתעשיית ה-IT מתפתחות.
המכוניות הראשונות יצאו למכירה בארה"ב בסוף שנות ה-1890. אחרי זה הגיעו שלל חוקי בטיחות במדינה. קונטיקט הציגה את הגבלת המהירות הראשונה בשנת 1901. ואז הגיעו הרמזורים הראשונים. ניו יורק העבירה את חוק הנהיגה בשכרות הראשון בשנת 1910. בסופו של דבר (אך לאט), החלו מדינות לתת רישיונות לנהגים ואף לבחון אותם מדי פעם.
להעניש את המשתמש, לחסוך מהספק
האמצעים האלה לשלוט בהתנהגות הנהג היו כולם חשובים, אבל אף אחד לא הטיל על ספקי הרכב אחריות על עיצוב הבטיחות במוצרים שלהם, מלכתחילה. רק ב-1965, כאשר ראלף נאדר פרסם את ספר החשיפה שלו על בטיחות כלי רכב, לא בטוח בכל מהירות, החלו הצרכנים לחשוב על דרישה למכוניות בטוחות יותר. שנה לאחר מכן, הקונגרס העביר את חוק הבטיחות הלאומי לתנועה ולרכב מנועי, יצר את משרד התחבורה ובסופו של דבר אילץ את ספקי הרכב לשים חגורות בטיחות בכלי רכב.
הקונגרס העביר את חוק חגורות הבטיחות הזה 60 שנה לאחר שהפורד דגם T הראשון ירד מפס הייצור. זה אולי לא מפתיע, אם כן, ש-42 שנים אחרי ש-IBM השיקה את המחשב האישי, יש כאלה כמעט בלי חוקים להטיל אחריות דומה על ספקי מוצרי טכנולוגיה לבטיחות המוצרים שלהם.
החוקים האמיתיים היחידים המסדירים את בטיחות המחשב כיום נמצאים שם כדי לשלוט על המשתמשים. חוק הונאה והתעללות במחשבים (CFAA), שנועד לעצור פריצות לאבטחת סייבר, התקבל לפני כמעט 40 שנה ומאז לא עודכן באופן משמעותי. חוק זכויות היוצרים של המילניום הדיגיטלי (DMCA) מתמקד במניעת מאנשים לעקוף בקרות זכויות יוצרים דיגיטליות.
להתעורר לאבטחה לפי עיצוב
כעת, יש מאמץ ייעודי לגרום ליצרנים לעשות את הדבר הנכון ולבנות אבטחה במוצרים שלהם בשלב התכנון ולא כתוסף לאחר השוק. באפריל 2023, הסוכנות לאבטחת סייבר ותשתיות (CISA) פרסמה את ההנחיות שלה לגבי עיצוב מוצר מאובטח: שינוי האיזון של סיכוני אבטחת סייבר: עקרונות וגישות לאבטחה לפי עיצוב וברירת מחדל.
אבטחה לפי תכנון בונה את האבטחה משלב התכנון ואילך ולא כתוסף שלאחר-מחשבה או לאחר שוק. אבטחה כברירת מחדל מבטיחה שהאבטחה מופעלת כדי להגן על המשתמשים מחוץ לקופסה ללא חיובים נוספים.
עקרונות הייעוץ המשותף כוללים כמה דברים לא ברורים לכאורה. למשל, הוא מזהיר שנטל האבטחה לא צריך ליפול רק על הלקוח. ספקי תוכנה צריכים "לקחת בעלות על תוצאות האבטחה של רכישת הלקוח שלהם." זה היה גם יעד אסטרטגי במרץ 2023 של הבית הלבן אסטרטגיית אבטחת סייבר לאומית.
אחר הוא "שקיפות רדיקלית", שבה ספקי תוכנה צריכים להתגאות ביצירת מוצרים מאובטחים, להדגים כיצד הם עושים זאת.
כל זה נשען על העיקרון השלישי: בניית מבנה מנהיגות התומך במטרות אלו. מנהלים בכירים חייבים להיות מוכנים לאסוף משוב מלקוחות על אבטחת המוצר ולאחר מכן להקדיש משאבים פנימיים לטיפול בבעיות אלו. מבנה ארגוני זה עשוי להיות הקדשת אדם ספציפי שאחראי לאבטחת תוכנה, מוסיף המסמך.
הבעיה עם אחריות הספק
אבטחה לפי תכנון נשמעת כמו הצעה פשוטה, אבל התומכים מתמודדים עם כמה אתגרים קשים, שרבים מהם הם כספיים.
ראשית, קבלת אחריות על אבטחת תוכנה מהווה סיכון לא מבוטל עבור ספקי תוכנה, שלקוחותיהם מסתכנים בהפסדים עצומים הודות לפגמים בתוכנה שלהם מדי יום. רק במקרים קיצוניים מאוד סובלים הספקים הללו כלכלית. למשל, המבטחים של SolarWinds נפרע 26 מיליון דולר ללקוחות בהסדר לאחר שהתוכנה שנפגעה השפיעה על כ-18,000 ארגונים ב-2020.
עבור כל ספק טכנולוגיה ששואף לאבטח את המוצרים שלהם מהיסוד, יהיו הרבה שלא. הבית הלבן התחייב לעבוד עם הקונגרס כדי לפתח חקיקה הקובעת אחריות של ספקים לאבטחת מוצרים טכנולוגיים, אבל כשאנחנו נכנסים לשנת בחירות והקונגרס בקושי יכול להסכים על מספיק כדי להמשיך את הממשלה, הסיכוי לכך נראה קלוש.
לעת עתה, ייתכן שאחריות הלקוח לאלץ אותם להשתנות. CISA ממליצה לחברות להצביע עם הארנקים שלהן, ולהעריך את מאמצי הספקים שלהן לאבטח מוצרים בעיצוב ובברירת מחדל. הבית הלבן מסייע. ביולי, הוא הכריז על אישור האמון של ארה"ב, מערכת דירוג אבטחת סייבר שנועדה לעזור לצרכנים להעריך מכשירים מחוברים.
ישנם אתגרים אחרים לאחריות הספק. בעוד שחלק מהצעדי אבטחה עשויים להיות אשמתו של הספק, יהיו רבים שבהם הספק יכול להאשים את הלקוח בשימוש לרעה או הגדרה שגויה של התוכנה.
כלי אחד שיעזור למנוע שימוש לרעה כזה של לקוחות הוא פרופיל הרשאות התוכנה. טקטיקת אבטחה מובנית זו, המודגשת על ידי CISA בהנחיה שלה, ממליצה כיצד משתמשים מסוגים מסוימים צריכים להשתמש בתוכנה, כולל פירוט הרשאות גישה עבור אותם תפקידים משתנים. זה מונע ממפקח חדר הדואר לגשת לאותן פונקציות במערכת תכנון המשאבים הארגוניים כמו ראש המכירות, למשל. ספקי תוכנה מושכלים יכולים להתריע בפני משתמשים אם הם מנסים לסטות מהפרופיל.
עלות ומורכבות
אבטחה משובצת היא מורכבת ויקרה. כפי שמציין הייעוץ המשותף: "פיתוח מאובטח לפי עיצוב דורש השקעה של משאבים משמעותיים על ידי יצרני תוכנה בכל שכבה של תהליך עיצוב ופיתוח המוצר, שלא ניתן 'להתחיל' מאוחר יותר".
זה בעייתי במיוחד כאשר עוסקים במוצרי תוכנה וחומרה מדור קודם. ספקי תוכנה רבים עובדים עם קוד מונוליטי שפותח לאורך שנים, שביר וקשה לעדכון. זה קשה יותר לעדכן מתוכנה מודולרית, עם הרבה רכיבים עצמאיים ומקושרים באופן רופף.
חברות יכולות לשלם את החוב הטכני הזה בהדרגה על פני מספר איטרציות של מוצרים, אבל נדרשים משאבים משמעותיים כדי לקלף את התוכנה הזו בחזרה ליסודות ולבנות מחדש את האבטחה מהיסוד.
עיצוב מאובטח: משימה חסרת תודה
זה מביא אותנו לבעיה הבאה: הנראות, או היעדר שלה.
הפק תכונה חדשה נוצצת וגלויה מאוד כמו AI יצירתי, ותפתה לקוחות לקנות את הגרסה הבאה של המוצר שלך או לשמור על המנוי שלהם. לעומת זאת, התאמה קוד מתחת למכסה המנוע כדי להיות בטוח יותר ומאורגן היטב ראוי לשבח אך חסר תודה; זה לא נקודת מכירה רבה עבור לקוחות רבים. אתר אינטרנט שאומר "עכשיו מאובטח מבפנים החוצה" סביר להניח שיגיד את התשובה: "מה, אתה מתכוון שזה לא היה כל כך מאובטח מלכתחילה?"
אבטחה תמיד הייתה קצת כמו ביטוח רכוש או חיים: אתה חייב לעשות את זה, אבל זה קשה למכור. הפיכת מוצרים משלך שאינם ביטחוניים לאבטחים יותר אינה מניבה הכנסות ישירות. עם זאת, מכירת מוצרי אבטחה לאחר השוק כמו תוכנות נגד תוכנות זדוניות וחומות אש היא משתלמת.
טקטיקות לאבטחה לפי עיצוב
עם כל זה, האתגרים לא צריכים להרתיע אותנו מלעסוק באבטחה בתכנון. ארגונים יכולים לאמץ כמה טקטיקות שיעזרו לעודד אבטחת תוכנה מההתחלה. אחד מהם, המודגש בהנחיית CISA, הוא השימוש בשפות בטוחות בזיכרון.
כמה שפות תכנות מסורתיות ברמה נמוכה, בעיקר C ו-C++, מאפשרות למתכנתים לתפעל אזורי זיכרון שהם לא צריכים לעשות. הם יכולים לקרוא זיכרון שעשוי להכיל מידע רגיש או קוד לא הולם. הם יכולים גם לשנות את אופן הפעלתן של תוכניות אחרות או להכניס אותן למצב מבולבל, ולהפוך אותן לפגיעות להתקפה.
ספקי מערכות הפעלה הציגו אמצעי הגנה על זיכרון, אך ב-CISA אומרים כי אלה אינם מתאימים בפני עצמם. במקום זאת, הוא ממליץ להשתמש בשפות תכנות עם אמצעי הגנה מובנים בזיכרון, כמו C#, Go או Rust.
התמודדות עם בעיה זו מההתחלה עשויה להניב שיפורי אבטחה משמעותיים. בשנת 2019, מהנדסי מיקרוסופט אמר שבערך שבע מתוך עשר מכל הפגיעויות במוצרי Microsoft נבעו מבעיות בטיחות זיכרון.
מי מוביל בתכנון אבטחה
למספר קבוצות ממשלתיות ותעשייה כבר יש עקרונות ומסגרות עיצוב מאובטחות המתמקדות ברמות שונות של ערימת הטכנולוגיה. בצד התוכנה, אלה כוללים מסגרת פיתוח תוכנה מאובטחת של NIST ויוזמה ענפה לפיתוח תוכנה מאובטחת בשם SafeCode. יש גם כמה מאמצים לבנות אבטחה בתחומים ספציפיים, כגון עיצוב יישומי אינטרנט, באמצעות עקרונות העיצוב המאובטח של OWASP.
בצד החומרה, חברות עבדו יחד במשך שנים על מערכות Trusted Platform Module (TPM) המאחסנות סודות פיזית בסיליקון חסין חבלה על לוח האם. בשלב זה, אינך יכול להתקין את Windows 11 ללא גרסה 2.0 TPM.
מירוץ לתחתית (של הערימה)
ההתעקשות של מיקרוסופט על חומרת TPM היא דוגמה לאופן שבו חלק מהספקים עושים כמיטב יכולתם להתמודד עם אבטחה על ידי עיצוב, משתפים פעולה זה עם זה כדי ליצור שרשראות אבטחה שמתחילות בסיליקון ומתרחבות לתוך מערכת ההפעלה.
דוגמה אחת היא Secure Boot, תכונת אבטחה המאחסנת קודים שאושרו על ידי היצרן המוכיחים שרכיבים שונים במערכת, כמו הקושחה ומערכת ההפעלה, הם לגיטימיים. זה מסתמך על TPM, יחד עם Unified Extensible Firmware Interface (UEFI), הגרסה המודרנית של קושחת המחשב - הדבר שרץ ומאתחל את שאר המחשב כשהוא נדלק.
על ידי אימות והגנה על קוד ברמות מערכת נמוכות יותר, ספקי מערכות ההפעלה ויצרני הציוד המקורי שואפים להבטיח שליטה מלאה על כל מה שמסתמך על הקוד הזה. עם זאת, הגנות אלו כפופות לפגמי האבטחה שלהן, בדיוק כמו כל דבר אחר. במקרה של Secure Boot, קוד פגיעות בשם Baton Drop אפשר לתוקפים להציג UEFI rootkit בשם BlackLotus שעקף את ההגנות הללו, ואיפשר לתוקפים להחזיק במערכת עבור התוקפים שלה.
התקפות כאלה לא אומרות שאנחנו לא צריכים לרדוף אחרי אבטחה בתכנון ובברירת מחדל. הכנסת יותר אבטחה למערכת מההתחלה דוחפת את המחט לטובת המגנים ומקשה על התקפות. אבל התקפות כמו BlackLotus מראות שאפשר לעקוף אפילו אבטחה שהוטלה בשלב התכנון. התשובה היא לעצב שכבות והיבטים מרובים של הגנה לתוך מערכות, לצמצם למינימום את משטח ההתקפה ולספק מספר מכשולים לתוקפים להתגבר עליהם.
תקנון
ממשלות מתחילות להתייחס ברצינות לאבטחה מעצם תכנון, עם כמה צעדי חקיקה כאן או בתהליך. בארה"ב, קליפורניה ואורגון העבירו חוקי אבטחת IoT. אלה דורשים מהתקנים מחוברים בודדים להיות בעלי סיסמאות ייחודיות מתוכנתות מראש או לאלץ משתמשים ליצור אמצעי אימות חדש לפני שהם יכולים לגשת למכשיר בפעם הראשונה.
בבריטניה, חוק אבטחת המוצר והטלקומוניקציה יחייב דרישות אבטחה בסיסיות עבור מוצרים מחוברים מחוץ לקופסה. אלה כוללים סיסמאות ייחודיות, מידע על דיווח על בעיות אבטחה במוצר ותקופת תמיכה מינימלית עבור עדכוני אבטחה.
זוהי התחלה, אך עדיין מפספס כמה הזדמנויות לאכוף אבטחה חזקה על ידי עיצוב על פני מוצרים חיוניים. לדוגמה, מחשבים שולחניים ומחשבים ניידים וטאבלטים אינם נכללים בחוק הבריטי, כמו גם מכשירים רפואיים, מונים חכמים וסמארטפונים. לפחות הקומקומים המחוברים ומצלמות האבטחה באינטרנט מכוסים.
הבעיה עם חוקים כאלה היא למצוא את האיזון בין יעילות למורכבות. קשה לשיטור ולעדכן חוקים המנהלים מיקרו את יישום עקרונות האבטחה. אף על פי כן, מחייב את הבקשה והתיעוד של א מחזור חיים מאובטח של פיתוח תוכנה יעזור לאבטח מוצרים רבים.
האיחוד האירופי גם מקווה לטפל בבעיית האבטחה המובנית ברמת הגוש. בספטמבר 2022 היא פרסמה טיוטת חקיקה, מחמירה בהרבה מהחוק הבריטי, שתחמיר את כללי אבטחת הסייבר כדי לאכוף אבטחת מוצרים טובה יותר. חוק חוסן הסייבר יאלץ יצרנים לשפר את אבטחת המוצרים לאורך כל מחזור חיי המוצר.
לומדים מההיסטוריה
הגישה של תעשיית ה-PC לאבטחה לפי עיצוב נמצאת כיום במקום שבו הייתה תעשיית הרכב באמצע שנות השישים. אבטחת סייבר הפכה לדאגה ציבורית רחבה, וכמה ארגונים בחנו גישות לאבטחה מובנית על בסיס וולונטרי כדי לבדל את עצמם ולהגן על המשתמשים שלהם.
כעת, ממשלות לוחצות בהדרגה על הנושא עם חקיקה. יש עוד דרך ארוכה לעבור, בין היתר משום שהמורכבות של פתרונות ה-IT ושרשרות האספקה הדיגיטליות התומכות בהם היא בסדר גודל גדול מזו של מגזר הרכב לפני הדיגיטציה.
חלק מהדברים נשארים אותו הדבר, בעיקר חוסר מודעות או אמביוולנטיות של הצרכנים. כאשר ארה"ב הטילה על הכללת חגורות בטיחות במכוניות, השימוש בהן היה מרצון. כאשר המדינות הראשונות החלו לדרוש שימוש בחגורות בטיחות כמעט שני עשורים מאוחר יותר, פחות מאחד מכל חמישה אנשים השתמשו בהן. זה יהיה תלוי בממשלות ובספקים לאכוף אבטחה טובה יותר במוצרים טכנולוגיים ולהבטיח שהם מופעלים למשתמשים כברירת מחדל.
