AI Threat Modeling: איך מתאימים STRIDE למערכות עם התנהגות הסתברותית

מאת צוות מדיה דיל · 04.08.2026 · Enterprise AI · 7 דק׳

מדריך מעמיק ל-AI Threat Modeling: התאמת STRIDE הקלאסי לעולם ה-AI, שימוש ב-MITRE ATLAS, ותהליך עבודה שמחבר מיפוי איומים למעקב הפחתה בפועל.

הבעיה: STRIDE לא נבנה עבור מערכות עם התנהגות הסתברותית

threat modeling קלאסי - STRIDE, DREAD, attack trees - נבנה בעולם שבו רכיבי המערכת דטרמיניסטיים: אותו קלט מייצר תמיד את אותו פלט, וניתן למפות במדויק כל נתיב נתונים. ברגע שמוסיפים לתמונה מודל שפה, ההנחה הזו קורסת: אותה שאלה יכולה להניב תשובות שונות בכל הרצה, וה"לוגיקה" הפנימית של המודל היא black box שאי אפשר לנתח בקוד סטטי. AI Threat Modeling הוא ההתאמה של המתודולוגיה הקלאסית לעולם הזה - שומר על המבנה השיטתי של threat modeling מסורתי, אבל מוסיף קטגוריות איום שספציפיות ל-AI ומחליף חלק מההנחות הבסיסיות.

מיפוי משטח ה-Data Flow הייחודי ל-AI

שלב ראשון בכל threat model הוא Data Flow Diagram (DFD) - מיפוי כל נתיב שבו מידע זורם דרך המערכת וכל גבול אמון (trust boundary) שהוא חוצה. במערכת AI, ה-DFD חייב לכלול רכיבים שלא קיימים ב-DFD מסורתי: זרימת ה-prompt (system prompt, היסטוריית שיחה, קלט משתמש - כל אחד עם רמת אמון שונה), זרימת ה-retrieval (מה מגיע מ-vector store, ומה מקור המסמכים שם), וזרימת ה-tool calls (איזה tool מקבל איזה פרמטר, ומאיזה מקור הפרמטר הזה נגזר). הנקודה הקריטית ביותר במיפוי הזה: לזהות בדיוק היכן קלט לא מהימן (משתמש, מסמך חיצוני, תוצאת API) "מתמזג" לתוך אותו context window יחד עם הוראות מהימנות (system prompt) - כי מיזוג הזה הוא בדיוק המנגנון שמאפשר prompt injection.

STRIDE-AI: התאמת הקטגוריות הקלאסיות

  • Spoofing - במקום רק התחזות זהות משתמש, כולל גם התחזות agent ל-agent אחר במערכת multi-agent, או MCP server זדוני שמתחזה לשירות לגיטימי.
  • Tampering - שינוי לא מורשה, כולל data poisoning של training data או של מאגר ה-RAG, ולא רק שינוי נתונים במסד נתונים מסורתי.
  • Repudiation - היכולת להתכחש לפעולה שבוצעה - קריטי במיוחד כש-agent מבצע פעולה אוטונומית, ויש צורך באודיט טרייל שמראה בדיוק איזו החלטה הובילה לאיזו פעולה.
  • Information Disclosure - חשיפת system prompts, training data, או תוכן מ-tenant אחר - קטגוריה שמקבלת משקל גדול משמעותית ב-AI לעומת אפליקציות מסורתיות.
  • Denial of Service - כולל גם resource exhaustion ייחודי ל-AI: הצפת context ארוך, לולאות tool-calling רקורסיביות, או ניצול עלות ה-inference עצמה כווקטור תקיפה כלכלי.
  • Elevation of Privilege - כולל "Excessive Agency" - agent שרוכש בפועל יכולת רחבה יותר ממה שתוכנן, דרך שרשור tools או ניצול הרשאות ברירת מחדל רחבות מדי.

Trust Boundaries ספציפיים לארכיטקטורת Agent ו-MCP

במערכת agentic מודרנית, יש לפחות ארבעה גבולות אמון שצריך לסמן במפורש ב-DFD ולא להתייחס אליהם כאל אזור אחד הומוגני: הגבול בין המשתמש לבין ה-agent (קלט חיצוני לא מהימן), הגבול בין ה-agent לבין ה-orchestrator שמנהל אותו (במערכות multi-agent), הגבול בין ה-agent לבין כל MCP server שהוא מתחבר אליו (שכל אחד עשוי להיות ברמת אמון שונה - MCP פנימי שנבנה בארגון מול MCP חיצוני שהותקן מ-registry ציבורי), והגבול בין תוצאת ה-tool call לבין ה-context שחוזר למודל. הטעות הנפוצה ביותר במיפוי DFD ל-agent systems היא לצייר את כל ה-tools כקטגוריה אחת "כלים מהימנים", בזמן שבפועל לכל tool יש רמת אמון שונה בהתאם למקור שלו, להרשאות שהוא מחזיק, ולשאלה האם הוא פותח בתוך הארגון או הותקן ממקור חיצוני.

