סייבר ואבטחת מידע · siem-detection

מה זה SIEM ואיך הוא עובד מאיסוף לוגים ועד Incident

מאת תאיר מלכא 7 דק׳ קריאהפורסם: 5 באוגוסט 2026

המחשה חזותית מקצועית בנושא מה זה SIEM בתחום SIEM וזיהוי

תשובה מהירה

SIEM — Security Information and Event Management — היא מערכת שמרכזת נתוני אבטחה ממקורות רבים, הופכת רשומות שונות למידע שניתן לחפש ולהשוות, מריצה לוגיקת זיהוי ומארגנת ממצאים כתראות או Incidents לחקירה. הערך אינו בעצם שמירת הלוגים, אלא ביכולת לחבר זמן, משתמש, נכס, כתובת IP והתנהגות לכדי סיפור שהאנליסט יכול לאמת ולפעול לפיו.

ארגון מודרני מייצר נתוני אבטחה כמעט בכל שכבה: תחנות קצה, שרתים, Active Directory, שירותי ענן, אפליקציות, Firewall, VPN, DNS, מערכות דואר ומוצרי EDR. כל מקור מדבר בשפה אחרת. אירוע התחברות עשוי להופיע עם שם משתמש בפורמט אחד ב-Entra ID, בפורמט אחר ב-Windows ובמזהה שלישי באפליקציה עסקית. בלי שכבה שמרכזת ומקשרת את המידע, אנליסט נאלץ לעבור בין מסכים ולבנות ידנית את התמונה.

מערכת SIEM נועדה לפתור את בעיית הפיזור. היא קולטת Telemetry, שומרת אותו בהתאם למדיניות, מאפשרת חיפוש ושאילתות, מפעילה Detection logic ומספקת סביבת Case Management לחקירה. עם זאת, התקנת מוצר אינה יוצרת SOC טוב באופן אוטומטי. SIEM איכותי תלוי במקורות נכונים, זמן מדויק, Parsing תקין, בעלות על Rules ותהליך תגובה ברור.

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

למה ארגון צריך SIEM

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

המטרה השנייה היא עקביות. SIEM מאפשר לארגון להגדיר Use Cases, Severity, Owners, Playbooks וקריטריונים לסגירה. במקום שכל אנליסט יחליט מחדש כיצד לבדוק Password Spray או Malware alert, הצוות עובד לפי לוגיקה ותיעוד שניתן למדוד ולשפר.

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

השלב הראשון: מקורות נתונים ואיסוף

Data Source הוא המקום שבו נוצר האירוע: Windows Security Log, Syslog של Firewall, Audit log של SaaS, Telemetry של EDR או Authentication log של VPN. האיסוף נעשה באמצעות Agent, Data Connector, API, Syslog/CEF, Event Forwarding או שירות ענן מובנה. לכל שיטה קיימים יתרונות, מגבלות והרשאות.

לפני שמחברים מקור, מגדירים את מטרת האיסוף. השאלה אינה “אילו לוגים אפשר לשלוח?”, אלא “איזו התנהגות נרצה לזהות או לחקור, ואילו שדות דרושים לכך?”. Password Spray, לדוגמה, דורש לפחות זמן, תוצאת התחברות, משתמש, כתובת מקור ולעיתים אפליקציה או Tenant. אם שדה המשתמש חסר, Rule מתוחכם לא יפתור את הבעיה.

שכבה	דוגמאות למקורות	שאלת איכות מרכזית
זהות	Entra ID, Active Directory, VPN	האם יש משתמש, תוצאה, MFA וכתובת מקור?
Endpoint	EDR, Sysmon, Windows Events	האם יש Host, Process, Parent, Command line ו-hash?
רשת	Firewall, DNS, Proxy, IDS	האם יש Source/Destination, Port, Action ו-Protocol?
ענן ואפליקציה	AWS CloudTrail, Azure Activity, SaaS Audit	האם הפעולה, המשאב וה-Actor מזוהים?

Parsing, Normalization והעשרה

לאחר הקליטה, המערכת צריכה להבין את הרשומה. Parsing מחלץ שדות מתוך טקסט או JSON. Normalization ממפה שמות שונים למודל עקבי: src_ip, sourceAddress ו-ClientIP עשויים לייצג אותו רעיון. במיקרוסופט, ASIM מספק מודל נרמול שמאפשר לכתוב Query או Detection מול Schema אחיד במקום להתאים לוגיקה לכל מוצר בנפרד.

