איך נראה אירוע סייבר ב-SOC (הסבר למתקדמים)

איך נראה אירוע סייבר ב-SOC (בשפה מקצועית של אנשי IT)

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

1. הבנה של העולם האמיתי, לא רק תאוריה

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

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

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

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

אדם שמתעניין בסייבר לא תמיד יודע אם הוא מתאים להיות SOC Analyst, Pen Tester, Incident Responder או Threat Hunter.

דרך התיאור של אירועים, רואים מי עושה מה, ואפשר לזהות לאיזה תפקיד מתחברים.

3. חשיפה לכלים וטכנולוגיות בשימוש אמיתי

מתעניין שומע שמות של כלים כמו SIEM, SOAR, EDR, Threat Intelligence, אבל לא תמיד מבין איך ולמה משתמשים בהם.

תיאור תהליכים ממחיש את תפקיד הכלים בתמונה המלאה.

זה ההבדל בין "יודע שיש דבר כזה Splunk" לבין "מבין מתי הוא מחלץ ערך ומה הקשר שלו ל-Windows Logs ול-SOAR".

4. פיתוח חשיבה מתודית ויכולת ניתוח

תיאורים כאלה מדגימים איך לחשוב סייבר:

• איך מזהים דפוס חריג?
• איך מחברים אינדיקציות?
• איך מקבלים החלטה אם מדובר באירוע אמיתי או False Positive?

זו התחלה של חשיבה כמו אנליסט – ולא רק כמו תלמיד.

5. הכנה לראיונות ומסלולי לימוד

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

מסייעת לענות על שאלות טכניות ("איך היית מטפל באירוע פישינג?")

עוזרת להבין את הלוגיקה של SOC

מקלה על ההבנה של קורסים או חומרי לימוד

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

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

אירוע 1': טיפול באירוע חשד לפישינג שגרם להשתלטות על תחנת עבודה

תיאור טכני כרונולוגי ברמה של אנשי IT

שלב 1: זיהוי ראשוני: SIEM מרים דגל

אחראי: מערכת SIEM

מה קורה: מערכת ה-SIEM אוספת לוגים ממערכות דוא"ל, תחנות קצה, Active Directory ועוד.

אירוע מתרחש: מתגלה חריגה – משתמש לוחץ על לינק מדוא"ל חשוד שהועבר דרך Microsoft 365, שמוביל לאתר התחזות.

ה-SIEM מייצר התראה:

• שימוש ב-rule שמזהה לחיצה על URL חשוד (המופיע ב-RBL או ב-URL blacklist).

הסבר: 

Rule (חוק) הוא תנאי שמוגדר בתוך ה-SIEM – למשל, "אם משתמש לחץ על URL, וה-URL נמצא ברשימת כתובות חשודות – תייצר התראה".

RBL (Realtime Blackhole List) או URL Blacklist הן רשימות שמתעדכנות תדיר, הכוללות כתובות URL, דומיינים, או IP-ים שזוהו כמסוכנים או מתחזים. אי אפשר לבדוק כל URL ידנית. ברגע ש-URL מסוים נכנס ל-blacklist בינ"ל או פנימי, ה-SIEM יכול להשוות מולו ולזהות שמדובר בלחיצה על משהו מסוכן.

• ההתראה כוללת את כתובת ה- IP, שם המשתמש, השעה, ושורת הנושא של המייל.

הסבר: איך ה-SIEM מייצר התראה באירוע פישינג?

ה-SIEM אינו "יודע" לבד שמדובר בפישינג. הוא מקבל לוגים ממקורות שונים (כגון Microsoft 365, שרת דואר, EDR, פרוקסי) ומפעיל עליהם סט חוקים (rules) שנכתבו מראש.

דוגמה לאינדיקציות שגורמות להתראה:

- לוג מדווח על משתמש שלחץ על URL כלשהו במייל.

- ה-URL נבדק מול רשימת דומיינים מסוכנים (RBL/URL Blacklist) ומופיע שם.

- כתובת ה-URL מקודדת או מקוצרת (bit.ly), אך בפענוח היא מובילה לאתר שמדווח עליו כאתר התחזות.

- זמן הלחיצה יוצא דופן (אמצע הלילה, או בבת אחת עשרות עובדים).

- נשלח מאותו דומיין לעובדים שונים, עם תוכן דומה.

ה-SIEM משלב בין הפרמטרים האלה ומייצר קורלציה – לדוגמה, "אם URL חשוד + נלחץ ע"י משתמש + מתוך מייל  ==> הפעל התראה מסוג: חשד לפישינג".] 

