הבקרות הן רק ההתחלה. העבודה היא לתפעל אותן.

אבטחת דואר נכנס

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

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

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

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

דיווח ותגובה לפישינג

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

החקירה עצמה היא פורנזיקה של שכבת הדואר. כותרות ההודעה, ומה ש-SPF, ‏DKIM, ‏DMARC ו-ARC באמת אמרו, ולא אם הופיע סימן ירוק. קישורים, כולל היכן ששרשרת ההפניות נוחתת בסוף. התנהגות הקובץ המצורף. ‏Reply-To, שולח המעטפה והתשתית ששלחה את ההודעה. תוצאות אימות הן ראיה על הרשאה, לא על כוונה, והודעת פישינג בנויה היטב יכולה לעבור אימות תקין מדומיין ששייך למי שאין סיבה לתת בו אמון.

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

מודעות לפישינג

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

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

DLP ובקרות תוכן ליוצא

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

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

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

תפעול ותחזוקה של אבטחת הדואר

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

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