در بسیاری از سازمان‌ها، SIEM به‌عنوان قلب مرکز عملیات امنیت (SOC) معرفی می‌شود. جایی که قرار است تمام رویدادهای امنیتی جمع‌آوری، تحلیل و همبسته‌سازی شوند.
اما واقعیت تلخ این است:
SIEM  به‌اندازه‌ی کیفیت و پوشش لاگ‌هایی که دریافت می‌کند ارزش دارد، نه بیشتر.

پیاده‌سازی SIEM بدون استراتژی لاگینگ، چیزی جز یک داشبورد پر از نویز، آلارم‌های ناقص و حس امنیت کاذب تولید نمی‌کند.

SIEM  واقعاً چه کاری انجام می‌دهد؟

SIEM  ذاتاً تولیدکننده‌ی داده نیست، تفسیرکننده‌ی داده است. برخلاف یک تصور رایج، SIEM خودش هیچ رویداد امنیتی ایجاد نمی‌کند. این پلتفرم نه می‌بیند، نه شنود می‌کند و نه لاگ می‌سازد.SIEM  صرفاً روی داده‌هایی که از منابع دیگر دریافت می‌کند تحلیل انجام می‌دهد. به‌طور دقیق، نقش SIEM محدود به این مراحل است:

.1 جمع‌آوری لاگ‌ها (Log Collection)

SIEM  رویدادها را از منابعی مثل سیستم‌عامل‌ها، فایروال‌ها، تجهیزات شبکه، سرویس‌های هویتی وEndpointها و Applicationها دریافت می‌کند. اگر منبعی لاگ ارسال نکند یا لاگ ناقص بفرستد، از دید SIEM آن اتفاق هرگز رخ نداده است.

.2 نرمال‌سازی و استانداردسازی (Normalization)

لاگ‌های دریافتی معمولاً ساختارهای متفاوت دارند، نام فیلدهای ناهماهنگ دارند و از Vendorهای مختلف می‌آیند.SIEM  این داده‌ها را به یک مدل منطقی مشترک تبدیل می‌کند تا بتوان روی آن‌ها تحلیل انجام داد.
اما نرمال‌سازی فقط روی آن چیزی انجام می‌شود که وجود دارد SIEM نمی‌تواند فیلدی را که لاگ نشده، حدس بزند یا بسازد.

.3 ایجاد همبستگی (Correlation)

Correlation  مغز SIEM است. جایی که رویدادهای ظاهراً بی‌خطر در کنار هم به یک الگوی تهدید تبدیل می‌شوند

اما این همبستگی به شدت وابسته به Context  است:

✔ کاربر چه کسی بوده؟

✔ از کجا لاگین کرده؟

✔ چه پردازشی اجرا شده؟

✔ چه ارتباط شبکه‌ای برقرار شده؟

بدون این Context، Correlation  به مجموعه‌ای از تطبیق‌های سطحی تبدیل می‌شود که نه حمله را درست تشخیص می‌دهد و نه رفتار عادی را می‌شناسد.

4 . تولید هشدار (Alerting)

Alert خروجی نهایی SIEM است، نه نقطه‌ی شروع آن. کیفیت هر Alert مستقیماً تابع کیفیت داده‌ی ورودی است:

Garbage In → Garbage Out

حتی پیچیده‌ترین Detection Ruleها، اگر روی لاگ ناقص، داده‌ی بدون جزئیات یا Eventهای تحریف‌شده اجرا شوند، فقط هشدارهای گمراه‌کننده یا بی‌ارزش تولید می‌کنند.

مشکل اول: نبود Visibility واقعی

بدون لاگ مناسب، SIEM عملاً نقاط کور (Blind Spots) دارد.

نمونه‌های رایج:

• PowerShell  بدون Script Block Logging
• NTLM Authentication  بدون Eventهای دقیق
• RDP  بدون لاگ Session و Logon Type
• Firewall  فقط با Allow/Deny ساده بدون Context
• Endpoint  بدون Command Line Logging

📌  نتیجه:

در چنین شرایطی، مهاجم در زیرساخت حرکت می‌کند، دسترسی خود را گسترش می‌دهد و ردپا باقی می‌گذارد. اما SIEM به‌دلیل فقدان لاگ‌های معنادار، هیچ نشانه‌ای از این فعالیت‌ها دریافت نمی‌کند. نتیجه این است که Incident  نه در زمان وقوع، بلکه زمانی کشف می‌شود که مهاجم به هدف خود رسیده و هزینه‌ی پاسخ‌گویی چند برابر شده است.

Correlation  بدون Context یعنی آلارم کور

Correlation Rule ها به Context  نیاز دارند، نه فقط Event ID .

مثال:

4624 (Logon Success)

4688 (Process Creation)

اگر لاگ‌ها این موارد را نداشته باشند:

• Logon Type
• Source IP
• Parent Process
• Command Line
• User Privilege Level

SIEM  فقط می‌بیند یک لاگ آمد نه اینکه چه اتفاق خطرناکی افتاده.

False Positive  زیاد =  SIEM بلااستفاده

وقتی لاگ‌ها ناقص‌اند:

SIEM ✔  نمی‌تواند تشخیص دهد رفتار عادی است یا مشکوک

Rule ✔ ها بیش‌ازحد ساده می‌شوند

SOC ✔ غرق آلارم‌های بی‌ارزش می‌شود

نتیجه ی مستقیم این است که Analyst ها Alert Fatigue می‌گیرند، آلارم‌های واقعی نادیده گرفته می‌شوند و اعتماد به SIEM از بین می‌رود.

