מפת הדרכים ל- CRA – איך לתעדף מוצרים, לזהות פערים ולהיערך לבדיקות תקינה?

היערכות ל־Cyber Resilience Act האירופי מציבה בפני יצרני חומרה ותוכנה אתגר מעשי: כיצד להפוך דרישות רגולטוריות רבות לתוכנית עבודה מסודרת, עם סדרי עדיפויות, אחריות מוגדרת ולוחות זמנים ברורים?

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

שלב ראשון – בניית מפת מוצרים

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

שלב שני – ביצוע ניתוח פערים לכל מוצר

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

שלב שלישי – תעדוף לפי סיכון, מורכבות ומועד השקה

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

שלב רביעי – בניית תוכנית בדיקות תקינה

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

שלב חמישי – ניהול ממצאים ובדיקות חוזרות

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

שלב שישי – מעקב אחר התקדמות ומוכנות רגולטורית

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

כיצד מעבדת בדיקות יכולה להשתלב ב־CRA roadmap?

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

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

סיכום – מתכנון רגולטורי לתוכנית עבודה ישימה

CRA roadmap יעיל מתחיל במיפוי המוצרים וממשיך בניתוח פערים, תעדוף סיכונים, ביצוע בדיקות, טיפול בממצאים ומעקב אחר התקדמות.
במקום להתייחס להיערכות כאל משימה חד־פעמית לקראת מועד רגולטורי, מומלץ לשלב אותה בתהליכי הפיתוח, האיכות ואבטחת המוצר.
כך ניתן לבנות תוכנית עבודה מדידה, להבין היכן נדרשת השקעה נוספת ולשפר את המוכנות של החברה לדרישות ה־Cyber Resilience Act.
המידע במאמר כללי בלבד. תחולת הרגולציה ותהליך הערכת ההתאמה צריכים להיבחן בהתאם למאפייני כל מוצר ולדרישות העדכניות.