פגם של יום אפס ביישום התוכנה הארגונית שלך אפשר לתוקפים להיכנס לרשת שלך ולפגוע בנתונים רגישים. זה הולך לעלות הרבה לתקן עוד לפני שתגיעו לקנסות רגולטוריים ולתביעות משפטיות של לקוחות - והאפליקציה אפילו לא שלכם. מי צריך לשלם?
כנראה שזו לא תהיה החברה שמכרה לך את התוכנה. הסכמי הרישיון למשתמש הקצה שלהם (EULA) מגבילים בדרך כלל את אחריותם. רובנו לא קוראים את אלה כי הם כן ארוך מדי ומורכב מדי.
במהלך החודשים האחרונים התגברו הדרישות לשנות מצב זה, והגיעו לדרגים העליונים בממשל. בפברואר, ג'ן איסטרלי, מנהלת הסוכנות לאבטחת סייבר ותשתיות, נקרא במפורש בגין אחריות ספק במהלך נאום באוניברסיטת קרנגי מלון.
העולם קיבל טכנולוגיה לא בטוחה ככלל כאשר היא צריכה להיות היוצאת מן הכלל, אמרה. "יצרני טכנולוגיה חייבים לקחת בעלות על תוצאות האבטחה עבור הלקוחות שלהם."
איסטרלי ביקש מהממשלה לפרסם חקיקה שתמנע מחברות טכנולוגיה להתנער מאחריות בחוזה. של ממשל ביידן אסטרטגיית אבטחת סייבר לאומית, שהושק במרץ הקרוב, הדהד את הקריאה לחוק זה.
ויכוח ארוך שנים
ממשלות חשבו על בעיה זו בעבר. בית הלורדים בבריטניה מוּמלָץ הטלת אחריות על ספקי תוכנה ב-2007, גם לאחר שמיעת טיעונים נגד אחריות ספקים ממפתחי תוכנה בנימוקים שונים.
מחאות אלו כללו את המורכבות הרבה של סביבות תוכנה מודרניות. סוגים רבים של תוכנות מתקיימים יחדיו, ציין המפתח, והוסיף שהם עשויים לקיים אינטראקציה זה עם זה בדרכים מוזרות. האם אנו יכולים לצפות באופן סביר מספק תוכנה לחזות כל מקרה של קצה-פעולה הדדית?
דאגה נוספת הייתה הפוטנציאל לשגיאות משתמש. מה אם משתמש הגדר את התוכנה בצורה שגויה, מה שהופך אותה או רכיב שאיתו קיים אינטראקציה ללא בטוחים בגלל ממשק משתמש לקוי? מה אם המשתמש לא הצליח להחיל תיקון מסיבה לגיטימית, כגון אילוץ רגולטורי? האם יש דבר כזה אחריות חלקית לתצורה שגויה, וכיצד ניתן להחליט על כך?
ישנם אתגרים אחרים עבור חברות המנסות לעמוד בבעיות אחריות ספקים. הרבה תוכנות אינן בנויות בחלל ריק; הוא מסתמך על ספריות של צד שלישי - שמשוחררות לרוב תחת רישיונות קוד פתוח - שעשויות להכיל בעיות אבטחה משלהן. Log4Shell, הבאג בספריית הרישום של Log4J Java שהשפיע על אבטחת הסייבר עבור אלפי חברות מבלי לשים לב מאז 2013 - הוא דוגמה מצוינת. מי משלם אם התוכנה שבנית משתמשת במקרה ברכיב צד שלישי לא מאובטח?
ההשקפה שלך על תוכנה צריכה להתרחב מעבר לגבולות שלך, הציע Easterly. היא הדדה את קריאתו של הבית הלבן לחוק חומרי תוכנה (SBOM) כדי להגדיר את מקור התוכנה המורכבת.
איך נראית תוכנה מאובטחת?
החזקת ספקים של מוצר מורכב באחריות מעלה בעיות אחרות, כמו האופן שבו אנחנו אפילו מגדירים אבטחת תוכנה. ההגדרות נמצאות לאורך רצף, החל מהלא מספק - המוכיח כמה מבחני תוכנה סטטיים בסיסיים - לאימות הפורמלי הבלתי מעשי. האחרון בודק את פעולת התוכנה מול מודל מתמטי מופשט. מערכות כאלה קיימות, אבל הן מיועדות ליישומים מיוחדים וכרוכות בתקורת קידוד רבה.
ההגדרה המציאותית ביותר נמצאת איפשהו באמצע, עם הוכחה מתועדת של שיטות עבודה מומלצות המטמיעות אבטחה ישירות בייצור התוכנה משלב התכנון ואילך. מסגרת פיתוח תוכנה מאובטחת של NIST, שעליו ממליץ ה-NCS, מבטא רבים מאלה.
המלצה נוספת של Easterly הייתה השימוש בשפות בטוחות בזיכרון. שפע של פגמי אבטחת תוכנה מודרניים מקורם בשימוש לרעה בזיכרון. מכיוון ששפות מהירות ונמוכות הדורשות מתכנתים לנהל את הזיכרון בעצמם, C ו-C++ חלשות במיוחד כאן. Go, Python ו-Java הן שפות מתפרשות ברמה גבוהה יותר המטפלות בזיכרון מטעם המתכנת. שפה עדכנית יותר, Rust של Mozilla, היא גם בטוחה לזיכרון - והיא השפה הראשונה מלבד C ו-assembly שנתמכת בליבת לינוקס.
Easterly קרא גם למדיניות גילוי פגיעות שקופה בקרב ספקי תוכנה. לעתים קרובות מדי, הם עושים כמיטב יכולתם כדי לשמור על באגי אבטחה נמוכים, תוך התעלמות או לפעמים מרתיעה מדיווחי באגי אבטחה. לדבריה, מערכת יחסים פתוחה ושיתופית יותר עם חוקרי אבטחת סייבר תעזור לסגור פערים בתוכנה.
שלבי ביניים
בזמן שהוא מחכה לקונגרס, הבית הלבן מסתמך על צו מבצעי לשיפור אבטחת הסייבר של האומה, כיום בן יותר משנתיים, כדי לדחוף את הספקים בכיוון הנכון. המשרד הסגלגל לא יכול להעניש ישירות חברות על הכנת קוד גס, אבל ה-EO אוסר על סוכנויות פדרליות לקנות אותו מהן.
אנו יכולים גם להסתכל על סטנדרטיזציה לתשובות. תקן ISO 27001:2022 המעודכן כולל נספח א' בקרה 8.28, המגדיר עקרונות עיצוב ופיתוח מאובטחים הן עבור תוכנה שפותחה באופן פנימי והן לשימוש חוזר בקוד חיצוני. כאשר חברות רבות מסתמכות על הסמכה זו כמבדיל מפתח, הוספת הבקרה הזו יוצרת לחץ נוסף לשיפור ולתעד אבטחת התוכנה.
שינוי גאות פוליטית
בעוד שחבות הספקים היא נושא דביק, הקונגרס לא נמנע משימוש בחקיקה כדי להתמודד עם בעיות טכנולוגיות מורכבות בעבר. לעניין התאגידי יש חלק משמעותי בחוסר הרצון שלו להתמודד עם הבעיה הספציפית הזו, המונעת על ידי תעשיית תוכנה עם כוח לובינג רב.
עם זאת, יותר אנשים נמצאים במשימה לתת דין וחשבון לתעשייה תחרותית מאוד. פייסבוק אולי זנחה רשמית את הסיסמה הפנימית הישנה שלה, "זוז מהר ותשבור דברים", אבל זה עדיין מודל תפעול דה פקטו לחברות טכנולוגיה הדוהרות לחדש. ככל שהתוכנה משפיעה על יותר מחיי היומיום שלנו, איזשהו איזון בין פיתוח פיצ'רים פזיזים ואחריות מדודה לתפעול מאובטח נחוץ מאי פעם.
