מה זה SIEM? לוגים, שאילתות והתראות

כשצוות אבטחה אומר "ראינו את התקיפה", הכוונה בדרך כלל היא שהתקיפה השאירה רשומות בכמה מקומות, ומערכת אספה את הרשומות האלה והרימה דגל. המערכת הזאת היא לרוב SIEM, קיצור של security information and event management. חלק גדול מהעבודה היומיומית של SOC מתחיל שם: אנליסט פותח התראה, בודק את האירועים שמאחוריה ומחליט אם מישהו צריך לפעול.

המאמר הזה מסביר מה SIEM עושה, שלב אחר שלב. הוא מכסה מאיפה הנתונים מגיעים, למה צריך לעצב לוגים מחדש לפני שהם שימושיים, איך חוקי קורלציה הופכים אירועים להתראות, ומה קורה אחרי שהתראה עולה. הוא מראה גם איפה SIEM נמצא לצד כלי EDR ו-SOAR, וממפה התראה לדוגמה לטכניקה של MITRE ATT&CK כדי לראות איך זיהוי מתחבר להתנהגות תוקף.

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

#מה זה SIEM

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

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

המילה "security" בשם חשובה פחות מהמילה "event". SIEM לא יודע כברירת מחדל מהו אירוע רע. הוא מכיר את האירועים ששולחים לו ואת החוקים שכותבים לו. האיכות שלו תלויה בנתונים שנכנסים ובזיהויים שרצים מעליהם.

#למה זה חשוב

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

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

#הצינור: מקורות, איסוף, נרמול

SIEM עובד בשלבים. כל שלב יכול להישבר, ובעיות זיהוי רבות מקורן באחד מהם.

#מקורות לוג

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

• מערכות הפעלה: אירועי אימות, יצירת תהליכים, שינויים בשירותים, הפעלה וכיבוי.
• מערכות זהות: התחברויות ל-directory, בקשות multi-factor ושינויי חשבון.
• ציוד רשת: רשומות allow ו-deny של חומת אש, סשני VPN ושאילתות DNS.
• אפליקציות: לוגי גישה של שרתי web, שגיאות אפליקציה ופעולות ניהול.
• פלטפורמות ענן: פעילות control-plane, כמו קריאות API שיוצרות, משנות או מוחקות משאבים.
• כלי endpoint: טלמטריית EDR, כשהיא קיימת.

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

#איסוף

איסוף מעביר רשומות מהמקור ל-SIEM. השיטות הרגילות הן agent שמותקן על המארח, forwarder שקורא קובצי לוג, הודעות syslog שנשלחות ברשת, או API שמושך אירועים משירות ענן. agents יכולים ללכוד יותר פרטים מהמארח. Syslog פשוט ונתמך באופן נרחב, אבל הוא יכול לאבד הודעות תחת עומס אם שום דבר לא מחזיק אותן בחוצץ.

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

#נרמול

כל מקור משתמש בפורמט משלו. מערכת אחת כותבת את שם המשתמש בשדה user, אחרת בשדה account, ושלישית בשדה subject.name בתוך JSON מקונן. נרמול ממפה את השדות האלה לסכמה משותפת אחת, כך שחוק יכול לומר "שדה המשתמש" ולהתכוון לאותו דבר בכל מקור.

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

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

#שמירת נתונים

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

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

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

#חוקי קורלציה, התראות וטריאז׳

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

הנה חוק בשפה פשוטה ל-password spraying. נבדוק אותו בסעיף המעשי.

Group events by source IP over a 10-minute window.
Count distinct user accounts with a failed login from that source.
If the count is 4 or more, and the same source later has a successful login,
create an alert with the source IP, the accounts and the successful login.

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

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

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

#איפה SIEM נמצא לצד EDR ו-SOAR

שלושה מונחים עולים יחד ברוב ה-SOCs, והתחומים שלהם חופפים.

SIEM אוסף ומצליב רשומות ממקורות רבים בסביבה. החוזק שלו הוא רוחב והיסטוריה. המגבלה שלו היא שהוא רואה רק את מה שכל מקור מדווח.

EDR, ‏endpoint detection and response, עוקב בפירוט אחרי נקודות קצה. הוא רושם פעילות תהליכים, שינויי קבצים וחיבורי רשת בכל מארח, ולעיתים קרובות יכול לבודד מחשב. החוזק שלו הוא עומק בנקודת הקצה. הוא לא רואה לוג של חומת אש או מסלול ביקורת בענן אלא אם מחברים אותו אליהם.

SOAR, ‏security orchestration, automation and response, מריץ playbooks. playbook יכול להעשיר התראה בבדיקת מוניטין, לפתוח כרטיס, להשבית חשבון אחרי אישור או להודיע לתורן. החוזק שלו הוא תגובה שאפשר לחזור עליה. התוצאות שלו תלויות באיכות ההתראות שהוא מקבל.

#תרגיל מעשי עם לוגים סינתטיים

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

שומרים את זה בשם siem_demo.py:

# Synthetic logs only. 192.0.2.0/24 is a documentation range (TEST-NET-1).
import re
from collections import defaultdict

RAW = """\
2026-11-07T10:00:01Z sshd[811]: Failed password for alice from 192.0.2.44 port 50111
2026-11-07T10:00:03Z sshd[812]: Failed password for bob from 192.0.2.44 port 50112
2026-11-07T10:00:05Z sshd[813]: Failed password for carol from 192.0.2.44 port 50113
2026-11-07T10:00:07Z sshd[814]: Failed password for dave from 192.0.2.44 port 50114
2026-11-07T10:00:09Z sshd[815]: Failed password for erin from 192.0.2.44 port 50115
2026-11-07T10:00:11Z sshd[816]: Accepted password for erin from 192.0.2.44 port 50116
2026-11-07T10:02:00Z sshd[820]: Accepted password for frank from 192.0.2.10 port 50200
2026-11-07T10:03:00Z sshd[821]: Failed password for frank from 192.0.2.10 port 50201
"""

