היעד הוא הפעולה העסקית
הודעה שנחזית לספק יכולה לבקש לעדכן פרטי חשבון לפני תשלום חשבונית. הודעה שנחזית למנהל יכולה לבקש רכישה דחופה או מידע רגיש. המשותף הוא ניסיון לעקוף את דרך האישור הרגילה באמצעות אמון או לחץ.
זו דוגמה מושגית ולא מקרה לקוח. גם כאשר שם הספק, מספר החשבונית והסכום נכונים, עדיין צריך לאמת בקשה שמשנה את דרך התשלום.
מה ההבדל מפישינג רגיל ומפריצה לתיבה
פישינג הוא מונח רחב לניסיון הטעיה. BEC מתמקד בהקשר עסקי ובניצול תהליך או קשר עבודה. השתלטות על תיבה יכולה לאפשר הונאה משכנעת, אבל לא כל ניסיון BEC דורש פריצה לתיבה של העסק.
תוצאת SPF, DKIM או DMARC תקינה אינה אישור להעברת כסף. היא אינה יודעת אם העובד שהחזיק בחשבון אישר את הבקשה או אם התיבה נפלה לידי גורם אחר.
איך מאמתים שינוי רגיש
FBI ו-IC3 ממליצים לאמת שינוי פרטי חשבון בערוץ נוסף. מסגרת העבודה הבאה משלבת זאת עם תיעוד והפרדת אחריות בעסק.
| שלב | בדיקה |
|---|---|
| עצירה | לא לשנות את פרטי התשלום רק על סמך ההודעה |
| אימות | לפנות לאיש קשר דרך מספר שנשמר קודם, ולא מספר שנוסף להודעה |
| אישור | לקבל אישור מבעל הסמכות לפי נוהל העסק; בסיכון מתאים גם אישור נוסף |
| תיעוד | לרשום מי בדק, מול מי, מתי ומה אושר |
| ביצוע | לעדכן רק לאחר סיום הבדיקות, בלי לעקוף אותן בגלל דחיפות |
אם הבקשה כבר בוצעה
אם הועבר תשלום בעקבות חשד להונאה, פנו מיד לבנק או לספק התשלום דרך הערוץ הרשמי ולבעל האחריות בעסק. האפשרות לעצור או להשיב כסף תלויה במקרה; אין הבטחה לכך. שמרו את פרטי הפעולה וההתכתבות לצורך בירור.
במקביל בודקים אם נפרצה תיבה: כניסות, כללי העברה, הרשאות יישומים וחיבורים פעילים. גם אם זו רק התחזות חיצונית, יש לתעד את הדרך שבה התהליך העסקי נעקף.
איזה חלק אפשר לשפר טכנית
הגדרת אימות דומיין, MFA וביקורת הרשאות מסייעות לצמצם סיכונים מסוימים. הן אינן מחליפות אימות אנושי של שינוי תשלום. נדרש קשר בין האחראי על הדואר לבין מי שמאשר ספקים וחשבוניות.
בבדיקה טכנית מגדירים מראש אילו חשבונות ותהליכים נכללים, אילו לוגים זמינים ומי מוסמך לקבל החלטות. אין צורך לשלוח מסמכי בנק או נתוני לקוחות בפנייה הראשונית ל-CyberFixCrew.