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

מגן מרגלית, סמנכ"ל דיגיטל בקבוצת CodeValue

ביום שישי (19/7/24), חווה העולם תקלה שונה מכל תקלת טכנולוגית שקדמה לה. כל כך חריגה כך שניתן לומר שהיא מהסוג שמשנה תעשיות וארגונים. עד היום היינו מורגלים בכך שתקלות מתרחשות בתוך ארגון ושההשפעה של תקלה כזו, גם אם היא חריגה בעוצמתה ובאופן ההשפעה שלה על העולם (כדוגמת פייסבוק , וואטסאפ וכ'...) היא עדיין תקלה מקומית, שמוגבלת לשירות כזה או אחר, ומגבילה אם בכלל באופן חלקי את אורח החיים של בני האדם. התקלה ביום שישי האחרון, יצרה השפעה רחבה על ארגונים בכל העולם מחברות ושדות תעופה, מוסדות בריאות, מוסדות פיננסים, שירותי ממשלה, עסקים שונים, ארגונים בטחוניים וכו.. וגרמה לשיבושים נרחבים באורח החיים של אנשים.

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

התחום שבו אנו עוסקים בעולם הטכנולוגיה נקרא – EDR – EndPoint Detection & Response,

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

חברת CrowdStrike הינה אחת מהיצרניות המובילות של פלטפורמה למתן פתרונות בתחום ה-EDR. החברה מקורה באוסטין טקסס, היא מעסיקה כ-8000 עובדים ברחבי העולם ושוויה (לפחות עד יום שישי האחרון) עמד על כ-80 מיליארד דולר. הפלטפורמה עצמה מתמקדת בעמדות קצה (שרתים, תחנות עבודה וכ'...) מבוססי מערכת ההפעלה הנפוצה בעולם ,Windows מבית מייקרוסופט. בלילה שבין חמישי לשישי הופץ עדכון תוכנה לחיישן Falcon שהינו אחד הפתרונות שהחברה מספקת ללקוחותיה. העדכון שהיה תקול, גרם לכך שלאחר אתחול של ציודי קצה שבהם הוכנס העדכון, התקבל Blue Screen והשרת /תחנת העבודה לא השלימו את התהליך העלייה.

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

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

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

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

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

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

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

שאלות? הערות ? מעניין?

אפשר לפנות אלי ישירות: MagenM@codevalue.com

‍