PATTERN = re.compile(
    r"^(?P<ts>\S+) sshd\[\d+\]: (?P<outcome>Failed|Accepted) password for "
    r"(?P<user>\S+) from (?P<src>\S+) port \d+$"
)

def normalize(line):
    m = PATTERN.match(line)
    if not m:
        return None
    return {
        "timestamp": m["ts"],
        "event_type": "authentication",
        "outcome": "success" if m["outcome"] == "Accepted" else "failure",
        "user": m["user"],
        "source_ip": m["src"],
    }

events = [e for e in (normalize(l) for l in RAW.splitlines()) if e]
print(f"normalized {len(events)} events")

# Rule: one source IP fails against 4+ different accounts, then gets a success from that IP.
fails = defaultdict(set)
successes = defaultdict(list)
for e in events:
    if e["outcome"] == "failure":
        fails[e["source_ip"]].add(e["user"])
    else:
        successes[e["source_ip"]].append(e)

for ip, users in fails.items():
    if len(users) >= 4 and successes.get(ip):
        s = successes[ip][0]
        print(f"ALERT src={ip} failed_accounts={len(users)} then_success_user={s['user']} at={s['timestamp']}")
        print("  mapped: T1110 Brute Force, sub-technique T1110.003 Password Spraying (candidate)")

מריצים מהתיקייה שבה הוא נשמר:

python -I siem_demo.py

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

על מחשב Windows 11 שבו נבדק המאמר, עם Python 3.12.10, הפלט היה:

normalized 8 events
ALERT src=192.0.2.44 failed_accounts=5 then_success_user=erin at=2026-11-07T10:00:11Z
  mapped: T1110 Brute Force, sub-technique T1110.003 Password Spraying (candidate)

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

#קריאת הפלט

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

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

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

#מיפוי ההתראה ל-ATT&CK

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

ההתראה מתאימה ל-T1110, ‏Brute Force, תחת הטקטיקה Credential Access. ATT&CK מתאר brute force כניסיונות חוזרים לגשת לחשבונות כשהתוקף לא יודע את הסיסמה. הוא מונה ארבע תת־טכניקות. Password Spraying ‏(T1110.003) פירושו ניסיון של סיסמה אחת או כמה מול חשבונות רבים, וכך נמנעת נעילה של חשבון בודד. Password Guessing ‏(T1110.001) מנסה סיסמאות רבות מול חשבון אחד. Credential Stuffing ‏(T1110.004) משתמש שוב בסיסמאות שדלפו משירותים אחרים. הדף מפנה גם לאסטרטגיית זיהוי שמצליבה כישלונות אימות בין פלטפורמות, וזה אותו רעיון כמו החוק הקטן שלנו.

כדאי לשים לב למילה "candidate" בפלט. החוק מזהה דפוס, והדפוס מתאים ל-spraying. הוא מתאים גם לשירות שהוגדר לא נכון ומנסה כמה פרטי התחברות שמורים, או לבדיקה פנימית. הטריאז׳ צריך לבדוק במה מדובר. המיפוי ל-ATT&CK אומר איפה לחפש ואיזו התנהגות קשורה לבדוק הלאה, כמו שימוש בחשבונות תקפים (T1078) אחרי התחברות מוצלחת. הוא לא מוכיח שהתקיפה קרתה.

#דרכים חינמיות לתרגל

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

#Wazuh

התיעוד של Wazuh מתאר אותה כפלטפורמת אבטחה חינמית בקוד פתוח שמאחדת יכולות XDR ו-SIEM. יש לה שלושה רכיבים מרכזיים, Wazuh indexer, ‏Wazuh server ו-Wazuh dashboard, ועוד agent אוניברסלי שמותקן על המערכות המנוטרות. מדריך ההתחלה מציע quickstart שמתקין את ה-stack בתוך כמה דקות. הוא מתעד גם התקנות שלב אחר שלב, מכונות וירטואליות, Docker ו-Kubernetes. כדאי לבדוק בתיעוד הנוכחי את הגרסה והפקודות המדויקות, כי הן משתנות בין מהדורות.

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

#Elastic

Elastic Security מתעד SIEM שבנוי על Elastic Stack. הסקירה שלו מתארת איסוף נתונים דרך integrations ו-Elastic Agent, זיהוי עם חוקים מובנים, חוקים מותאמים ו-machine learning, טריאז׳ התראות, Timeline לציד איומים ו-Cases לתיעוד חקירות. אילו מהיכולות האלה נכללות בהתקנה בניהול עצמי תלוי בדרגת הרישיון, ולכן קוראים את דף המנויים של Elastic לפני הפריסה. הסקירה לא מפרטת אילו יכולות SIEM מקבלת התקנה בניהול עצמי ללא תשלום, ולכן אין להניח שדרגה חינמית מכסה יכולת זיהוי מסוימת.

#טעויות נפוצות

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

#איך ממשיכים

מתחילים מהמדריך NIST SP 800-92. הוא ארגוני וברמה גבוהה, ולכן קוראים אותו בשביל השאלות שהוא שואל, כמו מי הבעלים של כל מקור לוג וכמה זמן שומרים אותו. אחר כך פותחים את דף ה-ATT&CK של T1110 וקוראים את הערות הזיהוי ליד תת־הטכניקות.

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

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

#מקורות

• NIST SP 800-92, Guide to Computer Security Log Management
• MITRE ATT&CK
• Wazuh documentation: getting started
• Elastic Security documentation: Elastic Security overview