521 - Evaluating risk with Marina from Cyera

רן ואורי מארחים את מרינה גנדלין, Data Scientist ו-Team Lead מחברת Cyera (סיירה), לשיחה על סייבר, דאטה, ואיך מעריכים סיכונים בעזרת מודלי שפה (LLMs). מרינה חולקת תובנות מרתקות מהפרויקט הראשון שהובילה בחברה להתמודדות עם עומס ההתראות (ניתן לצפות במצגת המקורית מתוך ההרצאה, וכן בוידאו של 17 דקות מאותו כנס).

[00:00] היכרות עם מרינה, Cyera וכנס רברסים

• תזכורת: כנס רברסים 2026 מתקרב! יתקיים ב-30 בנובמבר וב-1 בדצמבר. שווה להירשם.
• היכרות עם מרינה: מגיעה מרקע של עשור ב-AI ומערכות המלצה בחברות כמו טאבולה ו-ZipRecruiter, וכיום עובדת בסיירה.
• סיירה - “Where data meets cyber security”: חברה שעושה מיפוי מלא של דאטה ארגוני, סורקת קבצים, דאטה-בייסים, Jira, GitHub ועוד בסקייל עצום, כדי למצוא איפה מסתתר מידע רגיש.
  • האתגר הנוכחי: פריצה לעולם ה-AI Security והגנה מפני מצבים שבהם סוכנים (Agents) או מודלים ניגשים למידע שאסור להם.

[07:33] אתגר עומס ההתראות והמוצר (The Product)

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

[09:53] כשאין “אמת מוחלטת” (Ground Truth)

• המעבר מגישת Data Science קלאסית (למשל אימון XGBoost) למציאות מורכבת: אין “אמת מוחלטת” אחידה לכולם.
  • חומרת אירוע משתנה מלקוח ללקוח – מה שמסוכן ליצרן מזון (דליפת פוליסה) לא בהכרח יזיז למנכ”ל של בנק ענק עם 100,000 עובדים.
• רגע של “Let’s go anyway!”: יציאה מהירה לשטח עם לקוחות ראשונים.
  • נתנו ל-LLM בסביבה פרטית (On-premise deployment) את כל הקונטקסט כדי שיקבע את רמת החומרה ובעיקר - ייצר הסבר גנרטיבי ללקוח למה הוא בחר בה.
  • הלקוחות התאהבו בקונטקסט ובהסבר, והיו סלחניים כל עוד לא נעשתה טעות גסה.

[16:05] חיפוש אחר מטריקה ואופטימיזציית עלויות (COST)

• הבנה שאי אפשר להשתמש במטריקות הקלאסיות של מערכות המלצה (כמו NDCG), אלא פשוט להתמקד ב-Precision של ההתראות החמורות ביותר (Critical ו-High). הלקוח לא רוצה לבזבז זמן על False Positives.
• העלות: הרצת כל כרטיס אשראי בטקסט חופשי דרך LLM יקר (כמו Gemini Flash) יצרה עומס אדיר עלויות (Tokens).
  • נוצר צורך דחוף בהורדת עלויות, מה שחייב מעבר למודלים זולים יותר והקמת מערך Evaluation (הערכה) מסודר.

[17:56] אתגר ההערכה (Evaluation Challenge)

• שלב 1: יצירת Evaluation set גנרי מדי לא באמת עובדת, ודורשת המון עבודה ידנית של מומחי דומיין.
• שלב 2: ההתמודדות עם חוסר דטרמיניזם.
  • מודלים גנרטיביים (גם בטמפרטורה 0) משנים את התשובות שלהם והסיווגים שלהם בכ-20% מהמקרים כשמריצים אותם שוב.
  • הפתרון: שימוש במודל חזק כדי לרוץ כמה פעמים על אותו דאטה, ולקיחת תת-הקבוצה שבה המודל הסכים עם עצמו בצורה רובסטית כדי לייצר סט בדיקה יציב. לא נעשה שימוש במספר מודלים שונים לצורך זה.

[21:44] שופט מבוסס מודל שפה (LLM-as-a-Judge)

• שלב 3: כתיבת LLM-as-a-judge כדי להשוות מול המודלים הזולים את איכות ההסבר הגנרטיבי. קל לכתוב את השופט, אבל קשה מאוד לפרש את התוצאות ולהגיע לכיול (Calibration).
  • השופט בדק האם צוין אופי הקובץ, כמות הממצאים והגישות הקיימות.
  • הבעיה: איך מפרשים ממוצעים? מה ההבדל בין ציון 4.2 ל-3.7?
  • הפתרון: הגדרת סף איכות ברור (למשל, כל מה שמקבל ציון מעל 4 נחשב מספיק טוב), והחלטת טרייד-אוף מוצרית שמוכנה להקריב 5% מהאיכות בשביל לחסוך 30% מהעלויות.

[31:21] קסטומיזציה (Customization)

• שלב 4: ה-Pipeline ההנדסי שנבנה מאפשר להחליף בקלות פרומפטים ולהוסיף קונטקסט, מה שאיפשר לתמוך בעשרות פוליסות אבטחה בבת אחת.
• הוספת היכולת ללקוח לייצר חוקים ספציפיים לארגון שלו (למשל, התראה מיוחדת על פורמט של Gift cards שמתחיל במספרים 5 ו-6).

[34:12] פידבק מהשטח (Feedback loop)

• שלב 5: בחינת הפידבק בשטח.
  • 93% מההתראות שדורגו כ-Critical/High אכן טופלו ונסגרו על ידי הלקוחות (Action taken).
  • הפיצ’ר דילל ללקוחות כ-64% מנפח ההתראות המרעישות.
  • פידבק מצוין מ-Design partners שהגדירו את המערכת כ-”Best feature of the year”.

האזנה נעימה!