כאשר חברה מפתחת מוצר דיגיטלי או מחובר שמיועד לשיווק באירופה, אחד האתגרים המרכזיים הוא להבין מאיפה מתחילים. דרישות אבטחת סייבר אינן קשורות רק לתוכנה או לבדיקות חדירה. הן משפיעות על ארכיטקטורת המוצר, רכיבי התוכנה, מנגנוני העדכון, ניהול הספקים והתיעוד הטכני.
לכן, במקום להתחיל בשורה ארוכה של בדיקות ללא סדר ברור, כדאי לבנות מפת דרכים שמגדירה את שלבי ההיערכות.
שלב ראשון: להבין מהו המוצר
תהליך נכון מתחיל בהגדרה מדויקת של המוצר.
חשוב להבין אילו ממשקי תקשורת קיימים בו, האם הוא מחובר לאינטרנט, אילו נתונים הוא מעבד, האם קיימת אפליקציה נלווית והאם הוא מתקשר עם שירותי ענן.
במוצרים הכוללים Wi-Fi, Bluetooth, תקשורת סלולרית או טכנולוגיות רדיו אחרות, קיימת לעיתים חפיפה בין דרישות סייבר לבין דרישות תקינה נוספות.
לכן התמונה צריכה להיות רחבה ולא להתמקד רק באבטחת התוכנה.
שלב שני: לזהות נכסים וסיכונים
לא כל רכיב במוצר דורש אותה רמת הגנה.
יש לזהות אילו נתונים, ממשקים ופונקציות הם הקריטיים ביותר. לדוגמה, מפתחות הצפנה, פרטי משתמשים, הרשאות ניהול או מנגנון עדכון יכולים להיות נכסים רגישים במיוחד.
לאחר מכן ניתן לבחון אילו תרחישים עלולים לפגוע בהם.
גישה כזו מאפשרת לצוות הפיתוח להשקיע משאבים במקום שבו הסיכון משמעותי יותר.
שלב שלישי: לבדוק את מנגנוני הגישה
במכשירים מחוברים חשוב לבחון מי יכול להתחבר למוצר ומה כל משתמש רשאי לבצע.
שימוש בסיסמאות חלשות, הרשאות רחבות מדי או ממשקי ניהול פתוחים עלול להגדיל משמעותית את משטח התקיפה.
לכן חלק מתהליך ההיערכות כולל בדיקה של מנגנוני אימות, הרשאות ותהליכי ניהול משתמשים.
שלב רביעי: לבחון את שרשרת התוכנה
מוצרים מודרניים מבוססים בדרך כלל על רכיבי תוכנה רבים, שחלקם מגיעים מספקים חיצוניים או מקוד פתוח.
היצרן צריך לדעת אילו רכיבים קיימים במוצר ואילו גרסאות נמצאות בשימוש.
כאשר מתפרסמת חולשה חדשה ברכיב מסוים, מידע כזה מאפשר להבין במהירות האם המוצר מושפע ומה נדרש לעשות.
שלב חמישי: להכין מנגנון עדכון
אין מוצר תוכנה שנשאר ללא שינוי לאורך שנים.
לכן יש חשיבות רבה למנגנון שמאפשר להפיץ תיקוני אבטחה בצורה מבוקרת.
המוצר צריך להיות מסוגל לזהות עדכון אמין ולמנוע התקנה של קוד שאינו מורשה. במקביל, היצרן צריך להחזיק תהליך שמגדיר כיצד מתקבלת החלטה על תיקון וכיצד הוא מופץ.
שלב שישי: לבדוק את המוצר
בדיקות אבטחה הן שלב מרכזי, אך הן צריכות להגיע לאחר שיש הבנה ברורה של הארכיטקטורה והסיכונים.
הבדיקות יכולות לכלול תקשורת, גישה, ממשקי API, עדכונים, הצפנה ורכיבים נוספים בהתאם למוצר.
במוצרים הכוללים תקשורת אלחוטית, יש לעיתים צורך לבחון במקביל גם היבטי RF, EMC ודרישות רלוונטיות נוספות.
שלב שביעי: לבנות תיעוד
מפת דרכים טובה אינה מסתיימת בבדיקות.
יש לתעד את ההחלטות שנעשו, הסיכונים שזוהו, הבקרות שיושמו ותוצאות הבדיקות.
כך ניתן להראות לא רק שהמוצר עבר תהליך בדיקה, אלא גם שקיימת מתודולוגיה מסודרת לניהול האבטחה.
למה כדאי לבנות מפת דרכים מראש?
היתרון המרכזי הוא מניעת עבודה כפולה.
אם החברה מבצעת בדיקה ורק לאחר מכן מגלה שחסר מנגנון בסיסי במוצר, יהיה צורך לחזור שוב לפיתוח ולבדיקה.
לעומת זאת, מפת דרכים ל-CRA מאפשרת ליצרן להסתכל מראש על דרישות הסייבר, מאפייני התקשורת, הבדיקות והתיעוד כחלק מתהליך אחד.
כך ניתן לתעדף את העבודה ולזהות נקודות שעלולות לעכב את היציאה לשוק.
לסיכום
היערכות ל־CRA אינה מתחילה בבדיקת חדירה ואינה מסתיימת בדוח.
היא מתחילה בהבנת המוצר וממשיכה בניהול סיכונים, אבטחת גישה, טיפול ברכיבי תוכנה, עדכונים, בדיקות ותיעוד.
כאשר השלבים האלו מתוכננים מראש, תהליך ההיערכות הופך ברור ויעיל יותר, וניתן לצמצם את הסיכון לשינויים משמעותיים בשלבים מאוחרים של הפיתוח.