תקן ISO/SAE 21434 “רכבי כביש – הנדסת אבטחת-סייבר” מציין מגוון של דרישות והמלצות הנדסיות עבור ניהול סיכוני אבטחת סייבר בשלבי הרעיון, פיתוח המוצר, הייצור, התפעול, התחזוקה וההוצאה משירות של מערכות חשמליות ואלקטרוניות ברכבי כביש. התקן כולל גם את הרכיבים והממשקים של מערכות אלה. בעוד תקן ISO/SAE FDIS 21434 מספק מבט יותר הוליסטי על אבטחת סייבר ובכלל זה תיאורים של דרישות רבות, פעילויות ותוצרי עבודה של אבטחת סייבר, הן ברמה הארגונית והן ברמת הפרויקט, מאמר זה מתמקד בפתרונות פרקטיים לאבטחת סייבר עבור תהליך של פיתוח תוכנה מאובטחת. באופן ספציפי יותר, המאמר מתמקד בפתרונות בדיקה לאבטחת יישומים (AppSec) העוסקים בגורמים המובילים לחולשות ולפגיעויות בתוכנה למערכות רכב. על פי סקר אבטחת טכנולוגיות רכב (automative security survey), גורמים אלה כוללים שגיאות בכתיבת קוד, אי ביצוע בדיקות, ושימוש ברכיבים פגיעים של תוכנת קוד פתוח (Open Source Software – OSS).
פתרונות לביסוס תהליך של פיתוח תוכנה מאובטחת
קיים מגוון של פתרונות היכולים לשמש ארגונים בתחום הרכב במהלך מחזור החיים של פיתוח התוכנה, בכדי לסייע לזהות ולתקן פגיעויות. מכיוון שלארגונים בתחום הרכב יש לעיתים קרובות משאבי אבטחה מוגבלים, נתמקד כאן בפתרונות אוטומטיים לאבטחת יישומים ולא בפעילויות ידניות. איור 1 מספק סקירה של האופן שבו פתרונות אלה מותאמים ל-V-model ולסעיפים הרלבנטיים בתקן ISO/SAE FDIS 21434.
איור 1 :פתרונות המותאמים ל-model-V ולסעיפים רלבנטיים בתקן SAE/ISO 21434 FDIS . קרדיט: Synopsys
פעילויות אינטגרציה ואימות
בנוגע לכתיבת קוד, דרישה [RQ-10-09] בתקן ISO/SAE FDIS 21434 קובעת שפעילויות אינטגרציה ואימות נדרשות לאמת שהמימוש והאינטגרציה של רכיבים ימלאו את המפרטים המוגדרים לאבטחת סייבר. דרישה [RQ-10-10] מציינת שניתן להשתמש בניתוח סטטי כפעילות אימות עבור דרישה [RQ-10-09]. יתר על כן, דרישה [RQ-10-05] קובעת שיש להשתמש בקווים מנחים לכתיבת קוד במקרה שבו לא ניתן מענה מספק לאבטחת סייבר באמצעות שפת התכנות עצמה. כלים אוטומטיים לניתוח סטטי יכולים לנתח את קוד המקור בלי להריץ את התוכנה. משמעות הדבר היא שניתן להימנע מפעילויות ידניות להגדרת מקרי בדיקה. כלים אלה יכולים לסייע למצוא ממצאים כגון buffer overflows, דליפת משאבים, השחתת זיכרון ופגמים אחרים בקוד. בנוסף לכך, כלים לניתוח סטטי יכולים לבדוק את התוכנה ביחס לקווים מנחים רלבנטיים לכתיבת קוד, דוגמת MISRA C/C++, AUTOSTAR C++, ו-CERT C/C++.
בדיקת רכיבי תוכנה
בנוגע לבדיקות תוכנה, המלצה [RC-10-12] קובעת שיש לבצע בדיקת רכיבי תוכנה בכדי לאשר שחולשות ופגיעויות בלתי מזוהות שנותרות ברכיב התוכנה מצומצמות לכדי רמה מזערית. יתר על כן, המלצה [RQ-11-01] קובעת שניתן להשתמש בבדיקות חדירה כפעילות תיקוף בכדי
להדגים את ההתאמה והשגת יעדי אבטחת הסייבר. קיימות מספר שיטות בדיקה שניתן ליישם בכדי לבצע סוג זה של בדיקה, ובכלל זאת סריקת פגיעות (vulberability scanning), Fuzz testing ובדיקות חדירה.
סריקת פגיעות עושה שימוש בידע על פגיעויות ידועות או דפוסי מתקפה ידועים בכדי לזהות פגיעויות במערכת היעד. לדוגמא, כלים לניתוח מרכיבי תוכנה (Software Composition Analysis – SCA) יכולים לזהות פגיעויות ידועות ברכיבי OSS במערכת היעד. הסריקה האוטומטית של קוד המקור או של הרכיבים הבינאריים מזהה את רכיבי הקוד הפתוח, את הגרסאות של כל רכיב, ואת הפגיעויות הידועות הקשורות אליהם.
בעוד כלים לסריקת פגיעות עושים בדרך כלל שימוש במסד נתונים של פגיעויות ידועות או של דפוסי מתקפה ידועים, Fuzz testing היא בדיקה מרחיקת לכת יותר שמזהה פגיעויות בלתי ידועות באמצעות יצירת קלט פגום (לא חוקי) שמסופק מאוחר יותר למערכת היעד. כלים ל-Fuzz testing יכולים לזהות פגיעויות בלתי ידועות במגוון מימושי פרוטוקול ובכללם CAN, CAN-FD, Automotive Ethernet, Wi-Fi, ו-Bluetooth, בנוסף לזיהוי פגיעויות בפרוטוקולים מהשכבות הגבוהות יותר דוגמת ISO-TP, UDS, DoIP, gPTP, IP, TCP, HFP, A2DP, ועוד.
ניתן להשתמש בכלים אוטומטיים בכדי לבצע סריקת פגיעות ו-fuzz testing. בניגוד לכך, בדיקות חדירה כוללות בדרך כלל פעילויות ידניות במטרה לפרוץ מטרות אבטחה מסוימות במערכת היעד.
ארגונים אף צריכים לבצע ניטור רציף בכדי לגלות איומים חדשים ופגיעויות חדשות הן במהלך פיתוח התוכנה והן אחרי שהמוצר יצא לשוק. דרישה [RQ-08-01] קובעת שניתן לנטר מקורות פנימיים וחיצוניים בכדי לאסוף מידע על אבטחת סייבר. כלי SCA יכולים לספק התראות בנוגע לפגיעויות שזוהו לאחרונה ברכיבי OSS כחלק מפעילויות מתמשכות של אבטחת סייבר.
הפיקו את המיטב מהכלים שלכם באמצעות אוטומציה
ד”ר דניס קנגו אוקה) Dennis. Dr Oka Kengo ,אסטרטג ראשי לאבטחת טכנולוגיות רכב, Synopsys Group Integrity Software קרדיט: Synopsys
חשוב להכיר בכך שכלים אלה כשלעצמם אינם מועילים כמו אוטומציה של הכלים כחלק מפייפליין בתהליך פיתוח התוכנה (Continous Integration – CI). ארגונים בתחום הרכב צריכים לבסס תהליכים הולמים עבור ניתוח סטטי, סריקת פגיעות, Fuzz testing, וניטור אבטחת סייבר, ולשקול גישות לפריסה של כלים אוטומטיים לאבטחת יישומים. מהלכים אלה כוללים החלטות בנוגע לכלים שייכנסו לשימוש, מה לבדוק, אלו סביבות בדיקה נדרשות, ובאיזו תדירות יש לבצע בדיקות. יתר על כן, בכדי להבטיח את היעילות והאפקטיביות של הכלים, ארגונים בתחום הרכב צריכים לשקול לשלב כלים לבדיקת אבטחת יישומים לתוך תהליך פיתוח התוכנה יחד עם כלים אחרים, ובכללם מערכות לניהול קוד מקור, שרתי אוטומציה, ומערכות לאיתור באגים.
ארגונים בתחום הרכב אף יכולים לשקול לאמץ פלטפורמות אוטומציה בכדי להריץ כלים לאבטחת יישומים, למצוא קורלציה בין התוצאות ולסייע לתעדף טיפול בפגיעויות, וכן לספק יכולת לראות באופן מרוכז את הסיכונים בנוגע למה שנבדק, מתי הוא נבדק, מה נמצא, ומה תוקן.
פיתוח תוכנה מאובטחת לטכנולוגיות רכב עוד היום באמצעות ISO/SAE 21434
כאשר בוחרים בפתרונות עבור תהליך פיתוח תוכנה מאובטחת בתחום הרכב העומד בתקן ISO/SAE 21434, ארגונים חייבים להיות דינמיים. שילוב של תהליכי אבטחת סייבר דורש לעיתים קרובות שינוי תרבותי. יש לשים דגש על אוטומציה בשימוש בכלים בכדי לשלב באופן יעיל ואפקטיבי פעילויות אבטחת סייבר בתוך תהליך פיתוח התוכנה.
