כאשר מתגלה פגיעות קריטית ב-Apache, הסיכון הגדול ביותר הוא לא רק ניצול הפגיעות עצמו, אלא גם תגובה מאוחרת וחסרת תיאום. צוותים שפועלים לפי סדר פעולה ברור לרוב מגבילים את ההשפעה ומשחיזים את ההתאוששות במהירות רבה יותר.
שלב 1: להכיל את החשיפה מיד
התחילו בזיהוי מחשבים הנגישים מהאינטרנט שמריצים גרסאות פגיעות. אם לא ניתן לתקן מיד, צמצמו את החשיפה באמצעות אמצעי בקרה זמניים: כללי WAF נוקשים יותר, טווחי גישה מצומצמים, והשבתת פונקציות אופציונליות כאשר אפשרי.
- צור מלאי של מופעי Apache המושפעים בכל הסביבות.
- תן עדיפות למערכות ייצור המטפלות באימות, בתהליך התשלום או בנתוני לקוחות.
- החילו אמצעים להפחתת סיכון חירום לפני פריסה מלאה של התיקון אם חלונות התחזוקה מתעכבים.
שלב 2: תיקון עם אימות, לא הנחות
הפעלת עדכון חבילה היא רק חצי מהעבודה. ודא שקובץ הבינארי שרץ תואם לגרסה המתוקנת, שמודולים תלויים עדיין נטענים נכון, ושהאירוח הווירטואלי מתנהג כפי שמצופה תחת דפוסי תנועה אמיתיים.
- אשר את גרסאות החבילות המעודכנות ואת גרסאות התהליכים הרצים.
- הרץ בדיקות מהירות עבור ניהול משא ומתן TLS, הפניות ונקודות קצה מאומתות.
- בדוק את יומני השגיאות עבור ירידות תאימות של מודולים לאחר ההפעלה מחדש.
שלב 3: חיפוש אחר אינדיקטורים וסיכון שארי
גם אחרי תיקון, אתה צריך עדויות לכך שאין ניצול לפני התיקון. בדוק דפוסי בקשות לא רגילים, כתיבת קבצים חשודה, שינויים בהרשאות והתנהגות רשת יוצאת בזמן חלון החשיפה.
- בדוק יומני גישה/שגיאות סביב זמנים של גילוי ותיקון.
- בדוק את שלמות שורש האינטרנט ואת סטיית התצורה.
- סובבו אישורים שנחשפו אם אי אפשר לשלול פגיעה.
שלב 4: לתקשר ולשפר את זמן התגובה
אירועי אבטחה הם אירועים תפעוליים, לא רק משימות טכניות. עדכן בעלי עניין על מצב התיקונים, הסיכון שנותר ובדיקות הבאות. לאחר מכן ערוך רטרוספקטיבה קצרה כדי להפחית את הזמן הממוצע לתיקון בעתיד.
תגובה גמישה של Apache משלבת הכלה, תיקון מאומת, בדיקות פגיעה, ותקשורת שקופה. יש להתייחס לכל הארבעה כאל זרימת עבודה אחת.