Normalization אינה מוחקת את המקור. מומלץ לשמור גם את האירוע הגולמי כדי לאמת פרטים ולחקור Parsing שגוי. כאשר Parser משתנה, Rule עשוי להפסיק לעבוד בשקט. לכן מודדים Schema changes, שדות ריקים, Ingestion delay ונפח חריג.

Enrichment מוסיף הקשר שלא הופיע בלוג: קריטיות הנכס, בעל המערכת, מחלקה, GeoIP, Threat Intelligence, האם החשבון Privileged, האם ה-IP שייך ל-VPN ארגוני והאם הפעילות תואמת Change מאושר. ההעשרה משנה את איכות ההחלטה. התחברות כושלת אחת לשרת בדיקות אינה זהה לאותה התחברות לחשבון Domain Admin.

זיהוי: מ-Query לתראה

Detection rule בוחנת נתונים לפי תנאי. היא יכולה לחפש Indicator מוכר, רצף אירועים, Threshold, סטייה מ-Baseline או שילוב מקורות. Scheduled rule מריצה Query בפרקי זמן ובוחנת Lookback window. אם התוצאות עוברות סף, נוצר Alert. מוצרים אחרים מייבאים Alerts מוכנים, ו-SIEM עשוי לאגד כמה מהם ל-Incident אחד.

Rule טוב מתחיל ב-Use Case ובהיפותזה, לא בפקודה טכנית. יש להגדיר מה ההתנהגות, אילו מקורות נדרשים, מה יחידה אחת של תוצאה, אילו Entities ימופו, מה Severity, מה Expected noise ומה האנליסט אמור לעשות. Rule שאינו ניתן לחקירה יוצר עומס גם אם הוא “תופס” הרבה אירועים.

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

Incident ו-Case Management

Alert מתאר התאמה מסוימת. Incident הוא תיק חקירה שמרכז Alerts, Entities, Evidence, Timeline, Tasks, Owner, Severity, Status ותגובות. Case Management מאפשר Hand-off, הסלמה, תיעוד והפקת מדדים. המערכת צריכה לשמור הפרדה בין עובדות, פרשנות והחלטה.

בעת פתיחת Incident, האנליסט בודק: מי המשתמש והנכס, מהו זמן הפעילות, אילו מקורות השתתפו, האם קיימים Alerts נוספים, מה קריטיות הנכס ומה השתנה ביחס להרגל. לאחר מכן הוא מריץ Queries משלימות, מאמת Indicators, בונה Timeline ומחליט אם מדובר ב-False Positive, Benign Positive או True Positive.

תרחיש: אירוע התחברות מהשרת למסך האנליסט

שרת Windows רושם אירוע התחברות עם זמן, משתמש, Logon type וכתובת מקור.
Forwarder או Connector שולח את האירוע ל-SIEM. המערכת מוסיפה זמן קליטה ומזהה את מקור הנתונים.
Parser מחלץ Account, Computer, Source IP ו-Result. שכבת Normalization ממפה אותם לשדות אחידים.
Enrichment מסמן שהחשבון Privileged ושהשרת Production. Threat Intelligence אינה מזהה את ה-IP, אך GeoIP מצביע על מדינה לא צפויה.
Rule מזהה כמה כשלונות ואחריהם הצלחה בתוך חלון זמן. היא ממפה User, Host ו-IP ויוצרת Alert.
Alert נוסף מ-EDR מזהה Process חריג באותה תחנה. Alert grouping מאגד את שניהם ל-Incident.
האנליסט בודק MFA, VPN, Process tree, DNS ופעילות נוספת, בונה Timeline ומחליט על Containment והסלמה.

מה SIEM אינו עושה לבדו

SIEM אינו מבטיח שכל הנתונים קיימים או נכונים. הוא אינו מחליף Asset inventory, IAM תקין, EDR, Network controls או אנשי מקצוע. הוא גם אינו יודע אוטומטית מה נורמלי עבור הארגון. ללא Owners ו-Tuning, המערכת עלולה להציף Alerts או ליצור תחושת ביטחון מזויפת.