שימוש ב-MITRE ATLAS ככלי עזר

MITRE ATLAS (Adversarial Threat Landscape for AI Systems) הוא הרחבה של מסגרת ATT&CK הידועה, שממפה טקטיקות וטכניקות תקיפה ספציפיות למערכות ML ו-AI - מ-reconnaissance (איסוף מידע על המודל) ועד ל-impact (גרימת נזק בפועל). שימוש ב-ATLAS כמסגרת עזר ל-threat modeling נותן שני יתרונות מעשיים: שפה משותפת עם קהילת האבטחה הרחבה (כשמדווחים על ממצא, אפשר להתייחס למזהה טכניקה סטנדרטי במקום לתאר מחדש כל פעם), וקטלוג עדכני של טכניקות תקיפה אמיתיות שנצפו בשטח, ולא רק תיאוריה. threat model שממפה איומים גם מול ATLAS techniques, ולא רק מול STRIDE-AI, מקבל כיסוי מעשי משמעותית יותר.

תהליך עבודה: מ-Asset Identification ועד Mitigation Tracking

threat model בשל עובר ארבעה שלבים סדורים: זיהוי נכסים (מה אנחנו מגנים - נתונים, יכולות, מוניטין, כסף), זיהוי איומים (שימוש ב-STRIDE-AI ו-ATLAS כדי למפות תרחישים רלוונטיים), דירוג סיכון (שילוב הסתברות והשפעה, בדומה לדירוג שתואר במאמר על AI-SPM), ומעקב הפחתה - לכל איום שזוהה, מה הבקרה שממתנת אותו, ומי אחראי לוודא שהבקרה אכן קיימת ופעילה. השלב האחרון הוא הכי מוזנח בפועל - ארגונים רבים משקיעים במיפוי איומים אבל לא בונים מנגנון שעוקב אחרי מימוש ההפחתות לאורך זמן, מה שהופך את המסמך למדף אבק אקדמי במקום כלי עבודה חי.

מי בארגון "מחזיק" את ה-Threat Model - שאלת בעלות

שאלה ארגונית שלרוב לא מקבלת תשובה ברורה: מי אחראי לתחזק את המודל לאורך זמן? בארגונים רבים, threat modeling נעשה על ידי צוות אבטחה חיצוני או יועץ בשלב ה-launch, ואז "נעלם" - אין בעלים פנימי שמעדכן אותו כשהמערכת מתפתחת. הפרקטיקה הנכונה קובעת בעלים ברור (בדרך כלל tech lead של הצוות שמפתח את המערכת, לא צוות אבטחה מרכזי בלבד) שאחראי לעדכן את המודל בכל שינוי ארכיטקטוני משמעותי, עם צוות האבטחה בתפקיד מייעץ ומאמת ולא כבעלים בלעדי. חלוקת אחריות כזו, שמשלבת בעלות מבוזרת (הצוות שבונה) עם פיקוח מרכזי (צוות האבטחה), נותנת את הסיכוי הטוב ביותר שהמודל באמת יעודכן, ולא רק ייכתב פעם אחת ויישכח.

Trade-offs: עומק המודל מול תדירות העדכון

threat model מפורט במיוחד, שממפה כל נתיב נתונים אפשרי בדקדקנות, נותן כיסוי מרשים אך לוקח שבועות לבנות ומתיישן מהר במערכת AI שמשתנה תדיר. גישה מהירה יותר, "lightweight threat modeling", ממקדת מאמץ רק ברכיבים בסיכון הגבוה ביותר ומתעדכנת תדיר - כל פיצ'ר משמעותי חדש מקבל סבב מיפוי קצר (30-60 דקות) במקום מסמך מקיף. בפרודקשן, הגישה השנייה מנצחת כמעט תמיד: threat model שמתעדכן כל שבועיים בצורה קלה שווה יותר מ-threat model מושלם שנכתב פעם אחת ומתיישן תוך רבעון.

טעויות נפוצות בפרודקשן

הטעות הראשונה: לבצע threat modeling פעם אחת בתחילת הפרויקט ולא לחזור אליו כשהארכיטקטורה משתנה - הוספת יכולת agentic חדשה או MCP server חדש היא שינוי ארכיטקטוני מהותי שדורש עדכון המודל, לא רק תיעוד. הטעות השנייה: להשתמש ב-STRIDE הקלאסי בלי ההתאמות הספציפיות ל-AI, מה שמוביל למודל שנראה מקיף אך מפספס לגמרי תרחישים כמו prompt injection או model extraction. הטעות השלישית: לבנות threat model מפורט ומרשים בלי לחבר אותו למעקב הפחתה בפועל - המסמך הכי טוב לא שווה כלום אם אין מנגנון שמוודא שהבקרות המומלצות אכן יושמו.

Attack Trees: מ"מה עלול לקרות" ל"איך זה קורה בפועל צעד אחר צעד"

