بزرگ ترین اشتباه در راه اندازی SIEM چیست؟ بررسی یک تجربه واقعی و راهکارهای عملی

بیایید روراست باشیم؛ سناریوی خرید و راه اندازی SIEM در اکثر شرکت ها یک رویای شیرین است: «این ابزار را میخریم، همه چیز را مانیتور میکنیم و بالاخره از حالت آتش نشانی که مدام به دنبال برطرف کردن بحران است، به یک شکارچی تهدید تبدیل میشویم.» اما بی تعارف، تجربه های میدانی چیز دیگری میگویند. آمارها میگویند که ۷۰ درصد پروژه های SIEM در سال اول یا شکست میخورند یا تبدیل میشوند به یک اسباب بازی گران قیمت که فقط لایسنس می بلعد و کسی هم واقعاً به هشدارهایش اعتماد ندارد. جالب اینجاست که دلیل این شکست ها معمولاً نه انتخاب ابزار اشتباه است و نه ضعف تکنولوژی. مشکل تقریباً همیشه از یک نقطه مشترک شروع میشود:

لاگ برداری بی هدف

باتلاق لاگ برداری بدون استراتژی، احتمالاً برایتان آشناست:

• SIEM نصب میشود.
• تیم امنیت و IT با انگیزه و هیجان شروع به کار کرده و همه چیز را لاگ میکنند.
• هر چیزی که لاگ دارد، باید وارد SIEM شود؛ از فایروال و Domain Controller گرفته تا سوئیچ ها، پرینترها و حتی دیتابیس ها.

در ظاهر، این تصمیم منطقی به نظر میرسد؛ هرچه داده بیشتر، دید بهتر... اینطور نیست؟

اما فقط مدت کوتاهی طول میکشد تا واقعیت خودش را نشان دهد. استوریج ها پر میشود، کوئری‌ها کُند میشوند و صفِ پردازش (Event Queue) سر به فلک میکشد. نتیجه؟ بچه های تیم SOC میمانند و هزاران آلرتِ "False Positive" که فقط سردرد ایجاد میکنند. تیم خسته میشود و مدیر میگوید: "SIEM فقط پول دور ریختن بود."

تضاد عجیبی اتفاق می افتد: با اینکه حجم داده ها خیلی بیشتر شده اما دید امنیتی عملاً کمتر شده است!

در حالی که واقعیت چیز دیگری است؛ مشکل از ابزار نیست، مشکل از نداشتن استراتژی است.

چرا لاگ برداری بی هدف SIEM را بی اثر میکند؟

SIEM برای انبار کردن داده ساخته نشده است. هدف آن تحلیل رفتار، همبستگی رویدادها و کشف الگوهای مشکوک است. وقتی حجم عظیمی از لاگ های بدون اولویت وارد سیستم میشود، نویزها به سرعت بالا میروند. هزینه لایسنس و ذخیره سازی افزایش پیدا میکند، آن هم بدون اینکه ارزش امنیتی متناسبی ایجاد شود. تحلیلگران SOC بیشتر وقتشان را صرف بررسی هشدارهایی میکنند که هیچ اقدام عملی پشتشان نیست و در این شلوغی، تهدیدهای واقعی به راحتی گم میشوند.

به عبارت ساده، داده زیاد بدون هدف، دشمن تشخیص تهدید است.

چطور یک SIEM کاربردی بسازیم؟

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

تعیین Use Case قبل از انتخاب لاگ

اولین و مهم ترین سؤال این است:

واقعاً میخواهیم چه چیزی را تشخیص دهیم؟

آیا تمرکز ما روی حملات احراز هویت است؟ یا رفتارهای غیرعادی کاربران؟ یا تغییرات غیرمجاز در زیرساخت؟

Use Case یعنی تعریف شفاف سناریوهایی که برای سازمان خطرناک هستند. مثلاً شناسایی Brute Force روی Active Directory، تشخیص دانلودهای غیرعادی از Proxy، اجرای مشکوک PowerShell یا تغییر ناخواسته Rule در فایروال.

وقتی Use Case مشخص باشد، انتخاب لاگ ها کاملاً هدفمند میشود. در غیر این صورت، SIEM فقط داده جمع آوری میکند.

انتخاب لاگ ها با نگاه استاندارد، نه سلیقه ای

استاندارد ISO/IEC 27002 دقیقاً به همین نقطه اشاره میکند. (این استاندارد در بخش ضمیمه های این پست، جهت دانلود قرار داده شده است) در این استاندارد، تأکید شده که رویدادهای مرتبط با دسترسی، تغییرات سیستمی، فعالیت های سطح بالا، ترافیک شبکه، رخدادهای امنیتی و رویدادهای حیاتی اپلیکیشن باید ثبت شوند. این یعنی لازم نیست همه چیز را لاگ کنیم بلکه باید همان  Eventهایی را جمع آوری کنیم که به تشخیص تهدید کمک میکنند.

در عمل، شروع کار با منابعی مانند فایروال، Domain Controller، VPN، EDR، Proxy، سرورهای حیاتی و WAF بیشترین بازده را دارد. بقیه منابع، اگر Use Case مشخصی نداشته باشند، در فاز ابتدایی پروژه بهتر است فعلاً به SIEM متصل نشوند.

لاگ مفید، قبل از ورود به SIEM ساخته می شود

