תהליך עבודה מובנה להמרת מודיעין איומי סייבר לדפוסי זיהוי ניתנים לחישוב

סיכום

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

תקציר

מרכזי מבצעי אבטחה (SOCs) ממירים באופן שגרתי דוחות מודיעין איומי סייבר (CTI) לתוכן גילוי תפעולי. צוואר בקבוק מתמשך בזרימת עבודה זו הוא תרגום אינדיקטורים של חשיבה (IOC) שהופצו, במיוחד נתיבי קבצים, מפתחות רישום ומחרוזות שורת פקודה, לביטויים רגולריים ניתנים לפריסה (regexes) המתאימים להטמעה בכללי קורלציה של מידע אבטחה וניהול אירועים (SIEM). למרות שעבודות קודמות שיפרו חילוץ אוטומטי באמצעות אינדיקטור לפשרה (IOC), הפיכת מחרוזות שחולצו לתבניות רגקס מאומתות נשארת בעיקר ידנית, דורשת מומחיות מיוחדת ומועדת לשגיאות. מטרת הפרוטוקול היא לספק הליך סטנדרטי וניתן לשחזור לתרגום מ-IOC ל-REGEX. תהליך העבודה מורכב מחמישה שלבים: (1) פירוק דוחות CTI הטרוגניים לייצוג Markdown מאוחד; (2) חילוץ IOC באמצעות מספר מודלים לשוניים גדולים (LLMs) עם הצבעה קונצנזוס; (3) נרמול מבוסס כללים, קטגוריזציה והסרת כפילויות של IOCs שהופצו; (4) תיוג בסיוע גרף של רכיבי IOC כקבוצת שמירה (קבוצת לכידה) או דחייה (קבוצת לא-לכידה); ו-(5) יצירת רגקס איטרטיבית עם אימות אבחוני מול מחרוזות ה-IOC המקוריות. כדי להעריך את התועלת, זרימת העבודה יושמה על 3,156 דוחות CTI, וה-regexes שהתקבלו הוערכו מול יותר מ-2,400 מחרוזות אמת קרקעית שנאספו באופן עצמאי מעשרה תרחישי הערכה של MITRE Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK), שהניבו שיעור פגיעה ממוצע של 99.1% ושיעור אי-התאמה ממוצע בין IOC של 0.8%. לכן, הפרוטוקול מתעד מימוש שניתן לשחזור עבור תרגום IOC ל-regex ומגדיר במפורש את היקפו הנוכחי, הנחות התפעוליות ומקרי הכשלים הידועים.

מבוא

פשיעת סייבר ממשיכה להטיל עומס תפעולי ופיננסי משמעותי על ארגונים במגזר הציבורי והפרטי. בשנת 2023, ההפסדים המדווחים כתוצאה מפשיעת סייבר בארצות הברית עברו את 12.5^{מיליארד} דולר, מה שמדגיש את היקף והתמשכות הפעילות הזדונית. בתוך נוף זה, מרכזי מבצעי ביטחון (SOCs) משמשים כיחידות המבצעיות העיקריות האחראיות לאיתור, ניתוח ותגובה לאיומים בזמן אמת.
לוגיקת זיהוי ברבים מזרימות העבודה של SOC מיושמת באמצעות מנגנונים מבוססי כללים בתוך פלטפורמות ניהול מידע ואירועים אבטחה (SIEM), אשר נפוצות בכך שהן ניתנות לפרשנות, דטרמיניסטיות ותואמות לתהליכי SOC קיימים. מבין סוגי הכללים השונים, כללי SIEM מבוססי קורלציה חשובים במיוחד לזיהוי התנהגויות התקפה המשתרעות על פני אירועים, מארחים וחלונות זמן מרובים. בתוך כללים אלו, ביטויים רגולריים (regexes) פועלים כפרימיטיב חיפוש רב-פעמי: אנליסטים משלבים אותם בתוך כללי זיהוי רחבים יותר שמוסיפים מגבלות שדה, מסננים ספציפיים לפלטפורמה ולוגיקת אירועים-קורלציה, במקום לפרוס אותם כגלאים עצמאיים.