אוטומציה יכולה להעשיר, לפתוח Ticket או לבודד נכס, אך פעולה אוטומטית חייבת להתאים לרמת הוודאות וההשפעה. חסימת משתמש קריטי על בסיס Rule רועש עלולה לגרום להשבתה. לכן מגדירים Approval, Exceptions, Rollback ו-Audit trail.

SIEM מול מערכות קרובות

מושג	מוקד	הבדל מעשי
Log Management	איסוף, שמירה וחיפוש	עשוי לא לכלול Detection ו-Case Management מלאים
SIEM	זיהוי, חקירה וניהול אירועים על בסיס נתונים מרובים	מחבר Telemetry לתהליך SOC
SOAR	אוטומציה ותזמור תגובה	מריץ Playbooks ומחבר מערכות; לעיתים משולב ב-SIEM
XDR	זיהוי ותגובה משולבים בדומיינים כגון Endpoint, Identity ו-Email	מגיע עם Telemetry ו-Detections עמוקים של פלטפורמה מסוימת

Checklist להטמעת Use Case

הוגדרה התנהגות ולא רק שם Rule.
מקורות הנתונים והשדות הדרושים זמינים.
זמן האירועים מסונכרן ואזור הזמן ברור.
Parsing ו-Normalization נבדקו בדוגמאות אמיתיות.
Entities וקריטיות נכסים ממופים.
הוגדרו Threshold, Severity ו-Expected noise.
קיים Playbook עם Queries משלימות ונתיב הסלמה.
נקבעו Owner, Review date ומדדי איכות.
נבדקו Retention, עלות והרשאות גישה.

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

לחבר כל מקור אפשרי לפני שמגדירים Use Cases.
להסתמך על Timestamp של הקליטה במקום זמן האירוע.
להניח שכל שדה בשם user מייצג אותה זהות.
ליצור Rule ללא Entity mapping או הוראות חקירה.
לסגור Alerts כרעש בלי להחזיר משוב ל-Detection owner.
להציג Dashboard ירוק כאשר מקור נתונים הפסיק לשלוח.
לשמור לוגים לתקופה שאינה מאפשרת חקירה היסטורית.

סיכום ו-CTA

בחרו Use Case אחד — למשל Password Spray — ושרטטו את כל השרשרת: מקור, שדות, Parser, Query, Entity, Incident ופעולת אנליסט. לאחר מכן עברו למדריך KQL כדי לכתוב את החיפוש הראשון. במסלול Cybersecurity & AI של HPI מתרגלים SIEM כחלק מתהליך חקירה מלא, כולל לוגים, רשתות, Windows ותגובה לאירוע.

שאלות ותשובות

האם SIEM הוא מוצר או תהליך?

SIEM הוא מוצר או פלטפורמה, אך הערך מגיע מתהליך הכולל איסוף, Data quality, Detection engineering, חקירה, תגובה ושיפור. רכישת רישיון בלבד אינה יוצרת יכולת SOC.

האם כל אירוע ב-SIEM הופך להתראה?

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

מה ההבדל בין Alert ל-Incident?

Alert הוא ממצא זיהוי יחיד. Incident הוא תיק חקירה שיכול לכלול כמה Alerts וראיות סביב אותו סיפור או Entity.

האם SIEM חייב להיות בענן?

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

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

מתחילים מנכסים וזהויות קריטיים ומ-Use Cases ברורים. בדרך כלל Identity, Endpoint, Firewall/DNS ו-Cloud audit מספקים בסיס חזק, אך הסדר תלוי בסיכון הארגוני.

מקורות

רוצים לבדוק אם המסלול מתאים לכם?

השאירו פרטים ונציג של HPI יחזור אליכם לשיחת התאמה קצרה וללא התחייבות.

ללימודי SOC וסייבר במסגרת תוכנית Cybersecurity & AI

רוצים לשמוע פרטים על התוכנית? השאירו פרטים ונחזור אליכם.

ללימודי SOC וסייבר במסגרת תוכנית Cybersecurity & AI יצירת קשר

על הכותב

תאיר מלכא

מייסד ומנכ״ל HPI ומרצה לסייבר

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

לפרופיל הכותב ↗

הקודם באשכול

SOC Metrics: המדדים שבאמת משפרים איתור ותגובה

הבא באשכול

KQL למתחילים: שאילתות ראשונות לחקירת אירועים