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

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

מילות מפתח: אבטחה, IoT, מידול איומים, הערכת איומים וסיכונים, האינטרנט של הדברים, משטח תקיפה, האקר, איום אבטחה, פגיעויות מערכת, מערכת מקושרת, מערכות מקושרות, מטרות הערכה, TOE, מערכת ‘ניקוד הפגיעות המשותפת’, CVSS, צד שלישי, חומרה, תוכנה, חיישנים, ענן, שערים, TRA, תעשייתי, תכנון מאובטח

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

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

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

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

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

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

מידול איומים

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

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

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

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

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

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

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

משאבים זמינים

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

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

בשל המנעד הרחב של דרישות וטכניקות, כלים אוטומטיים כגון ‘פרויקט דרקון האיומים’ של OWASP (הפרויקט לאפליקציות פתוחות לאבטחה ברשת), SeaSponge של Mozilla, וכלי מידול האיומים של Microsoft נוצרו כדי לסייע למפתחים בתהליך המידול. כל כלי משתמש במתודולוגיית מידול איומים אחרת, החל מיצירת דיאגרמת מערכת ב’פרויקט דרקון האיומים’ ו-SeaSponge ועד לגישת STRIDE של Microsoft. אף שהכלים האלה כבר בני כמה שנים, ובנויים עבור מערכות תוכנה ארגוניות, מידול איומים הוא תהליך ישים ורענן תמיד המסתמך יותר על רשימות מעודכנות של וקטורי תקיפה, חולשות, ופגיעויות מאשר מתודולוגיות ספציפיות. עם זאת, כלים חדשים כבר החלו להופיע, המבטיחים קשר הדוק יותר בין תיאור המערכת לזיהוי האיומים. למרות העלייה המהירה של טכנולוגיות למידה עמוקה בתחומים אחרים, אתגרים משמעותיים נותרו עוד ביישום הטכנולוגיות האלה בהערכות איומים וסיכונים אוטומטיות. גם כך, הזמינות של כלים למידול חכם והערכת סיכונים עשויה להגיע בקרוב.

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

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

מסקנות

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

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