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

שימרו את המנטרה הזו בהישג יד: אל תנעלו את הדלת לפני שבעטתם את הפולש החוצה.

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

הקצו תפקידים לפני שאתם נוגעים במשהו

• מפקד האירוע (IC): הבעלים של ציר הזמן וההחלטות; מונע מצב שבו "כולם עושים הכל".
• מוביל ניהול זהויות וגישה (IAM): ספק זהויות, הזדהות אחודה, אימות רב-שלבי, איפוסי סיסמה, ביטול אסימונים, חשבונות שירות.
• מוביל פורנזיקה: שימור ראיות, מיון ראשוני (Triage) וקביעת היקף.
• ציד איומים / גילוי: שאילתות למערכת ניהול מידע ואירועי אבטחה (SIEM), מדדי פשרה (IOCs), כוונון חוקים.
• מוביל תקשורת: מול הנהלה בכירה, משפטים ופרטיות, יחסי ציבור, הודעות ללקוחות/שותפים.
• תפעול מערכות מידע / נקודות קצה: הכלה בנקודות קצה, ניהול מכשירים ניידים (MDM), פעולות זיהוי ותגובה בנקודות קצה (EDR).

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

השעה הראשונה (זמן 0 ← דקה 60): להכיל את מה שפעיל, לשמר את מה ששביר

הכלה מיידית (זהות ושיחות)

