בעת שחברות רבות שועטות במטרה לחולל טרנספורמציה דיגיטלית ולהישאר תחרותיות, שילובה של הקישוריות של האינטרנט התעשייתי של הדברים – IioT, בפעילות העסקית שלהן, הופכת לסטנדרט הלכה למעשה . כשנדרשת הכרעה האם לפתח או לרכוש פלטפורמות ופתרונות IIoT, בוחרים חלק מהארגונים לשגות ולהמשיך בנתיב הקודם והמוכר של פיתוח, מתוך הנחה שכך יוכלו לחסוך כסף לעומת החלופה. המלכודות הכלכליות הגלומות בפרויקטים של IloT בשיטת עשה זאת בעצמך (DIY) ניכרות היטב. אולם ישנו היבט אחד שארגונים רבים כושלים לקחת בחשבון שהופך לקריטי יותר ויותר, אבטחת סייבר.
הסיכון העסקי הכרוך במתקפה דיגיטלית ברור. המקרה של חברת ה-IT SolarWinds, אשר שימשה מבלי ידיעתה כערוץ מרכזי להדבקת תוכנות שרשרת האספקה של לקוחותיה בשנת 2020, הינו מאלף. החברה העריכה כי העלויות הישירות של ההתמודדות עם הפריצה יהיו לפחות 18 מיליון דולר, שלא לדבר על הנזק שנגרם למותג בעקבותיה. דוגמה מדאיגה עוד יותר היא המקרה של התוכנה זדונית המכונה TRITON. בשנת 2017, התקין גוף ממשלתי את הכלי הדיגיטלי הזדוני הזה במסגרת ניסיון שכמעט צלח להרוס פיזית מפעל פטרוכימי.
לנוכח האיומים הללו, עסקים צריכים להיות בטוחים שהם מפחיתים את סיכוני אבטחת הסייבר בצורה נאותה, ובמקביל עליהם להקצות משאבים ביעילות על מנת לשפר את התפעול היומיומי. פעולה זו יכולה עשויה להיות מאתגרת גם עבור חברות הבונות פתרונות דיגיטליים כקו העסקים העיקרי שלהן, ובמיוחד עבור אלו שמייצרות הכנסות גם מדברים אחרים מלבד פיתוח ומכירה של תוכנות.
שיקולי אבטחה בפלטפורמות lloTבשיטת עשה-זאת-בעצמך
בראש ובראשונה, פיתוח עצמי של פלטפורמת lloT בעל רמת אבטחה, מחייב את הארגון להעסיק מומחי אבטחה מתאימים. כמו כן, כל מערך הפיתוח של הארגון מאנשי הפיתוח, הארכיטקטים, מנהלי המוצר, אנשי הבדיקות וההנהלה הבכירה חייב להבין את הפשרות וההשלכות של פיתוח המוצר כאשר שיקולי אבטחת הסייבר נלקחים בחשבון. בחינה רעיונית ופילוסופית, יש לשקול כיצד תוכלו למדוד ולנהל את סיכוני הסייבר. מהן רמות הסובלנות שלכם לסיכונים? כיצד תשקללו את הפחתת סיכונים כנגד מטרות עסקיות? מי יקבל את ההחלטות הקשות ויחליט אילו כשלים לפתור ואילו מהם לקבל? (להיות אחראי אם משהו משתבש).
ברמה הטכנית, מהנדסים יצטרכו ללמוד כיצד לשלב עקרונות אבטחה בסקירת הקוד של עמיתיהם – בהנחה שהארגון שלכם כבר עושה זאת – וצוותי אבטחת איכות יצטרכו לוודא שהם בודקים גם את הבאגים של אבטחה המידע, במקום לבדוק רק את הפונקציונליות של המוצרים שלכם בלבד. הארגון שלכם יצטרך לערוך בקביעות הכשרות פיתוח מאובטח, כדי לשמור על כישורים אלה בקרב עובדיו.
בהנחה שהצוות הנדרש קיים או שהוכשר ברמה נאותה – הצעד הבא יהיה בחירה ויישום של מסגרת פיתוח מאובטחת. בין אם בחרתם ב- Microsoft Security Development Lifecycle (SDL) או במודל הבטחת בשלות התוכנות בקוד פתוח (SAMM), או כל פרדיגמה אחרת, פיתוח רכיב ניהול התוכניות לאכיפת תאימות ברחבי הארגון שלכם, יהיה מחויב המציאות.
אם הגעתם עד כאן ואתם מעוניינים להמשיך בנתיב ה-DIY, תצטרכו בשלב הבא לשלב כלי סריקה אוטומטיים מתאימים בצנרת הפיתוח שלכם. זאת, בנוסף לשימוש בניתוח קוד סטטי לזיהוי שגיאות תכנות. כמו כן, עליכם לערוך ניתוח הרכב תוכנה בקביעות, כדי לסקור ספריות צד שלישי הפועלות מול הקוד הקנייני שלכם. כאשר האפליקציה שלכם הושלמה ומוכנה לעבור לשלב ה- Production, מומלץ שתערכו כנגדה ניתוח דינאמי בזמן ההרצה כדי לוודא שאין פגיעות שלא היו מזוהות בעבר. למרות שאכן קיימות אופציות קוד פתוח לכל היכולות הללו, למוצרים ברמה הארגונית שיכולים לתמוך בתהליכי אינטגרציה מתמשכת/פריסה מתמשכת מודרנית, ודרישות תאימות רווחות, יש לרוב תג מחיר יקר.
גם ברגע שהגעתם לשלב ה- Production, האחריות הארגון על אבטחת הסייבר של המוצר לא הסתיימה . בדיקות סדירות לאיתור חדירות – הן של עובדים והן של מומחים חיצוניים – הינן קריטיות להדמיית התקפות סייבר בעולם האמיתי, ולמציאת פערי אבטחה לפני שהחבר’ה הרעים יעשו זאת. יתר על כן, מה תעשו אם מומחה אבטחת סייבר יאתר בעיה בפתרון העשה-זאת-בעצמך החדש שלכם? אתם תזדקקו ליכולת תגובה לאירוע, לנהל משא ומתן, ולגלות בצורה מתואמת את נקודות התורפה שלכם. אחרת, אתם עשויים להתמודד מול גילוי לא מתואם של פרצה על ידי מומחה אבטחה, המתוסכל מקצב העבודה האיטי שלכם.
גם אם הצלחתם ליישם את כל האמור לעיל בהצלחה, עדיין תצטרכו להמשיך ולשמור על הפלטפורמה שיצרתם ללא הגבלת זמן, באמצעות הקצאת משאבי הנדסה לתיקון באגים של אבטחה, עדכון ספריות, והקפדה על עבודה על פי פרוטוקולים סטנדרטיים המקובלים בתעשייה. בנוסף לעלויות הפיתוח הקבועות שנלקחו בחשבון מראש, הקפידו לתקצב את הוצאות התפעול החוזרות ונשנות למשך כל חיי פרויקט ה-DIY שלכם. מגמות בתעשייה מצביעות על כך ש-30% מזמן הפיתוח מוקדש לתחזוקת הקוד, ומהניסיון שלי, כשליש מזה מוקדש לאבטחה בלבד.
לבסוף, חשוב לקחת בחשבון את היתרון לגודל, עליו תאלצו לוותר בעת בניית פלטפורמת IloT משלכם. כארגון שהמטרה העיקרית שלו אינה פיתוח תוכנה, סביר להניח שתתקשו לעבוד ולתקשר ביעילות עם מומחי אבטחה אחרים במגזר הפרטי והציבורי כאחד. בדומה לכך, היעדר ניסיון בפיתוח אפליקציות מאובטחות עשוי להשפיע על פרמיות ביטוח הסייבר שלכם.
דני גוטמן, מנהל ה- IT בחברת PTC
קרדיט: PTC
תובנות לסיכום
לנוכח דרישות אלה והמורכבות הכרוכה באבטחה ותחזוקת פלטפורמת IloT משלכם, ניסיון לפתח באופן עצמי מוגדר כמשימה מאתגרת וקשה לארגון. בהתחשב בהיקף ההוצאות והסיכונים הגלומים במאמץ שכזה, לפחות מומחה אבטחה עצמאי אחד ימליץ שלא לעשות זאת. החלטנה נכונה יותר תהיה להשתמש בפלטפורמה קיימת מובילה בשוק, עם פתרונות מובנים מראש, אשר כבר משלבת שיטות עבודה מומלצות לאבטחה. פעולה זו תעזור לכם לנהל את סיכוני אבטחת המידע בצורה חסכונית, ובמקביל להתמקד במה שהכי חשוב לכם: העסק שלכם.
קרדיט תמונת שער: PTC
