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

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

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

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

כרגיל, הרשות מנצלת את ההזדמנות לחזור על כמה דגשים, ובהם:

• החובה לכלול גם רכיבי מערכת מבוססי קוד פתוח ברשימת המצאי של מערכות המאגר שיש להכין לפי תקנה 5.
• החובה להשתמש רק בספריות קוד פתוח שנתמכות ומתוחזקות בידי קהילת הקוד הפתוח או גוף רלוונטי אחר כדי לעמוד בתקנה 13(א) – בתקווה שהגורם המתחזק אינו עוין בעצמו, כפי שקרה ב xz Utils, כאמור לעיל.
• הצורך להתקין אמצעי הגנה על מאגר שמחובר לאינטרנט, תוך ציון החשש להפרה של תקנה 14(א) כאשר האמצעי מכיל קוד פתוח שעלול לאפשר חדירה לא מורשית למידע.
• החובה לבחון גם את הסיכונים הנובעים משימוש בקוד פתוח במסגרת מיקור חוץ, במסגרת הבדיקה הנדרשת לפי תקנה 15(א)(1).

במסגרת הפעולות הפרקטיות, הרשות מציינת את כל אלה:

• בדיקת חולשות ידועות בקוד הפתוח טרם שימוש בו בארגון (כחלק מהחלת גישת privacy by design). למסמך הרשות מצורף נספח שמונה ארבע חולשות מוכרות.
• דרישת רשימת מצאי מהספק של רשימת מערכות מבוססות קוד פתוח (במקרה שבו יש ספק של תוכנה מסחרית למשל שמבוססת קוד פתוח).
• העדפת ספק שמצהיר שהוא עומד במסגרות העבודה המקובלות בתחום.
• ביצוע הכשרות לבעלי תפקידים רלוונטיים.
• חלוקת תפקידים ביחס לאחריות לאבטחת מידע במסגרת השימוש בקוד הפתוח בארגון, ואפילו בחינת אפשרות למינוי Open Source Program Officer.
• החלטה על אופן תחזוק הקוד או החלפתו בנסיבות מסויימות.
• מיפוי רכיבי תוכנה בקוד הפתוח בארגון (כאמור, לדעת הרשות הדבר נדרש כחלק מיישום תקנה 5 לתקנות אבטחת מידע).
• ניהול רשימה שמפרטת באיזה רישיון משתמש כל רכיב קוד פתוח.
• יצירת נוהלי קוד פתוח בארגון ובקרות ליישומיהם, כולל בעת שימוש או שחרור המוצר, כשרלוונטי.
• סקירה כללית של תוכנית תאימות לקוד פתוח.
• בקרה (למשל באמצעות כלים ייעודיים שהרשות מציינת שניים מהם במסמך – SBOM ו VEX).
• וידוא כי ברמה החוזית יש שרשור של האחריות להטמעת קוד פתוח (באופן מאובטח) לאורך שרשרת האספקה.
• לבסוף, נציין כי הרשות מתייחסת במסמך גם ל"פרסום מסמך הגדרות מאגר". מכיוון שהתקנות מחייבות עריכה ועדכון בלבד של מסמך הגדרות מאגר, ולא את פרסומו, ניתן להניח שהכוונה היא לפרסום מסמך מעודכן באופן פנים ארגוני.

הרשות ממליצה להסתייע במסגרות עבודה לניהול סיכונים בקוד פתוח, כגון ISO5230, ISO DIS 18974 8 ו Microsoft S2C2F9.

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

אנו עומדים לרשותכם בכל שאלה,

אייל שגיא, שיר שושני כץ וליאור תלמוד

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