שיטות עבודה מומלצות לאבטחת סייבר ברשתות OT ו-SCADA

ההתכנסות של עולם ה-IT עם עולם ה-OT יצרה מציאות חדשה: משטחי תקיפה שכלי אבטחה רגילים מעולם לא תוכננו להתמודד איתם. מערכות SCADA, בקרי PLC ובקרים תעשייתיים נבנו לרשתות סגורות, בתקופה שבה ההפרדה הפיזית הייתה מודל האבטחה. ברגע שחיברו אותם לרשת הארגונית נפתחו סיכונים שדורשים גישת הגנה מסוג אחר.

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

פילוח רשת הוא עדיין קו ההגנה הראשון

פילוח רשת נשאר הבקרה עם התשואה הגבוהה ביותר. ארכיטקטורת Purdue Model עם אזורים מפורזים (DMZ) ברורים בין שכבות ה-IT ל-OT מונעת התפשטות לרוחב: תוקף שהשתלט על תחנת עבודה ברשת העסקית לא אמור למצוא מסלול מנותב אל בקר. חומות אש תעשייתיות ושערים חד-כיווניים מאפשרים לנתונים לזרום מה-OT ל-IT לצורכי ניטור ושכפול היסטוריאן, בזמן שהכיוון ההפוך מסונן בהדוקות או פשוט בלתי אפשרי פיזית.

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

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

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

IEC 62443 כמסגרת עבודה

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

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

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

ניטור תעבורת OT הוא לא ניטור תעבורת IT

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

מערכות IDS ייעודיות ל-OT יודעות לאתר חריגות בפרוטוקולים כמו Modbus, DNP3 ו-BACnet שכלים גנריים בכלל לא מפענחים. הרעיון פשוט: מגדירים התנהגות בסיסית לכל בקר, וכל סטייה מפעילה התראה. קוד פונקציה לא צפוי, כתיבה לרגיסטר שבדרך כלל רק קוראים ממנו, תחנת הנדסה חדשה שצצה על המקטע.

הניטור חייב להיות פסיבי. כלי סריקה אקטיביים שהם שגרה ב-IT מסוגלים להפיל PLC ותיק, פשוט מפני שמחסנית הרשת שלו מעולם לא נבנתה לספוג סריקת פורטים אגרסיבית. השתמשו ב-TAP או בפורט SPAN וקראו את התעבורה, אבל אל תתשאלו את הבקרים.

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

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

נהלו מצאי נכסים מדויק: אי אפשר להגן על בקרים שאתם לא יודעים שקיימים
בטלו סיסמאות משותפות וברירת מחדל, בעיקר ב-HMI ובתחנות הנדסה
אכפו אימות רב-שלבי על כל מסלול גישה מרחוק אל רשת ה-OT
שלטו במדיה נשלפת; USB עדיין וקטור הדבקה חי גם במתקנים מנותקים
החזיקו גיבויים מנותקי רשת ובדוקים של לוגיקת הבקרים ותצורת ה-HMI, לא רק של שרתים
היכן שעדכון בלתי אפשרי, רשמו בכתב את הבקרה המפצה ואת קבלת הסיכון

תגובה לאירוע תחת אילוצים תפעוליים

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

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

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