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

סיכום

כאן, אנו מציגים פרוטוקול להמרת אינדיקטורים של פריצה ממסלולי קבצי דוחות מודיעין איומי סייבר, מפתחות רישום ומדדי שורת פקודה לביטויים רגולריים מאומתים לכללי זיהוי מידע אבטחה וניהול אירועים (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. מחרוזות האמת הקרקעית הללו הן ארטיפקטים של תקיפה שנבחרו על ידי מומחים, המדווחים באופן עצמאי על ידי ספקי סייבר במהלך תרגילי הערכת MITRE ATT&CK, ולכן משקפים את הדפוסים המבניים שאנליסטים וספקים אנושיים מתעדים בפועל. התוצאות הבאות מתמקדות בהתנהגות זרימת עבודה, נכונות מבנית ותוצאות הערכה הרלוונטיות לניתוח וזיהוי יומן תפעולי.

סקירה של צינור הקצה לקצה מוצגת באיור 1, המסכם את שלבי מציאת קבוצת הלכידה ויצירת רגקס שמסגרים את שאר התוצאות המייצגות.

שלב 1: פלט ניתוח מסמכים

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

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

שלב 2: חילוץ מבוסס קונצנזוס ב-IOC

איור 3 ממחיש את התפוקה של שלב 2, שבו מופקים מועמדים IOC באמצעות הצבעה אנסמבלית רב-LLM. הממשק המתקבל מציג אוסף IOC בפורמט JSON, עם הערות עם ספירות קולות ומודלים תורמים.

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

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

טבלה 2 מסכמת את התפוקה הצפויה, שלבי אימות אוטומטיים ובדיקות בקרת איכות מול אנליסטים עבור כל שלב פרוטוקול.

איור 4 מציג את המועמדים של ה-IOC שלא עמדו בסף הקונצנזוס במהלך ההצבעה הקבוצתית בשלב 2 ושהממשק מופיע לבדיקת אנליסטים. מועמדים כאלה בדרך כלל משקפים הזיות ספציפיות למודל או קטעי טקסט מעורפלים. איור 4 ואיור 5 מתייחסים אפוא לפלטים שלבים נפרדים — הסט שהושלכו משלב 2 והסט השמור משלב 3 — ולא לתצוגות חלופיות של אותו תהליך שלב 3.

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

שלב 4: נרמול IOC בסיוע גרף בין סוגי IOC

איורים 6, איור 7 ואיור 8 ממחישים תוצאות נורמליזציה מייצגות עבור שלוש קטגוריות IOC שנדונו במחקר הנוכחי: נתיבי קבצים, מפתחות רישום ומדדי שורת פקודה. לכל קטגוריה, הנתונים משווים בין ה-IOC המקורי שהופק מדוח CTI לבין הייצוג המנורמל שנוצר באמצעות ניתוח בסיוע גרפים.

בכל סוגי ה-IOC, הפרוטוקול מפרק כל IOC לרכיבים סמנטיים ופותר קשרים היררכיים באמצעות ידע מובנה המקודד במסד הנתונים של הגרפים. במימוש הנוכחי, Neo4j מאחסן צמתים של נתיב, רישום ו-CLI מנורמלים ומשתמש בקשרי שכנות כדי לבדוק האם רכיבים שייכים לשרשראות מוכרות. תפקיד זה דומה לשימוש בידע מובנה של ATT&CK במהלך הנדסת גילוי².

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

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

שלב 5: יצירת ביטויים רגולריים עם בחירה מבוססת אילוצים עזר

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

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

כאשר מספר מועמדים עומדים בבדיקות האימות הבסיסיות, הפרוטוקול מפעיל מנגנון בחירה עזרי מבוסס מגבלות כדי לשמור על רגקס מייצג לשימוש במורד הזרם. היישום הנוכחי מעניק למועמדים ציון 'ציון = n_cg - n_wc', כאשר 'n_cg' הוא מספר רכיבי השמירה המיוצגים ו-'n_wc' הוא מספר האסימונים שהושלכו או לא ממופים שנמצאים ב-regex.

פונקציית הבחירה מוגדרת כך:

ניקוד = n_cg − n_wc

זוהי ההתמחות במשקל שווה (α = β = 1) של הצורה הכללית יותר Score = α·n_cg − β·n_wc. כאן, n_cg מציין את מספר רכיבי השמירה המיוצגים ו-n_wc מציין את מספר הרכיבים שהושלכו או טוקנים נוספים לא ממופים שהוחזרו על ידי הרגקס. המימוש גם מתעד ספירות איטרציות, רשימות הוצאות, צריכת טוקנים מוערכת, שימוש במטמון וטלמטריית השהייה עבור כל IOC. הגדרת המשקל השווה שימשה כברירת מחדל דטרמיניסטית פשוטה למימוש ההפניה; מכיוון שהוא מתייחס לרכיב שמירה חסר ולרכיב שהוחזר כבלתי רצויים באותה מידה, משקלים אחרים עשויים להיות מועדפים בהקשרי פריסה שבהם שליליות שגויות וחיוביות שגויות נושאות עלויות תפעול שונות.

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

סקירה אנליטית של עיבוד CTI

איור 10 מספק סקירה של תוצאות ניתוח CTI בכל המסמכים המעובדים. בהערכת ההתייחסות, חילוץ IOC מעל 3,156 דוחות CTI הניב יותר מ-63,000 מועמדים ל-IOC, כולל 12,195 מסלולי קבצים, 2,302 מפתחות רישום ו-10,286 מדדי שורת פקודה, כאשר המועמדים הנותרים שייכים לסוגי IOC שאינם יעדי רגקס.

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

בהערכת הייחוס, רגקסים שנוצרו הוערכו מול יותר מ-2,400 מחרוזות אמת קרקעית שנאספו באופן עצמאי מעשרה תרחישי הערכה של MITRE ATT&CK והשיגו שיעור פגיעה ממוצע של 99.1% יחד עם שיעור אי-התאמה ממוצע בין IOC של 0.8%. במאמר זה, שיעור אי-התאמה משמש כמדד ספציפיות סמנטית: אי-התאמה מתרחשת כאשר regex שנוצר עבור IOC אחד תואם גם מחרוזת אמת בסיסית הקשורה ל-IOC אחר. כמות זו לא צריכה להתפרש כשיעור התרעה תפעולי שגוי-חיובי מקצה לקצה, שתלוי גם בלוגיקת הכללים במורד הזרם ובהקשר הפריסה.

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

ניתוח פעולות אופטימיזציה של רגקס

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

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

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

אפיון סקלביליות נפרד על מדגם אקראי של 6,000 IOCs שנוצרו באמצעות LLM בדיקת הסקלאביליות (ראו טבלת חומרים) דיווח על השהיה חציונית של 2.95 שניות לכל IOC והשהייה ממוצעת של 23.18 שניות. באותו אפיון, קומפילציה של רגקס תקף בתחביר הגיעה ל-99.56%, הצלחת הייצור הכוללת הגיעה ל-99.4%, השימוש הממוצע המשוער באסימונים היה כ-3,986 טוקנים לכל IOC, וזרימת העבודה דרשה בממוצע כ-7.89 שיחות LLM לכל IOC. שיעורי ההצלחה במעבר ראשון היו 56.46% בלולאת ההתאמה-ניפוי שגיאות ו-72.92% בלולאת אימות שאינה קבוצת לכידה. מדידות אלו מסייעות לאפיין עלות חישובית ותפוקה תפעולית לשימוש באצוות.

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

ראיות מבצעיות וטיפול בכשלים. איור 12 מציג את מבנה קובץ ה-SIEM regex המיוצא שנוצר על ידי הפרוטוקול, יחד עם ראיות אימות ברמת הכלל עבור תבניות נתיב קובץ מייצג, מפתח רישום ושורת פקודה. איור 13 מציג את דוח ה-JSON המלא המתאים, שמציג את כל פלטי השלבים (IOCs שהופצו, נותחו וננורמו יחד עם דפוסי regex שנוצרו ודגלי אימות לכל IOC) והוא הפריט העיקרי שכלים צורכים במורד הזרם. איור 14 ממחיש את הטיפול של הפרוטוקול בקלט CTI רועש: נתיב קובץ מנותק, מופרע ברווחים לבנים, מסומן בשלב הניתוח, מתוקן, מנורמל לתבנית הקנונית %TEMP%, ואז מומר לרגקס קומפילציה ותואם. דוגמה עובדת זו משלימה את הראיות התפעוליות באיור 12 ובאיור 13 על ידי תיעוד האופן שבו הפרוטוקול מתנהג כאשר הטקסט הגולמי של ה-IOC סוטה מהצורה הקנונית.

איור 1: הארכיטקטורה הכוללת של פרוטוקול IOC-to-regex. התרשים מסכם את הצינור מקצה לקצה. מחרוזות IOC מועמדות המיוצרות על ידי מחלץ ה-IOC במעלה הזרם מפורקות ומושווים מול צמתים ייחוס בגרף Neo4j המאוכלס מתיעוד Windows (שלב 1), שאוסף רכיבי נתיב, רישום ושורת פקודה ידועים (שלב 2). קטעים משתנים או ספציפיים לסביבה מסומנים כמושלכים ומוחרגים מהבנייה המנורמלת תוך שמירה במטא-דאטה של הרכיבים, מה שמוביל ל-IOC מנורמל עם תוויות שמירה והשלכה ברמת הרכיב (שלב 3). ה-IOCs המנורמלים הללו מועברים לשלב יצירת רגקס מבוסס LLM (שלב 4) שמייצר ביטויים רגולריים מועמדים, אשר מדורגים ומותאמים באופן איטרטיבי מול מגבלות קבוצת לכידה וכללי טוקנים שנזרקו (שלב 5) לפני בחירת רגקס סופי (שלב 6). אנא לחצו כאן כדי לצפות בגרסה מוגדלת של הדמות הזו.

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

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

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

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

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

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

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

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

איור 10: התפלגות ה-IOCs שהופקו בין דוחות CTI. סיכום תוצאות חילוץ ה-IOC המציג את המספר הכולל של המדדים שזוהו בדוחות CTI ואת התפלגותם בין נתיבי קבצים, מפתחות רישום ומדדי שורת פקודה. תפיסה זו מספקת אימות ברמה גבוהה של כיסוי תוכן CTI והתנהגות החילוץ. אנא לחצו כאן כדי לצפות בגרסה מוגדלת של הדמות הזו.

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

איור 12: קובץ regex מייצא נציג. תוכן הדוגמה של ייצוא רגקס SIEM (siem_rules.txt) שנוצר על ידי הפרוטוקול. כל רשומה כוללת את ה-IOC המקור, את הקטגוריה המוסקת (נתיב קובץ, מפתח רישום או שורת פקודה), ואת דפוס הרגקס המאומת. טבלת האימות המצורפת מסכמת את ההתנהגות הצפויה ואת הראיות המערכתיות המשמשות לאישור נכונות לכל סוג חוק. אנא לחצו כאן כדי לצפות בגרסה מוגדלת של הדמות הזו.

איור 13: דוח JSON מלא של הנציג. פלט צינור מקצה לקצה שנוצר לאחר הרצת כל חמשת שלבי הפרוטוקול על דוח CTI מייצג. מסמך ה-JSON מתעד את קובץ המקור, ספירת חתכים מנותחים, IOCs שחולצו מקובצים לפי קטגוריה, רשומות מסווגות שלב 3 עם תגי מקור, diff נרמול שלב 4, ודפוסי regex שלב 5 עם דגלי אימות לפי IOC. הדוח גם חושף מטא-דאטה של הצלחה ושגיאות ברמה העליונה שמאפשרת לכלים במורד הזרם לזהות כשלים חלקיים. אנא לחצו כאן כדי לצפות בגרסה מוגדלת של הדמות הזו.

איור 14: קלט כושל או רועש: זיהוי ותיקון. דוגמה עובדת לאופן שבו הפרוטוקול מזהה ומתאושש מ-IOC רועש. הקלט הגולמי %T E M P%\malware[.]ה-exe מסומן כי האסימון של משתנה הסביבה שלו מכיל רווחים שהוכנסו וסיומת הקובץ שלו הוסרה מחדש. שלב התיקון מסיר את הרווח הלבן שהוכנס ומחזיר את הנקודה המילולית; נרמול שלב 4 מרחיב אז את %TEMP% לתבנית תיקיית Temp הקנונית של Windows; ושלב 5 מייצר regex שמרכיב ומתאים ל-IOC המנורמל המתוקן. דוגמה זו ממחישה את הטיפול בקלט רועש שנדון בדיון. אנא לחצו כאן כדי לצפות בגרסה מוגדלת של הדמות הזו.

אלמנט	סוג	ערך / סכימה	דוגמה	הערות
תווית צומת	תווית	:P את'	Windows, System32, cmd.exe	מאחסן רכיבי נתיב קבצים של Windows
תווית צומת	תווית	:רישום	תוכנה, מיקרוסופט, Windows NT	מאחסן רכיבי מפתח רישום מתחת לכוורות שורש
תווית צומת	תווית	:CLI	powershell.exe, -ExecutionPolicy, עקיפה	שומר טוקנים ופרמטרים של פקודות
תכונת צומת	מיתר	שם	cmd.exe	מעטפת מקורית; משמש להצגה בפלט מנורמל
תכונת צומת	מיתר	name_lower	cmd.exe	צורה קטנה; משמש כמפתח חיפוש לכל שאילתות MATCH
מערכת יחסים	קצה מכוון	(א)-[:הבא]->(ב)	(Windows)-[:NEXT]->(System32)	שתי נקודות הקצה חולקות את אותה תווית; מקודד שכנות מקורית במערכות Windows
אילוץ	ייחודיות	n.name_lower ייחודי לכל תווית	-	מיושם ל-:P ath, :Registry, :CLI
מקור הנתונים	כיסוי	Windows 8, 10, 11	-	מערכת ההפעלה של הלקוח מאוכלסת בגרף
מקור הנתונים	כיסוי	Windows Server 2012, 2016, 2019, 2022	-	מערכת ההפעלה של השרת מאוישת בגרף

טבלה 1: סכמת גרף Neo4j המשמשת לנרמול IOC (שלב 4). מפרטת את שלוש תוויות הצמתים (Path, Registry, CLI), את סכמת המאפיינים המשותפת (name, name_lower), את יחס השכנות המכוונת המשמשת לסדר קצוות מקורי, מגבלות ייחודיות, ואת גרסאות הלקוח והשרת של Windows שממלאות את הגרף.

במה	תפוקה צפויה	אימות אוטומטי	בקרת איכות מול אנליסטים
שלב 1: ניתוח מסמכים	טקסט מאוחד של Markdown, מחולק ל-4,000 תווים לפני עיבוד LLM.	—	בדיקה ויזואלית של תצוגה מקדימה של Markdown לאישור שמסלולי קבצים, מפתחות רישום, קטעי שורת פקודה וגבולות מקטעים שורדים את הניתוח; החלף את הצד האחורי אם מחרוזות טכניות מקוצרות.
שלב 2: חילוץ IOC	JSON עם שלושה מפתחות ברמה העליונה (נתיבי קבצים, שורות פקודה, מפתחות רישום); ספירת קולות לפי IOC ומטא-נתונים של מודל תורם כאשר הצבעה קבוצתית מופעלת.	מסנן סף הקונצנזוס (min_votes) אינו כולל IOCs שספירת הקולות שלהן נמוכה מסף ההגדרה.	בדיקת מועמדים מודחים כדי להבחין בין הזיות להצבעה קפדנית מדי לפני התאמת min_votes.
שלב 3: ניתוח וסיווג של ה-IOC	רשימת IOC מסווגת: כל IOC משולב עם קטגוריה סטנדרטית, תג מקור, ומפתח חילוץ מקורי כאשר זמין.	מיפוי קטגוריות סטנדרטי באמצעות כללים מבוססי רגקס והיוריסטיקות דפוסי IOC; (IOC, קטגוריה) ניתוק זוגות.	בדיקת תוצאה מסווגת עבור מועמדים עמומים או רועשים (איור 4A).
שלב 4: נרמול בסיוע Neo4j	טופס מנורמל לפי IOC עם תוויות שמירה/השלכה ברמת הרכיב.	Cypher שאילתות (i)-(iii) מעל גרף הפניות של Windows; גיבוי קדם-עיבוד דטרמיניסטי כאשר Neo4j אינו זמין.	בדיקת כל מקרים של השלכה לזיהוי פערי כיסוי גרפי; הרחבת נתוני גרף עם הפניות ספציפיות לספקים או לסביבה בעת הצורך.
שלב 5: יצירת רגקס וניקוד	regex סופי לכל IOC עם ציוני מועמדים, היסטוריית אופטימיזציה, ספירת איטרציות וטלמטריה לכל IOC.	בדיקת התאמה, בדיקות איכות סטטית, בדיקת אסימון אסור מודע לגבולות, בדיקת הכללה יתר מול 5 דגימות שליליות דטרמיניסטיות; חזרה למשחק חלקי עם הניקוד הגבוה ביותר (דגל used_fallback).	סקירת היסטוריית אופטימיזציה עבור רגקסים חלופיים; בדיקת אבחון לפי מיקום כשל לפי IOC לפני ההתחדשות.

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

קובץ משלים 1: הנחיות למודל LLM מילה במילה. המערכת המילה במילה וההנחיות האנושיות המשמשות להפקת IOC שלב 2 וליצירת regex ואופטימיזציה של שלב 5. אנא לחצו כאן להורדת הקובץ הזה.

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

דיון

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

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

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

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

ניתן להשוות את הפרוטוקול לשלוש משפחות של שיטות חלופיות. ראשית, שיטות סינתזת רגקס מבוססות דוגמאות כמו TransRegex¹¹ ו-Regex+¹² לומדות רגקסים מתוך קבוצות מובחנות של דוגמאות מיתרים חיוביות ושליליות. שיטות אלו מתפקדות היטב כאשר קיימות מערכות דוגמאות מייצגות אך הן פחות ישימות ישירות להקשרים של SOC, שבהם כל IOC המדווח ב-CTI מופיע בדרך כלל כמחרוזת מייצגת אחת, וגבול ההכללה הנדרש מונע על ידי סמנטיקה תפעולית ולא על ידי כיסוי דוגמאות. שנית, גישות לתכנות גנטי כמו אלו שהוצגו על ידי ברטולי ^{ואחרים.13,14} מחפשות את מרחב הרגקסים דרך אופרטורים אבולוציוניים ובדרך כלל דורשות קורפוס מתויג של מחרוזות התאמה ולא תואמות; הם מתאימים היטב לבניית דפוסי חילוץ באצווה אך אינם צורכים ישירות נרטיבים לא מובנים של CTI. שלישית, גישות עצביות ומבוססות LLM עדכניות^15,16 מתרגמות תיאורים בשפה טבעית ישירות למחרוזות רגקס; שיטות אלו עוצמתיות להנחיות מוגדרות היטב, אך בשימוש בזריקה אחת, עשויות לייצר רגקסים תקפים תחבירית אך מפספסים רכיבי קבוצת לכידה נדרשים או להכליל יתר על המידה בין גרסאות IOC שאינן קשורות. הפרוטוקול הנוכחי משלים את ההוראות הללו על ידי (i) לקיחת דוחות CTI לא מובנים במקום ערכות דוגמאות מובחנות או שאילתות בשפה טבעית כקלט, (ii) פירוק כל IOC לרכיבי שמירה והשלכה באמצעות נרמול בסיוע גרף לפני יצירת regex, ו-(iii) אימות כל regex מועמד באמצעות בדיקות התאמה דטרמיניסטית, השלכה והכללה יתר בתוך לולאת איטרטיבית מוגבלת. המטרה אינה להעלות על שיטות קודמות במדדים שלהן, אלא לספק צינור IOC ל-regex שניתן לשחזור, שהחלטות הביניים שלו ניתנות לבדיקה וביקורת על ידי אנליסטים של SOC.

הפרוטוקול מניח מספר הנחות לגבי איכות דוחות הקלט של CTI. היא מניחה ש-(i) מחרוזות IOC מופיעות בצורה טקסטואלית ניתנת לשחזור לאחר ניתוח מסמכים, כלומר נתיבי קבצים, מפתחות רישום ואינדיקטורים בשורת פקודה אינם מוטמעים אך ורק בתמונות, צילומי מסך או קידודים מוסתרים; (ii) קטעי IOC המדווחים ב-CTI שלמים מספיק כדי לשמר את העוגנים המבניים שלהם (לדוגמה, מפתחות הרשומה שומרים על קידומת הכוורת שלהם, נתיבי הקבצים שומרים לפחות עוגן תיקייה אחד המזוהה בגרף התיעוד של Windows, ושורות הפקודה שומרות על קובץ ההפעלה הקריאה או הפניה למודול ידוע); ו-(iii) ה-IOCs המדווחים אינם מקוצרים, מצונזרים או נכתבים מחדש בדרכים שמסירות את רכיבי קבוצת הלכידה שעליהם הפרוטוקול מסתמך. דוחות CTI שמקיימים הנחות אלו כוללים את רוב תיאורי טכניקת MITRE ATT&CK, ייעוץ ספקים, כתבי תגובה לאירועים והודעות איומים מעוצבות היטב. דוחות התלויים בעיקר על צילומי מסך, רשימות IOC מקוצרות מאוד ללא הקשר סביבי, או פרפראזות חופשיות ללא מחרוזות IOC מפורשות, נמצאים מחוץ לתחום הפעולה המיועד ויש לצפות מהם להפחית את שחזור החילוץ ולנורמליזציה פחות נאמנה; דוחות כאלה עשויים להפיק תועלת מעיבוד מוקדם של תמונה לטקסט או סקירת אנליסט לפני כניסה לצינור הצינור.

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

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

מספר מצבי כשל ניתנים לשחזור ניתנים לטיפול ברמת השלב שבו נוצרו. שלב 1 כשלים בניתוח (למשל, קבצי PDF סרוקים שמייצרים Markdown ריקים או מעוותים): עיבוד מוקדם של הקלט באמצעות זיהוי תווים אופטי או ממיר חיצוני לפני העלאה מחדש; וודא שמספר החתכים המנותקים וסך התווים אינם אפסיים לפני הממשיכים. כישלונות חילוץ בשלב 2 (לא הוחזרו IOCs, או רשומות הזיות): הגדלת סף ההצבעה הקבוצתית (מינימום הצבעות ≥ 2), הפעלת מופעי מודל נוספים, או הורדת טמפרטורת ה-LLM; אמת קישוריות API ושהמודל המוגדר מקבל פלט בפורמט JSON. נרמול שלב 4 עם תוויות השלכה מלאה (כל רכיב IOC מסומן כ'השלכה'): הרחבת גרף הייחוס של Neo4j עם רכיבי נתיב ושורשי רישום ספציפיים ליצרן או סביבה; סקריפטי הייבוא של Cypher וכלל ההחלטה לשמור/השלכה מפורטים בקובץ המשלים 2. כישלונות רגקס בשלב 5 (used_fallback = דחיות אמיתיות, או דחיות אימות השלכה חוזרות): בדקו את שדה היסטוריית האופטימיזציה לפי IOC כדי לזהות את המאמת הכושל; אם ל-IOC באמת חסרים רכיבי שמירה יציבים, שקול כתיבת regex ידנית עבור אותו IOC או החריגו מיצירת חוקים אוטומטית תוך שמירה בטבלת ה-IOC המסווגת לסקירת אנליסטים.

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

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

חומרים

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

שם	חברה	מספר קטלוג	הערות
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.