Threat Hunting بدون لاگ غیرممکن است

Threat Hunting  بر پایه‌ی فرضیه (Hypothesis) است، نه آلارم.

اما بدونtree  Process ، DNS Query Logs ، Network Flow، Authentication Trails و File Access Logs، فرآیند Hunting  تبدیل می‌شود به حدس‌زدن کورکورانه.

🎯  SIEM بدون لاگ مناسبHunting  را می‌کُشد، SOC  را Reactive نگه می‌دارد و blue team  را یک قدم عقب‌تر از مهاجم قرار می‌دهد

لاگ بد =  Forensics شکست‌خورده

در Incident Response، اولین سؤال این است: چه اتفاقی افتاد؟

بدون لاگ مناسب Timeline ساخته نمی‌شود، Root Cause مشخص نیست، Scope حمله مبهم می‌ماند و گزارش Incident ناقص است.

📌  از دید مدیریت اگر نمی‌دانید چه شده، چطور مطمئنید دوباره اتفاق نمی‌افتد؟

چرا بعضی SIEMها «بدنام» می‌شوند؟

در بسیاری از سازمان‌ها مشکل از SIEM نیست، مشکل از این‌ موارد است:

• Log Source  اشتباه
• Log Level  پایین
• Logging  غیرفعال برای Performance
• نبود Use Case مشخص
• جمع‌آوری لاگ بدون هدف امنیتی

بعد می‌شنوید که SIEM به درد نمی‌خورد درحالیکه:

SIEM  فقط به اندازه‌ی داده‌ای که می‌بیند هوشمند است

لاگ مناسب یعنی چه؟ (نگاه عملی)

لاگ مناسب یعنی:

✔ کامل (Complete) : نه فقط Event ID

✔ Context-aware : شامل User, Host, IP, Command

✔ قابل جستجو (Searchable) : ساختارمند

✔ قابل اعتماد (Trusted) : دستکاری‌نشده

✔ متناسب با Use Case امنیتی

نمونه حداقلی حیاتی:

• Windows :

4624 / 4625  با جزئیات

4688  با Command Line

PowerShell Script Block

• Network :

DNS Logs

NetFlow

• Endpoint :

Process Creation

File Write

• Identity :

Authentication Failures

Privilege Escalation

راهکار چیست؟ از لاگینگ درست تا هم‌افزایی SIEM و EDR

مسئله‌ی SIEM بی‌اثربا تعویض ابزار حل نمی‌شود، با اصلاح منبع داده حل می‌شود. راهکار واقعی، ساختن یک زنجیره‌ی منطقی از دیدپذیری تا تحلیل است.

1 . لاگینگ را به‌عنوان یک لایه‌ی امنیتی ببینید، نه تنظیم جانبی

قبل از هر Rule و Dashboard، باید به این سؤال پاسخ داده شود:

چه رفتارهایی را واقعاً می‌خواهیم ببینیم؟

بر این اساس:

Logging ✔ باید هدف‌محور (Use Case–Driven) باشد

Log Level ✔ ها بر اساس سناریوهای حمله تنظیم شوند، نه Performance صرف

✔ لاگ‌ها شامل Context عملیاتی باشند، نه فقط Event ID

بدون این مرحله، SIEM  صرفاً مصرف‌کننده‌ی داده‌ی ناقص خواهد بود.

.2  SIEM بدون EDR  = دید مرکزی بدون جزئیات رفتاری

بخش بزرگی از حملات مدرن Fileless  هستند، از Living-off-the-Land ابزارها استفاده می‌کنند و در سطح Endpoint اتفاق می‌افتند.

EDR دقیقاً همین خلأ را پر می‌کند:

• Process Tree
• Command Line
• Memory Behavior
• Parent–Child Relationship
• User Context

این داده‌ها وقتی به SIEM ارسال شوند، Correlation  از حالت تئوریک به تحلیل واقعی تبدیل می‌شود.

.3  EDR جای SIEM نیست! مکمل آن است

EDR رفتار را در لحظه می‌بیند، واکنش سریع (Containment) می‌دهد و دید عمیق Endpoint فراهم می‌کند. اما دید سراسری سازمان ندارد، Network و Identity را کامل پوشش نمی‌دهد و برای تحلیل‌های کلان مناسب نیست.

SIEM با دریافت داده‌های EDRحملات Endpoint را در سطح سازمانی می‌بیند، رفتارها را با Network و Identity همبسته می‌کند و Hunting را از تک‌نقطه‌ای به چندلایه ارتقا می‌دهد

4 . معماری درست:  EDR + Logging + SIEM

مدل بالغ امنیتی به‌جای اتکای کورکورانه به یک ابزار، این زنجیره را می‌سازد:

Endpoint / Network / Identity

        ↓

    Logging با Context

        ↓

     EDR (Behavior)

        ↓

      SIEM (Correlation)

        ↓

  Detection, Hunting, IR

در این معماریSIEM تصمیم‌گیر است، EDR چشم تیزبین است و لاگینگ ستون فقرات کل سیستم

جمع‌بندی نهایی

SIEM  بدون لاگ مناسب، فقط یک تحلیل‌گر خسته می‌سازد.
EDR  بدون SIEM، فقط یک دید محلی ارائه می‌دهد.

🔑 امنیت مؤثر زمانی شکل می‌گیرد که لاگینگ درست، EDR  رفتاری و SIEM تحلیلی در کنار هم کار کنند.