שלב 2: העשרה: SOAR אוסף מידע תומך

אחראי: מערכת SOAR

מה קורה: תהליך אוטומטי מופעל – Playbook שהוגדר מראש לאירוע פישינג.

הסבר: מה זה Playbook?

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

SOAR משלים מידע באופן אוטומטי:

• מאמת אם הלינק דווח כבר בעבר (VT, URLscan, AbuseIPDB).
• שואב מידע מתוסף הדפדפן אם מותקן (Extension Logger).
• בודק אם המשתמש הקליד סיסמה לאחר הכניסה לאתר החשוד.
• בודק אם נוצרו חיבורים חריגים מהמכונה (חיבור לשרת בכתובת IP לא מוכרת).

מהו מקור המידע שממנו מגיעים הנתונים כמו IP, שם המשתמש, השעה, ושורת הנושא?

הנתונים מגיעים מלוגים שנשלחים ל-SIEM ממערכות שונות, לדוגמה:

הלוגים נשלחים ל-SIEM בפורמט אחיד (JSON, Syslog, CEF) וכוללים שדות שמתויגים לפי תוכן – כך שה-SIEM יודע לשלוף אותם בעת יצירת התראה.

שלב 3: הערכה אנושית ראשונית

אחראי: אנליסט SOC Tier 1

מה קורה: האנליסט מקבל את ההתראה המועשרת מה-SOAR ומבצע בדיקה ראשונית:

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

שלב 4: העברת הטיפול ל-Tier 2

אחראי: אנליסט SOC Tier 2

מה קורה:

• מבצע איסוף לוגים נוספים (EDR, AD, Proxy Logs).
• מנתח את פעילות התחנה אחרי הלחיצה: האם הופעלו סקריפטים, האם נפתח PowerShell.
• מאתר אינדיקציות להשתלטות – חיבורים לשרתים חיצוניים, יצירת משתמשים חדשים ב-AD, תנועה פנימית ברשת.

שלב 5: נקיטת פעולה

אחראים: Tier 2 ו-Infra/IT יחד

מה קורה:

• SOAR מבצע אוטומטית את הניתוק של התחנה מהרשת (EDR Isolation).
• מושבת חשבון המשתמש ב-AD זמנית.
• מופעל סקריפט בדיקה בתחנה לבדיקת Persistence.
• מבוצע Reset לסיסמה במערכות קריטיות.

שלב 6: סיום האירוע ודיווח

אחראי: SOC Manager ו-GRC/Compliance

מה קורה:

• כתיבת דו"ח Post-Incident (אירוע, תגובה, ממצאים, פעולות מתקנות).
• הדו"ח כולל סטטוס אירוע: האם הסתיים, מה היה הסיכון, מה תוקן.
• המלצות לשיפור: לדוגמה – הוספת אימות דו-שלבי, חסימת דומיינים דומים, חינוך משתמשים.

האירוע נחתם ב-SIEM כ"טופל וסגור".

אירוע 2': טיפול באירוע חשד לתקיפה דרך שרת ציבורי (שרת Apache עם חולשת 0-Day)

תיאור טכני כרונולוגי ברמה של אנשי IT

שלב 1: זיהוי ב-SIEM

• מקור הלוג: WAF ושרת Apache.
• זיהוי: חוק ב-SIEM מזהה ניסיונות חוזרים לשליחת בקשות HTTP עם Payload חשוד (Command Injection).
• פרטים באירוע: IP תוקף, URI, תבנית של Exploit ידוע (למשל "() { :;};" מ-Bash).

הסבר:

החוק ב-SIEM מוגדר לזיהוי דפוסי התקפת Command Injection על שרתי Apache דרך ניטור לוגים. החוק ב-SIEM נכתב כך שיזהה דפוס חוזר של בקשות HTTP יוצאות או נכנסות עם מאפיינים חריגים, כמו פקודות מערכת בקלט (למשל ;wget או |bash). החוק סורק את לוגי ה-WAF וה-Apache, מחפש מחרוזות שמעידות על ניסיון Injection, וסופר את מספר הפעמים שזה קורה בפרק זמן קצר — כדי להפעיל התראה רק כשמדובר בדפוס תקיפה מובהק.

שלב 2: SOAR מריץ תגובה אוטומטית

• בודק אם ה-IP מופיע ב- Threat Intelligence.
• שולף לוגים נוספים מהשרת (access.log, error.log).
• שולף Process Tree מהשרת דרך סוכן (EDR או agent מותאם).
• שולף hash של קובצי executables שעלו ב-2 השעות האחרונות.

