האינטרנט של הדברים (IoT) מביא עמו בשורה חדשה והזדמנויות עסקיות חדשות, כאשר עסקים יוכלו להציע שירותים חדשים ומרגשים. עם זאת, ריבוי המכשירים והנכסים העסקיים המקושרים ל-IoT, ופתוחים לאינטרנט, מחייבים גישה קפדנית ואמינה לאבטחה. מודל אבטחה כזה, שנמצא בשימוש כבר זמן רב, הוא המודל של CIA triad. הרכיבים המרכזיים במודל זה (איור מס. 1), מבוססים על סודיות (confidentiality), שלמות נתונים (integrity) וזמינותם (availability). הסודיות חשובה להגנה על פרטיות מכשירי ה-IoT, שלמות נוגעת לנתונים המאוחסנים במכשירים, בעוד שזמינות קשורה לנגישות של המכשיר. מאמר זה יתמקד בהיבטים של שמירת שלמות הנתונים.
כאשר אנו חושבים על נתוני התקן IoT, דוגמת חיישן המשדר נתונים, אנו צריכים לחשוב לא רק על הנתונים המיוצרים על ידו או נמצאים בשימושו, אלא גם על נתוני התכנות שלו עצמם, הכוללים את כל רכיבי התוכנה, פרמטרים של תצורה ומערכת ההפעלה. כדי להנחות את תהליך שלמות הנתונים, כדאי לשקול שלושה מצבים שונים בהם הנתונים עשויים להימצא: בתנועה, במנוחה, ובתהליך. איור 2 מציג את פירוק עקרון שלמות הנתונים לעקרונות משנה, ולבסוף המימוש עצמו אותו עשוי מכשיר ה-IoT לכלול כדי להגן על שלמות נתוניו.
משמעות פגם בשלמות הנתונים הינה שלא רק שמכשיר IoT לא יפעל כראוי, אלא גם חושפת את המכשיר לניצול על ידי גורם לא מורשה, ובכך להפיכתו לפלטפורמה פרוצה ממנה ייצאו התקפות אחרות.
השיטה הרגילה לאימות שלמות הנתונים היא באמצעות אלגוריתם מתמטי הנקרא hash, כאשר SHA הוא אלגוריתם hash המאובטח הפופולארי ביותר.
נתונים בתנועה דורשים הגנה מפני שינויים בזמן המעבר של הנתונים מהחיישן עצמו אל אפליקציית ענן. בעוד שניתן להשתמש בטכניקת hash, גורם עוין תוקף יכול לבצע שינויים בהודעה לאחר פעולת hash. גישה חזקה יותר היא שימוש בבדיקת שלמות נתונים עם מפתח פרטי (private (key משותף, כפי שמוצג באיור 3. מפתח זה נקרא keyed-hash message authentication code , ומאחר ובגישה זו נדרש מפתח פרטי משותף, הוא חייב להיות מוגן כמו כל מפתח קריפטוגרפי אחר.
כאשר מדובר בנתונים במנוחה (data at rest), ישנם מספר שיקולים. הראשון שבהם – יש לאמת את נתוני התוכנה המאוחסנים, ולעשות זאת בזמן האתחול, נושא אליו אתייחס בהמשך. יש לאמת תמיד נתוני תצורה וכל נתוני מכשירים מאוחסנים, לפני עיבודם על ידי מכשיר IoT. ניתן לבצע בדיקות שלמות נתונים תקופתיות במהלך הפעילות, ותמיד בעת הפעלה וכן בכיבוי.
בדיקות שלמות צריכות להתבצע גם עבור נתונים הנמצאים בעיבוד, כדי להבטיח שניתן יהיה לבטוח בנתונים ובתהליך שלהם. שימוש בערכי מיספור ורישום ייחודיים עבור התוכנה, יבטיח כי ממשקי תכנות יישומים ייקראו עם פרמטרים ייחודיים רק ל-API ספציפי.
אימות תהליך האתחול יכול להתפצל לשני חלקים נפרדים, כפי שמודגם באיור 4. תחילה, תהליך אתחול מאובטח מופעל על ידי הפלטפורמה האמינה שקובעת את האותנטיות של קבצי המקור. תהליך האימות מוטמע באופן הטוב ביותר בשימוש בחתימה דיגיטלית, המשלבות שימוש בפלט הודעה של פונקציית hash, יחד עם הצפנת מפתח-פרטי אסימטרי של פונקציית hash על ידי המחבר. החתימה הדיגיטלית מאומתת באמצעות חישוב מחדש של הודעת ה- hash, פענוח החתימה הדיגיטלית המשויכת עם המפתח הציבורי, והשוואה של הודעות המסרים. אם אלה תואמות, אזי שלמות התוכנה מאומתת.
השלב השני בתהליך האתחול הוא ‘אתחול אמין’, בו יתר קבצי המקור והנתונים מאומתים על ידי התוכנה שאומתה לפני כן. טוב ביותר אם תהליך האתחול יכלול חומרה שתבצע את עיבוד אימות השלמות, מכיוון שהתכונות הבלתי ניתנות לשינוי של חומרה (בין אם מעבד מערכת – SoC, או מערך שערים – FPGA), ממזערות את הסיכון של שינוי זדוני שיביא לחדירה בעיבוד שאתחולו אומת. התהליך אימות רב שלבי “שרשרת אמון” (איור 5). גישת שרשרת האמון מבטיחה כי רק תוכנה מאומתת תוטען אל המערכת.
אם למכשיר IoT יש קישוריות אינטרנט אמינה בחיבור קבוע, ניתן להשתמש באימות מרחוק כדי לדווח ולאמת פרמטרים מרכזיים של אתחול, במהלך שלבי אתחול מאובטח ואתחול אמין, אל שרת פיזי נפרד. פרמטרים אלה הם בדרך כלל hash של הרכיבים של תהליך האתחול (טוען-אתחול, אפליקציות וכו’). השרת משווה מדדים אלה וקובע את האמינות של מכשיר ה-IoT. שידור המדידות מאובטח, וחייב לכלול את זהות מכשיר ה- IoT.
שכבה נוספת של הגנות
כל מכשיר המקושר לאינטרנט נמצא בסיכון, ומכשירי IoT אינם חריגים. אספקת שכבה נוספת של הגנות על שלמות הנתונים, באה ברמת AAA (triple A) – אימות (Authentication) הרשאה (Authorization), ובקרה (Accounting). תפקידה לקבוע עם אילו מכשירים אחרים ברשת, המכשיר יכול לתקשר, ואילו נתונים ניתן להעביר. גורם אמין נדרש כדי לתווך את התקשורת בין מכשיר ה-IoT ומכשיר או שרת מרוחק. ניתן להשתמש בפרוטוקול נפוץ הנקרא Kerberos כדי לבסס אמון זה בין מכשירים על גבי הרשת.
בעקבות האימות, מתבצעת הרשאה. הרשאה היא קביעת סוג הגישה שמותרת למשאב בתוך הרשת. מדיניות אבטחה כלל-רשתית משמשת לרישום המשאבים הקיימים, נתיבי התקשורת מתוך ואל כל משאב, ובאיזו רמה ניתן להרשות גישה.
הרכיב האחרון של AAA הוא הבקרה: יצירת יומן אירועים (log), אשר מסמן פעילויות הקשורות לאבטחה על מכשיר ה- IoT ובאמצעותו. ניתן לאחסן יומני אירועים בתוך מכשיר ה- IoT, או בדרך כלל בשרת חיצוני. מדיניות האבטחה תקבע אילו אירועים דורשים רישום. סקירה של הרישומים והמידע הקשור אליהם, תסייע לקבוע מה הוביל להתקפה, מהיכן היא הגיעה, ומה קרה במהלכה. טוב ביותר כי אירועים אלה יתועדו קרוב ככל הניתן לזמן אמת, כדי למזער את הנזק מהתקפה באמצעות הפעלת תגובה שהוגדרה במדיניות האבטחה.
בגלל המספר הגדול של מכשירי IoT אותם יש בדרך כלל לנטר, יחד עם המספר הרב של אירועים שצריך לנתח ולנהל, נדרש שרת ייעודי. סוג זה של שרת נקרא שרת נתוני אבטחה וניהול אירועים (SIEM). שרת SIEM מסוגל לבצע התאמה בין הודעות אירועי אבטחה ממכשירי IoT, ולהשתמש ב- predictive analytics כדי לקבוע אם מכשיר IoT הינו בסיכון של התקפה.
לסיכום, כדי להרוויח מהפוטנציאל העצום של מכשירי IoT מקושרים, יש צורך בגישה קפדנית ואמינה לאבטחה. ה- CIA triad מספק מודל פשוט מאוד ונוח לגילוי וייצוג של צרכי אבטחת מידע של מכשירי IoT. שמירה על שלמות נתונים היא ללא ספק אחד הרכיבים המרכזיים של הטמעת מדיניות אבטחה, ואותם שיקולים וגישה יש לבצע עבור סודיות וזמינות.
