פיתוח מערכת SIEM עם זיהוי איומים מבוסס AI

מדוע הכללים לא מצליחים לעמוד בקצב ההתקפות: היכן נשברת ה-SIEM

מערכת SIEM קלאסית נשענת על כללי קורלציה: המהנדס מתאר תנאי — "N כניסות כושלות בחלון זמן T מכתובת אחת" — והכלל מופעל כאשר מתקיימת התאמה. המודל שקוף וצפוי כל עוד התשתית יציבה וזרם האירועים הומוגני. הבעיה היא ששני התנאים מפסיקים להתקיים כמעט מיד לאחר ההפעלה.

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

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

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

מה נותנת זיהוי AI: אפקט מדיד עבור SOC

התראות שווא יורדות פי כמה

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

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

זמן התגובה של SOC מתקצר

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

גילוי אנומליות במקום תבניות מוכרות

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

נעלם סוג הכשל "החמצנו, כי לא הגדרנו חוק"

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

החקירה נשענת על נתונים, ולא על זיכרון

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

אפשרויות בנייה: מפיתוח עצמאי ועד להיברידי

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

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

מודל היברידי סוגר זאת אחרת: איסוף, נרמול ואחסון נשארים על מנוע מוכן, ושכבת זיהוי ה-AI — מודלים של אנליטיקה התנהגותית, ניקוד אנומליות, העשרה בהקשר — נבנית על ידינו. אפשרות כזו מעניקה שליטה על לוגיקת הזיהוי בלי סיכון לשכתב מאפס את כל תשתית ה-SOC.

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

שלבי הטמעת זיהוי AI במתאר הניטור

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

לאחר מכן בונים את סכמת הזרימות ורק אחר כך מחברים את הזיהוי — כך התוצאה משוחזרת ולא אקראית.

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

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

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

תוצרי פלט: תצורות, תרשימים, נהלים

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

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

המערך נמסר במאגר שלכם ובתשתית שלכם — בלי תלות בנו. תארו את המשימה, ונחזור עם הערכה ותוכנית: אילו מקורות מחברים ראשונים ואילו זיהויים מכסים את התרחישים המרכזיים שלכם.

מקרה בוחן: צמצום התראות שווא פי שלושה במחזור אחד

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

מה שינו

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

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

מדדים לפני ואחרי

MITRE ATT&CK שימשו כבסיס לסימון הטכניקות — זה נתן שפה משותפת בין המודל, חוקי המתאם והאנליסטים בעת טיפול באירוע.

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

במה שונה אנליטיקה התנהגותית מקורלציה של חוקים

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

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

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

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

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

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

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

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

ספקות טכניים נפוצים לפני תחילת העבודה

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

נצברו אצלנו מעט נתונים היסטוריים — האם המודלים בכלל יתאמנו?

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

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

האם נצטרך לרכוש ציוד חדש לעומס?

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

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

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

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

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

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