הסבר:

בשלב זה, ה-SOAR מגיב אוטומטית להתראה מה-SIEM. הוא בודק אם כתובת ה-IP מופיעה במקורות Threat Intelligence — מאגרי מידע שמרכזים כתובות, דומיינים, hash-ים וחתימות שנקשרו לתוקפים. לאחר מכן נשלפים קבצי access.log (שמתעדים כל בקשת HTTP לשרת) ו-error.log (שמתעדים שגיאות ובעיות בהרצת הקוד). ה-SOAR גם שואב את עץ התהליכים (Process Tree), כלומר תרשים היררכי של כל התהליכים שרצו על השרת בזמן הרלוונטי, כדי לזהות הרצות חשודות. לבסוף, נאספים hash-ים של קבצי הרצה שעלו לאחרונה — לבדיקה מול מאגרי קוד זדוני.

ה-hash של קובצי executables (קבצים ניתנים להרצה) הוא מזהה ייחודי שמחושב לפי תוכן הקובץ, בדומה לטביעת אצבע. הוא מאפשר לבדוק אם קובץ חדש או חשוד כבר מוכר כזדוני על ידי השוואה למאגרים של קוד מזיק (כמו VirusTotal או Threat Intelligence).

שלב 3: ניתוח אנושי (Tier 2)