בפועל, אנליסטים של SOC לעיתים מתחילים בפיתוח כללים עם אינדיקטורים של פשרה (IOCs) שמקורם בדוחות מודיעין איומי סייבר (CTI) שפורסמו על ידי ספקי אבטחה, חוקרים עצמאיים או בסיסי ידע ציבוריים כגון MITRE Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK)². מחרוזות IOC אלו עשויות לכלול נתיבי קבצים, קטעי שורת פקודה, מפתחות רישום או ארטיפקטים מובנים אחרים שנצפו במהלך התקפות³. תרגום מחרוזות כאלה לתבניות רגקס המתאימות לכללי הקורלציה של SIEM הוא משימה חוזרת בזרימת העבודה של כתיבת הכללים.

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

האתגר המרכזי בתרגום IOC ל-regex הוא להחליט אילו חלקים ב-IOC מקודדים התנהגות יציבה ורלוונטית לתוקף ולכן יש לשמרם, ואילו חלקים משקפים שונות ספציפית לסביבה או למארח ויש להכלילם. לדוגמה, שורשי רישום קנוניים כמו HKEY_CLASSES_ROOT\CLSID, תיקיות מערכת כמו System32, ושמות הרצה ידועים כמו rundll32.exe בדרך כלל צריכים להישאר מפורשים, בעוד שנתיבי פרופיל משתמש, מזהי אבטחה ספציפיים למארח (SIDs) ומזהים ייחודיים גלובלית (GUIDs) צריכים להיות מופשטים בדרך כלל. ביצוע זה בעקביות בין סוגי IOC הטרוגניים הוא מה שהופך את משימת התרגום לפחות טריוויאלית. לאורך כל הפרוטוקול הזה, אנו מתייחסים לראשונים כרכיבים שמורים או רכיבי קבוצת לכידה, ולשני כרכיבים מופשטים או שאינם לכידתיים.

עבודות קודמות חקרו חילוץ אוטומטי של מודיעין איומים מטקסט לא מובנה באמצעות טכניקות עיבוד שפה טבעית וחילוץ ישויות ^6,7. לאחרונה, מספר מחקרים חקרו יצירה ישירה של כללי זיהוי מדוחות CTI באמצעות מודלים לשוניים גדולים (LLMs)⁸. גישות אלו מראות שחלקים מתהליך כתיבת הכללים יכולים לקבל סיוע ממודלים לשוניים, אך בדרך כלל אינן מתמקדות בבעיה התפעולית הספציפית של יצירת דפוסי regex ששומרים על סמנטיקה של קבוצת לכידה ונשארים מתאימים לפריסת SIEM בהמשך. קווי עבודה משלימים כוללים תוכן CTI מובנה לשימוש בהמשך בדרכים שונות, כולל ייצוגים מבוססי גרף ידע כמו TINKER⁹ ויצירת שאילתות ציד לוגים מונחות CTI כמו ThreatRaptor¹⁰, שממירים CTI לא מובנה לשפות ידע מובנות או שאילתות ספציפיות לתחום במקום לתבניות regex המיועדות להטמעה בכללי הקורלציה של SIEM.

במקביל, מחקרים קודמים בחנו סינתזת רגקס אוטומטית באמצעות שיטות מבוססות דוגמאות, תרגום עצבי וגישות יצירה ותיקון 11,12,13,14,15,16. עם זאת, שיטות אלו מיועדות בדרך כלל לסביבות שמסתמכות על קבוצות גדולות של דוגמאות מייצגות או תיאורים בשפה טבעית, ולא על הקשרים מונעי זיהוי מונחי IOC. בזרשי עבודה של SOC, מחרוזות IOC לעיתים דלילות, הטרוגניות מבחינה מבנית וקשורות קשר הדוק לסמנטיקה תפעולית. חוסר התאמה זה מניע תהליך עבודה המותאם לתרגום מ-IOC לרגקס ולא לטענה ששיטות יצירת רגקס קיימות אינן מספקות באופן כללי.

