ככל שהסיכון להפסקות חשמל עולה, מה יכולות חברות לעשות כדי להתמודד עם השפעות אדוות הסייבר כמו פישינג והנדסה חברתית?
מאת קייט או'פלאהרטי
באוקטובר, אמזון שירותי אינטרנט (AWS) נפגעה מאחת מה... הפסקות הגדולות ביותר בשנים. בעוד שההפסקה עצמה גרמה לשיבושים משמעותיים, היא הובילה ל אזהרות שהיריבים ביצעו מתקפות סייבר כדי לנצל את הכאוס במהלך האירוע.
הפסקות החשמל הגיעו במהירות ובצפיפות במהלך שני החודשים האחרונים. Azure של מיקרוסופט היה הבא בתור לחוות אחת, שבוע בלבד לאחר AWS. לאחר מכן, בנובמבר, ספקית התשתיות Cloudflare ספגה מכה קשה הפסקת ששיתק מספר אתרים ואפליקציות, מה שנתן לתוקפים יותר הזדמנויות לתקוף.
הפסקת הרשת של AWS ואחרות מאז מראות כיצד שיבושים אצל ספקים יכולים להתגלגל במהירות לסיכונים הפונים ללקוחות, כגון פישינג והנדסה חברתית. ככל שהסיכון להפסקות עולה, מה יכולות חברות לעשות כדי להתמודד עם איום זה?
תוקפים מנצלים בלבול
הפסקות חשמל מושכות פושעי סייבר משום שהן יוצרות בלבול בקרב משתמשים וארגונים, אותו הם יכולים למנף למתקפות. עבור משתמשי הקצה, הפסקות חשמל הן "מבלבלות, ללא תשובות מיידיות", מציין ריצ'רד ג'ונס, סגן נשיא צפון אירופה ב-Confluent.
סביבה זו מאפשרת לפושעי סייבר לשגשג, תוך ניצול הקורבנות ואת רצונם לתשובות, הוא אומר. "אם אתם עובדים בבנק עם ארגון שמסתמך על AWS עבור האפליקציה שלו, ואתם לא יודעים מדוע חשבונכם הנוכחי אינו נגיש פתאום, סביר הרבה יותר שתיפלו להונאת פישינג שתבקש את הפרטים שלכם."
במהלך הפסקת פעילות AWS באוקטובר 2025, פושעים החלו במהירות להתחזות ל-AWS ופגעו בשירותים, תוך שליחת מיילים והודעות טקסט המבטיחים "לשחזר את הגישה" או "לפצות על זמן השבתה", מספר ברוס ג'נקינס, מנהל מערכות מידע בבלאק דאק. IO.
לאחר הפסקת חשמל, ארגונים נוטים להיות מטרה לקבלת מיילים הונאה הטוענים שהם מספק ענן או צוות תמיכת IT, אומר רוס ברואר, סגן נשיא Graylog EMEA. מיילים אלה ידחקו במשתמשים "לאמת מחדש את החשבון שלהם כעת", או "להוריד תיקון דחוף" כאשר השירות הלגיטימי נפגע.
"הונאות ממוקדות דחיפות" אלו משתמשות במיתוג משכנע ובכתובות מזויפות, תוך ניצול חרדות המשתמשים ורצונם לפתרונות מהירים, אומר ג'נקינס. "דפוסים דומים נצפו בשנת 2021 פייסבוק ו תכלת הפסקות תקשורת, שבהן תוקפים שלחו הודעות תמיכה או הנחיות שחזור חשבון מזויפות."
בנוסף לבעיה, הכאוס של הפסקת חשמל יכול להחמיר על ידי צוותי IT, אשר עלולים להחליש בשוגג את ההגנות בבהלה לשיקום השירותים. דבר זה עלול לגרום להם להשבית בקרות אבטחה או להרחיב הרשאות, אומר ג'נקינס.
נראות שרשרת האספקה וניהול תלות
ככל שהסיכוי להפסקות חשמל גדל, ארגונים חייבים כעת להתכונן לאפקט הגל שעלול להתרחש כאשר צד שלישי מהימן קורס.
כדי למנוע מתוקפים לנצל זאת, ארגונים זקוקים לנראות חזקה לגבי הפעולות שלהם שרשרת אספקה ותלות בענן. משמעות הדבר היא "מיפוי השירותים הקריטיים, ידיעת אזור ענן המכיל אותם וזיהוי נקודות כשל בודדות", לדברי ברואר.
שמירה על מפת תלות מעודכנת וביצוע תרגילי תרחישים, כולל שאילת שאלות כגון "מה אם פלטפורמת הענן העיקרית שלנו תיכשל?", הן חיוניות וצריכות להיות חלק מהעסק של הארגון. תוכנית חוסן, מייעץ ג'נקינס.
בניית יתירות, כגון ארכיטקטורות מרובות עננים או מרובות אזורים, יכולה להפחית סיכונים, אך לא כל עומס עבודה דורש זאת, אומר ג'נקינס. "חוזים צריכים לכלול הסכמי רמת שירות (SLA) ברורים ודרישות מגירה, והספקים צריכים להיות מדורגים לפי קריטיות."
תקשורת ברורה ובזמן
אם שירות שפוגע בך משפיע עליך, תקשורת ברורה ובזמן חיונית כדי למנוע מיריבים לנצל את בלבול המשתמשים כדי לתזמן התקפות.
במהלך הפסקת פעילות AWS, נראה כי עדכוני סטטוס ראשוניים פיגרו בדיווחי המשתמשים. לקוחות ארגוניים רבים מצאו את המידע "דליל וגנרי", אומר ג'נקינס. "בעוד ש-AWS פרסמה בסופו של דבר מידע מפורט שלאחר המוות "והתנצלות, היעדר העדכונים המהירים והשקיפים בשלב האקוטי הותיר חלל ריק שהתמלא בספקולציות וניסיונות פישינג."
למרות שזה יכול להיות מאתגר, הנוהג הטוב ביותר הוא להכיר בבעיות מוקדם, לספק עדכונים עובדתיים שוטפים ולהציע הנחיות בטיחות, הוא אומר. "השקיפות של AWS לאחר התקרית זכתה לשבחים, אך התקשורת בזמן אמת במהלך ההפסקה הייתה יכולה להשתפר."
עם זאת, עבור ספק הענן וארגון הלקוח, תקשורת יכולה להיות קשה במהלך הפסקת חשמל עקב חוסר הוודאות הכרוכה בכך. "מצד אחד אתם רוצים לשתף כמה שיותר מידע, אך מצד שני אתם לא רוצים להטעות את הלקוחות על ידי מתן מידע שמתברר כלא נכון ככל שהמצב מתפתח", אומר ג'יימס קרצ'מר, סגן נשיא מנהל הטכנולוגיה הראשי של קבוצת טכנולוגיית הענן ב-Akamai Technologies. "זה יכול להיות איזון קשה למצוא".
עם זאת, שקיפות היא קריטית, אומר קרצ'מר: "זה שומר על הלקוחות מעודכנים ומפחית את הסיכוי של תוקפים לנצל את אי הוודאות. אפילו הודעה פשוטה שאומרת 'אנחנו מודעים לבעיה, הנה מה מושפע והיכן ניתן לקבל עדכונים מאומתים' יכולה למנוע פאניקה ולעצור את התפשטות התראות מזויפות. המטרה היא לתקשר לעתים קרובות, גם כשאין לכם את כל התשובות."
ניהול תקין וניהול סיכונים
תקרית AWS וההשפעה המדורגת מדגישות גם את היסודות של ניהול תקין וניהול סיכונים. הפסקות ענן בוחנות את היסודות הללו, אומר ג'נקינס. "האחריות לסיכונים של צד שלישי חייבת להיות ברמת ההנהלה והדירקטוריון, עם בעלות ברורה על אסטרטגיות סיכוני ענן."
כחלק מתכנון מגירה חזק והסדרי המשכיות עסקית חיוניים, כולל תוכניות מפורשות להפסקות חשמל של ספקים ובדיקות תרחישים סדירות, אומר ג'נקינס.
"תהליך ניהול אירועים חזק" מבטיח תגובה יעילה לבעיות, אומר קרצ'מר. תהליך זה צריך לכלול "ספי הסלמה מוגדרים, קווי תקשורת ברורים וסדרי עבודה שנבדקו היטב", הוא מייעץ.
מסגרות רגולטוריות כגון חוק חוסן תפעולי דיגיטלי, מערכות רשת ומידע 2 ו ISO 27036 יכולים לעזור. אלה מזהים את הסיכונים על ידי חיוב חוסן תפעולי חזק יותר וניהול סיכוני ספקים, לדברי סיימון פמפלין, מנהל הטכנולוגיה הראשי ב-Certes. "בליבתם, הם מצפים לאבטחה מתמשכת, תכנון מגירה ויכולת להוכיח שאתם יכולים לעמוד בפני שיבוש משמעותי מצד צד שלישי."
בינתיים, ISO / IEC 27001 מטמיע אבטחת ספקים, המשכיות עסקית וניהול אירועים במערכות ניהול אבטחת מידע, אומר ג'נקינס.
היערכות להפסקות חשמל עתידיות
ככל ששירותים דיגיטליים הופכים להיות מחוברים יותר ויותר ותלויים בספקי ענן גדולים, הפסקות שירות יישארו בלתי נמנעות. משמעות הדבר היא שתוקפים ינצלו יותר ויותר רגעים של כשל מערכתי, אומר ברואר.
בהתחשב בכך, על מנהלי IT למפות תלויות, לבנות יתירות עבור שירותים קריטיים ולתרגל באופן קבוע תוכניות מגירה, אומר ג'נקינס. "תוכניות תקשורת למשברים חייבות להיות מוכנות, עם תבניות העברת הודעות ברורות וערוצי תקשורת מחוץ לטווח. הניטור צריך להשתמש במקורות מרובים, וחוזי ספקים צריכים לכלול התחייבויות לחוסן."
במקביל, אסור להקריב אבטחה לטובת מהירות במהלך הפסקות חשמל, מזהיר ג'נקינס. "יש לוודא ששינויים דחופים נרשמים ונבדקים. חינוך המשתמשים חייב לכסות הונאות הקשורות להפסקות חשמל, וניתוח לאחר אירוע צריך להניע שיפור מתמיד."
