 |
Author: Ran Tavory && Ori Lahav Language: he Genres: Technology Contact email: Get it Feed URL: Get it iTunes ID: Get it |
Listen Now...
511 AI Protection and Governance with Nimrod from BigID
Sunday, 25 January, 2026
פרק מספר 511 של רברס עם פלטפורמה, שהוקלט ב-18 בינואר 2026. אורי ורן מקליטים בכרכור (הגשומה והקרה) ומארחים את נמרוד וקס - CPO ו-Co-Founder של BigID - שחצה את כביש 6 בגשם זלעפות כדי לדבר על אתגרים טכנולוגיים בעולם המופלא של Data Production ו-Security. 🎗️[00:38] נמרוד, BigID ולמה אנחנו צריכים קטלוג ל-Data?נמרוד - אחד מה-Co-Founders של BigID, ש”עוזרת לארגונים להבין את ה-Data שלהם”.האתגר המרכזי של ארגונים היום הוא שהם אוספים אינסוף מידע (על לקוחות, עובדים, שוק), אבל מתקשים בשלושה דברים עיקריים: להגן עליו, לעמוד ברגולציות (פרטיות), ולהפיק ממנו ערך (למשל לטובת AI).הפתרון של BigID: בניית קטלוג של כל המידע בארגון.סריקת כל המערכות: Unstructured, Structured, Big Data, Cloud Storage, Business Applications . . . וגם אספקטים של Data at Rest & In Motion: מציאת המידע “איפה שהוא לא נמצא”.החברה עושה קלסיפיקציה (Classification) של המידע - שכבה סמנטית של ה-Metadata, ולא רק סמנטיקה: המערכת ממפה את ה-Metadata העסקי (“למה המידע משמש?”), האופרטיבי (“מי ה-Owner? למי יש גישה?”) והטכני.כולל Contextual Metadata - עמודות, שורות, Foreign Keys . . . לחברה יש גם את היכולת לייצר קורלציה ל-Data Subject – כלומר, להבין למי המידע שייך (לאיזה אדם ספציפי הוא מתייחס), שזה הבסיס לעולמות הפרטיות (כמו "הזכות להישכח").מעל הקטלוג הזה, BigID מנגישה אפליקציות - להגן על המידע - Data Access, Governance, Monitoring, Control.כולל היבטים של רגולציה בהגנה על המידע, בעיקר סביב Privacy Management.היום יש גם הרבה אספקטים של רגולציה סביב AI - ואיך להפיק ערך מהמידע הזה.הייחוד של החברה בעולמות ה-AI הוא היכולת לייצר קטלוג של Unstructured Data - שזה היום המקור המרכזי של AI.אם פעם אנשים היו מסתכלים על ה-Snowflake או על ה-Databricks שלהם כדי לעשות אנליזה למידע - היום הם מסתכלים על ה-OneDriveגם כדי למצוא את המידע שהם רוצים - וגם כדי למחוק את המידע שהם לא רוצים.רן - “אם פעם פיצ’רים היו בתוך עמודות ב-Database, היום אני מסתכל פשוט על Unstructured Text” . . . .החברה מאפשרת Secure pipelines ל-AI, ופיצ’רים של Security - גם ב-Design time וגם ב-Runtime - לאפליקציות AI.וגם אפשרות להפיק את המידע הזה החוצה - לספק את ה-Metadata הזה לכל אפליקציה אחרת בארגוןכלי Cataloging לשימושי AI או למטרות Security - העשרה של המידע עם מידע (Metadata . . . ).נמרוד מגיע מרקע של Product Management - ניהל את ה-Identity Management Product Line של CA (היום בתוך Broadcom).ולפני כן רקע טכני - מפתח בתחומים של Security.[05:18] האתגר הטכנולוגי: "אתה לא יכול להגן על מה שאתה לא רואה"רן מעלה את המשפט הידוע: "You can't protect what you can't see" - מה המשמעות מבחינת הלקוחות של BigID? מהם האתגרים הטכניים בייצור של פתרונות עבורם?נמרוד מסביר ש-BigID קמה על מנת לתת לארגונים את ה-Visibility הזה.ארגונים לא יודעים מה יש להם - וגם כשארגונים חושבים שהם יודעים איפה המידע הרגיש שלהם נמצא, בפועל הם טועים.ועל מנת להגן על מידע רגיש, בתור התחלה צריך לדעת איפה הוא - וזה האתגר מספר 1.דוגמא ל-Use Case נפוץ: איזשהו Stream של מידע, לפעמים Structured ולפעמים לא . . . עושים לו Structuring, מביאים אותו ל-Databases של האפליקציות - וחושבים שהוא רק שם.אחד ה-Use Cases הנפוצים זה עולם הבנקאות ו-Wealth Management - המון רגישות לפרטיות של הלקוחות.ארגונים כאלו מנהלים כמויות עצומות של מידע - ואסור שמספרי חשבון ופרטים מזהים יצאו מגבולות ה-Data Lake או ה-"Green Zones" לאיזורים אחרים.גם הדיוק מאוד חשוב - וגם ה-Scale מאוד גבוה.ואלו “עבירות של כלא” . . . .אם המידע דולף, המנכ"ל עלול ללכת לכלא.(רן) מהזוית של המהנדס - איך עושים דבר כזה? זה נשמע כמו RegEx . . . יש מספרי חשבונות בנק וכו’, אז הפתרון הטריויאלי הוא להפעיל איזשהו Regular Expression. אבל המציאות קצת יותר מורכבת . . . . אילו טכנולוגיות אחרות יש?נמרוד מסביר ש-”Regular Expression טוב בערך ל-Email . . . . לכל מה שהוא מעבר ל-Email, זה כבר לא עוזר לך”.הסיבה לכישלון של מערכות DLP (Data Loss Prevention) ישנות היא ההסתמכות על RegEx, שיצרו המון רעש.“זו פשוט לא טכנולוגיה מספיק טובה”.אחת הטכנולוגיות הראשונות ש-BigID יצאה איתה הייתה Correlation, מה שהחברה מכנה Identity Graph.היכולת לעשות Exact Value Matching על מידע שהוא Correlated.איך זה עובד? לוקחים Data ממערכת ה-CRM או ה-HR, ממפים פרופילים של משתמשים, ואז מוצאים את המידע הזה.זה נותן דיוק מאוד גבוה - וגם יכולת לדעת למי המידע שייך.לדוגמא - “מספרי חשבון זה רק רצף של מספרים - RegEx לא יעזור לך”.אם מוצאים רצף מספרים, קשה לדעת אם זה מספר חשבון או סתם מספר - אבל אם הרצף הזה תואם לרשימת הלקוחות מה-CRM – הוודאות גבוהה מאוד.מסתכלים על המסמך כולו, או על Entities בתוכו? גם וגם . . . יש Machine Learning & Deep Learning - שימוש ב-NER (Named Entity Recognition) לחילוץ ישויות.שימוש ב-Document Classifiers כדי לזהות את סוג המסמך (האם זה חוזה העסקה? האם זה NDA? - עושים Deep Learning על כל המסמך), ומזהים על סמך Training קודם.את אותו הדבר עושים גם עם LLM-Based Classification.מאפשר גמישות (גם וגם - או זה או זה, או שניהם)אבל מציב אתגרים חדשים של עלות ומהירות - זה יקר מאוד ואיטי מאוד לסרוק TBs של Data . . . . צריך להתחיל עם כל מיני סוגים של אופטימיזציות.[11:01] סוגיית ה-Scale וה-Cost בעולם ה-LLMרן מציין שגם מודלים "צנועים" זה עדיין “מליארדים של פרמטרים”, וגם הם דורשים GPU ועולים לא מעט כסף. נמרוד מפרט על האסטרטגיה להתמודדות - אחת הטכניקות הראשונות הייתה ב-Small Language Models (SLM): התחילו עם BERT או RoBERTa. זה עבד (ביצועים טובים, עדיין צריך GPU), אבל חייב אימון (Training) על ה-Data של הלקוח – וזה "Big No No" מבחינת אבטחה (ענייני Security ורגולציה) ואופרציה (זמן…).“סיוט אופרטיבי” . . . .השלב הבא הוא LLMs (“מודרניים”): גם מודלים של 50 מיליארד פרמטרים כבר לא דורשים אימון (Pre-trained) ונותנים תוצאות מעולות.“ה-LLM של לפני חודש זה כבר ה-SLM של היום” . . . .והם כבר באים מאומנים.מה לגבי המחיר? פה נכנסת האופציה לעשות אופטימיזציה לסריקה (Full Scan vs. Sampling): רוב פתרונות ה-DSPM (Data Security Posture Management) לא מסוגלים לעשות Full Scan, הם עושים רק דגימה (Sampling מהיר מעל ה-Data).זו הדרך היחידה ל-Cost Effective Brute-force עם LLM . . . .זו אופציה טובה למטרות Security (ו-BigID מאפשרת אותה), אבל נמרוד טוען שזה לא מספיק ל-CISO, שצריך Full Scan.זה טוב בשביל Risk Assessment, אבל לא “פתרון סופי” [הגענו גם לזה…].פה מגיע הפתרון ההיברידי (LLM Augmented):משתמשים בכלים דטרמיניסטיים וזולים (כמו RegExאו NER) כדי לסרוק את הרוב.משתמשים ב-LLM כדי לנקות את ה-False Positives."אתה מקטין בסדר גודל את כמות ה-Findings שאתה צריך לעבור עליהם וצריך לעשות עליהם LLM Classification”.מכוונים את ה-RegEx להיות "רחב" (לתפוס הרבה False Positive), ואז ה-LLM מנקה את השגיאות (גם אם עדיין משאיר קצת FP).אלו ענייני Cost-Effectiveness שצריך לקחת בחשבון.אורי מזכיר שנהוג לחשוב על LLM-ים כ”לא דטרמניסטיים” . . . . איך משתמשים בהם על מנת לקבל משהו דטרמניסטי?נמרוד משתמש במונח “כמה שיותר לא דטרמניסטי” - שהוא עצמו לא דטרמניסטי . . . .באופן כללי, Data Classification זו טכניקה סטטיסטית - אף פעם אין 100% ודאות.כן יודעים להגיע עם LLM לרמות דיוק מאוד גבוהות, יותר מאשר עם RegEx - כשמסתכלים על כל מגוון האפשרויות.יכול להיות שה-LLM ישווה ויטעה - אבל ל-RegEx אין שום אפשרות בכלל לבדוק (למשל - “האם זה לקוח?”).אלו False Positives עם Use Cases מאוד ספציפיים, לעומת שיטות דטרמיניסטיות שמחפשות את המידע הזה.[16:13] סיכונים וחיות אחרות / " LLM זה ראשי תיבות של לא למחוק"מה קורה עם לקוחות שגם מאמנים מודלים? רן העלה את החשש שמידע שדלף לתוך האימון של המודל "נצרב" בתוך המשקולות של ה-LLM (שזו למעשה “מכונה שיודעת לעשות Compaction מאוד יפה, וזוכרת כמה דברים” . . . ).איך מתמודדים עם מידע בתוך המודל?נמרוד אומר ש”למחוק מידע מ-LLM זו משימה כמעט-בלתי-אפשרית”.יש טכנולוגיות שמתיימרות לעשות את זה, אבל זה מצריך כמות חישוביות כל כך גבוהה, שכבר עדיף לאמן את המודל מחדש.פרקטית, מה שצריך לעשות זה לטפל ב-Pipeline של ה-Data:מניעה (Sanitization) - “לא להכניס מידע שאתה לא רוצה”, לנקות את ה-Data הלא-רצוי לפני שהוא נכנס ל-Training או ל-RAG.סריקת Vector DBs: להסתכל על ה-Inference Framework.האמבדינג (Embedding) הוא “וקטור של מספרים”, אבל הוא מכיל לרוב גם את ה-Snippet של המידע המקורי עצמו, או לינק ל-Data במקום אחר - BigID יכולים לסרוק את ה-Data הזה (את ה-Vector DB), מזהים וקטורים שמכילים מידע רגיש, ושמים עליהם Label (אם המפתחים לא רוצים למחוק אותם).ואז אפשר להפעיל Access Control: ברגע שהוקטור מסומן כרגיש, אפשר למנוע מהאפליקציה למשוך אותו בשלב בניית התשובה.אורי מציין שראשי התיבות של LLM זה “לא למחוק” . . . . נמרוד - "בתעשייה שלנו, Job Security זה שארגונים לא מוחקים מידע אף פעם".צריך לזכור שהסיכונים הם לא רק זליגה של מידע, אלא באותה מידה גם Insider Threat: חשש שהמידע יחשף בתוך הארגון.ארגונים חוששים שעובדים ישתמשו ב-Microsoft Copilot (או Glean, או Gemini) כדי לשאול "מה המשכרות של ה-CEO, או של החבר שלי?"פעם היינו מוגנים ע"י "Security by Obscurity" (אף אחד לא ידע איפה הקובץ . . .[יש הטוענים ש-SharePoint זו מכונת הצפנה כמעט מושלמת]היום ה-AI מוצא הכל, והפתרון הוא סניטציה בסיסית, ללא קשר ל-AI, אלא ל-Data Access Governance.“לוודא שלאנשים הנכונים יש Access לדברים הנכונים”.[20:38] הגנה בזמן ריצה Runtime Security & Agentsרן שואל על מקרים של שליחת מידע רגיש, (נניח ש)בטעות, למודלים פומביים, כמו -ChatGPT או Gemini. “לא תיארתי לעצמי שדווקא שם יהיה מספר חשבון בנק או פרטים סודיים” . . . אין אפשר להגן מפני טעויות כאלה?אז כאן יש את ה-Runtime - ואפשר לעשות Interception ל-LLM.מעיין Firewall לכל מה שיוצא החוצה ל-LLM - או נכנס פנימה.יש הרבה חברות שמתחילות להציע את זה היום - לא רק בשביל Data אלא גם עבור כל מיני שירותי Security: מציאת Vulnerabilities ו-Prompt Injections וכל מיני כאלה.ב-BigID מתמקדים ב-Data - גם מניעה של זליגה החוצה וגם ווידוא שהאנשים שנחשפים למידע הם אכן אלו שרשאים לגשת אליו.יש כל מיני שיטות לעשות את זה, כשב-BigID נמרוד מציג גישה של מעיין “AI Firewall” עבור “Home-grown Applications” - שימוש ב-LangChain hooks בשביל “יירוט הפרומפט” (Prompt Interception).אם רוצים להגן גם על Employee Access to AI, טכניקה נפוצה היא Plug-Ins ל-Browser (תוספי דפדפן, Browser Plugins).טכניקה נוספת היא להשתמש ב-API Gateways.כל API Firewall (כמו Congo למשל) מאפשר לעשות Hooking ל-Set של APIs.אפשר גם להתחבר ל-API של ה-Service - מאפשר לעשות את זה “בצורה הכי נקייה”.התממשקות, בדרך כלל ל-Audit Logs של הספקיות (OpenAI/Microsoft), ובאופן הזה חשיפה, דרך API, ל-Prompt.ואז יש יכולת לתת Alert או DDR - Data Discovery & Response.אבל גם Microsoft וגם אחרים נותנים עכשיו APIs שמאפשרים, ממש כמו LangChain, להיות Man in the Middle.רן מציין שבעולם ה-Agent-י זה כבר עוד יותר מורכב: זה כבר לא Copy-Paste אלא Agent ששובר את המשימה לחלקים ועושה Function Callings . . . . ”בלגן שלם”. איך מגינים על זה? כאן הבעיה הופכת לבעיית Identity Management - ו-Agent זו בעיה כזו.ה-Agent פועל בשם המשתמש - משתמש ב-Credentials וב-Identity של המשתמש.האתגר הוא להבדיל בין האדם למכונה - ומה ה-Context של העבודה.זה יותר מורכב מההבדלה בין Human ל-Non-Human Identities - זה דורש טכניקות מעולמות ה-Fraud Detection: זיהוי אנומליות, מהירות פעולה, ומקור הבקשה.הגבול הוא מאוד לא-חד (Blurred) - יש אדם שמשתמש ב-Agent - וצריך לדעת להבדיל בין פעילות של אדם לפעילות של מכונה.זה לא מדע חדש - אבל פתאום צריך לדעת להפעיל אותו על מקורות מידע ומקורות Compute חדשים.כשאתה ניגש בתור אדם למידע אז יש לך גישה, אבל אם ה-Agent מתחיל להעלות את כל הקוד לשרת בבלארוס – זו כנראה אנומליה שצריך לחסום . . .[27:10] איך מטפלים במה שאתה לא יודע? / גישה חדשה ל-Access Control (דינמי וסמנטי)בכל ענייני ה-Unknown מטפלים בדרך כלל ע”י Anomaly Detection - מזהים Baseline שלהתנהגות, וברגע שיש חריגה אז יודעים לתת התראה.זה יכול להיות דברים טריוויאליים כמו התנהגות של Downloads (כמויות או מיקום) ויכולים להיות דברים יותר מורכבים (בהתאם לסוג הפעולה וסוג המידע). זה דורש Visibility יותר אינטימי ל-Classification של המידע.דבר נוסף הוא נושא ה-Access Controls באופן כללי - עולם ה-Security עד היום נבנה על סמך הגישה המסורתית של ACL (Access Control Lists)בעולמות ה-Agent-יים ובעולמות ה-AI בכלל, הגישה של ACL סטטי נשברת - אגרגציה (Aggregation) של מידע יוצרת רגישות חדשה.מידע שאולי היה לחלוטין לא רגיש כשהוא מבוזר - אבל כשעושים אגרגציה, נוצרים ההקשרים ו-Re-identification של מידע, שהופכת אותו פתאום לרגיש.רן נותן דוגמא: פרט אחד על חולה ב-Yorkshire ופרט אחר על גיל 80+ ב-Yorkshire אולי לא מזהים בנפרד; כל עוד המידע מאוד “רחוק אחד מהשני”, נדרשת “עבודת בלשות”, אבל ה-LLM מחבר אותם בקלות, וזה מוריד את סף התקיפה.הפתרון הוא קלסיפיקציה (Classification) של המידע בזמן אמת (On the fly) - המערכת צריכה לזהות שכרגע המידע הוא "רפואי", ולבדוק האם לאפליקציה/משתמש הספציפי מותר לראות מידע רפואי ברגע זה, ללא קשר למאיזה קובץ הוא הגיע.וזה משנה לגמרי את האופן שבו מנהלים גישה ל-Data - וזה מחייב Controls חדשים ו-Visibility אחר למידע.“סוג של ACL - אבל סמנטי ודינמי, On the fly”: קלסיפיקציה בזמן השימוש במידע, ולא (רק) Static Policies לפיסות מידע לא מחוברות.קצת מזכיר את התהליך שעבר על ה-Firewalls.[31:38] סערת ה-LLM בחברה ותיקהאורי שואל “מחוץ ל-Script” - אנחנו מדברים על חברה ותיקה (BigID), מימי טרום ה-LLM. איך עוברת הטרנספורמציה הזו על החברה?זה תהליך טבעי של חברה ושל אימוץ של טכנולוגיות חדשות.נמרוד משתף ש-BigID לא התחילה מ-RegEx, אלא מטכנולוגיה אלטרנטיבית חדשה ל-Data Classification - ורק אז השלימה את ה-RegEx, “כשהלקוחות רצו משהו מוכר”.“כשהגיעו המודלים של ה-NER וה-Deep Learning אז הכנסנו אותם”.אימוץ ה-LLM בחברה היה תהליך טבעי ומהיר (התחיל בהאקתון), כי קלסיפיקציה מבוססת-LLM זה משהו שקל יותר להטמעה מאשר בניית מודלים של NER מאפס.ומה לגבי Real-time Identification? עולם האיומים השתנה - בהרבה.ה-Core של BigID הוא לא על בסיס Agents (על המכונות) - אלא API-Based, וזה תמיד היה ה-Guideline.גם ל-Activity Monitoring.ההתחלה הייתה עם Data at Rest - ואז נוספו Permissions ל-Data Access Governance.והדבר הבא שלקוחות רצו היה לדעת מי ניגש למידע - אז כל נושא ה-Real-time לא קשור ל-AI, אלא נכנס כחלק מההתפתחות של המוצר.אם כי זה כמובן גם משרת מאוד את כל נושא ה-AI.נמרוד לא בהכרח רואה את BigID נכנסת לבנייה של Gateways ל-AIבידול של BigID מול חברות Firewall (כמו Palo Alto / SentinalOne): חברות ה-Network וה-Endpoint שבונות את ה-Firewalls” “וטבעי להן” לבנות את ה-AI Gateways. ב-BigID פוגשים את זה בתור “האחראים על ה-Data” - וה-Data זה מה שמניע את ה-AI.כל מה שקשור ל-Home-grown AI Applications זה המשך מאוד רציף: AI Product הוא Data Product.היכולת לעשות אגרגציה ועיבוד מאוד מתקדם של מידע.עוד חוזקה היא על ה-Controls שקשורים ב-Data - ההבנה של ה-Context שעובר בתוך ה-Prompt.הכרות יותר אינטימית עם ה-Data והיכולת לדעת האם הוא רגיש.והיכרות עם הרגולציות הרלוונטיות - איזה מידע ניתן לשימוש באיזו אפליקציה: בדומה ל-Privacy, עכשיו זה לכיוון של AI Regulations.[36:59] גיוסים וסיכוםהחברה מונה כ-600 עובדים, מרכז הפיתוח (R&D, Product, Design) נמצא בתל אביב.מגייסים בכל התחומים - גם Product, גם פיתוח, גם Design. הארגון בינלאומי - אבל מובילים את המוצר מהארץ.תודה - ובהצלחה![קישור לקובץ mp3] האזנה נעימה ותודה רבה לעופר פורר על התמלול!