• יציאה גלובלית (התנתקות) עבור משתמשים/דיירים מושפעים דרך ספק הזהויות/הזדהות אחודה שלכם.
• ביטול אסימוני רענון ופסילת שיחות (עוגיות הפעלה של OAuth, OIDC, SAML) עבור האוכלוסייה החשודה.
• חסימת אימות מיושן/פרוטוקול משרד הדואר/פרוטוקול גישה להודעות אינטרנט/אימות בסיסי באופן זמני (חבילות דוא"ל אוהבות להיות מועילות; אתם לא רוצים את זה).
• אכיפת אימות רב-שלבי מוגבר על סיכון (אימות מחדש באפליקציות רגישות, פעולות אדמין, והעלאת הרשאות).
• הסגר (Quarantine) כניסות בסיכון גבוה (נסיעה בלתי אפשרית, יציאת דפדפן TOR/רשת פרטית מדומה, מספרי מערכת אוטונומית [ASNs] שידועים כרעים) עם גישה מותנית.

שימור ראיות

• תמונת מצב (Snapshot) לנתונים נדיפים: לכידות זיכרון מתוך מערכת זיהוי ותגובה בנקודות קצה (EDR) בנקודות קצה חשודות, ייצוא ממצאים מהדפדפן (עוגיות, אסימונים), רשימות תהליכים מרכזיים.
• נעילת שימור לוגים: ספק זהויות/הזדהות אחודה, רשת פרטית מדומה (VPN), דוא"ל, לוגים של מנהלי תוכנה כשירות (SaaS), ניהול זהויות וגישה בענן, זיהוי ותגובה בנקודות קצה, שרת פרוקסי/מערכת שמות מתחם (DNS).
• השבתת עבודות ניקוי אוטומטי שעלולות למחוק לוגים או לבצע רוטציה אוטומטית בדיוק לממצאים שאתם צריכים.

קביעת היקף מהירה

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

שעות 2–4: החליטו על רדיוס הפגיעה ועצרו את הדימום

קביעת היקף זהות וגישה

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

קביעת היקף נקודות קצה ושיחות

• מתוך מערכת הזיהוי ותגובה בנקודות קצה (EDR), צודו גונבי מידע (שמסבירים כיצד עוגיות ואסימונים יצאו החוצה) ומהלכי שימוש-בכלים-קיימים (כגון RDP, PSExec, WMI).
• אמתו פרופילי דפדפן ששימשו במהלך כניסות חשודות (גניבת אסימונים = זמן לספר הפעלה [חטיפת שיחות]).

שיפורי הכלה

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

רצף איפוס (הסדר קובע)

חשבו על זה כעל בעיטה החוצה ← נעילת דלתות ← החלפת מפתחות ← בדיקת מפתחות רזרביים ← פתיחה מחדש איטית. הרצף מונע משחק "הכה בחפרפרת" ומונע מכם לנעול את עצמכם בחוץ באמצע התגובה.

חיסול גישה פעילה

• יציאה גלובלית (ספק זהויות + תוכנה כשירות מרכזית).
• ביטול אסימוני רענון של OAuth ופסילת עוגיות הפעלה של פרוטוקול SAML.
• כפיית אימות מחדש עבור אפליקציות בעלות הרשאות באופן מיידי.

היגיינת אימות רב-שלבי (MFA)

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

איפוסי סיסמאות אנושיות

• אפסו סיסמאות לאחר שהשיחות מתות.
• רצף: חשבונות חירום ("שבור זכוכית")/מנהלי מערכת ← משתמשים ממוקדים מאוד ← כולם בטבעת המושפעת.

סיסמאות אפליקציה/מורשת

• בצעו רוטציה לסיסמאות אפליקציה/IMAP/POP (אם בשימוש), והשביתו אותן היכן שניתן.

אסימונים ומפתחות מחוץ לספק הזהויות

• אסימוני גישה אישיים (גיטהאב/גיטלאב, ג'ירה וכו'): בטלו והנפיקו מחדש.
• מפתחות ממשק תכנות יישומים (API) וסודות בתוכנה כשירות/ענן: בצעו רוטציה בכספת, לא רק באפליקציה.
• מפתחות גישה לניהול זהויות בענן (AWS/GCP/Azure): בצעו רוטציה למפתחות, קצרו זמני חיים (TTL), והנפיקו מחדש תפקידים עם זכות גישה מינימלית.

חשבונות שירות וזהויות שאינן אנושיות

• בצעו מלאי באמצעות הכספת/מסד נתונים לניהול תצורה (CMDB) שלכם; בצעו רוטציה לסודות; הגבילו כניסה אינטראקטיבית; הצמידו לתפקידים עם זכות גישה מינימלית.
• חתמו מחדש על אמון שירות-לשירות (mTLS/זהות עומס עבודה) אם אתם חושדים בלכידת אישורי גישה במארחים.

אמון מכשירים

• רשמו מחדש נקודות קצה שנפרצו לניהול מכשירים ניידים/זיהוי ותגובה בנקודות קצה, הנפיקו מחדש תעודות מכשיר במידת הצורך; חסמו מכשירים שנכשלים בבדיקות יציבה (Posture checks).

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

שעות 4–8: פורנזיקה שבאמת תשתמשו בה

בנו את ציר הזמן

אימות חשוד ראשון ← הסלמת הרשאות ← נוכחות מתמשכת (Persistence) ← גישה לנתונים/חילוץ נתונים ← טשטוש עקבות.

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

חפשו נוכחות מתמשכת

• מכשירי אימות רב-שלבי חדשים שנוספו, כללי העברת דוא"ל, הסכמות OAuth לאפליקציות חשודות.
• מנהלי מערכת מקומיים חדשים, משימות מתוזמנות, מפתחות הרצה, הרחבות דפדפן עם הרשאות רחבות.
• נוכחות מתמשכת בענן: מפתחות גישה חלופיים, רישומי אפליקציה חדשים/עקרונות שירות (Service Principals), אפליקציות OAuth סוררות.

העריכו חילוץ נתונים (Exfiltration)

• לוגים של מניעת דליפת מידע (DLP)/יציאה עבור קפיצות, יעדים חריגים, או הורדות גדולות מפורטלי ניהול ומאגרי קבצים.
• ביקורת תוכנה כשירות: ייצואים, כללי תיבת דואר, משיכות קוד מקור, הורדות דוחות חיוב.

תעדו מדדי פשרה (IOCs)

• כתובות IP, סוכני משתמש, גיבובי קבצים (Hashes), מזהי אפליקציית OAuth, מזהי אסימוני רענון, מזהי רשת אלחוטית (SSID) חשודים (אם הייתה מעורבת נסיעה).
• שתפו עם הנדסת גילוי ומרכז תפעול האבטחה (SOC) לחסימה/ציד מיידיים.

שעות 8–12: תקשורת (בהירות מנצחת מהירות – בקושי)

בעלי עניין פנימיים

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

חיצוניים

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

כללי זהב לתקשורת

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

שעות 12–24: ייצוב, ניטור והידוק

נטרו כניסה מחדש

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

הקשיחו היכן שזה כואב

• חסלו אימות מיושן שנאלצתם לשמור "בשביל מדפסת אחת" ב-2017.
• חייבו FIDO2 למנהלי מערכת עכשיו; קבעו תאריך לכלל הארגון.
• קצרו זמני חיים (TTLs) של אסימונים והוסיפו אימות מחדש לפעולות רגישות (קונסולות ניהול, דחיפות קוד, ייצואים).

גילויים וספרי הפעלה

• חוקים חדשים עבור: אנומליות בחטיפת שיחות, דיוג הסכמות, תשישות אימות רב-שלבי, הפרות של הגבלת זמן להרשאות.
• אפו ניצחונות מהירים לתוך מערכת ניהול אירועי אבטחה (SIEM)/זיהוי ותגובה מורחבים (XDR) שלכם; צרו פעולות תזמור אבטחה (SOAR) ליציאה גלובלית וביטול אסימונים.

הגדרת תחקיר

• קבעו סקירה ללא האשמות (תוך 72 שעות): מה עבד, מה לא, ואוטומציה אחת שתספקו בספרינט הזה.

פעולות מהירות לפי תחום (כללי, אגנוסטי לספק זהויות)

ספק זהויות (IdP) / הזדהות אחודה (SSO)

• יציאה גלובלית / ביטול אסימוני רענון
• השבתת אימות מיושן/בסיסי
• איפוס גורמי אימות רב-שלבי ודרישת אימות רב-שלבי עמיד בפני דיוג למנהלי מערכת
• סקירת הקצאות תפקידי מנהל; הסרת הרשאות עומדות (Standing privileges)

חבילות תוכנה כשירות (SaaS) (דואר, מסמכים, צ'אט)

• חיסול סיסמאות אפליקציה; חסימת POP/IMAP אם אפשרי
• ביקורת כללי תיבת דואר והעברה חיצונית
• סקירת מענקי אפליקציית OAuth; השבתת הסכמת משתמש באופן זמני

בקרת גרסאות / פלטפורמות פיתוח

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

ספקי ענן

• רוטציה למפתחות גישה; פסילת אישורי גישה ארוכי טווח
• סקירת הנחות תפקיד (Role assumptions) ויצירת נתיבי ניהול בדיוק בזמן (JIT)
• הפעלה/הרחבה של גישה מותנית ובדיקות יציבת מכשיר

נקודות קצה

• לכידת זיכרון במארחים חשודים; ייצוא ממצאי דפדפן
• בידוד, רישום מחדש, והנפקה מחדש של תעודות מכשיר במידת הצורך

שאילתות ואותות (רשימת התחלה)

• כניסות ספק זהויות לפי הבדלי IP/סוכן משתמש/מיקום גיאוגרפי עבור משתמשים מושפעים (30 יום אחרונים).
• אירועי אימות רב-שלבי: רישומי מכשיר חדשים, שינויי גורמים, שימוש בהשבתה/שחזור.
• הסכמות OAuth: מענקים חדשים, במיוחד לטווחים בסיכון גבוה (דואר, קבצים, אנשי קשר).
• לוגים של מנהלי תוכנה כשירות: ייצואים, שינויי תפקיד, כללי תיבת דואר, יצירת קישורים משותפים.
• טלמטריה של זיהוי ותגובה בנקודות קצה (EDR): גניבת אסימוני דפדפן, גישה למנהל אישורי הגישה, קבצים בינאריים לגיטימיים המשמשים לתקיפה (LOLBins) (כגון rundll32, regsvr32, פאוורשל עם פקודות מקודדות).

10 המלכודות המובילות (כדי שלא תככבו בניתוח שלאחר המוות של מישהו אחר)

1. איפוס סיסמאות לפני הריגת שיחות. הרגע נתתם לתוקף התראה מוקדמת.
2. שכחה מאסימוני OAuth/אסימוני רענון. הם חיים יותר מסיסמאות על פי תכנון.
3. השארת סיסמאות אפליקציה פעילות. IMAP/POP הם "ממתק לתוקפים".
4. התעלמות מחשבונות שירות. זהויות שאינן אנושיות מחזיקות לעיתים קרובות במפתחות האמיתיים.
5. אי-בדיקת רישומי אימות רב-שלבי. תוקפים אוהבים להוסיף את המכשיר שלהם.
6. הנחה ש"במקום (On-prem) נראה נקי" = "תוכנה כשירות (SaaS) נקייה". לוגים שונים, בעיות שונות.
7. דילוג על יציבת מכשיר. נקודות קצה שנפרצו גונבות מחדש אסימונים אחרי האיפוס הגדול שלכם.
8. רוטציה לסודות בתוך האפליקציה, לא בכספת. עותקי צל יבגדו בכם.
9. לתת לתקשורת להתפצל. השלמת פערים על ידי שמועות היא אף פעם לא חברה שלכם.
10. הפעלה מחדש של אימות מיושן "באופן זמני". ספוילר: זה לא יהיה זמני.

קשירות לערימת הבקרה שלכם

• חטיפת שיחות (גניבת אסימונים): ודאו שהיציאה הגלובלית/ביטול האסימונים שלכם הם במרחק קליק אחד; הוסיפו התרעות לדפוסי שימוש חוזר בעוגיות.
• דיוג ודיוג קולי: אשרו מראש דומיינים לקישורי כניסה; השתמשו בבאנרים והסרת פרוקסי עבור חשד לאדם-בתווך (AitM).
• הרחבות זדוניות / אפליקציות טרויאניות: רשימות היתר להרחבות דפדפן; פרופילי ניהול מכשירים ניידים (MDM) שחוסמים טעינת צד.
• ריסוס סיסמאות ופיצוח בכוח גס: נעילות חכמות, מוניטין IP, ואתגרים מבוססי סיכון.
• החלפת כרטיס סים / SS7: הוציאו משימוש מסרונים (SMS) עבור מנהלי מערכת; תעדפו פריסות FIDO.

המילה האחרונה (לעת עתה)

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

אחרי זה? הפכו את ספר ההפעלה לכפתורים. התגובה לאירועים (IR) הטובה ביותר היא מהסוג של קליק אחד.