רשימת קטגוריות STRIDE-AI טובה לזיהוי סוגי איום, אבל לא מסבירה איך תוקף בפועל מגיע ליעד. attack tree ממלא את הפער הזה: הוא מתחיל ממטרת התוקף (למשל, "חילוץ מידע פיננסי רגיש דרך ה-chatbot") ומפרק אותה לענפי דרכים אפשריות - הזרקת פרומפט ישירה, הזרקה עקיפה דרך מסמך שהועלה, ניצול tool שמחזיר מידע רגיש בלי סינון מספק - וכל ענף מתפצל שוב לתת-שלבים קונקרטיים. היתרון המעשי של attack tree על פני רשימת קטגוריות שטוחה הוא שהוא חושף במפורש את נקודות ה"צוואר בקבוק" - שלבים שדרכם כל ענפי התקיפה חייבים לעבור, ושחסימתם למעשה סוגרת מספר וקטורי תקיפה בבת אחת. בפרודקשן, בניית attack tree עבור 2-3 המטרות החמורות ביותר (ולא כל תרחיש אפשרי) נותנת יחס עלות-תועלת הרבה יותר טוב מניסיון למפות את כל עץ האפשרויות התיאורטי.

שיתוף Threat Model בין צוותים: מסמך אחד, קוראים שונים

אתגר ארגוני נפוץ הוא ש-threat model נכתב בשפה שמתאימה לצוות אבטחה אחד, אך לא מתקשרת עם מפתחים או עם הנהלה. threat model יעיל כולל שלוש שכבות תקשורת: תקציר ניהולי שממפה סיכונים עסקיים ("מה עלול לקרות ללקוחות אם התרחיש הזה מתממש") בלי ז'רגון טכני; מפרט טכני מפורט למפתחים עם נתיבי data flow קונקרטיים ומיקום מדויק בקוד; וסט בדיקות נגזר לצוות ה-QA/אבטחה שממיר כל איום מזוהה לתרחיש בדיקה בר-ביצוע. ארגונים שכותבים threat model כמסמך יחיד "אחד מתאים לכולם" בדרך כלל מגלים שהוא לא נקרא בפועל על ידי אף אחד מהקהלים, כי הוא לא מספיק פשוט להנהלה ולא מספיק מפורט למפתחים.

מתי כן ומתי לא

לכל מערכת AI חדשה, גם קטנה, ראוי לפחות סבב threat modeling מקוצר לפני launch - זה תרגיל שלוקח שעה-שעתיים ומגלה לרוב לפחות איום קריטי אחד שלא נלקח בחשבון. עבור מערכות עם רגישות גבוהה (נתונים פיננסיים, רפואיים, יכולות agentic נרחבות), נדרש threat model מלא ומקיף עם עדכון סדיר, ולא רק סבב ראשוני.

איך אנחנו ניגשים לזה

במדיה דיל אנחנו מריצים threat modeling מובנה כשלב חובה בתחילת כל פרויקט AI, עם מיפוי STRIDE-AI ו-ATLAS techniques, ומחברים אותו למעקב הפחתה חי שמתעדכן לאורך כל מחזור הפיתוח - לא מסמך שנכתב פעם אחת ונשכח.

קשר ל-Red Team ול-Security Testing: איפה כל דיסציפלינה תופסת

threat modeling הוא תמיד השלב הראשון בשרשרת - הוא קורה לפני שהמערכת קיימת בכלל, בשלב התכנון, ומטרתו לצפות מראש איפה כדאי להשקיע במאמצי הגנה. red teaming ו-pentest קורים אחרי שהמערכת קיימת, ומאמתים בפועל האם ההגנות שהמודל צפה מספיקות. security testing אוטומטי (ברמת LLM ו-agent) הוא השלב שממיר את הממצאים מהשניים הקודמים לבדיקות חוזרות ומתמשכות. ארגון שמדלג על threat modeling ועובר ישר ל-red teaming בזבז זמן יקר על בדיקה לא ממוקדת - בלי מפת דרכים ברורה, הבודקים "מנחשים" איפה לחפש במקום להתמקד באזורים שכבר זוהו כבעלי סיכון גבוה. הרצף הנכון תמיד מתחיל במיפוי שיטתי.

סיכום

AI Threat Modeling הוא ההתאמה השיטתית של מתודולוגיית האבטחה הקלאסית לעולם שבו התנהגות המערכת הסתברותית ולא דטרמיניסטית. הארכיטקטורה הנכונה משלבת מיפוי data flow ייחודי ל-AI, STRIDE-AI כמסגרת קטגוריות, ATLAS ככלי עזר לטכניקות עדכניות, ומעקב הפחתה חי שהופך את המודל מתיעוד למנגנון עבודה שוטף.

תגיות: AI Threat Modeling · STRIDE · MITRE ATLAS · data flow diagram · prompt injection · risk assessment · AI security architecture

← חזרה לבלוג · צור קשר