התוכנה מנהלת את העולם. זה שומר על מטוסים בשמיים, בתי חולים פועלים ומבטיח שהמערכת הפיננסית העולמית לא פוסחת אף פעם. אבל יותר ויותר, יישומים אלה נבנים באמצעות רכיבי קוד פתוח ממקורות שונים. מורכבות היא הרגיל החדש, בין אם מדובר בתוכנה קניינית או אפליקציות תוצרת בית. והמורכבות היא אויב הביטחון.
היחסים המורכבים בין רכיבים, והקלות שבה יכולים שחקני איומים להחדיר תוכנות זדוניות לקוד במעלה הזרם, צריכים להוות סיבה לדאגה למנהלי האבטחה. קריאות השכמה הגיעו עבה ומהר במהלך השנים האחרונות. הגיע הזמן למצוא דרך יעילה ניהול שרשרת אספקת התוכנה סיכון.
כיצד פועלת שרשרת אספקת התוכנה
שרשראות אספקה הן המסלולים הקריטיים דרכם מכוונים חומרי גלם ורכיבים לפני הרכבה, מכירה ושימוש. בעולם הדיגיטלי, רכיבים כאלה נחשבים לרוב כשירותים הניתנים מספק ללקוח. כפי שאנו נדון במאמר קודם, ספקי שירותים אלה הם יעד פופולרי יותר ויותר להתקפה מכיוון שגורמי איומים יכולים לייצר החזר ROI טוב. תקוף מיקור חוץ אחד של תהליכים עסקיים או ענקית שירותי IT, ויש להם הזדמנות לגנוב נתונים ו/או לסחוט מאגר פוטנציאלי גדול של לקוחות במורד הזרם.
שרשרת אספקת תוכנה דומה, אך במקרה זה, המערכת כוללת את הרכיבים, ספריות הקוד, הכלים והתהליכים הנדרשים לבניית תוכנה. על ידי התפשרות על רכיב בודד, או אפילו יישום שלם, תוקפים יכולים להשפיע על כל מפתח או ארגון המשתמשים בתוכנה/רכיב זה.
איפה הסיכון?
תוכנה אולי מנהלת את העולם, אבל מה בדיוק נכנס לבניית היישומים שמניעים כל דבר, החל מפלטפורמות מסחר אלקטרוני ועד למערכות ERP עסקיות קריטיות? יותר ויותר מדובר ברכיבי קוד פתוח. א דוח סונטיפ מעריך שבשנת 2022 לבדה, מפתחים הגישו 3.1 טריליון בקשות לרכיבים כאלה מארבע המערכות האקולוגיות המובילות בקוד פתוח: Java, JavaScript, Python ו-.NET. המשיכה היא שעל ידי הורדת החבילות המובנות מראש, מפתחים יכולים להאיץ את זמן היציאה לשוק ולעזור לעסק להגיב מהר יותר לביקוש השוק המשתנה במהירות. זה נטען ש-80% מהקוד ביישומים מודרניים מגיע מתוכנות קוד פתוח קיימות.
האתגר הוא שרכיבים אלה - או "תלות" בקוד פתוח - מכילים לרוב נקודות תורפה. לפי Sonatype, 1.2 מיליארד תלות פגיעות הורדו מדי חודש בשנה שעברה. אם יורדו בלי משים, הם עלולים להכניס את הסיכון לניצול על ידי גורמי איומים במועד מאוחר יותר. על פי קרן לינוקס, פרויקט פיתוח יישומים ממוצע מכיל 49 פגיעויות על פני 80 תלות ישירות.
גרוע מכך הן תלות עקיפה או טרנזיטיבית, שלטענת Sonatype מהוות שש מכל שבע פגיעויות בפרויקט. קשה יותר לעקוב אחר התלות הללו, מכיוון שהן למעשה הספריות והחבילות שקוראות לתלות ישירה - במילים אחרות, תלות של תלות. כתוצאה מכך, לא ברור מיד שאפליקציה מסוימת משתמשת בהם. זה יכול להסתיר נקודות תורפה מתחת לשכבה נוספת של ערפול.
מקרה נקודתי הוא הידוע לשמצה נקודות תורפה של Log4j. Log4j הוא כלי רישום לא מוכר אך פופולרי בשימוש על ידי למעלה מ-35,000 חבילות תוכנת Java. תיקון עבור פגיעות קריטית (CVSSS 10.0) בכלי שוחרר בסוף דצמבר 2021. אבל בגלל השימוש הנרחב שלו ברחבי מערכת הקוד הפתוח של Java, היה קשה מאוד לארגונים רבים למצוא ולתקן באופן סופי את כל המופעים של Log4j בסביבתם. לפי Google, רוב חבילות ה-Java שהושפעו היו פגיעות מכיוון ש-Log4j היה תלות טרנזיטיבית שקשה למצוא.
"ככל שהפגיעות עמוקה יותר בשרשרת תלות, כך נדרשים יותר שלבים לתיקון", הוסיפו.
לרוע המזל, שחקני איומים לא בזבזו זמן בניצול הבאג. לפי ורייזון, שליש (32%) מהסריקה לאיתור הפגיעות במערכות חשופות בשנה שעברה הגיע במהלך 30 הימים הראשונים לאחר פרסומו.
לצד האתגר של איתור ותיקון פגיעויות ברכיבי קוד פתוח, לארגונים יש כאב ראש נוסף של חבילות זדוניות שפורסמו למאגרי קוד פתוח על ידי גורמי איומים. Sonatype טוענת שרשמה עלייה שנתית של 633% בחבילות כאלה בשנת 2022, ליותר מ-88,000 מקרים ידועים.
איום נוסף: תוכנה קניינית
עם זאת, סיכון שרשרת אספקת התוכנה אינו מוגבל לקוד פתוח. מוצרים מסחריים קנייניים עשויים להכיל נקודות תורפה שהתקפות עלולות לנצל והן עושות באופן קבוע. הם עשויים לכלול גם באגי רכיבים וכלים בקוד פתוח, כמו Log4j. למעשה, מעט מאוד קוד שקיים היום ניתן באמת לתאר כ"קנייני", לפי מנהל סונטייפ של תמיכה למפתחים, סטיב פול.
"כתוצאה מכך, לצרכנים של יישומים קנייניים לכאורה יש תחושת אבטחה מזויפת, ולכן הם יכולים להיות פגיעים שלא ביודעין", הוא אומר ל-ISMS.online.
בהתקפות מתוחכמות יותר, כמו קמפיין SolarWinds, גורמי איומים יכולים אפילו לסכן את סביבת ה-IT של הספק עצמו ולהכניס תוכנה זדונית בעדכוני תוכנה לגיטימיים. זה אפשר לפעילי המדינה הרוסית להתפשר על כמה מחלקות ממשלתיות בארה"ב.
"ניתן להתפשר על כל סוג של תוכנה. הבעיה העיקרית היא אמון מרומז לא מוצדק בתוכנה הזו", טוען אודו שניידר, אוונגליסט אבטחה אירופה בטרנד מיקרו.
סמואל ברפוט, ראש צוות אבטחה ב-Checkmarx, אומר שהבגרות של ספק התוכנה והסמכת ISO היא חיונית.
"למרות שהתוכנה עצמה לא תוכננה לגרום נזק, אם היא חודרת, היא יכולה לשמש כדי להדליף מידע", הוא אומר ל-ISMS.online. "כאשר עוברים לענן, ארגונים מתמודדים גם עם סיכונים הקשורים לבקרה של ספקים, תמיכה, גיבויים וזמינות המערכת במקרה של פריצה או הפסקה. לבגרותו של הספק יש חשיבות מכרעת בהפחתת הסיכונים הללו באמצעות מוכנות והפרשות".
נראות היא הצעד הראשון לקראת ניהול סיכונים
בין אם הם עוסקים בקוד קנייני או בקוד פתוח, ארגונים המעוניינים להפחית סיכונים בשרשרת האספקה של התוכנה חייבים קודם כל לקבל תובנות לגבי רכיבים ותתי-רכיבים "רעים", לפי שניידר של Trend Micro. ניתן להשיג זאת על ידי בקשת קובץ תוכנה (SBOM).
"SBOM עבור חפץ תוכנה (ספרייה, בר הפעלה או אפילו מיכל) מכיל גרף תלות שבו מפורטים כל רכיבי התוכנה (משנה) שבהם נעשה שימוש, כולל מספר גרסה מדויק. ניתן להפיק SBOMs ישירות מהמקור בתוך a צינור CI/CD או מאוחר יותר על חפצים 'מתים' כמו קובצי הפעלה או אפילו מכולות", הוא מסביר.
"זה מועיל במיוחד עבור תוכנות קנייניות שבהן הספק בדרך כלל לא מספק SBOMs. בתחומי שיפוט/אנכיים שבהם הספקים חייבים לספק SBOM, ניתן לבדוק אותם באופן רציף מול פרצות ידועות, מה שמספק בסיס עדכני לפעולה אפשרית."
Poole של Sonatype מוסיף שארגונים צריכים גם להעריך את עמדת האבטחה של הספקים, תוך שימת לב מיוחדת לאיכות תהליכי הדיווח שלהם על פגיעות.
עבור רכיבי קוד פתוח, ארגונים צריכים להפעיל תוכנית של הערכה מתמשכת של רכיבי קוד פתוח, תיקון/עדכון מיידי במידת הצורך כדי למנוע ניצול מהיר, הוא טוען. כלי תוכנה לניתוח קומפוזיציה (SCA) יכולים לעזור גם על ידי גילוי מה יש בתוך מוצרים או רכיבים.
"עם זאת, התחכום של כלי ה-SCA חייב להתאים ולעלות על זה של השחקנים הרעים, אחרת הארגון עומד בפני הסיכון האמיתי של התקפה באמצעות וקטור לא מזוהה", הוא מזהיר.
"לבסוף, הביאו מפתחים לשוק על ידי חינוך כיצד מתרחשות התקפות סייבר מודרניות ומהם עקרונות קידוד מאובטח, ולמד אותם על האחריות שלהם בתחילת שרשרת אספקת התוכנה - לבחירות ולפעולות המיידיות שלהם יש השלכות".
התחל עם ISMS
שניידר של טרנד מיקרו טוענת כי א מערכת ניהול אבטחת מידע (ISMS) יכולה להיות דרך מצוינת להפחית את הסיכון בשרשרת האספקה של תוכנה על בסיס מתמשך.
"על ידי הזנת נתונים מכלי SBOM, מועשרים בנתוני הפצה, לתוך ISMS, ניתן להעריך טוב יותר ולתעד את עמדת האבטחה ולכן את הסיכון הכולל של המערכת כולה, שתוכנה היא רק חלק אחד ממנה", הוא מסביר. "כאשר משתמשים בו כבסיס להפחתת סיכונים ותיעוד הפעולות שננקטו, זה, באופן עקרוני, מספק אבטחה טובה בהרבה ממעקב ידני של נכסי תוכנה."
רשימת בדיקה לניהול סיכוני שרשרת אספקת תוכנה:
- בקש SBOM
- הערכת ספקי תוכנה קנייניים (במיוחד דיווח הפגיעות שלהם)
- השתמש בכלי SCA כדי לקבל תובנות לגבי רכיבי תוכנה
- סרוק באופן רציף לאיתור פגיעויות ותיקאי מיד
- למד מפתחים על החשיבות של אבטחה לפי עיצוב
- שקול להזין נתוני SBOM לתוך ISMS לניהול סיכונים הוליסטי
גלה כיצד הפתרון ISMS.online מאפשר גישה פשוטה, מאובטחת ובת קיימא לניהול סיכונים בשרשרת האספקה וניהול מידע עם ISO 27001 ולמעלה מ-100 מסגרות גלובליות אחרות.
