סייברס�キュリティ כתוסף ל-ASPICE ולמודל V

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

תקשורת הציגה תקנות סייבר בשנות ה-90 ותחילת שנות ה-2000, והמגזר הרפואי אפילו מוקדם יותר. מאז, כלי רכב הפכו מחוברים לאינטרנט, וחלק מהיצרנים (למשל Tesla) מבצעים עדכוני תוכנה מרחוק. יש לנו גם אפיקי תקשורת כמו CAN או LIN או אפילו Ethernet, שנמצאים כיום בשימוש נרחב בתעשיית ייצור הרכב ומאפשרים שליטה מרחוק בכלי רכב. 

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

גלו עוד על ASPICE מהמדריך שלנו

קבל את הספר האלקטרוני

קבל את הספר האלקטרוני

כיצד מוסדרת אבטחת סייבר במגזר הרכב? 

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

הדבר השתנה בשנה שעברה כאשר איגוד מהנדסי הרכב (SAE) פרסם את תקן ISO/SAE 21434:2021 – כלי רכב כבישיים – הנדסת סייבר. קיים גם תקן ISO/TR 4804:2020 כלי רכב כבישיים — בטיחות ואבטחת סייבר למערכות נהיגה אוטומטיות — תכנון, אימות ותיקוף וכן תקן TISAX המסדיר אבטחת מידע בתעשיית הרכב. 

Automotive SPICE לאבטחת סייבר 

למרות שנושא אבטחת הסייבר הוזנח בתעשיית הרכב במשך שנים רבות, אין זה נכון עוד לומר שהוא לא השתנה. איגוד תעשיית הרכב הגרמני הידוע (VDA) פרסם את הנחיות Automotive SPICE for Cybersecurity בפברואר האחרון. הן משמשות כעת כבסיס לכל חברה שעובדת עם יצרני OEM ועבור יצרניות הרכב עצמן.

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

למידע נוסף על מהו ASPICE, עיינו במדריך המבוא שלנו.

למרות שההנחיות מבוססות על מודל ה-V המסורתי שבו משימות מסוימות מקובצות לתהליכים, הן מוסיפות שכבה נוספת לרמות המוכרות ומכסות: 

• קבוצת תהליך הרכישה (ACQ) 
• קבוצת תהליכי אספקה (SPL) 
• קבוצת תהליכי הנדסת מערכות (SYS) 
• קבוצת תהליכי הנדסת תוכנה (SWE) 
• קבוצת תהליך התמיכה (SUP) 
• קבוצת תהליך הניהול (MAN) 
• קבוצת תהליכי שימוש חוזר (REU) 
• קבוצת תהליכי שיפור תהליכים (PIM) 

קבוצת הפעילויות הקשורות לאבטחת סייבר נקראה Cybersecurity Engineering Process Group (SEC) והיא כוללת 4 מרכיבים. 

בואו נעבור עליהם אחד אחד ונפענח אותם יחד. 

SEC.1: איסוף דרישות אבטחת סייבר 

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

ההנחיות גם מפרטות כללי דירוג מסוימים בכל הנוגע לסיכונים ולדרישות, כך שיטופלו ויזוהו כדי להבטיח בטיחות. 

SEC.2: יישום אבטחת סייבר 

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

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

SEC.3: אימות טיפול בסיכונים 

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

כמה משיטות האימות המפורטות בהנחיות כוללות: 

• ניתוח תוכנה סטטי, 
• בדיקות יחידה לתוכנה, 
• אינטגרציה של תוכנה ובדיקות קבלה, 
• אינטגרציה של מערכות ובדיקות קבלה. 

חשוב לציין כאן שהאימות אינו יכול להוכיח שנקבעו ויושמו אמצעי ניהול סיכונים נכונים. לשם כך נועד השלב הבא. 

סעיף 4: אימות טיפול בסיכונים 

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

שוב, קיימות שיטות אימות ספציפיות – כדלקמן: 

• סריקת פגיעויות, 
• בדיקות חדירה, 
• בדיקות ממשק 
• בדיקות פאזינג. 

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

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

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

אין להתעלם מהערכת הסיכונים הביטחונית הנקראת Threat Assessment and Remediation Analysis (TARA), המאפשרת זיהוי פגיעויות סייבר ומיתונן. 

תורך 

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

בדקו את הצעת Automotive Safety למידע נוסף, וצרו איתנו קשר אם יש לכם שאלות.