מכשיר רפואי על לינוקס שאינה נתמכת: מה עושים כשאי אפשר לעדכן

Read this article in English

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

המוצר רץ על גרסת לינוקס שכבר לא נתמכת, End of Life. אין עדכוני אבטחה. אין security patches. אין תמיכת ספק. והחברה לא יכולה לעדכן את מערכת ההפעלה בצורה גורפת, כי הגרסה הזו הוכרזה EOL והופסקה התמיכה הרשמית בה.

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

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

לפרק את הבעיה לגורמים

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

התחלנו בניתוח מפורט של כל החבילות שמותקנות במערכת, כל ה-packages וה-libraries. החלטנו לחלק למקרים.

מצאנו חבילות שלא בשימוש בכלל, אבל עם חולשות אבטחה ידועות – חבילות שמרחיבות את ה-attack surface של המוצר בלי לתת לו שום ערך פונקציונלי. המלצנו להסיר אותן לחלוטין. כבר בשלב הזה הצלחנו לצמצם בערך 50% מהבעיה. לא כי "תיקנו הכל", אלא כי עצם הפירוק לגורמים וההבנה מה באמת בשימוש ומה לא, אפשרה להוריד מהמערכת רכיבים שהיו שם רק כי "ככה זה תמיד היה".

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

בחלק מהמקרים זה היה עדכון של package ספציפי. בחלק מהמקרים החלפה של library ב-alternative נתמך. ובחלק מהמקרים הפתרון היה ברמת הלוגיקה של המוצר עצמו.

היו מקרים שבהם הפתרון היה יצירתי לגמרי. לא סטנדרטי. לא "לפי הספר". Mitigation ברמת ההבנה של מה המוצר שלהם באמת צריך ומשתמש ברמת ה-OS. ניתחנו את הקוד שלהם. ביצענו בעצם hardening, וחסימה יזומה של פרצות – גם בלי patch רשמי. אבל זה עבד, והסיכון עבור החברה ירד בצורה משמעותית.

מה שהפתיע את הלקוח

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

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

פוסט זה פורסם לראשונה בלינקדאין בתאריך 2026-01-10. — ארז מטולה