הפרוטוקול המוצג כאן מתמקד במיוחד בשלב התרגום מ-IOC ל-regex בתהליך זיהוי SOC. חילוץ IOC מטופל כקלט מעלה הזרם שעשוי לנבוע מניתוח ידני, כלים אוטומטיים, או שילוב של שניהם; הפרוטוקול אינו מנסה לייצר כללי SIEM שלמים. במקום זאת, הוא מספק הליך שיטתי להמרת מחרוזות IOC לתבניות רגקס שהן תקפות תחבירית, ניתנות לפרשנות סמנטית, ומתאימות לפריסה תפעולית. היקף ה-IOC הנוכחי מכוון: נתיבי קבצים, מפתחות רישום ומדדי שורת פקודה מכילים רכיבים מבניים יציבים ומשתנים שנהנים מהכללת רגקס, בעוד שאינדיקטורים אטומיים כמו כתובות IP, דומיינים וגיבוב מבוצעים באופן טבעי יותר דרך תנאי התאמה מדויקת או חיפושי מוניטין ולכן אינם בתחום העיקרי. בתוך גבולות אלו, הפרוטוקול מיועד להיות נייד בסביבות SOC החולקות פורמטים ותנאי כלים דומים.

פרוטוקול

השתמש בתהליך העבודה בן חמישה שלבים הבאים כדי להפוך דוח CTI לדפוסי רגקס מאומתים עם פלטים ביניים ניתנים למעקב (ראו איור 1 לסקירה כללית).

1. הגדרת מערכת

1. התקן דרישות קדם.
   1. התקן את Python 3.8 או מאוחר יותר, את כל התלויות ב-Python שמופיעות ב-requirements.txt, ומסד נתונים של גרפי Neo4j.
      1. אשר גישה לממשקי תכנות יישומים אחד או יותר (APIs) עבור מודלי השפה הגדולים שנבחרו ווודא ששירות Neo4j פועל ונגיש מהמכונה המקומית.
   2. אשר שטבלת החומרים שלמה.
      1. ודאו שמופיעות תלות בזמן ריצה מפורטים, כולל גרסת מפרש פייתון, תלות הצינור, גרסת Neo4j, וצד האחורי של חילוץ טקסט בפורמט מסמכים ניידים (PDF).
      2. ודאו שאפשרויות קונפיגורציית LLM מופיעות, כולל ספקי LLM, שמות דגמים וגרסאות, טמפרטורה, אפשרויות נימוק-מאמץ, והגדרות הצבעה קבוצתית.
      3. ודאו שפורמטי הקלט והפלט מופיעים, כולל פורמטי קבצי קלט נתמכים ופורמטי ייצוא נתמכים.
2. הפעל את ממשק המשתמש (UI).
   1. פתח טרמינל, נווט לתיקיית השורש של ייחוס-מימוש, והפעל את היישום באמצעות פקודת ההפעלה המתועדת (במימוש המתייחס: cd langchain_pipeline ואחריו streamlit run app_v2.py).
   2. ודא שהאפליקציה נטענת ב-http://localhost:8501 ושהפאנל של הקונפיגורציה של הסיידבר גלוי.
3. הגדר את ספק ה-LLM.
   1. בסעיף תצורת LLM בסרגל הצד, בחר ספק LLM, הזן את שם הדגם וספק מפתח API תקף לממשק תכנות יישומי.
   2. רשמו את הספק, שם הדגם, גרסת הדגם, טמפרטורה, אפשרויות ההסקה ותאריך הגישה לטבלת החומרים.
      הערה. במימוש הייחוס, חילוץ IOC ב-LLM בודד מוגדר כברירת מחדל ל-LLM המסחרי הראשי המופיע בטבלת החומרים עם טמפרטורה = 0.0; יצירת רגקס ברירת מחדל היא טמפרטורה = 0.3.
4. הפעל הצבעה קבוצתית (אופציונלית אך מומלץ לתוצאות שניתן לשחזר).
   1. הפעל את אפשרות ההצבעה הקבוצתית בסרגל הצד כדי לשמור רק על הוועדים הבינלאומיים העומדים בסף מינימום של הצבעה (מינימום הצבעות ≥ 2 מומלץ).
   2. הוסף מופעי LLM נוספים על ידי ציון הספק, שם המודל, מפתח ה-API ומספר החזרות על ההרצה לכל מודל.
      1. רשמו את ספירת החזרות של כל ספק ואת סף הקולות המינימלי שנבחר.
         הערה. הצבעה קבוצתית היא אופציונלית. כאשר הוא מושבת, הצינור מבצע חילוץ של LLM יחיד ומסנן הקונצנזוס מדלג. הגדרות ברירת המחדל של אנסמבל הן חזרות = 1 לכל דגם מוגדר ו-min_votes = 2.