• בודק אם נוצר קובץ לא מוכר בתיקיית tmp או var.
• בודק reverse shell ב-Process Tree.
• משווה תעבורת רשת מול תקשורת חשודה (למשל אל TOR או VPS זול מחו"ל).
• מריץ בדיקת שלמות קבצים – האם נגעו בקובצי Apache או auth.

הסבר:

בשלב זה, אנליסט סייבר מנוסה בודק אם נוצרו קבצים חשודים במיקומים נפוצים להתקפות, כמו /tmp או /var (תיקיות זמניות שקוד זדוני משתמש בהן). הוא סורק את ה-Process Tree כדי לזהות "reverse shell" – תהליך שבו השרת יוצר חיבור יזום החוצה, המאפשר לתוקף שליטה מרחוק. בנוסף, הוא משווה את תעבורת הרשת לכתובות חשודות, למשל לרשת TOR או VPSים זולים שמזוהים עם תקיפות. לבסוף, הוא מריץ בדיקת שלמות קבצים (File Integrity Check) כדי לוודא שלא שונו קובצי Apache או קובצי הרשאות (auth), שמהווים מטרות שכיחות לתוקפים.

שלב 4: פעולות תגובה

• חוסמים את כתובת ה-IP ב-Firewall ו-WAF.
• מבוצע snapshot וניתוק השרת מהרשת (אם קיים חשד להשתלטות).
• עותקים מועברים לסביבת Forensics.
• מועלה שרת גיבוי חלופי לאחר בדיקות עדכניות.

הסבר:

בשלב זה ננקטות פעולות ישירות למניעת נזק נוסף:

– כתובת ה-IP של התוקף נחסמת ב-Firewall וב-WAF כדי למנוע המשך גישה.

– אם קיים חשד להשתלטות, מבוצע snapshot (העתק מצב מלא של השרת) לפני כל שינוי, והשרת מנותק מיד מהרשת כדי לעצור את התקיפה.

– העותק מועבר לסביבת Forensics – סביבה מבודדת שמאפשרת ניתוח מעמיק של מה התרחש בלי לשבש ראיות.

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

שלב 5: Lessons Learned ודוח אירוע

• מיפוי חולשת  zero-day (או misconfiguration).
• המלצה לעדכון אוטומטי של גרסאות Apache.
• ניטור מראש של קבצים מבוצעים, חיבור WAF ל-SIEM, הקשחת הרשאות כתיבה.

הסבר:

לאחר סיום הטיפול באירוע, צוות ה-SOC מבצע תחקור (Post-Incident Review) כדי להפיק לקחים. הם ממפים את מקור הפגיעה – האם הייתה זו חולשת zero-day (חדשה ולא מתוקנת) או תצורה שגויה (misconfiguration) שאפשרה לתוקף להיכנס. על סמך זאת, ניתנות המלצות לשיפור, כמו הפעלת עדכונים אוטומטיים ל-Apache, ניטור שוטף של קבצים שמבוצעים על השרת, חיבור ה-WAF למערכת ה-SIEM כדי לשפר יכולות זיהוי, והקשחת הרשאות כתיבה כדי למנוע מהתוקף להעלות או לשנות קבצים בשרת.

אירוע 3': טיפול באירוע חשד חיבור USB לא מורשה בתחנה רגישה

תיאור טכני כרונולוגי ברמה של אנשי IT

שלב 1: זיהוי ב-SIEM

• מקור הלוג: Endpoint protection או Windows Event Logs.
• זיהוי: SIEM מזהה אירוע Event ID 2003: Device connected, שלא תואם לרשימת רכיבי USB המורשים.
• מתווספת התראה לפי חוק: "USB לא מזוהה מחובר לתחנה רגישה."

הסבר:

מערכת ה-SIEM מקבלת לוגים ממערכות ההגנה בתחנות קצה (Endpoint Protection) או מ-Windows Event Logs. היא מזהה את Event ID 2003, שמצביע על חיבור התקן חדש ל-USB.

ה-SIEM משווה את זיהוי ההתקן לרשימת USB-ים מאושרים מראש (Whitelist), ומזהה שההתקן אינו מוכר – דבר שמעורר התראה: "USB לא מזוהה חובר לתחנה רגישה."

מונחים:

Event ID 2003 – מזהה סטנדרטי בלוגים של Windows לחיבור התקן.

Whitelist – רשימת התקנים או ערכים מותרים מראש.

שלב 2: תגובת SOAR

• מאמת את סוג המכשיר (disk, smartphone, HID).
• משווה את ה-Serial Number למאגר מותרים.
• בודק לוגים של תהליכים שהופעלו מיד לאחר החיבור.
• שולף מידע מה-EDR: האם הופעלו קבצים מתוך ה-USB.

הסבר:

מערכת SOAR (אוטומציה של תגובות סייבר) מופעלת מיד. היא בודקת:

מהו סוג ההתקן שחובר (למשל דיסק, סמארטפון או HID כמו מקלדת).

האם המספר הסידורי שלו (Serial Number) נמצא ברשימת המורשים.

אילו תהליכים הופעלו מיד לאחר החיבור – לדוגמה, האם הופעל קובץ אוטומטי מהדיסק.

האם מערכת ה-EDR (מערכת לזיהוי ותגובה בתחנת הקצה) זיהתה הפעלה של קובץ מה-USB.

שלב 3: ניתוח אנושי (Tier 1 או 2)

• מזהים שהתחנה נמצאת באגף כספים, משתמש בכיר.
• מבוצעת פנייה למשתמש לבדיקה: "האם אתה חיברת USB? האם של החברה?"
• מבוצע סריקת תחנה עם אנטי-וירוס מתקדם, EDR, ומחפש artifacts.

הסבר:

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

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

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

שלב 4: תגובה

• אם יש חשד ל-malware: מבוצע בידוד של התחנה.
• סיסמאות מוחלפות לפי נהלים.
• הודעה להנהלה ואחראי אבטחת מידע.
• הרצת סקריפט דרך SOAR/SCCM להוצאת לוגים מכל התחנות עם חיבור USB באותו היום.

הסבר:

אם יש חשד לפעילות זדונית (malware), התחנה מבודדת מיד מהרשת כדי למנוע הדבקה.

מבצעים החלפת סיסמאות לפי נהלי אבטחת מידע.

האירוע מדווח להנהלה ול-CISO (מנהל אבטחת המידע).

בנוסף, נשלח סקריפט אוטומטי (דרך SOAR או SCCM) לשאר התחנות בארגון, לשם שליפת לוגים של כל חיבורי USB שנעשו באותו יום – כדי לבדוק אם מדובר באירוע נקודתי או חלק ממתקפה רחבה (SCCM: מערכת של מיקרוסופט לניהול תחנות קצה והפצת תוכן).

שלב 5: סגירת האירוע והפקת לקחים

• הכנסת רשימת "USB Whitelist" עדכנית למערכת DLP.
• חיזוק מדיניות: Block all USB except keyboard/mouse.
• ריענון נוהלי עובדים ואזהרות לגבי ציוד חיצוני.
• הכנסת חוק נוסף ב-SIEM לזיהוי ניסיון קריאה מקבצים מוצפנים ב-USB.

הסבר:

לאחר חקירה, מעדכנים את רשימת ההתקנים המורשים (USB Whitelist) במערכת למניעת דליפות מידע (DLP).

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

הארגון מבצע ריענון נהלים לעובדים ומחדד איסורים על חיבור ציוד חיצוני לא מאושר.

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