یکی از اشتباهات رایج این است که انتظار داریم SIEM همه چیز را جادو کند. اما واقعیت این است که این سیستم نمیتواند لاگ بد را به اطلاعات مفید تبدیل کند.

هر منبع لاگ، زبان خودش را دارد. یکی زمان را به شکل UTC میفرستد، یکی Local. یکی از کلمه src_ip استفاده میکند، یکی  source و یکی اصلاً نام مشخصی ندارد. نتیجه این میشود که SIEM داده های زیاد و کاملی دارد اما نمیتواند بین آنها ارتباط معناداری برقرار کند.Log Normalization دقیقاً همین جا وارد میشود. در این مرحله، لاگ ها قبل از ورود به موتور تحلیل، یک دست میشوند:

مهرهای زمانی (Timestamp) هماهنگ میشوند، فیلدهای مشترک نام واحد میگیرند، داده های تکراری حذف میشوند و هر رویداد جای مشخصی در ساختار SIEM پیدا میکند. تا وقتی که لاگ ها Normalized نشده باشند، همبستگی (Correlation) واقعی اتفاق نمی افتد و هر Rule یا  Alertی که نوشته میشود، کار نمیکند و یا پر از خطا و Noise است.

به زبان ساده، Log Normalization یعنی تبدیل انبوه پیام های نامنظم به داده هایی که SIEM واقعاً بتواند آنها را بفهمد.

تعیین معیارهای سنجش کیفیت عملکرد SIEM (KPI)

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

برای مثال، اگر SIEM روزانه صدها هشدار تولید کند اما در نهایت فقط یکی دو مورد آن قابل پیگیری باشد، مشکل از ابزار نیست؛ از استراتژی هشداردهی است؛ یا اگر تشخیص یک حمله ساده چند ساعت طول بکشد، حتی دقیق ترین لاگ ها هم ارزش عملی خود را از دست میدهند.

KPIها کمک میکنند این مسائل پنهان دیده شوند. بدون آنها، قضاوت درباره موفق یا ناموفق بودن SIEM، بیشتر شبیه به حدس زدن است تا تحلیل واقعی.

مهم ترین  KPIهای عملی SIEM معمولاً موارد زیر هستند:

• MTTD (Mean Time to Detect): میانگین زمانی که طول میکشد تا یک تهدید شناسایی شود. هرچه این عدد کمتر باشد، SIEM مؤثرتر عمل کرده است.
• MTTR (Mean Time to Respond): زمانی که تیم امنیت برای واکنش به یک هشدار نیاز دارد. یک SIEM خوب و استاندارد، تصمیم گیری را سریع تر میکند.
• Noise Ratio: نسبت هشدارهای بی ارزش به کل هشدارها. اگر این عدد بالا باشد، یعنی SIEM بیشتر مزاحم است تا کمک‌کننده.
• True Positive Rate: درصد هشدارهایی که واقعاً به یک تهدید واقعی ختم شده اند.
• Actionable Alerts: تعداد هشدارهایی که واقعاً منجر به اقدام شده اند، نه فقط دیده یا بسته شده اند.

این شاخص‌ها کمک میکنند تا بفهمیم که SIEM واقعاً میبیند یا فقط اطلاعات نمایش میدهد.

بررسی یک تجربه واقعی

در یکی از پروژه ها، مشکل زمانی جدی شد که تیم SOC متوجه یک الگوی عجیب شد:

تقریباً همه ی  وقایعیهایی که واقعاً ارزش بررسی داشتند، نه از Alertهای SIEM، بلکه از گزارش کاربران یا بررسی های دستی کشف میشدند.

SIEM فعال بود، لاگ ها می آمدند، هشدارها هم کم نبودند اما وقتی یک Incident واقعی رخ میداد، ردّ آن در میان صدها Alert کم اهمیت گم میشد. در عمل، SIEM بیشتر وقت تیم را میگرفت تا این که به تصمیم گیری کمک کند.

در بازبینی اولیه مشخص شد تمرکز سیستم روی حجم داده بوده، نه رفتار مشکوک. لاگ ها جمع میشدند چون در دسترس بودند، نه چون به یک سناریوی تهدید مشخص پاسخ میدادند.

بعد از تغییر رویکرد و طراحی SIEM بر اساس Use Case، اولین تفاوت نه در داشبوردها، بلکه در رفتار تیم دیده شد. Alertها کمتر شدند اما هرکدام سؤال مشخصی ایجاد میکردند و مسیر بررسی داشتند. برای اولین بار، SIEM قبل از گزارش کاربران یا بررسی های دستی به یک Incident واقعی اشاره کرد.

همان ابزار بود و همان تیم؛ اما SIEM از یک سیستم غیر قابل اعتماد و گیج کننده، به یک ابزار قابل اعتماد تبدیل شد.

جمع‌بندی

اگر بخواهیم کل این تجربه را در یک جمله خلاصه کنیم:

SIEM با جمع کردن همه لاگ ها قوی تر نمیشود؛ با جمع کردن لاگ های درست قوی تر میشود.

Use Case شفاف، انتخاب هوشمندانه منابع، لاگ استاندارد و KPI مشخص، همان چیزهایی هستند که SIEM را از یک ابزار پرهزینه به یک سیستم مؤثر امنیتی تبدیل میکنند. SIEM زمانی واقعاً قدرتمند میشود که قبل از روشن کردن آن، بدانید دقیقاً دنبال چه چیزی هستید.