5. התחבר ל-Neo4j.
   1. בחלק Neo4j Connection בסרגל הצד, הזן את ה-URI של החיבור (למשל, bolt://localhost:7687), שם המשתמש והסיסמה.
   2. וודא שהממשק מדווח על חיבור מוצלח. אל תמשיך בלי חיבור פעיל.
6. אבטח את כל האישורים.
   1. תתייחס למפתחות API של LLM ולסיסמת Neo4j כאישורים רגישים. אחסן אותם במשתני סביבה או במנהל סודות במקום בקבצי מקור, דוחות מיוצאים או צילומי מסך, וסובב כל מפתח במהירות אם יש חשד לדליפה.
      הערה. פרוטוקול תוכנה זה אינו דורש מכסה אדים כימי, ארון בטיחות ביולוגית או ציוד אחסון פיזי אחר; לטפל בדוחות ואישורים סודיים של CTI בהתאם למדיניות אבטחת המידע המוסדית.

2. שלב 1: ניתוח מסמכים

1. פרוצדורה.
   1. עבור ללשונית העיבוד בממשק הראשי.
   2. העלה דוח CTI בפורמט נתמך (.pdf, .docx, .md, .txt או .html).
   3. לחץ על "הרץ שלב הבא" כדי להריץ את שלב 1, או על "הרץ את כל השלבים" כדי להריץ את כל הצינור ברצף.
2. אשר את נקודת הביקורת של שלב 1.
   1. ודאו שמוצגת תצוגה מקדימה של מסמך הקלט ב-Markdown.
   2. ודאו שנתיבי הקבצים, מפתחות הרג'ירי, קטעי שורת הפקודה וגבולות החלקים נשארים שלמים בתצוגה המקדימה.
   3. אם המחרוזות הטכניות מקוצרות או הפורמט הוסר, תקן את קובץ המקור או עבד את המסמך עם ממיר חיצוני לפני ההעלאה מחדש.

3. שלב 2: חילוץ באמצעות IOC

1. פרוצדורה.
   1. אשר את תצורת ה-LLM (ואת ההצבעה הקבוצתית, אם מופעלת).
   2. לחץ על "הרץ שלב הבא" כדי לבצע את שלב 2.
2. אשר את נקודת הביקורת שלב 2.
   1. אשר שהממשק מציג אוסף IOC בפורמט JavaScript Object Notation (JSON) עם שלושה מפתחות ברמה עליונה: נתיבי קבצים, שורות פקודה ומפתחות רישום (Registry).
   2. כאשר הצבעה קבוצתית מופעלת, וודא שספירת הקולות ומטא-דאטה של מודל התורם נרשמות עבור כל IOC שנשמר.
      הערה. מערכת שלב 2 המילה במילה וההנחיות האנושיות, יחד עם הנחיות היצירה והאופטימיזציה של שלב 5, משוחררות כקובץ משלים 1 (Supplemental_File_1_Prompts.txt).

4. שלב 3: ניתוח וסיווג של ה-IOC

1. פרוצדורה.
   1. לחץ על "הרץ שלב הבא" כדי לבצע את שלב 3.
2. אשר את נקודת הביקורת שלב 3.
   1. ודאו שכל IOC שנשאר מופיע עם קטגוריה סטנדרטית, תג מקור, ומפתח חילוץ מקורי כאשר זמין.

5. שלב 4: נרמול IOC בסיוע Neo4j

1. פרוצדורה.
   1. אשר שהחיבור ל-Neo4j פעיל.
   2. לחץ על "הרץ שלב הבא" כדי לבצע את שלב 4.
   3. בדוק את פלט הנורמליזציה לפי IOC וודא שנוצרות תוויות שמור/השלכה עבור רכיבי מסלול ושורת פקודה, ושמפתחות הרישום מניבים תת-מחרוזת קנונית רציפה.
2. אשר את נקודת הביקורת שלב 4.
   1. וודא שטבלאות IOC מנורמלות מיוצרות עבור כל סוג IOC (נתיבי קבצים, מפתחות רישום, אינדיקטורים של שורת פקודה).
   2. ודאו שכל ערך כולל את הערך המקורי, הערך המנורמל, ורשימת רכיבים של זוגות אילמנט/סטטוס המסומנים לשמור או להשלך.
      הערה. סכימת Neo4j מפורטת, שאילתות Cypher, כללי החלטה והליך נורמליזציה של מפתחות הרישום מפורטים בקובץ המשלים 2; דוגמה מעובדת מוצגת בתוצאות מייצגות.

6. שלב 5: יצירת רגקס וניקוד

1. פרוצדורה.
   1. לחץ על "הרץ בשלב הבא" כדי לבצע את שלב 5. אשר שכל IOC מנורמל ורשימת הטוקנים האסורים שלו מוגשים ליצירת regex ולאימות דטרמיניסטי.
   2. אם מועמד נכשל באימות, אפשר ללולאת האופטימיזציה לחדד את הרגקס עד שיופק מועמד תואם או שמגיעים לתקרת האיטרציה.
   3. בדוק את פלט האבחון, היסטוריית האופטימיזציה וספירת האיטרציות עבור כל IOC שהרגקס הסופי שלו חוזר מהתאמה תואמת להתאמה חלקית בעלת הניקוד הגבוה ביותר (נרשמה כ-used_fallback = True).
2. אשר את נקודת הביקורת של שלב 5.
   1. ודאו שהופק רגקס סופי עבור כל IOC שנשמר.
   2. ודאו שציוני המועמדים, היסטוריית אופטימיזציה, רשימות בעיות וספירות איטרציות נרשמו.
   3. ודאו שטלמטריה לפי IOC, כולל שימוש משוער והשהייה בטוקנים, מתועדת.
      הערה. כללי אימות regex מפורטים, נוסחת הניקוד ופרמטרי בקרת איטרציה מפורטים בקובץ המשלים 2.

7. אנליטיקה ואימות

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

8. תוצאות יצוא

1. בלשונית הייצוא, בחר את פורמט הייצוא (טקסט רגיל, JSON או YAML) והורד את ערכת הרגקס. ודאו שהרגקסים המיוצאים כוללים את הציונים והמטא-דאטה של הסיווג הנלווים.
2. הפיק והורידו את דוח ה-JSON המלא הכולל מסמכים מפוזרים, IOCs שחולצו, ייצוגים מנורמלים, רגקסים מועמדים ופלטים סופיים. שמור דוח זה כרשומת שכפול.

9. פתרון תקלות

1. אם שלב 1 מחזיר תוכן PDF מקוצר או ריק, עבדו מראש את המסמך עם ממיר חיצוני או כלי זיהוי תווים אופטי לפני ההעלאה מחדש, וודאו שהארטיפקטים הטכניים נשארים גלויים בתצוגה המקדימה של Markdown.
2. אם שלב 2 מחזיר מעט מדי IOCs קונצנזוס, בדוק את הגדרות הספק, המודל, מפתח ה-API, ספירת החזרה וההצבעות המינימלית לפני שינוי הסף. בדוק מועמדים מודרים כדי להבחין בין הזיות להצבעה קפדנית מדי.
3. אם שלב 4 מסמן את כל הרכיבים כמושלכים, בדוק את הקישוריות של Neo4j ואשר שהגרף מכיל את אוצר המילים הרלוונטי של Path, Register או ממשק שורת פקודה (CLI) עבור סוג ה-IOC הנבדק.
4. אם שלב 5 מייצר רגקס שמבצע קומפילציה אך נכשל בהתאמה או הכללה יתר, יש לבדוק את היסטוריית האופטימיזציה, מיקום הכשל האבחוני ובדיקות הכללה מוגזמת לפני שמחדש את המועמד.

10. אשר את תוצאות הפרוטוקול הסופיות.

1. אשר שקובץ ה-Markdown המנותק, קבוצת ה-IOC (מאומת בהסכמה כאשר הצבעה קבוצתית מופעלת, או מודל יחיד כאשר מושבת), טבלת ה-IOC המסווגת, והייצוגים המנורמליים בגרף – כולם קיימים.
2. אשר שערכת ה-regex התואמת ל-SIEM, תקצירי האנליטיקה ודוח ה-JSON המלא כולם קיימים, וארכב את דוח ה-JSON כרשומת השחזור.

תוצאות

סעיף זה מציג תוצאות מייצגות שנוצרו על ידי פרוטוקול IOC-to-regex ומסכם את הערכת ההתייחסות המשמשת להערכת היישום התפעולי שלו. הערכת הייחוס עיבדה 3,156 דוחות CTI הקשורים לטכניקות MITRE ATT&CK, ניתחה יותר מ-230,000 משפטים, חילצה יותר מ-63,000 מועמדים ל-IOC, והעריכה רגקסים שנוצרו מול יותר מ-2,400 מחרוזות אמת קרקעית שנאספו באופן עצמאי מעשרה תרחישי הערכה של MITRE ATT&CK. מחרוזות האמת הקרקעית הללו הן ארטיפקטים של תקיפה שנבחרו על ידי מומחים, המדווחים באופן עצמאי על ידי ספקי סייבר במהלך תרגילי הערכ...

דיון

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

חומרים

רשימת החומרים שנעשה בהם שימוש במאמר זה

שם	חברה	מספר קטלוג	הערות
Computer (CPU)	—	≥ 4 cores recommended	לא נדרש GPU
LangChain	LangChain	≥ 0.1.x	מסגרת תזמור LLM
LLM (IOC extraction, single-model)	OpenAI	gpt-5.1	משמש לחילוץ IOC (שלב 2) כאשר הצבעה באנסמבל מושבתת. temperature = 0.0; max_workers = 5. נגיש: 2025-12-15.
LLM (Regex generation)	OpenAI	gpt-5.1	משמש לחילוץ regex (שלב 5). temperature = 0.3 לפני אימות מורד. נגיש: 2025-12-15.
LLM (Scalability characterization)	OpenAI	gpt-5.1	משמש לריצת ה-IOC של 6,000 הנדרשת בתוצאות המייצגות. נגיש: 2025-12-15.
Memory (RAM)	—	≥ 16 GB recommended	נדרש לעיבוד מסמכים
Neo4j	Neo4j, Inc.	≥ 5.x	מסד נתונים גרפי לנורמליזציה של IOC
Neo4j Python Driver	Neo4j, Inc.	≥ 5.x	ממשק Python ל-Neo4j
Operating System	Microsoft / Apple / Linux	Windows, macOS, או Linux	תמיכה חוצת פלטפורמות
PDF parsing — primary backend	Microsoft	MarkItDown ≥ 0.0.x	שלב 1 ברקע; ממיר קלט PDF/DOCX/HTML/TXT ל-Markdown. פלט נותח מחולק לגושים של 4,000 תווים לפני עיבוד LLM. נגיש: 2025-12-15. https://github.com/microsoft/markitdown
Pipeline configuration (Stage 2 — IOC extraction)	—	Reference defaults	מצב LLM יחיד: temperature = 0.0, max_workers = 5. ברירת מחדל של מצב הצבעה באנסמבל: repeats = 1 לכל מודל מוגדר, min_votes = 2.
Pipeline configuration (Stage 5 — regex generation)	—	Reference defaults	טמפרטורת יצירה = 0.3. אימות: overgen_random_tests = 5 דגימות שליליות דטרמיניסטיות לכל IOC. גבולות איטרציה: max_iterations = 10, debug_loop_cap = 5, discard_validation_cap = 5.
Python	Python Software Foundation	≥ 3.8	סביבת זמן ריצה נדרשת
Regex Engine	Python Standard Library	מודול re	משמש לאימות ובדיקת regex
Streamlit	Streamlit Inc.	≥ 1.25	ממשק משתמש מבוסס אינטרנט
Reference implementation source code	Authors / GitHub | GitHub repository		קוד מקור לממשק Streamlit, צינור LangChain, נורמליזציה בסיוע Neo4j, יצירת regex, כלי אימות וקבצי תצורה לדוגמה. זמין ב-https://github.com/SOCautomatic/cti-ioc-regex-pipeline. נגיש: 11 ביוני, 2026.